Estimando custos de tempo na base de código herdada

86

Recentemente, comecei a trabalhar em um projeto em que um aplicativo monolítico muito antigo está sendo migrado para a arquitetura baseada em microsserviços.

A base de código herdada é muito confusa ('código de espaguete') e geralmente uma função aparentemente simples (por exemplo, denominada "multiplyValueByTen") mais tarde se revela como "milhares de linhas de código de validação envolvendo 10 tabelas em 3 esquemas diferentes".

Agora, meu chefe está (com razão) me pedindo para estimar quanto tempo levaria para escrever o recurso X na nova arquitetura. Mas estou tendo dificuldades em apresentar uma estimativa realista; freqüentemente subestimo imensamente a tarefa devido a razões que afirmei acima e me envergonho porque não consigo terminar a tempo.

A coisa sensata pode parecer realmente entrar no código, anotar todas as ramificações e chamadas para outras funções e depois estimar o custo do tempo. Mas há realmente uma diferença minúscula entre documentar o código antigo e realmente escrever a nova versão.

Como devo abordar um cenário como este?

Embora eu entenda perfeitamente como funciona a refatoração de código legado, minha pergunta não é sobre "como refatorar / reescrever?" mas sobre dar uma resposta realista a "quanto tempo levaria para refatorar / reescrever a parte X?"

JuniorDev
fonte
37
Faça estimativas com margens amplas, não com valores únicos; por exemplo, 5 a 15 dias
Richard Tingle
32
@JuniorDev: por que você acha "inaceitável para um líder de equipe não técnico"? Ele pode não gostar da sua resposta, mas se você não pode dar uma estimativa melhor, é muitas vezes dizer diretamente à pessoa, em vez de tentar agradá-la agora com uma estimativa muito baixa e dizer depois de 5 dias, desculpe, apenas concluímos o tarefa para 30%.
Doc Brown
13
"O mais sensato pode parecer realmente entrar no código, anotar todas as ramificações e chamar outras funções e depois estimar o custo do tempo. Mas há realmente uma diferença minúscula entre documentar o código antigo e realmente escrever a nova versão". - hahahahahahahahahahahahahahahahahahahaha heh. heh Portanto, pode parecer que sim, mas quando você limpa um código legado, as peculiaridades lidam com problemas que você nunca ouviu falar em casos que nunca considerou. Ou remendar erros em outros lugares. Ou é um erro, mas erros que outras partes do código dependem da existência.
Yakk
27
Vou contar um pequeno segredo: se seu gerente está pedindo a um desenvolvedor júnior que faça uma estimativa técnica, uma das duas coisas é verdadeira: ele sabe que você não sabe como fazer uma estimativa verdadeira e está fazendo isso uma oportunidade de ensino, ou ele é um gerente inexperiente e acha que um desenvolvedor júnior pode fazê-lo. Eu nunca vi um desenvolvedor júnior que pudesse fazer isso, incluindo (especialmente?) Eu mesmo quando eu era um desenvolvedor júnior.
CorsiKa
27
6 a 8 semanas , como todos sabemos.
Matthieu M.

Respostas:

111

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:

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

mcottle
fonte
31
"Eles são um tolo - mas eu já conheci alguns assim". De fato.
Kramii
17
Eu quero aprovar isso, mas não posso ficar atrás de uma única estimativa pontual.
11337 RubberDuck
6
Está bem. +1 para o seu último marcador.
RubberDuck
5
+1, uma estimativa não é uma hora exata e, portanto, não pode ser um número único. Também pode valer a pena acrescentar que se trata de uma estimativa , não de um compromisso, portanto o gerente não deve esperar que você seja definitivamente feito. É responsabilidade de um engenheiro de software deixar a diferença clara para o gerente.
Kat
10
@mcottle FYI, esta não é uma estimativa de Monte Carlo. Você simplesmente calculou o valor esperado (que seria bem-sucedido em cerca de 50% do tempo) de uma distribuição PERT. Monte Carlo refere-se a um processo em que os valores estatísticos são derivados essencialmente por força bruta com um gerador de números aleatórios.
David Meister
30

Esse 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 do tipo fibonacci e atribuiu a cada tarefa um valor com base no tamanho:

  • 0 - instantâneo
  • 0.5 - vitória rápida
  • 1 - mudança simples
  • 2 - algumas mudanças simples
  • 3 - mais desafiador
  • 5 - exigirá alguma reflexão sobre
  • 8 - uma quantidade significativa de trabalho
  • 13 - um grande pedaço de trabalho que provavelmente precisa ser dividido
  • 20 - um pedaço enorme de trabalho que definitivamente precisa ser dividido

