Porre obiettivi e misurare il miglioramento

Conosciamo bene l’importanza del feedback con il cliente da parte di chi sviluppa software, e quali siano gli strumenti per aumentare tale feedback.

Anche dal punto di vista del miglioramento continuo del processo e dell’efficacia delle pratiche è molto importante ricercare un feedback frequente. Il problema è: in che modo accorgerci se stiamo migliorando nell’efficacia delle soluzioni intraprese, o se invece stiamo regredendo? Altra domanda importante che si lega alla precedente: quali obiettivi porre al team o al project manager, valutabili su base oggettiva al fine di stimolare nel modo corretto ed efficace team e manager?

Riveste infatti un ruolo fondamentale nella professione del manager e di chiunque si trovi a dover gestire delle persone, il sapere porre obiettivi su base regolare. Obiettivi che devono poter essere verificabili in modo oggettivo, e devono soprattutto essere efficaci nello stimolare, a seconda dell’area di pertinenza delle persone a cui sono posti, un miglioramento nel proprio settore. Avrebbe ben pochi risultati (anzi probabilmente creerebbe solo frustrazione) un manager che non ponga obiettivi, o che ponga obiettivi non pertinenti, non verificabili, o concentrati su un’area troppo distante da quella di influenza della persona.

La risposta di cui voglio parlarvi in questo post è: misurando.

A mio parere è importante che nel mondo del software vengano posti obiettivi sia a livello di prodotto, che a livello di processo, che a livello di business. Chiaramente tali obiettivi avranno più o meno rilevanza e pertinenza a seconda dal ruolo delle persone coinvolte.
Cominciamo quindi con le più importanti metriche di prodotto (per calcolare le quali consiglio il plugin per Eclipse metrics):

1. Numero ciclomatico di McCabe: è un prezioso indicatore della complessità del software (dà anche un’indicazione della testabilità e mantenibilità del codice)
2. Percentuale di copertura del codice da parte degli unit test: importante per sapere a che punto è il team con l’applicazione di pratiche come il TDD e qual è il rischio di incontrare bug.
3. Coesione di classi e metodi (difficile da misurare)
4. Numero di bug riscontrati in produzione
5. Numero di righe di codice per metodo (Delivered Source Instructions/Number of methods): ottimo indicatore del livello di refactoring dell’applicazione
6. Numero di metodi per classe
7. Max Inheritance Tree

Quindi alcune metriche di processo utilizzate in XP, molte delle quali riconducibili alla produzione di RunningTestedFeatures:

1. Numero di carte consegnate (in un’iterazione, in una release, etc)
2. Numero di carte approvate o non approvate dal cliente
3. Giorni ideali lavorati per iterazione
4. Giorni ideali stimati / Giorni reali impiegati (importante per migliorare l’accuratezza delle stime)
   
5. Pomodori (=30 minuti senza interruzioni) lavorati al giorno dal team / ore reali lavorate (importante perché permette di capire quanto si è distanti dalla giornata ideale e di comprendere la metrica precedente)
6. Molto utile è monitorare le metriche di prodotto rispetto all’adozione di nuovo pratiche (ad es. se si decide di porre maggiore attenzione al refactoring, monitorare di quanto decrescono le righe di codice o l’indice McCabe)

Come utilizzare queste metriche ed in che modo collezionarle? Per collezionare queste metriche è necessario che tutto il team effettui un tracciamento di ciò che fa in modo preciso e rigoroso. Francesco Cirillo in xplabs ad esempio fa tracciare su un foglio Excel ad ogni pomodoro ciò che viene fatto dai singoli membri del team (es. refactoring, analisi, a quale carta si sta lavorando, etc..). Gabriele Lana utilizza un wiki nel quale vengono tracciate a fine giornata (sottoforma di tag custom create appositamente) per ogni storia, la stima e l’effort speso giorno per giorno sui task. A fine giornata un script provvede ad ispezionare le pagine del wiki, collezionare le metriche per mezzo delle tag speciali incontrate, creare i grafici e quindi inviare una mail a tutti gli stakeholders del progetto.

Per mezzo di Big Visible Charts raffiguranti le metriche di interesse è possibile comunicare al team messaggi inequivocabili e di forte spinta al miglioramento, nonché rafforzare lo spirito di team così importante in una metodologia uomo-centrica come xp.

E’ importante che queste metriche vengano maneggiate con cautela e soprattutto che vengano analizzate una alla luce dell’altra, in modo da avere una visione d’insieme. E’ inoltre fondamentale che i dati necessari per collezionare una metrica siano realmente reperibili, pena una misura assolutamente dannosa perché non attendibile. Consiglio la lettura del seguente paper per un esempio di utilizzo delle metriche in modo costruttivo e con tracciamento praticabile: A tracking Experience.

Eccoci infine ad alcune metriche di business:

1. SoftwareInProcess: dopo quanto tempo una funzionalità accettata va in produzione? (questa metrica misura anche il ritorno dell’investimento)
2. Fatturato
3. Profitto
4. ROI (= Reddito netto / Risorse investite)
5. TCO (Total Cost of Ownership)

In sostanza credo che l’utilizzo di metriche sia fondamentale (e certamente non banale o sufficiente) da parte di chiunque voglia affrontare in modo serio, scientifico ed efficace la professione dell’informatico, a qualsiasi livello.

Ulteriori riferimenti possono essere trovati sotto il mio delicious sezione metriche e tracking.