Este conto será dedicado a como não cair na armadilha do controle imaginário sobre o processo de estimativa de tarefas para o próximo sprint. Devo dizer imediatamente que os dados apresentados abaixo são apenas indicativos e os comentários sobre a não utilização dos números de Fibonacci com o objetivo de estimar aqui serão supérfluos.
Nossa equipe era formada por analistas, testadores, designers e 2 desenvolvedores; no entanto, para maior clareza, deixamos apenas os desenvolvedores.
Iniciamos um novo sprint e prosseguimos sem problemas para a avaliação de histórias de usuários. Nada de novo. Vá em frente ...
O planejamento está concluído e os resultados podem ser vistos acima. Eles usaram três histórias de usuários avaliadas em 16, 20 e 37 pontos de história, respectivamente. Total - 73.
Além disso, como qualquer equipe de desenvolvimento que se preze que adora todas as delícias de trabalhar no Scrum, adicionamos essas classificações ao Jira. Ao mesmo tempo, apresentamos apenas estimativas gerais (ou médias - até piores!) Para cada história.
Duas semanas de trabalho sem tirar as mãos do teclado e sem se levantar da cadeira de escritório que é tão amada há anos, você pode contemplar a funcionalidade recém-criada.
Mas qual é o problema? O sprint terminou e vemos que a frente fez tudo como planejado e não teria tempo de pressionar mais as teclas, e as costas foram além do sprint e realizaram mais tarefas do que o planejado.
E então Scrum e XP, do PM Trenches, que acabou de ler, aparece e diz: “Tudo está claro !!! É necessário levar mais pontos de arremesso para o próximo sprint e então tudo ficará bem e nenhum apoio fugirá de mim, levando o escopo comigo !! ”
Estamos planejando um novo sprint ....
Ótimo! Tomou 10 storipoints mais !!! Agora calculamos tudo com certeza!
Outras 2 semanas voam rapidamente e é hora de fazer um balanço.
Mas, para pesar de todos, o sprint terminou de uma maneira completamente diferente da que gostaríamos.
Por alguma razão, as costas voltaram à frente e a frente não teve tempo para fazer o que planejava (a possibilidade de que a frente seja apenas um junho inexperiente, e reduziremos o senador intocável nas costas e imaginaremos que tudo está apenas no planejamento errado).
Outro sprint foi um fracasso !!! Mas por que nós pegamos um pouco mais de histórias e isso, apenas para bons propósitos - para fornecer a quantidade necessária de trabalho para o servidor ??!?
Como isso pode ser ?? A resposta é toda sobre o próprio sistema de avaliação. De volta aos nossos sprints.
O que nós vemos? Acontece que, tendo mais pontos de arrecadação no novo sprint para carregar as costas, acabamos de carregar a frente.
Tendo entendido isso, o primeiro pensamento na cabeça maluca de PM é descobrir quantos pontos da história a frente assumiu e quanto apoio. Mas olhar para a nota geral em Jira simplesmente não é possível, porque tudo o que você pode descobrir é a nota geral (boa ou média) de cada história e lembre-se de quem atribui qual nota não é mais possível.
E então a solução vem por si só. Para regular com sucesso a carga da equipe, é necessário manter não apenas um registro geral nos pontos históricos, mas também um registro separado no contexto da carga na frente e nas costas. Isso permitirá que você descubra a quantidade ideal de trabalho para cada área e conte com ela para preencher o backlog do sprint. Até o momento, essa abordagem não pode ser implementada no Jira sem notas separadas no MS Excel, mas isso não significa que não deva ser usada.
Estou certo de que os desenvolvedores do Atlassian encontrarão uma solução para esse problema, mas, por enquanto, apenas não repitam nossos erros!
PS Essas conclusões são aplicáveis apenas ao desenvolvimento de aplicativos cliente-servidor, onde há uma clara separação de trabalho no front e no back-end. Esse problema não deve surgir na equipe de desenvolvedores do Full-Stack, que avaliam imediatamente o trabalho em duas direções.