Fondamentali di SCRUM

Agile Project Management - LC90.99B
Che Cosa è SCRUM
L’interesse verso il project management Agile è unanimemente condiviso. Anche chi non è direttamente
“committed” dovrà avvicinarsi alla nuova terminologia e la filosofia sottostante.
Per apprendere la terminologia Agile conviene studiare SCRUM - il tool Agile più diffuso.
Le definizioni e la terminologia che seguono sono condivise dai massimi guru della disciplina,
come Mike Cohn, autore di Agile Estimating and Planning che ha ispirato questo elaborato
a beneficio di coloro che intendono affrontare la certificazione Agile PMI-ACPsm.
Scrum, forse il processo Agile più diffuso nello sviluppo software, sta diventando un "general-purpose
project management framework” utilizzabile anche in altri settori su progetti urgenti, complessi e
innovativi. I progetti Scrum procedono con iterazioni dette sprint che durano da 2 a 4 settimane. Perciò,
qualsiasi progetto complesso, innovativo e urgente può essere affrontato con un approccio Agile-SCRUM.
Team Scrum (gruppo di progetto)
Un Team Scrum composto solitamente da 5 a 9 persone, può raggiungere anche le centinaia di addetti e
può essere anche di una sola persona. Con Scrum non ci sono più le figure tradizionali dello sviluppo
software come: programmatori, designer, tester o architetti, ma tutti lavorano insieme per realizzare il lavoro
promesso in ogni sprint, convinti di “essere tutti sulla stessa barca”.
Il Product Owner rappresenta gli utenti, i clienti e altri soggetti coinvolti nel processo.
Lo ScrumMaster è responsabile di garantire che il team utilizzi correttamente il processo
eliminando eventuali ostacoli e proteggendo il team dalla pressione del Product Owner.
Scrum,
Il Product Backlog è la lista di lavori desiderati o di modifiche necessarie al prodotto. All’inizio di ogni
sprint, in una riunione di pianificazione, il product owner illustra i primi elementi del backlog al team, il
quale decide quale lavoro eseguire durante lo sprint successivo, spostandolo dal product backlog allo sprint
backlog che costituisce la lista dei task che il team promette di realizzare nel prossimo sprint.
Ogni giorno tutto il team partecipa ad una riunione veloce detta Daily Sprint per contestualizzare il lavoro
del giorno e mantenersi allineati. Alla fine di ogni sprint, il team espone ciò che ha realizzato in una sprint
review meeting. Si tratta di una demo informale di ciò che è stato realizzato durante lo sprint. Non sono
ammesse slide PowerPoint, la riunione non deve diventare un task né una distrazione dal processo.
Sempre alla fine di ogni sprint il team esegue uno sprint retrospective per riflettere su come sta
funzionando il processo Scrum e cosa cambiare per lavorare meglio.
Il termine “backlog” viene utilizzato con due accezioni:


