venho tentando dar precisão não nas estimativas, mas na capacidade de produção realista suportada em uma sprint. Explicando melhor, utilizo variaveis que me darão a dimensão de horas/pontos possiveis dentro do sprint. Dentre as variaveis, são abordados: HH semanal; Time Box; Tamanho da sprint (2,3 ou 4 semanas); numero de desenvolvedores; porcentagem de reprovação no teste(estimada); tempo de correção das tarefas que retornaram do teste(estimada); e tempo de teste sobre tarefa(estimada). Abaixo um exemplo:

- Horas /Homem Semanal (HS)
- Número de Desenvolvedores (ND)
- Número de Testadores (NT)
- Time Box (TB) – 2,3 ou 4 (Semanas)
- Porcentagem de Retorno do Teste (PRT) = % de tarefas que não passam no teste durante um Sprint
- Tempo Estimado do Teste/ Tarefa (TET) = %ET: Tempo em relação a tarefa destinado ao teste (exemplo: se uma tarefa possui um tempo estimado em 10 horas, e o TET é 150% logo o TET em relação a tarefa é 15 horas)
- Tempo de Correção das Tarefas (TCT) = %ET: Tempo em relação a tarefa destinado ao correção (exemplo: se uma tarefa possui um tempo estimado em 10 horas, e o TCT é 40% logo o TCT em relação a tarefa é 4 horas)
- Impacto dos Riscos (RI) = Porcentagem do impacto dos impedimentos sobre a produção.

Para se saber a capacidade realista de produção utilizo a seguinte formula:

Capacidade Realista de Produção do Desenvolvimento (RPD) = (MPD*(1-RI)) / (1+PRT*TCT)

Com isso, eu posso mensurar o tamanho real da sprint (a capacidade de produção). Daí cabe a equipe estimar o quanto de estória vai caber nesse espaço (RPD). Adianto que estamos tendo resultados muito próximo do previsto.

Sei que ficou um pouco complicado de entender, nao eh uma fórmula convencional e talvez precisasse de uma maior explanação. Mas funciona! rsrs!

Exatamente, não temos bolinha de cristal, certo? Então, nesse caso a velocidade será menor ao terminar o Sprint, e não há nada, absolutamente que possamos fazer neste caso.

“A velocidade que estimamos era 38, mas por conta do atropelamento do gato da Marecilda, e sua ausência nos 3 últimos dias prejudicou e fizemos só 32 pontos… Agora que o Fulcherbison (o nome do gato) se recuperou e a Mare está de volta podemos estimar novamente em 38?”

Primeiramente parabéns pelo problema levantado, acredito que a estimativa é a maior culpada de todos os sucessos e insucessos de qualquer produto, sem dúvida.
Mas tem um ponto que ainda fico em dúvida, e isso eu não sei se não entendi direito ou se minha dúvida faz sentido.
Mas quando você fala que baseado em pontos de um Sprint Backlog anterior, nós podemos estimar o atual, e descontar pontos para os possíveis problemas, estamos falando de algo previsível no momento da estimativa do Sprint Backlog, como por exemplo, viagens, treinamentos e etc. E para os casos imprevisíveis? Como por exemplo caso de saúde e etc? Vc concorda que não tem como saber isso no momento do Sprint Backlog?

Abraços.

Estimativa de software é uma das coisas mais incertas que existem, é muito dificil estimar alguma funcionalidade, correção etc, e isso varia muito de desenvolvedor para desenvolvedor, no final das contas a experiência de cada um conta muito.

Sem falar que já é muito dificil medir a produtividade de um time inteiro de desenvolvedores, imagine medir a produtividade de um membro da equipe.

Como você disse, é algo realmente empirico.

Enfim, excelente post, parabéns.

Pois é! Porém, o -49% é que a equipe relaxa!! he he he

@Marcelo

Cara, pensei umas 20 vezes antes de aprovar esse teu comentário. Curintianos, retaliações aqui no blog não serão toleradas.

Ótimo post!!!
Parabéns!

Diretor está de férias +49%

[]s