Como você estima um ROI para limpar a dívida técnica?

Question

Atualmente, estou trabalhando com um produto bastante antigo que foi sobrecarregado com muita dívida técnica de programadores ruins e práticas de desenvolvimento inadequadas no passado. Estamos começando a melhorar e a criação da dívida técnica diminuiu consideravelmente.

Identifiquei as áreas do aplicativo que estão em mau estado e posso estimar o custo de fixação dessas áreas, mas estou tendo dificuldade em estimar o retorno do investimento (ROI).

O código será mais fácil de manter e será mais fácil de estender no futuro, mas como posso colocar um valor em dólares neles?

Um bom lugar para começar parece voltar ao nosso sistema de rastreamento de bugs e estimar custos com base em bugs e recursos relacionados a essas áreas "ruins". Mas isso parece demorado e pode não ser o melhor preditor de valor.

Alguém realizou essa análise no passado e tem algum conselho para mim?

Answer 1

Os gerentes se preocupam em ganhar $ através do crescimento (em primeiro lugar, por exemplo, novos recursos que atraem novos clientes) e (segundo) através da otimização do ciclo de vida do processo.

Olhando para o seu problema, sua proposta se enquadra na segunda categoria: isso sem dúvida ficará atrás do gol nº 1 (e, assim, será priorizado para baixo até Se isso pudesse economizar dinheiro ... porque economizar dinheiro implica Gastar dinheiro (pelo menos na maioria das vezes ;-)).

Agora, colocando um valor de $ na "dívida técnica ruim" pode ser transformada em um giro mais positivo (assumindo que o seguinte se aplique no seu caso): "Se investirmos no componente X, poderíamos introduzir o recurso Y mais rápido e, assim, obtermos Z mais clientes ".

Em outras palavras, Avalie o custo da dívida técnica em relação ao custo das oportunidades de negócios perdidas.

Answer 2

Sonar tem um ótimo plugin (plugin de dívida técnica) para analisar seu focecode para procurar exatamente essa métrica. Embora você não consiga usá -lo especificamente para sua compilação, pois é uma ferramenta do Maven, ele deve fornecer algumas boas métricas.

Aqui está um trecho de seu algoritmo:

Debt(in man days) =
    cost_to_fix_duplications +
    cost_to_fix_violations + 
    cost_to_comment_public_API +
    cost_to_fix_uncovered_complexity + 
    cost_to_bring_complexity_below_threshold


 Where :

 Duplications = cost_to_fix_one_block * duplicated_blocks

 Violations   = cost_to fix_one_violation * mandatory_violations

 Comments     = cost_to_comment_one_API * public_undocumented_api

 Coverage     = cost_to_cover_one_of_complexity * 
                         uncovered_complexity_by_tests (80% of
                         coverage is the objective)

 Complexity   = cost_to_split_a_method *
                         (function_complexity_distribution >=
                          8) + cost_to_split_a_class *
                         (class_complexity_distribution >= 60)

Answer 3

Eu acho que você está no caminho certo.

Eu não tive que calcular isso, mas tive algumas discussões com um amigo que gerencia uma grande organização de desenvolvimento de software com muito código legado.

Uma das coisas que discutimos é gerar algumas métricas difíceis de esforço ao analisar os VCs se comprometer e usá -las para dividir uma estimativa aproximada das horas do programador. Isso foi inspirado no Joel Spolsky's Programação baseada em evidências.

Fazer essa mineração de dados permitiria que você também identificasse o cluster de quando o código está sendo mantido e compare isso para a conclusão de bugs no sistema de rastreamento (a menos que você já seja abençoado com uma integração rígida entre os dois e registros precisos).

O ROI adequado precisa calcular o retorno total, portanto, algumas coisas a considerar são: - Diminuição do custo de manutenção (obviamente) - custo de oportunidade para os negócios de tempo de inatividade ou novos recursos perdidos que não puderam ser adicionados a tempo de lançamento - capacidade de gerar novas linhas de produtos devido a refatorings

Lembre -se, depois de ter uma regra para derivar dados, você pode ter argumentos sobre exatamente Como as para calcular as coisas, mas pelo menos você tem algum Figuras para a discussão das sementes!

Answer 4

+1 para o foco da JLDupont em oportunidades de negócios perdidas.

Sugiro pensar nessas oportunidades percebidas pela administração. O que eles acham que afeta o crescimento da receita - novos recursos, tempo para mercado, qualidade do produto? Relacionar o pagamento da dívida a esses motoristas ajudará a gerenciamento a entender os ganhos.

