Scrum 101
Tempo di lettura: 15 minuti
La metodologia Scrum è forse la più nota tra quelle che abbiamo visto nell’articolo precedente. Come tutte, essa ha avuto origine nel mondo dello sviluppo di software, ma negli anni è risultata più che adeguata anche in contesti che richiedono la realizzazione di prodotti tangibili. Il comune denominatore di entrambi gli ambiti è il mix di un contesto di sviluppo turbolento e continue variazioni di requisiti.
Scrum (termine traducibile in italiano come “mischia”), ideato da Ken Schwaber e Jeff Sutherland (cofirmatari anche dell’Agile Manifesto), si basa su tre aspetti fondamentali:
Sprint: blocchi di lavoro incastrati in un tempo prefissato (si ricordi il concetto di timeboxing delle iterazioni delle quali si è parlato descrivendo i principi della filosofia Agile) che devono portare alla realizzazione di una parte di prodotto funzionante e che porti valore per il cliente;
Product Backlog: lista delle richieste del cliente dalla quale attingere per realizzare l’incremento che si vuole realizzare durante lo sprint successivo;
Scrum Meeting: momento di confronto derivante dal concetto di stand-up meeting che abbiamo espresso nella spiegazione del dodicesimo principio.
I valori e i principi di Scrum
Come detto e come è possibile intuire dal fatto che i due ideatori di questo framework abbiano anche collaborato alla definizione dei princìpi e delle pratiche Agile, la metodologia Scrum si ispira fortemente a quanto enunciato nell’Agile Manifesto, ma presenta anche valori e princìpi propri.
In particolare, i valori possono essere riassunti come segue:
openess: i membri del team sono liberi di esprimere emozioni e paure in maniera aperta, così che i problemi possano essere affrontati e superati;
courage: il lavoro di squadra permette al singolo di non sentirsi abbandonato e quindi di avere maggiore coraggio nell’affrontare le sfide che attendono lui e tutto il gruppo;
respect: lavorare insieme vuol dire condividere successi e insuccessi, ma significa soprattutto imparare a collaborare rispettandosi ed aiutandosi vicendevolmente;
focus: la concentrazione su pochi elementi alla volta permette di realizzare un lavoro più preciso e ben realizzato; questo aspetto è fortemente collegato al concetto di semplicità espresso dal decimo principio dell’Agile;
commitment: il team di progetto, come già visto, sarà chiamato ad auto-organizzarsi e questo porta a maggiore impegno e propensione verso il successo.
I princìpi di Scrum sono invece da vedersi come delle regole che devono essere seguite dal team di progetto; i principali sono:
empirismo: la conoscenza deriva dall’esperienza e tutte le decisioni vengono prese basandosi su ciò che si conosce. In Scrum hanno molta importanza le continue verifiche e i continui adattamenti proprio perché accrescono la base culturale; molta importanza ha poi l’approccio incrementale, che aiuta a ridurre imprevedibilità e rischi;
trasparenza: tutto ciò che ha valore e significato deve essere visibile ai responsabili del prodotto finale, siano essi team di sviluppo o clienti;
ispezione: come suggerito dalla metodologia Agile, anche Scrum si compone di tante iterazioni che portano alla realizzazione di artefatti i quali devono essere continuamente ispezionati al fine di evitare deviazioni indesiderate dal percorso tracciato;
adattamento: la riduzione di queste deviazioni porta a continui adattamenti che non devono essere mal visti, ma, anzi, devono essere motivo di stimolo per portare maggiore valore e vantaggio competitivo al cliente.
Il ciclo di vita di un progetto Scrum
Il ciclo di vita del framework Scrum è riassumibile nell’immagine riportata di seguito.
Ciclo Scrum by Scrum.org
Come si può notare dall’immagine, il ciclo Scrum non risulta particolarmente complicato ma, affinché il tutto abbia efficacia, deve essere seguito pedissequamente.
Il primo passaggio è definito dal già citato Product Backlog. Esso contiene l’insieme degli elementi che devono essere realizzati e ad ognuno di essi viene assegnata una priorità. Come suggerisce la sua posizione nell’immagine precedente, esso costituisce sia l’inizio di tutto il progetto, sia l’inizio di ogni iterazione nonché la conclusione di ogni iterazione. A valle di ogni ciclo, infatti, si può aggiornare e modificare il Product Backlog al fine di renderlo sempre più completo e ricco di elementi che generano valore per il cliente. Questo documento è quindi il primo artefatto prodotto da un progetto sviluppato con framework Scrum e contiene tutti quegli elementi che potrebbero risultare necessari per realizzare il prodotto finale.
Tutti gli elementi che vanno a comporre il Backlog devono possedere una descrizione, un ordine e una stima. Più alto sarà l’ordine di un elemento, maggiore sarà la sua importanza e maggiore sarà il consenso su di esso.
L’individuo atto a gestire, armonizzare e prioritizzare il Product Backlog è il Product Owner (il committente) che è l’unico responsabile per questa funzione assieme al team di sviluppo, il quale coadiuverà soprattutto per la fase di popolazione dell’elenco. Per valutare la buona riuscita della fase di riempimento del Backlog, si può usare un criterio denominato DEEP:
Detailed appropriately: non tutti gli elementi devono avere lo stesso livello di dettaglio, ma il team deve cercare di fornire specifiche più precise per quelli che entreranno nei primi sprints;
Emergent: bisogna essere consapevoli del fatto che il Backlog può essere continuamente aggiornato con nuove informazioni derivanti dall’esecuzione del progetto o da nuove esigenze che emergono dai confronti all’interno dello Scrum team;
Estimated: tutti gli elementi che andranno a comporre questa lista devono essere stimati (secondo Story Points o con altre tecniche) e quelli a più alta priorità devono avere una stima più precisa;
Prioritized: occorre assegnare a tutti gli elementi una priorità.
Una volta sancita la buona riuscita di questa prima fase, si può passare alla successiva, durante la quale tutto lo Scrum team identifica la funzionalità da implementare durante lo sprint (che inizierà a breve) e definirà la metrica per il rilascio dei deliverables che si vogliono fornire alla fine dell’iterazione (quella che avevamo chiamato definition of done). Questa seconda fase è quella di compilazione dello Sprint Backlog. Ciò avviene durante un incontro che ha il nome di Sprint Planning Meeting ed una durata di due ore per ogni settimana di durata dello sprint.
Gli elementi vengono espressi nella forma di User Stories. Quelli che vengono spostati dal Product Backlog allo Sprint Backlog devono essere scelti stando attenti a non eccedere la produttività del team per il periodo di tempo ricoperto dall’iterazione, cioè la quantità di Story Points che un gruppo di lavoro è in grado di processare in quel determinato arco temporale. Nel corso dello sprint, al completamento dei requisiti forniti dalle User Stories, il numero di Story Points ancora da processare si riduce. Questo andamento può essere riportato su un grafico chiamato Burn-Down Chart che mostra la variazione in funzione della durata dell’iterazione e che viene aggiornato quotidianamente.
I parametri utili per definire correttamente la durata di uno sprint sono: l’incertezza e la facilità di ottenere feedback, maggiori sono questi parametri e minore sarà il tempo che intercorre tra l’inizio e la fine di un’iterazione.
Una volta terminata questa prima fase di definizione, il team entra nella realizzazione del vero e proprio sprint. In tale fase il Product Backlog viene congelato e anche la composizione del gruppo di lavoro non deve cambiare. In questo lasso di tempo le persone coinvolte dovrebbero lavorare sul progetto senza interruzioni e con l’obiettivo di mantenere alto il livello di efficienza e di processare tutte le richieste che sono state inserite nello Sprint Backlog. Il numero di Story Points che un team può processare è anche detto capacità del gruppo di lavoro e viene stimata di volta in volta a seconda di: capacità di lavorare su specifiche tematiche, possibili assenze dei membri del gruppo e attività che potrebbero distrarre dal progetto. Inoltre, si è soliti inserire un certo buffer che permetta di assorbire eventuali ritardi e può essere valutato come una percentuale del tempo totale dello sprint.
Un momento molto importante in questa fase è quello definito Daily Scrum Meeting. Come suggerisce il nome, si tratta di un incontro a cadenza giornaliera della durata di 15 minuti massimo. Il team si ritaglia questo momento per aggiornarsi vicendevolmente su quanto avvenuto nelle ventiquattro ore precedenti e per aggiornare il Burndown Chart. È molto importante che l’incontro si svolga sempre allo stesso orario e sempre nello stesso luogo, che deve essere sia un ambiente il più possibile informale sia uno spazio che permetta di mantenere sott’occhio tutto ciò che riguarda il progetto. In questa fase è utile riportare agli altri membri del gruppo che cosa si è fatto il giorno precedente, cosa si ha intenzione di fare prima della prossima riunione e quali difficoltà si sono riscontrate nello svolgere i propri compiti.
La fine dello sprint è sancita dal rilascio di parte del prodotto funzionante e da un momento chiamato Sprint Review Meeting. Durante lo Sprint Review Meeting, della durata di un’ora per ogni settimana di lavoro, si valutano gli incrementi apportati dal team di progetto e si aggiorna il Product Backlog con le nuove richieste che emergono dagli stakeholders che sono chiamati a fornire quanti più feedback possibili al gruppo di lavoro.
A valle di tutto questo vi è uno dei momenti più importanti per il team di progetto, lo Sprint Retrospective Meeting. Il tempo dedicato a questo incontro (45 minuti per ogni settimana di lavoro) è molto importante per il gruppo che effettua una retrospettiva del proprio modo di lavorare. Ogni membro riporta gli aspetti che ha apprezzato, quelli che vorrebbe limitare e altri ancora che vorrebbe migliorare. L’obiettivo è quello di avere un confronto quanto più franco e libero con tutti gli altri componenti del gruppo. Il fine ultimo di questa tipologia di riunione è quello di migliorare il gruppo dal punto di vista dell’efficienza e di creare un piano che porti effettivamente a realizzare i miglioramenti che si vogliono implementare. Una delle tecniche usate in questa fase è quella comunemente chiamata Fish retrospective, la quale mette in evidenza gli aspetti che ogni membro del team vorrebbe fare maggiormente (more), con minore frequenza (less), che vorrebbe cominciare (start), smettere (stop) e continuare (keep) a fare nello sprint successivo.
Gli attori di Scrum
Gli attori principali descritti dalla metodologia Scrum sono: il team di sviluppo, il Product Owner e lo Scrum Master.
Il team di sviluppo può essere descritto grazie a due caratteristiche principali: sa auto-organizzarsi ed è multidisciplinare (cross-functional). L’auto-organizzazione indica il fatto che il gruppo sa identificare e perseguire le migliori scelte per svolgere adeguatamente il lavoro che gli è affidato, mentre il secondo aspetto mette in evidenza il fatto che il team dispone di tutte le competenze necessarie per portare avanti il progetto. È importante riportare che non è richiesto che ogni membro del team debba saper fare tutto, ma che la forza del gruppo deriva dall’unione delle diverse competenze specialistiche di ogni individuo e ognuno può comunque portare attivamente il suo contributo.
La dimensione ottimale di un gruppo è di 3 - 9 membri. Questa dimensione permette di avere un numero sufficiente di competenze differenti, un coordinamento non eccessivamente oneroso, l’impossibilità nella formazione di sottogruppi che sarebbero dannosi per la comunicazione e la trasparenza e la riduzione dei casi di social loafing. Dal conteggio degli individui coinvolti rimangono estranei il Product Owner e lo Scrum Master, a meno che anche essi non siano effettivamente membri che svolgono compiti legati alle specifiche presente nel Product Backlog.
Un’altra figura fortemente coinvolta nel progetto è quella del Product Owner, che ha la responsabilità di massimizzare il valore del prodotto realizzato dal team di sviluppo. Egli controlla il progetto cercando di interpretare bisogni e priorità delle figure interessate al progetto stesso e ha il compito di comunicare queste visioni al gruppo operativo. È sua responsabilità anche la validazione dell’ambito alla fine di ogni sprint e la gestione del Product Backlog. In relazione a questo ultimo punto, il Product Owner deve garantire che gli elementi siano espressi in maniera chiara, ordinati per priorità e che l’elenco sia visibile, trasparente e chiaro a tutti. Ciò che viene ufficializzato da questa figura è ciò che conta, egli costituisce l’unica fonte che deve essere ascoltata durante lo sprint per quanto riguarda i requisiti richiesti dai clienti.
Ultimo ruolo è quello dello Scrum Master. Egli deve aiutare tutti a comprendere ed abbracciare appieno i valori, i principi e le pratiche Scrum. Deve favorire la comprensione del ruolo di ogni individuo che si avvicina a questa metodologia, sia esso interno o esterno al gruppo di progetto. Questa figura funge anche da facilitatore per il team, favorendo il mantenimento di un’elevata produttività e la rimozione degli ostacoli. Lo Scrum Master non deve essere colui che risolve i problemi del gruppo, ma colui che aiuta il team a risolvere i propri problemi da solo. Altri compiti di questo attore sono: aiutare il Product Owner ad ottenere il massimo valore da ogni sprint, migliorare anche aspetti come creatività ed empowerment del team e migliorare l’utilizzo di tutti gli strumenti messi a disposizione dalla metodologia Scrum ed utilizzati dal gruppo durante le diverse iterazioni.
Lo Scrum-ban
Lo Scrum-ban trae ispirazione diretta dai kanban (cartellini), resi famosi dalla metodologia della Lean Manufacturing. L’idea alla base di tutto è che si debbano limitare gli elementi Work In Progress (WIP) che nel mondo manufacturing sono manufatti iniziati e non completati mentre, per quel che riguarda la metodologia Scrum, sono attività presenti nello Sprint Backlog che sono state iniziate ma non portate a termine. Ridurre i WIP vuol dire fornire maggiore continuità al flusso rendendo le previsioni sempre più affidabili.
I cartellini vengono riempiti con informazioni come: titolo dell’attività da svolgere, tipologia di attività (definibile anche in base al colore del cartellino), durata stimata, numero di Story Points che il completamento dell’attività permette di collezionare, figura responsabile, ecc… Ogni membro del gruppo si assume la responsabilità di uno dei kanban e lo porta fino alla sua conclusione. Una volta definiti i vari cartellini (e quindi le diverse attività), viene posizionato su di una lavagna detta Kanban Board (o Scrum Board), divisa in varie colonne che riportano come titoli i nomi di diverse fasi di avanzamento delle attività come ad esempio: to-do, valutazione idee, inprogress, intest, ready, done … È durante il Daily Scrum Meeting che viene aggiornata la situazione sulla lavagna a seconda delle attività completate durante la giornata precedente. Alla fine di ogni sprint tutto quello che era stato preso in carico (era stato messo nei to-do) deve essere stato terminato e quindi spostato nella colonna done. Al fine di garantire una maggiore continuità al flusso di lavoro, è possibile anche limitare la popolazione presente in alcune colonne così da ridurre il numero di WIP e obbligare i responsabili a trovare soluzioni per non creare ingorghi che potrebbero inficiare anche il lavoro degli altri membri del team.
Alcuni link per approfondire
Il sito ufficiale di Scrum
Alcune certificazioni Agile (e Scrum) ottenibili tramite il Project Management Institute
