Misurare lo sprint, la burndown chart

Posted on by

burndown_chartSul muro della stanza del team c’è un grafico molto semplice, riporta i giorni di uno sprint sull’asse delle ascisse e gli story point sull’asse delle ordinate. Il grafico si chiama sprint burndown chart: ogni volta che si chiudono una o più storie in un dato giorno dello sprint, la somma degli story point viene sottratta alla totalità iniziale. Non mi dilungo a spiegare i concetti di sprint e story point, li do per scontato altrimenti finirei per dare una struttura frattale e potenzialmente illimitata a questo post.

Alla fine del planning lo scrum master traccia una linea retta dal giorno 0 e story point totali previsti per quello sprint fino all’ultimo giorno a story point 0; questa è la linea ideale di rilascio lineare di story points dall’inizio alla fine. Quindi, alla fine di ogni giornata, segna invece gli story point delle storie messe quel giorno in stato done, o meglio to be reviewed; la linea che unisce questi punti è l’andamento reale dello sprint, chiamato sprint burndown chart.

Ed ecco la rivelazione. Quanto più la linea è aderente o quanto meno parallela alla linea ideale, tanto più la totalità delle pratiche metodologiche prescritte dallo scrum saraà stata eseguita con successo. In altre parole, la linea reale è vicina all’andamento teorico se le user stories sono piccole e cross funzionali (cioè tagliate in modo da poter essere lavorate con poco tempo da più membri del team), il team è concentrato sul lavoro e meno distratto da pratiche non funzionali al raggiungimento del goal dello sprint corrente (compresa l’attività di grooming per lo sprint successivo), la definition of ready delle user stories è stata valutata con attenzione, le user stories sono state realisticamente valutate, il tester è abilitato a lanciare i suoi test etc.; tutto questo influisce sulla capacità del team di chiudere user stories in maniera uniforme e continuativa, senza eccessivi accumuli di work in progress.

Ecco una sprint burndown chart. Rappresenta l’andamento di uno sprint fantastico, in cui tutto è andato come i migliori manuali di scrum prevedono. La linea rossa rappresenta l’andamento teorico, quella verde l’andamento reale del rilascio di story point. Sin dal primo giorno il team si è portato in vantaggio con il lavoro chiudendo la prima storia il secondo giorno, probabilmente perché il lavoro di planning e divisione in task previsto per il primo lunedì era stato abbastanza veloce da consentire al team di lavorare e chiudere una storia.

Nei giorni successivi altri story points sono stati macinati con una certa continuità, a parte un moderato rallentamento nei primi giorni della seconda settimana, avendo preso in carico storie più complesse.

Anche questa è una bella burndown chart, anzi forse addirittura più bella della precedente. Dopo il primo giorno di planning e il secondo di lavoro il team ha iniziato a rilasciare parti di codice completi e pronti per la revisione con una continuità assoluta, per cui la curva verde si presenta del tutto parallela alla linea ideale. Con poco sforzo finale il team ha concluso lo sprint con il rilascio di tutti gli story point stimati.

Ecco una burndown chart brutta. Forse il team ha aperto storie in contemporanea per 20 story points, o forse le attività di test sono rimaste bloccate per troppo tempo. Di certo, Giovedì 10 Maggio è stata una brutta giornata per il team

No comments Posted in Uncategorized

Aspettando la sprint review

Posted on by

C’è un’aria di tensione sospesa la mattina della review, un’atmosfera satura di elettricità che non sentivo dai tempi degli esami all’Università.

Il giorno di review è il Venerdì che già di per se si vive sempre con una indefinibile sensazione di rilassato piacere per la settimana che finisce; è il giorno dello slack time dedicato alla propria formazione, non ci sono richieste di interventi perché tanto qualunque modifica non potrebbe essere messa in produzione (“se poi succede qualcosa quando non ci siamo?”), eppure se il Venerdì sa di sospiro di sollievo questa attesa prima della review è l’inspirazione prima del sospiro.

