Como começar implementar o Scrum


“Qualquer projeto não é resultado do trabalho de uma única pessoa, é o produto do trabalho de uma equipe.” Jeff Sutherland (Co-Criador do Scrum)

1 – Escolha um Product Owner.
Essa pessoa é a responsável pela visão do que você vai fazer ou conseguir. Ele leva em consideração os riscos e benefícios, o que é possível, o que pode ser feito e o que desperta a paixão na equipe.

2 – Escolha uma equipe.
Quem são as pessoas que realmente trabalharão no projeto? Essa equipe precisa ter todas as habilidades necessárias para pegar a visão do Product Owner e transforma-la em realidade. As equipes devem ser pequenas, entre três e nove pessoas é o principio básico.

3 – Escolha um Scrum Master.
 Essa pessoa vai orientar o restante da equipe em relação à estrutura do Scrum, alem de ajudar a eliminar qualquer obstáculo que os esteja deixando mais lentos.

O olhar para melhoria dos processos é chave para um bom Scrum Master, como mostra neste vídeo, de uma moça que faz uma pequena melhoria e aumenta significativamente os resultados, ajudando as equipes se tornarem hiperprodutivas.



4 – Crie e priorize uma lista de Pendências do Produto (Product Backlog).
 Trata-se de uma lista detalhada de tudo que precisa ser feito ou construído para transformar a visão do produto em realidade. Essas Pendências (Backlog) existem e evoluem durante o desenvolvimento do produto; elas são o mapa do produto. Em qualquer fase do projeto, são a única e definitiva visão de “tudo que precisa ser feito pela equipe a qualquer momento, em ordem de prioridade”.

 Só existe uma lista de Pendências (Backlog); isso significa que o Product Owner precisa tomar decisões em relação às prioridades durante todo o processo; ele deve consultar todos os stakeholders e a equipe para se certificar de que elas representam tanto o que as pessoas querem, quanto o que pode ser construído.

5 – Aperfeiçoe e faça estimativas para as Pendências do Produto(Backlog).
 É crucial que as pessoas que irão realmente concluir os itens da lista façam as estimativas de quanto esforço eles exigirão. A equipe deve olhar para cada item do Backlog e ver se aquilo é factível. Existem informações suficientes para concluí-lo? Ele é pequeno o suficiente para ser estimado? Existe uma definição de “Feito”? Ele cria valor visível? Cada item deve poder ser mostrado, demonstrado e esperançosamente ser entregue.

Não estime as Pendências em horas, porque as pessoas são péssimas nesse tipo de previsão. Faça isso usando uma classificação relativa por tamanho: Pequeno, Médio ou Grande. Ou, melhor ainda, use a sequência de Fibonacci e faça estimativas de pontos para cada item: 1,2,3,5,8,13,21 etc.

Sequência de Fibonacci


6 – Planejamento do Sprint (Sprint Planning).
Esta é a primeira das reuniões Scrum. A equipe, o Scrum Master e o Product Owner se reúnem para planejar o Sprint, que sempre tem uma duração definida de tempo menor que um mês. A maioria das pessoas define Sprints de uma ou duas semanas. As equipes olham para as tarefas no topo do Backlog e estimam o quanto podem fazer naquele Sprint. Se a equipe já está trabalhando a alguns Sprints, ela deve pegar  tarefas que totalizem o mesmo número de pontos do Sprint anterior. Esse número é conhecido como a Velocidade da equipe. O Scrum Master e a equipe devem tentar aumentar o número de pontos a cada Sprint. Essa é outra chance para a equipe e o Product Owner se certificarem que todos entendem como os itens vão satisfazer a visão. Além disso, durante essa reunião todos devem concordar com o Objetivo do Sprint.

Um dos pilares do Scrum é que uma vez que a equipe se comprometeu com o que acredita ser capaz de fazer em um Sprint, fica sendo isso. Ele não pode ser mudado, nada pode ser acrescentado. A equipe deve trabalhar de forma autônoma durante o Sprint para concluir o que previu que conseguiu.

7 – Torne o trabalho visível.
 O melhor jeito para se fazer isso no Scrum é criar um Quadro Scrum com três colunas: A fazer, Fazendo e Feito. Post-its representam os itens que precisam ser concluídos e a equipe os move pelo Quadro Scrum à medida que forem concluídos, um a um.

