Há pouco tempo, Buddha Buck perguntou na lista de Extreme Programming se existe uma média de velocidade que poderia ser considerada 'boa' para uma equipe de sete pessoas que realiza iterações de duas semanas. Ele sentiu que uma velocidade de oito para baixo indicaria que as estórias estariam muito grandes. A discussão em torno do tema conseguiu responder a essa e a outras questões decorrentes também.
A velocidade é usada como uma ferramenta para predizer a produtividade futura da equipe. Se todas as estórias que a equipe trabalhou forem do mesmo tamanho, no que diz respeito à quantidade de trabalho necessário para implementá-las, então poderíamos apenas contar o número de estórias que a equipe completou por iteração. Uma determinada equipe provavelmente terminaria o mesmo número dessas "histórias do mesmo tamanho" a cada iteração, e a gerência poderia fazer planos conforme a capacidade conhecida dessa equipe.
Em muitos ambientes, as estórias não são todas do mesmo tamanho. Entretanto, as estórias recebem tamanhos relativos, frequentemente chamados de estimativas. Uma estória de tamanho dois tem o dobro do tamanho de uma estória de tamanho um. Uma estória de tamanho três, tem o triplo do tamanho, e assim por diante. É razoável esperar que as estórias de tamanho dois, em média, demorem o dobro do tempo para serem completadas, em relação às estórias de tamanho um. Para faciliar essas estimativas, os tamanhos são medidos em uma unidade chamada 'pontos' ou 'story points'. Assim, podemos dizer que uma estória de cinco pontos provavelmente vai demorar cinco vezes mais que uma estória de um ponto. Na média, uma equipe estará propensa a terminar o mesmo número de pontos de esforço de trabalho em cada iteração; este número é a velocidade da equipe. Desta forma, a velocidade é a capacidade de realização da equipe. Ela mede a quantidade de trabalho uma equipe consegue produzir em cada iteração.
Steven E. Newtondiz que "Uma boa velocidade é aquela que consegue dar uma noção clara de quanto trabalho você terá pronto nas iterações seguintes."
Kent Beck apontou outro benefício de saber a velocidade da equipe:
Outra finalidade de medir a capacidade é melhorar a vazão de entrega. Se você planeja entregar menos do que pode, terá menos do que sua equipe conseguiria. Se você planejar além, também terá menos do que realmente poderia entregar.
Charlie Poole lembrou aos participantes que os desenvolvedores tendem a pensar na quantidade de trabalho que será necessária para implementar as estórias, enquanto os gerentes e clientes pensam na quantidade de valor que está sendo entregue quando as estórias estiverem terminadas. É importante notar que a estimativa da estória e a velocidade estão relacionadas com a quantidade de trabalho existente e o tempo necessário para completá-lo.
O aspecto mais básico da pergunta de Buddha foi respondido, mas a discussão continuou examinando alguns dos problemas mas comuns nessa questão. Em particular, Buddha concluiu que as estórias de sua equipe estavam grandes demais. Os participantes desse tema confirmaram que estórias menores são preferíveis às maiores.
Tim Ottinger comentou que estórias menores fornecem pontos de checagem mais frequentes e ajudam a equipe e aos patrocinadores a saberem a quantidade de trabalho já realizada em determinado momento.
Obviamente nenhuma estória deveria ser maior do que uma iteração. A maior estória da iteração corre um grande risco de não ser terminada. Você não quer se ver em uma situação onde você tem N pontos ou 0 pontos. Seria bom se você tivesse 40% dos pontos terminados no meio da iteração.
Steven Gordon também compartilhou algumas dicas.
- Se você não tem certeza de que as estórias são mesmo pequenas, então provavelmente elas são muito grandes.
- Se as estórias forem pequenas demais, a equipe vai notar que a sobrecarga de acompanhá-las parece um desperdício.
- Os problemas decorrentes de estórias muito pequenas são menores do que os decorrentes das estórias muito grandes. Dessa forma, errar para menos é melhor do que para mais.
- Se estórias muito pequenas são o maior impedimento que uma equipe tem, comemorem juntos. Vocês são mestres em XP.
Ron Jeffries disse que ele gosta de ver as estórias de um tamanho, tal que uma dupla de programadores possa terminá-las em uma semana. Ele foi menos apaixonado com o conceito de pontos:
Eu acho que os pontos são uma bobagem e eu me arrependo de tê-los recomendado com tanta ênfase. Ele faz com que você se distraia do mais importante, que é quebrar as estórias até que elas sejam pequenas e possam ser feitas praticamente num ritmo constante.
Como sua equipe decide o tamanho que as estórias terão? Você usa a velocidade da equipe como um indicador de tamanho? Deixe um comentário e compartilhe seu pensamento.