O foco nas percepções de gerenciamento ajudará você a evitar a falsa numeração. O ROI é uma estimativa e não é melhor do que as suposições feitas em sua estimativa. A gerência suspeitará de argumentos quantitativos apenas porque eles sabem que há alguma qualitativa lá em algum lugar. Por exemplo, a curto prazo, o custo real do pagamento da dívida é o outro trabalho que os programadores não estão realizando, em vez do custo de caixa desses programadores, porque duvido que você contrate e treine nova equipe apenas para isso . As melhorias no tempo ou qualidade futuras de desenvolvimento são mais importantes do que os recursos que esses programadores estariam adicionando?

Além disso, certifique -se de entender o horizonte para o qual o produto é gerenciado. Se a gerência não estiver pensando em dois anos daqui a dois anos, eles não se importarão com benefícios que não aparecerão por 18 meses.

Por fim, reflita sobre o fato de que as percepções da administração permitiram que este produto chegasse a esse estado em primeiro lugar. O que mudou que tornaria a empresa mais atenta à dívida técnica? Se a diferença for vocês - Você é um gerente melhor do que seus antecessores- lembre-se de que sua equipe de gerenciamento não está acostumada a pensar sobre essas coisas. Você precisa encontrar o apetite deles e se concentrar nos itens que fornecerão resultados com os quais se importam. Se você fizer isso, ganhará credibilidade, que poderá usar para que eles pensem em mais mudanças. Mas a apreciação dos ganhos pode demorar um pouco.

Answer 5

Só posso falar sobre como fazer isso empiricamente em um processo iterativo e incremental.

Você precisa reunir métricas para estimar o seu melhor custo/ponto de história demonstrado. Presumivelmente, isso representa seu sistema logo após a rotatividade inicial da arquitetura, quando a maioria dos testes de design e erro foi feita, mas a entropia teve o menor tempo para causar decomposição. Encontre o ponto no histórico do projeto em que o Velocity/Team-Size é o mais alto. Use isso como sua linha de base de custo/ponto (zero-dívida).

Com o tempo, à medida que a dívida técnica se acumula, o tamanho da velocidade/equipe começa a diminuir. A diminuição percentual desse número em relação à sua linha de base pode ser traduzida para o "interesse" sendo pago em cada novo ponto da história. (Isso é realmente juros pagos sobre técnicos e dívida de conhecimento)

O refactamento e o recozimento Pense nisso como o interesse em estado estacionário que o proprietário do produto paga pela dívida técnica no sistema. (O mesmo conceito se aplica à dívida do conhecimento).

Alguns sistemas atingem o ponto em que o custo + juros em cada novo ponto da história excede o valor do ponto de característica que está sendo desenvolvido. É quando o sistema está falido e é hora de reescrever o sistema do zero.

Eu acho que é possível usar a análise de regressão para separar a dívida técnica e a dívida de conhecimento (mas não tentei). Por exemplo, se você assumir que a dívida técnica se correlaciona estreitamente com algumas métricas de código, por exemplo, a duplicação do código, poderá determinar o grau que os juros pagos estão aumentando devido à dívida técnica versus dívida do conhecimento.

Answer 6

Sendo um desenvolvedor mais solitário ou pequeno, isso está fora do meu campo, mas para mim uma ótima solução para descobrir onde é desperdiçado o tempo é muito, muito detalhado, por exemplo, com uma ferramenta útil da barra de tarefas como Este Isso pode até filtrar quando você vai ao LOO e pode exportar tudo para o XML.

Pode ser complicado no começo e um desafio a se apresentar a uma equipe, mas se sua equipe puder registrar a cada quinze minutos que gastam devido a um bug, erro ou equívoco no software, você acumula uma base de dados impressionantes da vida real sobre o que a dívida técnica está realmente custando nos salários todos os meses.

A ferramenta a que vinculei é a minha favorita porque é simples (nem exige uma base de dados) e fornece acesso a todos os projetos/item por meio de um ícone da barra de tarefas. Também inserir informações adicionais sobre o trabalho realizado podem ser feitas lá, e a cronometragem é literalmente ativada em segundos. (Eu não sou afiliado ao fornecedor.)

Answer 7

Pode ser mais fácil estimar a quantidade que custou no passado. Depois de fazer isso, você poderá encontrar uma estimativa para o futuro com intervalos e lógica, mesmo seus chefes podem entender.

Dito isto, não tenho muita experiência com esse tipo de coisa, simplesmente porque ainda nunca vi um gerente disposto a ir tão longe para consertar o código. Sempre foi algo que corrigimos quando precisamos modificar o código ruim; portanto, a refatoração é efetivamente um custo oculto em todas as modificações e correções de bugs.