Outro modo de tornar o trabalho visível é criar um Gráfico de Burndown. Um eixo é o número de pontos que a equipe definiu para o Sprint, o outro é o número de dias. Todos os dias, o Scrum Master soma o número de pontos concluídos e os marca no gráfico. O ideal é que haja uma ladeira descendo pelo gráfico até chegar ao zero no último dia do Sprint.

8 – Reuniões Diárias (Daily Meeting).
Este é o ritmo do Scrum. Todos os dias no mesmo horário, durante não mais que 15 minutos, a equipe e o Scrum Master se reúnem para responder três perguntas:
·        O que você fez ontem para ajudar a equipe a concluir o Sprint?
·        O que você vai fazer hoje para ajudar a equipe a concluir o Sprint?
·        Existe algum obstáculo impedindo você ou a equipe de alcançar o objetivo do Sprint?

Isso é tudo durante a reunião. Se ela levar mais do que 15 minutos, você está fazendo alguma coisa errada. Isso serve para ajudar a equipe inteira a saber exatamente em que ponto estão no Sprint. Todas as tarefas serão concluídas a tempo? Existem oportunidades para ajudar os outros membros da equipe a superarem os obstáculos? Não há designação de tarefas vindas de cima – a equipe é autônoma; são eles que fazem isso. Não há qualquer relatório detalhado para os gestores. O Scrum Master é responsável por resolver qualquer obstáculo ou impedimento para o progresso da equipe.

9 – Revisão ou Demonstração do Sprint (Sprint Review).
Trata-se da reunião a qual a equipe mostra o que conseguiu fazer durante o Sprint. Qualquer  pessoa pode participar, não apenas o Product Owner, o Scrum Master e a equipe, mas também os stakeholders, os gestores, os clientes, e qualquer outra pessoa. Esta é uma reunião aberta na qual a equipe demonstra o que conseguiu colocar na coluna de Feito. A equipe só deve demonstrar o que satisfaz a Definição de Feito. O que está total e completamente concluído e pode ser entregue sem qualquer trabalho adicional. Pode não ser o produto completo, mas deve ser um atributo concluído do produto.

10 – Retrospectiva do Sprint.
 Depois que a equipe mostrou o que conseguiu fazer no Sprint anterior – aquilo que está “Feito” e pode ser entregue para clientes para obtenção de feedback, eles se reúnem e pensam no que deu certo e o que poderia ter sido melhor, e o que podem melhorar no próximo Sprint. Qual é o aprimoramento no processo que eles, como uma equipe podem implementar de forma imediata?

Para ser eficaz, essa reunião requer certa dose de maturidade emocional e atmosfera de confiança. O importante é lembrar-se sempre de que você não está procurando culpados; está olhando para o processo. Por que aquilo aconteceu assim? Por que você não percebeu aquilo? O que poderia ter acontecido para sermos mais ágeis? É essencial que as pessoas na equipe assumam a responsabilidade pelo processo e seus respectivos resultados, e que busquem soluções como uma equipe. Ao mesmo tempo, elas tem de ter coragem de levantar as questões que realmente as incomodam, de forma que a solução seja orientada, em vez de acusadora. E o restante da equipe precisa ter maturidade para ouvir o feedback, absorvê-lo e procurar uma solução, em vez de assumir uma postura defensiva.

No final da reunião a equipe e o Scrum Master devem chegar a um acordo sobre um aprimoramento no processo que será implementado no Sprint seguinte. Tal aprimoramento no processo às vezes é chamado de Kaizen, e deve ser colocado nas Pendências do próximo Sprint, acompanhado de testes de aceitação. Desse modo, será fácil para a equipe verificar se o aprimoramento realmente foi implementado, e que efeito ele teve sobre a velocidade.

11 – Comece imediatamente o próximo Sprint, considerando a experiência da equipe com os impedimentos e os aprimoramentos no processo.


Vídeo mostrando Scrum na prática em uma empresa




Texto retirado do livro "Scrum - a arte de fazer o dobro de trabalho na metade do tempo"


0 comentários:

Postar um comentário

 

Sobre

Agile Coach, Scrum Master, Eng. de Software com formação em Administração de Empresas em Análise de Sistemas.

Paixão por Software e Administração, foi como unir fogo com gasolina, combustão!

Comecei a programar aos 13 e nunca mais quis parar de respirar software.

Acordo todos dias até hoje com a mesma empolgação de um garoto de 13 anos para criar ou aprender algo novo.
A arte de criar formas de vida virtuais #Tron

Thiago Torricelly

Thiago Torricelly