Coordinamento su Larga Scala

Il coordinamento tra ART è dove il Large Solution SAFe dimostra il suo valore—o fallisce. Diversi pattern aiutano:

1. Communities of Practice (CoP) — Gruppi cross-ART organizzati attorno a competenze o domini (es. CoP frontend, CoP sicurezza, CoP data engineering). Le CoP condividono conoscenza, allineano standard e riducono duplicazioni. Si incontrano regolarmente ma non possiedono la consegna—lo fanno i team.

2. Servizi Condivisi — Piccoli team che forniscono capacità utilizzate da tutti gli ART. Esempi: team di piattaforma, team DevOps/SRE, team di piattaforma dati. Questi team operano con la propria cadenza ma si allineano al ritmo PI del Solution Train.

3. System Team — Team dedicati che possiedono l'integrazione, l'infrastruttura di build e i test a livello di sistema. Assicurano che la pipeline CI/CD a livello di soluzione funzioni e mantengono gli ambienti di integrazione.

4. Release Management — Coordinare quando e come viene rilasciata la soluzione. Nelle soluzioni di grandi dimensioni, il rilascio può avvenire con una cadenza diversa dalla cadenza PI. Un rilascio può includere lavoro da più PI, oppure il lavoro di un PI può essere rilasciato in modo incrementale.

5. Architecture Council — I Solution Architect di tutti gli ART si incontrano regolarmente per allinearsi sulla direzione architetturale, risolvere decisioni tecniche cross-ART e mantenere la runway architetturale a livello di soluzione.

Il filo conduttore: questi pattern creano strutture di coordinamento leggere e persistenti che operano continuamente, non solo durante gli eventi di pianificazione. Il PI Planning è essenziale, ma non è sufficiente—il coordinamento deve avvenire anche tra gli eventi di pianificazione.

Molte soluzioni di grandi dimensioni coinvolgono fornitori esterni—vendor hardware, fornitori di software di terze parti, team di sviluppo in outsourcing. Il coordinamento con i fornitori aggiunge complessità perché si ha meno controllo.

Strategie per il coordinamento con i fornitori:

1. Allinearsi sulla cadenza: Se possibile, allineare la cadenza di consegna del fornitore con la cadenza PI. Anche se il fornitore non usa SAFe, punti di consegna regolari creano opportunità di integrazione.

2. Definire i contratti come interfacce: Invece di specificare come il fornitore dovrebbe lavorare, definire contratti di interfaccia chiari (API, protocolli, formati dati). Testare contro il contratto, non l'implementazione.

3. Includere rappresentanti dei fornitori nel PI Planning: Invitare i contatti chiave dei fornitori al Pre-PI e Post-PI Planning. Non devono partecipare all'intero PI Planning dell'ART, ma hanno bisogno di visibilità sui piani e sulle dipendenze.

4. Creare stub di integrazione: Costruire versioni mock dei componenti del fornitore in modo che i team possano sviluppare e testare senza aspettare la versione reale. Questo disaccoppia il ritmo di sviluppo da quello del fornitore.

5. Checkpoint di integrazione regolari: Programmare sessioni di integrazione regolari (settimanali o bisettimanali) dove il sistema si integra con i deliverable effettivi del fornitore. Non aspettare la fine del PI.

Il coordinamento con i fornitori è spesso la parte più frustrante del Large Solution SAFe perché non si può imporre come lavorano le organizzazioni esterne. Concentrarsi su ciò che si può controllare: definizioni di interfaccia, test di integrazione e comunicazione chiara delle aspettative.

I confini degli ART non sono permanenti. Man mano che il prodotto e l'organizzazione evolvono, potrebbe essere necessario riorganizzare:

Segnali che dovresti dividere un ART:

• Più di 12 team—l'ART è troppo grande per un PI Planning efficace
• Esistono due value stream distinti all'interno di un ART
• La maggior parte delle dipendenze è all'interno di sottogruppi, non nell'intero ART
• Il System Demo è diventato troppo lungo e poco focalizzato

Segnali che dovresti unire gli ART:

• Due ART hanno dipendenze estese che creano un overhead di coordinamento costante
• Un value stream è stato artificialmente diviso tra ART
• Un ART è troppo piccolo (meno di 3 team) per giustificare l'overhead
• I team vengono frequentemente "prestati" tra ART

Segnali che i confini del tuo ART sono sbagliati:

• Le dipendenze cross-ART superano in numero quelle intra-ART
• Gli ART non si allineano con l'architettura (violazione della Legge di Conway)
• Il PI Planning produce più stringhe di dipendenza inter-ART che intra-ART

Riorganizzare gli ART è dirompente, quindi non farlo con leggerezza. Ma non evitarlo nemmeno—vivere con confini sbagliati crea una tassa di coordinamento continua che si accumula ad ogni PI. Il momento migliore per riorganizzare è al confine di un PI.