Scrum: gestione di progetto agile, moderna e flessibile

Quando i team iniziano a lavorare a un progetto, le problematiche da valutare sono molte. Specialmente gli ordini più grandi richiedono un progetto funzionante o un sistema di gestione del prodotto. Attualmente sono sempre di più le aziende che scelgono le procedure agili. L'attenzione si concentra su metodi di lavoro flessibili, sviluppi incrementali e processi trasparenti. Nell'ambito della gestione agile dei progetti, anche il termine "Scrum" sta diventando sempre più comune. Originariamente destinato allo sviluppo software, questo approccio adesso è conosciuto in molti altri settori. In questo articolo vi spieghiamo cosa si nasconde esattamente dietro a questa parola così in voga.

L’origine di Scrum risale agli anni '80, anche se nella sua forma attuale è in circolazione solo dal 1995. In quell'anno Ken Schwaber e Jeff Sutherland, che in origine avevano entrambi usato, ciascuno nella propria azienda, modelli simili, pubblicarono un documento comune. Il loro obiettivo era quello di rendere il lavoro più produttivo e allo stesso tempo introdurre il minor numero possibile di regole, in modo tale da non limitare la produttività.

Per questo Scrum stabilisce un quadro (framework) che può essere applicato a situazioni diverse e che ha lo scopo di ottimizzare tanto il metodo di lavoro quanto il prodotto. Nel framework vengono definiti ruoli, eventi, artefatti e regole. In questo contesto i team Scrum dovrebbero raggiungere i risultati nel modo più efficiente possibile, offrendo al cliente il miglior prodotto possibile. Pertanto, clienti, committenti e utenti ricoprono una posizione importante nel metodo Scrum: lo sviluppo è orientato alle loro esigenze.

Quando si lavora con Scrum, sono due le parole chiave da tenere a mente:

• Iterativo: in Scrum, un prodotto viene continuamente aggiornato. Il lavoro può essere descritto come una sorta di cerchio che parte dalla pianificazione, passa per lo sviluppo e i test, fino ad arrivare alla valutazione e, dunque, ripartire con una nuova fase di pianificazione. In tal modo Scrum non guarda soltanto alla produzione iniziale ma anche agli aggiornamenti successivi.
• Incrementale: Scrum si basa sull'idea che un prodotto venga creato passo dopo passo. Queste fasi pongono degli obiettivi intermedi. Ci si allontana quindi da un metodo di lavoro più classico che mira a un unico importante obiettivo finale. I grandi progetti vengono suddivisi in progetti più piccoli, conservando una flessibilità più elevata.

