Simyl
simylflow
Inicio del curso
Módulo 4: Solución Grande
Lección 1 de 3
18 min

El Tren de Solución

Coordinación de múltiples ARTs cuando el producto es demasiado grande para un solo tren.

1Cuándo Necesitas un Tren de Solución

La mayoría de las organizaciones no necesitan el nivel de Solución Grande. Essential SAFe (un ART) maneja la mayoría de los escenarios de escalamiento. Necesitas un Tren de Solución cuando:

  • El producto requiere múltiples ARTs (más de 200 personas) para construir y mantener
  • Existen dependencias significativas entre ARTs que no pueden eliminarse mediante arquitectura
  • El sistema incluye hardware, firmware o proveedores externos que deben integrarse con software
  • Los requisitos regulatorios exigen cumplimiento coordinado a través de múltiples trenes

Ejemplos de sistemas que a menudo necesitan Trenes de Solución:

  • Plataformas de vehículos autónomos (percepción + planificación + control + infraestructura)
  • Plataformas financieras grandes (operaciones + riesgo + cumplimiento + datos)
  • Sistemas de telecomunicaciones (red + facturación + experiencia del cliente)
  • Sistemas militares/aeroespaciales (hardware + firmware + software + integración)

El indicador clave: Si tus ARTs están constantemente bloqueados entre sí y la gestión de dependencias consume tiempo significativo del RTE, es posible que necesites la estructura de coordinación que proporciona un Tren de Solución.

No Optimices Prematuramente

No crees un Tren de Solución 'por si acaso'. Comienza con ARTs independientes. Solo agrega la capa de Tren de Solución cuando el dolor de coordinación entre ARTs sea real y medible. La sobrecarga es significativa.

2Estructura del Tren de Solución

El Tren de Solución se sitúa por encima de los ARTs y proporciona coordinación entre ellos. Su estructura refleja la del ART, pero a un nivel superior:

Ingeniero del Tren de Solución (STE) — El equivalente del RTE para el Tren de Solución. Facilita eventos a nivel de Solución, gestiona riesgos entre ARTs y asegura que los trenes permanezcan alineados. Este es un rol extremadamente exigente que requiere comprensión técnica profunda y habilidades excepcionales de facilitación.

Gestión de Solución — El equivalente de Gestión de Producto. Define la visión y hoja de ruta de la solución. Divide iniciativas grandes en capacidades que se asignan a los ARTs. Trabaja con la Gestión de Producto en cada ART para asegurar la alineación.

Arquitecto/Ingeniero de Solución — Define la arquitectura general a través de todos los ARTs. Asegura coherencia técnica, gestiona interfaces entre subsistemas y mantiene la pista arquitectónica a nivel de solución. Debe equilibrar la autonomía del ART con la consistencia a nivel de sistema.

Backlog de Solución — Contiene capacidades (comportamientos grandes de la solución que abarcan ARTs) y habilitadores a nivel de solución. Las capacidades se descomponen en características que los ARTs individuales implementan.

El Tren de Solución no reemplaza las estructuras a nivel de ART, sino que agrega una capa de coordinación encima. Cada ART todavía tiene su propio RTE, Gestión de Producto y Arquitecto de Sistema. Los roles del Tren de Solución coordinan a través de estos roles del ART.

3Eventos del Tren de Solución

El Tren de Solución tiene su propia cadencia de eventos que envuelven los eventos del ART:

Planificación Pre-PI (1 día, antes de la Planificación PI del ART) — Los interesados a nivel de solución se alinean sobre la visión y las principales capacidades para el próximo PI. La Gestión de Solución presenta prioridades. El Arquitecto de Solución presenta la dirección técnica. Se identifican dependencias entre ARTs. El resultado alimenta el evento de Planificación PI de cada ART.

Planificación PI del ART (2 días, como es normal) — Cada ART ejecuta su Planificación PI estándar, pero ahora informado por el resultado de la Planificación Pre-PI. Los ARTs conocen las prioridades a nivel de solución y las dependencias entre ARTs.

Planificación Post-PI (1 día, después de que todos los ARTs planifican) — Representantes de todos los ARTs se reúnen para alinear planes, resolver dependencias restantes y crear los objetivos PI a nivel de solución. El Tren de Solución hace una votación de confianza sobre el plan integrado.

Demo de Solución (final del PI) — Como el Demo del Sistema pero a nivel de solución. Todos los ARTs demuestran su contribución integrada a la solución general. Esto prueba que el sistema funciona de extremo a extremo a través de todos los trenes.

Sincronización del Tren de Solución (semanal) — Los STEs y RTEs se reúnen para gestionar la coordinación entre ARTs, identificar impedimentos y rastrear el progreso a nivel de solución.

La cadencia agrega sobrecarga (Pre-PI, Post-PI), pero esta sobrecarga es el precio de coordinar más de 200 personas en un producto compartido. Sin ella, obtienes caos de integración al final de cada PI.

Viajes para Planificación Pre/Post-PI

Si tus ARTs están distribuidos geográficamente, vale la pena hacer volar a las personas para la Planificación Pre-PI y Post-PI. El valor de coordinación de la interacción cara a cara a este nivel es enorme. El trabajo remoto funciona para sincronizaciones diarias; la planificación se beneficia de la proximidad.

Conclusiones clave
  • Los Trenes de Solución coordinan múltiples ARTs que construyen un producto grande
  • Roles clave: STE, Gestión de Solución, Arquitecto de Solución
  • La Planificación Pre-PI y Post-PI envuelve la Planificación PI del ART con alineación a nivel de solución
  • Solo agrega la capa de Tren de Solución cuando el dolor de coordinación entre ARTs sea real