Em um post recente do seu blog, Martin Fowler questiona o propósito das estimativas em software. O propósito das estimativas é resumido no seguinte cenário:
Digamos que uma estimativa seja solicitada aos desenvolvedores para um determinado trabalho. Esses desenvolvedores, que são naturalmente otimistas, tendem a estimar para baixo. Isso acontece mesmo que não sofram, pelo menos explicitamente, pressão para reduzir suas estimativas. Em seguida, as tarefas estimadas se tornam planos de desenvolvimento, monitoradas por um gráfico de burn-down.
Fowler lembra o gasto de tempo e esforço para monitorar o progresso do desenvolvimento com relação ao plano inicial, e que todos se frustram quando o trabalho realizado é maior que o estimado. E em muitas situações, para adequar o ritmo do desenvolvimento às estimativas, a qualidade é sacrificada deixando as coisas ainda piores.
Fowler aponta dois efeitos colaterais das estimativas: devoção a funcionalidades e geração de expectativas. A devoção a funcionalidades ocorre quando a equipe de desenvolvimento começa a valorizar mais a conclusão de tarefas do que a entrega de valor real ao cliente. E a divulgação de estimativas tem como subproduto a geração de expectativas no cliente. Além disso, existe o risco das estimativas serem inferiores ao trabalho real e, qualquer que seja o aumento do tempo ou redução escopo, acarretará frustração ao cliente.
Esse ciclo vicioso de estimar, falhar e sacrificar a qualidade, segundo Fowler, produz em alguns agilistas a visão de que estimativas são nocivas, e que parte da comunidade ágil acredita que um profissional que realiza estimativas não é verdadeiramente ágil.
Embora Fowler apresente em seu texto cenários em que a estimativa é benéfica ao projeto e, em muitos casos, excelentes ferramentas de apoio a decisões, é importante também realizar uma análise ampla e apontar questionamentos às estimativas, especialmente em projetos de software.
No trabalho Limites amplos na estimativa de software de J.P. Lewis, é apresentado um modelo matemático que prova que é impossível medir software com precisão. Resumidamente, a proposta do autor é baseada na ideia de que especificações são compostas de strings arbitrárias. O artigo demonstra que é impossível o cálculo de complexidade de um algoritmo que gere strings arbitrárias. Com base nessa premissa, o autor conclui que, a partir de uma especificação, não é possível medir o tamanho de um software, sem que seja admitido certa imprecisão; ou seja, não existe estimativa de software 100% precisa.
No artigo Uma revisão das pesquisas em estimativas de esforço em software (Kjetil Moløkken and Magne Jørgensen), foi realizado o estudo de técnicas de estimativas de software, e os autores apresentaram conclusões interessantes:
A maioria dos projetos apresenta problemas de estimativas de esforço ou prazo..., mas o tamanho desses problemas é menor do que apresentado por algumas consultorias. O método de estimativas mais utilizado é o sentimento ou instinto de especialistas. Isto é resultado da falta de evidências formais provando que modelos de estimativas geram estimativas mais precisas.
Embora dignos de atenção, esses fatos não invalidam necessariamente o processo de estimativa de software. Voltando ao texto do Fowler, são apresentados alguns cenários em que a estimativa é útil e muitas vezes valiosa. Exemplos dessa aplicação seriam cenários de tomada de decisões e esclarecimento de requisitos durante as reuniões de estimativas.
Siobhan Keaveney e Kieran Conboy, no artigo Custo de estimativas no desenvolvimento de projetos ágeis, demonstram que quanto menores as iterações (tanto em escopo quanto em tempo), maior será a precisão das estimativas de um projeto.
Através da análise de quatro projetos, os autores afirmam que estimativas em iterações curtas, são mais produtivas e eficientes do que estimativas de longo prazo. No trabalho, os autores ainda recomendam projetos com orçamento fixo, na qual a variação ocorre ou em escopo ou em prazo. O autor ainda segue com algumas recomendações:
- Modelos ou metodologias de estimativas não são pré-requisitos do processo de estimativa;
- Preço fixo é a melhor opção para desenvolvedores e consumidores;
- Os fatores determinantes à precisão de uma estimativa são: a experiência do profissional que realizará a estimativa do projeto e a existência de dados relativos a projetos semelhantes executados anteriormente na empresa.
Fowler afirma que estimativas não devem ser classificadas nem como benéficas nem como nocivas ao software, pois são fortemente dependentes do contexto aplicado. Contudo, deve-se ter em mente que quanto menor o escopo estimado e maior a experiência do profissional que irá estimar, maiores são as chances dessa estimativa se transformar em realidade dos projetos.
E você? Qual a sua experiência com o sucesso de estimativas? Em quais cenários acredita que estimativas são benéficas? E em quais contextos seriam nocivas?