Avaliação de dívida técnica para equipes de engenharia

Avalie onde a dívida técnica atrasa sua equipe e se vocês estão conseguindo quitá-la.

Experimente esta avaliação de saúde ao vivo

O que uma avaliação de dívida técnica mede?

Ward Cunningham criou a metáfora da dívida técnica no seu relatório de experiência apresentado na OOPSLA em 1992, onde escreveu que "entregar código pela primeira vez é como contrair uma dívida". Um pouco de dívida pode acelerar o trabalho. O problema começa quando ela não é paga, e cada hora gasta contornando código que não está bem certo vira juros. Ferramentas de análise medem o código. Esta avaliação mede aquilo com que a equipe convive: se vocês conseguem enxergar a dívida, o quanto ela atrasa as entregas, como estão a saúde do código e dos sistemas e se vocês estão quitando essa dívida. Cada pessoa avalia as afirmações individualmente. Depois, vocês levam as notas mais baixas para uma retrospectiva e decidem juntos o que corrigir primeiro.

Dimensões

Visibilidade

Se a equipe sabe onde está a sua dívida e a trata como trabalho de verdade.

  • Pontos críticos conhecidos

    Sabemos quais partes do nosso sistema concentram mais dívida.

  • Registrada com o restante do trabalho

    A dívida é registrada no mesmo backlog que as funcionalidades e os bugs.

  • Custo conhecido

    Conseguimos explicar quanto nossas maiores dívidas nos custam em tempo ou em risco.

Impacto nas entregas

O quanto a dívida atrasa o trabalho que a equipe está tentando entregar.

  • Velocidade das funcionalidades

    A dívida raramente atrasa as funcionalidades que estamos desenvolvendo.

  • Mudanças seguras

    Alterar uma parte do nosso sistema raramente quebra outra parte sem relação.

  • Builds rápidos e confiáveis

    Nossos builds e testes são rápidos e confiáveis.

Saúde do código e dos sistemas

O quanto é fácil trabalhar hoje com o código, os sistemas e as dependências.

  • Fácil de alterar

    A maior parte do nosso código é fácil de entender e de alterar.

  • Dependências atualizadas

    Nossas dependências e plataformas estão razoavelmente atualizadas.

  • Testes que permitem refatorar

    Nossos testes nos dão confiança para refatorar.

Quitação da dívida

Se a equipe avança de forma constante e combinada na redução da dívida.

  • Tempo reservado

    Reservamos tempo regularmente para quitar dívida.

  • Dívida intencional registrada

    Quando assumimos uma dívida de propósito, nós a registramos com um plano para quitá-la.

  • Prioridades compartilhadas

    Produto e engenharia estão de acordo sobre como dividir o tempo entre funcionalidades e dívida.

Quando utilizar essa avaliação de saúde

  • Quando as funcionalidades demoram mais do que deveriam e a equipe sempre aponta para o código.
  • Antes do planejamento trimestral ou do roadmap, para combinar quanto tempo será dedicado a quitar dívida.
  • Depois de um grande esforço ou de um prazo apertado, para registrar os atalhos tomados antes que sejam esquecidos.

Dicas e truques

  • Comece pelo grupo com a nota mais baixa. Pouca visibilidade significa que vocês precisam de uma lista de dívidas antes de qualquer outra coisa. Muita visibilidade com pouca quitação indica um problema de planejamento, não de código.
  • Traga o gerente de produto para a discussão, mesmo que só os engenheiros façam a avaliação. A divisão do tempo entre funcionalidades e dívida é uma decisão compartilhada.
  • Combine as notas com dados que vocês já têm, como tempo de build, quantidade de testes instáveis ou causas de incidentes. A avaliação mostra onde dói; os dados mostram quanto.
  • Aplique junto com a Autoavaliação de Métricas DORA, a Avaliação de Maturidade DevOps ou o Modelo de Maturidade de Excelência em Engenharia para ver como a dívida se relaciona com as entregas e as práticas de engenharia.
  • Repita a cada trimestre. Uma nota em alta nas afirmações sobre quitação da dívida é o primeiro sinal de que o plano está funcionando.

Perguntas frequentes

Como medir a dívida técnica?
Não existe um número único. As equipes combinam métricas de código, como complexidade, rotatividade de alterações e cobertura de testes, com sinais de entrega, como tempo de build, mudanças com falha e tempo de desenvolvimento das funcionalidades. Uma avaliação em equipe como esta acrescenta o que as ferramentas não captam: onde a dívida realmente atrasa as pessoas. Acompanhe as mesmas medidas ao longo do tempo em vez de buscar um número perfeito.
Quais são os quatro tipos de dívida técnica?
A classificação mais conhecida é o quadrante da dívida técnica de Martin Fowler. Ele classifica a dívida a partir de duas perguntas: ela foi assumida de forma intencional ou inadvertida, e a escolha foi prudente ou imprudente? A dívida prudente e intencional é uma troca consciente com um plano para quitá-la, enquanto a dívida imprudente costuma se acumular sem que ninguém perceba.
Quanto tempo devemos dedicar à dívida técnica?
Não há uma resposta padrão. Algumas equipes reservam uma parte fixa de cada sprint, outras agendam trabalhos regulares de limpeza e outras corrigem a dívida no código que já estão alterando. Escolha uma quantidade, deixe-a visível no planejamento e aplique esta avaliação a cada trimestre para verificar se é suficiente.
Como explicar a dívida técnica para gerentes de produto?
Fale dos juros, não do código. Mostre como a dívida atrasa funcionalidades específicas, causa incidentes ou torna as estimativas menos confiáveis, e o que a correção liberaria. Aplicar esta avaliação com o produto presente ajuda, porque os dois lados veem as mesmas notas e podem decidir juntos o que corrigir primeiro.
Qual é um exemplo de dívida técnica?
Uma equipe copia um módulo para cumprir um prazo e planeja unificar as cópias depois. Meses mais tarde, cada correção precisa ser feita duas vezes e as cópias já divergiram. Outros exemplos comuns são dependências desatualizadas, falta de testes em código crítico e um build lento que todo mundo contorna.
Quem criou o termo dívida técnica?
Ward Cunningham apresentou a metáfora em 1992, em um relatório de experiência da OOPSLA sobre o sistema de gestão de carteiras WyCash. Ele escreveu que "entregar código pela primeira vez é como contrair uma dívida" e que o perigo surge quando a dívida não é paga. A TeamRetro não tem vínculo com Ward Cunningham.

Based on Ward Cunningham, 'The WyCash Portfolio Management System,' OOPSLA '92 Experience Report (1992).

Exames médicos relacionados