8 min leitura • Guide 100 of 877
Balanceando Desenvolvimento de Features com Correção de Bugs
Toda equipe de desenvolvimento enfrenta a tensão entre construir novas features e corrigir bugs existentes. A configuração de boards do GitScrum, sistema de labels, e ferramentas de planejamento de sprint ajudam times a encontrar o equilíbrio certo tornando trabalho de bugs visível, estabelecendo políticas de alocação, e criando processos que previnem bugs de serem perpetuamente despriorizados enquanto entrega valor ao cliente.
Entendendo a Tensão
O Problema do Equilíbrio
PRIORIDADES COMPETINDO:
┌─────────────────────────────────────────────────────────────┐
│ POR QUE EQUILIBRAR É DIFÍCIL │
├─────────────────────────────────────────────────────────────┤
│ │
│ PRESSÃO DE FEATURES: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Compromissos de roadmap com stakeholders ││
│ │ • Pressão competitiva para enviar ││
│ │ • Novas features = progresso visível ││
│ │ • Revenue atrelado a entrega de features ││
│ │ • Trabalho mais "empolgante" para time ││
│ │ ││
│ │ Resultado: Bugs são empurrados para "depois" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PRESSÃO DE BUGS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ • Reclamações clientes e churn ││
│ │ • Volume tickets suporte ││
│ │ • Dívida técnica desacelerando desenvolvimento ││
│ │ • Moral time (trabalhando em produto quebrado) ││
│ │ • Riscos segurança e compliance ││
│ │ ││
│ │ Resultado: "Falência de bugs" se ignorado muito ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ A ESPIRAL DA MORTE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Pular bugs → Enviar features → ││
│ │ Mais bugs aparecem → Pular bugs → ││
│ │ Enviar features mais rápido (pressão) → ││
│ │ Ainda mais bugs → Produto desestabiliza → ││
│ │ Features não podem enviar (tudo quebra) → ││
│ │ Sprint emergência bugs → Time esgota ││
│ │ ││
│ │ Quebrar o ciclo requer alocação intencional ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Estratégias Alocação
Alocação Percentual
ABORDAGEM ALOCAÇÃO FIXA:
┌─────────────────────────────────────────────────────────────┐
│ DIVISÃO CAPACIDADE SPRINT │
├─────────────────────────────────────────────────────────────┤
│ │
│ MODELO: 70/20/10 │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Capacidade Sprint: 80 story points ││
│ │ ││
│ │ ┌─────────────────────────────────────────────────┐ ││
│ │ │ FEATURES │ 56 pts │ ││
│ │ │ (Itens roadmap, capacidades novas) │ 70% │ ││
│ │ ├───────────────────────────────────────┼────────┤ ││
│ │ │ BUGS │ 16 pts │ ││
│ │ │ (Defeitos, regressões, qualidade) │ 20% │ ││
│ │ ├───────────────────────────────────────┼────────┤ ││
│ │ │ DÍVIDA TÉCNICA │ 8 pts │ ││
│ │ │ (Refactoring, tooling, upgrades) │ 10% │ ││
│ │ └───────────────────────────────────────┴────────┘ ││
│ │ ││
│ │ NO GITSCRUM: ││
│ │ • Usar labels: type/feature, type/bug, type/tech-debt ││
│ │ • Filtrar por labels para verificar alocação ││
│ │ • Rastrear no analytics do sprint ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ AJUSTANDO BASEADO EM ESTADO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Estado │ Features │ Bugs │ Dívida Técnica ││
│ │ ───────────────┼──────────┼──────┼─────────── ││
│ │ Saudável │ 70% │ 20% │ 10% ││
│ │ Backlog bugs │ 60% │ 30% │ 10% ││
│ │ Estabilização │ 50% │ 40% │ 10% ││
│ │ Crise │ 30% │ 60% │ 10% ││
│ │ Pós-crise │ 80% │ 15% │ 5% ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Dias/Rotação Bugs
TEMPO DEDICADO BUGS:
┌─────────────────────────────────────────────────────────────┐
│ ABORDAGENS ROTAÇÃO │
├─────────────────────────────────────────────────────────────┤
│ │
│ OPÇÃO 1: DIA DE BUGS │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Toda sexta: Dia de correção bugs ││
│ │ ││
│ │ Regras: ││
│ │ • Time todo trabalha em bugs ││
│ │ • Sem trabalho de features permitido ││
│ │ • Triage de manhã, corrigir o dia todo ││
│ │ • Celebrar fixes no final do dia ││
│ │ ││
│ │ Benefícios: ││
│ │ • Tempo bugs previsível ││
│ │ • Sem troca contexto durante semana ││
│ │ • Ritual time constrói cultura ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ OPÇÃO 2: ROTAÇÃO BUGS │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Cada sprint: Um desenvolvedor de plantão bugs ││
│ │ ││
│ │ Regras: ││
│ │ • Rotaciona cada sprint ││
│ │ • Plantão bugs = só bugs, sem features ││
│ │ • Lidar bugs críticos imediatamente ││
│ │ • Trabalhar através do backlog priorizado ││
│ │ ││
│ │ Benefícios: ││
│ │ • Resposta rápida a bugs críticos ││
│ │ • Foco dedicado (sem atenção dividida) ││
│ │ • Todos aprendem todas áreas do código ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ OPÇÃO 3: SPRINT DE BUGS │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ A cada 4º sprint: Sprint só bugs ││
│ │ ││
│ │ Regras: ││
│ │ • Sprint inteiro dedicado a qualidade ││
│ │ • Bugs, dívida técnica, melhorias testing ││
│ │ • Sem features novas ││
│ │ ││
│ │ Melhor para: Times com dívida significativa acumulada ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Priorização Bugs
Severidade e Prioridade
CLASSIFICAÇÃO BUGS:
┌─────────────────────────────────────────────────────────────┐
│ SEVERIDADE VS PRIORIDADE │
├─────────────────────────────────────────────────────────────┤
│ │
│ SEVERIDADE (Impacto do bug): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ S1 - CRÍTICO: ││
│ │ • Perda ou corrupção dados ││
│ │ • Vulnerabilidade segurança ││
│ │ • Feature completa quebrada ││
│ │ • Sem workaround possível ││
│ │ ││
│ │ S2 - ALTO: ││
│ │ • Feature maior significativamente degradada ││
│ │ • Workaround existe mas doloroso ││
│ │ • Afeta muitos usuários ││
│ │ ││
│ │ S3 - MÉDIO: ││
│ │ • Feature funciona mas com problemas ││
│ │ • Workaround fácil disponível ││
│ │ • Afeta alguns usuários ││
│ │ ││
│ │ S4 - BAIXO: ││
│ │ • Problemas cosméticos ││
│ │ • Casos edge ││
│ │ • Impacto usuário mínimo ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PRIORIDADE (Quando corrigir): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ P1: Corrigir imediatamente (largar tudo) ││
│ │ P2: Corrigir este sprint ││
│ │ P3: Corrigir em breve (próximos 2-3 sprints) ││
│ │ P4: Corrigir eventualmente (backlog) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ MAPEAMENTO SEVERIDADE → PRIORIDADE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ │ Muitos Users │ Alguns Users │ Poucos Users ││
│ │ ─────────┼──────────────┼──────────────┼─────────── ││
│ │ S1 Crít │ P1 │ P1 │ P2 ││
│ │ S2 Alto │ P1 │ P2 │ P2 ││
│ │ S3 Med │ P2 │ P3 │ P3 ││
│ │ S4 Baixo │ P3 │ P4 │ P4 ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Planejamento Sprint
Seleção Bugs
PLANEJANDO PARA BUGS:
┌─────────────────────────────────────────────────────────────┐
│ ABORDAGEM PLANEJAMENTO SPRINT │
├─────────────────────────────────────────────────────────────┤
│ │
│ ANTES DO PLANEJAMENTO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Triage backlog bugs ││
│ │ • Atualizar prioridades ││
│ │ • Fechar duplicados/inválidos ││
│ │ • Adicionar estimativas esforço ││
│ │ ││
│ │ 2. Calcular orçamento bugs ││
│ │ • Capacidade total × porcentagem bugs ││
│ │ • Exemplo: 80 pontos × 20% = 16 pontos para bugs ││
│ │ ││
│ │ 3. Pré-selecionar candidatos ││
│ │ • Bugs P1/P2 (obrigatórios) ││
│ │ • Bugs P3 mais antigos ││
│ │ • Bugs relacionados com features do sprint ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DURANTE PLANEJAMENTO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Começar com bugs obrigatórios (P1/P2) ││
│ │ • Não negociáveis, devem caber ││
│ │ • Se muitos, escalar problema capacidade ││
│ │ ││
│ │ 2. Preencher orçamento bugs restante ││
│ │ • Escolher de candidatos P3 ││
│ │ • Considerar: idade, impacto cliente, trabalho relac.││
│ │ ││
│ │ 3. Planejar features com capacidade restante ││
│ │ ││
│ │ 4. Verificar equilíbrio ││
│ │ • Alocação corresponde a percentuais objetivo? ││
│ │ • Ajustar se necessário ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