Metodologia Agile Scrum adottata dal Team WAPP

Obiettivo del documento

Di seguito viene descritto lo standard SCRUM applicato dal nostro gruppo di sviluppo. È importante ricordare che la metodologia è molto flessibile pertanto ciò che viene indicato in questo documento è solo un’indicazione; ognuno è libero di adattare e modificare questo modello al proprio contesto.

Product Backlog

Il product backlog è un elenco di elementi (Product backlog Items) necessarie al completamento del prodotto; possiamo trovare storie, bugs, requisiti tecnici, idee ed elementi di studio (Spike). È importante che il product owner riesca a capire ogni item e il motivo per cui sia lì senza necessariamente sapere cosa c’è da implementare (tecnicamente).

Altra cosa importante è che il product backlog è sempre soggetto a cambiamenti; l’acquisizione di nuove conoscenze sul prodotto da sviluppare infatti può portare a una rivalutazione delle priorità degli elementi posizionati nella parte alta del backlog, elementi che possono essere scambiati con altri più in basso, rimossi oppure aggiunti al Product Backlog.

User Story

Le user story descrivono una singola funzionalità del sistema dalla prospettiva di un utente finale. Dovrebbero essere piccole al fine di consentire al team di effettuare una stima a grandi linee dell’effort richiesto per la realizzazione.

Ogni storia comprende:

• ID: codice identificativo univoco della storia
• Nome: è un nome sintetico che identifica la storia, deve essere sufficientemente chiaro perché gli sviluppatori ed il product owner capiscano a grandi linee di che cosa si sta parlando.
• Importanza: un valore che misura quanto è importante la storia per il product owner.
• Stima: valutazione da parte del team di quanto lavoro è necessario per implementare la storia
• Ogni storia dovrebbe rispettare l’acronimo INVEST:
• Indipendent: Non deve avere interdipendenze con altre user story.
• Negotiable: Devono essere “negoziabili” ed aperte ai contributi di tutti
• Valuable: Deve essere in grado di portare valore aggiunto all’utente finale.
• Estimable: Deve essere possibile da stimare
• Small: Non deve essere talmente grande da non poter essere pianificata o realizzata
• Testable: Deve essere testabile e avere informazioni su come eseguire i test (Criteri di accettazione).

Suggerimento:

La cosa importante non è avere stime assolutamente corrette (cioè una storia da due punti richiede due giorni), la cosa importante è avere delle stime relativamente corrette (cioè una storia da due punti dovrebbe richiedere circa metà lavoro rispetto ad una storia da quattro punti).

Come scrivere le user story

Ogni storia descrive cosa fare, per chi e perché in modo che sia comprensibile allo stesso modo per il cliente e per gli sviluppatori. Il punto di vista è quello di chi richiede la nuova funzionalità, la quantità di informazioni è quella indispensabile per consentire al team di sviluppo di fare una stima di massima del lavoro richiesto per la realizzazione.

Scrum non fornisce alcuna indicazione o obbligo sul formato da utilizzare per la compilazione di tali elementi ma il formato che più risulta utile allo scopo è il seguente:

*As a type of user, I want some goal so that some reason

In qualità di tipologia di utente, voglio una specifica funzionalità, così che/per valore/vantaggio*

Backlog Refinement

L’obiettivo di questa riunione è quello di perfezionare il backlog leggendo le storie con lo scopo di preparare il terreno per la pianificazione del prossimo sprint. Il backlog refinement ha una durata massima di 2 ore e viene svolto durante lo sprint. Il product owner definisce l’obiettivo del prossimo sprint ed individua quelle che sono le storie affinché venga raggiunto, per ogni storia viene definito un grado di importanza.

Ovviamente lo scopo non è di passare in rassegna tutto il Product Backlog, ma solo quegli elementi che si prevede verranno inclusi nell’iterazione successiva o al massimo entro due Sprint. È responsabilità del Product Owner definire o rendere chiare le priorità e gli obiettivi.

