9 min leitura • Guide 26 of 877
Equilibrando Trabalho de Features com Correção de Bugs
Times de desenvolvimento lutam constantemente com a tensão entre construir novas features e corrigir bugs existentes. Muito foco em features leva a dívida técnica e frustração do usuário, enquanto muito foco em bugs estagna o progresso do produto. GitScrum permite alocação equilibrada através de workflows dedicados de bugs e métricas que ajudam a manter o equilíbrio certo.
O Dilema Feature vs. Bug
Alocação desequilibrada cria problemas:
- Sprints pesados em features — Usuários sofrem com issues não resolvidos
- Sprints pesados em bugs — Roadmap atrasa, stakeholders frustrados
- Troca de contexto — Desenvolvedores perdem produtividade pulando entre
- Bugs ocultos — Features são enviadas com issues conhecidos
- Acumulação de dívida técnica — Fixes rápidos criam problemas futuros
- Problemas de moral do time — Turno de bugs visto como punição
Soluções de Equilíbrio GitScrum
Ferramentas para manter o equilíbrio:
Mecanismos de Equilíbrio
| Mecanismo | Implementação GitScrum |
|---|---|
| Alocação de sprint | Capacidade baseada em percentual |
| Priorização de bugs | Labels de severidade + impacto |
| Rotação de bugs | Políticas de auto-atribuição |
| Gates de qualidade | Checklists que previnem releases |
| Rastreamento de métricas | Velocidade de bugs vs. features |
| Visibilidade | Views e relatórios separados |
Estratégias de Alocação de Sprint
Alocação Baseada em Capacidade
Planejamento de Capacidade do Sprint:
Capacidade do Time: 60 story points
Modelo de Alocação A: Percentual Fixo
─────────────────────────────────────
├── Novas Features: 70% (42 pontos)
├── Correção de Bugs: 20% (12 pontos)
├── Dívida Técnica: 10% (6 pontos)
└── Total: 100% (60 pontos)
Modelo de Alocação B: Média Móvel
─────────────────────────────────
├── Features Base: 60% (36 pontos)
├── Bugs Base: 15% (9 pontos)
├── Buffer: 25% (15 pontos)
│ └── Alocado durante sprint baseado em bugs emergentes
└── Total: 100% (60 pontos)
Modelo de Alocação C: Disparado por Qualidade
─────────────────────────────────────────────
├── Se bugs P0/P1 abertos < 5:
│ └── Features: 80% / Bugs: 15% / Dívida: 5%
├── Se bugs P0/P1 abertos 5-10:
│ └── Features: 60% / Bugs: 35% / Dívida: 5%
├── Se bugs P0/P1 abertos > 10:
│ └── Features: 40% / Bugs: 55% / Dívida: 5%
└── Ajustar automaticamente cada sprint
Alocação Sprint 15 (Modelo A):
┌─────────────────────────────────────────────────┐
│ CAPACIDADE SPRINT: 60 pontos │
├─────────────────────────────────────────────────┤
│ Features (42 pts) │████████████████████░░░░│ │
│ Bugs (12 pts) │██████░░░░░░░░░░░░░░░░░░│ │
│ Dívida Téc (6 pts) │███░░░░░░░░░░░░░░░░░░░░░│ │
├─────────────────────────────────────────────────┤
│ Comprometido: │ 55 pontos │
│ Capacidade Restante: │ 5 pontos (buffer) │
└─────────────────────────────────────────────────┘
Reserva de Orçamento de Bugs
Reservando Capacidade de Bugs:
Protocolo de Planejamento do Sprint:
────────────────────────────────────
1. Começar com Capacidade Total (60 pontos)
2. Reservar Alocação de Bugs Primeiro
├── Verificar contagem de bugs P0/P1 (atualmente 7)
├── Estimar pontos de bugs (média 2 pts cada)
├── Reservado: 7 × 2 = 14 pontos para bugs
└── Mais buffer: +4 pontos para bugs descobertos
Total Reserva Bugs: 18 pontos
3. Reservar Dívida Técnica (se houver crítica)
├── Itens de dívida críticos: 2
├── Pontos: 6 pontos
└── Total Reserva Dívida: 6 pontos
4. Restante para Features
├── Total: 60 pontos
├── Menos bugs: -18 pontos
├── Menos dívida: -6 pontos
└── Disponível para features: 36 pontos
5. Preencher Backlog de Features
├── Selecionar features totalizando ≤36 pontos
├── Priorizar por valor de negócio
└── Confirmar com Product Owner
Resultado Backlog do Sprint:
├── Features: 34 pontos (5 itens)
├── Bugs: 18 pontos (9 itens)
├── Dívida Técnica: 6 pontos (2 itens)
└── Buffer: 2 pontos (não alocado)
Sistema de Priorização de Bugs
Matriz Severidade-Impacto
Classificação de Prioridade de Bugs:
IMPACTO
Baixo Médio Alto
┌─────────┬──────────┬──────────┬──────────┐
Alto │ │ P1 │ P0 │ P0 │
│ │ 24-48h │ 4-8h │ <4h │
SEVERIDADE├────────┼──────────┼──────────┼──────────┤
Médio │ │ P2 │ P1 │ P0 │
│ │ Sprint │ 24-48h │ 4-8h │
├─────────┼──────────┼──────────┼──────────┤
Baixo │ │ P3 │ P2 │ P1 │
│ │ Backlog │ Sprint │ 24-48h │
└─────────┴──────────┴──────────┴──────────┘
Definições de Severidade:
├── Alto: Crash do sistema, perda de dados, brecha de segurança
├── Médio: Feature quebrada, workaround existe
└── Baixo: Cosmético, inconveniência menor
Definições de Impacto:
├── Alto: Todos os usuários afetados, impacto em receita
├── Médio: Segmento significativo de usuários afetado
└── Baixo: Poucos usuários, caso extremo
Tempo de Resposta (SLA):
├── P0: Largar tudo, corrigir imediatamente
├── P1: Corrigir em 24-48 horas
├── P2: Corrigir no sprint atual
└── P3: Adicionar ao backlog, priorizar depois
Workflow de Triagem de Bugs
Processo de Triagem de Bugs:
Novo Bug Reportado:
───────────────────
Passo 1: Triagem Inicial (Dentro de 4 horas)
├── Atribuir ao Líder de Triagem (rotação)
├── Verificar que o bug é reproduzível
├── Avaliar severidade (Alto/Médio/Baixo)
├── Avaliar impacto (Alto/Médio/Baixo)
├── Determinar prioridade (P0/P1/P2/P3)
└── Adicionar labels apropriados
Passo 2: Categorização
├── Adicionar labels:
│ ├── severity/high, severity/medium, severity/low
│ ├── impact/high, impact/medium, impact/low
│ ├── priority/P0, priority/P1, priority/P2, priority/P3
│ ├── component/[área] (UI, API, Database, etc.)
│ └── regression/yes ou regression/no
└── Vincular a issues relacionados se houver
Passo 3: Roteamento
├── P0: Atribuir imediatamente a dev senior disponível
├── P1: Adicionar à coluna "Bugs Urgentes", atribuir dono
├── P2: Adicionar à alocação de bugs do sprint atual
├── P3: Adicionar ao Bug Backlog, aguardar priorização
└── Atualizar status do bug para "Triado"
Passo 4: Comunicação
├── P0/P1: Notificar time imediatamente (alerta Slack)
├── P2: Incluir no standup diário
├── P3: Revisar no grooming semanal do backlog
└── Reportador notificado da decisão de triagem
Sistema de Rotação de Bugs
Distribuição Justa
Política de Rotação de Bugs:
Princípios:
├── Todo desenvolvedor faz turno de bugs
├── Rotação é justa e previsível
├── Pareamento Senior/Junior para aprendizado
└── Ninguém preso em bugs indefinidamente
Calendário de Rotação:
──────────────────────
Semana │ Dev Principal Bugs │ Backup │ Foco
───────┼────────────────────┼─────────────┼─────────────
1 │ Alice │ Bob │ Bugs UI
2 │ Bob │ Carol │ Bugs API
3 │ Carol │ David │ Bugs DB
4 │ David │ Emma │ Bugs UI
5 │ Emma │ Alice │ Bugs API
(repetir)
Durante Semana de Turno de Bugs:
├── Responsável por resposta imediata P0/P1
├── Primeiro a triar novos bugs na área do componente
├── Espera-se completar 60% dos bugs alocados do sprint
├── Pareado com backup para issues complexos
└── Trabalho de features reduzido proporcionalmente
Automação GitScrum:
├── Auto-atribuir novos bugs P0/P1 ao dev da rotação atual
├── Notificar no Slack quando bug atribuído
├── Alertar se bug não atribuído >4 horas
└── Lembrete de rotação semanal domingo à noite
Configuração do Board para Equilíbrio
Kanban de Dupla Pista
Estrutura do Board:
Opção 1: Swimlanes Separados
────────────────────────────
┌─────────────────────────────────────────────────────────────┐
│ BOARD SPRINT 15 │
├─────────────────────────────────────────────────────────────┤
│ Features │
├──────────────┬──────────────┬─────────────┬────────────────┤
│ A Fazer (5) │ Em Progresso │ Review (2) │ Feito (3) │
│ │ (3) │ │ │
├──────────────┴──────────────┴─────────────┴────────────────┤
│ Bugs │
├──────────────┬──────────────┬─────────────┬────────────────┤
│ A Fazer (8) │ Em Progresso │ Review (1) │ Feito (5) │
│ │ (2) │ │ │
├──────────────┴──────────────┴─────────────┴────────────────┤
│ Dívida Técnica │
├──────────────┬──────────────┬─────────────┬────────────────┤
│ A Fazer (2) │ Em Progresso │ Review (0) │ Feito (1) │
│ │ (1) │ │ │
└──────────────┴──────────────┴─────────────┴────────────────┘
Opção 2: Filtragem Baseada em Labels
────────────────────────────────────
Board único com toggles de filtro:
├── [Tudo] [Só Features] [Só Bugs] [Só Dívida Téc]
├── Labels: type/feature, type/bug, type/tech-debt
├── Troca rápida entre views
└── Progresso combinado visível na view "Tudo"
Rastreamento de Métricas de Qualidade
Dashboard de Equilíbrio
Dashboard de Equilíbrio Feature/Bug:
Progresso Sprint 15:
────────────────────
Distribuição de Trabalho:
├── Features: ████████████████░░░░ 80% completo (34/42 pts)
├── Bugs: ████████████░░░░░░░░ 60% completo (7/12 pts)
├── Dívida Téc:█████████░░░░░░░░░░░ 50% completo (3/6 pts)
└── Geral: ███████████████░░░░░ 73% completo
Métricas de Bugs:
├── Bugs Abertos: 23 (↓5 desde início do sprint)
├── P0/P1 Abertos: 2 (meta: 0)
├── Bugs Corrigidos Este Sprint: 9
├── Novos Bugs Este Sprint: 4
├── Mudança Líquida de Bugs: -5 (bom!)
└── Taxa de Escape de Bugs: 2% (1 bug por 50 features)
Tendência de Qualidade (Últimos 6 Sprints):
───────────────────────────────────────────
Sprint │ Features │ Bugs │ Bugs Líq │ Taxa Escape
───────┼──────────┼──────┼──────────┼────────────
10 │ 38 pts │ 12 │ +3 │ 5%
11 │ 42 pts │ 10 │ -2 │ 4%
12 │ 45 pts │ 8 │ -4 │ 3%
13 │ 40 pts │ 14 │ +2 │ 4%
14 │ 44 pts │ 11 │ -3 │ 2%
15 │ 42 pts │ 12 │ -5 │ 2%
Tendência: Contagem de bugs diminuindo, taxa de escape melhorando ✓
Melhores Práticas
Para Product Owners
- Orçar para bugs — Incluir alocação de bugs no planejamento
- Priorizar por impacto — Nem todos os bugs são iguais
- Aceitar trade-offs — Não dá para corrigir todos os bugs imediatamente
- Comunicar equilíbrio — Explicar aos stakeholders por que bugs importam
- Rastrear tendências — Monitorar contagens de bugs ao longo do tempo
Para Desenvolvedores
- Ser dono dos seus bugs — Ter orgulho do trabalho de qualidade
- Escrever testes primeiro — Prevenir bugs antes de acontecerem
- Investigar a fundo — Encontrar causa raiz, não só sintomas
- Compartilhar conhecimento — Ajudar time a aprender com bugs
- Equilibrar justamente — Fazer seu turno no duty de bugs
Para Team Leads
- Definir alocação clara — Definir e comunicar percentuais
- Rotacionar justamente — Ninguém deve se sentir destacado
- Reconhecer trabalho de qualidade — Celebrar vitórias de bugs
- Monitorar equilíbrio — Ajustar alocação baseado em métricas
- Construir cultura — Fazer trabalho de bugs ser valorizado, não punido