Gerenciamento Efetivo de Dívida Técnica

Dívida técnica é inevitável—a questão é se você a gerencia ou deixa ela gerenciar você. Dívida não rastreada se compound silenciosamente até desenvolvimento parar completamente. Gerenciamento efetivo significa tornar dívida visível, priorizar estrategicamente e alocar esforço consistente para reduzi-la.

Tipos Dívida Técnica

Tornando Dívida Visível

Rastreando Dívida Técnica

INVENTÁRIO DÍVIDA TÉCNICA
═════════════════════════

RASTREAMENTO DÍVIDA GITSCRUM:
├── Criar label "Technical Debt"
├── Marcar todos itens dívida consistentemente
├── Usar filtro board para visão dívida
├── Rastrear em coluna dedicada ou backlog

TEMPLATE ITEM DÍVIDA:
─────────────────────────────────────
Título: [Descrição clara dívida]
Tipo: [Intencional/Não intencional/Desatualizado]
Localização: [Arquivos/serviços afetados]
Impacto: [Como afeta desenvolvimento]
Risco: [O que poderia dar errado]
Esforço: [Estimativa S/M/L]
Gatilho: [Quando devemos consertar]
─────────────────────────────────────

EXEMPLO:
─────────────────────────────────────
Título: Módulo auth não tem testes
Tipo: Não intencional (cresceu sem TDD)
Localização: /src/auth/*
Impacto: Alto - Mudanças são arriscadas, revisões lentas
Risco: Bugs auth chegam produção
Esforço: L (estimado 2 semanas)
Gatilho: Antes qualquer mudança auth
─────────────────────────────────────

Dashboard Dívida

DASHBOARD DÍVIDA TÉCNICA
════════════════════════

┌─────────────────────────────────────────────────────────┐
│  Visão Geral Dívida Técnica                            │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  ESTADO ATUAL                                          │
│  Total itens: 47                                        │
│  Crítico: 3 | Alto: 12 | Médio: 20 | Baixo: 12        │
│                                                         │
│  POR CATEGORIA                                          │
│  ████████░░ Código: 23 (49%)                           │
│  ████░░░░░░ Testes: 9 (19%)                            │
│  ███░░░░░░░ Docs: 7 (15%)                              │
│  ██░░░░░░░░ Infra: 5 (11%)                             │
│  █░░░░░░░░░ Dependências: 3 (6%)                       │
│                                                         │
│  TENDÊNCIA                                             │
│  Adicionado este mês: 8                                │
│  Resolvido este mês: 11                                │
│  Mudança líquida: -3 ↘ (melhorando)                    │
│                                                         │
│  ESFORÇO INVESTIDO                                      │
│  Este sprint: 15% capacidade                           │
│  Alvo: 20%                                              │
│                                                         │
└─────────────────────────────────────────────────────────┘

Priorização

Matriz Priorização Dívida

FRAMEWORK PRIORIZAÇÃO
═════════════════════

PONTUAR CADA ITEM (1-5):

IMPACTO: Quanto desacelera nós?
├── 5: Bloqueia múltiplas features semanalmente
├── 4: Bloqueia trabalho mensalmente
├── 3: Desacelera trabalho regularmente
├── 2: Atrito ocasional
└── 1: Inconveniência menor

RISCO: O que poderia dar errado?
├── 5: Risco segurança/perda dados
├── 4: Risco outage produção
├── 3: Bugs significativos prováveis
├── 2: Bugs menores possíveis
└── 1: Apenas questões cosméticas

OPORTUNIDADE: O que consertar habilita?
├── 5: Habilita iniciativa maior
├── 4: Desbloqueia feature próximo prazo
├── 3: Habilita nice-to-have
├── 2: Melhoria geral
└── 1: Benefício mínimo

ESFORÇO: Quão difícil consertar?
├── 1: Semana+ trabalho
├── 2: Dias trabalho
├── 3: 1-2 dias
├── 4: Horas
└── 5: Correção rápida

PONTUAÇÃO PRIORIDADE = Impacto + Risco + Oportunidade + Esforço

Exemplo:
Testes auth faltando:
Impacto: 4 + Risco: 4 + Oportunidade: 3 + Esforço: 2 = 13 (ALTO)

Categorias Priorização

BUCKETS PRIORIZAÇÃO DÍVIDA
══════════════════════════

🔴 CRÍTICO (Pontuação 16-20):
├── Abordar imediatamente
├── Risco segurança ou estabilidade
├── Bloqueia caminho crítico
└── Alocar sprint dedicado

🟠 ALTO (Pontuação 12-15):
├── Agendar para próximo sprint
├── Incluir com feature relacionada
├── Não deixar acumular
└── Atenção regular

🟡 MÉDIO (Pontuação 8-11):
├── Incluir em planejamento sprint
├── Correções oportunistas
├── Abordar quando tocando área
└── Rastrear mas não correr

🟢 BAIXO (Pontuação 4-7):
├── Rastrear para futuro
├── Consertar se conveniente
├── Pode nunca abordar
└── Reavaliar periodicamente

Pagando Dívida

Estratégias Alocação

ABORDAGENS ALOCAÇÃO DÍVIDA
══════════════════════════

ABORDAGEM 1: Porcentagem Fixa
─────────────────────────────────────
Alocar 15-20% cada sprint para dívida
├── Capacidade previsível
├── Progresso consistente
├── Equipe conhece expectativa
└── Não eliminará itens grandes rapidamente

Exemplo: Sprint 80 pontos → 16 pontos para dívida

ABORDAGEM 2: Sprints Dívida
─────────────────────────────────────
Sprint todo-dívida periódico (trimestral)
├── Grandes chunks abordados
├── Foco equipe em qualidade
├── Pode parecer pausa
└── Dívida acumula entre

Exemplo: Cada 4º sprint é sprint dívida

ABORDAGEM 3: Regra Boy Scout
─────────────────────────────────────
Deixe código melhor que encontrou
├── Melhoria contínua
├── Sem alocação dedicada
├── Integrado com features
└── Pode perder itens grandes

Regra: 30 min melhoria com cada PR

ABORDAGEM 4: Híbrido (Recomendado)
─────────────────────────────────────
├── 15% capacidade sprint (consistente)
├── Regra boy scout (contínua)
├── Sprint dívida anual (itens maiores)
└── Itens críticos recebem alocação especial

Padrões Implementação

PADRÕES REDUÇÃO DÍVIDA
══════════════════════

STRANGLER FIG:
├── Construir novo sistema ao lado antigo
├── Migrar funcionalidade gradualmente
├── Eventualmente aposentar antigo
├── Baixo risco, mais lento

REFACTOR IN PLACE:
├── Melhorar código existente
├── Manter funcionalidade
├── Pode precisar freeze feature
├── Mais rápido mas arriscado

OPORTUNISTA:
├── Melhorar quando tocando código
├── Escopo limitado à área tarefa
├── Sem tempo dedicado necessário
├── Lento progresso geral

BIG BANG:
├── Reescrever completamente
├── Esforço significativo
├── Alto risco
├── Às vezes necessário

REGRA GERAL:
├── Dívida pequena: Oportunista
├── Dívida média: Alocação sprint
├── Dívida grande: Strangler ou sprint dedicado
└── Dívida crítica: Atenção imediata

GitScrum para Gerenciamento Dívida

Setup Rastreamento

SETUP GERENCIAMENTO DÍVIDA GITSCRUM
═══════════════════════════════════

LABELS:
├── tech-debt (label principal)
├── debt:critical
├── debt:high
├── debt:medium
├── debt:low

CAMPOS CUSTOMIZADOS:
├── Tipo Dívida: [dropdown]
├── Área Afetada: [text]
├── Nível Risco: [dropdown]
├── Data Criação: [date]

VIEWS:
├── Dashboard Dívida Técnica (visão filtrada)
├── Por Prioridade (ordenado)
├── Por Idade (mais antigo primeiro)
├── Por Área (agrupado)

AUTOMAÇÃO:
├── Alerta idade após 90 dias
├── Lembrar quando tocando arquivos afetados
├── Incluir em planejamento sprint
└── Rastrear taxa resolução

Melhores Práticas

Para Dívida Técnica

1. Torne visível — Rastreie cada item dívida
2. Priorize sistematicamente — Não apenas feeling
3. Alocar consistentemente — 15-20% capacidade
4. Meça progresso — Estamos ganhando ou perdendo?
5. Celebre pagamento — Reconheça trabalho qualidade

Anti-Padrões

ERROS GERENCIAMENTO DÍVIDA:
✗ Ignorando até crise
✗ Sem sistema rastreamento
✗ Abordagem tudo-ou-nada
✗ Sprints apenas features
✗ Big bang rewrites (geralmente)
✗ Priorizando novo sobre consertar
✗ Sem visibilidade para stakeholders
✗ Dívida como punição

Soluções Relacionadas

• Gerenciando backlog técnico
• Rastreando dívida técnica
• Mantendo velocity desenvolvimento