Depois que você estimar várias tarefas como essa, trabalha nelas. Em um ambiente ágil, você desenvolve 'velocidade', que é uma medida de quantos pontos você alcança em, digamos, uma semana. Depois de fazer algumas semanas de teste e aprendizado (você pode vendê-lo ao seu gerente como parte do processo - "Vou precisar de algumas semanas de teste e aprender a entender o processo de estimativa"). mais confiante em quantos pontos você pode passar a cada semana e, portanto, você pode traduzir sua estimativa de pontos mais rapidamente no tempo.

https://pm.stackexchange.com/questions/4251/why-would-teams-use-the-fibonacci-sequence-for-story-points

https://stackoverflow.com/questions/9362286/why-is-the-fibonacci-series-used-in-agile-planning-poker

Isso não é realmente ágil, pois não envolveria as cerimônias, mas eu entendi do OP que ele é ele mesmo. Esperamos que essa abordagem possa fornecer estimativas mais confiáveis.

amelvin
fonte
Isso funciona melhor em projetos de maior escala (mais de um mês). Em projetos de menor escala, isso só poderia funcionar após alguns projetos semelhantes.
Emile Bergeron
1
@RobP. é uma peculiaridade na progressão ágil ponto da história: 13, 20, 40, 100 - embora a maioria das pessoas não se preocupam ajuste mais de 20 pontos como pelo então você realmente precisa fazer para decompô-lo
HorusKol
1
Não concordo que pontos da história + cerimônias = Agile.
Webdevduck 15/02
1
@webdevduck "discordo de acordo"?
krillgar
1
@krillgar D'oh! Discordo!
Webdevduck 15/02
14

A primeira coisa a fazer é começar a coletar dados sobre quanto tempo você leva para fazer qualquer coisa no momento. Quanto mais dados você tiver sobre o desempenho de sua equipe, melhor. Vai estar em toda parte, 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 por Steve McConnell
  2. Trabalhando efetivamente com o código legado de Michael Feathers

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

Explique que se estimativas precisas são importantes para a empresa, você precisará começar a aplicar o que está aprendendo com o livro de Feather. Se você deseja avançar de maneira rápida, suave e previsível, precisará refatorar o código e colocá-lo em um equipamento de teste. Eu estive exatamente onde você está. O tempo de desenvolvimento é completamente imprevisível, porque você não tem idéia do que poderia quebrar, certo? ... Sim. Coloque-o em um equipamento de teste. Um servidor de CI para executar esses testes também não poderia prejudicar.

Por fim, explique ao seu chefe que as coisas ainda serão um pouco imprevisíveis por um tempo. Provavelmente daqui a alguns anos, mas esse desenvolvimento se tornará mais fácil diariamente e as estimativas se tornarão mais precisas conforme você tiver mais dados e o código melhorar. Este é um investimento de 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 melhorar o código do que estimar, mas a dura verdade é que suas estimativas serão péssimas até que você possa domesticar a base de código herdada. Enquanto isso, use o desempenho histórico para avaliar quanto tempo levará. Com o passar do tempo, convém levar em consideração se você já obteve ou não o código especificado nas suas estimativas.

Pato de borracha
fonte
1
+1 em "coloque-o em um equipamento de teste". Ao refatorar o código antigo, uma abordagem de teste primeiro (para verificar se os componentes críticos do código antigo funcionam exatamente como você pensa antes de alterar qualquer coisa) é imbatível. Essa resposta também me convenceu a comprar o livro "Estimativa de software", do qual nunca tinha ouvido falar antes (minhas estimativas são ruins).
GlenPeterson
7

Agora, meu chefe está corretamente me pedindo uma estimativa de quanto tempo levaria para escrever o recurso X na nova arquitetura. Mas estou tendo dificuldades em apresentar uma estimativa realista; muitas vezes subestimo a tarefa devido a razões que afirmei acima e me envergonho porque não consigo terminar a tempo.