Si procede riordinando le storie nel backlog rispetto alle scelte del product owner (obiettivo ed importanza). Durante la riunione, con l’aiuto del product owner, si leggono le storie selezionate, si chiariscono eventuali dubbi ed eventualmente, si ottimizzano (ad esempio storie grandi si suddividono in storie più piccole).

l Product Owner fornisce dettagli e risposte a domande sul “perché” Gli sviluppatori forniscono dettagli e rispondono a domande sul “come”

Sprint Planning

“Lo scopo dello sprint planning meeting è dare al team sufficienti informazioni per poter lavorare in indisturbata pace per poche settimane e dare al product owner abbastanza fiducia da lasciarglielo fare.”

Lo sprint planning è time boxed: dovrebbe durare al massimo 3 ore, con 10 minuti di pausa ogni ora. Se non si è raggiunto l’obiettivo si procede con quanto è

stato analizzato (il team impara a gestire meglio il tempo).

Il motivo per cui è necessario che l’intero team e il product owner siano presenti allo sprint planning meeting è che il product owner ha la responsabilità di condividere scope ed importanza mentre il team ha la responsabilità di fornire le stime; queste tre proprietà (scope, importanza, stime) vengono sottoposte ad un continuo raffinamento grazie ad un dialogo faccia a faccia con il product owner.

Nella prima parte della riunione il product owner condivide l’obiettivo dello sprint e indica le storie che, secondo lui, portano al raggiungimento dell’obiettivo; il team esamina ogni storia e ne stima i tempi, iniziando dalla più importante. Durante questo processo, se necessario, si procede alla suddivisione in task più dettagliati (le stime dei tempi sono di solito più facili da fare quando le storie sono suddivise in task); è possibile che durante la creazione dei task possano sorgere importanti domande sullo scope: In alcuni casi le risposte sorprenderanno il team inducendolo a cambiare le stime; in altri casi la stima non è quella desiderata dal product owner e potrebbe fargli cambiare l’importanza da dare alla storia, oppure cambiare il suo scope (cosa che determinerà una nuova stima). Quindi, per ogni task, si procede con il Planning Poker.

Quando tutte le storie risultano essere chiare, stimate e per ognuna di esse, se necessario, è stato definito un task: il team decide quali storie portare nel prossimo sprint (Il team

decide quante storie includere nello sprint, non il product owner, né nessun altro). A questo punto si può procedere in due modi:

• nel primo modo: si chiede al team di ignorare i numeri e limitarsi a pensare, a sensazione, se crede di riuscire a completare le storie selezionate per lo sprint; se sembra troppo, si prova a rimuovere qualche storia; se sembra poco invece, se ne provano ad aggiungere. Il product owner può influenzare questo processo manipolando le storie (può snellirle o cambiarne l’importanza).
• Nel secondo modo, si procede con la verifica della velocità del team e quindi si calcolano quante storie si possono aggiungere senza superare la velocità stimata.

Suggerimento per lo scrum master: è possibile combinare entrambi i modi!

Se lo sprint termina in anticipo

Si valutano e si portano in sprint le storie in cima al backlog (ordinato precedentemente)

Se lo sprint termina con storie non completate

Il team impara l’errore per non ripeterlo e le storie vengono spostate in cima al backlog. Riportarle nel prossimo sprint dipenderà dal Product Owner poiché, nel frattempo, potrebbero essere cambiate le priorità.

Velocità del team

La velocità del team è rappresentata dagli story point che il team riesce a consumare in una iterazione. Ci sono diversi metodi per calcolare la velocità del team, noi troviamo più efficace calcolare la velocità sulla base dei giorni-uomo, associamo ad un giorno-uomo l’unità di 2 story point. Quindi, supponendo un team di 4 persone, è possibile consumare 8 story point al giorno. Questo valore non è però efficace poiché presuppone un giorno ideale, senza interruzioni (cosa rara). Inoltre, sarebbe utile tenere conto di fattori come il lavoro non pianificato aggiunto allo sprint, persone che si ammalano, etc.

