Como você pode estimar o tempo para tarefas que consistem principalmente em descobrir um problema?

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.

Boss: AJ, We have 3 dogs, 2 rabbits, a catapult, and a nun. We need to find a way to get all 7 (yes, the catapult too) over a 20-foot wall and into the lake on the other side without the dogs eating any rabbits, and without drowning the nun. How long will it take you to come up with the solution?

Veja, o problema de estimar quanto tempo levará para resolver um problema é que ele leva pessoas diferentes em um período de tempo diferente. Se você tem um histórico de solução de problemas semelhantes, pode estimar com base em quanto tempo você demorou antes. Se você não o fizer, então você não está estimando, você está apenas supondo.

Além disso, o problema pode até não ter uma solução aceitável. Ou talvez a solução necessite de autorização adicional, o que poderia prejudicar todo o projeto. Ou talvez a solução mude toda a natureza percebida do problema, de modo que a solução se torne totalmente desnecessária.

A moral da história é, se você não tiver informações suficientes para fazer uma estimativa razoável, então não . Ainda não. Consiga mais informação. Pesquise mais. Normalmente, é perfeitamente correto dizer: "Voltarei a você em dois dias com números mais sólidos".

Ao projetar uma solução para o cliente I, não assinarei um contrato até que eu tenha o suficiente do design geral completo para que eu saiba como será a solução e quanto tempo o projeto levará. Isso significa que eu corro o risco de ter feito um trabalho de design inicial pelo qual não sou pago (se o projeto não for aprovado), mas isso é melhor do que estar em risco de reduzir o faturamento do trabalho que está sendo feito. .

Eu sugiro que você tente algo no meio do caminho entre as respostas de tylerl e MichaelT com o seguinte:

• divida o trabalho a ser feito em 3 ou 4 fases. As fases devem ser:
  1. Análise de problemas
  2. Prototipagem de soluções
  3. Solução do mundo real
  4. Avaliação de saída (teste)
• forneça uma estimativa apenas para a fase 1 (análise) com base na sua experiência, ou nas fases 1 + 2 (análise + protótipo) para o seu gerenciamento. Em seguida, forneça uma estimativa para as fases 3 + 4 quando as fases 1 e 2 do problema estiverem concluídas (ou pelo menos avançadas o suficiente para que você possa confiar em sua estimativa).

Isso pode não ser exatamente o que a gerência deseja, mas acredito que é sempre melhor gerar estimativas que você realmente atenderá.

A primeira pergunta que eu faria a mim mesmo, , é um problema que pode ser resolvido? Não se trata de um intelecto ou de uma questão de poder cerebral, mas de realidade prática. A menos que você esteja no mundo das fotos lunares do Google, onde o fracasso é um resultado esperado, a dura realidade é que espera-se que nós entreguemos isso , o que isso acaba estar. Uma regra básica parece ser: já sabemos o que 90% da solução precisa ser?

A segunda pergunta que eu faria, o que mais seria útil saber ao pensar sobre a solução? Esta é realmente uma forma de checar duas vezes se realmente sabemos o suficiente para chegar a uma solução isso será aceitável. Ele pode gerar uma série de tarefas de descoberta de fatos que ajudam a definir melhor o que a solução precisa ser, cada uma das quais é geralmente fácil de definir e estimar.

A terceira pergunta é, quem é o mais adequado na equipe para esse tipo de problema? Quem quer que tenha essa tarefa, dará sabor ao resultado com seu próprio estilo. Dando este tipo de problema a um programador que tem 10 milhões de perguntas no início de uma tarefa, e depois vai embora e entrega algo pela primeira vez (embora lentamente) pode bem ser uma escolha melhor do que dar ao programador uma implementação rápida , mas quando há um problema, ele é descoberto apenas no final do processo.

Então, a tarefa real seria pensar em possíveis soluções, implementações e abordagens, e ter uma escala de tempo fixa na qual eles precisam relatar.

Quando eles retornam, você tem a opção de obter um conjunto mais amplo de soluções possíveis, dando continuidade à implementação de uma solução ou refletindo, pois a solução ainda não está definida com clareza suficiente

Com questões de pesquisa em que não está claro se existe uma resposta, e muito menos uma ideia clara do que precisa ser feito, geralmente proponho gastar x quantidade de tempo como um começo.

"Eu não tenho ideia se isso é possível, mas eu poderia passar dois dias pesquisando. Isso provavelmente não nos dará uma solução, mas talvez eu seja capaz de descartar algumas coisas e eu provavelmente vou ter uma ideia de quais seriam os próximos passos concretos e que tipo de investimento de tempo significariam. Então, podemos decidir se faz sentido dar outro passo. "

Portanto, coloque a incerteza na outra direção - a estimativa é bem precisa (vou passar dois dias), é apenas muito indeterminado o que será alcançado até então.

Timeboxing, basicamente.