Talvez você esteja pensando em enviar uma estimativa. Tenho que trabalhar no código legado e, quando faço uma estimativa mais formal, costumo fazer dois ou três :

  1. Estimativa primária - supondo que eu tenha que gastar algum tempo cavando, mas a arquitetura permite as alterações que queremos
  2. Estimativa angélica - assume que tudo é transparente / fácil de encontrar e eu só preciso fazer pequenas alterações (essa é a que deixo de fora algumas vezes ... especialmente se eu souber que há apenas demônios em uma base de código específica)
  3. Estimativa Abissal - pressupõe que a estrutura fundamental do código legado seja incompatível com o recurso solicitado e eu farei uma grande refatoração para fazer as coisas funcionarem

Todas as três estimativas levam em consideração o grau de resistência do recurso, qualquer experiência que eu tenha tido com essa base geral de códigos e meu pressentimento sobre a mudança (que eu acho que pode ser bastante precisa)

Depois que essas estimativas são divulgadas, mantenho meu gerente atualizado sobre qual deles parece que estamos lidando. Se estivermos olhando para uma característica abissal, talvez tenhamos que sacrificá-la - aconteceu. Se o seu chefe não pode aceitar a existência de recursos abissais para um determinado pedaço de código legado, desejo-lhes boa sorte, pois eles terão uma vida muito difícil e frustrante.

Jeutnarg
fonte
+1 para o último parágrafo - Eu gostaria de ter incluído o que na minha resposta
mcottle
3

Quando enfrentei esse tipo de problema, contei com intervalos nas minhas estimativas. Comecei a dizer aos meus chefes que "é difícil fazer boas estimativas imediatas nessa 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 informado "Implementar XYZ, quanto tempo vai demorar?" minha resposta pode ser "algo entre um dia e quatro meses. No entanto, se você me deixar analisar 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". Essa ainda não é uma janela ideal, mas pelo menos é algo que pode ser gerenciado.

Existem algumas chaves para isso:

  • Convencer o chefe que essas estimativas são melhor tratados como uma conversa, porque você vai saber mais sobre o que a tarefa parece enquanto você trabalha nele. Esta é uma oportunidade para o seu chefe ter informações que não teria se apenas pedisse uma única estimativa.
  • Ofereça opções sobre como avançar em qual velocidade de desenvolvimento do código comercial vs. estimativas melhores. Dê a eles um botão extra que eles possam girar. Às vezes, os chefes sabem que uma tarefa precisa ser concluída e precisam apenas de uma estimativa aproximada. Outras vezes, eles executam os prós e os contras de uma tarefa, e a capacidade de refinar as estimativas é valiosa.
  • Se possível, também oferecerei bônus de sinergia. Muitas vezes, há melhorias arquiteturais que trariam benefícios para muitas tarefas. Se eu tiver 10 tarefas, todas com duração de "1-2 meses agora, mas levariam 2 semanas com a atualização X", é mais fácil vender as 20 semanas que podem levar para a atualização X.

Se eu tiver um chefe que não se sinta confortável em receber um intervalo atualizado à medida que for, darei a ele um número único e minha metodologia. Minha metodologia é uma combinação de uma regra prática que me disseram como jovem desenvolvedor e a lei de Hofstader .

Estime quanto tempo você acha que a tarefa deve levar, quadruplique esse número e dê-o como sua estimativa.

e

Lei de Hofstadter: "Sempre leva mais tempo do que você espera, mesmo quando você leva em conta a Lei de Hofstadter".

Cort Ammon
fonte
2

A coisa sensata pode parecer realmente entrar no código, anotar todas as ramificações e chamadas para outras funções e depois estimar o custo do tempo. Mas há realmente uma diferença minúscula entre documentar o código antigo e realmente escrever a nova versão.

Esta é a solução para o seu problema. Você não pode estimar se não possui requisitos. Diga ao seu chefe que você precisará fazer isso antes de começar a codificar. Depois de algumas funções e módulos, você pode descobrir que todos eles foram consistentemente codificados (nesse caso, mal), para ter uma linha de base para determinar estimativas futuras. Apenas certifique-se de ajustar sua estimativa se descobrir que a codificação piora.

Sei que seu chefe quer uma estimativa, mas sem saber como essas informações estão sendo usadas, não sabemos quão exatas são suas estimativas. Converse com ele e descubra. Se ele apenas precisar de um número para fornecer a seu chefe, você pode aumentar um pouco as estimativas e fornecer um número. Para os clientes que esperam pagar pelo seu código até que isso seja feito, verifique se as datas de vencimento da linha direta gerarão uma receita significativa.

