Alguns pontos sobre estimativas

Falar sobre estimativas sempre gera polêmica. Já há algum tempo uma hashtag no twitter vem causado burburinho. #noEstimates vai além do não uso de estimativas, mas sim de se trabalhar com uma deadline com qualidade. Dizer que não é possível estimar software pode parecer radical demais. O fato é que uma hora ou outra precisaremos estimar. Mas devemos ter plena consciência de que estimativas são chutes e algumas vezes, grosseiros. Então existe sim, uma deficiência no uso de estimativas em software.

Mais uma vez, tenho que pôr a culpa no scrum que nos fornece os benditos Story Points (veio do XP, mas o Scrum popularizou), uma unidade de medida obscura e que muitos não entendem direito pra que serve.

Chegou o momento de começarmos a nos questionar sobre isso. Medir velocidade não faz sentido.

Abaixo defini alguns pontos com base no que venho lendo sobre #noEstimates e na minha própria experiência trabalhando com estimativas:

• Backlogs pré-definidos de trabalho inibem a criatividade e dificultam ao time realizar ajustes no projeto.
• Estimativa é chute. Sempre será.
• Trabalhar sem estimativas é algo para equipes mais experientes.
• Pessoas de negócio e desenvolvedores devem trabalhar juntos para alinhar a visão do produto.
• Os únicos que estipulam prazos é negócios (analistas e clientes).
• Temos uma visão de que quem define escopo é negócios. Quem deve definir escopo é negócios juntamente com desenvolvedores. Pois desenvolvedores e negócios irão descobrir juntos o que de mais importante poderá ser entregue no prazo estipulado.
• Quem define o prazo é negócios.
• Estimar estórias de usuário com pontos não vai influenciar na entrega de valor. O time só irá perder tempo criando reuniões de planning desnecessárias.
• Estimar usando pontos faz com que o time se foque em quantidade e não em qualidade. 
• Impossível saber, antecipadamente, quanto um produto irá custar e quanto tempo irá levar para se construí-lo. Infelizmente o sobrenatural não existe.
• Se desenvolvedores fizessem somente cruds, story points seriam eficazes como medidas de desempenho.
• Quanto maior forem os riscos relacionados a entrega, mais o time irá adicionar gordura e ineficiência na estimativa.
• Um irônico conceito de administração, conhecido como Lei de Hofstadter, diz que as tarefas sempre levam mais tempo do que o previsto para serem executadas, mesmo que se conceda uma margem de segurança.
• O cliente geralmente não sabe como vai ser o produto final. 
• Não faz sentido planejar sprint. É muito melhor medir o final da iteração. É melhor começar a trabalhar logo a perder tempo estimando. Sprints são do mal. Ao invés de sprints, foque em releases.
• A única maneira de saber quanto um produto irá custar e quanto tempo irá levar para construí-lo é construindo-o.
• Criar um MVP pode ajudar a entender melhor o projeto e a ganhar a confiança do cliente. Além de que é muito mais fácil estimar uma entrega pequena.
• Não se deve entregar o que o cliente quer, mas sim o que ele precisa.
• Estimar o longo prazo vai contra a agilidade. Restringe a capacidade do cliente de solicitar mudanças.
• Se o cliente não entender a natureza imprevisível, criativa e inovadora de uma solução de software, o demita ou ele irá gerar muita dor de cabeça.
• Qualidade não é negociável. Se o prazo comprometer a qualidade, ignore o prazo.
• Negocie um contrato no qual o cliente possa se retirar cedo, seja por satisfação ou insatisfação.
• Software funcionando é uma medida de progresso. Pode-se tomar decisões com base em medidas de progresso de entregas anteriores.
• Prefira contratos de escopo negociável.

Essa discussão vai longe. E não existe receita pra nada. E o que funciona com um cliente pode não funcionar bem com outro. Devemos fazer experimentos e verificar qual método melhor se encaixa para nosso time e não seguir nada sem questionar, mesmo que um grande guru tenha dito em uma palestra ou escrito em um livro. Como disse Neil Degrasse Tyson: Questione a autoridade. Nenhuma ideia é necessariamente verdadeira só porque alguém disse (inclusive eu).