Gli artefatti di Scrum per il lavoro rappresentano un valore in quanto forniscono diversificate modalità attraverso le quali generare trasparenza e opportunità di ispezione e adattamento. Gli artefatti definiti da Scrum sono progettati per massimizzare la trasparenza delle informazioni chiave, di modo che ognuno abbia lo stesso livello di comprensione. Le decisioni per ottimizzare il valore e controllare il rischio sono prese in base allo stato attuale percepito degli artefatti. Nella misura in cui gli artefatti non siano completamente trasparenti, tali decisioni possono essere imperfette, il valore può diminuire e il rischio può aumentare. Compito dello Scrum Master è quello di lavorare con il Team di Scrum e con l'organizzazione per aumentare la trasparenza degli artefatti. Questo lavoro di solito comporta una fase di apprendimento: la trasparenza non si ottiene da un giorno all'altro, ma piuttosto attraverso un percorso chiaro e condiviso.
Il product backlog è il primo grande artefatto di Scrum, un elenco ordinato e prioritizzato di idee per il prodotto, ed è l’unica fonte di requisiti per le modifiche da apportare al prodotto. Per iniziare con la stesura del Backlog, naturalmente, bisogna avere un’idea chiara di ciò che si vuole ottenere alla fine del lavoro: quando si ha in mente la visione del prodotto, bisogna valutare con meticolosità cosa occorrerà per tradurla in realtà.
Il Product Owner è in linea teorica l’unico responsabile del Product Backlog, compreso il suo contenuto, la sua disponibilità, l’ordinamento e l’armonizzazione dei suoi elementi.
Naturalmente, anche il team di sviluppo ha il compito di supportare il PO nell’identificare le funzionalità e gli elementi da prioritizzare e le attività che richiedono maggior sforzo in termini di tempo e capacità. Oltre che, ben si intende, coadiuvare il PO nell’intercettare eventuali aspetti mancanti, soprattutto se intendiamo aspetti squisitamente tecnici dei quali il PO, essendo una figura rappresentante il lato business, può non avere massima consapevolezza e conoscenza. Il Product Backlog evolve insieme al prodotto e inizialmente comprende solo i requisiti di
36 prodotto meglio compresi e conosciuti: può nascere come una lunga lista oppure con pochi elementi, ma non è mai completo, è dinamico e cambia continuamente per identificare ciò che serve al prodotto per essere appropriato, competitivo e utile. Il Backlog infatti è soggetto a cambiamenti nei requisiti di business, tecnologici o semplicemente imprevisti che sorgono durante lo svolgimento degli sprint.
Il Product Backlog elenca tutte le caratteristiche, le funzioni, i requisiti, le migliorie e le correzioni che costituiscono le modifiche da apportare al prodotto nelle future versioni. I suoi elementi sono per lo più caratterizzati da un ID identificativo, un effort, ovvero la stima in punti che stabiliscono gli sviluppatori, lo status attuale, ad esempio se si tratta di un elemento ancora da lavorare o in lavorazione, il business value, non è altro che la priorità definita, il team e il progetto a cui fanno riferimento. I requisiti non smettono mai di cambiare e perciò il Product Backlog è un artefatto vivente. Il product backlog, come appena visto, contiene stime approssimative sia del valore di business che dell’effort necessario a svilupparle; tipicamente per stimare la complessità delle storie si usa il planning poker game: il team si riunisce avendo davanti le user stories da stimare, idealmente proiettate davanti a sé, e pesa ciascuna storia usando la serie di Fibonacci, i numeri sono chiamati story points. Il primo passo, al fine di avere un termine di paragone condiviso da tutto il team, è pesare/stimare la story più semplice mettendole 1 come story point. Il passo successivo è stimare le altre story dopo averle lette insieme ed, eventualmente, aver chiesto dei chiarimenti. Ognuno sceglie il punto in autonomia e senza farsi vedere, al momento della “scoperta delle carte”, ci si confronta: se c’è convergenza tra tutto il team allora quel numero corrisponderà ai points, se si verificasse discordanza, i membri che hanno scelto il numero più basso e più alto si confrontano e si arriva ad una conclusione concertata e condivisa. Infine, una volta stimate tutte le stories, si sommano i punti totali che corrisponderanno allo sforzo da erogare per lo specifico sprint. Il team di sviluppo è responsabile di tutte le stime.
Un buon metodo per mantenere il backlog ordinato è sicuramente raggruppare le attività per aree tematiche o Features. L’attivita di refiniment, ad ogni modo, comprende azioni anche volte a eliminare o riposizionare elementi qualora si ritenesse necessario, dividere (“to split”) in due elementi, soprattutto user story, che risultano troppo lunghe e complesse, in modo da agevolarne la lavorazione, stimare gli elementi e scrivere i tasks.
37 Il Product Owner può influenzare il Team di Sviluppo aiutando a capire e selezionare i compromessi ma, coloro che eseguiranno il lavoro sono gli stessi che effettueranno la stima finale.
View of Product Backlog on Target Process11:
Per Sprint backlog, come suggerisce il nome stesso, si intende la lista del lavoro che il team development deve effettuare nel corso dello sprint successivo. Questa lista viene formata selezionando una quantità di storie/funzionalità a partire dalla cima del product backlog e determinata da quanto il Team di sviluppo ritiene possa essere effettivamente realizzato durante lo sprint. Il Team di Sviluppo modifica lo Sprint Backlog durante tutto lo Sprint e lo Sprint Backlog emerge durante lo Sprint. Ciò si può verificare quando il Team di Sviluppo viene a conoscenza di più dettagli sul lavoro e sugli strumenti necessari a raggiungere il Goal fissato per lo sprint. In ogni caso, dopo il primo Sprint il backlog subirà continue modifiche, e col backlog anche l’ordine di priorità: probabilmente non si raggiungerà mai l’ordine ideale, ma l’idea è quella di identificare l’ordine capace di generare il massimo valore nel minor tempo, di
11 Nelle metodologie agile oltre ad esistere diversi framework, esistono anche diversi tool. L’immagine qui
riportata, e le altre che seguiranno, saranno tutte immagini catturate dal tool agile Target Process, poiché è quello utilizzato in Spindox.
38 raggiungere l’ordine ideale, sprint dopo sprint12. Durante le due settimane che formano lo sprint,
il team si auto-organizza per produrre un incremento di Prodotto corrispondente allo Sprint Backlog, come concordato durante lo Sprint Planning. Questo significa che il team si prende la responsabilità di produrre un incremento di prodotto in accordo con quanto stabilito insieme al Product Owner. L’incremento cui si fa riferimento non è altro che la somma di tutti gli elementi del Product Backlog completati durante lo sprint e che sono tali da creare valore per il cliente. Alla fine di uno Sprint, il nuovo Incremento deve risultare “Fatto”13, il che significa che deve
essere utilizzabile e deve incontrare la definizione di “Fatto” data dallo Scrum Team. Inoltre, ciò che dovrebbe essere fatto alla fine di ogni Sprint, è selezionare un piccolo miglioramento, definito da alcuni kaizen14, e far sì che questo diventi la cosa più importante da realizzare nello sprint successivo. Miglioramento continuo e misurazione del miglioramento sono elementi chiave per un appropriato uso di Scrum.
Passiamo ad uno degli elementi più piccoli utilizzati in Scrum: la user story.
Sebbene la metodologia Scrum non preveda formati particolari per gli elementi che compongono il backlog, e in particolare per definire le caratteristiche di un prodotto, lasciando quindi libertà al team, lo schema delle user stories sembra uno tra i più utilizzati, per la sua semplicità e per le sue caratteristiche che lo rendono ben adatto ad un processo iterativo ed incrementale come è Scrum. Prima di gettare nero su bianco le user stories del prodotto che si sta sviluppando, bisogna che tutti, Product Owner compreso, abbiano in mente il processo per trasformare l’idea da cui si è partiti in un vero e proprio prodotto; riescano a definirne i requisiti fondamentali; sappiano identificare in maniera efficace i bisogni dell’utente in modo tale che il prodotto possa soddisfarne le esigenze; conoscere, dunque, chi è il vero utente del prodotto. La storia utente, infatti, raccoglie i requisiti, specifica il valore e le priorità.
La user story così intesa in Scrum, e non solo, non è altro che la rappresentazione esplicita di un bisogno business da parte dell’utente, espresso con linguaggio semplice e naturale, comprensibile sia ai più tecnici che ai meno “esperti” in materia.
Nella compilazione di una storia utente, si parte dal definire in modo piuttosto generico e ad alto livello le funzionalità che andranno implementate per rispondere al bisogno espresso. Va
12 Un’idea interessante è quella di J. Sutherland: l’80% del valore di un prodotto (e per valore intendiamo ciò
che davvero desiderano le persone) sta nel 20% delle sue caratteristiche.
13 Si è parlato in un paragrafo precedente dell’espressione done o fatto in Scrum, oltre che dell’importanza che
il significato di questa sia sempre ben chiaro e condiviso da tutti.
14 Il termine kaizen deriva dalla lingua giapponese ed è l’unione di due parole, KAI che vuol dire cambiamento o
39 da sé che i dettagli prettamente tecnici o relativi al design, non sono destinati a rientrare all’interno dei confini delimitati dalla storia utente.
Gli elementi del Product Backlog, di cui si è già trattato, sono organizzati e classificati in base alla grandezza e/o livello di dettaglio: le Epiche sono l’elemento di più ampio respiro che definiscono e raccolgono le macro funzionalità; le Features sono elementi sempre grossi, ma che possono definirsi come raccolta di storie; infine le User Stories, sufficientemente contenute e dettagliate da poter essere prese in carico e messe in lavorazione dal team di sviluppo. Ogni storia ha una dimensione compatibile con uno sprint ed è a sua volta scomposta in elementi più piccoli, i cosiddetti tasks di natura tecnica, i quali vengono stabiliti solo e soltanto dal team di sviluppo e che servono anche e soprattutto a stimare l’effort e la capacity necessari per lavorare una specifica user story. I task, rispetto alle storie, hanno una durata che si potrebbe misurare in ore lavorative, e che difficilmente supera la giornata. Da questo punto di vista, i task sono come strumenti di cui si avvale il dev team per raggiungere l’obiettivo di ogni sprint: definire le storie come done.
Uno strumento efficace e diffuso tra chi si avvale di metodologie agile e incrementali come Scrum è la dash board, sia essa fisica o magnetica. In entrambi i casi, l’obiettivo che si vuole raggiungere è godere delle potenzialità del Visual, ovvero mettere a disposizione di tutto il team lo stato dell’arte del progetto, usando dei post-it colorati in cui sono trascritte tutte le user stories, e altri post-it più piccoli spesso contrassegnati da un codice in cui per ogni storia sono assegnati i task necessari al suo completamento. I post-it si muovono, seguendo un percorso che li vede attraversare lo stato di “open”, per cui si intendono le user stories comprese nel backlog ma ancora da lavorare, “in progress”, qui si trovano le storie oggetto di sviluppo e lavorazione nel momento corrente, “verify”, che è lo stato intermedio tra il momento in cui una storia è stata completata e quello in cui si può effettivamente considerarla come fatta e conclusa. La board è un mezzo utile per seguire lo stato di avanzamento sia dei tasks, quindi delle sotto- attività, che delle storie complete. Spesso, chi si avvale di questo strumento, tiene a mente anche alcuni principi tipici della metodologia inventata in Toyota15 e che ben si sposano alle metodologie agile: prediligere l’approccio pull e non push, limitare il numero di storie in
15 l termine "Lean" si è diffuso nei primi anni 90, grazie al best-seller che descrive l'approccio di Toyota alla
fabbricazione delle automobili, "The Machine That Changed the World" che descrive il Toyota Production System (TPS). L'approccio manifatturiero di Toyota, più comunemente noto come "Lean Production", ed implementato da Taiichi Ohno, esprimeva un modo di realizzare le autovetture in netta contrapposizione con quello della produzione di massa ("mass production"). L'obiettivo di Toyota era ottenere la migliore qualità e abbattere i costi e i tempi di realizzazione delle autovetture attraverso l'eliminazione degli sprechi (waste).
40 lavorazione, dare priorità al completamento delle storie già iniziate invece di cominciarne delle nuove e lasciarne altre di conseguenza in sospeso.
In parte connesso a questi aspetti, riemerge l’importanza già sottolineata dell’avere una condivisa e inequivocabile idea di cosa il team intende quando stabilisce che una storia è in “done”, per evitare che alcuni elementi del team possano spostare le storie in done prima del tempo e/o prima che effettivamente la storia possa essere considerata completata sotto tutti i punti di vista. Solo la definition of done16 fornisce i criteri utilizzati per validare o meno una user story e solo quando essi sono rispettati insieme ai criteri di accettazione specifici per ciascuna user story si può davvero considerare quella storia utente soddisfatta e terminata. Per ciò che riguarda la responsabilità sui tasks, il team di sviluppo si organizza autonomamente su quali task assegnarsi e, nonostante non sia una regola fissa e irrinunciabile, molto spesso il task rimarrà in carico allo sviluppatore lungo tutte le fasi previste dalla board.
Passando alla forma vera e propria in cui si presenta una user story, anche qui nonostante Scrum e le metodologie Agile non impongano un formato fisso e preconfezionato, si tende ad utilizzare diffusamente il seguente schema o formula:
As a < type of user >, I want < some goal > so that < some reason >.
Si riporta un esempio per fissare al meglio la struttura dello schema: As a user
I want to be able to login with Facebook So that I can save time
Come si nota, la formula utilizzata è piuttosto semplice ed intuitiva per tutti. Si specifica il tipo di utente cui il prodotto è indirizzato, si esprimono i desideri e i bisogni che l’utente ha manifestato e/o quelli a cui si vuole rispondere attraverso le funzionalità del prodotto, e infine si specifica il perché l’utente desidera quella funzionalità, il vero fine. Tuttavia, una user story per essere completa necessita dei propri criteri di accettazione, criteri usabili chiari che devono essere soddisfatti affinché una storia possa considerarsi finita. Anche questi ultimi sono spesso
16 Secondo la Scrum Alliance, La definition of done (DoD) è definibile come: “a checklist of valuable activities required to produce software”; “the primary reporting mechanism for team members”; “is informed by reality”;
41 scritti seguendo un particolare schema che definisce dei prerequisiti, una certa condizione, specifiche azioni e infine i risultati che ci si aspetta da esse. Si riporta un esempio di acceptance criteria legati alla user story di cui sopra:
Given I'm on the home screen with the Login With Facebook button,
When I press the 'Login With Facebook' button and I login with my Facebook credentials, Then I'm back on the home screen and the app shows that I'm logged in
Nel lavoro di gestione di un progetto con Scrum, scrivere user stories, specificare i task e definire i criteri di accettazione, sono tutte attività altamente strategiche e ad alto valore, che necessitano di cura e di attenzione al fine di non compiere errori nel processo di definizione e refiniment del Product Backlog e nella corretta esecuzione degli sprint.
A questo punto della trattazione, si evince quanto possano essere cruciali i grafici in Scrum. Il grafico di burndown in Scrum è uno strumento vitale di comunicazione in quanto permette di monitorare lo stato di avanzamento del lavoro del team di sviluppo. Il burndown è un istogramma il cui asse orizzontale rappresenta il tempo raffigurato sotto forma di step discreti, mentre sull’asse verticale sono riportate tutte le attività che devono ancora essere avviate. Sull’asse verticale avremo dunque il totale degli elementi del backlog, sull’asse orizzontale la data di attesa del termine del progetto. Questi tipi di grafici tendono tipicamente verso le zero, dal momento che ogni attività viene portata avanti, anche se fosse solo di poco, ogni giorno. Esistono due tipi diversi di grafici burndown, uno di Release e uno di Sprint. Come si può facilmente immaginare, il grafico burndown di Release mostra il lavoro rimanente (remaining work) in riferimento all’intero progetto, i grafici di burndown di Sprint, a loro volta, fanno riferimento alla quantità di lavoro rimanente per il ciclo di Sprint corrente. Tendenzialmente, questi ultimi vengono aggiornati quotidianamente, mentre i primi a valle di ciascun Sprint. Una delle funzionalità principali di questa tipologia di grafici è offrire valide informazioni al team riguardo al rispetto o meno della data di rilascio del prodotto, dunque, di conseguenza, di offrire l’opportunità al team di adottare tempestivi provvedimenti qualora dal grafico emergessero ritardi e complicazioni. Prendere provvedimenti può voler dire rivedere il backlog, eventualmente eliminare alcuni suoi elementi e più in generale velocizzare il lavoro rintracciando impediments che ne causano il rallentamento. Nota interessante è che i grafici burndown così intesi, non mostrano tanto il tempo trascorso sul prodotto, ma si concentrano piuttosto sul tempo rimanente al completamento del prodotto, nei suoi stadi intermedi e finali.
42 In questo modo si può ovviare ad un facile accostamento fuorviante, ossia credere che esista una correlazione quasi perfetta tra le ore di lavoro effettuate e la quantità di lavoro portato a termine. Dal punto di vista specifico della modalità di rappresentazione, si immagini di tracciare una retta “ideale” che unisca i due punti A e B, dove A è il lavoro da implementare, vediamolo anche come i punti del backlog, e B il tempo che scandisce la durata dell’intero progetto, dall’inizio alla sua fine. La retta discendente che ne viene fuori fornisce un’idea, iterazione dopo iterazione, di quale dovrebbe essere il trend dell’implementazione delle storie utenti affinché il progetto possa completarsi nei tempi e nei vincoli previsti. Una seconda linea (actual progress line) seguirà invece fedelmente il reale andamento del progetto, accostando la quantità di lavoro col tempo rimanente. In generale, valgono due considerazioni:
• Se la “actual work line” è al di sotto della retta ideale, allora il team sta lavorando più velocemente del previsto e il progetto è in anticipo con i tempi
• Se la “actual work line” è al di sopra della retta ideale, allora il team ha performance scarse in termini di tempo e il progetto è in ritardo
43
VI. Un processo Iterativo ed Incrementale
Il termine iterative, dall’inglese, o iterazione dall’italiano, sono ricorrenti per chiunque si approcci a metodologie della natura di Scrum.
Di cosa intendiamo per iterazioni abbiamo già avuto modo di parlare durante il presente lavoro, tuttavia, essendo termini molto diffusi tra chi sviluppa software attraverso un processo agile, è utile definire bene il significato di queste due espressioni, la differenza che li distingue e, finalmente, esporre la ragione per cui Agile Scrum ha bisogno che i suoi processi siano entrambi: incrementali e iterativi.
Cominciamo con lo spiegare perché sviluppare un software non può essere unicamente un processo accompagnato da una strategia incrementale. Jeff Patton, autore del testo User Story Mapping17, riporta un interessante paragone per sostenere la sua tesi: l’artista e lo sviluppatore
di un software. In particolare, se pensiamo al processo che aveva in mente Leonardo Da Vinci quando ha realizzato una delle sue opere più note, la Monna Lisa, difficilmente potremmo ammettere che esso sia stato guidato da una strategia incrementale. Se così fosse dovremmo immaginare che Da Vinci avesse sin da subito impressa nella mente l’idea e la vision perfettamente delineata in tutti i suoi particolari di quella che sarebbe stata la donna ritratta nel dipinto. Di conseguenza, egli avrebbe costruito il quadro aggiungendo giorno dopo giorno un singolo “pezzo” di esso, arrivando così con estrema semplicità all’ultimo giorno in cui,