La metodologia Scrum

Il Blog di T-PPM Project Management

27 December 2019
Letto 5792 volte

Nel primo articolo di questa serie sulle metodologie Agile, abbiamo visto quali siano i principi fondamentali di questo movimento. In questo secondo articolo vediamo uno degli approcci più conosciuti ed utilizzati: la metodologia Scrum.

Il metodo Scrum

Scrum è un vero e proprio framework, che si presta molto bene per gestire i progetti in modo iterativo ed incrementale. Negli anni questo approccio ha visto un aumento della sua popolarità grazie alla sua semplicità e alla sua capacità di incorporare in modo lineare molti dei principi Agile.

Seguendo questo approccio, il Product Owner lavora a stretto contatto con il team di sviluppo per stabilire e prioritizzare le funzionalità che dovranno essere realizzate, e inserisce queste User Stories all'interno di un elenco generale dei requisiti di tutto il progetto chiamato Product Backlog.

Il progetto viene a questo punto suddiviso in iterazioni (Sprint),ciascuna delle quali dovrebbe portare a compimento una parte del prodotto. Il team decide per ogni iterazione quali funzionalità implementare prendendole dal Product Backlog.

Ogni Sprint ha una durata limitata (generalmente 1 o 2 settimane, più raramente 4/6) per mantenere il team il più possibile focalizzato sull'obiettivo. Una volta che uno Sprint ha inizio, difficilmente saranno accolti altri requisiti all'interno dell'iterazione. Eventuali nuove richieste saranno incorporate in iterazioni successive.

Durante tutto il corso dello Sprint vengono organizzati giornalmente degli incontri tra i membri del team, della durata di qualche decina di minuti, dove ogni membro discute il lavoro fatto il giorno precedente e quello che intende eseguire quel giorno.

Al termine dello Sprint il Product Owner decide se e quali delle nuove funzionalità realizzate possano essere rilasciate come nuova versione del prodotto, oppure se sia necessario attendere il completamento di Sprint successivi. Viene inoltre organizzata una retrospettiva per valutare come sia andato lo Sprint, verificare che tutte le User Stories siano rispettate e valutare eventuali colli di bottiglia.

Una volta che un'iterazione viene dichiarata completata, i task rimanenti nel backlog vengono prioritizzati nuovamente e schedulati in un nuovo Sprint.

I ruoli previsti

Gli attori che collaborano in un processo Scrum possono essere suddivisi in 3 ruoli principali:

  • Product Owner: questo attore è deputato a stabilire le User Stories che devono rientrare in ogni Sprint, e di decidere quando uno Sprint possa essere rilasciato come una nuova versione del prodotto. Si tratta a tutti gli effetti di un'interfaccia tra il cliente, il management, e il team di sviluppo.

  • Scrum Master: il compito di questo ruolo è quello di mantenere il team focalizzato e ridurre le interruzioni al minimo. Se ad esempio uno dei membri del team di sviluppo viene richiesto a supporto di un altro team, sarà lo Scrum Master che dovrà stabilire le modalità e le tempistiche con cui potrà avvenire questo "prestito".

  • Development Team: i membri del team di sviluppo sono quelli effettivamente deputati allo svolgimento del lavoro di realizzazione delle User Stories. Il team collabora inoltre con il Product Owner, stimando l'impegno necessario per realizzare le User Stories, e stabilendo le priorità nel Backlog di Progetto. Inoltre, durante lo svolgimento di uno Sprint, il team ha il compito di presentare le funzionalità realizzate al Product Owner.

Un approccio "visuale"

A supporto di un processo Scrum vengono tipicamente utilizzati strumenti atti a semplificare il lavoro del team, in tutte le sue fasi.
Una delle caratteristiche comuni a tutti questi strumenti è la loro predisposizione ad essere altamente visuali, per permettere di individuare a colpo d'occhio lo stato dei lavori.

Story cards

Le story cards (o tasks) sono uno strumento molto utile per rappresentare le funzionalità che dovranno essere realizzate, e permettono di suddividere i requisiti di progetto (User Stories) in blocchi più piccoli e gestibili.
Una story card può essere vista come un cartellino compilato su entrambi i lati. Sul fronte viene riportato il titolo, la descrizione del requisito e l'obiettivo che si vuole ottenere. Vengono inoltre riportate altre informazioni, come l'utente/ruolo che dovrebbe utilizzare la funzionalità richiesta, un "punteggio" indicativo del valore e una stima del tempo necessario per la realizzazione. Sul retro della story card vengono invece riportate una serie di condizioni che descrivono in forma schematica il comportamento atteso della funzionalità.

Modello di story card (fronte)
Template di story card (fronte)
Modello di story card (retro)
Template di story card (retro)

Ad esempio, in un progetto di gestione di un catalogo prodotti, nel contesto di una User Story che richiede la realizzazione di un elenco dei prodotti, un possibile task potrebbe essere descritto come:

Esempio di story card (fronte)
Esempio di story card (fronte)
Esempio di story card (retro)
Esempio di story card (retro)

