Tag Archive for metodologia

Si può misurare la produttività (anche se non produciamo spilli)?

Posted on by

Se producessimo spilli sarebbe senza dubbio più semplice: oggi facciamo 10mila spilli al giorno, ottimizzando i processi e migliorando la catena produttiva il prossimo anno potrei produrne 30mila al giorno.
Poi un giorno inizierei a chiedermi: sono sicuri che valga la pena lavorare ancora sugli spilli? e non forse produrre linguette adesive che non forano il tessuto?
Allora inizierei a produrre le linguette, ma ecco che se volessi fare un mero conto della serva e monitorare la capacità produttiva della mia fabbrichetta non potrei certo confrontare l’anno 2 (quando producevamo spilli) con l’anno 3 (quando una parte inizia a produrre linguette, con un processo industriale totalmente diverso che mi porta inizialmente a produrne 5000 al giorno). E l’anno 4? ancora diverso, le linguette vanno a ruba e parte della produzione si sposta su quello ma una parte di clienti ha ancora bisogno di spilli, e il 30% della produzione resta ancorata a questo prodotto legacy.

Questo semplice esempio dimostra che misurare la produttività non è semplice nemmeno per chi produce spilli, in realtà.

Ma se un importante stakeholder ti chiede un giorno di definire un KPI per misurare come cambia la produttività del team, sicuramente un po’ di fatica mentale ci deve essere dedicata.
Abbiamo affrontato l’argomento in una community of practice interna, dedicata alla metodologia: un gruppo di product owners e scrum masters che inizia a buttare giù qualche idea ricordando che, per definizione, un indicatore di performance (KPI) deve essere SMART
Specifico, come motivazione di business che vuole misurare
Misurabile, per fornire un vero valore oggettivo
Achievable (raggiungibile) altrimenti si chiama utopia
Rilevante per l’azienda, altrimenti misura
Time oriented, cioè definibile in un intervallo di tempo.

Inoltre, misurando la produttività del team e non dell’intera azienda, non può posizionarsi troppo lontano nel processo aziendale per non rischiare di essere influenzato da variabili esterne su cui il team non ha controllo: quindi niente misuratori di ricavi o risparmi.

La conclusione (parziale) non è stata esaltante: esistono tali e tante variabili che sembra quasi impossibile monitorare la produttività.
Un paio di idee abbastanza interessanti, per lo meno come spunti di riflessione, sono state le seguenti.

Misuratore del tempo produttivo.
Risponde alla domanda: quanto tempo impiega il team su attività che portano un effettivo deliverable?
Abbiamo ipotizzato un rapporto: tempo totale impiegato sulle attività di sprint (e registrato in Jira, il nostro project management tool) DIVISO il tempo totale lavorato in uno sprint.
La parte restante di questa percentuale è attività non meglio precisata, attività reattiva (supporto, bug fixing), meeting e cerimonie, richieste non in sprint etc.
Il limite principale sta nella capacità che hai il team di loggare con precisione e onestà i tempi lavorati in sprint.

Misuratore di capacità di erogare deliverable
Risponde alla domanda: quanto prodotto è capace di erogare un team?
Abbiamo assunto che su lunghi intervalli di tempo la dimensione delle user stories fosse sufficientemente omogenea e di conseguenza il valore (in termini non economici ma di quantità di servizio erogato) fosse ben confinato all’interno dei limiti di una storia: quindi numero di storie erogate in uno sprint DIVISO il numero di team member, allo scopo di normalizzare questo parametro in funzione delle naturali variazioni di un team nel tempo.

Per adesso, comunque, la decisione condivisa co lo stakeholder è stata di abbandonare questo tentativo; la messa a punto di queste misure è troppo onerosa e il risultato tutt’altro che garantito.

Per ora, la risposta alla domanda nel titolo è: NO.

No comments Posted in Uncategorized

Grooming e socialismo reale

Posted on by

groominggrooming / ˈgruːmɪŋ/n. strigliatura f., preparazione f., governatura f.;

In agile si chiama grooming la gestione quotidiana del product backlog, che comporta l’ordinamento delle user stories in ordine di priorità, la divisione delle user stories troppo grosse, la cura delle descrizioni e dei contenuti di ciascuna user story, fino ad arrivare a un backlog che sia più vicino possibile al modello stratigrafico di deposito fluviale (geologi si nasce, qualunque altra cosa si diventa!): elementi grossolani e irregolari in basso, elementi fini e ben lavorati in alto.

Il grooming è una attività che spetta principalmente al Product Owner e in parte al team, con e senza il suo PO: per estensione siamo spesso soliti chiamare grooming gli incontri in cui PO e team lavorano insieme alla preparazione del backlog. In questo senso il grooming è una preziosa occasione di condivisione dei punti di vista, un punto di incontro tra le richieste del cosa (di cui il PO si fa portavoce) e quelle del come.

Non ho trovato mai indicazioni univoche su come organizzare un grooming, credo che nessun Cohn o Schwaber se la sia mai sentita di dare prescrizioni su qualcosa che può avere un’immensa variabilità in dipendenza di tantissimi elementi (team, product owner, tipo di progetto, stadio di maturità del progetto…). Voglio scrivere due cose su come noi siamo stiamo organizzando i nostri incontri di grooming in questo momento: in atmosfera assolutamente agile non è escluso che possa cambiare del tutto idea tra un mese.

Io e il mio team facciamo 2 incontri di grooming generale ogni sprint (che per noi sono di due settimane).

Il primo incontro è l’occasione per volare un po’ più in quota del solito e dare un’occhiata al progetto dall’alto, facciamo previsioni su dove saremo al prossimo sprint e a quello successivo e li contestualizziamo nel planning generale del progetto.

Condividiamo le nostre priorità almeno per i prossimi 6-8 sprint, quindi 4 mesi, e con questo orizzonte diamo un senso alle attività previste per i prossimi due sprint. Si fa una sorta di brainstorming moderato, ci si allinea sugli obiettivi.

E’ un incontro molto bello che i membri del team vivono come una nuova ed emozionante esperienza di partecipazione.

Il secondo grooming generale è invece molto più di dettaglio: si discute davanti a un lista di tasks, o meglio user stories, già abbastanza ben definite e ordinate, si finisce di discutere eventuali punti oscuri e si fa una prima stima di story point per facilitare il lavoro del Product Owner di organizzazione delle priorità e definizione del set definitivo di storie da portare al planning.

Poiché il primo incontro porta ad una analisi molto di massima e il secondo è per contro uno studio molto di dettaglio è chiaro che in mezzo ci deve essere un grosso lavoro di definizione delle user stories e di scomposizione delle attività troppo grandi. Al momento la soluzione più fruttuosa e meno dispendiosa per tutti è stata quella di organizzare dei grooming separati con singole persone o piccoli gruppi (es. con tester, con designers, con sviluppatori di backend, di frontend etc.) e concentrare in questi mini incontri la maggior parte del faticoso lavoro di mediazione tra i diversi punti di vista del “come fare” e del “cosa fare”.

Diciamo che è una soluzione aperta: nei primi 10 sprint della mia vita ho già cambiato pensiero almeno 5 o 6 volte e non posso escludere che anche il processo che ho illustrato possa avere delle modifiche in futuro; diciamo solo che per ora funziona abbastanza.

No comments Posted in Uncategorized

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

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
« Older Entries