The Scrum Framework — Seconda edizione

Questo capitolo mantiene il contesto didattico storico e pratico della seconda edizione. Nei contenuti sottostanti è disponibile anche il percorso della terza edizione.

---

Esempio Scrum: un caso reale per team agili di alto livello

In questo articolo vogliamo presentarti un esempio di metodologia Scrum che possa ispirare i tuoi team, le altre parti aziendali interessate e le persone coinvolte nei progetti. Abbiamo osservato molti casi in cui aziende e attività dispongono di professionisti Scrum formati, ma incontrano difficoltà nelle operazioni quotidiane e nell’implementazione del prodotto per mancanza di esperienza pratica.

Questo problema impedisce spesso ai team di raggiungere la velocità ottimale e consegnare i risultati nei tempi e nel budget previsti. Ecco perché questo esempio della metodologia Scrum è importante.

In questo breve articolo proveremo quindi ad aiutarti a vedere il quadro complessivo del framework: dalla costruzione dei processi Scrum che generano valore senza precedenti per le aziende, prodotti e servizi che offrono ai clienti un’ampia esperienza di agilità, fino alla configurazione e all’uso del grafico di burndown per migliorare e mantenere la velocità dei team.

Con questo esempio ti aiuteremo a comprendere come opera un team Scrum e quali benefici può portare all’organizzazione. I dati suggeriscono che nella maggior parte delle aziende i team siano generalmente composti da Product Owner, Scrum Master e sviluppatori, che insieme formano il team Scrum. Collaborano in brevi iterazioni, gli Sprint, per consegnare incrementi di prodotto di valore. Questo approccio iterativo consente flessibilità, adattabilità e feedback più rapidi.

Ecco i protagonisti di questo esempio di metodologia Scrum:

• Alex, il Product Owner Scrum.
• Frank, lo Scrum Master.
• Il team Scrum.

Prima di iniziare il primo Sprint

Alex viene nominato Product Owner Scrum di un nuovo progetto di sviluppo software. Una delle sue prime attività è avviare l’ingegneria dei requisiti. Annota i casi d’uso principali e li discute con architetti, rappresentanti del cliente e altre parti interessate. Dopo aver raccolto casi d’uso e requisiti di alto livello, li inserisce nel Product Backlog Scrum e avvia una sessione di stima e assegnazione delle priorità con gli architetti e alcuni sviluppatori senior. Al termine, tutti gli elementi del backlog hanno una prima stima approssimativa e una priorità. Inizia quindi a scomporre i requisiti di alto livello in storie utente più dettagliate. Con questo elenco convoca la prima riunione di pianificazione dello Sprint.

Introduzione a Scrum: un esempio reale attraverso le varie fasi e gli Sprint

Sprint 1 - Giorno 0

Durante la pianificazione, Alex presenta gli elementi del Product Backlog dal più al meno prioritario. Il team chiarisce le domande aperte e discute per ogni elemento se dispone di capacità, competenze e tutto il necessario. Dopo la discussione si impegna a completare le storie 1, 2, 3, 6, 7 e 8 entro la fine dello Sprint. Gli elementi 4 e 5 non sono realizzabili in questo Sprint, poiché parte dell’infrastruttura tecnica non è ancora disponibile.

Dopo la riunione di pianificazione, Frank, lo Scrum Master, riunisce il team per definire i dettagli dell’implementazione degli elementi presi in carico. Le attività risultanti vengono scritte su schede nella task board dello Sprint predisposta. Ora ogni componente del team Scrum sceglie un’attività su cui lavorare.

Consiglio per i team Scrum:

Alex, nel ruolo di Product Owner Scrum, guida un nuovo progetto di sviluppo software nell’organizzazione. È un po’ come il direttore di un’orchestra in cui ciascuno svolge la propria parte. Il suo ruolo interfunzionale comporta notevoli responsabilità e si concentra sulla creazione di framework agili auto-organizzati, in cui il miglioramento è continuo. Non è una soluzione universale, ma una rotta tracciata per guidare gli sviluppatori. Alex è il cuore pulsante dell’azienda e assicura che i prodotti finali rispondano alle esigenze dei clienti. Un approccio agile di questo tipo procede continuamente per iterazioni, favorendo il perfezionamento costante di prodotti e metodi.

Successivamente Alex promuove una sessione di stima e assegnazione delle priorità usando storie utente (scopri di più sulle storie utente Scrum) e story point come tecnica di stima relativa. Una visualizzazione di tipo Kanban può integrare il lavoro rendendo attività e flusso visibili a tutto il team. Tutti gli elementi del Product Backlog ricevono così una stima iniziale e una priorità. Alex usa l’esperienza nella gestione dei progetti per scomporre i requisiti di alto livello in storie centrate sull’utente, traducendoli efficacemente in parti consegnabili. Queste storie, esempi concreti di ciò che desiderano i clienti, illustrano percorsi verso gli obiettivi del progetto. Con l’elenco pronto, convoca la prima pianificazione dello Sprint, favorendo una stretta collaborazione nel team di sviluppo.

