Il Solution Train

La maggior parte delle organizzazioni non ha bisogno del livello Large Solution. Essential SAFe (un ART) gestisce la maggioranza degli scenari di scaling. Hai bisogno di un Solution Train quando:

• Il prodotto richiede più ART (oltre 200 persone) per essere costruito e mantenuto
• Esistono dipendenze significative tra ART che non possono essere eliminate attraverso l'architettura
• Il sistema include hardware, firmware o fornitori esterni che devono integrarsi con il software
• I requisiti normativi richiedono una conformità coordinata tra più train

Esempi di sistemi che spesso necessitano di Solution Train:

• Piattaforme per veicoli autonomi (percezione + pianificazione + controllo + infrastruttura)
• Grandi piattaforme finanziarie (trading + rischio + conformità + dati)
• Sistemi di telecomunicazioni (rete + fatturazione + esperienza cliente)
• Sistemi militari/aerospaziali (hardware + firmware + software + integrazione)

L'indicatore chiave: se i tuoi ART sono costantemente bloccati l'uno dall'altro e la gestione delle dipendenze consuma tempo significativo dell'RTE, potresti aver bisogno della struttura di coordinamento che un Solution Train fornisce.

Il Solution Train si colloca sopra gli ART e fornisce coordinamento tra di essi. La sua struttura rispecchia l'ART, ma a un livello superiore:

Solution Train Engineer (STE) — L'equivalente dell'RTE per il Solution Train. Facilita gli eventi a livello di soluzione, gestisce i rischi cross-ART e assicura che i train rimangano allineati. Questo è un ruolo estremamente impegnativo che richiede una profonda comprensione tecnica e capacità di facilitazione eccezionali.

Solution Management — L'equivalente del Product Management. Definisce la visione e la roadmap della soluzione. Scompone grandi iniziative in capability che mappano sugli ART. Lavora con il Product Management di ciascun ART per garantire l'allineamento.

Solution Architect/Engineer — Definisce l'architettura complessiva attraverso tutti gli ART. Assicura la coerenza tecnica, gestisce le interfacce tra i sottosistemi e mantiene l'architectural runway a livello di soluzione. Deve bilanciare l'autonomia degli ART con la coerenza a livello di sistema.

Solution Backlog — Contiene capability (comportamenti di soluzione di grandi dimensioni che attraversano gli ART) ed enabler a livello di soluzione. Le capability vengono scomposte in feature che i singoli ART implementano.

Il Solution Train non sostituisce le strutture a livello di ART—aggiunge un livello di coordinamento sopra di esse. Ogni ART ha ancora il proprio RTE, Product Management e System Architect. I ruoli del Solution Train coordinano questi ruoli degli ART.

Il Solution Train ha la propria cadenza di eventi che avvolgono gli eventi degli ART:

Pre-PI Planning (1 giorno, prima del PI Planning degli ART) — Gli stakeholder a livello di soluzione si allineano sulla visione e sulle capability principali per il prossimo PI. Il Solution Management presenta le priorità. Il Solution Architect presenta la direzione tecnica. Vengono identificate le dipendenze cross-ART. L'output alimenta l'evento di PI Planning di ciascun ART.

PI Planning degli ART (2 giorni, come di consueto) — Ogni ART esegue il suo PI Planning standard, ma ora informato dall'output del Pre-PI Planning. Gli ART conoscono le priorità a livello di soluzione e le dipendenze inter-ART.

Post-PI Planning (1 giorno, dopo che tutti gli ART hanno pianificato) — I rappresentanti di tutti gli ART si riuniscono per allineare i piani, risolvere le dipendenze rimanenti e creare gli obiettivi di PI a livello di soluzione. Il Solution Train effettua un voto di fiducia sul piano integrato.

Solution Demo (fine del PI) — Come il System Demo ma a livello di soluzione. Tutti gli ART dimostrano il loro contributo integrato alla soluzione complessiva. Questo dimostra che il sistema funziona end-to-end attraverso tutti i train.

Solution Train Sync (settimanale) — Gli STE e gli RTE si incontrano per gestire il coordinamento inter-ART, far emergere gli impedimenti e tracciare i progressi a livello di soluzione.

La cadenza aggiunge overhead (Pre-PI, Post-PI), ma questo overhead è il prezzo del coordinamento di oltre 200 persone su un prodotto condiviso. Senza di esso, si ottiene il caos dell'integrazione alla fine di ogni PI.