Cálculo da dívida técnica: baseado em velocidade vs. Com base em questões vs. Medições baseadas na qualidade explicadas

As taxas de juros aumentaram 157%!

Não, não estou falando sobre a última decisão do Fed, mas sobre a desaceleração que a Fictional Inc. enfrentou após lançar a versão 3.0 de sua plataforma.

Felizmente para eles, o lançamento do produto foi incrivelmente bem-sucedido e eles estão começando a ver o crescimento da receita aumentando rapidamente, mas agora precisam pensar em como vão lidar com a dívida técnica que introduziram como parte do lançamento.

A nova dívida de tecnologia que foi introduzida como parte de um novo lançamento pode ser considerada um aumento da taxa de juros e um aumento da desaceleração que a equipe enfrentará no futuro.

(Presumo que você esteja bastante familiarizado com o conceito de dívida técnica aqui, mas se precisar de uma atualização para se atualizar, aqui está um rápido primer )

Ok, você provavelmente não vai ouvir um gerente de engenharia falar assim sobre sua dívida técnica.

Mas porque não?

Ser capaz de medir e quantificar o impacto contínuo do seu dívida de tecnologia é crítica se você quiser montar um plano acionável para resolvê-lo.

Quando pensamos em dívida técnica, os juros são a quantidade de tempo perdida no desenvolvimento atual e futuro para seus níveis existentes de dívida técnica.

Isso significa que é a parte crítica da dívida a ser considerada ao pensar em decisões futuras para pagar o principal (o custo de reescrever, refatorar ou corrigir o código responsável pela dívida) - já que só a consideraremos se os juros é alto o suficiente.

O que é um nível saudável de dívida técnica?

A dívida técnica claramente retarda o novo desenvolvimento - mas isso por si só não significa que devemos consertar a dívida tecnológica em todos os lugares. Voltar para reescrever ou refatorar o código existente pode ser significativamente caro - portanto, só queremos pagar nosso principal da dívida técnica se nossos juros (o valor que está nos atrasando no futuro) excederem nosso principal.

Um problema óbvio surge imediatamente - o principal é uma unidade fixa de tempo (horas para consertar/reescrever), mas os juros são uma taxa de horas perdidas por hora. Para explicar isso, precisamos introduzir a ideia de um intervalo de impacto - o tempo durante o qual nos preocupamos se as desacelerações futuras da dívida técnica excedem o custo da reescrita. O intervalo de impacto com o qual você se preocupa dependerá fortemente de sua empresa, de seu processo de planejamento típico e de seu estágio ou ciclo de vida de sua base de código - mas, pessoalmente, normalmente analisarei um intervalo de impacto de 3 meses. Em nosso estágio inicial como empresa, olhar para qualquer coisa em escalas de tempo de um ano é muito amplo, mas qualquer coisa menor que 2 a 3 meses subestimará fortemente o impacto da dívida técnica, como veremos mais adiante.

Isso significa que não vale a pena abordar nosso nível de dívida de tecnologia se:

Por exemplo: se tivéssemos um pequeno projeto que sabíamos que tinha uma dívida de tecnologia que nos atrasava 2 horas/semana, levaríamos 4 dias para refatorar essa dívida e nos preocuparmos com um intervalo de impacto de 3 meses, então não teríamos gastar o tempo para pagar essa dívida ainda.

Agora, isso não responde ao nível do que é um nível saudável de dívida técnica - porque acho que todos podemos concordar que enfrentar grandes desacelerações na equipe não é saudável. Em vez disso, agora temos uma maneira rápida de determinar quando devemos ou não focar em reescrever e refatorar. Vamos dar uma olhada no que realmente é um nível saudável de dívida um pouco mais adiante neste artigo.

Como medimos a dívida técnica?

Determinar nossa taxa de juros de dívida de tecnologia exige que descubramos o quanto estamos sendo retardados por diferentes decisões que tomamos. Infelizmente, não há uma maneira óbvia ou trivial de rastrear o quanto seu desenvolvimento está sendo retardado - mas existem três abordagens diferentes que você pode adotar para obter boas aproximações.

Medição Baseada em Velocidade

A maneira mais direta de vincular lentidão a diferentes seções de nossa base de código é observar como a velocidade varia ao longo do tempo, em diferentes seções de seu projeto. Observando diferentes áreas da base de código, você pode começar a identificar variações (por exemplo, qualquer desenvolvimento que toque nesta seção de análise leva 3x mais tempo do que qualquer outra coisa) nas diferentes seções. Observar a variação de uma área ao longo do tempo também pode fornecer uma indicação de como o novo desenvolvimento afetou a taxa de desenvolvimento futuro e fornece uma indicação do nível de interesse com o qual sua equipe está lidando.

Por exemplo: se tivermos um projeto relativamente simples com 4 áreas diferentes nas quais trabalharemos, podemos observar como a velocidade muda com o tempo (aqui estamos rastreando a velocidade em pontos de história/mês do desenvolvedor).

Medição baseada na velocidade do impacto da dívida técnica

