DevOps: La misurazione

Nel nostro viaggio nelle organizzazioni DevOps, ci occupiamo della quarta iniziale dell’acronimo CALMS (Culture, Automation, Lean, Measurement e Sharing); ci occupiamo del Measurement.

La cultura della misurazione e dei dati è un altro presupposto importante per dare un valore ai nostri investimenti e poterli dichiarare di successo o meno.

La misurazione si riferisce all’astrazione di un fenomeno reale o alla sua approssimazione. Se associamo un determinato processo a una scala di misura, otteniamo una metrica di cui ci possiamo servire per prendere decisioni coerenti sulla base di dati oggettivi.

Tanto più i metodi di misurazione e aggregazione sono analiticamente determinati, tanto meno opinabili e più oggettivi saranno i presupposti sui quali prendiamo le decisioni.

In DevOps e nel mondo del software in generale, ci serviamo di misure che supportano il miglioramento continuo soprattutto con riferimento ad alcune macro-aree:

• Prestazioni dei metodi di rilascio e mantenimento;
• Prestazioni dello sviluppo dei prodotti e servizi;
• Supporto alle decisioni economiche dell’organizzazione.

Il Lean considera la misurazione come un’attività che non genera valore e sottrae tempo alle persone: per questo è consigliabile ridurla al minimo.

Troppo spesso, nella mia carriera, ho assistito a iperfagia da KPI. Un amico docente di Organizzazione Aziendale presso l’Università di Udine ripete sempre: “attenzione, di troppi KPI possiamo far fallire un’azienda!”.

Misurare per migliorare

Il Lean e i metodi Agili si basano su un approccio sistematico alla risoluzione dei problemi guidato dagli insegnamenti di William E. Deming. Tale approccio prende il nome di Ciclo di Deming o Plan-Do-Check-Act (Pianificazione-Esecuzione-Controllo-Azione). Alla base di tutti i processi di controllo della qualità, il PDCA costituisce la pietra angolare del miglioramento continuo e dei processi kaizen, parola giapponese che significa “cambiare in meglio”

Il Ciclo di Deming parte dalla misurazione dello stato attuale del sistema, per poi integrare con il feedback i cambiamenti al sistema per tentare di migliorare la performance futura.

Le fasi sono quattro, che si ripetono fino alla soluzione.

• Pianificazione: Stabilire obiettivi collegati alla causa per cui si cerca il miglioramento, individualmente o in team;
• Esecuzione: Svolgere l’attività facendo scorrere le lavorazioni nel processo, raccogliendo i dati, tenendo la scala piccola in merito a tempi o quantità di osservazioni;
• Controllo: Verificare i dati e le aspettative e successivamente decidere come migliorare il processo;
• Azione: Analizzare i dati raccolti e cercare di capire che cosa fare per migliorare la performance.

Si parte con l’analisi dello stato as is di un processo o di un fenomeno, si individuano gli indicatori necessari e si rileva il loro valore attuale, poi si prosegue definendo una visione futura degli indicatori come ce li si aspetta dopo l’effetto dell’azione di miglioramento.

Possiamo intendere gli indicatori sullo stato attuale di un processo o di un fenomeno come il punto di riferimento, mentre il valore futuro degli indicatori come obiettivi del miglioramento. Una metrica che non pone un obiettivo nel tempo potrebbe essere poco utile in un sistema complesso.

I processi kaizen del Lean sono solamente alcune tra la moltitudine di tecniche e strumenti che ricorrono al Ciclo di Deming, quali per esempio le retrospettive di Extreme Programming (XP) che fanno uso del principio di Continuous Improvement del Toyota Production System (TPS).

Per lavorare con questo metodo è necessario un ambiente di lavoro in cui la cultura di accettazione dell’errore sia ben integrata e basata sul presupposto della fiducia. Risulta quindi determinante lo stile di management adottato.

Come scegliere metriche e indicatori

Il Lean, i metodi Agili e DevOps mirano al miglioramento sistemico nel lungo periodo. Per questo motivo si adottano delle metriche end-to-end, dove si prende da un capo all’altro il prodotto e lo si studia come fosse una scatola nera di cui conosciamo il funzionamento. Solo successivamente si analizzano le singole parti del prodotto per capire come si integrano tra loro e gli effetti che hanno l’una sull’altra per giungere al dettaglio sui moduli interni.

Per operare queste analisi, DevOps fa largo uso di strumenti come le mappe concettuali, il visual thinking (pensiero visuale) con le lavagne ed i diagrammi architetturali.

Scegliere i KPI come abbiamo visto è il primo passo, ma la bontà dei risultati passa per la raccolta dati e la corretta interpretazione dei fenomeni e dell’andamento dei modelli di riferimento.

Aspetto da non sottovalutare nell’implementazione di DevOps è l’adozione di una terminologia comune e condivisa, per dare nomi ad elementi, fenomeni, fasi e dimensioni.

Due tecniche in uso con di Extreme Programming (XP) sono il Domain Driven Design di Eric Evans e l’Event Storming di Alberto Brandolini. Gli eventi di dominio sono ciò che accade nel sistema, gli aggregati di parti sono pezzi semplificati del modello che ne indicano altri: per analogia possiamo pensare a questi come indicatori. La terminologia che aiuta a delimitare il perimetro, il contesto e le parti del prodotto da realizzare è il linguaggio di dominio. Gli aggregati sono i gruppi di entità fisiche o logiche, gli eventi sono le cose che accadono nel tempo e hanno una sorgente che li genera; lo stato del sistema è il risultato della sequenza degli eventi che lo hanno interessato.

