Nell’ambito dello sviluppo software, il DevOps rivoluzione tecnologia e processi operativi, promuovendo una cultura trasparente, aperta e collaborativa tra i team coinvolti.
L’assunto di partenza è un concetto di responsabilità: l’atteggiamento del questo non mi compete lascia spazio al gioco di squadra. Si tratta di una cambiamento radicale, che può risultare problematico se non viene affrontato in modo sistematico.
Per misurare l’efficacia del DevOps con un approccio olistico, Gartner suggerisce diverse metriche (strutturate in una piramide concettuale) e una serie di comportamenti utili a fornire un riscontro ai team impegnati nello sviluppo nell’implementazione delle pratiche e dei processi di DevOps. Innanzitutto, chi si occupa di DevOps deve creare un ambiente capace di favorire un approccio di apprendimento rivolto al miglioramento dei processi (revisionando periodicamente le metriche relative alle prestazioni dei progetti DevOps), piuttosto che alle aspettative mancate.
I 5 capitoli del DevOps secondo Gartner
Secondo Gartner, le aziende IT dovrebbero concentrare i loro sforzi di misurazione su cinque aree principali:
- Il cliente
- L’organizzazione nel suo complesso
- L’applicazione stessa (o il servizio offerto)
- Le operations IT
- Il business
Alla base della piramide c’è la misurazione delle operations IT: la maggior parte delle metriche proposte in quest’area si concentra sul concetto di efficienza. In un ambiente DevOps, per esempio, il valore FTE (full-time equivalent) dovrebbe aumentare in modo proporzionale alla maggiore automazione all’ambiente. Un’altra metrica applicabile alle operations è il costo per transazione, un parametro che si concentra sui costi energetici e di solito è misurata in termini di kilowatt per transazione. L’area successiva proposta da Gartner prende in considerazione la qualità e la velocità del servizio, con una misurazione delle prestazioni sulla base della delivery finale al cliente.
Al centro della piramide si trovano invece le metriche che valutano l’organizzazione nel suo complesso: in questa sezione vengono monitorati i cambiamenti del comportamento (considerando che gran parte del successo di una strategia DevOps ruota attorno a una radicale modifica della cultura aziendale). Tra i parametri da valutare, Gartner consiglia la predisposizione dei dipendenti ad accettare il cambiamento in atto, la loro motivazione e la capacità di condivisione e collaborazione.
Poco sotto alla vetta della piramide si trova l’area dedicata al cliente, che prende in considerazione metriche come la velocità di consegna, il numero di rilasci mensili, la soddisfazione dell’utente finale e il cosiddetto NPS (net promoted score), parametro che considera la fedeltà del cliente valutando in che misura consiglierebbe un dato servizio agli altri utenti.
Il punto più alto della piramide coincide invece con la business performance, misurata attraverso parametri quali i guadagni, il cash flow, la quota di mercato e l’introduzione di nuovi servizi di business.
Farsi le giuste domande per ottimizzare i tempi di risposta
Le aziende IT devono sviluppare un proprio schema di misurazione delle prestazioni DevOps, riuscendo dove possibile a rispondere affermativamente a questi quesiti:
Questa metrica è misurabile? Alcuni parametri, come per esempio il morale e la motivazione dei dipendenti, possono risultare difficili da quantificare, ma possono essere interpretati esaminando diverse informazioni correlate, come per esempio i tassi di turnover in azienda
Questa metrica perseguibile? In altre parole, questo parametro suggerisce un piano di orientamento correttivo o è solo fine a se stesso?
Questa metrica è verificabile? Chiedersi sempre e comunque se sia possibile garantire un parametro non sia condizionabile è molto importante per una strategia di successo DevOps
Questa metrica è orientata verso l’intera catena di fornitura IT? Indubbiamente, non tutte le metriche possono concentrarsi su questo aspetto, ma le aziende IT dovrebbero cercare di selezionare parametri in grado, ad esempio, di misurare il flusso end-to-end e i tempi di consegna
È importante sottolineare che le strategie di DevOps devono avere un impatto concreto sul business. Alcuni esempi di metriche legate a precisi risultati di business possono essere:
- i cicli di rilascio più veloci che consentono di offrire rapidamente nuovi prodotti o servizi innovativi per posizionarsi per primi sul mercato
- la capacità di far fronte con rapidità alle modifiche del codice, al fine di fornire una user experience ottimale al cliente andando incontro velocemente alle sue esigenze
- una più rapida risoluzione dei problemi (che si traduce in una maggiore disponibilità dei servizi e quindi in una migliore produttività aziendale)
- i cicli di processo più veloci che si traducono in un maggior numero di istanze completate in un dato tempo (con conseguente diminuzione dei costi per processo)
I processi di verifica delle metriche
Il sistema delle metriche deve essere rivisto sia regolarmente che in modo casuale, con il fine di verificare una serie di condizioni per evitare di incappare in effetti indesiderati. Cosa tenere in considerazione? Per prima cosa, per esempio, occorre chiedersi se le metriche scelte non siano troppo ambiziose in base ai tempi stabiliti e quindi risultino poco realistiche da un punto di vista operativo. Al contrario, è importante anche verificare che un dato obiettivo non sia già stato raggiunto e quindi la metrica scelta per monitorarlo non sia più necessaria. È importante, inoltre, verificare gli indicatori comportamentali: un crescente malcontento tra i dipendenti nei confronti di determinate metriche potrebbe stare a significare che non è stata fatta una sufficiente formazione o non sono state fornite linee guida ottimali. Occorre concentrasi sulla formazione relativa ai sistemi di misurazione, soprattutto quando si tratta di indicatori immateriali. Senza la soddisfazione dei dipendenti, nessun vero cambiamento nella cultura aziendale sarà possibile. In quest’ottica, occorre trovare un equilibrio tra le metriche che Gartner definisce intra-team (vale a dire, lai produttività interna dei singoli team) e le metriche inter-team (come ad esempio il numero di iniziative in cui i team di operation stanno lavorando con i team di sviluppo).
I tre principali fattori critici di successo
I fattori critici di successo sono le variabili su cui l’azienda può intervenire con determinate decisioni in grado di incidere significativamente suoi suoi risultati di business. Il primo fattore critico di successo per il DevOps è proprio quello di spostare l’equilibrio e le priorità dalle metriche intra-team a quelle inter-team, ovvero parametri in comproprietà tra diversi team (ad esempio, offrendo ricompense a quei gruppi che si sono dimostrati più collaborativi nel lavoro di squadra).
Il secondo fattore critico di successo è il grado di soddisfazione dei dipendenti: puntare su una maggiore apertura culturale significa scoraggiare atteggiamenti non collaborativi o poco leali tra i singoli. Il terzo fattore critico di successo è rappresentato dall’interscambio di informazioni e conoscenze all’interno dell’azienda. Questo è in genere l’ostacolo più critico per una cultura di DevOps aperta e collaborativa. Solitamente le persone tendono a non voler condividere il proprio patrimonio di conoscenze, temendo di perdere il ruolo di esclusività all’interno dell’azienda.
L’obiettivo, in questo caso, è convincere i dipendenti che non sono le personali conoscenze il parametro su cui saranno valutati, bensì la capacità di metterle a fattore comune fornendo valore aggiunto alla squadra. Detto ciò, è utile sottolineare come questo tipo di cambiamenti andrebbero introdotti nella cultura aziendale in modo graduale, non intrusivo e personalizzato: DevOps significa nuovi servizi ma anche riunioni più frequenti e one-to-one, che possono essere fondamentali per far comprendere (e apprezzare) ai dipendenti il motivo per cui priorità e approccio al lavoro sono cambiati.
Qui il link all’articolo integrale in lingua originale
