Quali sono e utilizzo delle metriche per un progetto Scrum

Il metodo Scrum

Scrum è un metodo iterativo e incrementale, basato su controllo empirico del processo; è incrementale perchè il prodotto finale è il risultato di continui rilasci, ciascuno dei quali aggiunge valore a quello precedente; è iterativo perchè ogni nuovo rilascio viene adattato in base alle contingenze del momento. I suoi fondamenti sono: un processo di sviluppo con fasi ben caratterizzate, una definizione precisa dei ruoli e una serie di rituali.

Il processo Scrum

Il processo Scrum è caratterizzato da una fase iniziale di raccolta delle feature per il progetto richieste dal cliente che vengono riportate con delle User Stories: una User Story è una breve descrizione di come l’utente intende usare la feature richiesta. La scelta di quali User Stories accettare viene svolta esclusivamente dal Product Owner, che le inserisce nel Product Backlog. All’interno del Product Backlog le User Stories possono essere ulteriormente spezzetate dal team di sviluppo per creare dei requisiti più piccoli, la ratio è quella di rendere lo sforzo richiesto dall’implementazione di ogni requisito adattabile ai tempi delle iterazioni.

Successivamente il Product Owner sceglie tra i requisiti individuati nel Product Backlog quelli che si vogliono sviluppare nella successiva iterazione della fase di sviluppo, nel gergo Scrum i requisiti relativi a una singola iterazione vengono chiamati Sprint Backlog. Ogni iterazione è definita da uno Sprint: un periodo di tempo, solitamente compreso tra due e quattro settimane, durante il quale si sviluppano i requisiti che sono stati inseriti nello Sprint Backlog; ogni Sprint comprende l’implementazione di nuove feature e
i relativi test. Lo Sprint è la fase più delicata per lo sviluppo, quindi non sono ammesse modifiche allo Sprint Backlog e al Team Scrum fino al termine dello stesso.

Al termine dello Sprint segue una fase di revisione, detta Sprint Review, in cui si analizzano i risultati ottenuti e cosa è andato storto durante la fase di sviluppo. L’obiettivo è quello di migliorare il processo di sviluppo per le iterazioni future e accertarsi di aver soddisfatto le aspettative del cliente. Inoltre, comprendere quanto valore è stato aggiunto al prodotto ad ogni iterazione rende i membri dello Scrum Team più motivati e interessati al progetto. In questa fase il team verifica la qualità della release attraverso i test, in questo modo si accerta la continuità nel funzionamento generale del software e la correttezza di quanto prodotto durante lo Sprint.

Una volta completata la fase di Sprint Review si ritorna al Product Backlog e si scelgono i requisiti da implementare nello Sprint successivo. Potrebbe sembrare che in Scrum ci sia poca pianificazione, invece questa è solo un’impressione dovuta al fatto che la pianificazione non viene svolta in modo completo prima di cominciare a implementare i requisiti, ma viene diluita nello Sprint: un tipico Team Scrum spende 8 ore per pianificare l’iterazione, poi adatta la pianificazione durante i Daily Meetings (15 minuti per 30 giorni); se si considera un team di 5 persone, si scopre che la pianificazione comporta uno sforzo di 40 persone/ora per iterazione e altre 40 persone/ore di pianificazione spalmata sui successivi 30 giorni, in conclusione la quantità di tempo dedicata alla pianificazione risulta essere ben maggiore rispetto ad altri metodi, sempre considerando 30 giorni di sviluppo.

Le metriche di Scrum

Le fasi finali di ogni Sprint permettono allo Scrum Team di intraprendere un percorso di continuo miglioramento del processo di sviluppo. Lo scopo è quello di migliorare la qualità del software, cioè di soddisfare i requisiti richiesti dal cliente. Per comprendere quale sia il livello di qualità raggiunto e quali siano i margini di miglioramento è necessario raccogliere dei dati riguardo agli obiettivi raggiunti e a quelli mancati, andando così a individuare le aree più critiche del processo di sviluppo.

Lo Sprint Burndown Chart è uno strumento che permette di misurare lo sforzo che è stato necessario per portare a termine le User Stories e le attività durante lo Sprint. Più nel dettaglio, lo Sprint Burndown Chart è un grafico che illustra l’andamento dello Sprint: sull’asse delle ascisse vengono indicati i giorni dedicati allo Sprint, sull’asse delle ordinate viene misurato il numero di requisiti che non sono ancora stati completati; la retta che viene disegnata su questo grafico parte dal numero di requisiti dello Sprint sull’asse delle ordinate per procedere in diagonale verso il basso. Risulta quindi evidente per chiunque, con un semplice colpo d’occhio capire, se lo sviluppo prosegue come nelle previsioni o se gli sviluppatori sono bloccati (in questo caso troveremo una linea costante, in alcuni casi addirittura crescente).

Il fatto che un team non sia stato in grado di rispettare le previsioni può essere dovuto semplicemente al fatto che alcune attività sono state sottostimate, oppure al fatto che ne sono state introdotte troppe nel corso dello Sprint; quest’ultima situazione è dovuta al fatto che il Product Owner ha inserito troppo carico di lavoro sulle spalle del team e lo Scrum Master non è stato in grado di salvaguardare il team da un eccessivo stress, migliorando la comunicazione tra queste due figure è possibile evitare che situazioni simili si ripetano.

