Eventos do Scrum - Introdução e Sprint Planning

Scrum – Eventos essenciais na aplicação do Scrum


Alguns dos componentes mais conhecidos da estrutura do Scrum são o conjunto de eventos sequenciais, cerimônias ou reuniões que as equipes do scrum realizam regularmente. Esses eventos são todos “Time-Boxed”, tem tempo máximo definido. Apenas o Sprint, uma fez definida a sua duração, ela é fixa e não pode ser encurtado e nem alongado, os demais eventos, podem ser encerrados antes, desde que o seu objetivo tenha sido alcançado.

Esses eventos servem para manter os 3 pilares do Scrum, que são a transparência, inspeção e adaptação, não realizar ou realizar somente parte dos eventos, irão prejudicar esses 3 pilares.

Os eventos são:
  • Planejamento da Sprint (Sprint Planning)
  • Sprint
  • Reunião Diária (Daily Scrum)
  • Revisão da Sprint (Sprint Review)
  • Retrospectiva da Sprint (Sprint Retrospective)
Abaixo iremos descrever cada um  desses  os eventos chaves em que uma equipe scrum pode participar:

Planejamento da Sprint (Sprint Planning)


A Sprint começa pelo planejamento, logo o Sprint Planning é o primeiro evento oficial do framework Scrum dentro da Sprint.

Essa reunião é realizada por todo o time Scrum, ou seja, Dono do Produto, Time de Desenvolvimento e Scrum Master, dividida em duas partes iguais, com tempo máximo de 4 horas cada parte (total de 8 horas) para uma Sprint de 30 dias (para sprints menores que 30 dias, normalmente o tempo da reunião é menor proporcionalmente) e aonde são respondidas duas questões chaves:

  1. O que será desenvolvido na Sprint?
  2. Como será desenvolvido?

PARTE 1: “O QUE SERÁ DESENVOLVIDO NA SPRINT”.

Na primeira etapa, o Time de Desenvolvimento avalia as funcionalidades que poderão entrar na Sprint, conforme a prioridade dos itens definida pelo Dono do Produto. Então, o dono do produto poderá detalhar os itens de forma que o time de desenvolvimento possa compreendê-los e o time de desenvolvimento avaliará a complexidade e quantos itens caberão na Sprint.

As entradas para desta parte da reunião são:
  • Os itens de backlog do produto, devidamente priorizados e detalhados no nível maior possível, para que sejam facilmente compreendidos pelo time de desenvolvimento;
  • O último incremento do software em desenvolvimento;
  • A capacidade projetada do time de desenvolvimento (sua produtividade em pontos); e
  • A performance da última Sprint.
O detalhamento dos itens, normalmente é feito em formato de histórias de usuários(user stories), mas poderão ser casos de uso, especificação de requisitos ou simplesmente textos descritivos, cabe aqui a empresa ou o Time Scrum definir a melhor forma de descrever as necessidades do software.

Realizado o alinhamento entre o dono do produto e o time de desenvolvimento, é então definida as estimativas de complexidade para cada item selecionado. Essa complexidade, normalmente medida em pontos, é data pelo Time de Desenvolvimento.A técnica utilizada normalmente é o Planning Poker. 

O ideal é que independente da técnica usada para estimar (pontos de história, por exemplo), que cada tarefa não ocupe um membro do time por mais de um dia. Se isso acontecer, veja como pode quebrar a tarefa grande em tarefas menores.

Outro artefato muito popular, que também não é do Scrum, é o kanban (especialmente usando Trello), um board onde temos colunas com cards, onde em cada card temos uma tarefa a ser realizada, previamente estimada. Cada coluna representa um estágio do ciclo de desenvolvimento de uma tarefa, tais como: TODO (para fazer), DOING (fazendo), Testing (testando) e DONE (pronto).

Após as estimativas, o time de desenvolvimento seleciona os itens que acredita ser possível entregar na Sprint, sempre respeitando a prioridade definida pelo Dono do Produto, sempre tomando o cuidado para não selecionar itens além da capacidade de entrega do time na Sprint.

As saídas desta primeira parte serão:
  • Itens do backlog do produto selecionados para a Sprint;
  • Estimativas dos itens selecionados para a Sprint;
  • Meta da Sprint estabelecida e acordada pelo Time Scrum.

PARTE 2: “O QUE SERÁ DESENVOLVIDO NA SPRINT”.

Terminada a primeira parte, logo em seguida, começa a segunda parte da reunião, aonde a pergunta “Como será desenvolvido” será respondida.

Nesta etapa, o time de desenvolvimento deverá decidir como fará para desenvolver a funcionalidade dentro da definição de “Pronto”, ou seja, quais as tarefas necessárias, para construir os itens do backlog do produto, dentro dos critérios de pronto do projeto, que satisfaças as necessidades ou requisitos descritos nas histórias de usuário.

Serão discutidas todas as tarefas necessárias, como análise, criação de tabelas, design, layout de tela ou relatório, desenvolvimento, testes, tecnologia necessária, bibliotecas que poderão ser utilizadas, etc. Cada item do backlog do produto, serão desmembrados em pequenas tarefas que precisarão ser realizadas pelo time de desenvolvimento e não poderão ser terceirizadas.

Esse desmembramento dos itens de Backlog de Produto em tarefas menores gera o chamado Backlog da Sprint. Essas tarefas devem ser estimadas em horas e não deve exceder 8 horas (trabalho de 1 dia), caso contrário será mais difícil medir a evolução do time na busca da meta da Sprint, já que para medição são consideradas as tarefas completadas, não há percentual concluído da tarefa.

Ao final da reunião, o time de desenvolvimento deve ser capaz de apresentar ao Dono do Produto como será para converter o item do backlog do produto em incremento de software pronto, para enfim dar inicio às atividades da Sprint. No próximo post daremos continuidade sobre os demais eventos do Scrum explicando cada um deles.




Comentários

  1. Muito interessante a postagem.
    Tem alguns detalhes que na prática, pela minha experiência e pelo que ouço falar, são maleáveis e podem ter diferenças bem grandes a depender do projeto. Por exemplo "que cada tarefa não ocupe um membro do time por mais de um dia" a depender do projeto, pode ser que detalhar muito as tarefas demande muito tempo e não valha a pena. E ainda assim algumas tarefas mais complexas podem demorar dias pois exigem um "algorithm design", cálculos e testes mais demorados. Além disso algumas empressas grandes, como a famosa Rockstar Games, utilizam sprints de até 3 meses, com tarefas que podem durar semanas.

    ResponderExcluir

Postar um comentário

Postagens mais visitadas deste blog

Metodologia Ágil - O Manifesto Ágil

Microsoft Solutions Framework (MSF)