Le story card andranno a far parte in primo luogo del backlog di progetto, successivamente saranno prioritizzate in base al loro valore e alle stime, per poi essere prescelte ed incluse negli Sprint. In fase di realizzazione e di accettazione della funzionalità le condizioni indicate nel retro delle card saranno utilizzate per poter definire dei casi di test efficaci.

Scrum board

Lo scrum board è il principale strumento utilizzato dal team durante lo svolgimento di uno Sprint.

Si tratta in pratica di una lavagna suddivisa in righe e colonne: le righe rappresentano le singole User Stories, mentre le colonne costituiscono gli stati di lavorazione delle Story Cards. Il numero di colonne è variabile, ma tipicamente vengono almeno definiti gli stati:

  • Todo: requisiti che sono stati prescelti e che devono essere implementati nello Sprint
  • Wip: funzionalità in fase di lavorazione
  • Accept: funzionalità la cui implementazione è terminata e che devono sottostare all'accettazione da parte del Product Onwer
  • Done: implementazioni terminate e accettate

La scrum board è uno strumento che permette (anzi, incoraggia) l'auto organizzazione del team: ogni membro può prendere in carico in autonomia i task su cui intende lavorare, spostandoli di volta in volta nello stato di lavorazione corrispondente.
Grazie all'utilizzo di questo strumento, lo stato di avanzamento dei singoli task e dell'intero Sprint è sempre evidente a tutto il team.

Esempio di Scrum Board
Esempio di Scrum Board

Burndown chart

Questo è uno strumento molto utile che, combinato con la Scrum Board, permette di valutare e visualizzare in maniera immediata l'andamento di uno Sprint.
Si tratta di un grafico che, nella sua forma più semplice, rappresenta in uno degli assi il totale delle ore rimanenti al termine dello Sprint, calcolato come la somma delle ore stimate nelle Story Card ancora da completare, mentre nell'altro asse mostra i giorni dello Sprint.
Forme più avanzate prevedono un ulteriore asse in cui posizionare il numero di task ancora aperti.

In una situazione ideale l'andamento del grafico dovrebbe essere una curva con una "pendenza" discendente più o meno costante, ad indicare che giorno per giorno vengono "smarcati" i task previsti:

Esempio di burndown chart ideale
Burndown chart in una situazione "ideale"

Ovviamente non sempre ci si ritroverà in situazioni di questo tipo, per questo è molto importante riuscire ad interpretare le varie forme che questo grafico può assumere, al fine di individuare e correggere tempestivamente eventuali errori di valutazione.

Potremo ad esempio trovarci di fronte a una delle seguenti situazioni:

Esempio di burndown chart per uno Sprint sottostimato
Burndown chart per uno Sprint sottostimato
Esempio di burndown chart per uno Sprint sovrastimato
Burndown chart per uno Sprint sovrastimato

Nel primo caso, al termine dello Sprint le ore rimanenti previste non sono ancora azzerate. Questo può voler dire 2 cose:

  1. La stima fatta non è stata molto accurata. I task potrebbero essere comunque stati completati, ma essendo le stime di uno o più task errate, al termine dello Sprint si ha l'impressione che il lavoro non sia ancora terminato.
  2. Il lavoro non è effettivamente stato completato. Ci troviamo nella situazione in cui uno o più task sono stati sottostimati.

Nel secondo caso, le ore rimanenti vengono azzerate prima del termine previsto dello Sprint. Anche qui possono in realtà essere accadute 2 cose:

  1. Uno o più task sono stati sovrastimati
  2. E' stato sottostimato il numero di task che il team riesce a portare a termine nel corso dello Sprint

Entrambi i casi ci possono comunque aiutare a raffinare le stime in futuri progetti che dovessero richiedere requisiti simili.

In conclusione

Scrum è una metodologia di Project Management che sta riscuotendo molto successo, e sebbene sia nata per gestire progetti software, sempre più spesso viene applicata anche ad altre funzioni aziendali. Scrum è a tutti gli effetti uno strumento, ed in quanto tale può essere utilizzato per affrontare efficacemente i progetti in qualsiasi ambito che richeda un lavoro di gruppo. Non è ad esempio raro leggere di dipartimenti marketing che utilizzano lo stesso approccio, ed in generale adattano i principi dell'Agile Manifesto, nel loro ambito lavorativo.

Nei prossimi articoli di questa serie continueremo la panoramica delle principali metodologie Agile, cercando di chiarire le differenze tra i vari approcci.

Scopri tutti gli strumenti e le funzionalità della soluzione di gestione progetti, commesse ed attività T-PPM Project Management

Prova ora la demo del software gestione progetti e commesse T-PPM oppure prenota una live demo con un nostro esperto.
Per esigenze particolari contattaci per attivare un ambiente dedicato!

Contatta il nostro team

Vuoi avere più informazioni sui tool e gli strumenti integrati nel software gestione progetti T-PPM Project Portfolio Management?
Non esitare a contattarci tramite la seguente form, il nostro team è pronto a rispondere a tutte le tue domande!

Attendere prego