shelidonApril 27, 20201 Comment on Gene Kim – The DevOps Handbook

Ogni lunedì un libro per iniziare la settimana.

Prima della fine del mondo, quando ancora avevamo una vita sociale, avevo iniziato a preparare una lezione su questo framework di gestione della produzione, perché ritengo che alcuni dei suoi principi possano essere utili anche per chi si occupa di BIM: si tratta di un insieme di metodi di produzione del software il cui fulcro centrale è la creazione di sistemi di collaborazione e comunicazione efficaci tra sviluppatori (Dev) e operativi (Ops). Per chi era presente alle due ore che ho dedicato allo Scrum, qualche settimana fa, potete pensarlo come se fosse un ponte tra la parte di progetto e quello che ho definito business as usual.

Spesso capita che il BIM arrivi a creare un muro, anziché un ponte: che si vada a individuare, spesso addirittura per volontà direzionale, un “team BIM” distinto e contrapposto al team di progettazione. Naturalmente non condivido questo approccio. Ed è per questo che questo lunedì vi consiglio un manuale di DevOps.

Gene Kim, Jez Humble, Patrick Debois & John Willis,
The DevOps HandBook: How to create world-class Agility, Reliability, & Security in Technology Organizations
IT Revolution Press

Il libro si basa su una sistematizzazione delle cosiddette tre vie, presentate a livello generale nell’introduzione e cui viene dedicato un capitolo ciascuna:

1. The Principles of Flow;
2. The Principles of Feedback;
3. The Principles of Continual Learning.

1. I principi del flusso

La prima via consiste nell’accelerazione dei tempi di consegna da Development a Operations (praticamente privo di traduzione italiana in questa accezione) fino al cliente finale. Vengono individuati, tra le altre cose, diverse forme di spreco che suoneranno familiari a chi fa un mestiere simile al mio:

• lavoro parzialmente completato, ovvero tutto quel lavoro che è stato iniziato ma poi abbandonato per il sopraggiungere di urgenze differenti: sarà difficile riprenderlo in mano e ci vorrà tempo per recuperarne il filo, ammesso che il tempo non l’abbia reso obsoleto;
• processi extra, come ad esempio un lavoro di documentazione che non sia immediatamente necessario alla catena di trasmissione del valore al cliente;
• extra features, ovvero l’aggiunta di funzionalità che non sono state richieste o previste dai requisiti;
• task switching, ovvero l’abitudine deleteria ad affidare troppi progetti ad una singola persona, costringendola a passare in continuazione da un progetto all’altro;
• tempi d’attesa, causati da colli di bottiglia e altri tipi di inefficienza;
• costi di movimentazione, in questo caso relativi alla movimentazione delle informazioni da un dipartimento ad un altro, provocati da situazioni di scarsa trasparenza e non permeabilità;
• difetti, provocati da mancanza di informazioni o dall’utilizzo come base di materiale (es: codice) che era difettoso in partenza;
• lavoro manuale e/o non standardizzato: come mi è capitato di dire già più volte, gli standard costituiscono la base per qualunque automazione e in assenza di standard anche il lavoro più semplice deve essere svolto manualmente;
• eroiche, ovvero quelle situazioni in cui il normale svolgersi del lavoro si basa sulla straordinaria competenza e dedizione degli individui, più che sull’efficienza del processo (ne ho parlato tempo fa, discutendo l’evoluzione delle figure legate al BIM).

2. I principi del Feedback

Per lavorare in modo sicuro all’interno di sistemi complessi, l’importanza di feedback che siano onesti, rilevanti e continui. In particolare viene rilevata la necessità di:

• creare sistemi di monitoraggio (chiamate telemetrie) che consentano di individuare tempestivamente i problemi e la loro risoluzione;
• analizzare i dati rilevati da queste telemetrie per prevedere i problemi in futuro e raggiungere meglio gli obiettivi;
• attivare un sistema di comunicazione tra sviluppo e operations in modo che il codice possa essere rilasciato in sicurezza;
• integrare Hypothesis-Driven Development, uno degli elementi chiave del framework;
• integrare split-run testing nel lavoro di tutti i giorni;
• creare processi di revisione e di coordinamento per migliorare la qualità del lavoro.

3. I principi dell’apprendimento continuo

In ultimo, come mi è caro da sempre, il processo deve avere a cuore la necessità di iniettare percorsi di apprendimento nel lavoro di tutti i giorni, ma anche di fare tesoro dell’esperienza acquisita sul campo, ad esempio utilizzando sessioni di lesson-learned per integrare nel processo globale quelle piccole e grandi scoperte che si verificano sui singoli progetti.

…e noi?

Come dicevo, ci vorrebbe una lezione apposta, ma i principi del DevOps sono assolutamente rilevanti in tutte quelle circostanze in cui un dipartimento di produzione lavora alla realizzazione di qualcosa che serve ad un altro dipartimento. Non sto pensando solo agli specialisti di computational design che realizzano script per i progettisti (dinamica in cui personalmente io credo poco) ma anche a tutte quelle situazioni in cui la realizzazione dei componenti per il modello viene esternalizzata rispetto ai processi di progettazione. E forse potrebbe raccontarci tantissimo se davvero vogliamo provare a far uscire dal mito e dalla leggenda la realizzazione dei cosiddetti digital twin che servano alla manutenzione.

Intanto, vi consiglio il manuale. Sempre di Gene Kim, per la stessa collana e nello stesso formato, esiste anche un romanzo. Sì, avete capito giusto. Un romanzo che parla di IT, DevOps e Business. A tratti, mi dicono, è un horror.