Uno degli aspetti fondamentali che spesso finiscono in secondo piano quando si intraprende un percorso di cambiamento, è la capacità di misurare oggettivamente i progressi, individuando chiaramente gli obiettivi da perseguire: pochi, chiari e misurabili!
In tal modo, quando ci si chiede se si sono ottenuti effettivi vantaggi dal nostro “transformation journey”, possiamo rispondere con qualcosa di più interessante dell’inutile “mah… a naso… secondo me... siamo più bravi di prima”, affermazione che non significa un bel niente.
In Agile, Lean, e quindi in DevOps, il concetto di “misura”, l’individuazione delle metriche che contano (actionable metrics) e, soprattutto, delle azioni di improvement da settare per migliorarsi costantemente, sono elementi ben evidenziati e costantemente sottolineati.
Come tutte le cose, però, bisogna capire come individuare le “buone metriche”, ovvero quelle più adatte al proprio contesto e più significative per il percorso di miglioramento intrapreso. In generale, se si guarda al tutto in ottica Lean (ok… va bene anche DevOps J) è possibile caratterizzare le diverse metriche in funzione di tre elementi principali:
- Persone (People). Le Persone sono al centro del cambiamento culturale e sono il motore della nostra organizzazione. Risulta quindi evidente come sia necessario avere delle metriche che consentano di capire costantemente dove ci si trova, confrontando l’attuale situazione con quella di riferimento;
- Processi (Processes). Se si guarda al Value Stream, ovvero al flusso continuo di creazione di Valore, ci si accorge che esso è sempre basato su più processi che devono incastrarsi al meglio per generare il giusto ritmo operativo. Misurarne il grado di efficacia, efficienza e sinergia è sicuramente una delle azioni basilari;
- Tecnologie (Technologies). Le tecnologie che utilizziamo nel nostro lavoro devono sempre essere di supporto e non devono mai gravare sul contesto complessivo solo per “puro tecnicismo”. Sapere se ci sono di aiuto o se rappresentano un ulteriore vincolo negativo permette di fare opportune considerazioni e scelte specifiche.
Bisogna evidenziare che, generalmente, tutti questi tre elementi sono presenti nelle diverse metriche. Tipicamente uno di essi è dominante mentre gli altri sono di supporto: si crea implicitamente una sorta di “proporzione naturale” che ricorda l’affascinate sezione aurea (anche nota come proporzione divina) spesso ricorrente in natura.
Ma quali sono le metriche più utilizzate e, generalmente, ritenute più significative? Proviamo ad elencarne alcune e ad osservarle più da vicino:
- Deployment Frequency, è la frequenza di deployment della propria soluzione, organizzata possibilmente in chiave “small batch”. Più il rilascio è frequente, più si riescono ad ottenere feedback rapidi (the second way of devops) che permettono di riallineare le attività in funzione dei reali risultati ottenuti, misurabili in termini di Customer Satisfaction e di Solution Quality;
- Lead Time, si tratta del tempo che intercorre da quando si accetta di realizzare qualcosa a quando la stessa diventa disponibile per gli utenti. Inutile dire che l’obbiettivo è quello di ridurre il lead time il più possibile, senza però sacrificare la giusta proporzione tra il lavoro e il tempo per la propria vita (sustainable developmen, ottavo principio agile);
- Process Time (o Cycle Time), è una componente del Lead Time, in quanto misura il “solo” tempo di sviluppo annesso ad una nuova feature. Valgono considerazioni simili al Lead Time;
- Failure Rate, è il trend di “fallimento” annesso all’azione di delivery (attenzione: non di deploy, ma di delivery!). L’obiettivo è quello di ridurlo al minimo e creare una valida cultura basata sul valore intrinseco della continuous delivery;
- Mean Time To Recover (MTTR), è il tempo che intercorre tra un fallimento/problema e la sua risoluzione. Si tratta, in generale, di una metrica utile per capire la capacità del team di affrontare efficacemente una situazione inattesa;
- Quality of the output (%c/a), è indicativa della qualità della soluzione. Un modo relativamente semplice, ma estremamente valido, di misurarne il valore è quello di chiedere ai propri utenti quante volte sono riusciti ad utilizzare le nuove funzionalità “as-is” senza ulteriori informazioni o aggiustamenti.
La generazione del trend delle diverse metriche è spesso supportata da tool che fanno gathering da più fonti, permettendo anche di fare overlapping per meglio comprendere il contesto complessivo.
La cosa indispensabile è che, indipendentemente da quali metriche che si decida di utilizzare, il trend relativo sia facilmente visibile e comprensibile a tutti i membri del team. Inoltre, è altrettanto fondamentale che esso sia utilizzato per guidare le azioni di improvement e non per controllare o valutare il team dall’esterno.
Ricordate: senza metriche è come volare alla cieca… questo è un fatto, non un’opinione!
Stay tuned J
