Leia "Clean Coder", de Bob Martin (e "Clean Code", enquanto você faz isso). A seguir, é de memória, mas eu sugiro fortemente 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:
- um cenário de melhor caso - assumindo que tudo dá certo (a)
- o pior cenário possível - assumindo que tudo dá errado (b)
- o palpite real - o que você acha que provavelmente será necessário (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 atenua o otimismo, fazendo você considerar o pior caso.
- Sim, você terá que explicar ao seu gerente que não está familiarizado com o código e que é imprevisível demais fazer estimativas precisas e firmes, sem gastar muito tempo investigando o código a cada vez para melhorar a estimativa (ofereça isso, mas digamos que você precisa de n dias apenas para fornecer uma estimativa firme de quantos dias serão necessários). Se você é um "JuniorDev", isso deve ser aceitável para um gerente razoável.
- Você também deve explicar ao seu gerente que suas estimativas são calculadas como médias, com base no melhor caso, no pior caso e no caso provável e fornecer a eles seus números, o que também fornece as barras de erro.
- NÃO negocie uma estimativa - se o seu gerente tentar usar o melhor caso para cada estimativa (eles são tolos - mas eu já conheci alguns assim) e então intimidar / motivar você a tentar cumprir o prazo, bem, eles às vezes vou ficar decepcionado. Continue explicando a lógica por trás das estimativas (melhor, pior e provável) e continue se aproximando da média ponderada na maioria das vezes, e você deve estar bem. Além disso, para seus próprios fins, mantenha uma planilha de suas estimativas e adicione seus dados reais quando terminar. Isso deve lhe dar uma idéia melhor de como ajustar suas estimativas.
Editar:
Minhas suposições quando eu respondi isso:
- O OP é um desenvolvedor júnior (com base 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 possa executar estimativas mais sofisticadas, dependendo da maturidade do ambiente de desenvolvimento.
- O gerente de projeto criou um plano de projeto que consiste em um número bastante grande de tarefas planejadas para levar vários meses para serem entregues.
- Solicita-se ao OP que forneça uma série de estimativas para as tarefas às quais são designadas pelo gerente de projetos que desejam um número razoavelmente preciso (não uma curva de probabilidade :)) para alimentar o plano do projeto e usá-lo para acompanhar o progresso.
- O OP não tem semanas para produzir cada estimativa e foi queimado antes, fornecendo estimativas super otimistas e quer um método mais preciso do que enfiar um dedo no ar e dizer "2 semanas, a menos que o código seja particularmente arcano; nesse caso, 2 meses ou mais".
A média ponderada de três pontos funciona bem nesse caso. É rápido, compreensível para os não técnicos e, ao longo de várias estimativas, deve ter uma média aproximada da precisão. Especialmente se o OP seguir meus conselhos sobre como manter registros de estimativas e dados reais. Quando você sabe como é o "pior caso" e o "melhor caso" do mundo real, pode alimentar os dados reais em suas estimativas futuras e até mesmo ajustá-las ao gerente de projetos, se o pior caso for pior do que você pensava.
Vamos fazer um exemplo trabalhado:
- Na melhor das hipóteses, por experiência, o mais rápido que fiz foi realmente direto: uma semana do início ao fim (5 dias)
- Na pior das hipóteses, por experiência própria, houve um tempo em que havia links em todos os lugares e isso me levou 6 semanas (30 dias)
- Estimativa real, provavelmente levará duas semanas (10 dias)
5 + 30 + 2x10 = 55
55/4 = 13,75, que é o que você diz ao seu PM. Talvez você complete até 14 dias. Com o tempo (por exemplo, dez tarefas), a média deve ser calculada.
Não tenha medo de ajustar a fórmula. Talvez metade das tarefas acabe sendo pesadelo e apenas dez por cento sejam fáceis; então você faz o estmate a / 10 + b / 2 + 2c / 5. Aprenda com sua experiência.
Observe que não estou fazendo suposições sobre a qualidade do PM. Um PM ruim fornecerá uma estimativa curta ao conselho do projeto para obter aprovação e, em seguida, intimidará a equipe do projeto para tentar alcançar o 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.