JeffO
fonte
Embora seja necessário um entendimento profundo para entender o código antigo, existe uma grande diferença entre documentar o código antigo e obter o código recém-escrito até o ponto em que não há bugs.
Thorbjørn Ravn Andersen
1

Em uma situação como essa, não acredito que seja possível fornecer boas estimativas. O problema básico é que muitas vezes uma grande parte disso é descobrir exatamente o que precisa ser feito.

Lido com casos como esse, fornecendo uma estimativa com base no que parece implicar, mas com o cavet de que surpresas são prováveis. Embora eu não tenha tido que lidar com muita coisa no código legado, tive algumas surpresas muito desagradáveis ​​ao lidar com informações - já vi algumas horas se transformarem em algumas semanas e uma vez isso é impossível (Depois escavação considerável, eu descobri que não tinha dados suficientes em um determinado caso, de volta à prancheta.) Felizmente, meu chefe entende quando eu dou essas estimativas.

Loren Pechtel
fonte
-1

Bem, estimar é uma habilidade que algumas pessoas nunca aprendem bem. Isso não o torna inútil como desenvolvedor, mesmo que você não consiga obter boas estimativas. Talvez os colegas de equipe ou a gerência preencham as lacunas. Eu sou péssimo nisso, ainda assim a maioria das equipes gostava de trabalhar comigo. Mantenha a calma, junte-se e continue refatorando.

A dívida técnica oferece bons e pequenos desafios, mas lembre-se de que uma empresa / equipe que acabou produzindo dívida continuará produzindo dívida, a menos que haja mudanças no espírito de equipe ou na gerência. O código está apenas refletindo os problemas sociais, portanto, foque nos problemas reais.

Usamos uma heurística para estimar recursos em um projeto brownfield: estimamos quanto tempo levaria para implementar esse recurso em um projeto greenfield sem nada já implementado. Em seguida, multiplicamos essa estimativa por 2 para lidar com a limpeza de detritos que já existiam.

Esse fator depende da quantidade de acoplamento e do tamanho geral do código, mas se você fizer alguns recursos dessa maneira, poderá interpolar esse fator com base em evidências reais.

peruca
fonte
-3

Acho que você deveria se sentar com seu chefe, olhá-lo diretamente nos olhos e dizer:

'Ouça chefe! Estamos apenas refatorando aqui. Não há novas funcionalidades a serem entregues e nenhum cliente espera por essa funcionalidade; portanto, não deve haver prazos. Isso vai levar o tempo que for preciso, você precisa decidir se temos que fazer isso ou não.

Use uma gesticulação firme e assertiva como apontar e sente-se à frente em sua cadeira.

Como alternativa, você pode inventar alguns números para fazê-lo feliz. Mas vamos ser sinceros, até que você esteja no meio do trabalho, suas estimativas serão bastante imprecisas.

Ewan
fonte
3
-1 por recomendar o que é potencialmente suicídio profissional. Além disso, o OP diz que está estimando o trabalho dos recursos, e não apenas refatorando o código existente.
11337 RubberDuck
suicídio carreira ou fazer o salto para o grande jogo
Ewan
Bem, esse é um ponto justo @Ewan. Não posso dizer que não fiz algumas coisas que pareciam suicídio profissional no momento.
11337 RubberDuck
Algumas coisas não podem ser estimadas. Comunicar isso pode ser frustrante. Dito isto, votei esta questão para baixo porque parece que você está sugerindo que o OP tente intimidar o chefe deles para que acredite neles. Eu sei que isso acontece, e talvez seja necessário em uma situação desesperada isolada. Mas não quero trabalhar em nenhum lugar que seja a norma. Temos divergências no trabalho e ficamos chateados. Mas lidamos com isso tentando convencer um ao outro com dados, estudos e histórias. É mais provável que uma empresa tenha sucesso com uma cultura de "a melhor idéia vence" do que "a pessoa mais intimidadora vence".
22417 GlenPeterson
1
é uma língua na resposta bochecha. mas eu falo sério. por que o chefe está pedindo estimativas? você está ajudando a situação estimando? está tudo muito bem este 'ler tio bob' 'usa as respostas de estilo da sequência de Fibonacci. mas eles não chegam à raiz do problema. o chefe está preocupado que este refactoring é um desperdício de tempo e quer que ele seja mais breve
Ewan