Estimativa dos custos de tempo na base de código herdada

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:

1. 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.
2. 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.
3. 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 .
4. 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.

Este pode ser um bom momento para introduzir uma abordagem quase-ágil. Se, em vez de estimar em termos de horas / dias, você alocou uma escala de tipo fibonacci & deu a cada tarefa um valor baseado em quão grande é:

• 0 - instant
• 0,5 - vitória rápida
• 1 - alteração simples
• 2 - algumas alterações simples
• 3 - mais desafiador
• 5 - vai exigir algum pensamento sobre
• 8 - uma quantidade significativa de trabalho
• 13 - um grande pedaço de trabalho que provavelmente precisa ser dividido
• 20 - um grande pedaço de trabalho que definitivamente precisa ser quebrado

Depois de estimar um monte de tarefas como essa, você trabalha com elas. Em um ambiente ágil, você desenvolve 'velocidade', que é uma medida de quantos pontos você consegue em, digamos, uma semana. Depois de fazer algumas semanas de teste e aprendizado (você pode vender isso para seu gerente como parte do processo - "Vou precisar de algumas semanas de teste e aprender a entender o processo de estimativa"). tenha mais confiança em quantos pontos você pode passar a cada semana & portanto, você pode traduzir sua estimativa de pontos mais rapidamente em tempo.

link

link

Isso não é realmente ágil, pois não envolveria as cerimônias, mas eu tenho a idéia do OP de que ele está por conta própria. Espero que essa abordagem possa fornecer estimativas mais confiáveis.

A primeira coisa que você faz é começar a coletar dados sobre quanto tempo você leva para fazer qualquer coisa agora. Quanto mais dados você tiver sobre o desempenho de sua equipe, melhor. Vai ser todo o conselho, mas não se preocupe com isso agora. É a verdade e você precisa mostrar a realidade do seu chefe.

Então você vai comprar alguns livros.

1. Estimativa de software: desmistificando a arte negra de Steve McConnell
2. Trabalhando efetivamente com o código herdado de Michael Feathers

O livro de McConnell vai lhe dizer para começar a coletar dados e depois explicar como usá-lo para obter estimativas mais precisas. Sempre dê uma estimativa de 3 pontos! Sempre. Lembre-se de destacar as partes do livro que falam sobre como a qualidade do código ruim afetará suas estimativas. Mostre-os ao seu chefe.

Explique que, se as estimativas precisas forem importantes para a empresa, você precisará começar a aplicar as coisas que está aprendendo no livro de Feather. Se você quiser ir de forma rápida, suave e previsível, precisará começar a refatorar o código e colocá-lo em um equipamento de teste. Eu estive bem onde você está. O tempo de desenvolvimento é completamente imprevisível porque você não tem idéia do que você poderia quebrar, certo? ... Yeah. Coloque-o em um arnês de teste. Um servidor de IC para executar esses testes também não iria prejudicar.

Por fim, explique ao seu chefe que as coisas ainda serão um pouco imprevisíveis por um tempo. Provavelmente, alguns anos, mas esse desenvolvimento se tornará mais fácil diariamente e as estimativas se tornarão mais precisas, já que você tem mais dados e o código fica melhor. Este é um investimento a longo prazo para a empresa. Eu passei por isso recentemente, levou quase 2 anos para se tornar mais previsível.

Sei que falei mais sobre como melhorar o código do que sobre a estimativa, mas a dura verdade é que suas estimativas serão péssimas até que você consiga domar a base de código herdada. Nesse meio tempo, use o desempenho histórico para avaliar quanto tempo levará. À medida que o tempo passa, você deve levar em consideração se já obteve o código até a especificação em suas estimativas.

Now my boss is rightly asking me an estimation on how long would it take to write feature X in the new architecture. But I'm having difficulties coming up with a realistic estimation; often times I way underestimate the task due to reasons I've stated above and embarrass myself because I can't finish in time.

Você talvez esteja pensando na caixa de envio de uma uma estimativa. Eu tenho que trabalhar em código legado, e quando eu faço uma estimativa mais formal, eu costumo fazer dois ou três :

1. Estimativa principal - supondo que tenho que gastar algum tempo pesquisando, mas a arquitetura permite as alterações que desejamos
2. Angelic Estimate - presume que tudo é transparente / fácil de encontrar e eu só tenho que fazer pequenas alterações (isso é o que eu deixo de fora às vezes ... especialmente se eu sei que há apenas diabos em uma base de código particular )
3. Estimativa Abissal - presume que a estrutura fundamental do código legado é incompatível com o recurso solicitado e eu farei grandes refatorações para fazer as coisas funcionarem

Todas as três estimativas levam em conta quão difícil é a característica em si, qualquer experiência que eu tenha com essa base geral de código, e meu pressentimento sobre a mudança (que eu encontrei pode ser bastante preciso)

Depois que essas estimativas saem, mantenho meu gerente atualizado em qual delas parece que estamos lidando. Se descobrirmos que estamos olhando para um aspecto abissal, podemos ter que sacrificá-lo - isso aconteceu. Se o seu chefe não puder aceitar que existem recursos abissais para um determinado pedaço de código legado, então desejo-lhes boa sorte, pois eles terão uma vida muito difícil e frustrante.

Quando enfrentei esse tipo de problema, confiei em intervalos nas minhas estimativas. Fui longe de dizer aos meus chefes que "é difícil fazer boas estimativas improvisadas nesta base de código. Se você pedir uma, será uma estimativa muito ampla". Eu dei "3 dias a 3 anos" como uma estimativa uma vez. Escusado será dizer que não era uma estimativa popular, mas é o que eu dei.

A chave para isso é um acordo que atualizarei minhas estimativas à medida que o trabalho avança. Então, se eu for dito "Implement XYZ, quanto tempo vai demorar?" minha resposta pode ser "em algum lugar entre um dia e quatro meses. No entanto, se você me deixar realmente observar o código por algumas horas, posso reduzir a incerteza nessa janela". Então eu vou olhar o código e voltar com "2 a 4 semanas". Isso ainda não é uma janela ideal, mas pelo menos é algo que pode ser gerenciado.

Existem algumas chaves para isso:

• Convença o chefe de que essas estimativas são mais bem tratadas como uma conversa porque você aprenderá mais sobre a aparência da tarefa enquanto a trabalha. Esta é uma oportunidade para o seu chefe ter informações que eles não teriam se pedissem uma única estimativa.
• Ofereça opções sobre como avançar com a velocidade de desenvolvimento do código de negociação versus melhorar as estimativas. Dê-lhes um botão extra que eles podem virar. Às vezes, os chefes sabem que uma tarefa só precisa ser feita e precisam apenas de uma estimativa. Outras vezes eles estão executando os prós e contras de uma tarefa, e a capacidade de refinar as estimativas é valiosa.
• Se possível, também ofereço bônus de sinergia. Muitas vezes, há melhorias arquitetônicas que teriam benefícios para muitas tarefas. Se eu tiver 10 tarefas, todas com "1-2 meses agora, mas demorariam 2 semanas com o upgrade X", é mais fácil vender as 20 semanas que levará para atualizar o X.