É muito comum surgir dúvidas e discussões sobre como estimar em metodologias ágeis e apesar da dúvida surgir na adoção de um processo ágil, o problema existe em qualquer ambiente e aparece com muita frequência na forma de atrasos, compromissos não cumpridos, hora-extra, times cansados/estressados e outros recursos para perseguir um cronograma imaginário (mesmo que formalizado).

Há duas formas de mensurar, estimar e medir tarefas que vemos/aprendemos ao nos aprofundarmos em metodologias ágeis, são o famosos Story Points (Pontos ou Pontos de Estória) e Ideal Time (Tempo Ideal).

Definições

Algumas definições importantes de forma rápida e prática:

1. Desenvolvimento de software é um processo empírico e essa declaração traz toda sorte de implicações como incertezas, variáveis externas, mudanças, maturidade, conhecimento e até mesmo erros que devem ser endereçadas no planejamento (incluindo a estimativa), na execução (o processo de desenvolvimento em si), na entrega (e na forma que essa expectativa é gerada e gerida) e até mesmo no ciclo de vida do seu produto/projeto;
2. Velocidade é capacidade de entrega e só é conhecida pela entrega (histórico) que vai levar em conta o ambiente de trabalho, a maturidade da equipe, a estabilidade dos processos e do ambiente, entre outras questões. O principal ponto aqui é entender e aceitar que não existe uma conta de 8h/dia x 10 profissionais x 10 dias úteis x 0,10% do cafézinho = produção de 720 horas de trabalho bem feito;
3. Estimativa é uma E-S-T-I-M-A-T-I-V-A. Há incertezas, há erros e definitivamente não há precisão. O Gráfico de Gantt que fica bonito impresso não serve para muita coisa na parede.

Pontos

São uma medida de complexidade relativa. Não existe uma correlação com tempo cronológico e sim com tamanho e complexidade das tarefas.

Entre suas características podemos citar:

• Exige um bom “baseline” para servir de parâmetro para as definições de ponto. Ou seja, a equipe precisa conhecer bem e de forma uniforme (pessoalmente – não é preciso todos serem iguais) o que considera 1 ponto, 3 pontos (não é multiplicando o item de 1 ponto por 3), etc. Um erro muito comum nesse caso é iniciar-se com uma simples conversão de horas para pontos (ex: 4h = 1 ponto), nesse caso perde-se muito do conceito e dificilmente será possível entrar nos eixos;
• É bem difícil de explicar para o cliente ou fazer uma proposta nesse modelo se o relacionamento com o cliente não é baseado nas premissas ágeis (atualmente é comum adotar SCRUM & cia internamente mas não ter o relacionamento com o cliente nesse modelo);
• Exige alguns ciclos até que se tenha realmente uma relação com capacidade de entrega de forma uniforme e segura;
• Mudanças freqüentes na equipe tem alto impacto no auto-conhecimento e alteram significativamente a capacidade de entrega do time.

Tempo Ideal

Respondendo a pergunta “Quanto tempo, sem interrupções, você levaria para fazer ….” a estimativa resultante é feita em unidades de tempo ideal (geralmente horas).

Apesar de serem horas note que não existe o mundo ideal. Seu time será interrompido, haverá distrações, dias de pouca produtividade e inspiração entre outros fatores que farão uma tarefa de 8hi (hora-ideal) durar 14h cronológicas.

Dito isso, esse modelo ainda é mais fácil de ser adotado com alguma precisão desde o início e a comunicação em tempo ideal é mais fácil com as demais áreas relacionadas.

Considerações finais

Mais importante do que a forma de mensurar, medir ou controlar o desenvolvimento de software é a consistência e a constância dessas atividades, indepentende da abordagem utilizada.

Como algo incerto não existe uma escala certa ou errada. O bom senso nos diz que ao escolher a escala para estimar, seja em horas ideias ou pontos, a ordem de grandeza dos números deve ser diferente (não necessariamente o conceito matemático de ordem de grandeza, podemos ficar só com a idéia) já que o grau de segurança para escolher entre dois números da mesma ordem vai ser igual e não teremos realmente subsídios para escolher entre esses dois números. Por exemplo, uma tarefa pode levar 3hi ou 4hi ? Tanto faz. Agora, ela leva 2hi ou 6hi? Agora sim existe uma diferença.
Da mesma forma a partir de determinado limite qualquer número é válido. A tarefa leva 80hi ou 100hi? Novamente tanto faz, minha margem de erro é tão grande que qualquer um dos dois serve.

Claro que há vários fatores a serem endereçados como planejamento, orçamentação, precificação, dimensionamento de equipe e investimento. Isso tudo fica mais fácil se você não ignorar a natureza empírica do desenvolvimento e o processo criativo humano e lançar mãos de outros meios para respeitar essa natureza como o contrato, por exemplo.