Prosegue la trattazione di Scrum. In questa puntata parliamo di Sprint Planning
Organizzazione del lavoro: gli sprint e il backlog
Come abbiamo avuto modo di accennare nella precedente puntata, un progetto basato su Scrum prevede la suddivisione del lavoro in “quanti” temporali detti Sprint: uno Sprint è un periodo di tempo di lunghezza determinata e costante, all’interno del quale si dovranno completare un certo numero di elementi del Product Backlog (PB). La durata dello sprint, una volta scelta, non dovrebbe essere mai modificata (a meno di eventi catastrofici).
Al termine dello sprint si porteranno alla demo finale solo le cose completamente terminate e verificate; le funzionalità non completamente implementate non solo non verranno prese in considerazione alla demo finale, ma verranno re-inserite nell’elenco delle cose da fare (o finire, vedremo meglio questo importante concetto prossimamente).
L’insieme delle cose completate all’interno dello sprint andrà ad aggiungersi al resto delle cose fatte in modo da comporre pezzo dopo pezzo il sistema finale. Per questo motivo, al termine della iterazione, non solo le cose fatte devono essere fatte e fatte bene (in gergo si dice che una funzionalità deve essere “Done Done”, non semplicemente “Done”), ma devono essere potenzialmente rilasciabili in produzione. Le storie devono quindi essere complete, funzionanti, controllate e in modo che l’eventuale inserimento nel sistema di produzione ne renda possibile l’utilizzo senza bloccare il resto del sistema (la vera essenza della continuous integration).
Gli elementi che compongono il PB e che corrispondono alle “cose” da fare all’interno dello sprint, possono essere codificate secondo vari formati: nella maggior parte dei casi si usa il modello delle User Stories, anche se Scrum lascia libertà di utilizzare altri formati (per esempio gli Use Case). In questa trattazione, per semplicità ci riferiremo al concetto di storie, anche se non abbiamo ancora visto nel dettaglio cosa siano e come si strutturano.
Le cerimonie di Scrum
Fra gli elementi fondamentali e costituenti il framework Scrum, oltre ai ruoli e agli artefatti, troviamo le cosiddette cerimonie, eventi che sono considerati importantissimi per permettere un corretto svolgimento del progetto. Il termine “cerimonia” è stato scelto proprio a sottolineare la quasi “sacralità” di tali eventi (senza un planning non si parte, senza una review non si può sapere se quanto fatto è corretto, senza la retrospettiva non possiamo individuare e quindi correggere determinati errori nel processo).
Ultimamente il termine cerimonia viene sempre più spesso sostituito dal suo omologo “evento“, per limitare l’ironia o lo scetticismo di chi non crede o non conosce pregi e ricadute derivanti dall’utilizzo del framework. Pur riconoscendo il rischio di usare termini pittoreschi, ritengo il termine “cerimonia” estremamente efficace per farne comprendere l’importanza. Per questo motivo mi piace continuare ad usarlo. In quelle situazioni dove si immagina ci possa essere il rischio di perdere di credibilità, consiglio di usare il termine “evento”. Fra scrummers invece mi piace ritornare alla definizione di “cerimonia” proprio per rafforzare l’importanza delle cose da fare.
Le cerimonie di Scrum sono Sprint Planning, Sprint Review (o Demo), Sprint Retrospective, Daily Standup Meeting, Grooming, cui poi si aggiungono delle attività preparatorie.
Sprint Planning
Lo Sprint Planning, da effettuarsi a inizio sprint, serve per stabilire quali storie verranno implementate nello sprint che sta per iniziare.
Sprint Review (o Demo)
La Sprint Review serve per verificare (tramite una procedura definita e concordata con il team di sviluppo, il product owner e altri stakeholders) se e quali storie completate a fine sprint possono considerarsi terminate, funzionanti e sopratutto rispettano le richieste del cliente o utilizzatore finale. È una specie di test finale pre-produzione.
Sprint Retrospective
La retrospettiva serve per individuare cosa ha funzionato e cosa no. È una specie di valutazione del processo e del lavoro di gruppo in modo da individuare gli errori e intraprendere quelle iniziative necessarie per eliminarli.
Daily Standup Meeting
Incontro di breve durata (tipicamente 10-15′) che il gruppo di sviluppo svolge tutti i giorni alla stessa ora (in genere la mattina) in modo da allineare tutti i colleghi sullo stato di avanzamento. Ogni persona, a rotazione dice tre cose: cosa ha fatto il giorno precedente, cosa intende fare il giorno che sta per iniziare e quali particolari elementi di attenzione vuole condividere con gli altri (impedimenti, problemi, bug da risolvere, e così via).
Grooming
È una attività volta al raffinamento delle storie grandi all’interno del Product Backlog, in modo da renderle pronte alla lavorazione allo sprint successivo. È detto anche raffinamento.
Prima che il progetto inizi, si svolgono in genere alcune attività preparatorie, fra cui la Project Inception, lo User Story Workshop e a volte un vero e proprio sprint di preparazione, detto Sprint Zero.
La pianificazione dello sprint: Scrum Planning
Per semplificare la trattazione, proviamo per il momento a tralasciare la trattazione relativa alle attività di preparazione e di startup di progetto: sono attività molto importanti di cui parleremo in dettaglio in seguito. Supponiamo per questo che il progetto sia iniziato già da qualche tempo e che il lavoro proceda già più o meno a regime: il team ormai è esperto, sia del dominio del progetto che di Scrum.
Si immagini quindi di essere al primo giorno di lavoro dello sprint n e di dover quindi pianificare l’elenco delle cose da fare per le prossime due settimane (supponendo sprint di 10 giorni lavorativi).
Questo obiettivo si ottiene prelevando dalla cima della pila delle cose da fare dell’intero progetto (il Product Backlog Items) tante storie quante il gruppo di sviluppo è in grado di realizzarne nell’arco dei 10 giorni lavorativi. Si andrà a formare quindi un’altra pila, detta Sprint Backlog, che rappresenta pertanto tutto l’insieme delle cose che si dovranno fare.
Figura 1 – L’obiettivo del planning è di identificare le storie del PB che si potranno implementare nello sprint che sta per iniziare. Si parte quindi dall’andare ad analizzare le prime storie (quelle in alto) del PB. Durante il planning, il product owner presenta le varie storie, il team le “pesa” e accetta le prime “n” che si ritiene possano essere implementate nel tempo a disposizione.
Le varie fasi del planning
La cerimonia del planning funziona in questo modo:
- Il product owner si presenta alla riunione con un elenco di storie prese dal PB e le presenta una per una al team. Non è importante quante storie egli prepari, può essere anche un numero alto, visto che poi sarà il team di sviluppo a decidere quante effettivamente accettarne. Il formato è quello tipico delle User Stories, per cui su un cartellino troviamo scritto il titolo, una descrizione del “corpo” della storia e sul retro del cartellino una serie di Acceptance Criteria (ossia i criteri che decreteranno se, al termine del lavoro, la storia potrà considerarsi completa oppure no).
- Il product owner parte dalla presentazione della prima storia della pila: egli quindi legge ogni parte della storia e il team fa tutte le domande del caso in modo da chiarirsi quanto meglio il lavoro da fare. È importante notare che in questa fase non si dovrà entrare nei minimi dettagli dell’analisi o della progettazione delle singole parti. Per esempio, non si dovranno dettagliare gli aspetti legati alla GUI o alla struttura del database sottostante. In questo momento il team dovrà solamente fare quelle domande per comprendere la complessità o meglio il peso della storia. Si tratta quindi di acquisire una conoscenza sommaria e indicativa della storia. Infatti a questo punto il dev team, quando ritiene di avere sufficienti informazioni passa a “pesare” la storia assegnandole un punteggio che ne rappresenti in modo generico la complessità o il lavoro che sarà necessario svolgere per la sua realizzazione.
- Quando si ritiene che si sia discusso a sufficienza, lo Scrum Master (SM) chiede: “OK ragazzi, abbiamo abbastanza informazioni? Possiamo passare a votare la storia?”.
- Il team effettua una stima del peso della storia: fra le varie possibilità è ormai consuetudine utilizzare la tecnica del Planning Poker (vedi oltre). Al termine della votazione la storia riceve un punteggio (o “peso”) e viene aggiunta allo Sprint Backlog.
- Si aggiorna quindi il punteggio totalizzato dallo Sprint Backlog: si tratta di sommare il totale dei punti di tutte le storie che fino a quel momento compongono lo Sprint Backlog.
- A questo punto lo SM chiede: “Vogliamo prendere un’altra storia?”. Il team nel caso in cui reputi che ci sia il tempo nello Sprint per fare altro lavoro, procede con la valutazione di un’altra storia, altrimenti si ferma e le storie che comporranno lo Sprint Backlog in quel momento saranno quelle che verranno prese in lavorazione nello sprint.
- Nel primo caso, il product owner procede nuovamente alla presentazione di un’altra storia. In caso contrario invece, il product owner prende atto e si congeda dalla riunione (inizia la fase due, che vedremo fra breve).
Lo scopo del planning
Lo scopo del planning è di seguire un approccio agile e leggero nella fase di pianificazione delle cose da fare: invece di impiegare molto tempo in una dettagliata analisi preventiva (approccio waterfall), si procede nel dare una valutazione (non completa) in un tempo rapido delle cose che ci sono da fare. È convinzione infatti che ogni ulteriore approfondimento sarebbe in questo momento uno spreco di tempo (si veda quanto detto nell’articolo precedente nel paragrafo “Il cambiamento ha un costo”).
In questo momento ogni storia accettata è quindi un “impegno a rivedersi” in un secondo momento quando quella storia verrà presa in esame e implementata: solo in quel momento si procede con il fare fare tutte le domande del caso e si svolgono gli approfondimenti per completare la raccolta delle informazioni necessarie alla progettazione e implementazione della funzionalità in esame.
Durante il planning non si vuole arrivare quindi a una stima di dettaglio: è sufficiente capire la complessità delle varie cose da fare in modo da redersi conto di quante se ne potranno fare. Anche per questo motivo lo Scrum Master guida la riunione dedicando ad ogni storia un quanto di tempo definito in modo da evitare lunghe discussioni.
Stimare le storie: il planning poker
Per fare la stima agile di ogni singola storia e stabilirne il peso, si possono seguire varie tecniche, anche se la più usata è effettuare una votazione comune tramite il gioco del planning poker [PP]. Il planning poker si basa sulla tecnica di stima Delphi [DE] inventata negli anni Quaranta, ripresa nel 1968 e affinata nel 2002 da James Grenning, ma resa popolare da Mike Cohn nel libro “Agile Estimating and Planning” [AEP].
Si tratta di un metodo di lavoro collaborativo e molto semplice, al limite del gioco. Lo scopo è cercare di far emergere il punto di vista di tutti, senza perdere tempo in discussioni inutili e noiose, ma consentendo a tutti di esprimere liberamente il proprio parere. Ogni partecipante, per formulare una valutazione sulla storia in esame, può esprimere un voto secondo la ben nota serie di Fibonacci (1, 2, 3, 5, 8, 13, 21, etc).
Per votare si possono usare delle carte da gioco opportunamente stampate (se ne trovano in commercio moltissimi tipi), dei foglietti di carta con su scritti i numeri, le mani, oppure, nella forma più moderna, delle app installate sul telefono.
Figura 2 – Con il planning poker, in un ambito rilassato e divertente, tramite carte da gioco, biglietti, le dita delle mani o una app sullo smartphone, si arriva a votare, vale a dire “pesare”, la complessità in punti di ogni storia.
Il peso delle storie
Al momento del voto lo scrum master dice: “OK ragazzi procediamo al voto: 1, 2, 3… votate!”. In questo momento, e non prima, per non influenzare gli altri, ogni membro del team alza la carta, il foglietto, la mano o lo schermo del proprio smartphone con il voto espresso.
Oltre ai canonici numeri di Fibonacci, nelle carte sono presenti anche numeri particolari come 200 o 400 (per indicare che la storia è ancora molto grande, di fatto non è lavorabile dato che si tratta di una “epica”), infinito (non ci sono informazioni per pensare a un numero) e PiGreco (PI = ho bisogno di una pausa per fare pipì) o un simbolo di una tazzina (ho bisogno di una pausa).
Normalmente alla prima votazione non si raggiunge quasi mai l’unanimità sul peso da attribuire alla singola storia: per questo motivo si isolano i voti più distanti e si procede a una breve discussione. Supponendo che i voti siano stati 2, 3, 5, 5, 3, 13, si assume che 3 e 5 siano in un qualche modo paragonabili e si cerca di capire perche’ abbiamo un 2 e un 13. Quindi chi ha votato 2 esprime le sue ragioni e lo stesso fa chi ha votato 13: in genere il “regolamento” dice che ogni partecipante ha diritto di parola per argomentare la propria idea una sola volta e al massimo un diritto di replica. Gli altri non parlano. Si vuole evitare in questa fase di dar vita a lunghe ed estenuanti (spesso sterili) discussioni: come si potrebbe far valere le proprie ragioni circa il peso di una storia? Specialmente se il team è alle prime armi con Scrum o il progetto è appena iniziato il voto spesso è frutto di una valutazione istintiva (in inglese si parla di “gut-feeling”, il sentimento “di pancia”).
A questo punto si procede a votare nuovamente e si prende come risultato finale la media (sempre riportata sul primo numero di Fibonacci approssimando per eccesso, ossia, se la media è 4, si prende 5).
Lo SM a questo punto prende dal product owner il cartellino con la storia e lo appone su una parete dove è stato deciso che verrà costruito l’information radiator dello Sprint Backlog (in genere si usa una colonna apposita della Kanban Board). Si noti che quando si travasano le storie dal Product Backlog allo Sprint Backlog l’ordine che il product owner aveva stabilito deve essere rispettato anche nella composizione dello Sprint Backlog.
Come stabilire il limite: la velocity del team
Ogni storia pesata e aggiunta al backlog di sprint aumenta la quantità delle cose da fare. Per questo motivo, al termine dell’aggiunta di ogni storia, lo SM chiede al gruppo di sviluppo se vuole prendere in esame altre storie. Se il team pensa che ci sia spazio per altro lavoro, si procede; altrimenti ci si ferma.
La domanda a questo punto sorge spontanea: come fa il gruppo di sviluppo a stabilire se c’è posto per altre storie nello sprint backlog, ovvero come fa a conoscere quante cose potranno essere fatte? Per rispondere a questa domanda il team tiene sotto controllo un altro importante parametro, la velocity o capacity del team stesso.
Questo valore esprime il numero di punti (relativi al peso delle storie) che il team è in grado di consumare nell’arco di uno sprint, ossia il numero di “cose” che il team è in grado di implementare in una iterazione. Supponiamo per esempio che la capacity sia di 22 punti, il gruppo in fase di planning andrà ad aggiungere storie allo sprint backlog fino a che la somma delle storie accettate sarà minore o uguale alla capacity di 22 punti. Questo numero esprime la prestazione che il gruppo è in grado di erogare.
La seconda domanda che segue a ruota in questi casi è “Ma quando si pesano le storie in punti, questi punti cosa sono? Ore? Giorni uomo? E come si può calcolare la capacità del team?”.
Cosa rappresentano i punti
Inizialmente nei progetti Scrum si collegavano i punti a un effort effettivo, quindi corrispondevano a ore uomo o giorni. Dato che questo approccio portava spesso a ragionare in modo waterfall (faccio l’analisi e quindi calcolo la stima in giorni che ci vuole a fare una cosa, calcolo la deadline e faccio l’offerta al cliente), con il tempo si è preferito passare a qualcosa di più astratto e meno legato a numeri, giorni e preventivi. Per questo le storie si misurano in punti, i quali non hanno nulla a che fare con ore o giorni uomo (spesso si forza la mano parlando di “punti = numero di palline rosse o orsetti di gomma”).
Per calcolare il numero di “orsetti di gomma” che il team riesce a sviluppare in uno sprint si procede in modo empirico. Partendo da ipotesi piuttosto aleatorie, il team affina la propria capacità di lavoro confrontando il valore atteso con quello realmente eseguito. Dopo un po’ di iterazioni il team, quindi, conoscendo la storia degli sprint precedenti e facendo una media degli ultimi due o tre (non di più) punteggi realizzati, saprà quanto si può aspettare di fare per lo sprint successivo.
La velocity quindi è un valore che, dopo una serie di oscillazioni ampie dei primi sprint, si stabilizza iterazione dopo iterazione, fino ad assumere un asintoto più o meno orizzontale. Il grafico riportato in figura 3 esprime esattamente questo fenomeno.
Figura 3 – La velocity del team rappresenta la quantità di cose che il team riesce a implementare in uno sprint. Si misura in punti ed è valutata in modo empirico a posteriori. Il suo valore viene sempre aggiornato, sprint dopo sprint, in modo da avere sempre un valore medio approssimativo affidabile; è un numero che può cambiare nel tempo e che si stabilizza su asintoti più o meno costanti.
Il team quindi sa che se nelle ultime 3 o 4 iterazioni ha eseguito lavoro per 30 punti, al prossimo planning accetterà storie per una somma complessiva di più o meno 30 punti. In particolare ne accetterà un po’ di più se si aspetta di poter crescere (p.e., nel caso in cui siano ormai state assorbite le tecniche legate a un nuovo linguaggio/framework/tecnologia) oppure ne accetterà un po’ meno se si trova in un momento di difficoltà (nuovi strumenti o tecnologie da imparare, difficoltà personali su membri del team e così via).
Da che valore si parte?
È lecito rimanere con un dubbio: se il meccanismo funziona con valutazioni “a posteriori”, come si fa a calcolare la velocity alle prime iterazioni, quando non vi è esperienza passata? Come possiamo sapere quale è la performance del gruppo? Di fatto non vi è modo di saperlo, per cui si va molto a sensazione. In questo caso si usa quello che in inglese viene definito “gut feeling” ossia la sensazione di pancia.
Nelle prime iterazioni il valore della velocità è quindi puramente ipotetico e poco corrispondente alla realtà; è altrettanto vero che pure le performance del team alle prime iterazioni, quando tutto è nuovo, sono altamente variabili e dipendenti da fattori difficilmente identificabili.
Ogni tentativo di affinare tale valore è in questa fase uno spreco di energie, viste le poche informazioni disponibili; tanto vale provare ad affidarci all’intuito, immaginare un valore e verificare al primo giro quanto tale numero si è discostato dalla realtà. Quasi sicuramente la pianificazione non sarà attendibile: il fail fast del Lean ci dice che questo non è un problema, basta accorgersi dell’eventuale errore il prima possibile e provare a raddrizzare la curva. Grazie a una attenta retrospettiva, in poche iterazioni il team è quindi in grado di capire quale sia la propria velocità. Dopo poco tempo stima e valore effettivo finiscono per avvicinarsi: non ci sarà mai totale sovrapposizione fra le due curve, dato che ogni sprint ha delle peculiarità e differenze dagli altri e quindi c’è sempre una differenza. Più che preoccuparsi dell’errore assoluto è utile monitorare questo scarto, allarmando nel caso di evidenti e improvvise variazioni.
Alcune risposte a domande frequenti
Chi pianifica e come gestisce il backlog? È una cosa che possono fare tutti i membri del team?
Come si è più volte detto, Scrum impone una serie di regole ferree circa i ruoli, i compiti e le responsabilità delle varie persone del team.
Più volte si è sottolineato che il product owner è l’unico responsabile su cosa debba essere presente nel backlog, mentre, come si è appena visto, è il dev team che decide, per ogni sprint, quali storie inserire all’interno dello sprint backlog. Durante il planning si è potuto vedere come il cerimoniale dia mandato al product owner di presentare la lista ordinata delle cose da fare, mentre è compito e responsabilità del team di sviluppo di accettare quali di queste storie travasare nello Sprint Backlog (il travaso deve rispettare l’ordine proposto). È un fatto questo che in genere non porta a particolari conflitti fra i due ruoli: è noto a tutti che è una regola e non può essere infranta. A volte però questo può dar luogo a qualche problema se il risultato altera le attese o i piani del product owner.
Si immagini per esempio che il product owner abbia pianificato che nel prossimo sprint il gruppo di lavoro porti in completamento le prossime 5 storie presenti nel product backlog. Durante il planning invece il gruppo di sviluppo, comparando la somme delle stima delle storie con la velocità misurata alle iterazioni precedenti, decide di accettare solo 4 storie. Resta fuori quindi una storia, la quinta. Notare che il product owner ragiona a numero di storie, il dev team a punteggio complessivo da lavorare.
Supponiamo che in questo caso, questo fatto possa rappresentare un problema dal punto di vista della pianificazione del prodotto: il product owner infatti valuta importante che si possano concludere tutte e 5 le storie o addirittura solo la quinta; la motivazione potrebbe essere legata al poter eseguire una demo con il cliente o per eseguire un rilascio su ambiente di test tale da permettere agli utenti di iniziare a fare delle prove.
Dato che non può imporre l’accettazione della quinta storia, potrà fare in modo che questa sia messa in lavorazione per esempio mettendola al posto di una di quelle già accettate (ricordiamoci che il product owner ha potere di variare l’ordine della pila del backlog). In alternativa può procedere ad alleggerire (story slicing si “affettano” più sottilmente le storie) una o più di una delle storie in modo che il peso complessivo delle 5 storie diminuisca e il team possa quindi accettare anche l’ultima. Ciò che viene tolto da una storia verrà poi aggiunto dal product owner a una nuova storia creata ad hoc per uno sprint successivo.
Lo slicing delle storie è una tecnica molto importante ed è una delle cose più potenti di Scrum; la vedremo meglio quando parleremo di user stories, ovvero quando scopriremo che le storie devono essere INVEST, dove la N sta per negoziabili.
Cosa accade se durante lo sprint ci si rende conto che il peso attribuito a una storia era eccessivo o troppo piccolo?
Nulla, si tiene conto di quanto verificato e se ne fa tesoro per le iterazioni seguenti. L’obiettivo è fare in modo che il gruppo acquisisca maggior consapevolezza dei propri mezzi, in modo da avere una maggior capacità di valutazione delle storie al planning successivo.
Come si può affinare la consapevolezza di cosa il team riesce a fare? E come migliorare le capacità di valutazione delle storie?
Entrambe queste capacità sono allenate dal team in modo incrementale e iterativo. Per questo si ammette di sbagliare ma si è consapevoli anche di poter migliorare iterazione dopo iterazione. Ed è per questo che al termine di ogni iterazione si valuta cosa è andato bene e cosa no. Nel caso specifico, dopo ogni sprint si cerca di capire se le ipotesi di stima erano corrette oppure no.
L’obiettivo quindi è di addestrare un modo di lavorare “adattivo”: si cerca di perseguire la stabilizzazione delle stime tramite l’osservazione sperimentale sul campo. In tal senso, dato che le variabili in gioco sono molte e possono cambiare non di poco fra sprint e sprint, si deve cercare di minimizzare le alterazioni su cui si ha potere di intervento; è importante per esempio non modificare lo sprint backlog dopo che il planning è concluso e il lavoro di implementazione è iniziato. Si accetta di apportare modifiche a tale struttura solo in concomitanza di gravissimi eventi che possano portare a cambi di rotta, vision, obiettivi. In genere di parla di Sprint Failure.
Per lo stesso motivo è estremamente importante non variare i parametri di lavoro: dato che la velocità indica il numero (più precisamente il peso complessivo) delle cose che possono essere fatte, non si dovrebbe mai modificare ne’ la durata degli sprint, ne’ la dimensione del team. In tal caso infatti tutte le indagini statistiche verrebbero a perdere di significato. Ovvio che se si ritiene necessario intervenire in tal senso, per motivi molto importanti, per esempio per inseguire importanti obiettivi di business, lo si potrà fare, ma si dovrà mettere in conto un degrado delle prestazioni dovute al tempo necessario per ricreare le condizioni di stabilità a regime del team.
Per lo stesso motivo si cerca di stabilizzare, oltre alla lunghezza dello sprint, anche la cadenza. Non vi sono regole definite dal framework, per cui si cerca di allineare il lavoro alle consuetudini del gruppo e delle convenzioni aziendali o sociali. È comodo quindi allineare l’inizio dello sprint al lunedì e farlo terminare il venerdì, anche se poi in teoria nulla vieta di spostare in avanti o indietro tale schema.
Product owner e dev team possono negoziare l’ordine delle storie? Se ci sono propedeuticità tecniche che il product owner non è in grado di valutare, come ci si comporta?
Abbiamo detto che l’ordinamento delle storie all’interno del backlog è una responsabilità del product owner. Il backlog è quindi una struttura a pila da cui si preleva dall’alto senza saltare alcun elemento. L’ordine delle storie è deciso dal product owner perche’ tale ordine è funzione di precise strategie di rilascio e di costruzione del prodotto, ossia segue logiche di business che sono chiare sopratutto al product owner.
Il gruppo di sviluppo può contrattare nel caso in cui si si evidenzino propedeuticità tecniche che sarebbe meglio rispettare: se per esempio l’ordinamento prevede che si debbano realizzare le storie 122, 123, 124, 125 e 126, ma la 125 è necessaria per la realizzazione della 123, il team farà presente questo problema. Se il product owner valuta che si può procedere al riordinamento, allora si potrà effettuare l’inversione nello sprint backlog di conseguenza.
Nel caso in cui il product owner reputi necessario non alterare tale ordine, si dovrà realizzare la 123 in modo da simulare (per esempio con componenti mock o stub) le funzionalità offerte dalla 125 e poi solo in un secondo momento procedere alla 125.
Grazie a questo modo di agire, se per un motivo qualsiasi il team accusasse un ritardo nel completare una o più delle storie, se qualcosa rimane fuori dalla demo finale, abbiamo la certezza che rimarrà sempre quella, delle cinque, con importanza minore rispetto alle altre.
Un altro motivo per cui si può modificare l’ordinamento è per comporre meglio la somma dei punti e aggiungere magari qualche storia senza sforare il punteggio massimo corrispondente alla capacity del team. Anche in questo caso si potrà procedere, ma solo con l’accordo del PO. Sebbene questi casi non siano particolarmente frequenti, è bene tenerne conto, proprio per rispettare l’impostazione di Scrum e sfruttarne tutta l’efficacia.
Chi partecipa allo sprint planning?
Devono partecipare il product owner (obbligatorio, è lui che presenta e spiega l’elenco delle storie da realizzare), il dev team (deve valutare ogni singola storia in modo da comprenderne peso o complessità) e lo scrum master (se non è parte del dev team, il suo ruolo in questo caso è quello del “cerimoniere” per far rispettare tempistiche e sequenza delle varie attività). Se manca il product owner non si può fare planning, quindi in questo caso non si potrebbe iniziare il lavoro.
L’assenza del product owner potrebbe essere dovuta a vari motivi: se impegnato in riunioni con il management, bloccare il lavoro del team potrebbe essere un buon modo per far capire a chi di dovere che, senza le debite condizioni, il lavoro non può procedere; non è colpa di Scrum o del team se poi il lavoro fatto non rispetta in alcun modo le attese o i requisiti richiesti.
Se l’assenza del product owner fosse da imputarsi al product owner stesso (p.e., malattia o impegni personali inderogabili) sarà molto importante far comprendere la gravità della cosa al diretto interessato, suggerendo per la prossima volta per esempio la necessità di tenere allineato un “vice-PO”.
Quanto dura uno sprint planning?
Normalmente si dice che deve durare 2 ore per ogni 5 giorni di sprint; quindi se si è deciso di far durare lo sprint planning due settimane (10 giorni di calendario lavorativo) la pianificazione durerà 4 ore.
Ma allora quanto dura uno sprint? E chi lo decide?
Uno sprint può durare da un minimo di una settimana a un massimo di quattro. Sotto i 5 giorni di lavoro, il tempo necessario per la gestione delle varie attività (handover) supera il tempo che si dedica effettivamente all’implementazione delle storie e si rischia di non riuscire a prendere o tenere un ritmo sostenibile ed efficace. Sopra le 4 settimane diventa troppo lungo il tempo fra un check e un altro: a fine sprint si devono fare demo del prodotto e retrospettiva del processo. Dato che la regola delle metodologie agili è di provare e verificare, di non pianificare troppo ma accettare di fallire (fail fast), è importante che questo sia fatto sempre tenendo sotto controllo la situazione. Se intraprendo una strada che inizialmente non so se sarà sbagliata o meno, devo poterlo fare con la massima serenità, conscio che il rischio è controllato. Si effettueranno controlli frequenti e ricorrenti. Per questo le iterazioni non possono essere troppo lunghe. È presente anche un effetto memoria per cui dopo tanto tempo ci si dimentica o si perde contatto con quanto successo per esempio all’inizio dello sprint. Per quanto concerne la scelta della durata dello sprint, non c’è una regola precisa. In genere si cerca di unire necessità dell’azienda, del team, delle persone. Normalmente è una decisione che viene presa dal team (se ha esperienza), oppure suggerita da un coach esterno (se siamo alle prime armi con Scrum) o infine “pilotata” dal management se ci sono indicazioni particolari.
Si tenga presente che nella maggior parte dei casi la lunghezza adottata è di 2 settimane. Con team esperti e se il tipo di lavoro lo permette (per esempio le storie sono naturalmente e facilmente confezionabili in modo che siano piccole) si può scendere a una settimana. Su progetti molto grandi, a volte si passa alle tre settimane.
Come concludere il planning
Dopo che il team ha accettato un numero di storie tali da equiparare la capacity prefissata, la prima parte del planning termina. A questo punto il product owner lascia la riunione e il resto del gruppo effettua qualche verifica per controllare che l’impegno preso sia effettivamente compatibile con le possibilità del gruppo. Un modo è quello di procedere alla scomposizione delle storie in task, ovvero provare a capire quali siano le sotto-attività necessarie per completare ogni storia. Vedremo meglio questi aspetti quando parleremo di storie: per il momento ci basti dire che una storia è l’unità elementare quando si parla di backlog, ma dal punto di vista meramente operativo per comodità viene poi scomposta in sotto parti per semplificarne la realizzazione. Un modo semplice di dividere la storia per esempio è quello di individuare le classiche parti tipiche del ciclo di vita del software (analisi, design, implementazione, test, documentazione). Un altro modo può essere quello di frazionare in verticale la storia come se fossero le fette di una torta (p.e., se di tratta di un CRUD, dividere la storia nelle 4 parti C, R, U, D).
E le ore di lavoro?
Fatto ciò si prova a dare un peso questa volta in ore, delle singole attività; su piccole attività è concesso lasciare gli “orsetti di gomma” e passare alle ore. Per esempio per una storia stimata 8 punti si trova che è scomponibile in 8 ore di analisi, 4 di design, 16 di implementazione e 4 di test (numeri buttati qui a caso). Non c’è alcuna formula che traduca i punti in ore, anche il solo pensiero che si possano collegare è un errore. Sono due grandezze incomparabili. Al più si può osservare che una storia stimata in 5 punti non dovrebbe risultare poi scomponibile in attività che richiedano più ore di una che pesa 13; anche se poi, se dovesse succedere, non è uno scandalo.
A questo punto si sommano le ore ottenute da tutte le storie e si procede a verificare che tale totale sia comparabile con le ore a disposizione nell’arco di tutto lo sprint. Per esempio se si è stabilito che lo sprint debba durare 10 gg, avremo a disposizione 560 ore se il team è composto da 7 persone equivalenti fra loro, ossia dove tutti fanno tutte le attività, dall’analisi all’implementazione. Questo 560 deve poi essere diminuito di un fattore (focus factor) legato alla produttività effettiva: nessuno lavora sempre al 100% delle proprie possibilità. Statisticamente, per un team medio, tale valore è stabilito in un 15%. Se il team è alle prime armi meglio aumentare a un 20%. Si deve poi togliere un’altra percentuale corrispondente al totale delle ore che si dedicheranno ad altro (leggere mail di lavoro extra progetto, attività amministrative, espletare bisogni fisiologici etc.).
Complessivamente e in maniera approssimativa si toglie in genere un 30%: per cui le 560 ore diventano 392. È un numero approssimativo che deve essere confrontato a grandi linee con la somma delle ore necessarie per completare tutti i task. Fra i due non deve esserci precisa equivalenza, ma almeno una qualche vicinanza; appare ovvio infatti che se il monte ore disponibili a calendario è molto lontano dalle ore necessarie per fare i vari task è probabile che sia stato fatto qualche errore nel conteggio delle storie o della velocity del team.
Al termine di tale indagine si chiamerà nuovamente il product owner e si comunica la decisione: se il team conferma che si accettano le storie si può procedere, altrimenti si procede a una ulteriore negoziazione. Il planning quindi termina e si dà inizio allo sprint vero e proprio.
Alcuni aspetti rimasti in sospeso
Quello che abbiamo visto in questo articolo rappresenta una parte delle attività legate allo sprint, vale a dire la pianificazione delle cose da fare che, come abbiamo visto, è legata alla performance del gruppo. Restano ancora molti aspetti da approfondire, come per esempio cosa succede se il gruppo di sviluppo consuma tutte le storie che si erano pianificate nello Sprint Backlog, oppure come gestire eventuali anomalie come l’interruzione a metà di uno sprint. Questi temi verranno affrontati in una delle prossime puntate, quando parleremo di Grooming (o “raffinamento” del backlog) e del come prevenire il prosciugamento della pipeline di lavorazione (“DryPipeline”) tramite l’utilizzo dello Sprint Buffer, che dalle mie parti si chiama il “frigorifero delle storie già pronte”.
Riferimenti
[DE] La pagina Wikipedia del Metodo Delphi
http://en.wikipedia.org/wiki/Delphi_method
[PP] Planning Poker, lo strumento per effettuare le stime sulle storie utente
[AEP] Mike Cohn, “Agile Estimating And Planning”, Prentice Hall, 2005