Product backlog - lista di dispositivi (feature) che dovrà avere il prodotto.
Sprint backlog - lista di task da eseguire in uno sprint.
Mutuato dal Rugby,
il termine SCRUM indica un gruppo di persone che si spinge per agguantare la palla lanciata dall’arbitro.
Materiale utile per Prepararare la Certificazione Agile PMI-ACMsm
di
Vito Madaio
pag. 1
Agile Project Management - LC90.99B
Rappresentazione Visuale
Mike Cohn rappresenta l’intero processo Scrum con il seguente grafico:
Il grafico contiene gli elementi essenziali del processo Scrum. A sinistra vediamo la product backlog
con le relative priorità stabilite dal product owner , ciò che si conosce alla data.
All’inizio di ogni sprint, il team stabilisce il lavoro da eseguire durante lo sprint, creando lo sprint
backlog ossia la lista dei task dello sprint in corso con le rispettive stime delle durate.
Ogni giorno, il team discute l’avanzamento e gli ostacoli incontrati, nel Daily Scrum Meeting.
Alla fine di ogni sprint, il team produce un potenziale rilascio di prodotto.
Il Daily Scrum Meeting
E’ una riunione giornaliera, alla stessa ora, di massimo 15 minuti per condividere il lavoro da eseguire
durante il giorno con la discussione ridotta all’essenziale: “Daily Scrum”.
Ecco come sdrammatizza questo impegno giornaliero Mike Cohn:
“There is an old joke in which a chicken and a pig are talking and the chicken says, "Let's start a restaurant."
The pig replies, "Good idea, but what should we call it?" "How about 'Ham and Eggs'" says the chicken.
"No thanks," says the pig, "I'd be committed, you'd only be involved.” The joke is meant to point out
the difference between those who are committed on a project and those who are only involved.”
Solo chi è “committed” ha il diritto di parlare durante un Daily Scrum.
Al Daily Scrum partecipano tutti i membri del team, lo ScrumMaster ed il Product Owner. Altre figure
interessate possono partecipare solo se si limitano ad ascoltare. Aprire il Daily Scrum agli uditori è un modo
molto efficace per informare gli altri stakeholder sullo stato del progetto. Deve essere chiaro che non si
tratta di una riunione per risolvere problemi ed eventuali issue sollevate devono essere trattate offline dagli
interessati dopo la riunione.
Durante la riunione ogni partecipante risponde alle seguenti tre domande:
1. Cosa hai fatto ieri?
2. Cosa farai oggi?
3. Vedi ostacoli al lavoro da fare oggi?
Concentrandosi su quello che ognuno ha fatto ieri e cosa farà oggi, il team raggiunge una notevole
comprensione del lavoro fatto e di quello rimanente.
Il Daily Scrum Meeting non è una riunione di revisione dove il manager raccoglie informazioni sulle attività in
ritardo, invece, si tratta di un incontro dove i membri del team prendono impegni fra loro.
Se uno si alza e dice ”oggi finisco la definizione del database”, tutti sapranno che domani quel signore dirà
se ha finito di definire il database o meno. In pratica, le persone prendono impegni di fronte a tutto il
gruppo di lavoro. Se sorge un problema che impedisce di realizzare un’attività, lo ScrumMaster ha la
Materiale utile per Prepararare la Certificazione Agile PMI-ACMsm
di
Vito Madaio
pag. 2
Agile Project Management - LC90.99B
responsabilità di risolverlo il prima possibile. Se lo ScrumMaster non è in grado di risolvere una issue tecnica,
deve individuare chi lo potrà fare velocemente al posto suo.
Le tre domande del Daily Scrum possono riguardare le singola persona oppure singole storie, se le
persone hanno in carico più storie e non sono in grado di parlare di quelle non ancora in lavorazione.
Questo è un dilemma di tutti i team Scrum: task o story? Bisogna essere precisi.
Il Product Backlog
Il Product Backlog è la lista delle cose da fare con una breve descrizione delle funzionalità desiderate.
Non è necessario documentare in anticipo tutti i requisiti, ma il team ed il product owner iniziano a
scrivere ciò che risulta più facile ed evidente al momento. Meglio che niente come primo sprint!
Il backlog inizia a crescere man mano che l’utente racconta altri dettagli (della sua story),
aggiungendo: dispositivi, difetti da colmare, lavoro tecnico, conoscenze da acquisire, etc.
Le User Stories sono l’insieme di brevi descrizioni delle funzionalità desiderate raccontate dal punto di
vista e prospettiva dell’utente.
Una volta costituito il product backlog di progetto, il product owner stabilisce le priorità da applicare
durante lo sprint planning meeting. Il team valuta e determina quali componenti potrà realizzare nel
successivo sprint e sposta i componenti prescelti dal product backlog allo sprint backlog, come
illustrato nella figura precedente.
Così come un work package della WBS (work breakdown structure) viene scomposto in una o più
attività nel project management tradizionale, anche con Scrum una User Story inserita nel product
backlog diventa uno o più task dello sprint backlog.
Praticamene, il team parte dall’elemento del product backlog con priorità più alta e si ferma all’ultimo
che ritiene di poter inserire in quello sprint. Può accadere che selezioni anche degli elementi con
priorità più bassa, saltandone altri, se questi ultimi sono collegati a quelli con priorità più alta.
Il Product Owner
Il product owner
è uno stakeholder chiave del progetto che deve saper
trasmettere al team la visione di ciò che bisogna sviluppare: agisce sul product
backlog e la lista delle funzionalità da realizzare. Questa figura deve avere chiaro
le esigenze dell’utente, la situazione del mercato, cosa fa la concorrenza, il trend
futuro del tipo di applicazione che sta sviluppando.
Sebbene il product owner stabilisca le priorità degli elementi del product backlog,
il team decide, autonomamente, cosa realizzare in uno sprint.
Il product owner non ha il potere di dire cosa deve fare il team, ma può influenzarlo, ovviamente.
Il suo compito è motivare il team con propositi chiari.
I membri del team sanno cosa sono in grado di fare e scelgono su quali user stories impegnarsi,
partendo da quelle con priorità più alta. In cambio il product owner si impegna a non proporre nuovi
requisiti su quelle stories durante lo sprint.
Nuovi requisiti sono ammessi, anzi sono incoraggiate le richieste di modifiche, ma solo
fuori dallo sprint in corso.
Una volta che il team inizia uno sprint resta maniacalmente concentrato sul suo goal.
Release Burndown charts
In un progetto Scrum, il team traccia l’avanzamento di un piano di rilascio aggiornando il relaese
burndown chart alla fine di ogni sprint. L’asse orizzontale del grafico indica gli sprint, l’asse verticale il
lavoro rimanente all’inizio di ogni sprint. Il lavoro rimanente può essere espresso in qualsiasi unità di
misura: story points, ideal days, team days e così via.
Mike Cohn dichiara di preferire gli story points nel libro Agile Estimating and Planning.
Materiale utile per Prepararare la Certificazione Agile PMI-ACMsm
di
Vito Madaio
pag. 3
Agile Project Management - LC90.99B
In questo burndown chart, il team ha avviato un progetto di 11
sprint da 2 settimane l’uno con 200 story points.
Il primo sprint è andato bene, lasciando 180 story points in coda.
Nel secondo sprint il lavoro rimanente aumenta di nuovo. Forse è
stato aggiunto altro lavoro o il team ha cambiato qualche stima.
Dal terzo sprint in poi il progetto è andato bene. Il lavoro rimanente
decresce regolarmente.
Durane lo sprint 7 c’è stato un rallentamento subito recuperato.
Questo tipo di burndown chart funziona molto bene in molte
situazioni e con molti team, però, ci possono essere delle
complicazioni se il progetto riceve troppe richieste di modifiche.
Il tipico burndown chart mostra la stima del lavoro rimanente sempre
decrescente, ma nella realtà non è sempre così. Immaginiamo che il
team pensava di ridurre il lavoro di 40 ore nel primo sprint ed invece
lo ha ridotto solo di 10.
Il team è stato più lento del previsto oppure è stato aggiunto altro lavoro?
Bisogna chiarire queste situazioni per non perdere il controllo del progetto. Ecco un esempio:
Il fenomeno delle richieste di modifiche può essere evidenziato, utilizzando anche il quadrante sotto
l’asse X. Nell’esempio sopra vediamo un burndown chart con 175 story points iniziali, di cui 25
realizzati in sprint 1, scendendo a 150 story points a inizio sprint 2 e poi a 120 a inizio sprint 3.
Come si vede dal grafico, la parte superiore delle barre si riduce del numero di story points realizzati
ad ogni sprint. Però se viene aggiunto del lavoro, come a inizio sprint 4, il nuovo lavoro deve essere
rappresentato sotto l’asse X per evidenziare che sono intervenute delle richieste di modifiche e
migliorare la lettura dell’intero grafico.
A inizio sprint 4, in realtà rimangono 135 story points, dove, però, 40 story points sono stati appena
aggiunti e sono quelli sotto l’asse X, mentre sopra rimangono i 95 story points come stimato
inizialmente.
Prima dell’avvio di sprint 6 il product owner ha eliminato del lavoro. Anche le riduzioni di lavoro
vengono rappresentate sotto l’asse X come si vede da sprint 6.
Questo approccio consente di veder decrescere il lavoro iniziale di sprint in sprint e di evidenziare le
variazioni del carico di lavoro in corso d’opera, creando qualche difficoltà nel predire la data di
ultimazione del progetto.
Lo ScrumMaster
Lo ScrumMaster è responsabile del corretto utilizzo del processo Scrum da
parte del team. E’ un allenatore (coach) che aiuta il team a dare il meglio.
Spesso viene chiamato anche process owner in contrapposizione a product
owner.
Lo ScrumMaster aiuta il team a fornire la massima prestazione, rimuovendo
eventuali ostacoli, moderando le riunioni e lavorando sul product owner affinché
il product backlog sia sempre aggiornato e pronto per lo sprint successivo.
Materiale utile per Prepararare la Certificazione Agile PMI-ACMsm
di
Vito Madaio
pag. 4
Agile Project Management - LC90.99B
Questo ruolo viene ricoperto di solito da un project manager o un team leader, ma può essere
ricoperto da chiunque sia in grado di proteggere il team di lavoro. Per protezione si intende non fargli
subire le pressioni del product owner che li potrebbe sovraccaricare di lavoro. Il team va protetto dal
product owner, ma anche dalla propria compiacenza.
Il team potrebbe accontentarsi, ritenendosi soddisfatto, dei primi successi facili, per cui potrebbe
smettere di cercare altre opportunità di miglioramento. Lo ScrumMaster deve prevenire questo rischio,
da un lato, frenando la pressione del product owner quando il team è sovraccarico e dall’altro
chiedendogli più lavoro quando il team è meno impegnato.
Il ruolo di ScrumMaster può apparire contraddittorio perché pur curando gli interessi del team, non ha
nessuna autorità su di esso, invece ha molta autorità sui processi. In pratica non ha voce in
capitolo sulle persone, ma può determinare come deve essere organizzato uno sprint.
Lo ScrumMaster è simile ad un personal trainer che aiuta il team a seguire correttamente le regole
Scrum, lo motiva ed evita che si lamenti saltando i passi più pesanti, sebbene abbia poca autorità.
Lo ScrumMaster non ha autorità impositiva, ma ha il compito di ricordare al team gli obiettivi da
raggiungere e come il team stesso ha promesso di raggiungerli.
La poca autorità dello ScrumMaster è garantita dal comportamento del team di progetto.
Uno ScrumMaster non può assegnare del lavoro ai membri del team, ma può decidere di modificare
dei processi. Perciò con questa autorità limitata, lo ScrumMaster ha più difficoltà di un normale project
manager. Il project manager tradizionale può dire “fai questo, perché l’ho deciso io”, invece lo
ScrumMaster si limita a verificare che vengano seguiti i processi Scrum.
Secondo Mike Cohn un buon ScrumMaster deve avere questi sei attributi:
1.
2.
3.
4.
5.
Responsabile
Umile
Collaborativo
Impegnato
Influente
6. Competente
Il Team Scrum
I gruppi di lavoro Scrum non comprendono i tradizionali ruoli di ingegneri del
software come: programmatori, designer, tester o architetti. Ognuno lavora per
completare, entro la fine dello sprint, il lavoro che ha preso in carico.
In questo modo il team sviluppa un forte cameratismo ed il senso di “essere sulla
stessa barca”. Di solito, il team Scrum è composto da 5 a 9 persone e invece di
tendere a creare team numerosi, Scrum tende a creare team di team. Con la tecnica
“Scrum of Scrum” ogni team partecipa con una sua persona alla riunione che
coordina il lavoro di più team; riunioni analoghe al Daily Scrum Meeting, ma non
necessariamente con la stessa frequenza giornaliera.
Ecco come funziona la tecnica dello Scrum of Scrum, arrivando fino a 243 persone nel seguente
esempio.
Ogni cella della figura rappresenta 1 di 9 persone del team Scrum. Una persona di ogni team partecipa
allo Scrum of Scrum per coordinare il lavoro sopra il suo team. Poi da questo team di 9 persone
viene scelta un’altra persona per partecipare allo Scrum of Scrum of Scrum.
Sprint Backlog
Lo sprint backlog è la lista dei task identificati dal team Scrum durante un sprint planning.
Materiale utile per Prepararare la Certificazione Agile PMI-ACMsm
di
Vito Madaio
pag. 5
Agile Project Management - LC90.99B
Nel corso dello sprint planning il gruppo di lavoro discute alcuni elementi del product backlog detti
user stories per stabilire i task necessari al prossimo sprint e per stimarne le durate per realizzarli.
I membri del team decidono gli elementi e le dimensioni del backlog, essendo gli unici ad impegnarsi
a realizzare quelle attività.
Lo sprint backlog, di solito, è una tabella tipo foglio excel, ma si può utilizzare anche software più
sofisticato specifico dell’ambiente Scrum o del mondo Agile in genere. Eccone un esempio:
Durante lo sprint, i membri del team aggiornano lo sprint backlog man mano che assumono nuove
informazioni o almeno una volta al giorno. Alcuni lo fanno nel Daily Scrum in collaborazione con lo
ScrumMaster il quale ricalcola il lavoro rimanente e produce il burndown chart, come il seguente:
Il team fa del suo meglio per inserire la giusta quantità di lavoro in ogni sprint.
Nell’esempio di burndown chart appare che il team inizialmente ha inserito troppo lavoro, circa 600 ore
fino al 16/5/02. A quel punto, con il consenso del product owner, è stato rimosso del lavoro dallo
sprint, portando alla diminuzione del lavoro rimanente tra il 16 ed il 17/5. Da allora in poi il team ha
proceduto senza alcun impedimento fino alla fine.
Sprint Planning Meeting
Alla riunione di pianificazione dello sprint partecipano:
 il Product Owner,
 lo ScrumMaster e
