8 min leitura • Guide 718 of 877
Gerenciando Débito Técnico em Times Ágeis
Débito técnico é inevitável - deixar crescer fora de controle não é. O GitScrum ajuda times a rastrear, priorizar e pagar débito técnico sistematicamente enquanto mantém momentum de entrega.
Entendendo Débito Técnico
Tipos de Débito
CATEGORIAS DE DÉBITO TÉCNICO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DÉBITO DELIBERADO (Escolhas táticas): │
│ "Sabemos que não é ideal, mas vamos entregar" │
│ • Atalhos para deadline │
│ • Decisões de MVP │
│ • Soluções temporárias │
│ Risco: Baixo se rastreado e planejado │
│ │
│ DÉBITO ACIDENTAL (Gaps de aprendizado): │
│ "Não sabíamos melhor na época" │
│ • Padrões desatualizados │
│ • Decisões ruins no início │
│ • Abordagem melhor descoberta depois │
│ Risco: Médio, acumula silenciosamente │
│ │
│ BIT ROT (Entropia): │
│ "O mundo mudou, nosso código não" │
│ • Dependências desatualizadas │
│ • Integrações legadas │
│ • APIs deprecadas │
│ Risco: Alto se relacionado a segurança │
│ │
│ CRUFT (Bagunça acumulada): │
│ "Simplesmente cresceu com o tempo" │
│ • Código morto │
│ • Código duplicado │
│ • Padrões inconsistentes │
│ Risco: Médio, desacelera desenvolvimento │
└─────────────────────────────────────────────────────────────┘
Sintomas de Débito
SINAIS DE DÉBITO TÉCNICO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ EXPERIÊNCIA DO DESENVOLVEDOR: │
│ • "Mudanças simples demoram eternamente" │
│ • "Tenho medo de mexer naquele código" │
│ • "Precisamos contornar isso" │
│ • "Ninguém sabe como isso funciona" │
│ • "Testes são flaky/lentos/faltando" │
│ │
│ IMPACTO NA VELOCIDADE: │
│ • Features demoram mais que esperado │
│ • Bugs aparecem em áreas não relacionadas │
│ • Onboarding demora muito │
│ • Mesmos problemas continuam recorrendo │
│ │
│ IMPACTO NA QUALIDADE: │
│ • Taxa alta de bugs em certas áreas │
│ • Difícil de testar │
│ • Incidentes de infraestrutura envelhecida │
│ • Vulnerabilidades de segurança │
│ │
│ JUROS DO DÉBITO: │
│ Como débito financeiro, débito técnico compõe: │
│ │
│ Ano 1: Feature leva 1 semana │
│ Ano 2: Feature leva 2 semanas (débito) │
│ Ano 3: Feature leva 3 semanas (mais débito) │
│ │
│ Eventualmente: "Seria mais rápido reescrever" │
└─────────────────────────────────────────────────────────────┘
Gestão de Débito
Tornando Débito Visível
INVENTÁRIO DE DÉBITO:
┌─────────────────────────────────────────────────────────────┐
│ Backlog de Débito Técnico │
├─────────────────────────────────────────────────────────────┤
│ │
│ ID │ Descrição │ Área │ Impacto│ Esforço│
│──────┼────────────────────────┼──────────┼────────┼────────│
│ TD-1 │ Sistema auth em │ Auth │ Alto │ Grande │
│ │ biblioteca deprecada │ │ │ │
│──────┼────────────────────────┼──────────┼────────┼────────│
│ TD-2 │ Sem testes para módulo │ Pagamento│ Alto │ Médio │
│ │ de pagamento │ │ │ │
│──────┼────────────────────────┼──────────┼────────┼────────│
│ TD-3 │ Lógica duplicada de │ Usuários │ Médio │ Pequeno│
│ │ validação de usuário │ │ │ │
│──────┼────────────────────────┼──────────┼────────┼────────│
│ TD-4 │ Valores de config │ Global │ Baixo │ Pequeno│
│ │ hardcoded │ │ │ │
│──────┼────────────────────────┼──────────┼────────┼────────│
│ TD-5 │ Queries N+1 em │ Relatórios│ Médio │ Médio │
│ │ relatórios │ │ │ │
│ │
│ SCORING DE DÉBITO: │
│ Impacto × Frequência de Mudança na Área = Prioridade │
│ │
│ TD-2 tem score mais alto: │
│ Alto impacto + Área de pagamento muda frequentemente │
└─────────────────────────────────────────────────────────────┘
Alocação de Capacidade
DIVISÃO DE CAPACIDADE DO SPRINT:
┌─────────────────────────────────────────────────────────────┐
│ │
│ REGRA RECOMENDADA: │
│ ───────────────── │
│ 70-80% Features novas │
│ 15-20% Paydown de débito técnico │
│ 5-10% Bugs e manutenção │
│ │
│ SPRINT 26 - 40 pontos disponíveis: │
│ ────────────────────────────────── │
│ Features: 30 pontos │
│ ├── GS-400: Nova busca (8 pts) │
│ ├── GS-401: Filtros (5 pts) │
│ ├── GS-402: Export (5 pts) │
│ └── GS-403: Dashboard (12 pts) │
│ │
│ Débito Técnico: 8 pontos │
│ ├── TD-3: Consolidar validação (3 pts) │
│ └── TD-5: Otimizar queries N+1 (5 pts) │
│ │
│ Buffer: 2 pontos │
│ └── Bugs urgentes │
│ │
│ NOTA: Débito é negociável com PO, │
│ mas NUNCA zero por muito tempo │
│ │
└─────────────────────────────────────────────────────────────┘
Estratégias de Paydown
Priorização
PRIORIZANDO DÉBITO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ MATRIZ DE PRIORIDADE: │
│ │
│ │ Área Muda │ Área Estável │
│ │ Frequente │ │
│ ──────────┼──────────────┼───────────── │
│ Alto │ 🔴 URGENTE │ 🟡 PLANEJAR │
│ Impacto │ Pagar logo │ Agendar │
│ ──────────┼──────────────┼───────────── │
│ Baixo │ 🟡 OPORTUNO │ 🟢 IGNORAR │
│ Impacto │ Quando mexer │ Aceitar │
│ │
│ ORDEM DE ATAQUE: │
│ ────────────────── │
│ 1. Alto impacto + área frequente → Agora │
│ 2. Alto impacto + área estável → Próximos sprints │
│ 3. Baixo impacto + área frequente → Quando for mexer │
│ 4. Baixo impacto + área estável → Não priorizar │
│ │
└─────────────────────────────────────────────────────────────┘
Técnicas de Paydown
ESTRATÉGIAS DE PAGAMENTO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ 1. BOY SCOUT RULE │
│ ───────────────── │
│ "Deixe o código melhor do que encontrou" │
│ • Pequenas melhorias junto com features │
│ • Não precisa ser perfeito, só melhor │
│ • Incremental, não big bang │
│ │
│ 2. CAPACIDADE DEDICADA │
│ ────────────────────── │
│ • 15-20% de cada sprint │
│ • Proteger de "emergências" │
│ • Consistência > sprints ocasionais 100% │
│ │
│ 3. TECH DEBT SPRINT │
│ ─────────────────── │
│ • 1 sprint inteiro a cada 6-8 sprints │
│ • Para débito que precisa de foco │
│ • Bom para refactors grandes │
│ • Comunicar valor para stakeholders │
│ │
│ 4. PAGAR ANTES DE CONSTRUIR │
│ ─────────────────────────── │
│ • Feature nova em área com débito? │
│ • Pagar débito primeiro │
│ • Evita construir sobre fundação ruim │
│ │
└─────────────────────────────────────────────────────────────┘
Comunicação com Stakeholders
Explicando Valor
COMUNICANDO DÉBITO TÉCNICO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ❌ NÃO DIGA: │
│ "Precisamos refatorar porque o código está feio" │
│ │
│ ✅ DIGA: │
│ "Se não endereçarmos o sistema de autenticação: │
│ • Features de segurança levarão 3x mais tempo │
│ • Risco de vulnerabilidade aumenta │
│ • Cada feature nova nessa área custa 5 dias extras" │
│ │
│ LINGUAGEM QUE FUNCIONA: │
│ ───────────────────── │
│ • "Investimento" não "refatoração" │
│ • "Velocidade futura" não "código limpo" │
│ • "Redução de risco" não "melhores práticas" │
│ • "ROI em X sprints" não "devemos fazer isso" │
│ │
│ MÉTRICAS PARA MOSTRAR: │
│ ──────────────────── │
│ • Tempo médio para features na área │
│ • Taxa de bugs na área │
│ • Tempo de onboarding │
│ • Incidentes relacionados │
│ │
└─────────────────────────────────────────────────────────────┘
Melhores Práticas
Checklist de Implementação
CHECKLIST DE DÉBITO TÉCNICO
═══════════════════════════
VISIBILIDADE:
☐ Backlog de débito existe
☐ Débito categorizado
☐ Impacto avaliado
☐ Time contribui para identificação
ALOCAÇÃO:
☐ Capacidade reservada (15-20%)
☐ PO entende e apoia
☐ Não negociável a zero
☐ Visível no sprint
PRIORIZAÇÃO:
☐ Matriz de prioridade usada
☐ Áreas de mudança frequente priorizadas
☐ Risco de segurança alto prioridade
☐ Quick wins incluídos
PREVENÇÃO:
☐ Code review de qualidade
☐ Definição de done inclui qualidade
☐ Débito deliberado documentado
☐ Boy scout rule praticado
COMUNICAÇÃO:
☐ Stakeholders entendem valor
☐ Métricas de impacto rastreadas
☐ Progresso comunicado
☐ Vitórias celebradas
Débito técnico bem gerenciado é investimento contínuo em velocidade futura—não uma interrupção das features, mas um habilitador delas.