Scrum in pillole: la fase di Implementazione

Scrum in pillole: la fase di Implementazione

Nell’ultimo appuntamento con Scrum in pillole ci eravamo lasciati con una domanda: una volta pianificato e concordato lo Sprint che si fa? La risposta è molto semplice: si passa alla implementazione dei deliverable corrispondenti alle User Story concordate per lo Sprint e inserite nello Sprint Backlog e, come di consueto, la troviamo, insieme a molto altro, nella Guida SBOK® Ed. III, tradotta da PME in lingua Italiana per conto di SCRUMstudy(1), e scaricabile gratuitamente da sito ufficiale di SCRUMstudy.
La fase di Implementazione riguarda appunto l‘esecuzione delle attività e delle azioni che servono a creare un prodotto di progetto. Il termine ‘prodotto’ si può riferire ad un prodotto, servizio, o altro deliverable. Le attività di questa fase attengono alla creazione di vari deliverable, alla conduzione dei Daily Standup Meeting e alla messa a punto (vale a dire, revisione, ottimizzazione e regolare aggiornamento) del Product Backlog a intervalli regolari.
Creare i Deliverable—In questo processo, lo Scrum Team lavora alle attività dello Sprint Backlog per creare i Deliverable dello Sprint. Per monitorare il lavoro e le attività che si stanno eseguendo viene di norma utilizzata una Scrumboard. Le questioni o i problemi che lo Scrum Team si trova ad affrontare possono essere annotati in un Registro degli Impedimenti. I membri dello Scrum Team hanno l‘autorità e la responsabilità di stabilire i mezzi migliori per trasformare gli elementi del Prioritized Product Backlog in prodotti finiti, senza bisogno di coinvolgere alcuno stakeholder esterno al team. Per la schedulazione, la raccolta delle informazioni e la loro distribuzione possono essere utilizzati strumenti di Software Automatizzato. Nei progetti in cui gli Scrum Team non sono co-ubicati sono inoltre essenziali gli strumenti di collaborazione virtuale. Sono disponibili molti strumenti software automatizzati, che permettono il monitoraggio dello stato di avanzamento, la raccolta dei dati e la loro distribuzione e contribuiscono a velocizzare i processi.
Condurre il Daily Standup—Tutti i giorni si tiene una riunione estremamente mirata, di durata predeterminata, chiamata Daily Standup Meeting. Questo rappresenta per lo Scrum Team il luogo di discussione per un aggiornamento sui reciproci progressi e sugli eventuali impedimenti che i singoli membri stanno riscontrando. Questa breve riunione quotidiana ha una durata predeterminata di 15 minuti. I membri del team si riuniscono per fare un resoconto sui loro progressi nello Sprint e per pianificare le attività del giorno. La durata della riunione è molto breve e ci si aspetta che partecipino tutti i membri dello Scrum Team. Tuttavia, la riunione non viene cancellata o rinviata se uno o più membri non possono partecipare. Nel Daily Standup Meeting, facilitato dallo Scrum Master, ciascun membro dello Scrum Team fornisce informazioni sotto forma di risposte a tre domande specifiche:
• Cosa ho fatto nel tempo intercorso dall’ultima riunione?
• Cosa pianifico di fare prima della prossima riunione?
• Quali (eventuali) impedimenti o ostacoli sto riscontrando attualmente?
Focalizzandosi su queste tre domande, l‘intero team può farsi un‘idea precisa dello stato del lavoro. Ogni tanto possono essere discussi anche altri elementi, ma questo dibattito viene ridotto al minimo, in virtù della durata predeterminata (e molto breve) che caratterizza il tipo di riunione.
Mettere a Punto il Prioritized Product Backlog—L‘oggetto di questo processo è il continuo aggiornamento e mantenimento del Prioritized Product Backlog. Durante i Prioritized Product Backlog Review Meeting tutti i cambiamenti e gli aggiornamenti del backlog vengono discussi e, se del caso, incorporati nel Prioritized Product Backlog. L‘intento dei Prioritized Product Backlog Review Meeting è fare in modo che le User Story e i Criteri di Accettazione siano compresi e scritti in modo appropriato dal Product Owner, così da riflettere i reali requisiti e priorità dello stakeholder (cliente); che le User Story siano comprese da tutto lo Scrum Team e, infine che le User Story con priorità alta siano ben rifinite, in modo da poter essere correttamente stimate e quindi prese in carico dallo Scrum Team. I Prioritized Product Backlog Review Meeting assicurano inoltre la rimozione delle User Story inutili e l‘incorporazione nel Prioritized Product Backlog di tutte le Richieste di Modifica Approvate e dei Rischi Identificati, che possono scaturire anche dal processo di creazione dei deliverable e dai Daily Standup. Questa attività di messa a punto prepara al meglio la partenza dello Sprint successivo, perché consente di avere un Prioritized Product Backlog aggiornato con i requisiti e le priorità reali del cliente.
La creazione di incrementi di prodotto/servizio/deliverable in ogni Sprint ha un preciso scopo in Scrum: quello di poter consegnare valore al cliente potenzialmente al termine di ogni Sprint. Come si raggiunge questo obiettivo? Tramite la review, cioè la convalida da parte del Product Owner dei deliverable completati al termine di ogni Sprint. E proprio di questo parleremo nel nostro prossimo appuntamento con le pillole di Scrum.

Lo Staff di PME

(1)I contenuti di questo articolo sono tratti dalla traduzione ufficiale in Italiano della Guida SBOK e di altri contenuti didattici, curata da PME per conto di VMEdu Inc., proprietaria del marchio SCRUMstudy.
Project Management Europa S.r.l. è Authorized Training Partner di VMEdu e SCRUMstudy
SCRUMstudy, SFC, SDC, SMC, SPOC, SSMC, SSPOC, ESMC, SAMC, SBOK sono marchi registrati diVMedu Inc.
Le immagini dell’articolo sono utilizzate su concessione di VMEdu Inc., che ne è la proprietaria.
Se vuoi maggiori informazioni su tutti i nostri corsi Scrum, disponibili ora anche in Italiano e sulle offerte attualmente disponibili Clicca qui.

0 Commenti

Leave a reply

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

*