7 min leitura • Guide 507 of 877
Como Gerenciar Projetos de Manutenção de Sistemas Legados
Sistemas legados requerem manutenção contínua enquanto times simultaneamente planejam esforços de modernização. O GitScrum ajuda organizações a equilibrar essas demandas concorrentes fornecendo boards separados para manutenção e modernização, frameworks claros de priorização e rastreamento que garante que atualizações críticas não se percam em meio ao desenvolvimento de features.
Categorias de Sistemas Legados
| Tipo | Características | Estratégia |
|---|---|---|
| Crítico estável | Essencial ao negócio, raramente muda | Manter cuidadosamente |
| Crítico instável | Essencial ao negócio, problemas frequentes | Priorizar modernização |
| Não-crítico estável | Funciona bem, não estratégico | Manter minimamente |
| Não-crítico instável | Causa dor, não essencial | Considerar aposentadoria |
Framework de Manutenção Legada
ABORDAGEM DE GESTÃO DE SISTEMAS LEGADOS
1. AVALIAÇÃO
┌─────────────────────────────────────────────────┐
│ Para cada sistema legado: │
│ ├── Criticidade de negócio (1-5) │
│ ├── Saúde técnica (1-5) │
│ ├── Custo de manutenção (R$/mês) │
│ ├── Disponibilidade de especialistas │
│ ├── Nível de risco de segurança │
│ └── Dependências de integração │
│ │
│ Output: Inventário de sistemas legados │
└─────────────────────────────────────────────────┘
2. CLASSIFICAÇÃO
┌─────────────────────────────────────────────────┐
│ │
│ Alta Criticidade │
│ │ │
│ ┌──────────┼──────────┐ │
│ │ INVESTIR │MODERNIZAR│ │
│ │ (estável)│ (urgente)│ │
│ │ │ │ │
│ ├──────────┼──────────┤ │
│ │ MANTER │APOSENTAR │ │
│ │ (mínimo) │(planejar)│ │
│ └──────────┴──────────┘ │
│ Boa Saúde │ Saúde Ruim │
│ │
└─────────────────────────────────────────────────┘
3. ALOCAÇÃO DE RECURSOS
┌─────────────────────────────────────────────────┐
│ Alocação de capacidade do time: │
│ ├── Novo desenvolvimento: 60-70% │
│ ├── Manutenção legada: 20-30% │
│ └── Projetos de modernização: 10-20% │
│ │
│ Ajustar baseado na estabilidade do sistema │
└─────────────────────────────────────────────────┘
Gestão de Tarefas para Trabalho Legado
TRABALHO LEGADO NO GITSCRUM
ESTRUTURA DO PROJETO:
┌─────────────────────────────────────────────────┐
│ Projeto: Manutenção de Sistemas Legados │
│ │
│ Labels: │
│ ├── [legado-critico] - Issues de produção │
│ ├── [legado-seguranca] - Patches de segurança │
│ ├── [legado-tech-debt] - Trabalho de melhoria │
│ └── [legado-documentacao] - Captura de conhec. │
│ │
│ Colunas do Board: │
│ ├── Entrada - Novos pedidos/issues │
│ ├── Triagem - Priorizado, agendado │
│ ├── Em Progresso - Trabalho ativo │
│ ├── Review - Code review/testes │
│ └── Concluído - Completado │
└─────────────────────────────────────────────────┘
TEMPLATE DE TAREFA:
┌─────────────────────────────────────────────────┐
│ Título: [Nome Sistema] - Descrição do Issue │
│ │
│ Sistema: Processamento de Pedidos (COBOL) │
│ Criticidade: Alta │
│ Tipo: Bug Fix / Enhancement / Segurança │
│ │
│ Contexto: │
│ Qual é o comportamento atual? │
│ O que deveria acontecer? │
│ Impacto no negócio se não endereçado? │
│ │
│ Notas Técnicas: │
│ Módulos/arquivos relevantes │
│ Especialistas conhecidos: @joao, @maria │
│ Dependências de outros sistemas │
│ │
│ Testes: │
│ Como verificar a correção │
│ Preocupações de regressão │
└─────────────────────────────────────────────────┘
Preservação de Conhecimento
GESTÃO DE CONHECIMENTO LEGADO
REQUISITOS DE DOCUMENTAÇÃO:
┌─────────────────────────────────────────────────┐
│ Para cada sistema legado: │
│ ├── Visão geral da arquitetura │
│ ├── Decisões de design e lógica │
│ ├── Procedimentos operacionais │
│ ├── Problemas conhecidos e workarounds │
│ └── Contatos de especialistas │
└─────────────────────────────────────────────────┘
ESTRATÉGIAS DE CAPTURA DE CONHECIMENTO:
┌─────────────────────────────────────────────────┐
│ Sessões de Transferência de Conhecimento: │
│ ├── Gravar walkthroughs de código │
│ ├── Documentar decisões de design │
│ ├── Capturar troubleshooting tribal │
│ └── Criar runbooks para operações │
│ │
│ Aprendizado Contínuo: │
│ ├── Pair programming com especialistas │
│ ├── Documentar cada bug fix com contexto │
│ ├── ADRs para mudanças │
│ └── Brown bag sessions sobre sistemas │
└─────────────────────────────────────────────────┘
Planejando Modernização
FRAMEWORK DE DECISÃO DE MODERNIZAÇÃO
QUANDO MODERNIZAR:
┌─────────────────────────────────────────────────┐
│ ✓ Custo de manutenção > limite aceitável │
│ ✓ Riscos de segurança não podem ser mitigados │
│ ✓ Capacidades de negócio bloqueadas │
│ ✓ Especialistas saindo/indisponíveis │
│ ✓ Requisitos de compliance não atendíveis │
│ ✓ Custo de integração muito alto │
└─────────────────────────────────────────────────┘
ESTRATÉGIAS DE MODERNIZAÇÃO:
┌─────────────────────────────────────────────────┐
│ 1. Strangler Fig Pattern │
│ • Substituir incrementalmente │
│ • Rotear tráfego gradualmente │
│ • Menor risco, maior tempo │
│ │
│ 2. Big Bang Replacement │
│ • Substituição completa │
│ • Cutover em data específica │
│ • Maior risco, menor tempo │
│ │
│ 3. Refactoring Gradual │
│ • Melhorar in-place │
│ • Manter funcionalidade │
│ • Médio risco, médio tempo │
└─────────────────────────────────────────────────┘
Estrutura de Projeto de Modernização
ÉPICO DE MODERNIZAÇÃO NO GITSCRUM
Épico: Modernizar Sistema de Pedidos (COBOL → Java)
├── Fase 1: Preparação
│ ├── Documentar estado atual
│ ├── Definir critérios de sucesso
│ ├── Criar plano de migração de dados
│ └── Estabelecer ambiente de desenvolvimento
│
├── Fase 2: Desenvolvimento Paralelo
│ ├── Implementar funcionalidades core
│ ├── Criar adapters para integração
│ ├── Desenvolver migration scripts
│ └── Testes de comparação
│
├── Fase 3: Migração Gradual
│ ├── Rotear tráfego para novo sistema
│ ├── Monitorar comportamento
│ ├── Resolver discrepâncias
│ └── Aumentar porcentagem de tráfego
│
└── Fase 4: Descomissionamento
├── Verificar paridade completa
├── Migrar dados históricos
├── Desligar sistema antigo
└── Arquivar documentação
Métricas de Manutenção Legada
INDICADORES DE SAÚDE DE SISTEMAS LEGADOS
MÉTRICAS OPERACIONAIS:
┌─────────────────────────────────────────────────┐
│ Disponibilidade: 99.5% │
│ Incidentes/mês: 3 │
│ MTTR: 4 horas │
│ Tickets de manutenção/mês: 15 │
└─────────────────────────────────────────────────┘
MÉTRICAS DE CUSTO:
┌─────────────────────────────────────────────────┐
│ Horas de manutenção/mês: 80h │
│ Custo de especialista/hora: R$200 │
│ Custo mensal total: R$16.000 │
│ Tendência: ↑ 5% por trimestre │
└─────────────────────────────────────────────────┘
MÉTRICAS DE RISCO:
┌─────────────────────────────────────────────────┐
│ Vulnerabilidades abertas: 12 │
│ Idade média de vulnerabilidade: 45 dias │
│ Especialistas disponíveis: 2 │
│ Idade do sistema: 15 anos │
└─────────────────────────────────────────────────┘
Comunicação com Stakeholders
REPORTANDO SOBRE SISTEMAS LEGADOS
RELATÓRIO EXECUTIVO:
┌─────────────────────────────────────────────────┐
│ Sistema: Processamento de Pedidos │
│ Status: ⚠️ Atenção Necessária │
│ │
│ Resumo: │
│ • Custos de manutenção subiram 15% no ano │
│ • 2 especialistas restantes (1 aposentando) │
│ • 5 vulnerabilidades críticas abertas │
│ │
│ Recomendação: │
│ Aprovar projeto de modernização no Q3 │
│ Investimento: R$500k | ROI: 18 meses │
│ │
│ Riscos de não fazer: │
│ • Impossibilidade de manutenção em 2 anos │
│ • Exposição a incidentes de segurança │
│ • Novas funcionalidades bloqueadas │
└─────────────────────────────────────────────────┘