Blog

Go Sprint

Ual!!!! Passamos da metade. Yuhu!

Depois de concluir o Passo 5, você deve agora ter seu backlog de produtos em ordem , backlog estimado,  planejado o seu sprint,  estórias quebradas em tarefas, e agora temos um ambiente criativo.

O Scrum é uma prática de gerenciamento ágil e não abrange realmente a engenharia ágil.

O XP (Extreme Programming), por outro lado, é uma prática de engenharia ágil.

Seja o que for, no Scrum, e eu volto a afirmar que o SCRUM não deve ser utlizado apenas para uma abordagem de desenvolvimento.

E é por isso que o Scrum funcionou e funciona, mesmo fora de um contexto de desenvolvimento.

Mas voltando a nossa Sprints, é hora de executarmos as tarefas com o intuito de atingir o objetivo Sprint que eles comprometeu durante as etapas de planejamento.

Baseando nos princípios das equipes ágeis, temos algumas características a serem levadas em questão. A equipe Scrum deve sempre tomar suas próprias decisões durante o Sprint.

A equipe é totalmente habilitada para isto.

Se você for ScrumMaster, a equipe deve receber apoio, orientação, treinamento e assistência.

Lembre-se a equipe deve ser ajudada a alcançar suas próprias decisões.

A facilitação torna-se uma habilidade chave para scrum master, agile choach e gerentes ágeis.

Usando sua experiência e responsabilidade de gerenciamento para ajudar a equipe a fazer seu trabalho.

A gestão ágil requer liderança inspiradora.

A equipe se auto-organiza para alcançar seus objetivos. Mas a auto-organização não pode ser sem limites.

Lembre-se:

O tempo perdido, não volta!

Se você terminar cedo, inclua mais estorias no escopo, ou seja, a próxima coisa mais importante do Product Backlog.

Se você vai atrasar, você deve reduzir o escopo para atingir o prazo.

E observação muito, mas muito importante.

Feito é feito!

Para alcançar um tempo de Sprint fixo, seja 30 dias como diz o Scrum, ou 15 , é necessário garantir que você complete um item do backlog da sprint por vez antes de passar para o próximo.

Afinal é muito mais vantajoso chegar no final com 100% de algo entregue do que 80% de avanço no todo.

É preciso testar!

O teste deve estar integrado ao longo do ciclo de vida do que esta sendo criado.

Porque? Porque quando alcançamos a integridade para garantir que o que esta feito realmente esteja integro, antes de passarmos ao próximo item. E

quando os testes iniciam?  Lembra? Eles devem iniciar no Sprint Planning, pois neste momento envolvemos os testadores no início.

Mudanças constantes nas prioridades impedem que uma equipe de desenvolvimento seja totalmente produtiva e, na pior das hipóteses, pode impedir que uma equipe de desenvolvimento entregue. Se as prioridades devem ser alteradas durante um Sprint. No entanto, um trabalho equivalente deve ser removido do Sprint para compensar.

 

E se for preciso abortar? O sprint não faz mais sentido?

 

É importante considerar que abortar um Sprint é algo muito sério e deve ser reservado para circunstâncias excepcionalmente raras.

Digamos que a Meta do Sprint não é mais aplicável.

Ou o Sprint ou o projeto está tão longe do controle que realmente garante uma re-análise completa.

Estes são os tipos de eventos quando você deve considerar abortar um Sprint.

Cancelar um Sprint significa literalmente abandoná-lo e voltar ao Planejamento Sprint para reavaliar as prioridades e re-planejar.

 

Preparado para o próximo passo?

2 Comments

0

Post A Comment