Scrum: Cos’è e Come Funziona (Metodologia Agile)
A volte parlare di Scrum è come parlare dell’ultimo film che ha vinto agli Oscar.
Tutti ti dicono che l’hanno visto, ma in pochi sanno raccontarti la trama nel dettaglio.
Ecco, per Scrum è la stessa cosa: tanti dicono di sapere cos’è, pochi sanno la differenza tra un Project Manager e uno Scrum Master.
Se per il film non abbiamo intenzione di fare spoiler, per Scrum non ci tratteniamo: ecco la guida completa di questa metodologia Agile!
Che cos’è Scrum e come funziona?
Scrum è “un framework per sviluppare e sostenere prodotti complessi”, come viene definito dalla guida ufficiale.
Fa parte delle metodologie Agile, di cui è la versione di gran lunga più diffusa.
Infatti l’ultimo report annuale sull’utilizzo di metodologie Agile la colloca al primo posto: il 58% usa Scrum, mentre un altro 10% combina Scrum e XP.
Scrum è un approccio basato sulla teoria del controllo empirico dei processi: le decisioni vengono prese sulla base dell’esperienza (empirismo).
Tutti gli aspetti del lavoro devono essere visibili ai responsabili del risultato finale (trasparenza). Per rendere trasparenti questi elementi, il Team Scrum ispeziona di frequente il prodotto mentre lo sta sviluppando (ispezione). Così il processo e il prodotto possono essere adattati immediatamente nel caso di nuove esigenze o di condizioni mutate del mercato (adattamento).
I suoi creatori, Ken Schwaber e Jeff Sutherland, hanno preso in prestito il termine dal rugby, dove indica il pacchetto di mischia, la situazione di gioco in cui i giocatori della squadra compongono un insieme compatto che spinge nella stessa direzione.
Perché è questo il senso di Scrum: far lavorare tutto il team insieme, in modo coordinato e organizzato.
Ma in concreto come funziona Scrum?
Come tutte le metodologie Agile, si basa sulla divisione del progetto in più fasi, chiamate Sprint.
Ad ogni Sprint il gruppo di lavoro presenta nuove funzionalità, operative e implementabili, che vengono fatte valutare al cliente. Si configura così un sistema iterativo che consente di incrementare poco alla volta, ma molto di frequente, le funzionalità del progetto.
E allo stesso tempo si può verificare costantemente l’andamento complessivo e la soddisfazione del cliente su quanto già prodotto.
La metodologia Scrum viene definita da Ruoli, Artefatti ed Eventi.
Vediamoli!
Ruoli
Sono 3 i ruoli che vengono individuati nella metodologia Scrum: Product Owner, Scrum Master e Team di Sviluppo.
Il Product Owner definisce il lavoro da svolgere e l’ordine con cui viene completato. Raccoglie la voce degli stakeholder (clienti, management e chiunque abbia un interesse nel prodotto), le necessità dell’utente finale, i requisiti del mercato e sulla base di questi elementi stabilisce le priorità di sviluppo per il Team Scrum.
Lo Scrum Master è il responsabile del processo, e un leader a servizio (servant-leader) dello Scrum Team. Conoscitore esperto della metodologia Scrum, sa come applicarla e si assicura che il Team comprenda e segua le regole che la caratterizzano, perché il progetto abbia successo.
Inoltre favorisce il lavoro del Team di Sviluppo, rimuovendo ostacoli, organizzando meeting di confronto, e soprattutto proteggendolo da ogni possibile distrazione: ogni membro del gruppo deve poter lavorare al 100% sullo sviluppo, e lo Scrum Master si assicura che questo avvenga.
Il Team di Sviluppo è la squadra di lavoro, composta da 3 a 9 persone. Anche lo Scrum Master può far parte del Team di Sviluppo. Chi concretamente porta a termine gli Sprint e fornisce le funzionalità da implementare è questo insieme coordinato di persone, autogestito e cross-funzionale.
Autogestito perché decide in autonomia come sviluppare le funzionalità individuate dal Product Owner. Cross-funzionale perché contiene al proprio interno tutte le competenze e le funzioni necessarie per portare a termine i task. Per lo sviluppo di software, significa avere architetti, designer, sviluppatori e tester, anche se tutti prendono il nome di Sviluppatori, a prescindere dalle funzioni svolte. Inoltre ogni membro del Team è responsabile dell’intero sviluppo: condividere la responsabilità aumenta il senso di appartenenza e incentiva la collaborazione tra i componenti del Team di Sviluppo.
Product Owner, Scrum Master e Team di Sviluppo costituiscono insieme lo Scrum Team.
ARTEFATTI
Gli artefatti sono tre: Product Backlog, Sprint Backlog e Incremento. Sono pensati per aumentare la trasparenza delle informazioni principali, così che tutto il Team ne sia al corrente.
Analizziamoli nel dettaglio!
Product Backlog
Il Product Backlog è la lista ordinata di tutti gli elementi che servono nel prodotto. Elenca caratteristiche, funzioni, requisiti, miglioramenti e correzioni che costituiscono le modifiche da apportare alle versioni future del prodotto. Viene creato dal Product Owner, che è il responsabile dell’individuazione degli elementi (Product Backlog Items) e del loro ordine: stabilisce infatti la priorità con cui il Team di Sviluppo dovrà lavorarci.
Il Product Backlog non è fisso, ma evolve: diventa più complesso man mano che il prodotto viene costruito, e asseconda anche i feedback degli utenti che hanno testato le funzionalità già rilasciate.
Le singole voci del Product Backlog vengono descritte come User Story: brevi e semplici descrizioni di una funzionalità raccontata dal punto di vista dell’utente o del cliente del sistema.
La struttura di una User Story è questa:
Come <tipo di utente>, voglio <obiettivo> in modo da <ragione>
Esistono diversi template, ma questo è uno dei più comuni. Vediamo un esempio pratico di User Story:
“Come venditore, mi piacerebbe impostare la mia password, così posso accedere al sistema”.
In questo caso la funzionalità descritta è particolarmente complessa e generica: questo tipo di User Story viene chiamata Epic. Le Epic vengono poi divise in User Story più specifiche, per permettere una corretta valutazione delle funzionalità da creare.
Il nostro esempio potrebbe venire diviso così:
“Come venditore, mi piacerebbe modificare il mio profilo, così posso impostare la mia password”.
“Come amministratore, vorrei inviare un’email a un nuovo venditore con un link di accesso tokenizzato, in modo che possa accedere temporaneamente al sistema per impostare la propria password”.
Sprint Backlog
Lo Sprint Backlog è l’insieme degli elementi del Product Backlog che sono stati selezionati per essere completati in una iterazione. È anche una previsione del Team di Sviluppo su quanto verrà prodotto alla fine dello Sprint.
Rende evidente a tutti gli Sviluppatori il lavoro che deve essere fatto per raggiungere l’obiettivo dell’iterazione (lo Sprint Goal). Lo Sprint Backlog è in continua evoluzione: tiene traccia del lavoro svolto giornalmente, delle attività completate e di quanto rimane da fare. Solo il Team di Sviluppo può intervenire sullo Sprint Backlog, anche aggiungendo o eliminando task.
Incremento
L’Incremento è la somma di tutte le funzionalità completate in uno Sprint, insieme a quelle già completate negli Sprint precedenti. L’Incremento prodotto deve soddisfare la “Definizione di Fatto” (in inglese DoD, Definition of Done): ogni Team Scrum crea una propria definizione, ovvero un documento condiviso su quali siano i criteri per stabilire che cosa significa “Fatto”.
EVENTI
Gli eventi che caratterizzano la strategia Scrum sono 4, pensati per strutturare il processo, aumentare la trasparenza del lavoro, fornire un momento formale per adattare il progetto, e ridurre la necessità di incontri non programmati.
Ma prima di vederli nel dettaglio, analizziamo il contenitore di questi quattro eventi, lo Sprint.
Sprint
Lo Sprint è il cuore del framework Scrum. Della durata compresa tra 2 e 4 settimane, ogni Sprint è nella pratica un mini progetto, il cui scopo è presentare un Incremento che risponde ai requisiti di “Fatto”, utilizzabile e potenzialmente rilasciabile.
Durante lo Sprint, gli obiettivi individuati nella fase di pianificazione restano fissi, così come la durata: scaduto il termine, lo sprint si conclude anche se non tutti i risultati sono stati raggiunti.
Se l’obiettivo di uno Sprint diventa obsoleto e palesemente inutile, un intero Sprint può essere cancellato: ma vista la breve durata dello Sprint, è un’eventualità molto rara.
Lo Sprint è composto da 4 eventi: Sprint Planning, Daily Scrum, Sprint Review e Sprint Retrospective. Sono tutti eventi time-boxed, quindi dalla durata prestabilita.
Eccoli!
Sprint Planning
Lo Sprint Planning è l’inizio di ogni Sprint: una riunione in cui il Team Scrum concorda l’obiettivo dello Sprint (lo Sprint Goal) e il Team di Sviluppo seleziona i Product Backlog Items da realizzare e pianifica come portarli a termine (viene impostato lo Sprint Backlog). Dura al massimo 8 ore per gli Sprint di 4 settimane.
Daily Scrum
È un evento giornaliero di 15 minuti in cui il Team di Sviluppo programma la giornata di lavoro. I punti affrontati in questa riunione sono tre: cosa è stato fatto il giorno prima, cosa si farà nelle successive 24 ore, e gli eventuali ostacoli incontrati.
Il Daily Scrum incentiva la collaborazione e la sincronizzazione del lavoro tra gli Sviluppatori, rende chiara a tutti la progressione verso lo Sprint Goal e permette allo Scrum Master di intervenire tempestivamente sui problemi che rallentano il Team di Sviluppo.
Sprint Review
Alla fine di ogni Sprint è prevista una riunione, la Sprint Review, in cui lo Scrum Team discute insieme agli stakeholder l’Incremento realizzato. La riunione serve per dimostrare quanto è stato svolto, e per iniziare a raccogliere gli input per le successive riunioni di Sprint Planning. Ha una durata proporzionata alla lunghezza dello Sprint, e non supera mai le 4 ore di riunione per uno Sprint di 4 settimane.
Sprint Retrospective
Dopo la Sprint Review si apre la Sprint Retrospective, un momento formale in cui il Team Scrum analizza lo Sprint concluso, identifica le cose che sono andate bene, individua i miglioramenti che possono essere fatti e pianifica il modo in cui implementarli nello Sprint successivo. Dura al massimo tre ore.
E dopo la Sprint Retrospective, si ricomincia da capo, con un nuovo Sprint Planning, finché il progetto non è concluso.
Eccoci arrivati alla fine: come dicono i suoi creatori…
Scrum è semplice da comprendere, e molto difficile da padroneggiare
Grazie a questa guida, adesso ti sarà un po’ meno difficile da padroneggiare…
…e la prossima volta che si parlerà di Scrum, potrai rispondere a qualsiasi domanda like a Scrum pro ;)
