Nel mondo della tecnologia si parla spesso di performance e di innovazione, ma perché non vengono mai date indicazioni o metodi chiari per raggiungere questi obiettivi?
In quest’articolo vedremo 24 key capabilities, ovvero attività e funzioni operative per il DevOps nella software delivery, in grado di migliorarne notevolmente le performance complessive.
DevOps nella software delivery: accelerare le performance
La letteratura in ambito Information Technology è piena di capisaldi editoriali, libri che nel tempo sono diventati dei riferimenti assoluti ed hanno formato/ispirato migliaia di persone
In questo articolo parliamo di un libro che è uscito solamente qualche anno fa (2018) ma che è probabilmente destinato ad entrare a far parte di questa “cerchia elitaria” di libri. Il titolo è “Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations” ed i suoi autori (Nicole Forsgren, Jez Humble e Gene Kim) sono noti per i loro fondamentali contributi nel campo della ricerca in tema “DevOps”, argomento cardine del libro (in particolare DevOps nella software delivery).
Che cos’è la performance? Come si misura?
L’argomento trattato è la cultura DevOps, in particolare riferita all’importante tema della performance nel mondo della software delivery.
Il libro riporta in modo rigoroso e statisticamente corretto i risultati di ricerca svolta tra il 2014 ed il 2017, dove gli autori hanno inviato un sondaggio a migliaia di attori (dal singolo professionista ai giganti dell’IT) per identificare/catalogare la performance nella software delivery.
Sono state individuate quattro metriche indicatori di performance, di seguito riportate:
| Metrica | Significato |
| Lead time | Tempo intercorso tra una commit/push di una modifica ed il momento in cui (questa modifica) viene rilasciata in produzione |
| Deployment | Frequency La frequenza con la quale il software viene rilasciato in produzione |
| Mean time to Restore (MTTR) | Tempo necessario per ristabilire il corretto funzionamento in produzione dopo un incidente |
| Change Fail Percentage | Percentuale dei cambiamenti in produzione che portano ad un degrado del servizio e/o richiedono un rimedio (i.e. hotfix, rollback, etc. etc.) |
Gli autori hanno classificato i soggetti intervistati all’interno di tre categorie di performance (low performers, medium performers e high performers), in relazione alle suddette metriche, con lo scopo di individuare quali caratteristiche differenziano gli uni dagli altri.
Il risultato è visibile nella tabella sottostante:
| High Performers | Medium Performers | Low Performers | |
| Deployment Frequency | On demand (più volte al giorno) | Tra “una volta a settimana” e “una volta al mese” | Tra “una volta a settimana” e “una volta al mese” * |
| Mean time to Restore (MTTR) | Meno di un’ora | Tra “una settimana” e “un mese” | Tra “una settimana” e “un mese” * |
| Change Fail Percentage | 0-15% | 0-15% | 31-45% |
* (NOTA: stesso valore mediano, ma media aritmetica più bassa)
“Incrementare le performance è possibile per tutti, ma si tratta di un processo che non potrà mai essere copiato da altri oppure acquistato.”
Si può migliorare la performance?
Il risultato probabilmente più importante del libro è quello di aver identificato 24 key capabilities il cui impiego viene direttamente correlato ad un incremento nelle performance della software delivery, ovvero alle metriche sopra introdotte.
Le capabilities sono suddivise in gruppi, di seguito elencati:
Continuous Delivery
1. Mantenere tutti gli artefatti di produzione in un VCS (i.e. Git, Svn), non solo il codice ma anche le configurazioni/script
2. Automatizzare il processo di deploy del codice, senza richiedere intervento umano
3. Implementare una metodologia di Continuous Integration, ovvero effettuare frequenti “check-in” del codice. Questi innescano l’esecuzione di una build che prevede l’esecuzione test automatici, così come la creazione di un artefatto deployabile.
4. Utilizzare metodi di sviluppo basati su trunk-based, limitando a 3/4 il numero di branch contemporaneamente attivi la cui durata (prima del merge) non dovrebbe superare la giornata
5. Implementare test automatici ed eseguirli continuamente durante lo sviluppo del codice, per trovare bug/regressioni
6. Mantenere data-set per test automatici, dal momento che sono un asset importante per eseguire test automatici efficaci e corretti
7. Integrare la gestione della sicurezza nel progetto nelle varie fasi (design, testing, coding, etc.). I test automatici dovrebbero includere anche test di sicurezza, così come le review periodiche
8. Implementare una metodologia di Continuous Delivery, ovvero la codebase deve essere sempre in uno stato “deployabile”. Il codice deve essere poter rilasciato on demand, in qualsiasi momento.
Architetturali
9. Implementare architetture disaccoppiate, in modo che ogni team non dipenda da altri team e/o fattori esterni che ne limitino la possibilità di essere agile, e creare valore al business
10. Implementare team potenziati, che possono scegliere gli strumenti con i quali lavorare per migliorare la delivery e la qualità del software
Prodotto e processo
1. Raccogliere e incorporare il feedback dei clienti nel design del software, dal momento che assicura fedeltà ai desideri del cliente ed in ultima analisi aumenta la qualità del prodotto
2. Rendere “visibile” il lavoro, ovvero permettere ai team di vedere in ogni momento lo stato del progetto e delle sue features, ed anche di osservare/capire il flusso di lavoro per come si evolve dal business fino al cliente, attraverso lo sviluppo del codice
3. Separare il lavoro in piccoli “lotti”, che dovrebbero essere completati entro una settimana per favorire uno sviluppo agile e l’aumento di frequenza dei rilasci
4. Incoraggiare ed abilitare i team nella sperimentazione volta al provare nuove idee e modalità di lavoro, senza controlli/approvazioni complicati. Questa agilità viene ripagata da un rapido incremento dell’innovazione e della capacità dei team di creare valore
Lean management
5. Adottare modalità snelle per approvare i cambiamenti, come il pair-programming o le code review intra-team, per garantire l’agilità necessaria durante il processo di sviluppo
6. Monitorare ed informare il business, ovvero raccogliere dati applicativi ed infrastrutturali per informare il business, così che possa effettuare le scelte migliori per il prodotto/processo
7. Monitorare lo stato di salute del sistema pro-attivamente, attraverso l’utilizzo di strumenti, soglie ed allarmistica. Fondamentale per intervenire con tempestività sotto condizioni di degrado/errore
8. Migliorare il processo produttivo limitando il Work-In-Progress (WIP), approccio solido del mondo Lean e che consente di isolare i colli di bottiglia, oltre che di incrementare il “throughput” del processo
9. Visualizzare il work-in-progress e le metriche di qualità attraverso l’utilizzo di dashboard o altri strumenti visuali, per permettere ai team di essere a conoscenza dello stato dell’arte e concentrarsi laddove c’è più necessità di creare valore
Culturali
0. Supportare una cultura “rigenerativa” in azienda attraverso un’efficace comunicazione, sostenenere un elevato grado di cooperazione e fiducia tra le persone, favorire l’interazione tra team differenti, abolire atteggiamenti inquisitori
1. Incoraggiare e supportare una cultura dove la formazione è un investimento importante, nell’ottica di una crescita continua
2. Facilitare la collaborazione tra i team nell’ottica di abolire il più possibile la creazione di “silos” verticali dove non si comunica, tutto a discapito della qualità del processo/prodotto
3. Rendere significativo il lavoro, perché più una persona trova un significato nel lavoro che fa, più si identifica, si appassiona, e dedica sé stesso alla buona riuscita. Questo passa da una comunicazione efficace e dal concedere ai team i migliori strumenti di lavoro
4. Implementare la transformational leadership, fondamentale in quanto supporta ed amplifica il lavoro tecnico e di processo, così essenziali in una cultura DevOps. I leader di questo tipo devono avere visione, devono saper stimolare intellettualmente, sapere ispirare, essere solidati e sapere riconoscere/promuovere i meriti altrui
Conclusioni
La conclusione degli autori è che incrementare le performance è possibile per tutti, premesso che non potrà mai trattarsi di un processo copiato da altri oppure acquistato.
Si può accelerare solo con il duro lavoro, investimenti economici, visione aziendale, leader che sappiano catalizzare ed amplificare il processo, sforzi continuativi e l’impegno di tutti a voler crescere ogni giorno.
La cosa più importante, forse, è proprio quest’ultima: crescere e migliorare non è un progetto “one-off” che ha una data di fine, bensì un processo che non ha termine e si re-inventa perpetuamente.
