6 min leitura • Guide 663 of 877
Como Usar GitScrum para Projetos de Desenvolvimento de Grande Escala
Projetos de grande escala requerem coordenação entre múltiplos times enquanto preservam autonomia e agilidade do time. O GitScrum fornece visibilidade de portfólio, rastreamento de dependências cross-team e relatórios a nível de programa que ajudam organizações a gerenciar complexidade sem sacrificar velocidade.
Estrutura de Programa
Organização de Times
ESTRUTURA DE PROJETO DE GRANDE ESCALA:
┌─────────────────────────────────────────────────────────────┐
│ PROGRAMA: Reconstrução Plataforma E-Commerce │
├─────────────────────────────────────────────────────────────┤
│ │
│ GESTÃO DO PROGRAMA: │
│ • Product Manager: Visão geral & prioridades │
│ • Program Manager: Coordenação cross-team │
│ • Architecture Lead: Alinhamento técnico │
│ │
│ TIME: CATÁLOGO (6 engenheiros) │
│ Owner: Listagens de produtos, busca, categorias │
│ ├── Trabalho de sprint │
│ └── Dependências: Search, Platform │
│ │
│ TIME: CHECKOUT (5 engenheiros) │
│ Owner: Carrinho, pagamento, processamento de pedidos │
│ ├── Trabalho de sprint │
│ └── Dependências: Catalog, Platform, Payments │
│ │
│ TIME: PLATFORM (4 engenheiros) │
│ Owner: Serviços compartilhados, infraestrutura │
│ ├── Trabalho de sprint │
│ └── Dependências: (enabler para todos os times) │
│ │
│ TIME: MOBILE (5 engenheiros) │
│ Owner: Apps iOS e Android │
│ ├── Trabalho de sprint │
│ └── Dependências: Todos os times de API │
└─────────────────────────────────────────────────────────────┘
Visão de Portfólio
DASHBOARD DE PORTFÓLIO DO PROGRAMA:
┌─────────────────────────────────────────────────────────────┐
│ Reconstrução Plataforma E-Commerce - Q1 2024 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ÉPICO: Nova Experiência de Busca │
│ [████████████████████░░░░░] 80% │
│ Times: Catalog, Platform | Risco: Baixo │
│ │
│ ÉPICO: Redesign do Checkout │
│ [████████████░░░░░░░░░░░░░] 50% │
│ Times: Checkout, Platform | Risco: Médio (atraso API) │
│ │
│ ÉPICO: App Mobile v3 │
│ [██████░░░░░░░░░░░░░░░░░░░] 25% │
│ Times: Mobile, Todos API | Risco: Alto (dependências) │
│ │
│ ÉPICO: Otimização de Performance │
│ [████████████████████████░] 95% │
│ Times: Platform | Risco: Baixo │
│ │
│ RESUMO: │
│ Total Stories: 245 | Completadas: 156 | Em Progresso: 42 │
│ Velocidade Sprint: 89 pts (média entre times) │
│ Dependências Resolvidas: 23/28 │
└─────────────────────────────────────────────────────────────┘
Gestão de Dependências
Tipos de Dependências
CATEGORIAS DE DEPENDÊNCIAS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DEPENDÊNCIAS DE API: │
│ Time A precisa de API do Time B │
│ Gestão: Definir contrato cedo, mock enquanto espera │
│ │
│ DEPENDÊNCIAS DE COMPONENTE: │
│ Time A precisa de componente compartilhado do Time B │
│ Gestão: Ownership de component library claro │
│ │
│ DEPENDÊNCIAS DE DADOS: │
│ Time A precisa de pipeline de dados do Time B │
│ Gestão: Versionamento de schema, planos de migração │
│ │
│ DEPENDÊNCIAS DE SKILL: │
│ Time A precisa de expertise de membro do Time B │
│ Gestão: Cross-training, alocação temporária │
│ │
│ DEPENDÊNCIAS DE INFRAESTRUTURA: │
│ Time A precisa de ambiente da Platform │
│ Gestão: Self-service onde possível │
└─────────────────────────────────────────────────────────────┘
Rastreamento de Dependências
BOARD DE DEPENDÊNCIAS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ AGUARDANDO COMPROMETIDO ENTREGUE │
├──────────────────┬─────────────────┬────────────────────────┤
│ │ │ │
│ ⚠️ Mobile precisa│ ✓ Checkout │ ✓ Search API v2 │
│ Catalog API │ precisa │ (Catalog → Mobile) │
│ v2 (bloqueado │ gateway de │ │
│ 3 dias) │ pagamento │ ✓ Atualização auth │
│ │ (ETA: 20 Jan) │ service │
│ ⚠️ Checkout │ │ (Platform → Todos) │
│ precisa schema │ ✓ Mobile │ │
│ update │ precisa push │ │
│ (aguardando │ notification │ │
│ review) │ (ETA: 25 Jan) │ │
│ │ │ │
└──────────────────┴─────────────────┴────────────────────────┘
Coordenação Cross-Team
CERIMÔNIAS DE COORDENAÇÃO
SCRUM OF SCRUMS (2x/semana, 30 min):
┌─────────────────────────────────────────────────────────────┐
│ Participantes: 1 rep de cada time + Program Manager │
│ │
│ Agenda: │
│ ├── O que cada time completou desde último sync │
│ ├── O que cada time vai fazer até próximo sync │
│ ├── Bloqueios cross-team │
│ └── Updates de dependências │
│ │
│ Regra: Resolver em 30 min ou agendar follow-up │
└─────────────────────────────────────────────────────────────┘
PI PLANNING (trimestral, 2 dias):
┌─────────────────────────────────────────────────────────────┐
│ Participantes: Todos os times do programa │
│ │
│ Dia 1: │
│ ├── Visão de negócio (30 min) │
│ ├── Visão arquitetural (30 min) │
│ ├── Times fazem planning (resto do dia) │
│ └── Draft review │
│ │
│ Dia 2: │
│ ├── Ajustes de planning │
│ ├── Identificação de riscos │
│ ├── Votação de confiança │
│ └── Compromissos finais │
└─────────────────────────────────────────────────────────────┘
Resolução de Conflitos
PROCESSO DE RESOLUÇÃO DE CONFLITOS
CONFLITO DE PRIORIDADE:
┌─────────────────────────────────────────────────────────────┐
│ Sintoma: Time A e Time B ambos precisam de recurso X │
│ │
│ Escalação: │
│ 1. Times tentam resolver entre si │
│ 2. Se não resolver → Program Manager │
│ 3. Se estratégico → Product Management │
│ │
│ Critérios de decisão: │
│ • Impacto em cliente │
│ • Custo de atraso │
│ • Dependências downstream │
└─────────────────────────────────────────────────────────────┘
CONFLITO TÉCNICO:
┌─────────────────────────────────────────────────────────────┐
│ Sintoma: Desacordo sobre abordagem técnica │
│ │
│ Escalação: │
│ 1. Discussão técnica entre leads │
│ 2. Se não resolver → Architecture Lead │
│ 3. Documentar decisão como ADR │
└─────────────────────────────────────────────────────────────┘
Métricas de Programa
DASHBOARD DE MÉTRICAS DO PROGRAMA
MÉTRICAS DE ENTREGA:
┌─────────────────────────────────────────────────────────────┐
│ Velocidade do Programa: 89 pts/sprint │
│ Previsibilidade: 85% (features entregues vs planejadas) │
│ Lead Time (feature → produção): 18 dias │
│ Cycle Time médio: 5 dias │
└─────────────────────────────────────────────────────────────┘
MÉTRICAS DE DEPENDÊNCIAS:
┌─────────────────────────────────────────────────────────────┐
│ Total de dependências: 28 │
│ Resolvidas: 23 (82%) │
│ Bloqueando: 2 │
│ Tempo médio de resolução: 4 dias │
└─────────────────────────────────────────────────────────────┘
MÉTRICAS DE QUALIDADE:
┌─────────────────────────────────────────────────────────────┐
│ Bugs em produção: 3 (este sprint) │
│ Cobertura de testes: 78% │
│ Incidentes P1: 0 │
│ Tech debt ratio: 15% │
└─────────────────────────────────────────────────────────────┘