Scrum: gestione di progetto agile, moderna e fles­si­bi­le

Quando i team iniziano a lavorare a un progetto, le pro­ble­ma­ti­che da valutare sono molte. Spe­cial­men­te gli ordini più grandi ri­chie­do­no un progetto fun­zio­nan­te o un sistema di gestione del prodotto. At­tual­men­te sono sempre di più le aziende che scelgono le procedure agili. L'at­ten­zio­ne si concentra su metodi di lavoro fles­si­bi­li, sviluppi in­cre­men­ta­li e processi tra­spa­ren­ti. Nel­l'am­bi­to della gestione agile dei progetti, anche il termine "Scrum" sta di­ven­tan­do sempre più comune. Ori­gi­na­ria­men­te destinato allo sviluppo software, questo approccio adesso è co­no­sciu­to in molti altri settori. In questo articolo vi spie­ghia­mo cosa si nasconde esat­ta­men­te dietro a questa parola così in voga.

L’origine di Scrum risale agli anni '80, anche se nella sua forma attuale è in cir­co­la­zio­ne solo dal 1995. In quel­l'an­no Ken Schwaber e Jeff Su­ther­land, che in origine avevano entrambi usato, ciascuno nella propria azienda, modelli simili, pub­bli­ca­ro­no un documento comune. Il loro obiettivo era quello di rendere il lavoro più pro­dut­ti­vo e allo stesso tempo in­tro­dur­re il minor numero possibile di regole, in modo tale da non limitare la pro­dut­ti­vi­tà.

Per questo Scrum sta­bi­li­sce un quadro (framework) che può essere applicato a si­tua­zio­ni diverse e che ha lo scopo di ot­ti­miz­za­re tanto il metodo di lavoro quanto il prodotto. Nel framework vengono definiti ruoli, eventi, artefatti e regole. In questo contesto i team Scrum do­vreb­be­ro rag­giun­ge­re i risultati nel modo più ef­fi­cien­te possibile, offrendo al cliente il miglior prodotto possibile. Pertanto, clienti, com­mit­ten­ti e utenti ricoprono una posizione im­por­tan­te 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 con­ti­nua­men­te ag­gior­na­to. Il lavoro può essere descritto come una sorta di cerchio che parte dalla pia­ni­fi­ca­zio­ne, passa per lo sviluppo e i test, fino ad arrivare alla va­lu­ta­zio­ne e, dunque, ripartire con una nuova fase di pia­ni­fi­ca­zio­ne. In tal modo Scrum non guarda soltanto alla pro­du­zio­ne iniziale ma anche agli ag­gior­na­men­ti suc­ces­si­vi.
• In­cre­men­ta­le: 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 im­por­tan­te obiettivo finale. I grandi progetti vengono suddivisi in progetti più piccoli, con­ser­van­do una fles­si­bi­li­tà più elevata.