A partir daqui, podemos ver que D sempre levou aproximadamente 3x mais tempo para trabalhar do que qualquer outra área para tarefas igualmente complexas. Isso implica que ele tem 3x o interesse de todas as outras seções da base de código. B costumava estar relativamente no mesmo nível de A e C, mas a partir do mês 4, de repente, saltou para levar 2x mais tempo. Isso sugere que introduzimos alguma dívida aqui que dobrou nossa taxa de juros em relação ao que era antes para B.

Uma coisa a destacar é que não estamos falando sobre a taxa de juros para toda a base de código, mas sim para componentes/áreas individuais - isso porque as desacelerações introduzidas por acúmulos em dívida técnica geralmente não são problemas que afetam tudo o que fazemos, em vez disso, eles estão localizados em uma parte da base de código.

Existem algumas ressalvas importantes a serem consideradas quando se trata de medição baseada em velocidade.

• A velocidade pode ser volátil e pode depender de fatores independentes da dívida técnica, como bugs novos (ou existentes), estimativas desalinhadas, obstáculos técnicos ou atrasos externos no projeto.

• As estimativas têm um nível de incerteza inerente e podem ser uma medida imprecisa para começar.

• Coletar e analisar esses dados pode ser complicado e demorado.

  
  

Um proxy rápido para medição baseada em velocidade é pedir à sua equipe de engenharia para estimar relativamente quanto tempo leva para concluir um projeto/tarefa em cada área principal de sua base de código. Concorde com alguma linha de base estabelecida para uma área bem compreendida/usada com frequência e, em seguida, faça com que todos estimem a área uns dos outros como uma porcentagem ou múltiplo dessa linha de base. Embora não seja tão rigorosa quanto uma abordagem de medição baseada em velocidade total, ela pode dar uma ideia rápida de seus juros relativos à dívida de tecnologia com base no insight e na intuição de sua equipe.

Medição baseada em problemas

Uma abordagem diferente é identificar instâncias específicas de dívida técnica em seu projeto e estimar o quanto elas podem estar atrasando você. Parte disso pode ser feito usando ferramentas automatizadas, como ferramentas de análise estática, para encontrar problemas comuns em relação à qualidade do código que podem ter impactos na legibilidade, extensibilidade ou manutenção de um projeto. Para cada tipo de problema, você pode atribuir um custo de juros (por exemplo, 5 min/semana ou 1%) com base na experiência de sua equipe em lidar com esses tipos de problemas.

No entanto, isso capturará apenas um subconjunto de dívidas técnicas que causam problemas - outras serão mais sutis ou mais personalizadas para sua base de código e serão observadas apenas enquanto sua equipe estiver trabalhando ativamente nessa área do código. Nesse caso, você deseja registrar o problema específico (vinculado a uma área de sua base de código) junto com o impacto estimado que ele tem na desaceleração do desenvolvimento. Para rastrear esses problemas, recomendamos o uso de algum tipo de rastreador de problemas - seja em um backlog de problemas no GitHub, Jira etc. Tamanho do passo .

Algumas das desvantagens dessa abordagem são:

• As estimativas de tempo vinculadas a problemas específicos podem ser imprecisas
• Alguns problemas podem facilmente passar despercebidos por um longo período de tempo

Medição Baseada na Qualidade

Há uma variedade de métricas de qualidade de código que você pode usar para obter uma noção geral do status de sua base de código e, por sua vez, obter uma estimativa de quanta dívida técnica você tem atualmente impactando o desenvolvimento futuro em cada área. Na Sourcery, tendemos a olhar para Complexidade , Memória de trabalho , e Method Length como as métricas críticas ao olhar dentro de uma função ou classe - mas você também pode olhar para coisas como Índice de Manutenibilidade, Doc & Test Coverage, Duplication Rate e muitos outros.

Semelhante à abordagem baseada em problemas, você pode atribuir um impacto relativo de diferentes pontuações (ou de uma pontuação geral de qualidade ou integridade) à desaceleração contínua e futura no desenvolvimento devido a dívida técnica. A pesquisa mostrou uma forte correlação negativa entre coisas como Complexidade e Velocidade, bem como com qualidade de código e risco de bug, carga de manutenção e muito mais.

Olhando para um exemplo - vamos revisitar a base de código simples de 4 partes que vimos na seção sobre medição baseada em velocidade.

Podemos ver facilmente as seções problemáticas deste projeto na tabela (destacadas em vermelho) e calcular a estimativa de juros é relativamente simples - basta somar os impactos de juros dos diferentes componentes.

Algumas das desvantagens dessa abordagem são:

• Você precisa definir estimativas de impacto de interesse em diferentes métricas de qualidade (estou procurando reunir algumas como uma linha de base, mas será bastante dependente da base de código). Para fazer isso, você provavelmente vai querer olhar para alguma medição baseada em velocidade e associá-la à qualidade.
• As próprias métricas de qualidade são imperfeitas e podem variam significativamente de idioma para idioma .

