Eventi utilizzati in Scrum per il successo di un progetto

Gli Eventi Scrum: Propulsori del Successo nei Progetti

Nel panorama dello sviluppo software agile, Scrum si distingue come metodologia strutturata e ricca di eventi cadenzati. Questi eventi, definiti “time-box”, hanno una durata prestabilita volta a massimizzare l’efficienza e a ridurre al minimo sprechi di tempo.

Oltre allo Sprint, che rappresenta il contenitore di tutti gli altri eventi, Scrum definisce specifici momenti di ispezione e adattamento, garantendo trasparenza e favorendo un continuo miglioramento.

Caratteristiche degli Eventi Scrum:

Durata Massima: Ogni evento Scrum ha una durata massima per evitare dilatazioni e dispersioni di focus.
Ispezione e Adattamento: Gli eventi sono strutturati per facilitare l’analisi del lavoro svolto e l’identificazione di aree su cui intervenire per ottimizzare il processo.
Trasparenza: La cadenza regolare degli eventi favorisce la condivisione di informazioni e la collaborazione tra tutti gli stakeholder.

I Cinque Pilastri:

Sprint: Unità base dello sviluppo Scrum, con durata variabile da una a quattro settimane. Ogni Sprint è caratterizzato da un obiettivo specifico (Sprint Goal) e da un piano di lavoro definito durante il Sprint Planning. Al termine dello Sprint, il team consegna un incremento funzionante del prodotto.
Sprint Planning: Incontro di pianificazione della durata massima di otto ore, dove si definiscono gli obiettivi dello Sprint e si selezionano gli elementi del Product Backlog da implementare. Il Product Owner, il Scrum Master e il Development Team collaborano per stimare il lavoro e creare lo Sprint Backlog.
Daily Scrum: Riunione quotidiana di massimo 15 minuti, dove ogni membro del Development Team condivide i propri progressi, i potenziali ostacoli e il piano per la giornata successiva. Il Daily Scrum favorisce la comunicazione, la risoluzione di problemi e l’allineamento del team.
Sprint Review: Incontro di massimo 4 ore al termine dello Sprint, dove si presenta il lavoro completato agli stakeholder. Il Product Owner spiega le funzionalità implementate, il Development Team dimostra il prodotto incrementato e si raccolgono feedback per migliorare il Product Backlog.
Sprint Retrospective: Incontro di massimo 3 ore dopo la Sprint Review, dove il Scrum Team riflette sul Sprint appena concluso. Si analizzano i punti di forza e di debolezza, si identificano aree di miglioramento e si definiscono azioni concrete da implementare nel successivo Sprint.

Cancellazione dello Sprint:

In casi eccezionali, lo Sprint può essere cancellato prima del termine se il Sprint Goal diviene obsoleto. La decisione spetta al Product Owner, che può agire anche su suggerimento degli stakeholder, del Development Team o dello Scrum Master. Le cancellazioni, tuttavia, sono rare a causa del loro impatto sul processo e sulla motivazione del team.

Vantaggi degli Eventi Scrum:

Maggiore Predicibilità: Gli Sprint regolari garantiscono una cadenza definita per il rilascio di nuove funzionalità.
Riduzione del Rischio: Limitando il lavoro a un mese, si riducono i rischi associati a cambiamenti di rotta o imprevisti.
Miglioramento Continuo: Le ispezioni e gli adattamenti favoriscono un apprendimento continuo e un’ottimizzazione costante del processo.
Aumento della Motivazione: Il coinvolgimento del team nella pianificazione e il ritmo cadenzato degli eventi mantengono alta la motivazione e la focalizzazione.
Trasparenza e Collaborazione: Gli eventi favoriscono la condivisione di informazioni, la collaborazione tra i team e l’allineamento con gli stakeholder.

Conclusione:

Gli eventi Scrum rappresentano la spina dorsale della metodologia, strutturando il lavoro in maniera efficiente, favorendo la trasparenza e promuovendo un ciclo continuo di miglioramento. La cadenza regolare degli eventi e la loro focalizzazione su ispezione e adattamento rendono Scrum un metodo efficace per il raggiungimento del successo nei progetti di sviluppo software.

Eventi in Scrum per il successo di un progetto

Lo Sprint