Un approccio iterativo-in­cre­men­ta­le, che dunque combina i due aspetti, fa sì che lo sviluppo avvenga secondo un processo pro­gres­si­vo e continuo. Da un lato, il processo di sviluppo è molto più tra­spa­ren­te, in quanto vengono pia­ni­fi­ca­ti controlli più frequenti del lavoro (risultato del­l'ap­proc­cio a piccoli passi) e dal­l'al­tro si ottimizza la qualità del prodotto, in quanto la sua fun­zio­na­li­tà viene co­stan­te­men­te con­trol­la­ta.

Scrum nasce ori­gi­na­ria­men­te per lo sviluppo agile del software, fi­na­liz­za­to all’ot­ti­miz­za­zio­ne continua del lavoro sui programmi. Ma Scrum è diventato un modello efficace anche per altri prodotti, ad esempio per la pro­du­zio­ne di hardware. Un progetto Scrum non deve ne­ces­sa­ria­men­te terminare con un prodotto nel vero senso della parola: qualsiasi progetto orientato ai risultati può infatti trarre vantaggio da questo tipo di approccio. Ap­pli­ca­zio­ni dei principi Scrum si trovano ad esempio nel­l'or­ga­niz­za­zio­ne di team di marketing o enti am­mi­ni­stra­ti­vi, nonché nello sviluppo di servizi.

Il metodo Scrum pre­sup­po­ne piccoli gruppi di lavoro, anche se "piccolo" è un termine piuttosto relativo: per i grandi gruppi di lavoro il modello fles­si­bi­le rimane comunque meno indicato. Spesso è possibile sud­di­vi­de­re un grande gruppo in squadre più piccole. Scrum è ideale anche quando i team co­mu­ni­ca­no tra loro in rete. Il lavoro di squadra ha un valore si­gni­fi­ca­ti­vo in questo modello: al­l'in­ter­no di un team Scrum, i singoli membri do­vreb­be­ro com­ple­tar­si a vicenda, ciascuno con le proprie com­pe­ten­ze.

Scrum non va con­si­de­ra­to un metodo fisso o una tecnica di lavoro concreta, ma piuttosto un framework che offre ai team dei saldi punti di ri­fe­ri­men­to per il loro lavoro. In questo framework rientrano de­ter­mi­na­ti ruoli, eventi e artefatti.

Al­l'in­ter­no di un team Scrum ci sono tre ruoli fissi: il Team, il Product Owner e lo Scrum Master. Il team è il vero e proprio svi­lup­pa­to­re del prodotto. Il gruppo è or­ga­niz­za­to in modo da potersi au­to­ge­sti­re e sta­bi­li­sce in che modo rag­giun­ge­re un obiettivo con­cor­da­to. Al­l'in­ter­no di un team Scrum non esistono gerarchie. Va da sé che ogni di­pen­den­te ha la propria area di re­spon­sa­bi­li­tà ma nella revisione finale tutti insieme devono rendere conto del prodotto.

La di­men­sio­ne della squadra non è standard: il team viene formato perché possa lavorare in modo rapido e fles­si­bi­le, rimanendo sempre ef­fi­cien­te. Quindi né troppo grande né troppo piccolo. Schwaber e Su­ther­land pro­pon­go­no gruppi composti dai 3 ai 9 membri.

In Scrum, il Product Owner è re­spon­sa­bi­le della qualità del prodotto e del lavoro e assume dunque la funzione di su­per­vi­so­re. I Product Owner or­ga­niz­za­no il Product Backlog, cioè un elenco che definisce i requisiti del progetto (troverete maggiori in­for­ma­zio­ni sul Product Backlog al paragrafo "artefatti su Scrum"). Tra i suoi compiti c'è anche quello di ordinare gli obiettivi secondo una logica si­gni­fi­ca­ti­va e do­cu­men­tar­li in modo com­pren­si­bi­le. Il Product Owner ha un ruolo au­to­ri­ta­rio: anche se di fatto sono i team a stabilire come rag­giun­ge­re gli obiettivi formulati nel backlog, la de­ter­mi­na­zio­ne di questi è a di­scre­zio­ne del Product Owner. Nessuno può mettere in dubbio le sue decisioni: per garantire la massima pro­dut­ti­vi­tà, 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 re­spon­sa­bi­li­tà diverse e hanno potere de­ci­sio­na­le re­la­ti­va­men­te a queste. Così come il team non deve mettere in di­scus­sio­ne il backlog, il Product Owner non deve in­ter­fe­ri­re con il processo di sviluppo.

Rispetto agli altri due ruoli, lo Scrum Master agisce come una sorta di mediatore. Lo Scrum Master è re­spon­sa­bi­le del­l'in­te­gra­zio­ne e del­l'ap­pli­ca­zio­ne del metodo Scrum nel flusso di lavoro. Questo significa che tale ruolo è re­spon­sa­bi­le del­l'or­ga­niz­za­zio­ne degli eventi su Scrum: determina gli incontri e li modera. Inoltre, lo Scrum Master fornisce as­si­sten­za al team e al Product Owner. Tuttavia, non in­ter­vie­ne mai nel processo di sviluppo vero e proprio. La sua funzione è puramente quella di sem­pli­fi­ca­re i processi di lavoro nei confronti dei col­la­bo­ra­to­ri coinvolti nella pro­du­zio­ne, in­cre­men­tan­do così la pro­dut­ti­vi­tà e la crea­ti­vi­tà.

In qualità di referente, lo Scrum Master si assicura che tutte le parti coinvolte com­pren­da­no cor­ret­ta­men­te i processi: fornisce consigli sulla creazione di backlog o sul­l'or­ga­niz­za­zio­ne della squadra e aiuta a fron­teg­gia­re le dif­fi­col­tà. Lo Scrum Master ha tra le sue varie funzioni anche il ruolo di coach; per questo è fon­da­men­ta­le una co­no­scen­za ap­pro­fon­di­ta di Scrum. Per questo motivo è anche possibile ottenere la cer­ti­fi­ca­zio­ne per diventare Scrum Master. At­tual­men­te esistono diversi organismi di cer­ti­fi­ca­zio­ne che offrono anche corsi di for­ma­zio­ne in merito. Sia la Scrum Alliance che Scrum.org sono stati fondati da Ken Schwaber e per­met­to­no di ottenere i cer­ti­fi­ca­ti "Certified Scrum Master" e "Pro­fes­sio­nal Scrum Master".

Se si or­ga­niz­za­no processi di lavoro secondo il principio di Scrum, alcuni eventi si ve­ri­fi­ca­no re­go­lar­men­te. Poiché Scrum è un processo iterativo, il lavoro viene svolto in cicli ri­pe­ti­ti­vi: ogni evento si svolge nuo­va­men­te a ogni ri­pe­ti­zio­ne. La frequenza degli eventi su Scrum fa sì che le riunioni straor­di­na­rie siano piuttosto rare. Inoltre, tutti gli eventi hanno un ca­len­da­rio 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 in­cre­men­to del prodotto finito. Ciò significa che lo sviluppo deve portare a un prodotto che potrebbe essere po­ten­zial­men­te con­se­gna­to. Così ogni sprint ha una missione concreta, che alla fine viene indicata come "fatta". L'arco di tempo dello sprint viene pre­sta­bi­li­to ma non deve superare i 30 giorni. Nella de­ter­mi­na­zio­ne del periodo di tempo occorre tenere presente che uno sprint non può essere né pro­lun­ga­to né ab­bre­via­to e gli sprint suc­ces­si­vi del progetto do­vreb­be­ro avere tutti la stessa durata.

Gli sprint devono essere brevi affinché la for­mu­la­zio­ne degli obiettivi non diventi troppo com­pli­ca­ta. La breve durata permette inoltre di con­trol­la­re lo sviluppo almeno una volta al mese. Solo in pochi casi ec­ce­zio­na­li il Product Owner (e lui soltanto) può annullare uno sprint, ad esempio quando l'o­biet­ti­vo non deve più essere raggiunto perché l'azienda ha una finalità diversa. In linea di principio gli sprint non do­vreb­be­ro essere in­ter­rot­ti perché ciò riduce no­te­vol­men­te la pro­dut­ti­vi­tà.

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 par­te­ci­pan­ti discutono sul­l'in­cre­men­to del prodotto imminente: cosa dovrebbe essere incluso nel­l'in­cre­men­to e come si vuole rag­giun­ge­re il risultato? Il punto di partenza per la pia­ni­fi­ca­zio­ne è il Product Backlog. Il team di sviluppo e il Product Owner si mettono d'accordo su quali obiettivi rag­giun­ge­re nel mese suc­ces­si­vo. Il team di sviluppo discute poi su come devono essere svolti i compiti. Alla fine del­l'in­con­tro, gli svi­lup­pa­to­ri do­vreb­be­ro essere in grado di discutere il loro piano con il Product Owner e lo Scrum Master.

Al­l'in­ter­no dello sprint, ogni giorno si svolge un Daily Scrum, sempre nello stesso orario e luogo, perché più semplice dal punto di vista or­ga­niz­za­ti­vo. 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 pre­ce­den­te. Gli svi­lup­pa­to­ri valutano anche il progresso com­ples­si­vo del progetto: a che punto delle voci del backlog sono arrivati? Il confronto quo­ti­dia­no assicura che tutte le persone coinvolte non perdano di vista gli obiettivi, il che, in ultima analisi, aumenta anche la pro­dut­ti­vi­tà.

Lo Scrum Master si assicura che ogni giorno si svolga un Daily Scrum ma i pro­ta­go­ni­sti del­l'in­con­tro sono gli svi­lup­pa­to­ri, che de­ter­mi­na­no quali argomenti vengono discussi. Finché il contenuto riguarda il rag­giun­gi­men­to del­l'o­biet­ti­vo dello sprint e i 15 minuti non vengono superati, lo Scrum Master non in­ter­vie­ne. Inoltre ga­ran­ti­sce che gli altri par­te­ci­pan­ti al Daily Scrum non di­stur­bi­no il lavoro degli svi­lup­pa­to­ri.

Quando uno sprint è terminato, segue una Sprint Review: l'in­cre­men­to del prodotto viene con­trol­la­to. I risultati vengono valutati insieme alle persone che non fanno parte del team Scrum, ma che hanno un interesse im­por­tan­te per il prodotto, come i pro­prie­ta­ri del­l'a­zien­da o i clienti (col­let­ti­va­men­te chiamati sta­ke­hol­der). Si discute anche del processo di lavoro in quanto tale, si af­fron­ta­no i problemi di sviluppo e si discutono le criticità. Questo ha un'in­fluen­za anche sulla pia­ni­fi­ca­zio­ne suc­ces­si­va, perché il Product Owner sfrutta l'op­por­tu­ni­tà di discutere l’avan­za­men­to del backlog. I risultati dello sprint in­fluen­za­no le pre­vi­sio­ni sulle per­for­man­ce future.

Anche la ri­spet­ti­va si­tua­zio­ne di mercato influisce sul backlog: in par­ti­co­la­re nei progetti a lungo termine, le priorità possono mutare nel tempo e i budget possono cambiare. Nella sprint review sono presi in con­si­de­ra­zio­ne anche questi argomenti, che cambiano l'ap­proc­cio futuro. In uno sprint mensile, la review non dovrebbe durare oltre quattro ore.

La sprint review è seguita da un'ul­te­rio­re fase: la Sprint Re­tro­spec­ti­ve. L'intero team Scrum (compresi il Product Owner e lo Scrum Master, ma esclusi gli sta­ke­hol­der) viene riunito per un giro di feedback in una riunione che non supera le tre ore. Mentre la review si concentra prin­ci­pal­men­te sul prodotto e sullo stato di avan­za­men­to del progetto, la re­tro­spec­ti­ve si concentra prin­ci­pal­men­te sul lavoro di squadra. L'o­biet­ti­vo di quest’ultima è quello di mi­glio­ra­re la col­la­bo­ra­zio­ne ed evitare problemi interni. Non appena uno sprint è terminato, quello suc­ces­si­vo ri­co­min­cia di nuovo con lo sprint planning.

Gli oggetti che rivestono un ruolo im­por­tan­te in Scrum sono chiamati artefatti e sono il Product Backlog, lo Sprint Backlog e l'In­cre­men­to.

In Scrum la tra­spa­ren­za è un fattore im­por­tan­te. Ogni persona coinvolta deve poter ricevere tutte le in­for­ma­zio­ni nel modo più semplice possibile in qualsiasi momento. Pertanto, quando si pro­get­ta­no gli artefatti Scrum, si deve fare in modo che questi siano semplici e com­pren­si­bi­li. Il Product Owner è re­spon­sa­bi­le del Product Backlog: que­st'ul­ti­mo è un elenco ordinato di tutti i fattori rilevanti per il prodotto. Queste includono sia le fun­zio­na­li­tà del prodotto sia le cor­re­zio­ni o i per­fe­zio­na­men­ti.

Il lavoro sul Product Backlog è sempre in corso: l'elenco viene gestito in modo dinamico, le nuove scoperte sono integrate in qualsiasi momento e ga­ran­ti­sco­no una maggiore dif­fe­ren­zia­zio­ne delle voci, l'ag­giun­ta di nuovi compiti e l'a­de­gua­men­to della cernita. Al­l'i­ni­zio, il Product Owner è so­li­ta­men­te assistito dallo Scrum Master. Sulla base della loro espe­rien­za, i master sanno come formulare il documento per sod­di­sfa­re i requisiti di tra­spa­ren­za ed efficacia. Le voci devono essere ge­ne­ral­men­te orientate alle esigenze del cliente. Oltre alla de­scri­zio­ne della ca­rat­te­ri­sti­ca 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 se­le­zio­na­te nello sprint planning per lo sprint suc­ces­si­vo. Questo backlog rap­pre­sen­ta quindi tutti i passi per rag­giun­ge­re l’obiettivo. Durante il daily scrum, basandosi sullo sprint backlog si valuta lo stato di avan­za­men­to del lavoro. Anche questo elenco può essere ag­gior­na­to nel corso stesso dello sprint per sod­di­sfa­re le esigenze e le pro­ble­ma­ti­che del team. Pertanto, è re­spon­sa­bi­li­tà degli svi­lup­pa­to­ri apportare modifiche allo sprint backlog. Né il Product Owner né lo Scrum Master sono au­to­riz­za­ti a mo­di­fi­ca­re l'elenco.

Al termine di uno sprint, il team di sviluppo presenta l'in­cre­men­to, cioè il risultato della fase di sviluppo. Un in­cre­men­to dovrebbe contenere tutte le voci dello sprint backlog e tutti gli in­cre­men­ti degli sprint pre­ce­den­ti. Un in­cre­men­to dovrebbe po­ten­zial­men­te poter essere già ri­la­scia­bi­le ed essere pronto all'uso, anche quando non vi è un piano di consegna effettivo. Nella Sprint Review, il team presenta l'in­cre­men­to in modo tale che il Product Owner e gli sta­ke­hol­der siano in grado di valutarne il risultato.

Scrum offre alcuni vantaggi, sia rispetto ad altri metodi agili che ai metodi più tra­di­zio­na­li di gestione dei progetti. Questi sono prin­ci­pal­men­te l'ap­proc­cio a piccoli passi e il numero limitato di regole che il team Scrum deve ri­spet­ta­re:

• Co­mu­ni­ca­zio­ne: una buona gestione del progetto può fun­zio­na­re solo se tutti i membri del team sono allo stesso livello. Scrum at­tri­bui­sce grande im­por­tan­za alla co­mu­ni­ca­zio­ne tra i col­la­bo­ra­to­ri. Pertanto gli eventi Scrum sono de­ci­sa­men­te frequenti. L'in­con­tro quo­ti­dia­no al­l'i­ni­zio della giornata assicura che ogni svi­lup­pa­to­re non in­ter­fe­ri­sca con il lavoro degli altri e nella fase finale vengono af­fron­ta­ti anche i problemi al­l'in­ter­no del team.
• Fles­si­bi­li­tà: con Scrum gli sprint sono re­la­ti­va­men­te brevi. Dal momento che in­ter­cor­re massimo un mese tra due riunioni di pia­ni­fi­ca­zio­ne, il progetto può essere mo­di­fi­ca­to in breve tempo e adattato alle nuove esigenze.
• Tra­spa­ren­za: la co­mu­ni­ca­zio­ne costante tra tutti i membri del team e la pro­get­ta­zio­ne degli artefatti Scrum ga­ran­ti­sco­no un elevato livello di tra­spa­ren­za. I backlog sono formulati in modo tale che tutti gli in­te­res­sa­ti possano orien­tar­si fa­cil­men­te e trovare le in­for­ma­zio­ni ne­ces­sa­rie sul progetto.
• Controllo della qualità: il principio iterativo di Scrum assicura un controllo costante del prodotto. Le cor­re­zio­ni vengono apportate sia al Product Backlog che agli ag­gior­na­men­ti. Durante la Sprint Review, il team di sviluppo presenta inoltre un in­cre­men­to finito. I Product Backlog e gli sta­ke­hol­der hanno facoltà di testare la qualità. In questo modo è possibile reagire molto più ra­pi­da­men­te agli errori di sviluppo, evitando di scoprire una funzione difettosa solo quando si è ormai alla fine di un progetto.
• Crea­ti­vi­tà: Scrum si basa sul­l'au­to­ge­stio­ne del team. Invece di dettare il metodo di lavoro dall'alto, gli svi­lup­pa­to­ri lavorano mettendo le proprie idee sullo stesso piano. Poiché il framework di Scrum è re­la­ti­va­men­te aperto e ha poche regole, i singoli membri del team par­te­ci­pa­no con­tri­buen­do con le proprie idee.
• Efficacia: rispetto alla gestione di progetti tra­di­zio­na­li, Scrum non richiede un'ampia do­cu­men­ta­zio­ne. L'at­ten­zio­ne si concentra sul prodotto fun­zio­nan­te e non sulla do­cu­men­ta­zio­ne completa che richiede tempo e risorse. Il team può dunque con­cen­trar­si com­ple­ta­men­te sul lavoro di sviluppo durante lo sprint ed eseguirlo come meglio crede.

No­no­stan­te questi vantaggi con­si­de­re­vo­li, Scrum non si addice ugual­men­te 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 svan­tag­gio per l'altra: le fasi di pia­ni­fi­ca­zio­ne molto brevi possono far perdere di vista il quadro generale in progetti più complessi.
• Co­mu­ni­ca­zio­ne complessa: gli eventi Scrum sono tenuti a cadenza regolare. Tuttavia per alcuni team e in certi progetti un tale livello di co­mu­ni­ca­zio­ne potrebbe risultare superfluo. In questi casi, i daily scrum tendono a osta­co­la­re la pro­dut­ti­vi­tà. Troppo tempo viene dedicato al­l'or­ga­niz­za­zio­ne e alla co­mu­ni­ca­zio­ne piuttosto che al lavoro effettivo sul prodotto.
• In­cer­tez­za nella pia­ni­fi­ca­zio­ne e nella re­spon­sa­bi­li­tà: Scrum prevede che i team si or­ga­niz­zi­no da soli. Ciò può essere van­tag­gio­so ma in alcune aree e settori tali gerarchie piatte possono portare a in­cer­tez­ze nella pia­ni­fi­ca­zio­ne e con­fu­sio­ne sulle re­spon­sa­bi­li­tà.
• Non in­te­gra­bi­le: in alcune strutture aziendali non si riesce a integrare fa­cil­men­te Scrum. In tali casi ci si chiede fino a che punto questo metodo possa essere efficace e pro­dut­ti­vo.

Se Scrum si addice alla vostra azienda, sta a voi giudicare e valutare se le gerarchie piatte e la co­mu­ni­ca­zio­ne regolare dei team Scrum po­treb­be­ro portare a un aumento della pro­dut­ti­vi­tà e a una migliore qualità del lavoro e del prodotto.