Nem sempre dedicar o máximo esforço possível a uma determinada tarefa é a melhor coisa a fazer. Muitas vezes, por apenas uma fração deste esforço é possível obter resultados adequados. Isto vale para o esforço despendido em estimativas. Para o autor, a curva precisão da estimativa por esforço é como uma parábola, ou seja, ele argumenta que há uma certa quantidade de esforço até a qual a qualidade das estimativas é crescente. Desta quantidade de esforço em diante, a precisão da estimativa passa a decair. Além disto, mesmo o ponto máximo da parábola não chega a 100% de precisão, talvez nem a 80%.
A ilusão da previsibilidade é uma armadilha para muitos projetos, que visando obter uma estimativa de máxima precisão realiza uma grande quantidade de trabalho up-front e ainda assim as estimativas não são as desejadas.
Uma equipe ágil prefere ficar na metade crescente da parábola, reconhecendo que é impossível eliminar a incerteza e buscando a dose correta onde pequenos esforços trazem grandes resultados (p. ex. a regra 20-80). Mesmo recusando um grande esforço de planejamento, planos ágeis tendem a ser mais confiáveis no decorrer do tempo, pois são norteados por entrega de frequente de pequenos incrementos código completamente funcional, testado e integrado
Equipes ágeis estimam em grupo, por todos os membros, pois normalmente não se sabe a priori quem será responsável pela implementação de nenhuma história em particular. Além disto, a diversidade de opiniões tende a minimizar vícios individuais, tanto de demasiado otimismo quanto de pessimismo.
Nós somos melhores em estimar coisas dentro de 1 ordem de magnitude. Assim, estimativas ágeis são feitas dentro de uma faixa. O autor tem tido sucesso com duas escalas:
- 1, 2, 3, 5 e 8 (fibonacci)
- 1, 2, 4 e 8 (dobro)
Embora ambas funcionem bem, o autor tem ligeira preferência pela primeira. Tomando esta como base, caso uma história seja vista como um pouco maior que outra à qual foi atribuído 5, não há problemas em atribuí-la 5 também. Por outro lado, uma história que mereceria um 7 poderia perfeitamente ser aproximada para 8.
É útil permitir que zero seja um valor válido para estimativas. Como as estimativas são relativas e estamos em uma escala de 8x, definir 1 para histórias minúsculas pode limitar muito o tamanho máximo das histórias. Além disto, se uma história é muito mais próxima de zero que de 1, atribuir 1 poderia trazer ruído ao cálculo da velocidade.
Se a equipe adota zero na escala, é preciso fazer todos na equipe (principalmente o product owner) entender que 15 vezes zero não é igual a zero. Uma história de zero pontos pode ser vista como gratuita, mas 10 delas não. Uma alternativa o uso de zero é definir uma estimativa única para um grupo de histórias minúsculas.
Algumas equipes preferem valores como 10, 20, 30, 50 e 100. Não há problema, pois estão todos na mesma ordem de magnitude. Contudo deve-se estabelecer, assim como com números pequenos, os valores aceitáveis. Não se pode permitir uma história estimada como 66 e outra como 67, pois é um nível de precisão falso, já que não é possível discernir a 1%.
Embora sempre seja preferível estimar histórias cujos tamanhos sejam pequenos, nem sempre isto é possível, pois nem todos os requisitos se apresentam em uma granularidade tão fina. Estimativas iniciais, por exemplo, para requisitos de alto nível que não serão implementados no futuro próximo, por exemplo. Ou quando se está analisando a viabilidade de se implementar um módulo. Para estes casos, é desejável ter uma grande história, que normalmente é chamda de épico.
Além disto, um conjunto de histórias relacionadas pode ser combinada e tratada, para fins de estimativa ou planejamento de release, como um todo. Este conjunto normalmente é chamado de tema.
É necessário sempre ter em mente que estimativas para épicos ou temas sempre terão um grau de incerteza muito maior do que estimativas para histórias comuns.
Histórias que serão abordadas em um futuro próximo (ou seja, nas próximas iterações) precisam ser pequenas o suficiente para caber em uma iteração, devendo ser estimadas com números pequenos (1, 2, 3, 5, 8, por exemplo). Histórias cuja implementação está mais distante podem ser mantidas como épicos. O autor utiliza os valores de 13, 20, 40 e 100 para estes casos.
As técnicas mais comuns (que podem ser usadas isoladamente ou em conjunto) são:
- opinião de especialista
- analogia
- desagregação
Esta abordagem é simplesmente perguntar a alguém que conheça bem o assunto em questão. Isto é mais útil em histórias que não envolvem conhecimentos que não possam ser dominados por uma só pessoa. Embora seja baseada em intuição, há evidências que dizem que este tipo de abordagem costuma ser mais precisa do que abordagens mais analíticas (Phillip Johnson et al., Empirically Guided Software Effort Estimation. IEEE Software, 17(6), pp. 51-56, 2000).
Nesta abordagem, uma história é estimada comparativamente a outras. Uma técnica útil é a triangulação: uma história estimada como 5 deve ser maior que uma estimada como 3 e menor que uma de 8. Há evidências de que estimamos melhor usando comparações do que tamanhos absolutos.
Na desagregação, uma história é dividida em outras menores e mais fáceis de estimar. É mais simples estimar coisas pequenas que grandes. Mais adiante no livro há um capítulo específico sobre como dividir histórias.
Uma das melhores técnicas para estimativas ágeis é o planning poker. Planning poker combina opinião do especialista, analogia e desagregação em uma abordagem agradável que resulta em estimativas rápidas, porém confiáveis.
Todos os desenvolvedores participam do planning poker. Lembrando que por “desenvolvedores” entende-se toda a equipe. Em um projeto ágil, isto normalmente não ultrapassa 10 pessoas. Caso aconteça, é normalmente melhor dividir a equipe em duas, com cada equipe estimando individualmente. O product owner participa do planning poker mas não estima.
No início do planning poker, cada estimador recebe um conjunto de cartas, com cada uma contendo o número de um dos valores válidos para estimativas (por exemplo, 0, 1, 2, 3, 5, 8, 13, 20, 40 e 100). Os cartões devem ser preparados antes do PP e os números devem ser grandes o suficiente para serem vistos por todos quando estiverem sobre a mesa.
Cada história a ser estimada tem sua descrição lida por um moderador. O moderador normalmente é o product owner, embora nada impeça que seja qualquer outro. O product owner responde a qualquer dúvida que os estimadores eventualmente tenham. Contudo, todos são lembrados da curva de esforço por precisão. A meta do PP é chegar a uma estimativa adequada rapidamente.
Após todas as questões serem respondidas, cada estimador seleciona um cartão contendo a sua estimativa. Nenhum cartão escolhido é mostrado até que todos os estimadores tenham terminado. Quando todos terminam, todos os cartões são colocados ao mesmo tempo sobre a mesa para que todos possam ver cada estimativa.
É comum e mesmo desejável que as estimativas sejam bem diferentes, o que levará a que os estimadores das extremidades expliquem suas posições. É importante que o espírito não seja de disputa ou ataques pessoais, mas de aprendizado mútuo.
O grupo tem poucos minutos para discutir, após o que cada estimador reestima com base nos argumentos fornecidos. Novamente, os cartões só são mostrados após todos reestimarem. A maioria das estimativas se resolve no segundo round; raramente alguma ultrapassa o terceiro. A regra geral não é precisão absoluta, mas bom senso.
É importante que as discussões sigam fielmente um timebox. O autor considera que dois minutos seja um tempo razoável e recomenda que seja adquirida uma ampulheta que marque este tempo. Quando o tempo se esgota, um novo round se inicia.
É possível, embora não seja o ideal, que o PP seja feito com um subconjunto dos membros do projeto. Porém, pode ser útil quando há uma grande quantidade de histórias a serem estimadas, o que normalmente acontece no início dos projetos.
Quando isto ocorrer, é importante que os subgrupos não tenham menos de 3 estimadores e que as estimativas sejam consistentes entre os grupos. Uma boa abordagem é estimar de 10 a 20 histórias com a equipe completa e os subgrupos estimarem as restantes a partir daí com base naquelas estimadas pelo grupo completo.
Primeiro, devido a presença da equipe inteira, com pessoas com habilidades diversas. Segundo, porque os estimadores são levados a justificar suas estimativas para o grupo, o que contribui para aumentar a precisão da estimativa, especialmente quando há níveis altos de incerteza. Além disto, PP combina as abordagens individual e coletiva de se realizar estimativas.
Por fim, planning poker funciona porque é divertido.
shoooow