Lo Sprint è un’unità di base dello sviluppo in Scrum ed è di durata fissa, generalmente da una a quattro settimane. Ogni Sprint è preceduto da una riunione di pianificazione in cui vengono identificati gli obbiettivi e vengono stimati i tempi. Durante uno Sprint non è permesso cambiare gli obiettivi, quindi le modifiche sono sospese fino alla successiva riunione di pianificazione, in cui potranno essere inserite nel prossimo sprint. Ogni Sprint può essere considerato un progetto con un orizzonte non più lungo di un mese. Come i progetti, gli Sprint sono utilizzabili per realizzare qualcosa. Ogni Sprint ha una definizione di ciò che si va a costruire, un progetto e un piano flessibile che guideranno la costruzione, il lavoro svolto e il prodotto risultante.

Al termine di ogni Sprint il team di sviluppo consegna una versione potenzialmente completa e funzionante del prodotto, contenente gli avanzamenti decisi nella riunione di pianificazione dello sprint. Gli Sprint migliorano la prevedibilità, assicurando che l’ispezione e l’adattamento del progresso verso un obiettivo sono effettuati almeno una volta al mese. Gli Sprint inoltre limitano il rischio ad un mese di costo.

Lo Sprint consiste e contiene lo Sprint Planning, il Daily Scrum, il lavoro di sviluppo, la Sprint Review e la Sprint Retrospective.
Uno Sprint può essere cancellato prima della scadenza del tempo massimo stabilito se lo Sprint Goal diventa obsoleto: questo potrebbe verificarsi se l’organizzazione cambia direzione o se le condizioni di mercato o della tecnologia cambiano. Solo il Product Owner ha l’autorità di annullare lo Sprint, anche se può farlo anche sotto l’influenza degli stakeholder, del Team di Sviluppo o dello Scrum Master. Le cancellazioni degli Sprint consumano risorse, poiché tutti devono partecipare di nuovo ad un altro Sprint Planning Meeting per poterne cominciare un altro; per questo motivo sono molto rare.

Sprint Planning

Il meeting di Sprint Planning è un incontro della durata massima di otto ore per uno Sprint di un mese. Durante questo meeting lo Scrum Master, il Product Owner e il Team si riuniscono per determinare su quali funzionalità del prodotto il team dovrà lavorare.

L’input per questo incontro sono il Product Backlog, l’ultimo incremento del prodotto (somma di tutti gli elementi del Product Backlog completati durante uno Sprint), la previsione di capacità del Team di Sviluppo durante lo Sprint e le performance registrate in passato del Team di Sviluppo. Il numero di elementi selezionati dal Product Backlog per lo Sprint è definito esclusivamente dal Team di Sviluppo. Soltanto il Team di Sviluppo è in grado di valutare cosa può compiere durante il prossimo Sprint. Dopo che il Team di Sviluppo ha previsto gli elementi del Product Backlog che consegnerà con lo Sprint, lo Scrum Team modella lo Sprint Goal.

Lo Sprint Goal è l’obiettivo selezionato per lo Sprint che può essere raggiunto attraverso l’implementazione del Product Backlog. Esso fornisce una guida al Team di Sviluppo sul perché stia costruendo l’incremento. Lo Sprint Goal può creare quella coerenza nel lavoro del Team di Sviluppo che non sarebbe invece presente attraverso iniziative individuali senza un obiettivo comune.

Dopo aver creato lo Sprint Goal e selezionato gli elementi del Product Backlog per lo Sprint, il Team di Sviluppo decide come costruirà queste funzionalità in un Incremento “Fatto” del prodotto all’interno dello Sprint stesso. Le voci del Product Backlog selezionate per lo Sprint più il piano per la consegna definiscono lo Sprint Backlog. Il Team di Sviluppo di solito inizia con la progettazione del sistema e il lavoro necessario per convertire il Product Backlog in un Incremento del prodotto. Il Team di Sviluppo pianifica sempre avendo in mente lo Sprint Goal. Può capitare che durante lo Sprint il lavoro necessario sia diverso da quanto il Team di Sviluppo aveva pianificato. In questo caso il Team di Sviluppo collaborerà con il Product Owner per determinare come rivedere al meglio il piano senza perdere di vista lo Sprint Goal.

Alla fine del meeting di Sprint Planning, il Team di Sviluppo dovrebbe essere in grado di spiegare al Product Owner e allo Scrum Master come intende lavorare in quanto team autogestito, al fine di raggiungere l’Obiettivo di Sprint e creare l’Incremento previsto.

