Antes que eu chegue muito longe, deixe-me dizer que Estimativa de software: desmistificando a arte negra é um excelente recurso para pessoas que olham e pensam em estimativas. Ambas as imagens abaixo são desse livro, assim como o núcleo, se as ideias apresentadas a seguir.
Como você observou, as estimativas são uma parte importante na capacidade de prever e planejar com precisão o trabalho. Não ter estimativas torna o negócio cego sobre quanto tempo algo vai demorar. Não é incomum que os negócios tenham uma ideia completamente equivocada sobre quanto tempo as coisas levarão - o que eles acham que é fácil leva de seis a oito semanas e o que é considerado difícil é um hack da tarde de sexta-feira.
A primeira coisa é dar uma estimativa. Uma estimativa em si não é um único número - isso é um compromisso. "Quanto tempo vai demorar ABC" - > "Cerca de 5 dias" significa que são cerca de 5 dias. No entanto, uma boa estimativa é um intervalo em que você tem 90% de certeza de que terá esse intervalo. Se você quer dizer "Eu tenho 90% de certeza de que levará entre 1 e 5 dias", então diga isso. Não trabalhe "Acho que vai demorar entre 1 e 10 dias, então 5 dias é provavelmente sobre a média" - isso não é uma estimativa e você estará errado em 50% do tempo.
Bem, 50% ou mais do tempo, os programadores são notórios subestimadores para os tempos de tarefas.
Considere o Cone da Incerteza: link
Imagem do link - artigo completo em link
Perceba que a primeira estimativa nesse intervalo é de 16x. Isto é semelhante a dizer "eu acho que vai demorar entre uma tarde e duas semanas" - mas você não sabe ainda. Conforme você avança um pouco com o design, o alcance diminui para 4x. Isso faz não significa que levará uma semana, isso significa que você preferiria dizer "depois de analisar isso um pouco, levará entre três semanas" - sim, a estimativa subiu, mas também o intervalo da estimativa caiu.
A cada estimativa que você der, você precisa ter 90% de certeza de que a estimativa está dentro desse intervalo. Você pode estar errado - 10% do tempo vai cair fora desse intervalo.
Existem muitas maneiras de estimar o tamanho dos projetos. Comparando com projetos passados, usando um proxy (acho que seriam necessárias 1000 linhas de código que demorariam tanto tempo para escrever), usando pontos de função (para converter em LOC ...), obtendo estimativas de um número de pessoas e então refinando iterativamente ... algum trabalho para alguns projetos, alguns trabalhos para outros projetos.
Um muito capítulo importante neste livro que mencionei no topo é o nº 23, que trata da política de estimativa e de lidar com gerentes e executivos.
A chave para uma estimativa é o processo iterativo de refiná-la depois de trabalhar um pouco nela.
Dar uma estimativa muito precisa de uma estimativa muito cedo no processo pode ser muito propenso a erros. Se você não tem certeza sobre isso, dê uma estimativa ampla e depois volte com uma outra estimativa após algum período de tempo para mais introspecção no problema e possivelmente esboçando como você o fará, observando quanto código você escreveu para o problema. o último problema semelhante e outros fatores que afetarão a estimativa.
As estimativas exigem algum pensamento - não exponha as estimativas de algemas. Eles geralmente têm erros enormes associados a eles, em comparação com o que é preciso quando você pensa um pouco sobre isso.
De Como responder quando lhe pedem uma estimativa?
What to Say When Asked for an Estimate
You say "I'll get back to you."
You almost always get better results if you slow the process down and spend some time going through the steps we describe in this section. Estimates given at the coffee machine will (like the coffee) come back to haunt you.
Do capítulo 4 da estimativa de software:
Observe que, nesse caso, as estimativas após um pouco de revisão são sistematicamente menos agressivas e propensas a erros do que as estimativas improvisadas. Não faça estimativas improvisadas. Sente-se e pense sobre a tarefa e faça a estimativa depois de refletir um pouco sobre ela.