“Ottieni ciò che misuri” è un eccellente modo di dire che avverte chi vuole misurare qualcosa. Ad esempio, se volessi misurare la produttività dei developer in “righe di codice prodotte” (cosa che non farei mai ma seguimi nell’esempio anche se un po’ estremo) e istituissi delle pratiche e strumenti per farlo che cosa otterresti in termini di “valore”? Probabilmente nulla perché un developer sarebbe incentivato a scrivere molte righe di codice per dimostrare che fa bene il suo lavoro. E sappiamo tutti, invece, che meno ne scriviamo meglio è (ogni riga di codice potrebbe facilmente essere un debito invece che una risorsa). Altri esempi errati sarebbero: numero di bug risolti, numero di feature completate e così via.

Quando misuri i developer non usare quei numeri per punirli. I developer sono persone intelligenti e se lo fai quei tuoi numeri cominceranno a essere magicamente sempre perfetti. Usa quei numeri per capire la qualità del tuo processo.

In generale, puoi intuire, qualunque cosa sia incentrata sul misurare puro volume potrebbe avere effetti collaterali imprevisti. Questo genere di metriche può tuttavia essere raccolto come secondarie.

Una misura di performance deve avere due caratteristiche:

• deve focalizzarsi su un obiettivo globale per evitare la competizione tra team.
• deve focalizzarsi sugli output e non sugli input: questo evita che le persone facciano lavori inutili solo per influenzare delle misurazioni senza benefici per il business.

Date queste caratteristiche sono state quindi individuate, tra le tante metriche esistenti, gli autori di Accelerate hanno individuato le seguenti quattro come primarie:

• Lead time
• Deployment frequency
• Mean Time to Restore (MTTR)
• Change Fail Percentage

Tempo di consegna (lead-time)

Per lead time (tempo di consegna) si intende il tempo che intercorre tra il momento in cui la software factory riceve una richiesta cliente e il momento in cui la richiesta viene soddisfatta tramite software funzionante in produzione che il cliente può usare.

All’interno di questo intervallo di tempo si svolge il processo per intero e puoi dividerlo in due macro-fasi:

• Progettazione e sviluppo: comprende il design architetturale, grafico, esplorazioni e risoluzione di problemi nuovi. In generale è ad alta variabilità.
• Delivery: comprende il trasportare gli artefatti sviluppati dall’ambiente di sviluppo fino alla produzione. Il lavoro dovrebbe essere generalmente prevedibile e ripetibile con test e deployment effettuati il più frequentemente possibile.

Puoi apprezzare i benefici di un lead time breve da svariati punti di vista:

• I clienti / utenti finali sono più soddisfatti perché vedono soddisfatte in tempi brevi le loro richieste. Il cliente soddisfatto paga le fatture. Il business realizza i suoi obiettivi.
• In caso di problemi sai che una patch sarà pronta in tempi ragionevoli e compatibili con i livelli di servizio del business in cui .
• Si abilita il rilascio di feature in modo iterativo e incrementale, consentendo di imparare dagli utenti e dal comportamento in produzione. Potenzialmente si risparmiano costi di sviluppi inutili dovuti all’assenza di feedback o a feedback limitati.

Frequenza di rilascio (deployment frequency)

Per frequenza di deployment si intende quante volte gli artefatti vengono rilasciati in produzione o pubblicati su uno store on-line pronti per il download da parte degli utenti.

La frequenza di deployment è direttamente influenzata dalla dimensione in cui vengono spezzate le unità di lavoro. È difficile trasportare il concetto di one-piece flow del mondo Lean, che ha a che fare con oggetti fisici, nel mondo astratto del knowledge work del software. Tuttavia, per ottenere una frequenza di rilascio si deve suddividere per quanto più possibile il lavoro in pezzi rilasciabili in modo indipendente. In questo modo hai benefici come feedback più rapidi dalla produzione e riduzione del rischio associato a una release.

Tempo medio di ripristino (Mean Time To Restore – MTTR)

Una software factory deve essere rapida ma senza sacrificare la stabilità del sistema e dei servizi ai propri utenti. La misura tradizionale relativa alla stabilità è il tempo medio misurato tra il verificarsi di un problema e l’altro. Tuttavia, in contesti particolarmente complessi, i problemi sono inevitabili e una software factory deve essere in grado di ripristinare la situazione rapidamente. Per questo ci si concentra sul tempo medio di ripristino (MTTR – Mean time to restore).

Percentuale di cambiamenti difettosi (change fail percentage)

Sempre con un occhio riguardo alla stabilità e alla qualità dei processi questa metrica conteggia quanti cambiamenti (nuova versione software, cambi di configurazione, aggiornamenti infrastrutturali, …) causano un problema in produzione e che richiedono un intervento per riportare la situazione alla normalità (hotfix, rollback, rollforward, patch…).

Altrettanto importante è sapere cosa NON misurare… ma sarà argomento della prossima pubblicazione!