Estimativa dos 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 estava sendo migrado para a arquitetura baseada em microsserviço.

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

Agora meu chefe está (corretamente) me pedindo para estimar quanto tempo levaria para escrever o recurso X na nova arquitetura. Mas estou tendo dificuldades para chegar a uma estimativa realista; muitas vezes eu imenso subestimo a tarefa devido a razões que mencionei acima e me envergonho porque não posso terminar a tempo.

A coisa sensata pode parecer realmente entrar no código, anotar cada ramificação e ligar para outras funções e depois estimar o custo do tempo. Mas existe 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 compreenda perfeitamente como funciona a refatoração de código legado, minha pergunta não é sobre "como refatorar / reescrever?" mas sobre dar uma resposta realista para "quanto tempo levaria para refatorar / reescrever a parte X?"

    
por JuniorDev 13.02.2017 / 09:17
fonte

9 respostas

110

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.

    
por 13.02.2017 / 10:32
fonte
30

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.

    
por 13.02.2017 / 10:00
fonte
14

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.

    
por 13.02.2017 / 11:44
fonte
7

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.

    
por 14.02.2017 / 00:40
fonte
3

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.

Se eu tiver um chefe que não se sente à vontade para receber um intervalo que seja atualizado à medida que eu for, darei a ele um único número e minha metodologia. Minha metodologia é uma combinação de uma regra geral que me foi contada como um jovem desenvolvedor e a lei de Hofstader .

Estimate how long you think the task should take, then quadruple that number and give that as your estimate.

and

Hofstadter's Law: "It always takes longer than you expect, even when you take into account Hofstadter's Law."

    
por 14.02.2017 / 00:22
fonte
2

The sensible thing might seem to really get into the code, note every branch and calls to other functions and then estimate the time cost. But there is really a minuscule difference between documenting the old code and actually writing down the new version.

Esta é a solução para o seu problema. Você não pode estimar se você não tem 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 foram consistentemente codificados (neste caso, mal), então você tem uma linha de base para determinar estimativas futuras. Apenas certifique-se de ajustar sua estimativa se descobrir que o código piora.

Sei que seu chefe quer uma estimativa, mas sem saber como essa informação está sendo usada, não sabemos com que exatidão suas estimativas precisam ser. Tenha uma conversa com ele e descubra. Se ele precisar apenas de um número para dar ao seu chefe, você pode aumentar um pouco as estimativas e fornecer um número. Para os clientes que estão aguardando para pagar pelo seu código até que isso seja feito, verifique se as datas de vencimento da linha de vendas estão gerando receita significativa.

    
por 13.02.2017 / 17:01
fonte
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 de fazer isso é descobrir exatamente o que precisa ser feito.

Eu lidei com casos como este, dando uma estimativa com base no que parece implicar, mas com o cavet que surpresas são prováveis. Enquanto eu não tive que lidar muito com o código legado, eu tive algumas surpresas muito desagradáveis lidando com a entrada - eu vi algumas horas se transformarem em algumas semanas e uma vez isso é impossível (After escavação considerável, descobri que não tinha dados suficientes em um determinado caso, de volta à prancheta.) Felizmente, meu chefe entende quando eu forneço essas estimativas.

    
por 14.02.2017 / 01:52
fonte
-1

Bem, a estimativa é uma habilidade que algumas pessoas nunca aprendem bem. Ele não o torna inútil como desenvolvedor, mesmo que você não consiga obter boas estimativas. Talvez os companheiros de equipe ou a gerência preencham as lacunas. Eu sou terrível nisso, a maioria das equipes gostava de trabalhar comigo. Mantenha a calma, junte-se à equipe e continue com a refatoração.

A dívida técnica oferece bons 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 administração. O código está apenas espelhando os problemas sociais, então foque nos problemas reais.

Usamos uma heurística para estimar recursos em um projeto brownfield: estimamos quanto tempo teria sido para implementar esse recurso em um projeto greenfield sem qualquer coisa já implementado. Então 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 na evidência real.

    
por 13.02.2017 / 16:54
fonte
-3

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

'Listen boss! We are just refactoring here. There is no new functionality to deliver, and no customers waiting for that functionality; so there shouldnt be any deadlines. This is going to take as long as it takes, you need to decide whether we have to do it or not.'

Use uma firme gesticulação assertiva, como apontar e sentar-se na cadeira.

Alternativamente, você poderia inventar alguns números para fazê-lo feliz. Mas vamos encarar isso, até que você esteja na metade do trabalho, suas estimativas serão bem imprecisas.

    
por 13.02.2017 / 10:27
fonte