Un approccio iterativo-incrementale, che dunque combina i due aspetti, fa sì che lo sviluppo avvenga secondo un processo progressivo e continuo. Da un lato, il processo di sviluppo è molto più trasparente, in quanto vengono pianificati controlli più frequenti del lavoro (risultato dell'approccio a piccoli passi) e dall'altro si ottimizza la qualità del prodotto, in quanto la sua funzionalità viene costantemente controllata.

Scrum nasce originariamente per lo sviluppo agile del software, finalizzato all’ottimizzazione continua del lavoro sui programmi. Ma Scrum è diventato un modello efficace anche per altri prodotti, ad esempio per la produzione di hardware. Un progetto Scrum non deve necessariamente terminare con un prodotto nel vero senso della parola: qualsiasi progetto orientato ai risultati può infatti trarre vantaggio da questo tipo di approccio. Applicazioni dei principi Scrum si trovano ad esempio nell'organizzazione di team di marketing o enti amministrativi, nonché nello sviluppo di servizi.

Il metodo Scrum presuppone piccoli gruppi di lavoro, anche se "piccolo" è un termine piuttosto relativo: per i grandi gruppi di lavoro il modello flessibile rimane comunque meno indicato. Spesso è possibile suddividere un grande gruppo in squadre più piccole. Scrum è ideale anche quando i team comunicano tra loro in rete. Il lavoro di squadra ha un valore significativo in questo modello: all'interno di un team Scrum, i singoli membri dovrebbero completarsi a vicenda, ciascuno con le proprie competenze.

Scrum non va considerato un metodo fisso o una tecnica di lavoro concreta, ma piuttosto un framework che offre ai team dei saldi punti di riferimento per il loro lavoro. In questo framework rientrano determinati ruoli, eventi e artefatti.

All'interno di un team Scrum ci sono tre ruoli fissi: il Team, il Product Owner e lo Scrum Master. Il team è il vero e proprio sviluppatore del prodotto. Il gruppo è organizzato in modo da potersi autogestire e stabilisce in che modo raggiungere un obiettivo concordato. All'interno di un team Scrum non esistono gerarchie. Va da sé che ogni dipendente ha la propria area di responsabilità ma nella revisione finale tutti insieme devono rendere conto del prodotto.

La dimensione della squadra non è standard: il team viene formato perché possa lavorare in modo rapido e flessibile, rimanendo sempre efficiente. Quindi né troppo grande né troppo piccolo. Schwaber e Sutherland propongono gruppi composti dai 3 ai 9 membri.

In Scrum, il Product Owner è responsabile della qualità del prodotto e del lavoro e assume dunque la funzione di supervisore. I Product Owner organizzano il Product Backlog, cioè un elenco che definisce i requisiti del progetto (troverete maggiori informazioni sul Product Backlog al paragrafo "artefatti su Scrum"). Tra i suoi compiti c'è anche quello di ordinare gli obiettivi secondo una logica significativa e documentarli in modo comprensibile. Il Product Owner ha un ruolo autoritario: anche se di fatto sono i team a stabilire come raggiungere gli obiettivi formulati nel backlog, la determinazione di questi è a discrezione del Product Owner. Nessuno può mettere in dubbio le sue decisioni: per garantire la massima produttività, il team deve fidarsi delle decisioni del Product Owner. Non si tratta comunque di una posizione di leader: il Product Owner e il team hanno aree di responsabilità diverse e hanno potere decisionale relativamente a queste. Così come il team non deve mettere in discussione il backlog, il Product Owner non deve interferire con il processo di sviluppo.

Rispetto agli altri due ruoli, lo Scrum Master agisce come una sorta di mediatore. Lo Scrum Master è responsabile dell'integrazione e dell'applicazione del metodo Scrum nel flusso di lavoro. Questo significa che tale ruolo è responsabile dell'organizzazione degli eventi su Scrum: determina gli incontri e li modera. Inoltre, lo Scrum Master fornisce assistenza al team e al Product Owner. Tuttavia, non interviene mai nel processo di sviluppo vero e proprio. La sua funzione è puramente quella di semplificare i processi di lavoro nei confronti dei collaboratori coinvolti nella produzione, incrementando così la produttività e la creatività.

In qualità di referente, lo Scrum Master si assicura che tutte le parti coinvolte comprendano correttamente i processi: fornisce consigli sulla creazione di backlog o sull'organizzazione della squadra e aiuta a fronteggiare le difficoltà. Lo Scrum Master ha tra le sue varie funzioni anche il ruolo di coach; per questo è fondamentale una conoscenza approfondita di Scrum. Per questo motivo è anche possibile ottenere la certificazione per diventare Scrum Master. Attualmente esistono diversi organismi di certificazione che offrono anche corsi di formazione in merito. Sia la Scrum Alliance che Scrum.org sono stati fondati da Ken Schwaber e permettono di ottenere i certificati "Certified Scrum Master" e "Professional Scrum Master".

Se si organizzano processi di lavoro secondo il principio di Scrum, alcuni eventi si verificano regolarmente. Poiché Scrum è un processo iterativo, il lavoro viene svolto in cicli ripetitivi: ogni evento si svolge nuovamente a ogni ripetizione. La frequenza degli eventi su Scrum fa sì che le riunioni straordinarie siano piuttosto rare. Inoltre, tutti gli eventi hanno un calendario fisso.

Il ciclo è chiamato sprint e descrive il periodo di tempo di una fase di sviluppo. Al termine di uno sprint, il team di sviluppo rilascia un incremento del prodotto finito. Ciò significa che lo sviluppo deve portare a un prodotto che potrebbe essere potenzialmente consegnato. Così ogni sprint ha una missione concreta, che alla fine viene indicata come "fatta". L'arco di tempo dello sprint viene prestabilito ma non deve superare i 30 giorni. Nella determinazione del periodo di tempo occorre tenere presente che uno sprint non può essere né prolungato né abbreviato e gli sprint successivi del progetto dovrebbero avere tutti la stessa durata.

Gli sprint devono essere brevi affinché la formulazione degli obiettivi non diventi troppo complicata. La breve durata permette inoltre di controllare lo sviluppo almeno una volta al mese. Solo in pochi casi eccezionali il Product Owner (e lui soltanto) può annullare uno sprint, ad esempio quando l'obiettivo non deve più essere raggiunto perché l'azienda ha una finalità diversa. In linea di principio gli sprint non dovrebbero essere interrotti perché ciò riduce notevolmente la produttività.

Lo sprint inizia con lo Sprint Planning: tutti i ruoli del team Scrum sono coinvolti in questo evento. Durante un incontro della durata massima di otto ore, i partecipanti discutono sull'incremento del prodotto imminente: cosa dovrebbe essere incluso nell'incremento e come si vuole raggiungere il risultato? Il punto di partenza per la pianificazione è il Product Backlog. Il team di sviluppo e il Product Owner si mettono d'accordo su quali obiettivi raggiungere nel mese successivo. Il team di sviluppo discute poi su come devono essere svolti i compiti. Alla fine dell'incontro, gli sviluppatori dovrebbero essere in grado di discutere il loro piano con il Product Owner e lo Scrum Master.

All'interno dello sprint, ogni giorno si svolge un Daily Scrum, sempre nello stesso orario e luogo, perché più semplice dal punto di vista organizzativo. Nel corso di una riunione di 15 minuti, il team di sviluppo discute su quali compiti sono previsti per quel giorno e quali risultati sono stati raggiunti il giorno precedente. Gli sviluppatori valutano anche il progresso complessivo del progetto: a che punto delle voci del backlog sono arrivati? Il confronto quotidiano assicura che tutte le persone coinvolte non perdano di vista gli obiettivi, il che, in ultima analisi, aumenta anche la produttività.

Lo Scrum Master si assicura che ogni giorno si svolga un Daily Scrum ma i protagonisti dell'incontro sono gli sviluppatori, che determinano quali argomenti vengono discussi. Finché il contenuto riguarda il raggiungimento dell'obiettivo dello sprint e i 15 minuti non vengono superati, lo Scrum Master non interviene. Inoltre garantisce che gli altri partecipanti al Daily Scrum non disturbino il lavoro degli sviluppatori.

Quando uno sprint è terminato, segue una Sprint Review: l'incremento del prodotto viene controllato. I risultati vengono valutati insieme alle persone che non fanno parte del team Scrum, ma che hanno un interesse importante per il prodotto, come i proprietari dell'azienda o i clienti (collettivamente chiamati stakeholder). Si discute anche del processo di lavoro in quanto tale, si affrontano i problemi di sviluppo e si discutono le criticità. Questo ha un'influenza anche sulla pianificazione successiva, perché il Product Owner sfrutta l'opportunità di discutere l’avanzamento del backlog. I risultati dello sprint influenzano le previsioni sulle performance future.

Anche la rispettiva situazione di mercato influisce sul backlog: in particolare nei progetti a lungo termine, le priorità possono mutare nel tempo e i budget possono cambiare. Nella sprint review sono presi in considerazione anche questi argomenti, che cambiano l'approccio futuro. In uno sprint mensile, la review non dovrebbe durare oltre quattro ore.

La sprint review è seguita da un'ulteriore fase: la Sprint Retrospective. L'intero team Scrum (compresi il Product Owner e lo Scrum Master, ma esclusi gli stakeholder) viene riunito per un giro di feedback in una riunione che non supera le tre ore. Mentre la review si concentra principalmente sul prodotto e sullo stato di avanzamento del progetto, la retrospective si concentra principalmente sul lavoro di squadra. L'obiettivo di quest’ultima è quello di migliorare la collaborazione ed evitare problemi interni. Non appena uno sprint è terminato, quello successivo ricomincia di nuovo con lo sprint planning.

Gli oggetti che rivestono un ruolo importante in Scrum sono chiamati artefatti e sono il Product Backlog, lo Sprint Backlog e l'Incremento.

In Scrum la trasparenza è un fattore importante. Ogni persona coinvolta deve poter ricevere tutte le informazioni nel modo più semplice possibile in qualsiasi momento. Pertanto, quando si progettano gli artefatti Scrum, si deve fare in modo che questi siano semplici e comprensibili. Il Product Owner è responsabile del Product Backlog: quest'ultimo è un elenco ordinato di tutti i fattori rilevanti per il prodotto. Queste includono sia le funzionalità del prodotto sia le correzioni o i perfezionamenti.

Il lavoro sul Product Backlog è sempre in corso: l'elenco viene gestito in modo dinamico, le nuove scoperte sono integrate in qualsiasi momento e garantiscono una maggiore differenziazione delle voci, l'aggiunta di nuovi compiti e l'adeguamento della cernita. All'inizio, il Product Owner è solitamente assistito dallo Scrum Master. Sulla base della loro esperienza, i master sanno come formulare il documento per soddisfare i requisiti di trasparenza ed efficacia. Le voci devono essere generalmente orientate alle esigenze del cliente. Oltre alla descrizione della caratteristica richiesta, il documento contiene anche una nota sul carico di lavoro e una voce del livello di priorità.

Accanto al Product Backlog c'è lo Sprint Backlog, che viene generato dal primo. Lo Sprint Backlog contiene tutte le voci del Product Backlog selezionate nello sprint planning per lo sprint successivo. Questo backlog rappresenta quindi tutti i passi per raggiungere l’obiettivo. Durante il daily scrum, basandosi sullo sprint backlog si valuta lo stato di avanzamento del lavoro. Anche questo elenco può essere aggiornato nel corso stesso dello sprint per soddisfare le esigenze e le problematiche del team. Pertanto, è responsabilità degli sviluppatori apportare modifiche allo sprint backlog. Né il Product Owner né lo Scrum Master sono autorizzati a modificare l'elenco.

Al termine di uno sprint, il team di sviluppo presenta l'incremento, cioè il risultato della fase di sviluppo. Un incremento dovrebbe contenere tutte le voci dello sprint backlog e tutti gli incrementi degli sprint precedenti. Un incremento dovrebbe potenzialmente poter essere già rilasciabile ed essere pronto all'uso, anche quando non vi è un piano di consegna effettivo. Nella Sprint Review, il team presenta l'incremento in modo tale che il Product Owner e gli stakeholder siano in grado di valutarne il risultato.

Scrum offre alcuni vantaggi, sia rispetto ad altri metodi agili che ai metodi più tradizionali di gestione dei progetti. Questi sono principalmente l'approccio a piccoli passi e il numero limitato di regole che il team Scrum deve rispettare:

• Comunicazione: una buona gestione del progetto può funzionare solo se tutti i membri del team sono allo stesso livello. Scrum attribuisce grande importanza alla comunicazione tra i collaboratori. Pertanto gli eventi Scrum sono decisamente frequenti. L'incontro quotidiano all'inizio della giornata assicura che ogni sviluppatore non interferisca con il lavoro degli altri e nella fase finale vengono affrontati anche i problemi all'interno del team.
• Flessibilità: con Scrum gli sprint sono relativamente brevi. Dal momento che intercorre massimo un mese tra due riunioni di pianificazione, il progetto può essere modificato in breve tempo e adattato alle nuove esigenze.
• Trasparenza: la comunicazione costante tra tutti i membri del team e la progettazione degli artefatti Scrum garantiscono un elevato livello di trasparenza. I backlog sono formulati in modo tale che tutti gli interessati possano orientarsi facilmente e trovare le informazioni necessarie sul progetto.
• Controllo della qualità: il principio iterativo di Scrum assicura un controllo costante del prodotto. Le correzioni vengono apportate sia al Product Backlog che agli aggiornamenti. Durante la Sprint Review, il team di sviluppo presenta inoltre un incremento finito. I Product Backlog e gli stakeholder hanno facoltà di testare la qualità. In questo modo è possibile reagire molto più rapidamente agli errori di sviluppo, evitando di scoprire una funzione difettosa solo quando si è ormai alla fine di un progetto.
• Creatività: Scrum si basa sull'autogestione del team. Invece di dettare il metodo di lavoro dall'alto, gli sviluppatori lavorano mettendo le proprie idee sullo stesso piano. Poiché il framework di Scrum è relativamente aperto e ha poche regole, i singoli membri del team partecipano contribuendo con le proprie idee.
• Efficacia: rispetto alla gestione di progetti tradizionali, Scrum non richiede un'ampia documentazione. L'attenzione si concentra sul prodotto funzionante e non sulla documentazione completa che richiede tempo e risorse. Il team può dunque concentrarsi completamente sul lavoro di sviluppo durante lo sprint ed eseguirlo come meglio crede.

Nonostante questi vantaggi considerevoli, Scrum non si addice ugualmente a tutte le aziende. Vediamo quali sono gli aspetti che lo rendono inadatto in certi contesti aziendali:

• Mancanza di una visione d’insieme: quello che può essere un grande vantaggio per una squadra, è uno svantaggio per l'altra: le fasi di pianificazione molto brevi possono far perdere di vista il quadro generale in progetti più complessi.
• Comunicazione complessa: gli eventi Scrum sono tenuti a cadenza regolare. Tuttavia per alcuni team e in certi progetti un tale livello di comunicazione potrebbe risultare superfluo. In questi casi, i daily scrum tendono a ostacolare la produttività. Troppo tempo viene dedicato all'organizzazione e alla comunicazione piuttosto che al lavoro effettivo sul prodotto.
• Incertezza nella pianificazione e nella responsabilità: Scrum prevede che i team si organizzino da soli. Ciò può essere vantaggioso ma in alcune aree e settori tali gerarchie piatte possono portare a incertezze nella pianificazione e confusione sulle responsabilità.
• Non integrabile: in alcune strutture aziendali non si riesce a integrare facilmente Scrum. In tali casi ci si chiede fino a che punto questo metodo possa essere efficace e produttivo.

Se Scrum si addice alla vostra azienda, sta a voi giudicare e valutare se le gerarchie piatte e la comunicazione regolare dei team Scrum potrebbero portare a un aumento della produttività e a una migliore qualità del lavoro e del prodotto.