Artigos

Alguns pontos sobre estimativas

vidente-recorte

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).

2 Comentários

  • rildosantos

    Gostei, belo post, o tema gera discussão, mas você abordou, muito bem, parabéns!
    Só alguns detalhes, 1- Story Point não faz parte do Scrum; 2 – Ser humano precisa de previsibilidade de tempo, para resolver isso fazemos as estimativas, mesmo sabendo que ela é falha, mas vale como uma referência.
    3 – Concordo contigo quando escreve que não existe receita de bolo e quando diz que trabalhar sem estimativa é para equipe experiente.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *