Technical Debt: como estimar e priorizar
Todo time de desenvolvimento lida com dívida técnica. O problema não é tê-la — é não gerenciá-la. Ignorar dívida técnica é como ignorar juros de cartão de crédito: a conta chega, e com multas.
O que é dívida técnica
Dívida técnica é o custo adicional futuro causado por escolhas de implementação subótimas no presente. Inclui:
- Código sem testes
- Arquitetura que não escala
- Dependências desatualizadas
- Falta de documentação
- Code reviews superficiais
- Duplicação de código
Como estimar dívida técnica
Dívida conhecida
Items específicos de refatoração são estimados normalmente com Planning Poker:
- “Refatorar módulo de autenticação para usar OAuth2” → 8 pontos
- “Adicionar testes ao serviço de pagamento (cobertura atual: 12%)” → 13 pontos
Dívida invisível
O custo da dívida que ninguém catalogou é estimado pelo impacto na velocidade:
“Nos últimos 3 sprints, 30% do tempo foi gasto com bugs no módulo legado. Isso equivale a ~8 pontos/sprint em retrabalho.”
Custo do atraso
“Se não refatorarmos agora, cada nova feature nesse módulo levará 40% mais tempo. Em 6 sprints, o custo adicional será de ~48 pontos.”
Como priorizar
Regra do 20%
Reserve 20% da capacidade de cada sprint para dívida técnica. Isso é suficiente para evitar que cresça sem sacrificar entregas de valor.
Quadrante de urgência
| Impacto alto | Impacto baixo | |
|---|---|---|
| Risco alto | FAÇA AGORA | PLANEJE |
| Risco baixo | MONITORE | ACEITE |
Dívida como bloquedor
Se a dívida técnica impede uma feature de alto valor, ela automaticamente ganha prioridade. Exemplo: “Não conseguimos adicionar 2FA porque a autenticação é toda hardcoded.”
Como comunicar para stakeholders
Traduza para impacto de negócio
Não diga: “Precisamos refatorar o código do checkout.” Diga: “O código atual do checkout causa 30% dos bugs reportados. Refatorar vai reduzir bugs em ~15 por mês e acelerar novas features de pagamento em 40%.”
Use analogias
“Assim como um carro precisa de manutenção preventiva, nosso código precisa de refatoração. Rodar com pneu careca funciona até o dia que não funciona mais.”
Mostre a tendência
Um gráfico mostrando o aumento de bugs ou tempo de desenvolvimento ao longo do tempo é mais convincente que qualquer argumento técnico.
Estratégias de pagamento
Boy Scout Rule
“Deixe o código mais limpo do que encontrou.” Pequenas melhorias a cada PR acumulam significativamente.
Sprints de hardening
A cada 3-4 sprints, dedique um sprint inteiro para qualidade. Funciona, mas é difícil de vender.
Refatoração contínua (recomendada)
Inclua refatoração como parte das histórias normais. Se vai trabalhar em um módulo, melhore-o. Estimativa da história já inclui a melhoria.
Katas técnicos
Sessões de 1-2 horas semanais onde o time melhora voluntariamente partes do código. Bom para moral e para código.
Métricas de dívida técnica
- Cobertura de testes — porcentagem do código testada
- Duplicação de código — % de código duplicado (SonarQube)
- Tempo de build — quanto demora o CI/CD
- Bug rate — bugs por sprint por módulo
- Lead time — tempo médio de entrega (aumenta com dívida alta)
Conclusão
Dívida técnica não é opcional — você a tem de qualquer forma. A escolha é entre dívida controlada (com plano de pagamento) e dívida descontrolada (que um dia paralisa o time). Reserve 20% do sprint, comunique em termos de negócio e trate qualidade como feature, não como luxo.