Il prodotto che seguo come Product Owner ha un numero incredibile di stakeholders, o clienti interni che dir si voglia, distribuiti in 8 sedi diverse di cui 6 in altri paesi europei. Oggi si collegheranno da Bergamo, Barcellona, Worcester (UK), Eindhoven (NL), forse Parigi, saranno connessi parte tramite Polycomm video conference e parte in Skype, dovranno condividere tutti lo schermo che vedremo qui in sede, ascoltare le presentazioni che verranno fatte (inglese obbligatorio anche per chiedere di andare al bagno), interrompere la review, commentare e chiedere variazioni, potranno persino bocciare una user story e rimandarla al mittente. Qualcuno esprime il suo sogno di lanciare la sigla dell’Eurovisione RAI all’inizio della review.

Sul tavolo ci sono i bignè dell’amicizia, i manuali di scrum dicono che l’apporto di zuccheri favorisce la condivisione e crea una associazione mentale tra dolcezza e pratiche scrum, ma sarà difficile rilasciare questa sensazione di benessere via Polycomm quindi l’effetto glicemico sarà limitato al team e agli stakeholder presenti in sala.

Il team però ora è concentrato, oggi c’è anche il coach scrum e il team sente l’importanza della prossima ora e mezza come un raccolto di ciò che è stato seminato e coltivato con tanta cura nell’ultimo sprint di due settimane; il tester prova le ultime procedure, lo scrum master verifica le attrezzature per la call conference e contatta gli stakeholder, c’è un po’ di parapiglia, chi non risponde e chi prova a collegarsi senza riuscirci, chi è già collegato e chi non si sa se arriva.

Ore 11.00 si parte, il Product Owner (cioè io) dà il benvenuto e cerca di esprimere quanta più gioia possibile dall’avere tanti stakeholder alla propria review, la presenza del main stakeholder da Worcester mi rende un po’ nervoso ma mi ripeto che andrà tutto bene, la presenza del team alle spalle mi da energia. Fino a qui tutto bene.

No comments Posted in Uncategorized

Incontrare chi investe in noi

Posted on by

Con il termine stakeholder si intende uno sponsor del progetto che il Product Owner sta seguendo, un super cliente interno all’azienda o comunque uno di quelli che, sul vostro progetto, ci mette il soldo.

Già da questa definizione si capisce che uno sbadiglio del vostro stakeholder è peggio di una critica del vostro capo: non avete interessato il vostro investitore, non lo avete eccitato con quello che avete rilasciato.
Male.

Da lì in poi la situazione è tutta in salita, ma recuperabile.
Ci sono fior di capitoli dedicati al coinvolgimento dell’investitore, dai piccoli dettagli dei pasticcini offerti in review agli incontri one to one di preparazione e di retrospettiva di ogni review: ho scoperto quanto gli investitori siano timidi e quante cose emergano da incontri personali (“volevo dirlo in review, ma non me la sentivo in inglese”, “non volevo che il mio commento portasse alla bocciatura della user story”, “mi scocciava fare una critica in pubblico”).
Io spendo decine di ore in incontri con i miei stakeholders e non sembrano mai bastare; se l’investitore tiene davvero ai propri soldi non sarà mai sazio di incontri e presentazioni personalizzate e revisioni del planning e dei rilasci.
Non si tratta di una mera attività diplomatica: è uno scambio nelle due direzioni, un processo per rendere permeabile quella membrana di diffidenza o timidezza che altrimenti sarebbe impermeabile.

Un’altra tecnica scaccia-timidezza si basa sui feedback anonimi.

Le nostre review attualmente si chiudono sempre con un survey inviato alla lista degli stakeholder. Il survey è anonimo e brevissimo (4 domande, con risposte multiple, e campi di testo solo per chi vuole aggiungere qualcosa).
Allo stakeholder è richiesto un breve giudizio sulla qualità della review, in termini sia di comunicazione che di contenuti espressi, quindi viene chiesto l’argomento preferito, e infine si entra nel dettaglio del rilascio più importante, chiedendo il grado di apprezzamento del prodotto ed eventuali commenti.

No comments Posted in Uncategorized

Comprehensive user story

Posted on by

Tutti quelli che lavorano in scrum hanno una decisa confidenza con la user story, essendo questa l’elemento cardine del lavoro quotidiano sia del Product Owner, che le crea, che del team di sviluppo, che le trasforma in rilasci incrementali.