Daily Scrum

Ogni giorno durante lo Sprint, viene tenuta una riunione di comunicazione del team di progetto. Questo meeting viene chiamato “daily scrum” e ed ha un insieme di regole specifiche:

Tutti i membri del Team di sviluppo vengono preparati con gli aggiornamenti per la riunione;
L’incontro inizia puntualmente anche se qualche membro del team è assente;
Il meeting dovrebbe avvenire ogni giorno nello stesso luogo e allo stesso tempo per ridurre la complessità;
La durata del meeting è fissata al tempo massimo di 15 minuti;
Si partecipa rimanendo in piedi, per non dare modo ai partecipanti di distrarsi ed isolarsi come accade nelle riunioni “tradizionali”;
Tutti sono benvenuti, ma normalmente solo i ruoli principali possono parlare .

Durante l’incontro ogni persona del Team di Sviluppo spiega:

Cosa ho fatto ieri che ha aiutato il Team di Sviluppo a procedere verso lo Sprint Goal?
Cosa farò oggi per aiutare il Team di Sviluppo a procedere verso lo Sprint Goal?
Vedo degli ostacoli tra me o il Team di Sviluppo e lo Spring Goal?

Lo Scrum Master fa rispettare la regola che soltanto i membri del Development Team possono partecipare al Daily Scrum. Il Daily Scrum migliora la comunicazione, elimina altri incontri, identifica e rimuove gli ostacoli allo sviluppo, evidenzia e promuove il rapido processo decisionale e migliora il livello di conoscenza del progetto da parte del Team di Sviluppo. Rappresenta un incontro chiave d’ispezione e adattamento.

Sprint Review

Alla fine dello Sprint si tiene l’incontro di Sprint Review, della durata massima di 4 ore, per ispezionare l’incremento e adattare, se necessario, il Product Backlog. Durante la riunione di Sprint Review lo Scrum Team e gli stakeholder collaborano su ciò che è stato fatto durante lo Sprint.

A partire da questo e dai cambiamenti apportati al Product Backlog durante lo Sprint, i partecipanti collaborano sulle prossime cose che potrebbero essere fatte per ottimizzare il valore.
La Sprint Review include i seguenti elementi:

I partecipanti includono lo Scrum Team e i principali stakeholder invitati dal Product Owner;
Il Product Owner identifica ciò che è stato “Fatto” e ciò che non è stato “Fatto”;
Il Team di Sviluppo discute su cosa è andato bene durante lo Sprint, quali problemi si sono incontrati e come questi problemi sono stati risolti;
Il Team di Sviluppo mostra il lavoro “Fatto” e risponde alle domande relative all’Incremento;
Il Product Owner discute lo stato attuale del Product Backlog. Fa una previsione della possibile data di completamento in base alla misura dell’avanzamento attuale se necessario;
L’intero gruppo collabora su cosa fare dopo, così la Sprint Review fornisce un prezioso contributo alle successive riunioni di Sprint Planning.
Passare in rassegna come il marketplace o il potenziale utilizzo del prodotto possa avere cambiato l’elemento di maggior valore da implementare prossimamente;
Passare in rassegna la timeline, il budget, le funzionalità potenziali e il marketplace per la prossima prevista release del prodotto.

Sprint Retrospective

La Sprint Retrospective è un incontro della durata massima di tre ore ed è un’occasione per lo Scrum Team per ispezionare se stesso e creare un piano di miglioramento da attuare durante il prossimo Sprint. Lo Scrum Team si riunisce per la Sprint Retrospective dopo la Sprint Review e prima del successivo Sprint Planning.

Lo scopo della Sprint Retrospective è di:

Esaminare come l’ultimo Sprint è andato in merito a persone, relazioni, processi e strumenti;
Identificare e ordinare gli elementi principali che sono andati bene e le migliorie potenziali;
Creare un piano per attuare i miglioramenti al modo di lavorare dello Scrum Team.

Entro la fine della Sprint Retrospective, lo Scrum Team dovrebbe aver individuato i miglioramenti che saranno implementati nel prossimo Sprint. Attuare tali miglioramenti durante il prossimo Sprint è l’adattamento all’ispezione dello Scrum Team stesso. Anche se i miglioramenti possono essere implementati in ogni momento, la Sprint Retrospective fornisce un’opportunità formale per focalizzare l’ispezione e l’adattamento.