Calcular custos de código incorreto

Estou procurando argumentos para convencer a gerência a investir esforços na refatoração.

Registramos o trabalho usando o Jira e relacionamos cada svn-commit a uma chamada do jira.

Minha ideia é fazer o seguinte:

• localize manualmente uma área de código que é extremamente ruim implementada, mas frequentemente usada: tanto no User-POV quanto no Developer-POV (correções de bugs)
• obtenha os svn-commits que contêm os problemas do JIRA
• filtrar os problemas de acordo com alguns critérios (tipo de problema, versão, preço, etc ...)
• calcular o tempo / esforço gasto nesses bugs
• estimar esforços e riscos de refatoração
• apresente os números e peça um esforço para corrigi-lo.

O que você acha disso? Essa medida seria útil e / ou convincente? Quais são os prós e contras?

Descobri que, se você pode fornecer números válidos, é mais provável que os gerentes ajam. (Se eles puderem entender a lógica e o custo / benefício.)

IMHO, para fazer um caso convincente, você precisaria do seguinte para mostrar o quão ruim é:

• número de incidentes de suporte registrados para os problemas
• tempo gasto em horas mantendo / mau código de auxílio à banda / fazendo correções de suporte
• custo de tempo com base na taxa horária de pessoas que fazem os serviços de manutenção / banda / suporte
• alguma maneira de demonstrar como esses itens são críticos para a empresa

E para defender a refatoração, você precisará:

• estimativa de tempo para refatorar e implementar cada uma das 3 principais coisas ruins
• estimativa de custo para implementação (mesmas taxas horárias usadas acima)

Com isso, você poderá economizar tempo se a refatoração demorar muito menos do que o tempo de suporte para três incidentes para cada um desses três itens principais. Você pode argumentar que esse menor tempo gasto será

• ser menor que n mais incidentes de suporte
• não haverá mais nenhum desses incidentes para essas coisas (MESMO MELHOR!)

No entanto, a parte mais difícil dessa venda será responder à seguinte pergunta, já que muitas pessoas não reservam tempo nas agendas para todo o suporte que você está prestando:

Quanto tempo terei que esperar o projeto Y atual ser concluído enquanto você estiver gastando tempo trabalhando nesses problemas com o X ????? (apesar dos tempos atuais de suporte, que não podem ser previstos e agendados nos gráficos de Gantt)

Isso depende muito de como você se comunica com os tomadores de decisão e como eles entendem a situação.

DEFINITIVAMENTE, acho que vale a pena fazer, assim você adquire a prática de construir o caso com as métricas e economizar tempo, mesmo que não o façam. Infelizmente, nem todo mundo é fácil de convencer, apesar dos dados. BOA SORTE!

Lembre-se de que a refatoração também apresenta bugs (que você detectará em seus testes, mas ainda assim são bugs e devem ser corrigidos). Não puxe um Netscape por acidente. Depende da sua definição pessoal de "refatoração". Para alguns, isso significa "reescrever todo o código" para outros, significa "alterar alguns elementos internos". Como você diz que tipo você é? Faça a si mesmo a seguinte pergunta:

Estou mudando a interface pública?

Se a resposta for sim, você está fazendo um novo design. Se a resposta for não, você está refatorando e provavelmente pode fazê-lo ao longo de suas atividades diárias sem aprovação especial. Isso é relevante para sua pergunta, porque um novo design gera muito mais erros, enquanto uma refatoração é geralmente mais fácil de executar (já que seus testes já exercitam a interface pública e não precisam ser modificados).

É um caso difícil de entender, porque ninguém sabe quanto X custaria com ou sem o refatorador que foi feito há um ano. Na minha experiência, os gerentes pragmáticos sempre derrubam esse tipo de coisa porque:

1. Nenhum fluxo de receita direta vem do esforço (custo financeiro, não faturável)
2. Código de trabalho feio ainda está funcionando, você corre o risco de criar problemas em vez de corrigi-los (custo potencial de qualidade)
3. Outros projetos serão adiados enquanto você refatorar (custo do tempo)

Todos esses números são, em última análise com base em suposições, no seu caso comparando a quantidade que você acho que custaria não refatorar vs. o que você acho que custaria para refatorar. O melhor que você pode fazer é mostrar que tem algum tipo de base numérica e factual para as suposições, e você tem uma boa.

Os profissionais são que provavelmente será eficaz em convencê-los a refatorar, e isso pode funcionar bem e reduzir o número de bugs.

Os contras são que, se o tempo gasto na correção de bugs não cair pelo menos tanto quanto o tempo gasto na refatoração, você provavelmente não poderá refatorar mais e provavelmente será responsabilizado pelo tempo "desperdiçado" .

A economia de tempo de depuração obtida pela redução da complexidade do projeto geral ou por facilitar a adição de recursos pode ser muito difícil de medir para ajudar muito, mas você pode mencionar que eles existem.