Materiale utile per Prepararare la Certificazione Agile PMI-ACMsm
di
Vito Madaio
pag. 6
Agile Project Management - LC90.99B
 l’intero team di progetto.
Il product owner descrive i dispositivi con priorità più alta al team. Il team pone domande per
comprendere meglio le user stories del product backlog e disporre di sprint backlog più dettagliati.
Il product owner non descrive tutti gli argomenti nel product backlog; un buon metodo è prepararsi a
parlare di almeno due sprint.
In uno sprint planning meeting devono emergere due fatti:
 il proposito (goal) dello sprint
 il backlog dello sprint.
Lo sprint goal, scritto in collaborazione tra team e product owner, deve essere breve di una o due
frasi su ciò che il team pianifica di realizzare durante lo sprint.
Lo sprint goal viene utilizzato per informare gli stakeholder, fuori dallo sprint, che desiderano sapere
cosa sta realizzando quel team, ma non hanno bisogno di sentire tutti i dettagli.
Il successo dello sprint viene verificato durante lo Sprint Review Meeting, rispetto allo sprint goal e non
agli argomenti del product backlog.
Lo sprint backlog è l’altro output della pianificazione dello sprint.
Sprint Retrospective
Un team può sempre migliorare. Anche se il team è efficiente perché sfrutta tutte le opportunità per
migliorare, il team, alla fine di ogni sprint, impiega del tempo per riflettere su come sta andando il
progetto e come potrebbe migliorare.
Questo momento si chiama “Sprint retrospective” ed è l’ultimo evento di uno sprint.
Viene indetta una riunione della durata di un’ora circa, di solito, subito dopo lo sprint review.
Vi partecipano i soliti: ScrumMaster, Product Owner e intero team di progetto.
Il modo più semplice di condurre questa riunione è la così detta “start-stop continue meeting”
dove ogni partecipante è chiamato a indicare cosa avvierebbe, cosa fermerebbe e cosa continuerebbe.
Lo ScrumMaster modera la riunione chiedendo ad ognuno di esprimere la propria idea.
Una volta raccolte abbastanza idee vengono messe ai voti per decidere su quali idee concentrarsi
durante il prossimo sprint. Si tratta di una tecnica di bainstorming.
A fine sprint, la successiva riunione retrospettiva rivede gli argomenti della precedente retrospettiva.
Sprint Review Meeting
Alla fine di ogni sprint, il team presenta ciò che ha realizzato in una sprint review meeting. Si tratta di
una demo molto informale delle funzionalità realizzate durante lo sprint, appena concluso. Non sono
ammesse slide PowerPoint, né sono ammesse più di due ore per preparare la riunione, perché non deve
diventare un task né una distrazione dal processo, ma deve essere solo il risultato naturale dello sprint.
I partecipanti sono i soliti: Product Owner, ScrumMaster e intero Team dello Scrum; più manager,
clienti e sviluppatori di altri progetti come uditori.
Durante la riunione viene rivisto il progetto rispetto ai propositi fissati nello Sprint Planning Meeting.
Idealmente il team deve aver completato ogni argomento del product backlog trasferito nello sprint, ma è
più importante il proposito complessivo dello sprint.
Task Board
Si tratta di un tabellone sul quale esporre lo stato di ogni task delle stories del backlog e le eventuali
aggiunte, spostamenti, modifiche, etc. I membri del team in qualsiasi momento sono liberi di
modificare il tabellone per rappresentare la situazione di un componente da quell’istante in poi.
Materiale utile per Prepararare la Certificazione Agile PMI-ACMsm
di
Vito Madaio
pag. 7
Agile Project Management - LC90.99B
Questo è un tipico esempio di task board.
Ogni riga rappresenta una user story che è l’unità di lavoro suggerita per il product backlog.
Durante lo sprint planning meeting il team decide cosa realizzare durante lo sprint successivo.
Ogni product backlog si compone di più sprint backlog item che in pratica sono i task- attività,
rappresentati da una scheda collocata sul tabellone. Ogni scheda (task) nasce nella colonna To do e
viene spostata nelle altre colonne man mano che viene lavorata.
Le colonne tipiche del task board sono:
 Story - la descrizione di alto livello di cosa si deve fare
 To do - le schede di dettaglio delle attività da realizzare
 Work in Process - le schede in lavorazione
 To verify - schede che rappresentano momenti di test dipendenti da altri task
 Done - mucchio di schede lavorate da rimuovere a fine sprint.
Questo lavoro è stato possibile grazie al materiale pubblicato da Mike Cohn sul suo sito, oltre alla
presentazione: http://www.mountaingoatsoftware.com/scrum-a-presentation che ho ripreso e messo
a vostra disposizione su http://www.tenstep.it/Agile/Introduzione-SCRUM.pdf .
Se questo lavoro ti è piaciuto, raccontalo ad un amico che
sta pensando alla certificazione Agile e non sa a chi
rivolersi.
PASSAPAROLA
Materiale utile per Prepararare la Certificazione Agile PMI-ACMsm
di
Vito Madaio
pag. 8