L’applicazione di tecniche di questo genere produce un linguaggio coerente e costruito per obiettivo ben preciso, rivolto a interlocutori definiti, indipendenti tra loro.

Le Kanban board sono un altro punto di intersezione tra metodi Agili e Lean e sono usate largamente per rappresentare i processi ed individuare i colli di bottiglia.

Per costruire la Kanban board è necessario tracciare tante colonne quante sono le fasi del processo da rappresentare, da sinistra verso destra. In ogni colonna vengono inseriti i kanban (cartellini) che sono una richiesta di lavorazione. Le lavorazioni partono dalla colonna di sinistra, la fase iniziale del processo. Questa colonna contiene la coda delle lavorazioni che il team si è impegnato a consegnare entro un certo tempo (stato To-Do, ovvero “da fare”) e transita, man mano che proseguono le fasi, verso destra. Quando la lavorazione è completata esce dalla board (stato done, “fatto”). Le lavorazioni vengono inserite in ordine di priorità in ciascuna colonna. Ogni volta che si libera uno spazio, ci si chiede quale sia la prossima lavorazione da prendere in carico. Alla parte superiore corrisponde la maggiore urgenza.

Metriche sui processi

A tutti i processi di lavorazione del software possono essere applicate le quattro metriche fondamentali di seguito descritte.

• Lead time (tempo di completamento): il tempo che un generico processo impiega per essere completato;
• Wait time (tempo di attesa): la prima porzione di lead time che include il tempo intercorso tra la richiesta di lavorazione e la sua presa in carico dal team;
• Process time (tempo di lavorazione): la seconda porzione di lead time che comprende il tempo effettivo della lavorazione da quando il team la prende in carico a quando la funzionalità è completata;
• Delivery time (tempo di consegna): il tempo che trascorre tra il completamento del lavoro e l’arrivo del prodotto all’utente.

Per costruire queste metriche di processo, i dati da raccogliere sono i tempi di attraversamento per ciascuna fase.

Risulta così possibile costruire diversi diagrammi a supporto delle decisioni.

• Control Chart: Il Control Chart di Walter Andrew Shewhart si costruisce considerando i lead time di ogni lavorazione. Si pongono le lavorazioni sulle ascisse e, per ciascuna di esse, si rileva il tempo di lavorazione. Le opportunità di miglioramento sono indicate dagli eventi fuori media o agli estremi alla distribuzione. Studiando lavorazioni lunghe o molto brevi si può indagare quali parti del processo costituiscano il vincolo.
• Release Chart: Il Release Chart è una rappresentazione del rapporto tra il delivery time e il process time e ci consente di capire quanto impatta la fase di rilascio in un processo. Rende visibile a colpo d’occhio quanto tempo intercorre dalla fine della lavorazione al suo rilascio.
• Cumulative Flow Diagram: Il Cumulative Flow Diagram è uno degli strumenti più utilizzati rappresentando l’andamento dei tempi di attraversamento delle lavorazioni per ciascuna fase. Sull’asse delle ascisse c’è il tempo, per esempio in giorni, sulle ordinate il numero di lavorazioni cumulate, ovvero eseguite in totale fino a quel momento). Per ciascuna unità di tempo contiamo il numero di lavorazioni presenti in quel momento preciso in ogni fase del flusso, assegniamo un colore e le disegniamo in un grafico. Quando il nostro processo si colloca nello stato ideale, le linee crescono parallelamente senza fluttuazioni. Lo spazio tra una fase e l’altra (in altezza) è ampio tanto quanto lo è il numero di lavorazioni presenti. La base crescente rappresenta le lavorazioni già completate,mentre su di essa si accumula il Work in Progress (WIP). L’altezza del WIP comprende tutte le fasi nel lead time. Più l’andamento del grafico è costante, più è possibile stimare una data di rilascio (delivery date).

Metriche e strumenti in DevOps

Per monitorare la performance di rilascio di software nella nostra organizzazione, gli indicatori principali di cui possiamo servirci sono il throughput e la stabilità.

Nel contesto dell’operatività, il rilascio, le operation a supporto di un servizio software, le metriche e indicatori di uso più frequente sono di seguito indicate.

• Release frequency (frequenza di rilascio): misura il numero di rilasci per unità di tempo. Un valore elevato indica che il processo di Continuous Delivery è efficiente e gli sviluppatori sono incentivati a fare piccole e frequenti modifiche senza temere di destabilizzare il sistema;
• Mean-Time-To-Recover (MTTR, tempo medio di ripristino): tempo necessario a riportare il sistema in esercizio dopo un guasto (o la sua rilevazione);
• Quality of Product (qualità del prodotto): rapporto che indica quanti interventi sono stati completati con qualità e successo al primo tentativo senza necessità di ulteriori rilavorazioni;
• Uptime (disponibilità del servizio): rapporto che rappresenta il tempo in cui il servizio è stato attivo e disponibile all’utente rispetto al tempo totale.
• Change Failure Rate (tasso di fallimento nelle lavorazioni): rapporto che traccia il numero di incident verificatisi in seguito all’introduzione di cambiamenti. È sicuramente un indicatore dello stato di salute del processo DevOps.