Perdendo o Rastreamento da Dívida Técnica

Dívida técnica se acumula silenciosamente até paralisar a velocidade de desenvolvimento. GitScrum fornece rastreamento estruturado com labels, priorização e alocação de sprint para gerenciar dívida sistematicamente antes de virar emergência.

O Problema da Dívida Técnica

Dívida não rastreada cria problemas compostos:

• Acumulação invisível — Sem visibilidade do crescimento da dívida
• Adiada indefinidamente — Sempre despriorizada por features
• Crises repentinas — Pequenos problemas viram grandes outages
• Declínio de velocidade — Tudo leva mais tempo ao longo do tempo
• Frustração de desenvolvedores — Trabalhar em codebases degradadas
• Erros de estimativa — Dívida torna novo trabalho imprevisível

Solução de Rastreamento de Dívida GitScrum

Gestão sistemática de dívida no GitScrum:

Recursos Principais

Configurando Rastreamento de Dívida

Criar Labels de Dívida

Labels para Dívida Técnica:
├── tech-debt          (categoria pai)
├── debt-architecture  (problemas estruturais)
├── debt-performance   (velocidade/eficiência)
├── debt-security      (preocupações de segurança)
├── debt-testing       (gaps de cobertura de testes)
├── debt-documentation (docs faltantes)
└── debt-dependencies  (pacotes desatualizados)

Níveis de Prioridade

Matriz de Prioridade para Dívida:
├── Crítica — Bloqueando features ou causando incidentes
├── Alta    — Desacelerando significativamente desenvolvimento
├── Média   — Fricção perceptível, gerenciável
└── Baixa   — Limpeza, nice to have

Criar Template de Dívida

Template de Tarefa: Item de Dívida Técnica

Título: [DEBT] Descrição breve
Descrição:
  - O quê: Estado problemático atual
  - Por quê: Como isso virou dívida
  - Impacto: Efeito no desenvolvimento/produto
  - Solução: Abordagem de fix proposta
  - Esforço: Tempo estimado para resolver
  - Risco: Consequências se não abordado

Labels: tech-debt, [tipo-de-divida]
Prioridade: [Crítica/Alta/Média/Baixa]

Capturando Dívida Técnica

Quando Registrar Dívida

Registrar dívida quando:
├── Implementando workarounds para entregar features
├── Pulando testes para cumprir prazos
├── Copiar-colar em vez de refatorar
├── Ignorando avisos de deprecação
├── Hardcodeando valores que deveriam ser config
├── Deixando comentários TODO no código
└── Descobrindo conhecimento tribal não documentado

Exemplo de Tarefa de Dívida

[DEBT] Módulo de pagamento usa API Stripe deprecada

O quê: Processamento de pagamento usa Stripe API v1, 
deprecada desde 2023. O código atual ainda funciona 
mas não recebe atualizações de segurança.

Por quê: Implementação original em 2021, sem capacidade 
para migração durante pushes de features.

Impacto: 
- Risco de segurança por API sem manutenção
- Faltam novas features de pagamento
- Vai quebrar quando v1 sunset (Jan 2025)

Solução: Migrar para Stripe API v3
- Atualizar dependência do SDK
- Refatorar serviço de pagamento
- Atualizar handlers de webhook
- Testar todos os fluxos de pagamento

Esforço: 3-5 dias para desenvolvedor senior
Risco: Alto - serviço vai falhar após data de sunset

Labels: tech-debt, debt-security, debt-dependencies
Prioridade: Crítica
Prazo: Antes de Jan 2025

Priorização de Dívida

Matriz Impacto/Esforço

                    Baixo Esforço   Alto Esforço
                   ┌───────────────┬───────────────┐
Alto Impacto       │ FAZER PRIMEIRO│ PLANEJAR      │
                   │ Quick wins    │ Trabalho maior│
                   ├───────────────┼───────────────┤
Baixo Impacto      │ PREENCHER GAPS│ ADIAR         │
                   │ Limpeza fácil │ Não vale a pena│
                   └───────────────┴───────────────┘

Critérios de Priorização

Alocação de Sprint para Dívida

A Regra dos 20%

Reservar capacidade para trabalho de dívida:

Capacidade do Sprint: 100 pontos
├── Features: 80 pontos (80%)
└── Tech Debt: 20 pontos (20%)

Alocação consistente previne:
- Acumulação de dívida
- Variância sprint-a-sprint
- "Sprints de dívida" que frustram stakeholders

Planejamento de Sprint de Dívida

Planejamento de Sprint para Dívida:

1. Revisar backlog de dívida
2. Verificar itens críticos/alta prioridade
3. Combinar com capacidade disponível (20%)
4. Selecionar itens que:
   - Combinam bem com features planejadas
   - Abordam pain points atuais
   - Têm critérios de conclusão claros
5. Atribuir a desenvolvedores com contexto

Vinculando Dívida a Features

Conectar Trabalho Relacionado

Tarefa de Feature #234: Adicionar faturamento de assinatura
├── Tarefas de Dívida Vinculadas:
│   ├── #198: [DEBT] Migrar para Stripe API v3
│   │   └── Razão: Necessário para features de assinatura
│   ├── #210: [DEBT] Adicionar lógica de retry de pagamento
│   │   └── Razão: Assinaturas precisam de auto-retry
│   └── #215: [DEBT] Melhorar tratamento de erros de pagamento
│       └── Razão: Melhor UX para falhas recorrentes

Benefícios de Vincular

• Justificar trabalho de dívida para stakeholders
• Surfacear pré-requisitos ocultos
• Estimativas de features precisas
• Resolução natural de dívida durante features