In effetti, ci vorranno dai tre ai cinque sprint per stabilizzare la velocità del team di sviluppo. Il primo sprint è generalmente complesso. Si tratta di iniziare con un team i cui membri non si conoscono necessariamente. La velocità è raramente alta ma aumenterà gradualmente durante i primi tre o quattro sprint fino a quando non si stabilizza. La velocità agile è quindi ottimale ed è relativamente rappresentativa, anche se rimane una stima dello sforzo che il team è in grado di produrre durante uno sprint. Una volta stabilizzata la velocità Agile, è quindi possibile prevedere in modo abbastanza fedele il numero di story point che il team riesce a consumare. Per avere una stima attendibile e fare quindi, previsioni sui rilasci in maniera più efficace, conviene prendere in considerazione almeno 4 o 5 Sprint.

Sprint Review

La sprint demo è una riunione, di massimo un’ora, molto importante con l’obiettivo di aumentare la fiducia tra il team ed il product owner affinché il disturbo e le pressioni diminuiscano. Infatti, permette al team di dimostrare al product owner quanto sia stato attento alle sue richieste guadagnando credito. Inoltre, si ottengono i feedback da parte dei vari stakeholders in modo da aggiustare il tiro al procedere delle iterazioni.

Ulteriore vantaggio: il team è spinto a completare e rilasciare l’incremento (anche solo in un ambiente di test). Senza le demo, si continuerà ad avere una lunga lista di

cose “Finite al 99%”.

Durante la demo viene ricordato l’obiettivo dello sprint e se necessario viene descritto il prodotto alle persone che non lo conoscono. Bisognerebbe rendere la demo breve, non bella e deve essere orientata al business evitando dettagli tecnici.Se possibile, bisognerebbe consentire ai presenti (Product owner) di provare da soli le funzionalità del prodotto.

Retrospettiva

La retrospettiva è la seconda riunione più importante dell’iterazione perché è la migliore occasione per migliorare ed ha una durata massima di tre ore. Ogni persona del team potrebbe avere un’idea per migliorare ma non è possibile sapere se il team è disposto ad applicare tale idea e questa riunione dà la possibilità di confrontarsi, discutere affinché tutti possano contribuire al miglioramento.

Ogni persona del team può dire cosa pensa sia andato bene, cosa pensa sarebbe potuto andare meglio, e cosa farebbe in modo diverso al prossimo sprint.

Viene analizzata la differenza tra la velocità stimata e la velocità effettiva e se c’è una grossa differenza si cerca di analizzare le cause. Quando il tempo è quasi finito lo scrum master tenta di riassumere i suggerimenti concreti su cosa si potrebbe fare meglio al prossimo sprint.

Poker Planning

• Il team di sviluppatori, insieme al Product Owner, si incontrano in una stanza (anche virtuale)
• Il Product Owner presenta al team una user story e lascia uno spazio per le domande. L’obiettivo è che tutte le persone presenti capiscano e partano dalla stessa base per poter arrivare ad una stima di ciascuno degli item che compongono la user story.
• Inizia la fase in cui si “stima”: viene scelto il primo elemento da valutare e ogni partecipante, individualmente e privatamente, assegna una carta del proprio mazzo, a seconda dello sforzo che ritiene necessario.
• In seguito ad un conto alla rovescia, i partecipanti svelano le proprie carte simultaneamente: se tutte le carte coincidono, si assegna questo valore all’item e la procedura si conclude. Se le carte sono diverse, si discutono i valori che sono particolarmente lontani rispetto alla media. Così, la persona che ha assegnato il valore più basso e quella con il valore più alto devono giustificare la loro Una volta concluse le spiegazioni, è necessario svolgere una nuova stima. Questo procedimento si ripete in un circolo continuo, fino al raggiungimento di unanimità.

*Suggerimento:

• Le storie possono essere stimate anche mediante un confronto con storie già
• completate o stimate precedentemente (ha lo stesso peso? un pò in meno o un pò in più)
• Per facilitare la stima si può presupporre che 2 story point equivalgono ad una giornata lavorativa (8 ore).
• Nell’eventualità in cui non c’è il raggiungimento di un consenso si può procedere o con una media*

Iterazione Ideale

