Gerenciando Dívida Técnica em Projetos Crescentes
Rastreie, priorize, e reduza sistematicamente dívida técnica usando rotulagem, estimativa esforço, e features planejamento sprint do GitScrum para balancear novo desenvolvimento com saúde codebase e manutenibilidade longo prazo.
6 min de leitura
Dívida técnica se acumula invisivelmente até desenvolvimento ficar lento. Times sabem que dívida existe mas lutam para quantificar, priorizar, ou obter buy-in stakeholder para endereçá-la. Gerenciar dívida efetivamente requer torná-la visível através de tracking, articular impacto negócio, e alocar capacidade consistentemente—tratando redução dívida como trabalho planejado, não limpeza opcional feita "quando tivermos tempo."
O Problema de Dívida Técnica
Por Que Dívida Espirala Fora de Controle
PADRÃO ACUMULAÇÃO DÍVIDA:
┌─────────────────────────────────────────────────────────────┐
│ COMO CODEBASES SE DETERIORAM │
├─────────────────────────────────────────────────────────────┤
│ │
│ PROGRESSÃO TÍPICA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Mês 1-3: "Consertamos depois" ││
│ │ • Quick fixes para cumprir deadline ││
│ │ • Implementações "bom o suficiente" ││
│ │ • Comentários TODO adicionados, nunca endereçados ││
│ │ ││
│ │ Mês 4-6: "Coisas estão ficando bagunçadas" ││
│ │ • Novos devs lutam para entender código ││
│ │ • Bug fixes causam novos bugs ││
│ │ • Features levam mais tempo que esperado ││
│ │ ││
│ │ Mês 7-12: "Não conseguimos mais mover rápido" ││
│ │ • Mudanças simples requerem tocar muitos arquivos ││
│ │ • Medo de refatorar (pode quebrar coisas) ││
│ │ • Frustração developer aumentando ││
│ │ ││
│ │ Mês 12+: "Precisamos reescrever" ││
│ │ • Velocity caiu 50%+ ││
│ │ • Cada feature é uma luta ││
│ │ • Moral time sofrendo ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ CUSTO DE IGNORAR DÍVIDA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Cedo: Feature X leva 3 dias ││
│ │ 6 meses dívida: Feature X leva 5 dias ││
│ │ 12 meses dívida: Feature X leva 8 dias ││
│ │ ││
│ │ Efeito composto: ││
│ │ 10 features × 3 dias = 30 dias (codebase limpo) ││
│ │ 10 features × 8 dias = 80 dias (codebase endividado) ││
│ │ ││
│ │ Perdido: 50 dias developer = ~$40,000 ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Sistema Tracking GitScrum
Tornando Dívida Visível
SETUP TRACKING DÍVIDA:
┌─────────────────────────────────────────────────────────────┐
│ ORGANIZANDO DÍVIDA TÉCNICA │
├─────────────────────────────────────────────────────────────┤
│ │
│ ESTRUTURA LABELS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ divida/codigo - Melhorias nível código ││
│ │ divida/arquitetura - Mudanças estruturais ││
│ │ divida/teste - Gaps cobertura testes ││
│ │ divida/documentacao - Updates documentação ││
│ │ divida/dependencia - Upgrades biblioteca/framework ││
│ │ ││
│ │ Labels prioridade: ││
│ │ divida-prioridade/critica - Bloqueando novo trabalho ││
│ │ divida-prioridade/alta - Desacelerando desenvolvimento││
│ │ divida-prioridade/media - Deveria endereçar em breve ││
│ │ divida-prioridade/baixa - Nice to have ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ TEMPLATE TAREFA DÍVIDA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Título: [DÍVIDA] Descrição breve ││
│ │ ││
│ │ Tipo: [codigo/arquitetura/teste/doc/dependencia] ││
│ │ ││
│ │ O que é a dívida: ││
│ │ [Descrever problema técnico] ││
│ │ ││
│ │ Impacto negócio: ││
│ │ [Como isso desacelera desenvolvimento ou causa bugs] ││
│ │ ││
│ │ Taxa juros (custo ongoing): ││
│ │ [Horas desperdiçadas por sprint/mês por esta dívida] ││
│ │ ││
│ │ Esforço payoff: ││
│ │ [Esforço estimado para consertar] ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Priorizando Redução Dívida
Quadrante Dívida
FRAMEWORK PRIORIZAÇÃO:
┌─────────────────────────────────────────────────────────────┐
│ DECIDINDO O QUE PAGAR │
├─────────────────────────────────────────────────────────────┤
│ │
│ MATRIZ IMPACTO vs ESFORÇO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ ALTO │ Agendar │ Fazer Primeiro ││
│ │ IMPACTO │ (Planejar para│ (Quick wins) ││
│ │ │ próx trimestre)│ ││
│ │ │ │ ││
│ │ ────────┼───────────────┼───────────────── ││
│ │ │ │ ││
│ │ BAIXO │ Ignorar │ Oportunístico ││
│ │ IMPACTO │ (Não vale │ (Consertar quando ││
│ │ │ o esforço) │ tocando de qualquer forma) ││
│ │ │ │ ││
│ │ │ ALTO ESFORÇO │ BAIXO ESFORÇO ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ SISTEMA PONTUAÇÃO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Score Impacto (1-5): ││
│ │ 5 = Bloqueando múltiplas features ││
│ │ 4 = Causando bugs em produção ││
│ │ 3 = Desacelerando desenvolvimento significativamente ││
│ │ 2 = Fricção menor, workarounds existem ││
│ │ 1 = Cosmético, sem impacto real ││
│ │ ││
│ │ Prioridade = Impacto / Esforço ││
│ │ Score mais alto = maior prioridade ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Alocando Capacidade
Orçamento para Redução Dívida
ALOCAÇÃO CAPACIDADE SPRINT:
┌─────────────────────────────────────────────────────────────┐
│ FAZENDO TEMPO PARA DÍVIDA │
├─────────────────────────────────────────────────────────────┤
│ │
│ ESTRATÉGIAS ALOCAÇÃO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Opção A: Porcentagem por Sprint ││
│ │ ││
│ │ Trabalho features: 70% ││
│ │ Bug fixes: 10% ││
│ │ Dívida técnica: 15% ││
│ │ Buffer: 5% ││
│ │ ││
│ │ Exemplo: 100 pontos → 15 pontos para dívida por sprint ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Opção B: Sprint Dívida ││
│ │ ││
│ │ Cada 4º sprint: 80% dívida, 20% bugs críticos ││
│ │ ││
│ │ Pros: Abordar itens grandes, esforço focado ││
│ │ Cons: Delays features, resistência stakeholders ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ RECOMENDADO: Combinar A + Oportunístico │
│ 15% capacidade dedicada + melhorias oportunísticas │
│ │
└─────────────────────────────────────────────────────────────┘