8 min leitura • Guide 514 of 877
Como Gerenciar Débito Técnico com Pontos de Esforço do GitScrum
Débito técnico acumula silenciosamente até paralisar a velocidade de entrega. O sistema de pontos de esforço do GitScrum permite times quantificar itens de débito junto com trabalho de features, tornando o custo real visível para stakeholders e habilitando decisões baseadas em dados sobre quando e o que pagar.
Estimativa de Débito Técnico
| Tipo de Débito | Fatores de Complexidade | Pontos Típicos |
|---|---|---|
| Refactor simples | Arquivo único, bem testado | 1-2 |
| Melhoria de módulo | Múltiplos arquivos, testes necessários | 3-5 |
| Redesign de componente | Cross-módulo, breaking changes | 8-13 |
| Mudança de arquitetura | System-wide, migração necessária | 13-21+ |
Rastreamento de Débito com Pontos de Esforço
INVENTÁRIO DE DÉBITO TÉCNICO
┌─────────────────────────────────────────────────┐
│ ESTRUTURA DO BACKLOG DE DÉBITO │
│ │
│ Épico: Redução de Débito Técnico Q1 │
│ │
│ Categoria: Banco de Dados (Total: 34 pontos) │
│ ├── [5 pts] Migrar para connection pooling │
│ ├── [8 pts] Adicionar indexes faltando │
│ ├── [13 pts] Refatorar uso de ORM │
│ └── [8 pts] Implementar cache de queries │
│ │
│ Categoria: Camada de API (Total: 21 pontos) │
│ ├── [3 pts] Padronizar respostas de erro │
│ ├── [5 pts] Adicionar validação de input │
│ ├── [8 pts] Implementar rate limiting │
│ └── [5 pts] Adicionar versionamento de API │
│ │
│ Categoria: Frontend (Total: 26 pontos) │
│ ├── [8 pts] Substituir state management legado │
│ ├── [5 pts] Extrair componentes compartilhados │
│ ├── [8 pts] Adicionar TypeScript strict mode │
│ └── [5 pts] Melhorar bundle splitting │
│ │
│ TOTAL BACKLOG DE DÉBITO: 81 pontos │
└─────────────────────────────────────────────────┘
Alocação de Capacidade de Sprint
SPRINT PLANNING COM ALOCAÇÃO DE DÉBITO
VELOCIDADE DO TIME: 40 pontos/sprint
┌─────────────────────────────────────────────────┐
│ DIVISÃO DE CAPACIDADE: │
│ │
│ Desenvolvimento de Features: 28 pontos (70%)│
│ ├── User stories │
│ └── Nova funcionalidade │
│ │
│ Débito Técnico: 8 pontos (20%) │
│ ├── Refatoração │
│ ├── Melhorias de testes │
│ └── Updates de arquitetura │
│ │
│ Manutenção: 4 pontos (10%) │
│ ├── Bug fixes │
│ └── Updates de dependências │
└─────────────────────────────────────────────────┘
CRITÉRIOS DE SELEÇÃO DE DÉBITO NA SPRINT:
┌─────────────────────────────────────────────────┐
│ Ordem de prioridade: │
│ 1. Débito bloqueando features planejadas │
│ 2. Débito causando issues de produção │
│ 3. Débito reduzindo velocidade │
│ 4. Débito com implicações de segurança │
│ 5. Ganhos rápidos (alto impacto, baixo esforço)│
└─────────────────────────────────────────────────┘
Guia de Estimativa de Pontos de Débito
ESTIMATIVA DE PONTOS DE ESFORÇO PARA DÉBITO
1 PONTO - Trivial
┌─────────────────────────────────────────────────┐
│ • Renomear para clareza │
│ • Adicionar null check faltando │
│ • Atualizar comentário desatualizado │
│ • Corrigir code smell simples │
│ Tempo: < 2 horas │
└─────────────────────────────────────────────────┘
2-3 PONTOS - Simples
┌─────────────────────────────────────────────────┐
│ • Extrair método/função │
│ • Adicionar testes faltando para função única │
│ • Substituir chamada de biblioteca deprecated │
│ • Corrigir duplicação de código em arquivo │
│ Tempo: 2-4 horas │
└─────────────────────────────────────────────────┘
5 PONTOS - Médio
┌─────────────────────────────────────────────────┐
│ • Refatorar uma classe/módulo │
│ • Adicionar cobertura de testes para componente│
│ • Substituir padrão em múltiplos arquivos │
│ • Extrair utilitário compartilhado │
│ Tempo: 1-2 dias │
└─────────────────────────────────────────────────┘
8 PONTOS - Grande
┌─────────────────────────────────────────────────┐
│ • Redesign de componente/service │
│ • Migrar de padrão antigo para novo │
│ • Adicionar camada de abstração │
│ • Refatorar acesso a dados │
│ Tempo: 2-3 dias │
└─────────────────────────────────────────────────┘
13 PONTOS - Muito Grande
┌─────────────────────────────────────────────────┐
│ • Redesign de subsistema │
│ • Migração de framework/biblioteca │
│ • Reestruturação de domínio │
│ • Separação de bounded context │
│ Tempo: 1 sprint │
└─────────────────────────────────────────────────┘
Tipos de Débito Técnico
CATEGORIZAÇÃO DE DÉBITO
DÉBITO PRUDENTE DELIBERADO:
┌─────────────────────────────────────────────────┐
│ "Sabemos que isso é shortcuts, mas precisamos │
│ entregar para o deadline. Vamos corrigir." │
│ │
│ Exemplos: │
│ • Hardcoded configs para MVP │
│ • Testes mínimos para deadline │
│ • Solução simples antes de escalar │
│ │
│ Ação: Criar tarefa de débito imediatamente │
└─────────────────────────────────────────────────┘
DÉBITO PRUDENTE INADVERTIDO:
┌─────────────────────────────────────────────────┐
│ "Agora que terminamos, percebemos que │
│ poderíamos ter feito de forma melhor." │
│ │
│ Exemplos: │
│ • Design que não escala bem │
│ • Abstrações erradas descobertas depois │
│ • Duplicação emergente │
│ │
│ Ação: Documentar aprendizado, planejar melhoria│
└─────────────────────────────────────────────────┘
DÉBITO IMPRUDENTE DELIBERADO:
┌─────────────────────────────────────────────────┐
│ "Não temos tempo para fazer direito." │
│ │
│ Exemplos: │
│ • Copiar/colar código consciente │
│ • Pular testes "dessa vez" │
│ • Ignorar best practices conhecidas │
│ │
│ Ação: Evitar! Custo muito alto depois │
└─────────────────────────────────────────────────┘
Medindo Redução de Débito
DASHBOARD DE DÉBITO TÉCNICO
TENDÊNCIA DE BACKLOG:
┌─────────────────────────────────────────────────┐
│ Mês Pontos Adicionado Removido Net │
│ ───────────────────────────────────────────── │
│ Janeiro 81 12 8 +4 │
│ Fevereiro 77 8 12 -4 │
│ Março 69 6 14 -8 │
│ Abril 65 10 14 -4 │
│ │
│ Tendência: ↓ 20% em 4 meses ✓ │
└─────────────────────────────────────────────────┘
VELOCIDADE DE PAGAMENTO:
┌─────────────────────────────────────────────────┐
│ Capacidade alocada: 8 pts/sprint │
│ Média completada: 10 pts/sprint │
│ Eficiência: 125% │
│ │
│ Taxa de adição: 6 pts/sprint │
│ Taxa de remoção: 10 pts/sprint │
│ Net por sprint: -4 pts (reduzindo!) ✓ │
└─────────────────────────────────────────────────┘
IMPACTO NA QUALIDADE:
┌─────────────────────────────────────────────────┐
│ Bugs em produção: │
│ • Antes do programa de débito: 12/mês │
│ • Depois de 3 meses: 6/mês │
│ • Redução: 50% │
│ │
│ Tempo de desenvolvimento: │
│ • Feature típica antes: 8 dias │
│ • Feature típica agora: 5 dias │
│ • Ganho de velocidade: 37% │
└─────────────────────────────────────────────────┘
Comunicando Débito para Stakeholders
RELATÓRIO DE DÉBITO PARA EXECUTIVOS
RESUMO MENSAL:
┌─────────────────────────────────────────────────┐
│ Débito Técnico: Status Amarelo ⚠️ │
│ │
│ Situação Atual: │
│ • 65 pontos de débito no backlog │
│ • Reduzindo 4 pontos/sprint │
│ • Projeção de saúde: 6 meses │
│ │
│ Impacto no Negócio: │
│ • Velocidade de features -20% por débito │
│ • Custo estimado: 1 dev/mês em manutenção │
│ │
│ Recomendação: │
│ Manter 20% de capacidade para débito │
│ por mais 2 quarters │
│ │
│ ROI do Programa: │
│ • Investimento: 2 devs × 20% × 6 meses │
│ • Retorno: Velocidade +37%, Bugs -50% │
└─────────────────────────────────────────────────┘
Prevenindo Novo Débito
ESTRATÉGIAS DE PREVENÇÃO
DEFINITION OF DONE:
┌─────────────────────────────────────────────────┐
│ ☐ Código revisado e aprovado │
│ ☐ Testes unitários >= 80% cobertura │
│ ☐ Documentação atualizada │
│ ☐ Sem warnings do linter │
│ ☐ Performance dentro do budget │
│ ☐ Sem débito técnico introduzido │
│ (ou tarefa de pagamento criada) │
└─────────────────────────────────────────────────┘
BOY SCOUT RULE:
┌─────────────────────────────────────────────────┐
│ "Deixe o código melhor do que encontrou" │
│ │
│ Ao tocar em código: │
│ • Renomear variável confusa │
│ • Extrair função duplicada │
│ • Adicionar teste faltando │
│ • Atualizar comentário errado │
│ │
│ Pequenas melhorias constantes = débito zero │
└─────────────────────────────────────────────────┘