Coordenação em Escala

A coordenação entre ARTs é onde o Large Solution SAFe demonstra seu valor—ou falha. Vários padrões ajudam:

1. Comunidades de Prática (CoPs) — Grupos entre ARTs organizados em torno de habilidades ou domínios (por exemplo, CoP de frontend, CoP de segurança, CoP de engenharia de dados). As CoPs compartilham conhecimento, alinham padrões e reduzem duplicação. Elas se reúnem regularmente, mas não são responsáveis pela entrega—as equipes são.

2. Serviços Compartilhados — Pequenas equipes que fornecem capacidades usadas por todos os ARTs. Exemplos: equipe de plataforma, equipe de DevOps/SRE, equipe de plataforma de dados. Essas equipes operam em sua própria cadência, mas se alinham com o ritmo de PI do Solution Train.

3. Equipes de Sistema — Equipes dedicadas que são responsáveis pela integração, infraestrutura de build e testes em nível de sistema. Elas garantem que o pipeline de CI/CD em nível de solução funcione e mantêm ambientes de integração.

4. Gestão de Releases — Coordenar quando e como a solução é liberada. Em soluções grandes, o release pode acontecer em uma cadência diferente da cadência de PI. Um release pode incluir trabalho de múltiplos PIs, ou o trabalho de um PI pode ser liberado incrementalmente.

5. Conselhos de Arquitetura — Arquitetos de Solução de todos os ARTs se reúnem regularmente para alinhar a direção arquitetural, resolver decisões técnicas entre ARTs e manter a pista de arquitetura em nível de solução.

O fio condutor: esses padrões criam estruturas de coordenação leves e persistentes que operam continuamente, não apenas durante eventos de planejamento. O PI Planning é essencial, mas não é suficiente—a coordenação deve acontecer também entre os eventos de planejamento.

Muitas soluções grandes envolvem fornecedores externos—fabricantes de hardware, provedores de software de terceiros, equipes de desenvolvimento terceirizadas. Coordenar com fornecedores adiciona complexidade porque você tem menos controle.

Estratégias para coordenação com fornecedores:

1. Alinhar a cadência: Se possível, alinhe a cadência de entrega do fornecedor com sua cadência de PI. Mesmo que o fornecedor não use SAFe, pontos de entrega regulares criam oportunidades de integração.

2. Definir contratos como interfaces: Em vez de especificar como o fornecedor deve trabalhar, defina contratos de interface claros (APIs, protocolos, formatos de dados). Teste contra o contrato, não contra a implementação.

3. Incluir representantes de fornecedores no PI Planning: Convide contatos-chave de fornecedores para o Pre-PI e Post-PI Planning. Eles não precisam participar de todo o PI Planning do ART, mas precisam de visibilidade sobre planos e dependências.

4. Criar stubs de integração: Construa versões simuladas de componentes de fornecedores para que suas equipes possam desenvolver e testar sem esperar pela versão real. Isso desacopla seu ritmo de desenvolvimento do ritmo do fornecedor.

5. Pontos de verificação de integração regulares: Agende sessões de integração regulares (semanais ou quinzenais) onde seu sistema se integra com entregas reais do fornecedor. Não espere até o final do PI.

A coordenação com fornecedores é frequentemente a parte mais frustrante do Large Solution SAFe porque você não pode determinar como organizações externas trabalham. Concentre-se no que você pode controlar: definições de interface, testes de integração e comunicação clara de expectativas.

Os limites de ART não são permanentes. À medida que o produto e a organização evoluem, você pode precisar reorganizar:

Sinais de que você deve dividir um ART:

• Mais de 12 equipes—o ART é grande demais para um PI Planning eficaz
• Dois fluxos de valor distintos existem dentro de um ART
• A maioria das dependências está dentro de subgrupos, não em todo o ART
• A Demo do Sistema ficou longa demais e sem foco

Sinais de que você deve mesclar ARTs:

• Dois ARTs têm dependências extensas que criam sobrecarga constante de coordenação
• Um fluxo de valor foi artificialmente dividido entre ARTs
• Um ART é pequeno demais (menos de 3 equipes) para justificar a sobrecarga
• Equipes são frequentemente "emprestadas" entre ARTs

Sinais de que os limites do seu ART estão errados:

• Dependências entre ARTs superam as dependências dentro do ART
• ARTs não se alinham com a arquitetura (violação da Lei de Conway)
• O PI Planning produz mais strings de dependência inter-ART do que intra-ART

Reorganizar ARTs é disruptivo, então não faça isso casualmente. Mas também não evite—viver com limites errados cria um imposto de coordenação contínuo que se acumula a cada PI. O melhor momento para reorganizar é em um limite de PI.