6 min leitura • Guide 51 of 877
Equilibrando Desenvolvimento de Funcionalidades com Manutenção
Cada equipe de desenvolvimento enfrenta a tensão entre lançar novas funcionalidades e manter sistemas existentes. Muito foco em funcionalidades leva a dívida técnica crescente; muita manutenção significa ficar atrás dos concorrentes. O GitScrum ajuda as equipes a encontrar o equilíbrio certo.
O Desafio do Equilíbrio
| Todas Funcionalidades | Toda Manutenção |
|---|---|
| Progresso inicial rápido | Base de código limpa |
| Dívida técnica crescente | Nenhum novo valor entregue |
| Mais lento com o tempo | Frustração dos stakeholders |
| Mais incidentes | Pode perder posição no mercado |
| Frustração do desenvolvedor | Tédio do desenvolvedor |
Estratégia de Alocação de Capacidade
Divisões Recomendadas
MODELOS DE ALOCAÇÃO
═══════════════════
SISTEMA SAUDÁVEL (Baixa dívida, poucos incidentes):
├── Funcionalidades: 80%
├── Manutenção: 10%
├── Dívida Técnica: 5%
└── Inovação: 5%
DÍVIDA MODERADA:
├── Funcionalidades: 70%
├── Manutenção: 15%
└── Dívida Técnica: 15%
ALTA DÍVIDA / MUITOS INCIDENTES:
├── Funcionalidades: 50%
├── Manutenção: 25%
└── Dívida Técnica: 25%
MODO CRISE:
├── Funcionalidades: 20% (apenas críticas)
├── Manutenção: 40%
└── Dívida Técnica: 40%
Planejamento de Capacidade de Sprint
CAPACIDADE DO SPRINT 12 (40 pontos)
═══════════════════════════════════
FUNCIONALIDADES (70% = 28 pontos)
─────────────────────────────────
#123 Autenticação de usuário 8 pts
#124 Widgets do dashboard 8 pts
#125 Endpoints da API 6 pts
#126 Navegação mobile 6 pts
MANUTENÇÃO (15% = 6 pontos)
───────────────────────────
#127 Atualizar dependências 3 pts
#128 Corrigir testes instáveis 3 pts
DÍVIDA TÉCNICA (15% = 6 pontos)
──────────────────────────────
#129 Refatorar módulo auth 4 pts
#130 Adicionar monitoramento 2 pts
Etiquetagem para Visibilidade
Etiquetas de Tipo de Trabalho
CONFIGURAÇÃO DE ETIQUETAS
═════════════════════════
TIPO DE TRABALHO:
├── type:feature (verde) - Nova funcionalidade
├── type:maintenance (azul) - Manter sistemas funcionando
├── type:tech-debt (laranja) - Melhorias de qualidade do código
├── type:bug (vermelho) - Correções de defeitos
└── type:innovation (roxo) - Pesquisa, spikes
PRIORIDADE:
├── priority:critical - Fazer primeiro
├── priority:high - Este sprint
├── priority:medium - Este trimestre
└── priority:low - Quando possível
Rastreamento de Alocação
RELATÓRIO DE ALOCAÇÃO DE SPRINT
═══════════════════════════════
Sprint 11 (Concluído)
─────────────────────
Funcionalidade: 32 pts (76%) ████████████████░░░░
Manutenção: 5 pts (12%) ██░░░░░░░░░░░░░░░░░░
Dívida Técnica: 5 pts (12%) ██░░░░░░░░░░░░░░░░░░
Sprint 12 (Atual)
─────────────────
Funcionalidade: 28 pts (70%) ██████████████░░░░░░
Manutenção: 6 pts (15%) ███░░░░░░░░░░░░░░░░░
Dívida Técnica: 6 pts (15%) ███░░░░░░░░░░░░░░░░░
Tendência: ↑ Aumento da alocação de manutenção (saudável)
Tornando a Manutenção Visível
Valor de Negócio da Manutenção
RASTREAMENTO DE VALOR DE MANUTENÇÃO
═══════════════════════════════════
ATUALIZAÇÃO DE DEPENDÊNCIA (Sprint 12)
──────────────────────────────────────
Trabalho: Atualizar Node.js 18 → 20
Tempo: 3 pontos
Valor:
├── Patches de segurança incluídos
├── Melhoria de performance de 15%
├── Suporte LTS até 2025
└── Desbloqueia novas funcionalidades da biblioteca
Risco se Pulado:
├── Vulnerabilidade conhecida CVE-2024-xxxx
├── Atraso em relação ao ecossistema
└── Atualização mais difícil depois
CORREÇÃO DE TESTE INSTÁVEL (Sprint 12)
──────────────────────────────────────
Trabalho: Corrigir 5 falhas intermitentes de teste
Tempo: 3 pontos
Valor:
├── Confiabilidade do pipeline CI
├── Loops de feedback mais rápidos
├── Confiança do desenvolvedor nos testes
└── Investigações de falsos positivos reduzidas
Risco se Pulado:
├── Ignorar falhas reais
├── CI mais lento (mais tentativas)
└── Frustração do desenvolvedor
Protegendo Tempo de Manutenção
Rituais de Planejamento de Sprint
PROCESSO DE ALOCAÇÃO PROTEGIDA
══════════════════════════════
ANTES DO PLANEJAMENTO DE SPRINT:
───────────────────────────────
1. Calcular capacidade total
2. Reservar % de manutenção PRIMEIRO
3. Restante vai para funcionalidades
4. Manutenção é não-negociável
EXEMPLO:
────────
Total: 40 pontos
Reservado: 8 pontos manutenção (20%)
Disponível para funcionalidades: 32 pontos
Solicitação do stakeholder: 36 pontos de funcionalidades
Resposta: "Podemos fazer 32 pontos de funcionalidades.
8 pontos reservados para saúde do sistema."
Abordagens de Rotação
ROTAÇÃO DE MANUTENÇÃO
═════════════════════
OPÇÃO 1: Sprint Dedicado
────────────────────────
A cada 4º sprint: 50% foco em manutenção
Prós: Trabalho profundo, melhorias significativas
Contras: Queda visível na velocidade de funcionalidades
OPÇÃO 2: Alocação Por-Sprint
────────────────────────────
Cada sprint: 20% manutenção
Prós: Progresso consistente, velocidade suave
Contras: Pode não abordar itens grandes
OPÇÃO 3: Sexta-feira de Manutenção
──────────────────────────────────
Toda sexta-feira: Apenas manutenção
Prós: Previsível, fácil de proteger
Contras: Semana fragmentada
OPÇÃO 4: Atribuição de Rotação
──────────────────────────────
Uma pessoa por sprint: dever de manutenção
Prós: Foco profundo, propriedade clara
Contras: Troca de contexto para o indivíduo
Métricas para Equilíbrio
Indicadores de Saúde
DASHBOARD DE SAÚDE DO SISTEMA
═════════════════════════════
INCIDENTES:
├── Este mês: 3 (meta: <5) ✓
├── Mês passado: 7
└── Tendência: Melhorando ↓
TEMPO MÉDIO PARA RECUPERAÇÃO:
├── Este mês: 45 min (meta: <60) ✓
└── Mês passado: 72 min
FREQUÊNCIA DE IMPLANTAÇÃO:
├── Esta semana: 8 (meta: >5) ✓
└── Tempo de lead: 2 horas ✓
IDADE DAS DEPENDÊNCIAS:
├── Atualizadas: 85%
├── Pouco atrasadas: 10%
└── Muito atrasadas: 5% ⚠️
PROPORÇÃO DE DÍVIDA TÉCNICA:
├── Tarefas de dívida: 23
├── Total de tarefas: 156
└── Proporção: 15% (saudável)
Melhores Práticas
Para Equilíbrio Sustentável
- Reserve capacidade explicitamente — Não force manutenção
- Rastreie alocação — O que é medido é feito
- Conecte a resultados — Mostre que manutenção previne incidentes
- Rodeie de forma justa — Compartilhe manutenção entre equipe
- Celebre melhorias — Reconheça trabalho de saúde do sistema
Anti-Padrões
EVITE ESTES:
✗ "Faremos manutenção depois"
✗ Manutenção apenas após incidentes
✗ Manutenção oculta (chamando de funcionalidades)
✗ Mesma pessoa sempre faz manutenção
✗ Sem rastreamento de alocação de manutenção
✗ Sprints 100% funcionalidades