Come gestire i silo?

Come si gestiscono i silo in modo da mitigarne gli effetti negativi? Dei silo ho parlato la settimana scorsa, evidenziandone gli effetti pericolosi. Oggi voglio descrivere alcune delle scelte strategiche relative ai silo che sono state adottate in un grande progetto scientifico di cui ho la fortuna di essere parte.

Il progetto Square Kilometre Array (http://skao.int) mira a costruire il più grande radiotelescopio del mondo implementato su quello che sarà il più grande supercomputer del mondo. 

Tra un anno circa le prime antenne (sia quelle paraboliche di 15m di diametro in Sudafrica, che quelle fisse in Australia) forniranno i primi dati che serviranno per i primi collaudi in produzione, necessari per supportare un lungo processo di calibrazione e revisione di molti aspetti tecnici.

Come si può immaginare, anche se costituito da vari componenti hardware sviluppati custom, un sistema di questo tipo è dominato dal software, che da circa 4 anni viene sviluppato in modalità agile seguendo il metodo SAFe (Scaled Agile Framework). 

Ci sono 24 team agili (SCRUM) con circa 200 persone coinvolte che partecipano da varie parti del mondo, dall’Italia all’Australia, Sudafrica, Gran Bretagna, Canada, India, etc.

E questo solo per lo sviluppo del software e firmware. Perché poi ci sono gruppi che seguono l’effettiva costruzione dei telescopi (edifici, strade, infrastrutture, ambienti dedicati di collaudo) e gruppi che hanno lo scopo di verificare e validare l’integrazione di vari prodotti (hardware e software) forniti dai team software o da altri fornitori.

Dal punto di vista del software, i 24 team sono al momento suddivisi in 4 Agile Release Trains (una specie di team di team previsto da SAFe). Uno che include i team che si occupano del software di gestione delle campagne osservative e il software di controllo e monitoraggio delle centinaia di migliaia di apparecchiature, uno che include il software dedicato all’elaborazione dei segnali e produzione di dati scientifici, e infine due per gestire una serie di servizi trasversali (sistemistici, supporto alla messa a punto di ambienti fisici di test, etc.).

È chiaro che in un progetto di questa scala e complessità i silo possono giocare un ruolo estremamente dannoso, limitando il flusso delle informazioni chiave che consentono ai vari individui di fare al meglio il proprio lavoro. Ad es. ciascun ART può rappresentare un silo, e a sua volta il gruppo di persone che sviluppa software può essere un silo rispetto ai team che si occupano del collaudo.

Come vengono gestiti? Come si cerca di mitigarne l’effetto negativo?

La risposta è variegata, e dipende dal caso specifico. 

In generale, ciascun ART ha un team di management e l’insieme di ART ha un suo team di management. E ovviamente sono previsti scambi di informazione verticali, verso l’alto o verso il basso, con cadenza regolare.

Ma in aggiunta a ciò, vengono creati altri flussi di informazione. 

Ad es. per quanto riguarda il testing, dal punto di vista del software, ci sono molte interazioni orizzontali, ma sono regolate. È responsabilità dei singoli team di sviluppo curare i test di unità e quelli di componente. Ciascun team deve collaborare con gli altri team nello sviluppo e manutenzione dei test di integrazione dei componenti, e seguire lo stato di salute delle pipeline di continuous integration in ambienti “software in the loop”. Quando si passa al “hardware in loop”, siccome il software deve essere installato su hardware custom, questo viene delegato a dei team specializzati di integration testing che collaborano con i team che producono quel hardware e quel software. Al momento ci sono varie installazioni di hardware custom che vengono seguite da team appositi.

Le interazioni menzionate sopra sono un modo per prevedere uno scambio di informazioni sostenuto tra i team coinvolti. Il modo con cui SAFe è adottato in SKAO prevede una pianificazione trimestrale del lavoro, da svolgersi durante un evento che dura una settimana chiamato “Program Increment Planning”. È durante questo evento che queste interazioni vengono pianificate e per le quali i team coinvolti devono garantire di essere a disposizione, nei tempi e nei modi che si prevede sia necessario. Trimestre per trimestre queste interazioni possono cambiare, in funzione di diversi obiettivi di business: non si tratta quindi di una struttura fissa. La maggior parte delle interazioni sono intra-ART, anche se spesso si vedono delle interazioni tra team appartenenti ad ART diversi. Grazie alla sincronicità del PI Planning (che avviene nella stessa settimana per tutti gli ART), è relativamente facile gestire queste dipendenze.

Un altro meccanismo per favorire lo scambio di informazioni è la presenza di meeting periodici. Alcuni di questi incontri sono relativi alla comunità di pratica sul testing, che racchiude al momento circa 140 persone che sono tutti coloro che in qualche modo hanno a che fare con il testing. Questi incontri, più o meno mensili, sono un’occasione per scambiarsi idee, problemi, soluzioni, priorità tra persone che appartengono a diversi team di sviluppo, diversi ART, diversi gruppi, ma che hanno in comune un forte interesse sul testing.

Un’altra serie di incontri sono relativi al lavoro di test di integrazione dei componenti, per sviluppare e monitorare la strategia specifica di integrazione che si segue in quel trimestre e per affrontare e risolvere i vari problemi che spesso sorgono in questo contesto. Questi incontri, settimanali, vengono seguiti solamente dalle persone che sono direttamente coinvolte nell’integrazione e che possono far parte di ART diversi.

Sia le interazioni della comunità di pratica, sia quelle relative all’integrazione, sono sistematiche e non cambiano trimestre per trimestre. 

Queste scelte (scambi verticali, pianificazione coordinata ogni trimestre, incontri della comunità di pratica, incontri dei team coinvolti nell’integrazione di componenti software) sono il risultato di scelte strategiche che in parte derivano da principi generali.

Altre scelte sono guidate dai dati. Ad es. proprio in queste settimane si sta considerando se ristrutturare gli ART sulla base della frequenza delle interazioni verticali (troppi team in un ART richiedono uno sforzo più che proporzionale di management), e delle dipendenze tra team di ART diversi che si identificano durante il PI planning.

In conclusione, questi esempi mostrano che i silo vengono trattati come entità in continua evoluzione, così come le interazioni tra essi. Solo in questo modo una organizzazione può adattarsi alle specifiche situazioni e migliorare il modo con cui le affronta.

E nel vostro caso come sono strutturati i silo? Vengono rivisti periodicamente? Sulla base di cosa?

Pubblicato originariamente come Articolo LinkedIn.