Um dos aspectos mais desafiadores de qualquer projeto de software é a estimativa – determinar quanto tempo o trabalho levará. É tão difícil que alguns a chamam de arte negra. É por isso que recomendo fortemente o livro de McConnell, Software Estimation: Demystifying the Black Art; é o trabalho definitivo sobre o assunto. Qualquer pessoa que esteja executando um projeto de software deve ter uma cópia. Se o senhor acha que não tem precisa deste livro, aceite o desafio da estimativa: o senhor é um bom avaliador?
Como o senhor se saiu? Se o senhor for como o resto de nós, o senhor não presta. Em estimativas, quero dizer.
Dada a incerteza e a variabilidade do planejamento, é totalmente apropriado que haja um jogo circulando nos círculos de desenvolvimento ágil chamado Pôquer de planejamento.
Há até mesmo cartões para issoo que, na prática, dá uma sensação muito mais parecida com a do pôquer. E, como no pôquer, as apostas no desenvolvimento de software são de dinheiro real, embora geralmente estejamos jogando com o dinheiro de outra pessoa. Se o senhor tiver uma equipe distribuída, os jogos de cartas podem parecer uma piada cruel. Mas há uma maneira muito bacana de jogar cartas. implementação baseada na Web do Planning Pokertambém.
O Planning Poker é uma forma da técnica de estimativa conhecida como Delphi de banda larga. O Wideband Delphi foi criado pela corporação RAND em 1968. Presumo que, por Delphi, eles estejam se referindo ao o oráculo em Delphi. Se alguma coisa diz “não temos a menor ideia de quanto tempo isso levará”, é nomear seu processo de estimativa após sacerdotisas antigas e cheias de gás que ofereciam conselhos na forma de enigmas crípticos. Isso não inspira exatamente confiança, mas provavelmente é uma boa expectativa a ser estabelecida, considerando os riscos da estimativa.
O Planning Poker não é um conceito tão elevado quanto o Wideband Delphi, mas o processo é funcionalmente idêntico:
- Forme um grupo de, no máximo, 10 estimadores e um moderador. O proprietário do produto pode participar, mas não pode ser um estimador.
- Cada estimador recebe um baralho de cartas: 0, 1, 2, 3, 5, 8, 13, 20, 40 e 100.
- O moderador lê a descrição da história do usuário ou do tema. O proprietário do produto responde a breves perguntas dos estimadores.
- Cada avaliador seleciona um cartão de estimativa e o coloca virado para baixo na mesa. Depois que todas as estimativas são feitas, as cartas são viradas.
- Se as estimativas variarem muito, os proprietários das estimativas altas e baixas discutem os motivos pelos quais suas estimativas são tão diferentes. Todos os estimadores devem participar da discussão.
- Repita a partir da etapa 4 até que as estimativas convirjam.
Não há nada de mágico aqui; é o poder do diálogo em grupo e da média de estimativas múltiplas, apresentado em um formato acessível e divertido.
O Planning Poker é uma boa opção, principalmente se o seu processo de estimativa atual se assemelha a atirar dardos em uma impressão de um gráfico de Gantt do Microsoft Project. Mas o as melhores estimativas que o senhor pode produzir são aquelas baseadas em dados históricos. Steve McConnell disse um capítulo inteiro sobre isso, e aqui está o ponto de vista dele:
Se o senhor não tiver sido exposto anteriormente ao poder dos dados históricos, pode ser desculpado por não ter nenhum dado para usar em suas estimativas. Mas agora que sabe como os dados históricos são valiosos, o senhor não tem mais desculpas para não coletá-los. Certifique-se de que, ao reler este capítulo no próximo ano, o senhor não esteja ainda dizendo “Gostaria de ter alguns dados históricos!”
Em outras palavras, se o senhor não tiver dados históricos para basear suas estimativas, comece a coletá-los o mais rápido possível. Existem ferramentas que podem ajudar o senhor a fazer isso. Considere a versão mais recente do Fogbugz; seu principal recurso é o agendamento baseado em evidências. Armado com as evidências históricas corretas, o senhor pode…
Prever quando seu software será lançado. Aqui o senhor pode ver que temos 74% de chance de envio até 17 de dezembro.
Determinar quais desenvolvedores estão no caminho crítico. Alguns desenvolvedores são melhores em estimativas do que outros; o senhor pode transferir tarefas críticas para desenvolvedores com um histórico comprovado de cumprimento de suas estimativas.
Veja se o senhor é realmente um estimador preciso. O quanto suas estimativas se aproximam do tempo real que a tarefa levou?
Veja suas datas de envio previstas mudarem ao longo do tempo. Estamos vendo as estimativas de 5%, 50% e 95% no mesmo gráfico aqui. Observe como elas convergem à medida que o desenvolvimento avança; essa é uma evidência de que o projeto acabará sendo concluído e o senhor não ficará preso em algum tipo de limbo do Duke Nukem Forever.
Testemunhem, meus amigos, o poder dos dados históricos em um projeto de software.
O pequeno segredo sujo da programação baseada em evidências é que a coleta desse tipo de dados históricos não é trivial. Entra lixo, sai lixo. É preciso disciplina e esforço conjunto para inserir os tempos de esforço – mesmo em versões muito simplificadas – e mantê-los atualizados enquanto o senhor trabalha nas tarefas. O Fogbugz faz o possível para tornar isso simples, mas sua equipe tem que aderir à filosofia de acompanhamento de tempo para que funcione.
O senhor não precisa usar o Fogbugz. Mas, seja como for, recomendo que o senhor comece a capturar dados históricos de estimativas, se ainda não o fez. É um tremendo crédito para Joel Spolsky o fato de ele ter feito desse recurso crucial a peça central do novo Fogbugz. Não tenho conhecimento de nenhuma outra ferramenta de ciclo de vida de software que se esforce tanto para ajudá-lo a produzir boas estimativas.
Planejar o pôquer é um ponto de partida razoável. Mas o fato de dois ícones do setor, Joel Spolsky e Steve McConnell, estarem defendendo o mesmo ponto não é uma coincidência. Os dados históricos de estimativa são fundamentais para a ciência da engenharia de software. Com o tempo, tente reduzir sua dependência de apostas e comece a basear suas estimativas em dados reais. Sem algum tipo de memória de estimativa institucional, sem apreciar o poder dos dados históricos— o senhor provavelmente manterá repetindo os mesmos erros de estimativa várias vezes.