Alguns conselhos do lado negro de alguém que aprendeu da maneira mais difícil.
The requirements are unclear. Nobody has done an in depth analysis of
all the implications.
Não faça uma estimativa neste momento. Não se estima quantos soldados são necessários para vencer uma batalha sem pistas sobre os números inimigos. A estimativa é feita após o escotismo. Isto é, a menos que você já tenha lutado contra esse inimigo.
The new feature will probably break some assumptions you made in your
code and you start thinking immediately of all the things you might
have to refactor.
Esta é sua responsabilidade de levar em consideração, a menos que você espere que os outros tenham conhecimento sobre essa área.
You have other things to do from past assignments and you will have to
come up with an estimate that takes that other work into account.
O mesmo que acima, mesmo para trabalhos imprevistos criados por um colega de equipe desleixado ao seu lado com um procedimento de teste quase inexistente que faz com que seu código se destaque e não seja possível prever com precisão antecipadamente. É uma previsão do tempo.
The 'done' definition is probably unclear: When will it be done?
'Done' as in just finished coding it, or 'done' as in "the users are
using it"?
Entenda o requisito de fim de usuário aqui, pense como um usuário. Não faça o que seus colegas fazem se eles estimarem que algo está "pronto" só porque algumas funcionalidades básicas com um fluxo de trabalho básico que nenhum usuário pode tolerar é o que eles consideram ser "feito" . Pense nisso do ponto de vista do usuário, porque isso é tudo o que você está fazendo a estimativa para entender normalmente. Estime para os requisitos completos de usuário final, não para os requisitos técnicos do barebone. E perceba que seus clientes que pedem estimativas serão totalmente imprecisos aqui sobre como eles dizem as coisas e entendem os aspectos técnicos do que você diz.
No matter how conscious you are of all these things, sometimes your
"programmer's pride" makes you give/accept shorter times than you
originally suppose it might take. Specially when you feel the pressure
of deadlines and management expectations.
Não faça isso! Você parece um trabalhador esforçado e auto-motivado e possivelmente alguém que se entrega facilmente à coerção.
O problema aqui é o seguinte: digamos que você e Joe tenham feito estimativas de tempo para a mesma tarefa (mas entre dois funcionários separados, inconscientes de ambas as estimativas ao mesmo tempo). Você estima valentemente, "uma semana" . Tudo bem, você pensa, você vai trabalhar mais de 100 horas por semana, horas extras não pagas. Agora você está três dias atrasado.
Enquanto isso, Joe estima 5 meses. Você acha que isso é ridículo, você acha que pode conseguir isso em uma semana. Quanto Joe trabalha? 10 horas por semana? ... exceto que ele termina no tempo em exatamente 5 meses.
Adivinha quem é percebido como o idiota? Está certo você. Joe parece ser um grande trabalhador, você parece pouco confiável agora. Não importa tanto que você tenha conseguido um resultado ainda melhor em aproximadamente 7% do tempo que Joe tomou. O que importa é que você ficou 3 dias fora de uma estimativa de uma semana.
Nunca erre do lado da estimativa mais apertada. Errar do lado da estimativa mais solta. Há uma reputação a ser construída em sua empresa e não se baseia tanto no tamanho de suas estimativas quanto na precisão de suas estimativas. É fácil ser preciso com uma estimativa que é muito longa, você só tem mais tempo para trabalhar no problema e resolvê-lo melhor. Uma estimativa que é muito curta não deixa espaço para respirar, você quer encontrá-lo desesperadamente ou você está ferrado.