Con i ritmi sempre più frenetici dei mercati non ci si può più permettere di lavorare senza una pianificazione dettagliata delle attività che si andranno a svolgere. È necessario prediligere un controllo formale delle stesse attività per poter dare un riscontro effettivo di quanto si è a priori pianificato.
Lo scopo del monitoraggio è quello di evidenziare le deviazioni rispetto al piano di progetto e individuare l’esigenza di possibili azioni correttive prima che la situazione diventi irrecuperabile.
Il controllo dei progetti, nella sua forma tradizionale, avviene attraverso sistemi Waterfall, definiti a cascata (un esempio è il famoso diagramma di Gantt), che richiedono in genere interi gruppi di progetto per incontrarsi e discutere gli obiettivi in tutte le fasi. Il fine ultimo di questa attività è quello di:
- evitare che le tempistiche di progetto richieste dal cliente non vengano rispettate;
- monitorare l’assegnamento delle risorse;
- controllare il raggiungimento degli obiettivi.
Con l’aumento della complessità dello sviluppo prodotti e di implementazione di nuove tecnologie, attività che oggi avviene con estrema velocità, rispettare tali vincoli è diventato sempre più difficile per le aziende.
Questo è uno dei motivi per cui si sono diffusi modelli di agile project management che hanno permesso di raggiungere obiettivi di qualità, con meno dispendio di risorse economiche e temporali.
Mi sto riferendo in particolare al metodo SCRUM: in sostanza, si tratta di un sistema che è stato messo a punto per gestire progetti la cui componente tecnologica (sviluppo di software) è rilevante, anche se oggi si è espanso nei settori più disparati quali l’istruzione, l’esercito e l’industria automobilistica.
Tuttavia, prima di addentrarci nella metodologia scrum, vediamo da dove nasce e a cosa serve.
Da dove nasce Scrum
Nonostante non ci sia l’unanimità tra i ricercatori di chi abbia creato il metodo accennato, è possibile affermare che le radici di Scrum si fondino nel pensiero giapponese.
I primi concetti del metodo furono elaborati dai professori giapponesi Hirotaka Takeuchi e Ikujiro Nonaka nella loro pubblicazione “The New Product Development Game” (1986).
Successivamente Jeff Sutherland e Ken Schwaber misero in pratica, raffinarono tali concetti e produssero nel 1995 un articolo che codificava queste pratiche. Gli fu assegnato il nome Scrum: Il termine deriva dal rugby e si riferisce al modo in cui il team lavora collettivamente per muovere la palla sul campo.
La motivazione del nome probabilmente è dovuta al fatto che “i professori giapponesi paragonavano il lavoro dei team a quello di una squadra di rugby e affermavano che i migliori agivano come se si trovassero in una mischia: .. la palla viene passata all’interno del team mentre questo si muove come un’entità unica sul campo” [Fare il doppio in metà del tempo. Puntare al successo con il metodo Scrum – Jeff Sutherland ]
Da allora, si è esteso nelle realtà aziendali soprattutto in area di software management e sviluppo di prodotto.
A cosa serve Scrum
Quando si parla di Scrum, solitamente si fa riferimento ad un sistema agile di project management. Perciò è bene fare una breve introduzione di tali metodologie, per comprendere meglio l’utilizzo di tali tecniche.
Agile è un processo iterativo che è stato inizialmente discusso in profondità negli anni ’70 da William Royce e ripreso recentemente, nel 2001, da 17 sviluppatori di software che hanno elaborato il manifesto agile. Esso include i 12 principi per guidare un approccio iterativo e incentrato sulle persone allo sviluppo del software.
Un sistema agile non si applica solo al mondo del software. Fondamentalmente, si focalizza sul valore del cliente, sull’interazione del team rispetto alle attività e sull’adattamento alla realtà aziendale attuale anziché seguire un piano prestabilito.
Praticamente Scrum serve per gestire i progetti in maniera agile.
Si basa sull’utilizzo di gruppi più focalizzati e piccoli che si incontrano con maggiore frequenza per discutere obiettivi molto specifici. In questo modo risulta più semplice apportare modifiche rapide come richiesto e consente ai team di essere più efficaci e veloci.
Il vantaggio fondamentale è che tale metodologia aumenta le possibilità di raggiungere gli obiettivi dei clienti con successo, soprattutto in considerazione del fatto che anche le esigenze dei clienti potrebbero cambiare.
Questa metodologia ha costantemente contribuito a migliorare l’organizzazione, la collaborazione e la comunicazione, spesso con il risultato di un prodotto finito di qualità più elevata e di una migliore soddisfazione generale del team di progetto.
Vediamo ora come il metodo scrum viene utilizzato.
Come funziona Scrum
La metodologia Scrum può essere implementata come segue.
Il primo passo da fare risulta quello di nominare il Product Owner.
Solitamente è colui che conosce i risultati che si vogliono ottenere, ossia l’output del progetto. Potrebbe essere il proprietario dell’azienda, i clienti o gli utenti finali, ma avrà la visione per far sì che il team costruisca il prodotto giusto.
Successivamente è bene creare il Team, composto dalle persone che svolgeranno fisicamente il lavoro. Fondamentale che il team sia piccolo (non più di 9 membri. Ti dice qualcosa? 😉 ). Non prevede le figure tradizionali (analista, programmatore, ecc.) ma una serie di nuovi ruoli ben definiti, che collaborano nel cercare di soddisfare tutte le richieste dell’utente.
Contemporaneamente alla definizione del team, occorre nominare uno Scrum Master: non è altro che la persona incaricata di rimuovere gli ostacoli e che guiderà il team nell’applicazione del metodo.
Lo Scrum Master aiuta il team a rimanere concentrato sulle attività da compiere: il suo ruolo è di insegnare e motivare, e dare l’esempio al team.
Dopodiché occorre individuare le attività da eseguire e ordinarle per priorità in quello che si definisce Product Backlog, ossia la mappa da seguire per realizzare la costruzione di un prodotto. Esso varia in continuazione, proprio per permettere modifiche in corso d’opera da parte della clientela.
Le priorità sono definite dal Product Owner, il quale dovrebbe avere consenso dal team e dagli stakeholder, in modo da procedere secondo quanto si vuole davvero realizzare.
Arrivati a questo punto cosa manca? Sicuramente un’attività fondamentale è quella della stima della durata delle attività. Si potrebbe pensare di usare come stima le ore, ma non rende bene l’idea di lavoro da fare.
Perciò, come suggerisce Jeff Sutherland, utilizzate la sequenza di Fibonacci per indicare la grandezza di un’attività. Ciò può essere fatto assegnando ad ogni attività un numero appartenente alla serie di Fibonacci, che ne rappresenti indicativamente una stima di durata.
Per chi non lo sapesse la serie di Fibonacci è composta dai seguenti numeri:
1 , 2 , 3 , 5 , 8 , 13 , 21 , 34 , 55 , 89 , 144 , 233 , 377 , ….
dove ogni numero della successione si ottiene prendendo la somma dei due che lo precedono (con l’esclusione dei primi due).
In questo modo, risulta più semplice cogliere la deviazione di durata tra un’attività e un’altra. Ipotizza che un’attività sia stimata a 8 e una a 13: è chiara immediatamente la differenza. Viceversa è piuttosto sottile la distinzione del nostro cervello da un 8 a un 9, giusto per fare un esempio.
Non è finita qui: in scrum occorre pianificare lo Sprint.
Lo sprint rappresenta un periodo di tempo, di solito un mese o due settimane, nel quale vengono svolte le attività inserite nel Product Backlog in base alla priorità. In questa fase viene definito lo Spring Backlog, ossia la lista delle attività codificate dal team che devono essere completate entro la fine dello Sprint.
Inizialmente lo sprint è pianificato dal Product Owner, dallo Scrum Master e dal team. Essi decidono quante attività si possono svolgere durante uno sprint e ne calcolano la velocità determinandone un punteggio. La velocità dipende da quante attività vengono svolte in uno sprint, nonché dalla loro durata temporale.
Nell’implementazione di un metodo Scrum è importante non dimenticarsi del Daily Scrum, un breve incontro giornaliero della durata di quindici minuti che consente al team di sviluppo di pianificare i prossimi giorni di lavoro.
Il Daily Scrum è un’opportunità per rivedere dove si trova la squadra in relazione all’obiettivo generale di sprint.
Il team esamina il lavoro che è stato completato nel giorno precedente e prevede cosa si possa ottenere nelle prossime ventiquattro ore rispondendo alle seguenti domande:
- Cosa avete fatto ieri per aiutare il team a portare a termine lo sprint?
- Cosa farete oggi per aiutare il team a portare a termine lo sprint?
- C’è qualche ostacolo che impedisce di raggiungere l’obiettivo dello sprint?
Al termine dei vari Sprint si fa una riunione che viene definita Sprint Review, dove si stabilisce a chiunque voglia partecipare cosa è stato portato a termine e cosa no.
Successivamente parte il nuovo Sprint, che comprenderà altre attività pianificate sempre ordinate per priorità. E così via finché non si terminano tutti gli Sprint (e di conseguenza le attività) e si raggiunge l’obiettivo di progetto.
Infine, si definisce la Sprint Retrospective, con lo scopo di dimostrare cosa è stato portato a termine nell’ultimo sprint e per effettuare le ultime valutazioni sul progetto concluso.
Per un maggior approfondimento della tecnica, consiglio la lettura del libro “Fare il doppio in metà del tempo. Puntare al successo con il metodo Scrum” – Jeff Sutherland, o se hai familiarità con l’inglese puoi visitare questo sito, che spiega le guide linea da seguire per adottare la metodologia descritta.
