Blog

Planejar seu Sprint.

Se você seguiu as duas primeiras etapas desta série, você deve agora ter seu backlog de produtos em ordem de prioridade e backlog estimado em tamanho usando os pontos de Fibonacci.

 

O próximo passo – O Passo 3 é Planejar seu Sprint.

 

Checklist

 

 

 

Agende uma reunião de Planejamento Sprint.

Certifique-se que esta data da reunião atenda a equipe.

Crie a recorrência dos eventos para Planejamento a cada 1 ou 2 semanas.

Inclua todos os papéis.

Analistas de negócios

Testadores

Desenvolvedores.

Proprietário do produto.

 

A primeira coisa que você deve fazer (na sua primeira reunião de Planejamento Sprint) é decidir sobre a duração do Sprint.

Essa decisão deve ser tomada como uma equipe.

Decida sua duração de Sprint

Esta é uma decisão importante.

Scrum sugere 30 dias. E ele pode estar certo para times maduros.

Mas esse é um ponto que parece ser amplamente adaptado por equipes ágeis que praticam Scrum.

A duração ideal de Sprint depende de muitos fatores. Algo que li recentemente sugeriu que o “tempo de ciclo” de uma equipe de desenvolvimento é um reflexo direto da maturidade de seus processos.

Eu concordo plenamente com essa afirmação.

 

Uma equipe com processos imaturos encontrará a intensidade do Scrum e a sobrecarga do Sprint Planning, Testing, Deployment e Review bastante onerosos para um curto ciclo de Sprint.

Enquanto equipes com processos maduros (por exemplo, testes automatizados, implantação automatizada), um ciclo curto pode ser muito confortável.

Sugiro que o intervalo seja entre 1 semana e 2 semanas até 1 mês. 1 semana é provavelmente o mais curto e que nunca será tão prático, os times tendem a gostar de 2 semanas.

Para produtos ou mercados de movimento rápido, como utilização de machine learning, que são critérios avaliados evolução em tempo curtos, 1 mês pode parece ser uma vida inteira!

Pessoalmente, eu gosto de Sprints de 2 semanas para produtos em movimento rápido.

 

Mantenha a duração do Sprint consistente

 

Seja qual for a duração de Sprint que você escolhe, o meu conselho é mantenha os ritmos.

Isso, de fato, é mais importante do que o próprio comprimento.

Quando falamos de consistência, falamos de ritmo. É essa consistência que torna seu processo repetido ser aprendido.

E, portanto, você ajuda os ajustes necessários a cada passo como uma equipe. E é essa consistência que permite que você comece a entender quantos pontos de Backlog do Produto você pode normalmente fazer em um Sprint.

 

Defina a META de Backlog para Sprint

 

Agora você decidiu sua duração no Sprint. Em seguida, você deve decidir sobre o objetivo do Sprint .

Como eu sei que o que foi entregue é entregue?

 

Olhando para a seção superior do Backlog do produto, o que parece ser um objetivo razoável para definir o Sprint?

Você pode expressar um objetivo que resume o objetivo do próximo Sprint ou, pelo menos, escolher uma seção de itens / recursos do topo do Backlog de produtos que a equipe pensa que pode ser alcançado na duração do Sprint?

Selecione do seu backlog o destino para o Sprint.

Faça essa decisão como uma equipe.

 

Inclua um pouco mais do que você acha que pode ser alcançado. É importante preparar mais itens durante o planejamento, caso a equipe termine cedo.

Esses itens podem ser claramente identificados como tarefas de “ajustes de direção” e o Proprietário do Produto não deve esperar que sejam completadas.

Estas são as coisas que você fará apenas se o Sprint for melhor do que o esperado.

No futuro, não tão longe e você verá.

Você poderá usar a velocidade anterior da equipe Scrum para ajudar com essa decisão. A velocidade é o número de Pontos de Backlog de Produtos entregues em um Sprint.

Isso tende a flutuar relativamente cedo quando adotar o Scrum.

Mas vai se estabelecer à medida que a equipe entra em um ritmo e, no futuro, fornecer-lhe uma norma razoável para basear o seu atraso no alvo.

 

Esclareça os requisitos da Sprint

 

Pegue cada item no Product Backlog.

É importante passar por eles metodicamente, um item por vez …

O Proprietário do Produto apresenta cada item e explica como ele o vê a partir de uma perspectiva funcional.

Toda a equipe discute o item em detalhes. Toda a equipe faz perguntas sobre o item do backlog, a fim de estabelecer o que deve fazer e como deve funcionar.

Os resultados desta discussão devem ser capturados em um quadro branco ou flipchart, ou alguém pode escrever notas em um laptop à medida que a discussão avança. Os quadros interativos ou imprimíveis são ideais para este processo.

Você pode usar qualquer forma de requisitos de escrita que você deseja. Mas o princípio importante no Scrum, e em qualquer metodologia de desenvolvimento ágil, é que você escreve  requisitos por item, imediatamente antes de serem desenvolvidos.

 

Escreva os requisitos de forma leve e visual.

Os requisitos ágeis podem ser pouco, leve mas suficientes. O fato de os recursos serem desenvolvidos e testados já nas próximas semanas, e pelo time que esteve presente, torna isso possível.

Considere escrever ‘Histórias do usuário’, um conceito utilizado do  XP (eXtreme Programming). Está além do escopo deste artigo para explicar as histórias dos usuários em qualquer detalhe. Mas o conceito básico pode ser escrever estorias usando esta construção:

 

COMO?

Assim,

 

Como um [tipo de usuário], eu quero [fazer o que for], para que eu possa [alcançar o objetivo].

 

A história pode ser apoiada por um esboço da UI, um wireframe ou visual.

Anotações para descrever a funcionalidade, são sempre bem vindas. Apoiado com declarações sobre como será confirmado (ou testado).

Isso ajudará a identificar cenários de aceitação/regras necessárias, antes que ele seja desenvolvido.

 

 

Uma vez que você tenha esclarecido os requisitos para todos os itens do Backlog do produto separados para o seu Sprint, o próximo passo é o

Passo 4: Criar as tarefas do planejamento / estimativa do Sprint …

6 Comments

0

Post A Comment