Teoria vs Prática - Mito 4 - Estimativa é um compromisso de entrega
Estimativa, como o nome diz é uma estimativa. E acho que é um dos pontos mais complexos dentro do processo de desenvolvimento. Mesmo times tecnicamente brilhantes muitas vezes erram de forma grosseira as estimativas (seja de pontos, ou de horas). Isso é decorrente de alguns fatores, mas dentre todos, julgo os seguintes, os mais importantes:
De forma geral o desenvolver é um profissional otimista
Entre o que ele acha que sabe, e o que realmente acontece existem muitos detalhes que na hora das estimativas passam ao largo do processo mental dele.
Dependendo da complexidade do software e dos seus casos de uso, entender o que impacta o que é muito mais difícil do que aparenta.
Logicamente existem softwares mais simples onde as estimativas são mais fáceis ou menos difíceis. Mas basta o software ter uma complexidade mediana, e de forma geral as estimativas são muito mais chutes educados e bem intencionados do que qualquer outra coisa.
Esse ponto nos leva a um outro problema muito comum. Dado que é difícil estimar, muitas pessoas acham que basta especificar melhor. Na minha experiência, nunca consegui ver esse raciocínio implementado na prática.
Sempre que eu segui por esse caminho, acabei gastando mais tempo especificando, e o mesmo tempo depois implementando. Ou seja, de nada adiantou. E essa é uma das razões que o Scrum em particular usa um critério abstrato de pontuação.
A pontuação serve basicamente para indicar um grau de complexidade, e nada mais que isso.
Observação: recentemente descobri um "movimento" que prega por simplesmente não estimar nada. Tem vários insights interessantes.
