Mischia, scrummage o Scrum?
Avete presente il rugby? Quello sport in cui 15 persone contro 15 tentano di portare in ogni modo una palla ovale nella meta avversaria. Di certo non è il più famoso tra gli sport (anche se per me resta tra i più onorevoli) ma se per caso avete visto qualcosa, di sicuro vi sarà rimasta impressa una fase molto particolare di questo gioco: la mischia, detta anche scrummage o per gli amici scrum. Nello scrum i giocatori di una squadra si impegnano, uniti e compatti uno all’altro, a guadagnare il possesso della palla spingendo tutti assieme e nella stessa direzione, un modo molto pratico di raggiungere l’obiettivo comune.
È proprio da qui che Ken Schwaber e Jeff Sutherland hanno preso spunto nel lontano 1995 per dare un nome alla metodologia di lavoro che stavano ideando: lo Scrum. Il senso era proprio questo: un metodo per unire un team di persone e farle lavorare in modo coordinato e organizzato al fine di raggiungere un obiettivo nel migliore dei modi.
Dagli anni ‘90 ad oggi si è sentito parecchio parlare di Agile e in particolare di metodologie Agile (se non hai mai sentito parlare di Agile ti consiglio questo articolo), ad oggi la maggior parte delle aziende dell’industria IT (in realtà anche in altri settori) adottano approcci di questo tipo nella progettazione e realizzazione di prodotti di successo. Lo Scrum si colloca tra le metodologie Agile più diffuse e stando allo State of Agile Survey, circa il 64% delle aziende lo adottano, è di fatto il metodo più indicato per progetti complessi ed innovativi.
Cos’è Scrum e come funziona?
La guida ufficiale indica lo Scrum come “un framework che consente alle persone di risolvere problemi complessi di tipo adattivo e, al tempo stesso, di creare e rilasciare prodotti in modo efficace e creativo del più alto valore possibile.”
Si parla quindi di framework: un insieme di prassi, di ruoli e di strumenti per organizzare al meglio il proprio processo produttivo. Un set di conoscenze dalla quale partire per affinare la propria metodologia su misura della propria organizzazione.
Scrum si basa sull’approccio empirico: trasparenza, ispezione e adattamento sono definiti i 3 pilastri del controllo empirico. Gli obiettivi del progetto deve essere chiari, ogni fase del processo deve essere ispezionabile e sulla base dell’esperienza acquisita il processo deve essere adattabile al fine di migliorare il risultato finale.
Come tutte le metodologie Agile, lo Scrum si basa sulla divisione del progetto in più fasi di sviluppo iterative, chiamate Sprint. Al termine di ogni Sprint vengono presentate le nuove funzionalità implementate, il cliente può valutarle e decidere come proseguire. Questo sistema iterativo consente di incrementare poco alla volta, ma molto di frequente, le funzionalità del progetto. Allo stesso tempo il team di lavoro e il cliente possono verificare costantemente l’andamento complessivo.
Il lavoro di progettazione e sviluppo viene affidato allo Scrum Team, un team di professionisti che adotta il framework Scrum definendo Ruoli nel team, utilizzando Artefatti e organizzando lo Sprint in determinati Eventi.
Ruoli
I ruoli all’interno dello Scrum Team sono 3: Product Owner, Scrum Master, Team di sviluppo
Product Owner
Definisce il lavoro da svolgere, ponendosi come interfaccia tra gli stakeholders e il team. Il suo ruolo è quello di raccogliere i requisiti, mediare tra le parti e programmare l’avanzamento del lavoro, al fine di massimizzare il valore del prodotto finale e il lavoro del Team di Sviluppo. Collabora attivamente con gli sviluppatori chiarendo dubbi, rispondendo alle domande e definendo obiettivi di sviluppo in linea con la roadmap di prodotto e i desiderata degli utenti.
Scrum Master
È un leader, una sorta di coach, al servizio dello Scrum Team. È responsabile di promuovere e sostenere Scrum aiutando chiunque a comprendere la teoria, le pratiche, le regole, ed i valori di Scrum. Il suo ruolo è proteggere il team da interferenze esterne e interruzioni, risolvere eventuali impedimenti, facilitare i meeting di confronto, affinché il progetto abbia successo.
Team di Sviluppo
È un team di professionisti auto-organizzato e cross-funzionale, composto da un minimo di 3 ad un massimo di 9 elementi, che si occupa dello sviluppo del prodotto e del test delle funzionalità. Il team decide autonomamente come implementare le funzionalità individuate dal Product Owner e si prende la responsabilità dell’intero sviluppo al fine di portare a termine i singoli Sprint.
Artefatti
Gli artefatti sono 3: Product Backlog, Sprint Backlog e Incremento. Sono progettati per aumentare la trasparenza delle informazioni principali e l’opportunità di ispezione e adattamento.
Product Backlog
Il documento che contiene la lista di tutti requisiti necessari per la realizzazione del progetto. Il Product Owner è responsabile del suo contenuto, della sua disponibilità e dell’ordinamento dei suoi elementi in base alla priorità di svolgimento e di rilascio. È un documento vivente: la sua prima stesura definisce i requisiti inizialmente conosciuti e meglio compresi, per poi evolversi in base a come evolve il prodotto, ai feedback ricevuti dal cliente e alle necessità che man mano emergono. Il Product Backlog è composto dalle User Story: brevi e semplici descrizioni che descrivono la funzionalità dal punto di vista dell’utente e dal valore di business che questa apporta al progetto.
Una User Story è di norma strutturata in questa forma: Come <ruolo dell’utente>, voglio <obiettivo> così che <ragione o valore di business>
Qualche esempio:
Come amministratore del blog voglio moderare i commenti così che non ci sia spam
Come utente voglio registrarmi al portale così da accedere ai servizi riservati
Come amministratore dell’ecommerce voglio ricevere una mail ad ogni ordine così da poter organizzare al meglio le spedizioni
Sprint Backlog
È l’insieme degli elementi del Product Backlog selezionati per lo Sprint. È una previsione fatta dal Team di Sviluppo in relazione alle priorità indicate nel Product Backlog e al lavoro necessario per raggiungere gli obiettivi dello Sprint. Lo Sprint Backlog rende visibile tutto il lavoro che il Team di Sviluppo identifica come necessario per raggiungere lo Sprint Goal, tiene traccia del lavoro svolto giornalmente, delle attività completate e di quanto rimane da fare.
Incremento
L’Incremento è la somma di tutti gli elementi del Product Backlog completati durante uno Sprint e del valore degli incrementi di tutti gli Sprint precedenti. Un Incremento è un insieme di lavoro “Fatto” ed ispezionabile che supporta l’empirismo alla fine dello Sprint. L’incremento deve essere utilizzabile indipendentemente dal fatto che il Product Owner decida di rilasciarlo o meno.
Definizione di “Fatto”
Lo Scrum Team definisce le regole e le condizioni per cui un elemento del Product Backlog o un incremento risulta “Fatto”, i membri devono avere una comprensione condivisa di ciò che si intende per lavoro completo, al fine di garantire la trasparenza.
Lo Sprint
Il cuore di Scrum è lo Sprint, un periodo limitato (time-boxed) che generalmente va da due settimane a un mese, durante la quale viene creato un Incremento di prodotto potenzialmente utilizzabile e rilasciabile.
Può essere considerato come un mini-progetto e tutto il team deve avere ben chiaro lo Sprint Goal. 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. Solo i risultati raggiunti e considerati come completati dal team possono essere candidati a finire nel prodotto finale.
Lo Sprint è organizzato in 4 principali eventi: Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective e ovviamente dalle sessioni di sviluppo.
Eventi (o Rituals)
Gli eventi utilizzati in Scrum sono a durata prefissata e servono a creare regolarità, sincronizzare le attività e ridurre al minimo la necessità di incontri non definiti. L’obiettivo di questi eventi è consentire trasparenza critica ed ispezione sull’andamento del progetto.
Sprint Planning
È la riunione che segna l’inizio dello Sprint: lo Scrum Team concorda l’obiettivo principale dello Sprint (Sprint Goal) e individua gli elementi del Product Backlog necessari al raggiungimento. Il Team di Sviluppo analizza le User Story, individua le singole attività per portarle allo stato “Fatto” ed effettua una stima per comprendere quali possano essere sviluppate durante lo Sprint. Al termine dello Sprint Planning viene redatto lo Sprint Backlog. Lo Sprint Planning è limitato temporalmente (time-boxed) ad un massimo di otto ore per uno Sprint di un mese. Per Sprint più brevi, l’evento è di solito più breve.
Daily Scrum
È la riunione del Team di Sviluppo che viene svolta ogni giorno dello Sprint, per una durata massima di 15 minuti. In questo breve lasso di tempo, il team pianifica il lavoro della giornata ispezionando il lavoro svolto dall’ultimo Daily Scrum e prevedendo il lavoro in arrivo per i prossimi giorni dello Sprint. Il Daily Scrum ottimizza la probabilità che il Team di Sviluppo raggiunga lo Sprint Goal. La riunione permette allo Scrum Master di individuare eventuali problemi che possano rallentare il lavoro del team e permettergli di intervenire tempestivamente.
Sprint Review
Al termine di ogni Sprint viene organizzato lo Sprint Review, una riunione di massimo 4 ore per uno sprint di un mese, per valutare se l’obiettivo prefissato è stato raggiunto e con quali risultati. La Sprint Review è una riunione informale e serve allo Scrum Team per presentare agli stakeholder l’Incremento realizzato durante lo Sprint. Lo scopo della review è di suscitare commenti e promuovere la collaborazione tra il team e gli stakeholder. In seguito a questo confronto il Product Owner può decidere se rilasciare o meno l’Incremento.
Sprint Retrospective
Subito dopo la Sprint Review viene organizzato la Sprint Retrospective, una riunione formale dedicata al solo Scrum Team utile ad analizzare lo Sprint appena concluso.
Il Team in questa fase identifica le cose che sono andate bene, le cause di eventuali problemi e individua i miglioramenti che possono essere apportati al processo. Al termine di questa ispezione il team è in grado di pianificare eventuali azioni di correzione da applicare nel prossimo Sprint.
Con la Sprint Retrospective termina ufficialmente lo Sprint e lo sviluppo del progetto prosegue ripartendo dalla pianificazione del prossimo Sprint, continuando iterativamente fino al completamento del progetto.
Conclusioni
Come si diceva all’inizio di questo lungo articolo Scrum è un framework, è una base di partenza per l’ottimizzazione dei processi. Noi lo applichiamo allo sviluppo del software ma ciò non toglie che possa essere applicato a qualsiasi settore.
La sua natura di framework ci permette di avere a disposizione un set di strumenti e prassi ben rodate, sta a noi applicarci e utilizzarle nel migliore dei modi al fine di “…creare e rilasciare prodotti in modo efficace e creativo del più alto valore possibile” – cit. The Scrum Guide™