8 min leitura • Guide 828 of 877
Release Train Engineering
Trens rodam no horário. GitScrum ajuda release train engineers a coordenar entregas cross-team, garantindo releases regulares e previsíveis.
Conceito de Release Train
Como Trens Funcionam
MODELO DE RELEASE TRAIN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ A METÁFORA DO TREM: │
│ ─────────────────── │
│ │
│ Um release train: │
│ • Sai da estação em um cronograma fixo │
│ • Leva o que estiver pronto quando parte │
│ • Não espera por features atrasadas │
│ • Próximo trem vem logo (não precisa correr para este) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CRONOGRAMA DO TREM: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ ──────────────────────────────────────────────────────► ││
│ │ ▲ Trem 1 ▲ Trem 2 ▲ Trem 3 ▲ Trem 4 ││
│ │ │ 15 Jan │ 29 Jan │ 12 Fev │ 26 Fev ││
│ │ │ │ │ │ ││
│ │ └──────────────┴──────────────┴──────────────┴────────► ││
│ │ A cada 2 semanas, no cronograma ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ FLUXO DE FEATURES: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ Feature A: ████████ Pronta ──► No Trem 1 ✓ ││
│ │ Feature B: █████████████████ Pronta ──► No Trem 2 ✓ ││
│ │ Feature C: ████████████░░░░ Não Pronta ──► Trem 3 ││
│ │ Feature D: ███ Pronta ──► No Trem 1 ✓ ││
│ │ ││
│ │ Pronta pelo cutoff = No trem ││
│ │ Não pronta = Espere próximo trem ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ BENEFÍCIOS: │
│ • Releases previsíveis │
│ • Sem esperar por "aquela feature" │
│ • Menos estresse (próximo trem vem) │
│ • Entrega de valor regular │
└─────────────────────────────────────────────────────────────┘
Release Train Engineer
Papel do RTE
RESPONSABILIDADES DO RELEASE TRAIN ENGINEER:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FACILITAÇÃO: │
│ ───────────── │
│ • Planejar e executar PI Planning │
│ • Facilitar syncs cross-team │
│ • Liderar demos do sistema │
│ • Coordenar inspect & adapt │
│ │
│ COORDENAÇÃO: │
│ ───────────── │
│ • Gerenciar dependências cross-team │
│ • Rastrear progresso em nível de programa │
│ • Coordenar integração │
│ • Alinhar cronogramas dos times │
│ │
│ GESTÃO DE RISCOS: │
│ ──────────────── │
│ • Identificar riscos do programa │
│ • Escalar bloqueios │
│ • Remover impedimentos │
│ • Garantir contingências │
│ │
│ COMUNICAÇÃO: │
│ ────────────── │
│ • Updates para stakeholders │
│ • Relatórios de status │
│ • Comunicação de release │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ RTE NÃO É: │
│ ─────────── │
│ ❌ Gerente de projeto dizendo aos times o que fazer │
│ ❌ Ponto único de falha │
│ ❌ Tomador de decisões técnicas │
│ │
│ RTE É: │
│ ───────── │
│ ✅ Líder servidor para o trem │
│ ✅ Facilitador e coordenador │
│ ✅ Removedor de bloqueios │
└─────────────────────────────────────────────────────────────┘
PI Planning
Planejamento de Program Increment
VISÃO GERAL DO PI PLANNING:
┌─────────────────────────────────────────────────────────────┐
│ │
│ O QUE É UM PI: │
│ ───────────── │
│ Program Increment = 8-12 semanas │
│ Contém múltiplos sprints (tipicamente 5-6) │
│ Termina com iteração de Inovação e Planejamento │
│ │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ PROGRAM INCREMENT (10 semanas) ││
│ │ ││
│ │ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────────────┐ ││
│ │ │ S 1 │ │ S 2 │ │ S 3 │ │ S 4 │ │ IP Sprint │ ││
│ │ │ 2sem │ │ 2sem │ │ 2sem │ │ 2sem │ │ Inovação+ │ ││
│ │ │ │ │ │ │ │ │ │ │ PI Planning │ ││
│ │ └──────┘ └──────┘ └──────┘ └──────┘ └──────────────┘ ││
│ │ ││
│ │ Cada sprint = oportunidade de partida do trem ││
│ │ IP Sprint = Inovação, planejamento, folga ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ EVENTO DE PI PLANNING (2 dias): │
│ ─────────────────────────────── │
│ Dia 1: │
│ • Contexto de negócio e visão │
│ • Visão de arquitetura │
│ • Breakouts de time: Rascunhar planos │
│ • Revisão da gestão │
│ │
│ Dia 2: │
│ • Ajustar planos │
│ • Identificar dependências │
│ • Identificação de riscos │
│ • Voto de confiança │
│ • Compromisso │
│ │
│ OUTPUT: │
│ • Objetivos do PI para cada time │
│ • Program board (dependências visualizadas) │
│ • Registro de riscos │
│ • Features comprometidas │
└─────────────────────────────────────────────────────────────┘
Gestão de Dependências
Coordenação Cross-Team
GERENCIANDO DEPENDÊNCIAS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PROGRAM BOARD: │
│ ────────────── │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ SPRINT │ S1 │ S2 │ S3 │ S4 ││
│ │ ───────────┼─────────┼─────────┼─────────┼─────────── ││
│ │ │ │ │ │ ││
│ │ TIME A │ [F1]────┼─────────┼────────►[F3] ││
│ │ │ ╲ │ │ │ ││
│ │ │ ╲ │ │ │ ││
│ │ TIME B │ ╲──┼►[F2]────┼─────────┼────► ││
│ │ │ │ │ │ ││
│ │ │ │ │ │ ││
│ │ TIME C │ │ [F4]─┼►───────►[F5] ││
│ │ │ │ │ │ ││
│ │ ───────────┴─────────┴─────────┴─────────┴─────────── ││
│ │ ││
│ │ Setas = Dependências entre times/features ││
│ │ Fio vermelho = Risco (no board físico) ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ TIPOS DE DEPENDÊNCIA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ TIPO EXEMPLO RISCO ││
│ │ ──── ─────── ───── ││
│ │ Time→Time "Precisamos da API do Time B" Alto ││
│ │ Externa "Esperando fornecedor" Muito Alto ││
│ │ Técnica "Precisa upgrade BD primeiro" Médio ││
│ │ Release "Feature A antes de B" Médio ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ RTE GERENCIA: │
│ • Identificar dependências no PI Planning │
│ • Rastrear resolução de dependências │
│ • Escalar dependências em risco │
│ • Coordenar comunicação cross-team │
└─────────────────────────────────────────────────────────────┘
Rodando o Trem
Cadência e Sincronização
CADÊNCIA DO TREM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ EVENTOS REGULARES: │
│ ─────────────── │
│ │
│ SEMANAL: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ SCRUM DE SCRUMS (30-60 min) ││
│ │ ││
│ │ Quem: Representantes dos times ││
│ │ Quando: 2-3x por semana ││
│ │ ││
│ │ Formato: ││
│ │ • O que realizamos ││
│ │ • No que estamos trabalhando ││
│ │ • Bloqueios precisando escalação ││
│ │ • Update de dependências ││
│ │ ││
│ │ RTE facilita, remove bloqueios ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ CADA SPRINT: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ DEMO DO SISTEMA (1-2 horas) ││
│ │ ││
│ │ Quem: Todos times + stakeholders ││
│ │ Quando: Final de cada sprint ││
│ │ ││
│ │ Formato: ││
│ │ • Demo do incremento integrado ││
│ │ • Mostrar funcionalidade ponta-a-ponta ││
│ │ • Coletar feedback ││
│ │ ││
│ │ Todos times integram em única demo ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ CADA PI: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ INSPECT & ADAPT (3-4 horas) ││
│ │ ││
│ │ Parte 1: Demo do Sistema do PI ││
│ │ Parte 2: Revisão de métricas quantitativas ││
│ │ Parte 3: Retrospectiva ││
│ │ Parte 4: Workshop de resolução de problemas ││
│ │ ││
│ │ Trem inteiro reflete e melhora ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Melhores Práticas
Para Release Train Engineering
- Cadência é sagrada — Trem parte no horário
- Planejamento alinhado — PI Planning efetivo
- Dependências visíveis — Program board claro
- Riscos gerenciados — Escalação proativa
- Comunicação consistente — Stakeholders informados
Anti-Padrões
ERROS DE RELEASE TRAIN:
✗ Adiar trem para feature atrasada
✗ Planejamento sem dependências mapeadas
✗ RTE como gargalo
✗ Ignorar riscos identificados
✗ Falta de demos regulares
✗ Times trabalhando isolados
✗ Sem buffer para incertezas
✗ Scope creep durante PI