SCRUM: AGILIDADE EM SEU PROJETO
01. O Scrum e a Sprint
O que é o Scrum?
O Scrum é um framework ágil e sua principal característica
é trabalhar com time-boxes: caixas de tempo cujo tamanho,
uma vez definido, não muda durante a Sprint atual.
O que é o Sprint (ou iteração do Scrum)?
Sprint é a time-box básica do Scrum. Ela é o tempo que o
time tem para agregar valor para o usuário do projeto.
Duração de Sprint
O tempo máximo de uma Sprint é limitada a 1 mês, um
tamanho de Sprint mais factível para um projeto é de 2
semanas.
Critérios para aumentar a Sprint
Vamos supor que a duração atual de uma Sprint é de uma
semana. Os itens abaixo podem estimular a decisão pelo
aumento da duração das Sprints futuras:
- O time é muito pequeno e a tecnologia não os ajuda a
produzir valor rapidamente.
- Meu cliente passa uma semana em Chicago e outra aqui,
alternando.
- Falta conhecimento técnico para o time.
Sempre que não estamos conseguindo entregar ou validar
o valor entregue, pode ser necessário aumentar o tamanho
da Sprint.
Problema de Sprint grandes
Ao escolher um mês de duração de uma Sprint, em vez de
uma semana, menos chances de feedback temos e,
portanto, maior o risco de errarmos o que precisa ser feito.
02. Review meeting (Reunião de Revisão)
Qual o propósito da Review Meeting? Quem está
presente nesta reunião?
A Review Meeting é uma reunião para mostrar o que o time
produziu nessa Sprint para o cliente ou usuário.
Participam dessa reunião o time todo (desenvolvedores,
Product Owner e Scrum Master) e mais o cliente e/ou
usuários interessados nos itens desenvolvidos nessa Sprint.
Bugs e novas ideias
Ao avaliar o que foi feito, o cliente pode encontrar erros de
entendimento, bugs ou mesmo ter ideias novas sobre o
projeto.
O Product Owner deve anotar as modificações que serão
necessárias, transformá-las em histórias e adicionar ao
Product Backlog, na prioridade que couber a elas.
Correções de bugs
Se na hora da Review Meeting o cliente encontrar um bug e
o desenvolvedor sabe corrigir, ele não deve fazer neste
momento, pois isso desfocará a reunião, podendo consumir
todo o time-box.
Usuário ou cliente?
A vantagem de trazer um usuário final na Review, em vez
de apenas o cliente é que podemos acompanhar o mesmo
usando o sistema e aprender a pensar como ele. Além
disso, ainda que um cliente dê ok para uma funcionalidade,
ele pode ter alguma falha de comunicação com seu usuário,
pois o que está certo para o cliente pode não atender quem
realmente interessa: o usuário do projeto.
Definição de Pronto
A Definição de Pronto é uma sequência de passos pelos
quais cada história (item de desenvolvimento) precisa
passar para sair de “A fazer” e ser considerada “Pronta”,
isto é, mostrável para o cliente.
Exemplo:
Teste de aceitação -> Desenvolvimento -> Code Review ->
Aprovando -> Pronto
03. Retrospectiva
Retrospectiva
Para que serve a reunião de retrospectiva?
A retrospectiva é a maior oportunidade, em cada Sprint, de
promovermos melhorias no processo, no time e no
andamento do projeto que está sendo desenvolvido. Ela
promove a melhoria contínua.
Resultado da Retrospectiva
Esperamos obter Ações de melhoria ao final de cada
retrospectiva.
Prime Directive
Texto de Norm Kerth conhecido como a diretiva primária de
retrospectivas
“Independentemente do que descobrirmos, nós
entendemos e acreditamos de verdade que todos fizeram o
melhor trabalho que puderam, dado o que eles sabiam no
momento, suas habilidades e perícia, os recursos
disponíveis e a situação que enfrentaram.”
04. Daily Scrum
Três perguntas
Quais são as 3 perguntas que o time responde em um Daily
Scrum?
- O que fiz desde o último Daily Scrum?
- O que pretendo fazer até o próximo?
- Quais problemas me atrapalharam?
Daily Scrum
Fazemos a Daily Scrum para todos saberem como está o
andamento das tarefas e histórias nessa Sprint, evitando
retrabalho e ajudando uns aos outros. A Timebox é de 15
minutos.
Problemas apontados
Quando um membro do time relata um problema que está
tendo, quem sabe ajudar, indica que sabe e eles conversam
depois da Daily para que o Timebox não seja todo
consumido.
05. Planning Meeting (Reunião de planejamento)
Planning Meeting
No Scrum, toda Sprint começa com uma reunião para
enterdermos os itens a serem feitos, planejarmos o que
cabe no tempo disponível e definirmos a meta para o time
nessa Sprint. A reunião consome 5% do tempo da Sprint
então, para Sprint de uma semana, a reunião dura no
máximo 2 horas.
Quem deve estar presente
Deveriam estar presente em todo Planning Meeting o time
todo: desenvolvedores, Product Owner e Scrum Master.
Preparação para a reunião
Em preparação para essa reunião, o P.O deve ter olhado as
histórias mais prioritárias do projeto, confirmando o
entendimento delas com o cliente, melhorando sua clareza,
quebrando grandes funcionalidades em partes menores que
já agregam valor para o cliente, etc.
Este processo é conhecido como refinement, ou
refinamento, do topo do Product Backlog.
Meta
A meta é uma frase que exprime o maior valor que esse
Sprint vai trazer para o usuário.
06. Product Backlog, Sprint Backlog e suas partes
O que é uma história (user story)
Uma história representa algo que agrega valor para o
usuário da aplicação. Seja no Product Backlog, como um
item a fazer, ou no nosso histórico do que foi feito no
projeto, histórias representam o valor que agrega(re)mos
para o usuário!.
O que é uma tarefa (task)
Tasks são um subitem técnico da história, para
conseguirmos dividir o trabalho entre diversos
desenvolvedores.
Conteúdo de Product e Sprint Backlogs
Diferenças no conteúdo dos backlogs descritos no Scrum.
O Product Backlog só tem histórias e o Sprint Backlog tem
histórias e tarefas.
Quem altera os Backlogs
Product Backlog – apenas o P.O altera, mas todos podem
influenciá-lo, tanto desenvolvedores, scrum master e
clientes.
Sprint Backlog – O cliente não pode alterá-lo ou influenciá-
lo. Apenas o time altera esse backlog, renegociando
internamente o escopo quando necessário, quebrando
melhor as histórias em tarefas, etc.
07. Scrum Master
Scrum Master nas reuniões
O Scrum Master é o responsável por garantir que o Time
Scrum se oriente pelos valores e práticas do Scrum.
O Scrum Master age para manter a reunião produtiva e
dentro do timebox combinado.
Ele não coordena reuniões como faria um chefe tradicional,
apenas ajuda o time a manter o foco!
O Scrum Master:
- Facilitador
- Educador sobre o processo
- Resolve impedimentos
Problemas e Impedimentos
Enquanto problemas são feitos de qualquer coisa que
atrapalhe o time, ele só se tornam impedimentos quando o
time tentou resolvê-lo e não conseguiu.
08. Product Owner
Representante do cliente dentro do time.
Mantém o product backlog atualizado.
O Product Owner representa os interesses de todos os
envolvidos (Stakeholders), define as funcionalidades do
produto e prioriza os itens de Product Backlog.
Cliente e P.O.
Diferença ente um cliente e um product owner.
Diferentemente de clientes/usuários, o P.O. é uma pessoa
só e trabalha diariamente com o time no decorrer do
projeto. Product Owner é uma pessoa que faz parte do time
e está disponível para ajudá-lo a produzir o maior valor
possível para os clientes.
Atualização do Backlog
A principal função do Product Owner é manter o Product
Backlog devidamente atualizado.
O P.O. adiciona novos itens, remove itens que não fazem
mais sentido e, muito frequentemente, reprioriza as
histórias para aumentar o valor a ser agregado pelo time.
Outra atividade é o refinamento das histórias mais
prioritárias do Product Backlog em histórias menores que
ainda agreguem valor para o cliente.
09. Desenvolvedores
Desenvolvedores
- Todos que ajudam o projeto a andar para frente.
- Estimam o esforço para realização das histórias.
- Negociam quais tarefas serão realizadas no sprint.
- Decidem quem faz o quê.
Quem é desenvolvedor?
Programadores, arquitetos, DBAs, analistas, testers,
pessoas de usabilidade e quaisquer outros papéis que
ajudam o produto a evoluir.
Responsabilidades do dev
Em um ambiente ágil há muitas atividades pelas quais os
desenvolvedores se tornam responsáveis, a liberdade para
crescer na carreira e a autonomia são pontos
extremamente positivos.
Apenas, não vale passar por cima das decisões do P.O.
sobre o Product Backlog!
Ex: Pegar pedidos do cliente.
10. O time todo
Pessoas diferentes
Por que os papéis de Scrum Master e Product Owner não
podem ser ocupados pela mesma pessoa?
Há muitas responsabilidades focadas na entrega de valor
que são dos Product Owners. Há muitas responsabilidades
focadas em processos que são do Scrum Master.
Juntar ambos os papéis é um acúmulo muito grande de
responsabilidades e frequentemente leva ao abandono de
um dos lados, desbalanceado o equilíbrio do Scrum.
Melhoria continua
Qualquer ponto que causa dor ao time no momento é uma
oportunidade de melhoria para o futuro –e é um treino
contínuo enxergar problemas como oportunidades.
Melhoria contínua é também, na minha opinião, uma forma
de pensar que nos torna mais responsáveis pelo estado em
que nos encontramos no momento. É uma
responsabilização que ajuda a sair do hábito de reclamar e
procurar culpados. E é algo que pode ser levado para outros
aspectos da vida facilmente.