Sprint 1 - Giorno 1

Al mattino l’intero team si riunisce per il Daily Scrum. Ciascuno spiega brevemente quanto fatto, aggiorna sulle schede della task board la stima delle ore residue, comunica che cosa intende fare quel giorno e indica eventuali impedimenti. Oggi un componente spiega di avere un problema: gli serve una nuova licenza per uno strumento software. Frank verifica se anche altri abbiano lo stesso problema e dice che se ne occuperà dopo la riunione. Dopo 15 minuti tutti tornano al lavoro.

Dopo la riunione Frank aggiorna il burndown dello Sprint. Poi chiama il fornitore dello strumento, ordina le licenze e le inoltra a chi ne ha bisogno.

Consiglio per i team Scrum:

Durante la pianificazione Alex illustra gli elementi del Product Backlog ordinati per priorità. È sua responsabilità nell’organizzazione assicurare che tutti comprendano l’obiettivo complessivo del progetto. Le riunioni stand-up del team favoriscono discussioni aperte che chiariscono i ruoli e risolvono potenziali problemi.

Frank, lo Scrum Master, ha un altro ruolo fondamentale nel team. Segue ogni stand-up quotidiano, aiutando quando necessario la conversazione a restare concentrata sull’obiettivo dello Sprint. Gli sviluppatori sono responsabili del proprio piano e scelgono le attività in collaborazione: Frank non assegna loro il lavoro.

Sprint 1 - Giorno 2

Al mattino l’intero team si riunisce nuovamente per il Daily Scrum. Nel pomeriggio un componente non è sicuro dei dettagli di una storia utente. Chiama Alex, il Product Owner, e discute con lui i punti aperti. Una volta chiarito che cosa fare, può continuare l’implementazione.

Sprint 1 - Giorno 28

È l’ultimo giorno del primo Sprint e Frank, lo Scrum Master, ha invitato il team alla revisione. Il team ha preparato una macchina con l’implementazione software corrente. Alex, il Product Owner, si siede davanti alla macchina e verifica che l’implementazione risponda alle aspettative e che le funzionalità siano documentate come richiesto. Alla fine conclude:

• Le storie 1, 2, 6 e 7 sono terminate come previsto.
• La storia 3 non è stata completata in tempo e non è stata presentata.
• La storia 8 presenta alcuni punti che richiedono refactoring.

Nel pomeriggio il team si riunisce per la retrospettiva e discute che cosa sia andato bene nello Sprint e che cosa si possa migliorare. Uno dei feedback è che il team ritiene di conoscere troppo poco l’architettura complessiva. Frank si incarica di invitare l’architetto di sistema a presentarla più dettagliatamente.

Esempio di metodologia Scrum

Consiglio per i team Scrum:

All’arrivo dell’ultimo giorno del primo Sprint, Frank guida il team nella riunione di revisione. La collaborazione costante produce un prototipo tangibile che rispecchia l’impegno e il duro lavoro del team.

Nel pomeriggio il team si riunisce per la retrospettiva dello Sprint. Condivide considerazioni sull’avanzamento e riesamina gli aspetti da migliorare negli Sprint futuri. La riunione si rivela un elemento fondamentale dell’approccio agile e offre un notevole valore all’intero progetto.

Pianificando lo Sprint successivo, il ruolo fondamentale di Alex come Product Owner emerge ancora quando aggiunge elementi al backlog sulla base degli ultimi incontri con il cliente. All’inizio del secondo Sprint è evidente che lavoro di squadra, trasparenza e gestione efficace continuano a spingere verso il successo questo team guidato dalle informazioni.

Sprint 2 - Giorno 1

Alex, il Product Owner, aggiunge elementi al Product Backlog sulla base degli ultimi incontri con il cliente. Inserisce anche attività di refactoring per la storia 8. Invita poi il team alla pianificazione dello Sprint 2. Con la guida di Frank, lo Scrum Master, il team discute e prende in carico le storie: inizia così il secondo Sprint.

Consiglio per i team Scrum:

Il secondo Sprint mette in pratica quanto appreso: il Product Backlog aggiornato rispecchia il feedback del cliente, il lavoro incompleto viene riconsiderato e la collaborazione prosegue attorno al prossimo obiettivo dello Sprint.

Studiare esempi e casi Scrum è essenziale per le organizzazioni che vogliono creare team efficienti e performanti. Analizzare situazioni reali offre preziose indicazioni sulle implementazioni riuscite e aiuta, altrettanto importante, a riconoscere gli errori comuni da evitare. Imparando da questi esempi, i team possono diventare più rapidamente eccellenti, sfruttare le migliori pratiche, evitare possibili errori e ottenere successi iniziali.

Continua a seguirci per altri scenari reali e casi di studio che arricchiranno la tua comprensione del framework Scrum e delle sue applicazioni pratiche.