Tra i numerosi metodi per gestire il processo di sviluppo è molto difficile trovarne uno che accontenti tutti: spesso i tanti ruoli introdotti o la difficoltà di certe procedure non si adattano a certe tipologie di progetto. Scrum si connota per la semplicità del modello proposto per organizzare il proprio progetto. In questo articolo cominciamo ad analizzarne le linee guida, rimandando al prossimo mese gli scenari di applicazione e la conclusione del discorso.
Che cosa è Scrum ?
Scrum è una metodologia agile di sviluppo del software. [WP3]. Come tutte le metodologie agili è incentrata sulla riduzione del numero di ruoli e del numero di artefatti da produrre. Ha ovviamente anche delle sue peculiarità e, rispetto ad altre metodologie, si differenzia in quanto si delinea come un “framework”. In tal modo, Scrum non è un metodo rigido, ma piuttosto rappresenta una base su cui costruire un processo di sviluppo, che sarà di volta in volta adattato alla realtà in cui viene calato. Non a caso, il motto di Scrum è “l’arte del possibile”.
User Story
Gli elementi che caratterizzano Scrum sono molti, ma alcuni sicuramente hanno un peso maggiore rispetto ad altri. In particolare viene introdotto un concetto “nuovo”: la User Story. È abbastanza normale cercare di fare paragoni con altri ambiti: in metodologie diverse ci si potrebbe riferire alla User Story con termini quali “requisito utente” o “funzionalità” o “specifica”. Sono tutte parole abbastanza adeguate ma non catturano pienamente lo “spirito” che Scrum assegna a una User Story.
Descrivere una storia utente è molto complicato e spesso la sua identificazione può essere difficile. Un buon punto di partenza per capire di cosa stiamo parlando è il modello INVEST [WP4]. Esso è un acronimo che viene sciolto come segue:
- Independent
- Negotiable
- Valuable
- Estimable
- Small
- Testable
Vediamo di tradurre tali aggettivi in pratica. Secondo tale impostazione INVEST, una User Story quindi dovrà soddisfare una serie di condizioni.
Non deve dipendere da nessuna altra storia (Independent). Deve essere possibile chiarirla in tutti i suoi aspetti (Negotiable) attraverso il dibattito fino a quando tutti gli attori coinvolti non concordano sul suo contenuto. Esiste solo se anche l’utente finale trae vantaggio (Valuable) dalla sua realizzazione e deve essere possibile effettuarne una stima (Estimable). Essa deve inoltre essere piccola (Small) e oggettivamente verificabile (Testable).
Inoltre, durante la fase di “negoziazione”, si devono identificare tutti gli ostacoli che possono impedire o rallentare la realizzazione di una storia. In questo modo è più facile mettere in evidenza i rischi e attivarsi per tempo per rimuovere ogni impedimento.
A questo punto, quando una storia viene identificata, deve essere anche registrata e catalogata. Scrum prevede un artefatto specifico per questo compito chiamato Product Backlog. Al momento del suo inserimento, ad ogni storia viene associata una “importanza“ o una priorità in modo tale da poter decidere quali realizzare prima e quali dopo.
Il tempo
In Scrum ogni attività è time boxed, cioè ha una durata certa! Assegnare dei limiti di tempo (molto stretti) per ogni attività aiuta a concentrarsi solo sulle cose strettamente necessarie. La consegna delle storie avviene quindi con una frequenza molto alta: in tal modo, si possono ricevere dei feedback molto velocemente ed eventualmente correggere subito le cose che non vanno bene, senza traumi tardivi.
Ruoli
In Scrum, le persone che partecipano al progetto vengono inquadrate in ruoli a cui corrispondono delle responsabilità. In pratica esistono 2 macro categorie: pig e chicken. Scrum ha un linguaggio molto colorito e questa divisione fra “maiali” e “polli” deriva da una barzelletta in cui un pollo propone a un maiale di aprire insieme un ristorante, da chiamare “uova e prosciutto”. Chiaramente, in un accordo del genere, la categoria più coinvolta è proprio quella del “maiale”…
Pertanto, della macrocategoria pig fanno parte i ruoli di Product Owner (PO), di Scrum Master (SM), e il Team, cioè coloro che a vario titolo identificano e realizzano le User Story.
Della seconda, categoria, quella dei chicken, fanno parte gli Stake Holder, i manager e qualsiasi altra persona che si può ritenere un “osservatore interessato” del progetto a qualsiasi titolo, ma che non si occupa in alcun modo di realizzare le storie utente.
Team
Il Team è l’insieme delle persone più direttamente coinvolte nella fase di sviluppo e deve esprimere tutte le competenze, funzionali e tecniche, utili alla consegna del lavoro. Esso si autogestisce e quindi tutti i componenti del Team hanno stessa “dignità” e responsabilità. Il Team è l’unico ruolo che può effettivamente dire quanto costa realizzare una storia.
Product Owner
Il Product Owner (PO) è una singola persona e rappresenta gli interessi degli utenti. Il suo compito è quindi quello di analizzare le richieste degli Stake Holder per poterle poi “tradurre” al Team e allo Scrum Master. Il PO è l’unico che può assegnare importanza e priorità alle User Story.
Scrum Master
Lo Scrum Master (SM) è una persona al servizio del Team e del PO. Il suo compito è quello di sorvegliare che il processo venga “implementato” nel modo corretto. Lo SM deve rimuovere tutti gli ostacoli che gli vengono segnalati e deve aiutare il PO a massimizzare il ROI.
Scrum Heartbeat
Sprint Planning e Sprint Backlog
Le “pulsazioni” (o per meglio dire le iterazioni) di un processo basato su Scrum sono chiamate Sprint. Uno Sprint è pertanto un periodo di sviluppo, che ha le seguenti caratteristiche:
- ha un obiettivo dichiarato (goal) espresso in modo chiaro e non tecnico;
- ha una durata prefissata (generalmente di 3 o 4 settimane) e quindi una data di consegna (demo) ben identificata;
- deve portare alla realizzazione completa di una lista di storie presenti nel Product Backlog.
Figura 1 – Le “pulsazioni” del processo: Scrum Heartbeat
Tutte queste informazioni sono raccolte in un altro artefatto previsto da Scrum chiamato Sprint Backlog creato alla fine dello Sprint Planning, che è una riunione a cui partecipano PO, SM e tutto il Team e che non dovrebbe durare più di un giorno di lavoro.
Lo svolgimento del planning è una di quelle parti che dipendono altamente dalla situazione e dalle persone coinvolte per cui, anche se esistono delle indicazioni di massima al riguardo, ogni gruppo di lavoro può mettere a punto un suo personale metodo di pianificazione.
In ogni caso le indicazioni generali consigliano di dividere giornata di planning in 2 parti: nella prima parte si scelgono le storie da realizzare; nella seconda parte, il Team suddivide in task le storie ed eventualmente pone al PO delle domande per chiarire con esattezza qual è il contenuto e il costo di tali storie.
Sprint (Execution)
Dopo la pianificazione (che vi assicuro sarà l’attività più difficile) è giunto il momento di lavorare sul serio. Questo è il periodo dello sprint vero e proprio, in cui tutto il Team è concentrato nella realizzazione delle storie e si fa aiutare dallo SM nell’eliminazione degli ostacoli individuati. Lo Scrum Master ha anche il compito di evitare che altri interferiscano in modo inopportuno con il Team perche’ questo riduce la capacità di concentrazione e quindi anche la velocità di lavoro.
Può sembrare che questo periodo sia tutto sommato facile da “gestire”, ma nella realtà questo è il periodo in cui si concentrano i maggiori rischi, perche’ alla fine del planning è stata fatta una promessa (formalizzata nello Sprint Backlog) e ora si deve mantenerla!
Tuttavia tutti coloro che non hanno fatto quella promessa (chicken, colleghi vari, passanti…) sono prontissimi a disturbare il lavoro del Team con mille richieste (molto legittime e intelligenti) ma che portano via tempo e concentrazione anche solo per starle ad ascoltare.
Naturalmente i membri del Team possono (o, meglio, devono) parlare tra loro perche’ questo migliora il passaggio delle informazioni e delle conoscenze e aiuta a chiudere in tempi minori le singole attività.
In ogni caso la giornata di lavoro ha un proprio “rito” per cominciare le attività, chiamato Daily Scrum che si può concludere in soli 15 minuti. In pratica è una brevissima riunione, in cui ogni persona deve rispondere alle seguenti domande:
- cosa ho fatto ieri?
- cosa farò oggi?
- quali sono gli ostacoli che ho rilevato?
Questa mini riunione a cui partecipano SM e Team si dovrebbe svolgere al mattino, più o meno sempre alla stessa ora, prima di iniziare le attività della giornata.
Sprint Demo o Review
Alla fine di uno sprint c’è la demo! Si tratta di una giornata (in alcuni casi potrebbero bastare addirittura pochi minuti) in cui si mostrano a PO e Stake Holder i risultati ottenuti.
Ma come ci si prepara a una demo? Prima di tutto si parte dallo sprint backlog e, per ogni storia che era stata promessa, si dichiara se questa è stata o meno realizzata completamente. Le storie non complete non saranno presentate in demo.
Al termine di questa fase il PO, insieme allo SM, mostra agli Stake Holder i risultati ottenuti. In quest’ultima fase è molto importante raccogliere il maggior numero di feedback e capire quali correzioni apportare.
Sprint Retrospective
Dopo la demo, lo SM incontra il Team per illustrare a tutti il risultato della demo e per ragionare insieme su quali sono i problemi che maggiormente ostacolano il lavoro. Questa riunione non dovrebbe andare oltre le 4 ore di lavoro; però spesso è necessario formalizzare in qualche modo (documentare) il contenuto della riunione: e quindi arrivare fino a un massimo di 8 ore è a mio parere assolutamente accettabile.
In particolare è possibile che si debbano aggiornare le linee guida del progetto in termini di standard di design e architettura oppure aggiornare un documento di FAQ in cui vengono raccolte domande, “tips & tricks”, e così via, che aiutano a condividere in modo più veloce ed efficace le soluzioni adottate.
Sprint Monitoring
Come tutti i progetti, anche quelli realizzati con Scrum devono essere monitorati per capire cosa sta succedendo; come in tutti i processi agili, è necessario che siano resi effettivi i concetti di chiarezza e trasparenza nei confronti di tutti, in particolare degli Stake Holder.
Questa operazione è sempre molto complicata ed è difficile formalizzarla in modo assoluto e quindi sarà soggetta a forte personalizzazione in quanto è molto utile al Team ma spesso è necessaria anche per coloro che valutano il progetto: persone che generalmente ignorano Scrum e i suoi principi.
Velocity
La velocity di un Team è l’effort esprimibile durante uno sprint! Teoricamente è quindi molto facile calcolare tale informazione:
Vt = nT * nD
Dove nT è il numero di sviluppatori e nD è il numero di giorni di esecuzione dello sprint. Quindi per esempio se c’è un Team di 5 persone (nT = 5) e uno sprint di 3 settimane (nD = 15) allora la velocità sarà di V = 5 * 15 = 75 giorni di lavoro per sprint. Ma occorre fare attenzione! Questa velocità è solo teorica e va verificata prima di ogni sprint per svariate ragioni. Anzitutto, il numero di giorni lavorativi reali potrebbe essere più basso del previsto, a causa di ferie e festività; e sono poi possibili sia imprevisti personali di ogni partecipante che sforamenti delle stime. Inoltre, cè un ulteriore aspetto da tenere in considerazione ed è che lo Scrum Master non dovrebbe essere conteggiato nel nT per definire la velocity, in quanto il suo lavoro è oggetto di forti interazioni con l’esterno e quindi non può effettivamente concentrarsi solo su una serie di attività isolate.
Empiricamente, comunque, si può stabilire che la velocità media (Vm) di un buon Team debba essere compresa tra il 60% e il 70% della velocity teorica.
Vm = nT * nD * 0.65
Per cui nell’esempio precedente avremmo che la velocità media Vm è di circa 50 giorni. Naturalmente queste sono solo indicazioni: occorre usare il buon senso per capire l’effettiva capacità del proprio Team e adoperarsi affinche’ la velocity sia la maggiore possibile.
Un’ultima nota riguarda il modo in cui misurare la velocity. Le unità di misura usate in Scrum possono essere diverse: story points, giorni, ore, a seconda delle preferenze dei vari gruppi di sviluppo. In questa miniserie adotteremo come unità di misura i giorni di sviluppo.
Burndown Chart
Un burndown chart è un diagramma cartesiano per monitorare l’andamento di uno sprint: sull’asse X sono indicati i giorni dello sprint, mentre sull’asse Y sono indicati i giorni di effort.
Figura 2 – Un Burndown Chart per monitorare l’andamento di uno Sprint.
Una volta che si è potuta stabilire la velocity del proprio Team, si può monitorare l’andamento dello sprint grazie ai Burndown Chart. Come prima cosa si traccia la linea ideale di effort erogabile giorno per giorno in base alla velocity stabilita. Poi si traccia, sempre giorno per giorno, la linea dei giorni che mancano alla consegna dello sprint. Se la linea dei giorni che mancano alla consegna è al di sopra della linea ideale, vuol dire che il progetto è in ritardo e quindi sarà necessaria una qualche analisi per adottare le adeguate correzioni.
In ottica di trasparenza, il grafico deve essere visibile da chiunque, ma occorre ricordare che non tutti riusciranno a “leggerlo”; per cui per “spiegarlo” è forse raccomandabile un nota in cui si indica se il progetto è in linea oppure in ritardo (e in teoria potrebbe essere anche in anticipo…).
Un altro strumento utile per monitorare l’andamento del progetto è la Task Board. Essa è semplicemente una lavagnetta in cui si appiccica un post-it per ogni task diviso per storia e stato.
Figura 3 – La Task Board: uno strumento utile per monitorare l’andamento del progetto, è praticamente una lavagnetta in cui si attacca un post-it per ogni task. Consente di vedere con uno sguardo d’insieme cosa è già stato fatto e cosa è attualmente in corso d’opera.
In questo modo è molto facile capire cosa è in lavorazione e cosa invece è già stato fatto. In particolare se si deve gestire una storia, essa è completa quando tutti i task ad essa associati sono chiusi e soprattutto quando è “dimostrabile” tramite un test ripetibile in demo oppure che produce un report valido per gli Stake Holder.
Conclusioni
Ci fermiamo qui, per ora, dopo aver visto alcuni elementi fondamentali per la pianificazione, l’esecuzione e il monitoraggio di uno Sprint. Come sarà apparso da questi primi fondamentali, Scrum è una metodologia con alcune sue peculiarità e con uno “spirito” particolare in cui occorre entrare per sfruttarla al meglio, ma non è affatto un processo complicato.
Sostanzialmente abbiamo visto come si gestisce una iterazione di lavoro con Scrum, ma non abbiamo spiegato cosa succede prima e dopo uno Sprint. Bene, riprendermo il discorso il prossimo mese proprio vedendo il prima e il dopo di uno Sprint.
Riferimenti
[KEN1] Ken Schwaber, “Agile Project Management with Scrum”, Microsoft Professional
[SC1] Henrik Kniberg, “Scrum and XP from the Trenches”
[SC2] Schema riassuntivo degli elementi di Scrum
[MTD1] Scrum Methodology
[MTD2] Scrum Alliance
[WP1] Wikipedia, locuzione latina “Si vis pacem, para bellum”
[WP2] Wikipedia, voce “Comunicazione”
[WP3] Wikipedia, voce “Scrum”
[WP4] Wikipedia, voce “INVEST”
[WP5] Wikipedia, pagina su uno dei due inventori di Scrum, fondatore della Scrum Alliance
[WP6] Wikipedia, locuzione latica “De iure”
[SW1] Rally Software
[SW2] Scrum Tools – ScrumWorks Pro & ScrumWorks Basic