D’altro canto, il Release Burndown Chart è uno strumento molto utile per misurare la velocità del team di rilasciare le attività nel Product Backlog e tenere traccia di quanto lavoro rimane per completare il prodotto.
Questo grafico rappresenta sull’asse delle ascisse il numero di Sprint effettuati e sull’asse delle ordinate lo sforzo richiesto complessivamente dalle attività nel Product Backlog. La misura dello sforzo può essere misurato nel modo che il team preferisce, per esempio: punteggio assegnato alla User Story, dimensione dell’attività, ore di lavoro.

Affinchè il Release Burndown Chart sia utile diventa necessario:

• specificare il numero di release da osservare e quali sono le date di inizio e di fine per ognuna di esse
• definire le attività nel Product Backlog e assegnarle a ogni Sprint
• all’inizio di ogni Sprint si fa una stima del carico di lavoro per la release
• al termine dello Sprint si rimuovono le attività completate.

Questo strumento è utile per tracciare l’andamento del progetto e avere uno storico di quante feature siano state inserite tra uno Sprint e l’altro nel corso del tempo e quante sono state completate.

Un altro strumento molto utile per i team Scrum è il Velocity Report. Questo grafico è simile allo Release Burndown Chart, ma invece di misurare il numero complessivo di attività presenti nel Product Backlog registra lo sforzo dei compiti portati a termine ad ogni rilascio.
Il Velocity Report permette di stimare una media dello sforzo che il team è in grado di sostenere per ogni Sprint, a patto che i componenti del team e la durata degli Sprint rimangano invariati. Inoltre, questo grafico rende subito evidente l’andamento delle performance del team, quando si verificano delle inflessioni è chiaro che il processo di sviluppo richiede una revisione.

Altre metriche più semplici, ma comunque interessanti comprendono:

• User Stories completate vs. User Stories assegnate allo Sprint: si misura l’abilità del team di comprendere e prevedere le sue capacità confrontando il numero di User Stories assegnate allo Sprint con quelle effettivamente completate.
• Technical Debt Management: comprende i problemi noti e i bug inclusi nel rilascio al termine dello Sprint; solitamente misura il numero di bug, ma può anche includere altre informazioni come la documentazione e i mezzi usati per il rilascio; le User Stories che vengono inserite in questa categoria possono essere considerate completate rispetto alle aspettative del cliente, ma che sono state implementate in modo non ottimale per riuscire a rispettare i tempi di consegna.
• Team Velocity: corrisponde alla media di quanto sforzo il team riesce a compiere in un singolo Sprint (vengono considerate solo le attività completate e prive di difetti e/o bug); viene calcolato confrontando il risultato di ogni Sprint con quello precedente, l’obiettivo è di mantenere una capacità costante con margini di +/-10%.
• Qualità del prodotto consegnato al cliente: si valuta se il software rispetta le aspettative e i bisogni del cliente, si cerca di capire quale sia il contributo di ogni Sprint nell’aggiungere valore al prodotto; al termine di ogni Sprint si fornisce una demo al cliente e in base al suo feedback è possibile stimare quale sia il suo grado di soddisfazione.
• Entusiasmo del team: mantenere monitorato il grado di entusiasmo del team per il progetto è utile perchè senza questa componente non esiste processo o metodologia in grado di salvare la situazione; questa metrica può essere ottenuta osservando i risultati degli Sprint nel corso del tempo o chiedendo direttamente agli sviluppatori quanto sono soddisfatti del progetto e si sentano motivati; un altro parametro da tenere in considerazione è il turnover del team, poichè un valore alto può denotare una scarsa motivazione tra i suoi membri.
• Retrospective Process Improvement: l’abilità di uno Scrum Team di rivedere il suo processo di sviluppo per renderlo più efficace nello Sprint successivo; può essere misurato contando quante attività sono state sottoposte a revisione, quante di queste il team si è impegnato a risolvere e quante attività sono state risolte entro il termine dello Sprint.
• Comunicazione: è possibile valutare quanto il Development Team, il Product Owner, lo Scrum Master e il cliente riescono a comunicare tra di loro in modo aperto e onesto; l’unico modo per stimare la qualità della comunicazione è quella di osservare e ascoltare.
• In quale misura il team ha aderito alle pratiche e al metodo Scrum: anche se Scrum non definisce delle pratiche ingegneristiche universali, molte aziende ne stabiliscono delle proprie; è possibile verificare quanto spesso, nel corso di uno Sprint, il team non rispetti le regole prestabilite per misurare il suo grado di aderenza alla metodologia.
• Sprint goal success rates: misura il grado di successo raggiunto dal team in ogni Sprint, per raggiungere un tasso soddisfacente non è necessario portare a termine tutte le attività nello Sprint Backlog, ma una quantità prestabilita di esse e che siano considerabili completate a tutti gli effetti (test, documentazione e integrazione con le altre feature).
• La comprensione dell’obiettivo dello Sprint da parte del team: è una valutazione soggettiva di quanto il team e il cliente abbiano compreso l’obiettivo dello Sprint; solitamente l’obiettivo corrisponde al valore aggiunto che il cliente si aspetta e che è stato definito nei criteri di accettazione per la User Story. Questa valutazione può essere effettuata solo mantenendo un contatto quotidiano con il team e con il cliente.