Essa abordagem de medição baseada na qualidade é a menos precisa das três abordagens que examinamos - mas é muito eficaz em fornecer uma visão holística de diferentes áreas do seu projeto ao longo do tempo. Você pode combinar essa abordagem com a abordagem baseada em problemas que acabamos de discutir para equilibrar o rastreamento de problemas específicos com o rastreamento de problemas gerais de qualidade e saúde em cada seção do seu projeto.

Observando a frequência de interação da base de código

Para todas essas três abordagens, precisamos ter uma maneira de mapear o impacto em diferentes seções de nossa base de código em relação à frequência com que realmente tocamos essa seção da base de código. Se há uma seção de nosso projeto que é um pesadelo de se lidar, mas que ninguém mais toca, isso não está realmente impactando fortemente nossa dívida técnica contínua. Por outro lado, uma desaceleração pequena, mas persistente, em uma seção da base de código para a qual contribuímos todos os dias pode resultar em grandes perdas de tempo muito rapidamente.

Para contabilizar isso, precisaremos ver com que frequência cada área do nosso projeto é contribuída. Existem algumas abordagens diferentes que podemos adotar aqui - olhando para o histórico do Git para entender qual área é amplamente tocada com mais frequência, usando ferramentas mais focadas como Codescene para obter dados históricos de contribuição mais digeríveis ou usar uma abordagem voltada para o futuro, observando nossos planos e prioridades futuros para entender onde nossa equipe passará a maior parte do tempo nos próximos meses.

Independentemente de como obtemos os dados - podemos obter uma análise de qual porcentagem de nosso tempo gastaremos interagindo com cada seção de nossa base de código. Combinando isso com a contribuição de juros que já determinamos, agora podemos ver exatamente o quanto esperamos diminuir ao lidar com cada seção de nossa base de código no futuro.

Continuando com nosso exemplo anterior - se tivéssemos uma visão voltada para o futuro e novos todos os projetos nos quais trabalharíamos nos próximos 3 meses e pudéssemos estimar com confiança que essa foi a quantidade de tempo gasto em cada área da base de código ( lembre-se que este é um projeto muito simples):

Agora podemos vincular isso às estimativas de juros que tínhamos de nossa abordagem baseada em velocidade e nossa abordagem baseada em métrica de qualidade e ter uma boa ideia de onde estamos sendo mais lentos.

Aqui estamos usando as desacelerações na velocidade que vimos para o trabalho nas seções B e C de quando analisamos a medição baseada em velocidade anteriormente e estamos usando isso para calcular quanto tempo perdido esperamos devido a dívidas de tecnologia nos próximos três meses. No geral, esperamos ver mais de 28 meses de desenvolvimento de esforço extra a serem gastos apenas na dívida. Uma coisa importante a considerar a partir desta abordagem é que tudo isso está olhando para a velocidade relativa - então os projetos de linha de base são tratados como tendo efetivamente nenhuma dívida, o que normalmente não é preciso. O outro problema com essa abordagem é que ela não leva em conta as variações nos níveis de endividamento futuros - que provavelmente ocorrerão. Mas eles são difíceis de prever, então é mais fácil ignorá-los.

Aqui, pegamos nossos atrasos típicos projetados com base na qualidade do código de cada seção e projetamos isso nos próximos três meses. Em geral, vemos projeções de impacto da dívida significativamente menores do que quando usamos o método de velocidade. Isso ocorre porque as estimativas de desaceleração com base na dívida de tecnologia são menores do que o que vimos no caso de velocidade - talvez seja necessário fazer mais calibração neste caso! Assim como com a métrica baseada em velocidade, isso não leva em consideração mudanças futuras na dívida de tecnologia - mas ambas as estimativas podem nos ajudar a determinar como devemos priorizar a reescrita e refatoração das diferentes seções de nosso projeto.

Gerenciando Juros e Dívidas

Analisamos algumas maneiras diferentes de contabilizar o quanto nossa dívida técnica está nos impactando continuamente, mas não respondemos totalmente à pergunta sobre o que é um nível saudável de dívida técnica.

Infelizmente, não há realmente um número preciso. No curto prazo, aceitar alguma dívida pode ser pragmático. Mas, no longo prazo, queremos manter nossa dívida próxima de zero. Porque o interesse persistente vai se mostrar muito caro e a dívida de tecnologia continua se acumulando. Mas não queremos gastar todo o nosso tempo refatorando e reescrevendo problemas que nos dão apenas ganhos marginais.

Como discutimos anteriormente, geralmente não queremos gastar tempo abordando áreas da base de código onde:

Mas, no caso extremo disso, podemos acabar com um caso em que estamos massivamente desacelerados por um alto nível de dívida que é extremamente caro para consertar - o que também não é uma boa situação.

A melhor abordagem é cair em algum lugar no meio. Reserve um tempo em seu planejamento contínuo para resolver problemas de dívida técnica e refatorar o código existente - priorizando o que é atualmente o mais caro para você. E continue a empurrar isso até ver retornos decrescentes significativos ao reduzir sua dívida.