7 min leitura • Guide 65 of 877
Gerenciando Dívida Técnica Estrategicamente
Dívida técnica é inevitável em desenvolvimento de software, mas dívida não gerenciada acumula juros que desaceleram times. Gestão estratégica de dívida significa tomar decisões informadas sobre quando incorrer dívida, rastreá-la explicitamente, e pagá-la sistematicamente. GitScrum fornece visibilidade e ferramentas de planejamento para gerenciar dívida técnica como preocupação de primeira classe.
Entendendo Dívida Técnica
Tipos e impacto de dívida técnica:
| Tipo Dívida | Causa | Impacto | Taxa Juros |
|---|---|---|---|
| Deliberada-Prudente | Trade-off consciente por deadline | Conhecido, contido | Baixo-Médio |
| Deliberada-Imprudente | "Não há tempo para design" | Acumula rápido | Alto |
| Inadvertida-Prudente | "Não sabíamos melhor então" | Descoberto com tempo | Médio |
| Inadvertida-Imprudente | "O que é arquitetura?" | Problemas sistema todo | Muito Alto |
Tornando Dívida Visível
Tracking no GitScrum
ESTRUTURA TAREFA DÍVIDA TÉCNICA:
┌─────────────────────────────────────────────────────────────┐
│ SISTEMA VISIBILIDADE DÍVIDA │
├─────────────────────────────────────────────────────────────┤
│ │
│ LABELS PARA CATEGORIZAÇÃO: │
│ ├── "type:tech-debt" - Todos itens dívida técnica │
│ ├── "debt:architecture" - Problemas design/estrutura │
│ ├── "debt:code-quality" - Código bagunçado, duplicação │
│ ├── "debt:testing" - Testes faltando/inadequados │
│ ├── "debt:dependencies" - Bibliotecas desatualizadas │
│ ├── "debt:documentation" - Docs faltando/desatualizados │
│ └── "debt:infrastructure" - Build, deploy, monitoring │
│ │
│ LABELS PRIORIDADE/URGÊNCIA: │
│ ├── "debt-priority:critical" - Bloqueando desenvolvimento │
│ ├── "debt-priority:high" - Causando desaceleração signif. │
│ ├── "debt-priority:medium" - Inconveniente mas gerenciável │
│ └── "debt-priority:low" - Bom arrumar algum dia │
│ │
│ EXEMPLO TAREFA DÍVIDA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Título: Refatorar módulo processamento pagamentos ││
│ │ ││
│ │ Labels: type:tech-debt, debt:architecture, ││
│ │ debt-priority:high ││
│ │ ││
│ │ Descrição: ││
│ │ Estado Atual: ││
│ │ Lógica processamento pagamentos espalhada em 5 serviços ││
│ │ com validação duplicada e tratamento erros inconsistente.││
│ │ ││
│ │ Impacto: ││
│ │ - Cada feature de pagamentos leva 2x mais ││
│ │ - 3 bugs de pagamentos último trimestre por inconsistência││
│ │ ││
│ │ Esforço: 13 pontos (1 sprint com testing) ││
│ │ ROI: Reduz tempo feature pagamentos 50% ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Registro de Dívida
INVENTÁRIO DÍVIDA TÉCNICA:
┌─────────────────────────────────────────────────────────────┐
│ DASHBOARD TRACKING DÍVIDA │
├─────────────────────────────────────────────────────────────┤
│ │
│ DÍVIDA POR CATEGORIA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Arquitetura ████████████████ 42 pts (8 itens) ││
│ │ Qualidade Código██████████████ 35 pts (12 itens) ││
│ │ Testes ████████████ 28 pts (6 itens) ││
│ │ Dependências ████████ 18 pts (4 itens) ││
│ │ Documentação ██████ 15 pts (5 itens) ││
│ │ Infraestrutura █████ 12 pts (3 itens) ││
│ │ ││
│ │ TOTAL: 150 pontos em 38 itens ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DÍVIDA POR PRIORIDADE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 🔴 Crítica: 3 itens (25 pts) - Abordar imediatamente ││
│ │ 🟠 Alta: 8 itens (48 pts) - Agendar este trimestre ││
│ │ 🟡 Média: 15 itens (52 pts) - Monitorar, oportunístico││
│ │ 🟢 Baixa: 12 itens (25 pts) - Backlog ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Framework de Priorização
Avaliando Itens de Dívida
MATRIZ PRIORIZAÇÃO DÍVIDA:
┌─────────────────────────────────────────────────────────────┐
│ CRITÉRIOS DE PONTUAÇÃO │
├─────────────────────────────────────────────────────────────┤
│ │
│ PONTUAÇÃO IMPACTO (1-5): │
│ ├── 5: Bloqueando features novas ou causando quedas │
│ ├── 4: Desacelerando desenvolvimento significativamente │
│ ├── 3: Fricção notável, bugs ocasionais │
│ ├── 2: Inconveniência menor, code smell │
│ └── 1: Cosmético, sem impacto real │
│ │
│ PONTUAÇÃO ESFORÇO (1-5): │
│ ├── 1: Correção rápida (< 4 horas) │
│ ├── 2: Tarefa pequena (1-2 dias) │
│ ├── 3: Tarefa média (3-5 dias) │
│ ├── 4: Tarefa grande (1-2 sprints) │
│ └── 5: Esforço maior (> 2 sprints) │
│ │
│ PONTUAÇÃO CONTÁGIO (1-5): │
│ ├── 5: Espalhando rápido, infectando código novo │
│ ├── 4: Time está copiando padrões ruins │
│ ├── 3: Contido mas crescendo devagar │
│ ├── 2: Isolado a uma área │
│ └── 1: Estático, não espalhando │
│ │
│ PRIORIDADE = (Impacto × 2 + Contágio) / Esforço │
│ │
└─────────────────────────────────────────────────────────────┘
Alocação de Capacidade
Balanceando Dívida com Features
MODELO CAPACIDADE SPRINT:
┌─────────────────────────────────────────────────────────────┐
│ ALOCAÇÃO TIPO TRABALHO │
├─────────────────────────────────────────────────────────────┤
│ │
│ BASELINE RECOMENDADO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ Features ──────────────────── 70% ││
│ │ ██████████████████████████████████████████████████████ ││
│ │ ││
│ │ Correção Bugs ─────────────── 15% ││
│ │ ██████████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ││
│ │ ││
│ │ Dívida Técnica ────────────── 10% ││
│ │ █████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ││
│ │ ││
│ │ Inovação/Spikes ───────────── 5% ││
│ │ █████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ AJUSTANDO POR NÍVEIS DÍVIDA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ DÍVIDA BAIXA (< 50 pts): ││
│ │ Features: 75%, Bugs: 15%, Dívida: 5%, Inovação: 5% ││
│ │ ││
│ │ DÍVIDA MODERADA (50-150 pts): ││
│ │ Features: 70%, Bugs: 15%, Dívida: 10%, Inovação: 5% ││
│ │ ││
│ │ DÍVIDA ALTA (150-300 pts): ││
│ │ Features: 60%, Bugs: 15%, Dívida: 20%, Inovação: 5% ││
│ │ ││
│ │ DÍVIDA CRÍTICA (> 300 pts): ││
│ │ Features: 40%, Bugs: 10%, Dívida: 40%, Inovação: 10% ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Prevenindo Nova Dívida
Padrões de Desenvolvimento
PRÁTICAS PREVENÇÃO DÍVIDA:
┌─────────────────────────────────────────────────────────────┐
│ PARANDO DÍVIDA NA FONTE │
├─────────────────────────────────────────────────────────────┤
│ │
│ GATES CODE REVIEW: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Checklist Review: ││
│ │ ├── [ ] Sem código duplicado introduzido ││
│ │ ├── [ ] Testes cobrem nova funcionalidade ││
│ │ ├── [ ] Documentação atualizada ││
│ │ ├── [ ] Sem TODO sem tarefa vinculada ││
│ │ ├── [ ] Segue padrões estabelecidos ││
│ │ └── [ ] Sem novos warnings linter/type ││
│ │ ││
│ │ Dívida Adicionada? Deve ser: ││
│ │ ├── Rastreada explicitamente (criar tarefa dívida) ││
│ │ ├── Justificada na descrição PR ││
│ │ └── Aprovada por tech lead ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DEFINIÇÃO DE PRONTO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Feature está "Pronta" quando: ││
│ │ ├── Funcionalidade completa ││
│ │ ├── Testes escritos e passando ││
│ │ ├── Código revisado e aprovado ││
│ │ ├── Documentação atualizada ││
│ │ └── Sem nova dívida (ou tarefa dívida criada) ││
│ │ ││
│ │ Atalhos = Incompleto, não Pronto ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Melhores Práticas
Fazer
GESTÃO ESTRATÉGICA DÍVIDA:
✓ TORNAR DÍVIDA VISÍVEL
Cada item dívida rastreado no GitScrum com labels
✓ ALOCAR CAPACIDADE
10-20% de cada sprint para trabalho dívida
✓ PRIORIZAR POR IMPACTO
Focar em dívida bloqueando trabalho atual
✓ RASTREAR TENDÊNCIAS
Monitorar níveis dívida ao longo tempo
✓ PREVENIR NOVA DÍVIDA
Quality gates e padrões code review
Não Fazer
ARMADILHAS GESTÃO DÍVIDA:
✗ IGNORAR DÍVIDA
"Vamos arrumar depois" sem rastreamento
✗ TUDO OU NADA
Esperando sprints dedicados a dívida
✗ CONVERSAS SÓ TÉCNICAS
Stakeholders não entendem impacto
✗ GOLD PLATING
Arrumando código sem impacto "porque é feio"