Coordinación a Escala

La coordinación entre ARTs es donde Large Solution SAFe demuestra su valor—o falla. Varios patrones ayudan:

1. Comunidades de Práctica (CoPs) — Grupos entre ARTs organizados en torno a habilidades o dominios (por ejemplo, CoP de frontend, CoP de seguridad, CoP de ingeniería de datos). Las CoPs comparten conocimiento, alinean estándares y reducen la duplicación. Se reúnen regularmente pero no son dueñas de la entrega—los equipos sí.

2. Servicios Compartidos — Equipos pequeños que proporcionan capacidades utilizadas por todos los ARTs. Ejemplos: equipo de plataforma, equipo de DevOps/SRE, equipo de plataforma de datos. Estos equipos operan en su propia cadencia pero se alinean con el ritmo de PI del Solution Train.

3. Equipos de Sistema — Equipos dedicados que son dueños de la integración, infraestructura de construcción y pruebas a nivel de sistema. Aseguran que el pipeline de CI/CD a nivel de solución funcione y mantienen los entornos de integración.

4. Gestión de Lanzamientos — Coordinar cuándo y cómo se lanza la solución. En soluciones grandes, el lanzamiento puede ocurrir en una cadencia diferente a la cadencia de PI. Un lanzamiento puede incluir trabajo de múltiples PIs, o el trabajo de un PI puede lanzarse de forma incremental.

5. Consejos de Arquitectura — Los Arquitectos de Solución de todos los ARTs se reúnen regularmente para alinearse en la dirección arquitectónica, resolver decisiones técnicas entre ARTs y mantener la pista de arquitectura a nivel de solución.

El hilo común: estos patrones crean estructuras de coordinación ligeras y persistentes que operan continuamente, no solo durante los eventos de planificación. La Planificación de PI es esencial, pero no es suficiente—la coordinación debe ocurrir también entre eventos de planificación.

Muchas soluciones grandes involucran proveedores externos—vendedores de hardware, proveedores de software de terceros, equipos de desarrollo externalizados. Coordinar con proveedores añade complejidad porque tienes menos control.

Estrategias para la coordinación con proveedores:

1. Alinear en cadencia: Si es posible, alinea la cadencia de entrega del proveedor con tu cadencia de PI. Incluso si el proveedor no usa SAFe, los puntos de entrega regulares crean oportunidades de integración.

2. Definir contratos como interfaces: En lugar de especificar cómo debe trabajar el proveedor, define contratos de interfaz claros (APIs, protocolos, formatos de datos). Prueba contra el contrato, no contra la implementación.

3. Incluir representantes del proveedor en la Planificación de PI: Invita a contactos clave del proveedor a la Planificación Pre-PI y Post-PI. No necesitan asistir a toda la Planificación de PI del ART, pero necesitan visibilidad de los planes y dependencias.

4. Crear stubs de integración: Construye versiones simuladas de componentes del proveedor para que tus equipos puedan desarrollar y probar sin esperar lo real. Esto desacopla tu ritmo de desarrollo del ritmo del proveedor.

5. Puntos de control de integración regulares: Programa sesiones de integración regulares (semanales o quincenales) donde tu sistema se integre con entregables reales del proveedor. No esperes hasta el final del PI.

La coordinación con proveedores es a menudo la parte más frustrante de Large Solution SAFe porque no puedes dictar cómo trabajan las organizaciones externas. Enfócate en lo que puedes controlar: definiciones de interfaz, pruebas de integración y comunicación clara de expectativas.

Los límites de los ARTs no son permanentes. A medida que el producto y la organización evolucionan, puede que necesites reorganizar:

Señales de que debes dividir un ART:

• Más de 12 equipos—el ART es demasiado grande para una Planificación de PI efectiva
• Existen dos flujos de valor distintos dentro de un ART
• La mayoría de las dependencias están dentro de subgrupos, no a través de todo el ART
• El System Demo se ha vuelto demasiado largo y sin enfoque

Señales de que debes fusionar ARTs:

• Dos ARTs tienen dependencias extensas que crean sobrecarga de coordinación constante
• Un flujo de valor ha sido dividido artificialmente entre ARTs
• Un ART es demasiado pequeño (menos de 3 equipos) para justificar la sobrecarga
• Los equipos son frecuentemente "prestados" entre ARTs

Señales de que los límites de tu ART están mal:

• Las dependencias entre ARTs superan en número a las dependencias dentro del ART
• Los ARTs no se alinean con la arquitectura (violación de la Ley de Conway)
• La Planificación de PI produce más cadenas de dependencia inter-ART que intra-ART

Reorganizar ARTs es disruptivo, así que no lo hagas casualmente. Pero tampoco lo evites—vivir con límites incorrectos crea un impuesto de coordinación continuo que se acumula cada PI. El mejor momento para reorganizar es en un límite de PI.