Leia "Clean Coder", de Bob Martin (e "Clean Code", enquanto você está nisso). O que se segue é da memória, mas sugiro que você compre sua própria cópia.
O que você precisa fazer é uma média ponderada de três pontos. Você faz três estimativas para cada trabalho:
- o melhor cenário possível - supondo que tudo corra bem (a)
- o pior cenário possível - supondo que tudo esteja errado (b)
- o palpite real - o que você acha que provavelmente vai demorar (c)
Sua estimativa é então (a + b + 2c) / 4
- Não, não será preciso. Existem maneiras melhores de estimar, mas esse método é rápido, fácil de entender e mitiga o otimismo, fazendo com que você considere o pior caso.
- Sim, você terá que explicar ao seu gerente que não está familiarizado com o código e que é muito imprevisível fazer estimativas firmes e precisas sem gastar muito tempo investigando o código a cada vez para melhorar a estimativa (oferta para faça isso, mas diga que precisa de n dias apenas para dar uma estimativa firme de quantos dias a mais levará). Se você é um "JuniorDev", isso deve ser aceitável para um gerente razoável.
- Você também deve explicar ao seu gerente que as suas estimativas são calculadas com base na melhor das hipóteses, no pior caso e no caso provável, além de fornecer a eles seus números, o que também lhes dá as barras de erro.
- NÃO negocie em uma estimativa - se seu gerente tentar usar o melhor caso para cada estimativa (eles são um tolo - mas eu conheci alguns assim) e depois intimidar / motivá-lo a tentar atingir o prazo, bem, eles vão ficar desapontados às vezes. Continue explicando a lógica por trás das estimativas (melhor caso, pior caso e caso provável) e mantenha-se perto da média ponderada na maioria das vezes e você deve estar OK. Além disso, para seus próprios propósitos, mantenha uma planilha com suas estimativas e adicione seus valores reais quando terminar. Isso deve lhe dar uma ideia melhor de como ajustar suas estimativas.
Editar:
Minhas suposições quando respondi isso:
- O OP é um Desenvolvedor Júnior (baseado no nome de usuário escolhido). Qualquer conselho dado não é, portanto, da perspectiva de um Gerente de Projeto ou Líder de Equipe, que pode ser capaz de realizar estimativas mais sofisticadas, dependendo da maturidade do ambiente de desenvolvimento.
- O gerente de projetos criou um plano de projeto que consiste em um número bastante grande de tarefas planejadas para levar vários meses para serem entregues.
- Solicitou-se ao OP que fornecesse uma série de estimativas para as tarefas atribuídas pelo gerente de projetos que deseja um número razoavelmente preciso (não uma curva de probabilidade :) para alimentar o plano do projeto e usá-lo para rastrear o progresso .
- OP não tem semanas para produzir cada estimativa e foi queimado antes, dando estimativas otimistas e quer um método mais preciso do que colocar um dedo no ar e dizer "2 semanas, a menos que o código seja particularmente arcaico em que caso 2 meses ou mais ".
A média ponderada de três pontos funciona bem nesse caso. É rápido, compreensível para o não-técnico e, ao longo de várias estimativas, deve ser considerado como algo próximo da precisão. Especialmente se OP me aconselhar sobre manter registros de estimativas e dados reais. Quando você sabe como o "pior caso" e o "melhor caso" do mundo real parecem, você pode inserir os dados atuais em suas estimativas futuras e até mesmo ajustar as estimativas para o gerente do projeto se o pior cenário for pior do que você imaginava.
Vamos fazer um exemplo trabalhado:
- Best case, from experience the fastest I've done a really straightforward one was a week start to finish (5 days)
- Worst case, from experience, there was that time that there were links everywhere and it ended up taking me 6 weeks (30 days)
- Actual Estimate, it'll probably take me 2 weeks (10 days)
5+30+2x10 = 55
55/4 = 13.75 which is what you tell your PM. Maybe you round up to 14 days. Over time, (e.g. ten tasks), it should average out.
Não tenha medo de ajustar a fórmula. Talvez metade das tarefas acabe em pesadelos e apenas dez por cento sejam fáceis; então você faz a estmate a / 10 + b / 2 + 2c / 5. Aprenda com sua experiência.
Note que não estou fazendo nenhuma suposição sobre a qualidade do PM. Um PM ruim vai dar uma pequena estimativa para a diretoria do projeto para obter aprovação e, em seguida, intimidar a equipe do projeto para tentar chegar ao prazo irrealista com o qual se comprometeram. A única defesa é manter um registro para que você possa ser visto dando suas estimativas e se aproximando delas.