Prosegue la trattazione di Scrum. In questa puntata parliamo di daily standup meeting, di Definition of Done e di Demo finale
Esecuzione dello sprint
Continua questo viaggio interstellare nella galassia agile: in questa puntata parleremo della gestione delle attività e cerimonie che compongono il lavoro quotidiano di un team Scrum.
In base alla mappa interstellare della galassia Agile, siamo locati nel sistema solare “Cerimonie” come riportato nella figura 1.
Dopo aver affrontato lo sprint planning (si veda l’articolo precedente), il team inizia lo sprint vero e proprio cominciando la lavorazione delle storie che sono state accettate in fase di planning.
Prima di fare questo, il gruppo decide il nome che si vorrà dare allo sprint: non è una attività obbligatoria, ma è utile a tutti per ricordare cosa dovrà essere fatto e quali sono gli obiettivi del lavoro che sta per iniziare. A volte il team assegna allo sprint sia un nome che ricordi l’obiettivo di business (p.e.:, “Sprint 4 – Elaborazione stampe online”) sia l’obiettivo del team o del processo (p.e.: “Sprint 4 – Miglioramento della continuous integration”).
L’analisi delle storie: scomposizione in sotto-attività
Il team inizia quindi lo sprint analizzando l’elenco delle storie accettate e che compongono lo sprint backlog. Un’attività utile, che viene spesso eseguita come preparazione dello sprint, prevede la scomposizione di ogni storia in sotto-attività o task: in questo caso si appongono al cartellino della storia una serie bigliettini colorati (i task) che rappresentano le attività che dovranno essere svolte per implementare quella storia.
Figura 2 – Scomposizione delle storia in task. Per ogni attività si attacca al cartellino un biglietto con un codice colore concordato.
Nella figura 2 è riportato un caso piuttosto tipico di scomposizione di una storia. Non ci sono regole su come scomporre le storie ne’ sul colore da utilizzare per i vari task; è una decisione che spetta al gruppo, così come non è detto che tutte le storie debbano comprendere lo stesso numero e tipo di attività. Le storie tecniche (installazione dell’application server o preparazione del database) e le storie di preparazione (documentazione, amministrazione, formazione del personale utente, etc.) presumibilmente avranno solo alcune delle attività elencate.
Analogamente può capitare che siano necessari più biglietti dello stesso tipo di attività (quando si vuole eseguire due tipi di analisi o predisporre due task di implementazione che verranno eseguiti da due programmatori in parallelo).
Tramite l’ausilio di una kanban board si compone una rappresentazione visuale dello stato di avanzamento delle lavorazioni sulle varie storie e task.
Figura 3 – Le storie sono organizzate su una Kanban board che permette di seguire la lavorazione sia delle sotto-attività che delle storie nel loro complesso.
Il team quindi si auto-organizza prendendo in carico la lavorazione delle varie attività: tramite l’utilizzo dei biglietti sulla lavagna, si potrà in ogni momento avere un’idea dello stato di avanzamento non solo del singolo task, ma anche delle relative storie.
Nel caso di team cross-funzionali (tutti possono fare tutto, dall’analisi all’implementazione al test) si potranno avere situazioni in cui due persone lavorano alla stessa storia passando da un task all’altro. Se invece il team prevede una qualche specializzazione, alcuni lavoreranno solo coi cartellini verdi (analisi), altri con quelli bianchi (test) e così via.
Un esempio
Per capire meglio, supponiamo di fare un esempio; si immagini che lo sprint backlog contenga un numero arbitrario di storie (non è importante al momento specificarne il numero) e che tali storie siano organizzate in modo da contenere i classici task di cui sopra.
A questo punto possiamo immaginare che ogni membro del dev team prenda in carico una storia e proceda alla sua realizzazione. Supponiamo che Andrea si sia preso in carico il lavoro sulla storia con identificativo US.123: per prima cosa egli ripasserà scopo e dettagli della storia leggendo titolo, corpo e criteri di accettazione.
Andrea quindi, prenderà in esame i task della storia: per esempio prima effettuerà una analisi di dettaglio, poi il design e così via. Per ogni attività egli è il responsabile della storia e quindi lui sa quanto e come portare a termine il lavoro.
In alcuni casi l’analisi richiederà un lungo e dettagliato lavoro di approfondimento, in altri casi invece potrebbe bastare una cosa molto più semplice: nel primo caso l’analisi dei requisiti funzionali potrebbe essere portata a termine tramite la compilazione di un Use Case Form (UCF). Nel secondo invece potrebbe bastare una sintetica ma esaustiva pagina di testo magari corredata di qualche disegno sui prototipi della interfaccia utente.
Quindi il biglietto dell’analisi verrà spostato nella colonna WIP (work in progess) e al termine in quella di done.
Ricordiamo che, come già visto in precedenza, per la gestione delle varie attività di progetto si segue sempre un approccio pull: si procede quindi alla lavorazione di una attività prelevandola dalla colonna precedente (“done”) dove di fatto sono stati parcheggiati i task sui quali è stata terminata correttamente la fase di lavorazione precedente. L’approccio push (appena finita la lavorazione di un task lo passo direttamente alla lavorazione della fase successiva) non è efficace ne’ efficiente, dato che dà luogo a ingolfamenti e finisce per rallentare l’intero sistema.
Terminata quindi la fase di analisi, ci si comporta in modo analogo per tutti i task di tutte le storie in esame.
È per consentire il parcheggio delle attività terminate che ogni colonna presenta delle sotto-colonne corrispondenti allo stato “in lavorazione” e a quello “lavorazione conclusa”, che significa, sostanzialmente, essere nello stato “pronto per essere preso per la lavorazione successiva”.
Grazie a questa semplice convenzione, ogni task può essere preso in carico sempre dalla stessa persona per tutti gli step del processo di lavorazione, oppure, non appena si rende disponibile qualcuno in grado di svolgere un determinato compito, si possono avere più colleghi che lavorano sullo stesso task in momenti differenti (si veda la figura 4).
Daily standup meeting
Una delle attività più semplici da implementare, ma probabilmente fra le più efficaci e importanti, è la riunione quotidiana del daily standup meeting. In questo momento il team si riunisce per parlare del lavoro fatto il giorno prima e per condividere eventuali difficoltà o punti di attenzione. La riunione ha una durata breve, normalmente 10 o 15 minuti e si svolge in piedi formando una specie di cerchio. Ogni membro del team espone agli altri tre cose: cosa ha fatto il giorno precedente, cosa pensa di fare il giorno corrente e quali difficoltà si sono incontrate nel lavoro svolto il giorno precedente (o se si immagina che tali problemi si ripresentino).
È una formula rapida che segue un approccio molto pragmatico: si sta in piedi proprio per impedire che ci si faccia prendere la mano in una discussione lunga e noiosa; se ciò accadesse, dopo pochi giorni si perderebbe di efficacia e di attrattiva.
Si tratta di un momento di condivisione utile per allineare i colleghi e per permettere a tutti di sapere lo stato di avanzamento dei colleghi ed essere quindi informati dei problemi degli altri; non è raro che si scopra in questo momento di non essere i soli ad aver incontrato un determinato problema e quindi si può chiedere o offrire aiuto a seconda di chi ha già visto e magari risolto il problema.
Sebbene il daily standup meeting sia molto semplice nel cerimoniale e nella struttura, risulta un’attività estremamente potente ed efficace. Spesso permette infatti di risolvere in modo rapido ed economico problemi derivanti da una comunicazione carente e da una cattiva condivisione delle informazioni; da non sottovalutare i benefici derivanti da un miglioramento della confidenza e dello spirito di appartenenza al gruppo.
Spesso si consiglia di introdurre il daily standup come primo elemento di Scrum qualora si voglia portare l’agile in un team o azienda un po’ per volta: richiede poco sforzo, è semplice da gestire, ha un benefico ritorno in tempi rapidi.
Al daily standup meeting in genere partecipa tutto il team di sviluppo e anche lo scrum master (se non è già incluso nel dev team). Il product owner tipicamente non è necessario anche se in alcuni casi può essere utile la sua presenza come osservatore per rendersi conto in prima persona di eventuali problemi nel team o nel progetto.
Come valutare il completamento delle storie: la Definition of Done
Quando la lavorazione di una storia è portata a termine, verrà posta nella posizione delle Done/Done, a significare che si tratta di storie non solo complete ma che soddisfano la cosiddetta Definition of Done (DoD). Si tratta di un elenco di criteri di accettazione finale, criteri a cui ogni storia deve sottostare per essere considerata realmente finita e pronta per essere presentata alla demo di fine sprint.
Il numero e la specificità delle condizioni incluse nella lista, se da un lato aiutano a definire meglio quando una storia è completata, migliorando quindi la qualità del prodotto finito, sono direttamente proporzionali al lavoro che deve essere svolto se si vuole completare una storia.
Per questo motivo la compilazione della DoD è un passaggio molto importante e deve essere condiviso da tutto il gruppo: non è raro che il team di sviluppo decida di “votare” col sistema del dot voting la lista delle cose da inserire nella DoD. In questo caso per prima cosa si pone in tutta libertà l’elenco delle cose che tutti vorrebbero inserire apponendo, su una lavagna o una parete, una serie di biglietti adesivi, uno per ogni elemento. Si spazia in questo caso dalla verifica dei test unitari, alla scrittura della documentazione, dall’esecuzione del test utente a quello di non regressione dopo il merge su server di continuous integration.
Figura 5 – Per indivudare quali elementi comporranno la DoD si parte dalla stesura di tutti i temi che il team reputa interessanti
Dopo questa prima parte, lo scrum master procede a fare il raggruppamento (o clustering) dei biglietti, raggruppando fra loro i temi simili. Come riportato nella figura 6, potrebbe capitare che alcuni elementi non siano raggruppabili e quindi si lasciano isolati.
A questo punto si effettua il dot voting: ogni partecipante ha a disposizione 3-4 voti (dipende dal numero totale di argomenti che si sono ottenuti dopo il raggruppamento) e decide dove piazzarli: potrebbe metterli tutti su un argomento o spargerli sui vari set.
Al termine della votazione si contano i voti di ogni set e si stila in questo modo l’elenco ordinato in base all’importanza (così come è valutata dal team) delle condizioni cui ogni storia dovrà sottostare.
Figura 6 – Dopo il clusterig si procede al dot voting di ogni set individuato precedentemente.
Aggiustamenti sulla Definition of Done
Sebbene tutti i membri del team siano contenti del risultato ottenuto, dopo qualche iterazione può capitare che ci si accorga che la DoD sia più impegnativa del previsto: dopo un paio di sprint infatti, ci si potrebbe accorgere che l’implementazione di tutti i punti della DoD richiede molto più tempo di quello previsto e che per questo motivo la velocity del gruppo risulta più bassa del previsto.
In questo caso, se una lista di controlli troppo impegnativa dovesse portare al blocco o al rallentamento dei lavori, si può optare col partire con una soluzione più soft, per poi accrescerla col tempo mano mano che il gruppo acquisisce competenze e dimestichezza col processo.
Si ricordi che la DoD rappresenta l’elenco dei requisiti ortogonali a tutte le storie: tipicamente infatti contiene requisiti non funzionali come QA, test, performance, sicurezza e altro ancora. È quindi chiaro che ogni volta che si aggiunge un elemento alla DoD questo dovrà non solo essere rispettato dalle nuove storie che si rilasceranno, ma si dovrà procedere alla sua verifica in tutte le storie già rilasciate (che eventualmente dovranno essere modificate). Per fare questo spesso si decide di inserire nel backlog una storia ad hoc che consenta di inserire tale requisito. Anche di questo parleremo ulteriormente quando parleremo di user stories.
Valutazione del prodotto finito: Sprint Review
A termine di ogni sprint, prima di considerare terminato il lavoro, è necessario verificare ogni storia prodotta tramite una apposita cerimonia detta sprint review o sprint demo.
In questo caso lo scrum master indice la riunione che si dovrebbe tenere nella stanza di lavoro del gruppo di sviluppo. Ogni storia verrà presentata direttamente dalla persona che l’ha sviluppata; nel caso che il lavoro sia stato fatto da più persone, la demo verrà fatta da colui che, a inizio lavoro, è stato scelto (o si è proposto) come il responsabile (owner) della storia.
A tale incontro partecipano (per ovvi motivi) tutti membri del team di sviluppo, lo scrum master (la cui presenza è scontata se è lui stesso un membro del dev team) e il product owner.
Lo scopo è verificare, dopo un intero sprint, che quanto fatto sia corrispondente a quanto richiesto o che, nel caso di mancanza di ipotesi chiare sul come realizzare una determinata funzionalità, le ipotesi fatte abbiano dato luogo a soluzioni realmente utili.
Alla demo è molto utile la partecipazione anche di persone appartenenti al gruppo di utenti e il cliente che ha commissionato il lavoro. Non sempre è possibile chiedere la loro presenza ad ogni demo (possono esserci problemi logistici, organizzativi, politici e altro ancora), specialmente nel caso di iterazioni frequenti; in questo caso sarà il product owner che ricopre il ruolo di giudice inappellabile sulla correttezza e sulla ammissibilità finale delle storie. Il product owner è infatti il portatore degli interessi di business del cliente, e delle aspettative funzionali degli utilizzatori.
Lo scrum master quindi ha preparato una board come quella riportata in figura 7
Figura 7 – Per la sprint review di prepara una lavagna con tutte le storie completate e pronte per la demo finale.
Tale tabella contiene l’elenco delle storie completate (come da DoD) che il team porta alla demo (le storie non completate o che non soddisfino la DoD non sono presentate); per ogni storia è riportato il punteggio, una descrizione, l’owner e il tracker della storia e un check finale che sarà verde (storia passata) o rosso (storia rifiutata).
Il tracker è una persona che, durante la demo, prende appunti su quello che viene detto riguardo la storia: si scrivono eventuali note su come migliorare la GUI, dettagli non bloccanti ma che dovranno essere corretti e altre cose utili per la storia in esame o per il processo.
Si noti che owner e tracker non possono essere la stessa persona: il primo effettua la demo della storia, il secondo invece prende appunti.
La cerimonia si svolge in questo modo: lo scrum master preleva una per una le varie storie dall’elenco delle storie. Per ogni storia l’owner si attiva per eseguire al product owner (e verso altri attori presenti alla riunione) la storia di sua pertinenza. Per fare questo egli mostra sul proprio computer le parti dell’applicazione in funzione; se presente un utente reale, tale prova potrà essere fatta direttamente da chi poi userà tali funzionalità realmente in produzione.
Il product owner a questo punto, valuta se la storia è implementata correttamente, sia controllandone il funzionamento, sia verificando gli acceptance criteria presenti sul cartellino, sia chiedendo (se presente) all’utente se il lavoro fatto corrisponde alle aspettative.
La valutazione deve essere estremamente rigorosa e inflessibile: il product owner in questo caso valuta ogni aspetto della storia, verifica ogni punto degli acceptance criteria. Se anche uno dei punti in elenco non è rispettato o se è presente qualche difetto che ne pregiudichi il funzionamento, la storia viene “bocciata”. Frasi del tipo “si ok c’è un errore, ma possiamo correggerlo dopo” non sono ammesse. A volte, in concomitanza di piccoli difetti che non pregiudicano ne’ gli acceptance criteria ne’ il funzionamento, si può accettare la storia con defect: in tal caso il product owner (e il tracker) si segnano il punto in modo da creare, appena finita la riunione, una storia di correzione. Niente viene lasciato al caso o al “si correggerà quando avremo tempo”.
Se la storia passa al vaglio dell’esaminatore, lo scrum master segna con una flag verde sulla board delle storie, altrimenti con una croce rossa: ovviamente ogni altro simbolismo o codice colore è ammesso 🙂
Contestualmente calcola il nuovo punteggio parziale totalizzato: ogni storia passata infatti aggiunge un punteggio che si somma alle altre.
A termine della demo si controlla il punteggio di sprint ottenuto con quello ipotizzato al momento del planning. Questo è rappresenta la reale velocity del team calcolata a posteriori. Il team in fase di retrospettiva e di planning successivo, valuterà il punteggio ottenuto in rapporto alle ipotesi di inizio sprint e di conseguenza penserà a come aggiustare le stime per lo sprint successivo.
Conclusione
Abbiamo parlato delle varie attività che compongono lo sprint. Resta da affrontare quella che probabilmente è la cerimonia più importante (dal punto di vista del processo), ovvero la Sprint Retrospective. Ne parleremo nella prossima puntata di questa serie.
Giovanni Puliti ha lavorato per oltre 20 anni come consulente nel settore dell’IT e attualmente svolge la professione di Agile Coach. Nel 1996, insieme ad altri collaboratori, crea MokaByte, la prima rivista italiana web dedicata a Java. Autore di numerosi articoli pubblicate sia su MokaByte.it che su riviste del settore, ha partecipato a diversi progetti editoriali e prende parte regolarmente a conference in qualità di speaker. Dopo aver a lungo lavorato all’interno di progetti di web enterprise, come esperto di tecnologie e architetture, è passato a erogare consulenze in ambito di project management. Da diversi anni ha abbracciato le metodologie agili offrendo ad aziende e organizzazioni il suo supporto sia come coach agile che come business coach. È cofondatore di AgileReloaded, l’azienda italiana per il coaching agile.