Ao escrever minha monografia sobre técnicas de estimativas de software ágeis e “tradicionais”, comecei achando que conseguiria definir o melhor método de todos, pelo menos para determinados casos.

Entretanto, após orientação e pesquisa, enquanto escrevia sobre o assunto, acabei chegando a uma das “piores” e óbvias conclusões: isso é impossível.

O motivo é simples (pelo menos após a devida reflexão): o software é abstrato, complexo, mutante e intangível.

O que isso significa? Resumindo:

  • Você não pode medir objetivamente um software;
  • Você não pode simplificar (abstrair) um software sem perda de informação;
  • Você não pode definir estaticamente um software.

Anteriormente, pensava que as já conhecidas métricas de software eram confiáveis. Mas quem pode medir o tamanho de um software? Linhas de código realmente refletem o “tamanho” do sistema? Como afirmar que um sistema é mais confiável que outro? Ou, como medir a usabilidade?

A verdade é que, dado um mesmo requisito, há uma implementação para cada programador que já viveu, que vive e que surgirá na terra!

Um autor afirmou que os requisitos de software mudam, em média, 25% desde que os requisitos foram levantados até a primeira versão. O software é mutante! Não que ele tenha caído num tambor de lixo tóxico ou teve seu DNA alterado por radiação, mas porque os negócios e suas necessidades mudam.

Infelizmente, estimativas de software sofrem do mesmo mal. É impossível afirmar categoricamente que uma determinada estimativa é melhor que qualquer outra.

No fim, como tudo que envolve software, o que conta é o talento das pessoas envolvidas. Algumas pessoas estimam melhor que outras, mas não são o estudo, a experiência e o método científico que tornam isso possível. É simplesmente algum tipo de intuição subjetiva, que pode ser melhor ou pior aproveitada ao se utilizar uma determinada técnica.

Estimar é simplesmente “chutar”. É um erro acreditar que qualquer estimativa é um número matemático que você pode jogar numa fórmula e obter um resultado qualquer, por mais tentador que isso pareça. Fazemos por necessidade, mas isso consiste apenas como um chute em cima de outros.

Se você estivesse indo apostar que seu time ganharia de dois a zero contra outro e, no meio do caminho, lesse uma matéria no jornal que algumas contratações deixaram seu time duas vezes melhor, você aumentaria a aposta para quatro a zero?

O único meio de fazer comparações significativas e objetivas entre softwares, estimativas e técnicas de estimativa é utilizando critérios específicos.

Por exemplo, o software S1 pode processar uma quantidade Q de informação num tempo T, enquanto S2 processa Q em T+1. Especificamente no quesito eficiência, S1 é superior a S2, mas essa informação não agrega nada nos demais aspectos de um sistema de software.

Da mesma forma, uma determinada estimativa pode se mostrar melhor que outra por se aproximar mais da realidade concretizada, mas isso em nada prova que ela é superior, pois existem fatores demasiadamente complexos para que alguém possa fazer tal afirmação.

Quanto às técnicas de estimativa, escreverei em breve.

Conclusão

Estimativas são… estimativas.

É errado pensar em estimativas como medidas numéricas absolutas.

É errado considerar estimativas como a palavra final para o planejamento e o cronograma.

É errado acreditar que quanto mais detalhadas as estimativas melhor ou mesmo que é possível garantir uma determinada precisão.

McConnell, em seu livro “Estimativas de Software: Desmistificando a Magia Negra” (Software Estimation: Demystifying the Black Art) afirma que é preciso definir e diferenciar conceitos, tais como:

  • Estimativas são estimativas, não um compromisso;
  • Compromisso é quando a equipe se dispõe a cumprir um determinado cronograma;
  • Cronograma é o planejamento no tempo, o qual pode ou não ser baseado em estimativas.

Nota: repare no título sugestivo do livro de McConnell. Estimar não é quase como tentar prever o futuro?