Una user story, si sa, rappresenta una singola funzionalità, o comunque uno sviluppo che risponde alla richiesta di un cliente o di uno stakeholder. Tanto più la funzionalità di una user story sarà isolata dalle funzionalità adiacenti, cioè tanto più sarà atomicamente tagliata, maggiore sarà la semplicità di trattamento della stessa.

Esiste un concetto che onestamente ho scoperto da poco di Comprehensive user story.

Per capirne la definizione, partiamo dalla struttura di una user story:
In quanto…. attore che beneficerà della funzionalità
voglio che… la funzionalità
così che… beneficio che deriverà dalla funzionalità
Acceptance criteria 1…n: sono criteri che vengono imposti alla realizzazione della funzionalità e integrano il default della definizione di done. Ad esempio:
– attore deve fare cliccare sul tasto e scatenare l’azione
– se l’attore non clicca sul tasto l’azione non si scatena

Eccoci al punto. La comprehensive user story parte dallo stesso presupposto di definizione funzionalità ma usa l’occasione fornitagli dagli acceptance criteria per immaginare tutti i possibili percorsi alternativi, o almeno quanti più possibile, quindi:
– attore deve fare cliccare sul tasto e scatenare l’azione
– se l’attore non clicca sul tasto l’azione non si scatena
– attore clicca su tasto, se sistema va in timeout esce messaggio x
– attore non capisce che deve cliccare il tasto per scatenare l’azione, legge help contestuale
– attore clicca sul tasto ma la batteria del laptop finisce; rientrando più tardi potrà verificare se l’azione è andata a buon fine e nel caso rilanciarla.
L’uso di CUS assicura che i membri del team e il product owner mantengano una visione completa delle varianti, minimizzano l’errore di usabilità, aiutano il tester a definire i test case. D’altronde la CUS può solo nascere da un lavoro di concerto tra Product Owner e tester, che meglio di ogni altro ha l’elasticità mentale e l’abitudine necessari a impersonificare le personas e ipotizzare scenari.

Non sono del tutto sicuro che ci sia una differenza così netta tra una Comprehensive User Story e una semplice User Story ben fatta, in altre parole non sono convinto della necessità di una ulteriore classificazione dei backlog items; in ogni caso cercherò di applicarne i principi e trarne i benefici a prescindere dal suo nome.

No comments Posted in Uncategorized

Chi scommette sul fallimento del progetto (e viene pagato per questo)

Posted on by

C’è un ruolo nel team che scommette sul fallimento delle storie. Cerca l’insuccesso con i clienti. Ama trovare la magagna.

E’ il tester.

Tutto il team, PO compreso, desiderano creare valore in un clima di zelante ottimismo. Il ruolo di tester invece prescrive la ricerca dell’insuccesso di una user story: questo fa della persona che ricopre tale ruolo un elemento chiave del team, in quanto lui solo si sente votato alla ricerca del fallimento.

Persino il PO, più o meno consciamente, desidera il successo delle user stories e ne vede il fallimento come un impedimento al normale procedere del progetto, così che lui stesso diventa il peggior nemico della qualità di quello che viene rilasciato, a volte anche accettando una certa quantità di debito (tecnologico o di usabilità) pur di rilasciare la funzionalità. Per sua fortuna il tester non ha pietà.

In “lessons learned in sofware testing” la cosa prende una piega epica: “sull’isola dei tester essi erano destinati per sempre a cercare ciò che non potrebbe e non dovrebbe esistere, sapendo che avere successo porterà miseria agli Dei”.

Parlando di tester il mio coach era stato ancora più illuminante.
Citando Diana Larsen ha presentato il valore del ruolo di tester come l’effetto di arricchimento intellettivo apportato da un elemento di eterogeneità: se in un team di sviluppatori si inseriscono dei designers, o se in un team di soli maschi si inserisce una signorina (questo era proprio l’esempio fatto), l’effetto è un ampliamento della curva gaussiana delle possibilità di variazione del punto di vista e quindi della soluzione a un problema logico o tecnico, e di fatto un ampliamento statistico del range di variabilità, e di fatto un miglioramento della qualità.
L’introduzione di un tester, che ha una visione esattamente speculare a quella di un qualsiasi altro team member, è un valore inestimabile per un qualsias gruppo di lavoro.

No comments Posted in Uncategorized
« Older Entries Recent Entries »