A seguito di vari progetti e di vari tentativi abbiamo configurato quella che riteniamo ad oggi essere l’iterazione ideale. Abbiamo notato che uno sprint di 2 settimane permette di avere un giusto compromesso tra qualità e velocità. La configurazione della settimana che ci è sembrata essere migliore è la seguente: Lo sprint inizia di lunedì e finisce di venerdì, l’ultimo mercoledì si procede con il Backlog Refinement al fine di organizzare il prossimo Sprint; quindi il mercoledì si considera chiuso lo sprint e si procede con le altre riunioni (demo, restrospective, Sprint Planning per l’iterazione successiva).

Presupponendo ci sia un backlog definito si inizia con il Backlog Refinement con una durata massima di 2 ore; durante questa riunione si riordinando le storie a seconda delle priorità del cliente e si procede illustrando le storie al team partendo dalla prima in cima al backlog, eventualmente si scompongono le storie in work-items più semplici.

Terminate le 2 ore avremo abbastanza storie raffinate per poter organizzare uno sprint; le restanti storie verranno raffinate nel prossimo refinement se e solo se le priorità lo permettono. A seguito del Backlog Refinement, anche nella stessa giornata, si procede con il Poker Planning stimando le storie raffinate precedentemente; è utile farlo nella stessa giornata perché il team dovrebbe avere ben chiaro cosa ha raffinato e non è stato distratto da altro. Stimate le storie precedentemente raffinate si procede con lo Sprint Planning dove il team decide cosa portare in sprint per raggiungere l’obiettivo indicato dal PO; il team indica le storie seguendo un sentiment, è importante far capire che non è così grave se alcune storie restano in sprint e non vengono completate perché il team, soprattutto nella fase iniziale, deve raggiungere un grado di consapevolezza tale da migliorare quel sentiment; Lo scrum master può sfruttare la velocity del team per capire se quanto è stato indicato risulta essere veritiero oppure no, nel caso può influenzare la scelta del team. Lo sprint planning dura al massimo 2 ore, convenzionalmente 2 ore per ogni 5 giorni di sprint. Si procede con lo sprint ed ogni giorno si fanno i vari Daily Meeting dove è importante far capire ad ogni componente del team l’importanza dell’aggiornare il team sullo stato delle attività svolte. Il Daily ha una durata massima di 15 minuti, eventuali discussioni che non rientrano nelle 3 domande vanno fatte in altre riunione con i diretti interessati.

Terminato lo sprint si procede con la Review, questa permette al cliente di testare l’applicativo e

di fornire un feedback sul lavoro svolto ed ha una durata massima di 1 ora. Infine si svolge la Retrospective, anche nella stessa giornata, dove il team identifica cosa sia andato bene e cosa

invece male, al fine di migliorare le prossime iterazioni; ha una durata massima di 3 ore. Si riprende con il Backlog Refinement.

Pro tips

Precondizioni: Esiste un backlog di user story.

• Portare Il cliente a definire più goal in modo da pianificare un release plan.
• Il PO definisce un obiettivo (goal dello sprint) per il prossimo sprint (cosa rilasciare nella prossima release)
• Il PO individua quali sono le storie da portare nello sprint affinché l’obiettivo venga raggiunto (il goal venga centrato) e si riordinano le storie.
• Si fa il refinement con il team: si spiegano le user story ed eventualmente si ottimizzano (ad esempio storie grandi si suddividono in storie più piccole) Si lascia un periodo di studio delle storie approvate nel backlog (1 giorno) Si ricavano i task per ogni storia studiata.
• Si fa il poker planning dei task creati.
• Si fa lo sprint planning con il team: si portano in sprint tutte le storie e i task da completare per raggiungere l’obiettivo della release predisposto dal PO. Dura max due ore per settimana di sviluppo.
• Lo sprint si avvia e si fanno i diversi daily scrum.
• Alla fine dello sprint si fa la review: una demo con il cliente per capire quali storie con stato completato si vogliono rilasciare.
• L’incremento viene rilasciato al cliente (si fanno le merge su main e si incrementano le versioni secondo le logiche classiche).
• Lo sprint è finito. A questo punto si fa una retrospective.