Scrum, elenco (quasi) completo dei framework Agile

Iniziamo l’approfondimento dei framework Agile con uno dei più utilizzati: Scrum.

Descrizione generale
Scrum nasce ufficialmente durante una presentazione all’OOPSLA del 1995 tenuta da Jeff Sutherland e Ken Schwaber. Si configura come un insieme di linee guida da seguire nel corso dello sviluppo di un prodotto. Definisce eventi, artefatti e ruoli specifici, ma non strumenti o metodologie particolari, che lascia all’auto-organizzazione del team. Adotta un approccio iterativo e incrementale, grazie ad un processo empirico.

Focus su
Trasparenza, Adattabilità e Ispezione. E’ un framework basato sulle persone. Gli Sprint sono alla base del processo iterativo e alla fine di ogni Sprint deve essere rilasciato codice che presenti “valore” per il cliente finale.

Ruoli
Lo Scrum Team è composto dal Development Team (gruppo di 3-9 persone che si occupa dell’implementazione vera e propria, auto organizzandosi, senza “titoli” individuali, multidisciplinare quanto necessario per raggiungere l’obiettivo prefisso), dal Product Owner (responsabile di business che raccoglie e ordina per priorità le funzionalità che il prodotto deve avere, supportando il team di sviluppo con tutte le informazioni necessarie al corretto procedere del lavoro e facendo da punto di contatto con tutti gli stakeholder) e dallo Scrum Master (il facilitatore per antonomasia, colui che assicura che i principi dello Scrum siano correttamente recepiti da tutti, che supporta il team rimuovendo gli impedimenti e lo istruisce su come acquisire quel grado di auto organizzazione e responsabilità alla base del framework).

Dimensione del team
Scrum consiglia da un minimo di 3 ad un massimo di 9 elementi come componenti del team, esclusi i ruoli di Product Owner e Scrum Master. I quali potrebbero comunque far parte del Development Team se in possesso delle conoscenze necessarie a raggiungere l’obiettivo previsto dallo Sprint.

Eventi
Sono definiti il Daily Scrum (incontro giornaliero con timebox a 15 minuti nel quale ogni membro del Development Team condivide cosa ha fatto, cosa farà e quali problemi ha rilevato), lo Sprint Planning Meeting (diviso in due sessioni da max 4 ore in preparazione allo Sprint con definizione dello Sprint Backlog e dei task), lo Sprint Review Meeting (una sessione da massimo 4 ore per presentare i risultati dello sprint e discutere di come procedere insieme agli stakeholders), Sprint Retrospective Meeting (una sessione da massimo 3 ore nella quale analizzare le lezioni imparate e migliorare ciò che può essere migliorato). Possono esserci anche altri eventi se necessari al raggiungimento dell’obiettivo di uno Sprint, ma questi sono quelli prescritti da Scrum.

Artefatti
Il Product Backlog e lo Sprint Backlog rappresentano l’elenco delle funzionalità, ordinato per priorità, rispettivamente dell’intero prodotto e della singola iterazione. Il Product Backlog è in gestione al Product Owner. Lo Sprint Backlog è in gestione del Development Team. Più è elevata la priorità di un elemento del Product Backlog maggiore deve essere il suo dettaglio descrittivo. Durante lo Sprint Planning Meeting il Product Owner lavora con il Development Team alla definizione dettagliata delle funzionalità da includere nello Sprint Backlog. I Burndown Chart mostrano l’andamento di quanto fatto durante gli Sprint e una stima di quanto manca alla chiusura del progetto.

Durata di un’iterazione
Scrum suggerisce un massimo di un mese (elapsed, ossia 30 giorni solari, non solo quelli lavorativi) per ogni Sprint, che può anche essere ridotto, con relativa diminuzione proporzionale degli eventi (a meno del Daily Scrum che resta sempre di 15 min). L’idea alla base di questa durata è che un mese di tempo è sia il massimo periodo dopo cui va rilasciato valore al cliente, sia il massimo periodo di ritardo assorbile in caso ci si renda conto di un errore di valutazione nel progetto.

Metodo per le stime
L’assegnazione di un valore numerico ad ogni funzionalità presente nel Product backlog consente di avere una stima generale del prodotto. Può essere un valore di complessità o un’ipotesi di effort necessario alla sua conclusione. In ogni caso man mano che passano le iterazioni è necessario rivedere le stime effettuate e allineare il Burndown Chart riducendo della somma dei valori assegnati alle funzionalità consegnate negli Sprint il totale del lavoro rimanente. Questa capacità di produzione di funzionalità del team in uno Sprint viene definita “Velocità”. Grazie alla definizione sempre più corretta della Velocità e alla valutazione precisa del valore di ogni funzionalità a priorità più alta è quindi possibile stimare l’andamento del progetto.

Scalabilità
Scrum può essere facilmente scalato. Uno dei metodi che si utilizza è Scrum di Scrum, ossia estendere di uno o più livelli le pratiche Scrum. Esistono anche interi framework estensioni di Scrum come ad esempio LeSS o SAFe che dettano le linee guida di come gestire progetti che necessità di diversi team di sviluppo che lavorano in contemporanea.