Visibilidade de Dívida

Visão de Board para Dívida

Kanban Board: Dívida Técnica
┌──────────────┬──────────────┬──────────────┬──────────────┐
│ Backlog (23) │ Planejado (5)│ Em Progresso │ Resolvido (8)│
├──────────────┼──────────────┼──────────────┼──────────────┤
│ [DEBT] Auth  │ [DEBT] API   │ [DEBT] Stripe│ [DEBT] Tests │
│ [DEBT] Cache │ [DEBT] Logs  │ migração     │ [DEBT] Docs  │
│ [DEBT] Tests │ [DEBT] DB    │              │ ...          │
│ ...          │ ...          │              │              │
└──────────────┴──────────────┴──────────────┴──────────────┘

Métricas de Dashboard

Rastrear saúde da dívida ao longo do tempo:

Dashboard de Dívida Técnica
━━━━━━━━━━━━━━━━━━━━━━━━━━━

Total Itens de Dívida: 45
├── Crítica: 3 🔴
├── Alta: 12 🟡
├── Média: 18 🟢
└── Baixa: 12 ⚪

Este Sprint:
├── Planejados: 5 itens (23 pontos)
└── Resolvidos: 3 itens (15 pontos)

Tendência: ↓ 4% do mês passado
Item Mais Antigo: 8 meses (migração DB)

Documentação no NoteVault

Registro de Dívida Técnica

NoteVault: Registro de Dívida Técnica

## Visão Geral
Este documento rastreia itens maiores de dívida técnica 
e seu contexto de negócio.

## Dívida Ativa

### Sistema de Pagamento
- **Problema**: API Stripe v1 deprecada
- **Dono**: @backend-team
- **Status**: Planejado para Q1
- **Impacto de Negócio**: Risco segurança, features faltantes
- **Plano de Resolução**: #198

### Autenticação
- **Problema**: Sem rotação de refresh token
- **Dono**: @security-team
- **Status**: Em progresso
- **Impacto de Negócio**: Gap de compliance de segurança
- **Plano de Resolução**: #245

## Dívida Resolvida
| Item | Resolvido | Tempo Gasto | Notas |
|------|-----------|-------------|-------|
| Legacy ORM | Nov 2024 | 2 semanas | Migração completa |
| Cobertura testes | Out 2024 | 3 sprints | 40% → 80% |

Revisões de Dívida

Reuniões Regulares de Dívida

Revisão Mensal de Dívida Técnica

Agenda:
1. Revisar métricas de dívida (15 min)
   - Nova dívida registrada
   - Dívida resolvida
   - Direção da tendência

2. Triagem de novos itens (20 min)
   - Atribuir prioridade
   - Estimar esforço
   - Identificar quick wins

3. Planejar próximo sprint (15 min)
   - Selecionar dívida para próximo sprint
   - Atribuir donos
   - Vincular a features

4. Discutir bloqueios (10 min)
   - Itens bloqueados
   - Necessidades de recursos
   - Alinhamento com stakeholders

Integração na Retrospectiva

Abordar dívida em retros:

Retrospectiva do Sprint

O que nos desacelerou?
├── "Falhas de retry de pagamento desperdiçaram 2 dias debugando"
│   └── Ação: Priorizar #210 (dívida de lógica de retry)
├── "Testes flaky causaram falsos alarmes"
│   └── Ação: Adicionar #260 (dívida de estabilidade de testes)

Prevenindo Nova Dívida

Definição de Pronto

Definição de Pronto (inclui prevenção de dívida):
☑ Feature completa conforme requisitos
☑ Testes unitários escritos (>80% cobertura)
☑ Testes de integração passam
☑ Documentação atualizada
☑ Sem novos comentários TODO sem ticket
☑ Dependências atualizadas se tocadas
☑ Code review aprovado
☑ Sem avisos de segurança
☑ Performance aceitável

Checklist de Code Review

Code Review Consciente de Dívida:

□ Isso introduz nova dívida?
  - Se sim, ticket criado?
□ Isso resolve alguma dívida existente?
  - Se sim, vincular e fechar ticket de dívida
□ Existem workarounds?
  - Documentar por quê, criar ticket de limpeza
□ Dependências estão atualizadas?
  - Verificar deprecações
□ Cobertura de testes é mantida?
  - Sem regressão de cobertura

Comunicando Dívida a Stakeholders

Tradução para Linguagem de Negócio

Técnico → Impacto de Negócio

"API está deprecada"
→ "Risco de segurança: sem patches após janeiro"

"Cobertura de testes é baixa"  
→ "Risco de release: bugs mais prováveis em produção"

"Arquitetura é monolítica"
→ "Velocidade de entrega: features levam 3x mais tempo"

"Dependências estão desatualizadas"
→ "Risco de compliance: vulnerabilidades conhecidas"

Relatório de Burn-down de Dívida

Relatório de Dívida Técnica Q4

Início Q4: 52 itens de dívida (312 pontos)
Resolvidos: 18 itens (98 pontos)
Adicionados: 7 itens (43 pontos)
Fim Q4: 41 itens (257 pontos)

Redução Líquida: 11 itens (55 pontos) ↓17%

Destaques:
✓ Completada migração Stripe (crítica)
✓ Cobertura de testes melhorou 15%
⚠ Migração de banco de dados ainda pendente

Soluções Relacionadas

• Gerenciar código legacy em projetos ativos
• Métricas de qualidade de código e rastreamento
• Planejamento de sprint com trabalho técnico