| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

ReportMeet20060927

Page history last edited by Zoltar 17 years, 6 months ago

Meet, 27 settembre 2006. Tema: XP Game!

 

L'incontro di questa sera fa parte della serie alternativa rispetto al nostro tradizionale lavoro: ci occupiamo di business! E stasera in particolare ci occupiamo di capire meglio il planning agile (foto).

 

Lo strumento è lo XP Game, inventato dal mitico Pascal Van Cauwenberghe, già nostro ospite. Di che si tratta? E' una simulazione in cui si formano più team che competono per ottenere il massimo valore di business.

 

Il valore di business è il motivo per cui lavoriamo. In cosa consista questo valore dipende dal contesto; per esempio c'è chi lo definisce semplicemente come il fatturato. E' importante tenere sempre presente che non lavoriamo per risolvere problemi interessanti.

 

Il team a volte porta il cappellino del cliente, e a volte il cappellino dello sviluppatore. Ci sono delle carte già fatte, che rappresentano storie tipo "costruisci 10 cappelli di carta" o "gonfia 5 palloncini fino a 40 cm di circonferenza" (giuro!). Il team ha a disposizione 180 secondi per l'implementazione. C'è un tempo molto più ampio per pianificare, per eseguire spike, per organizzare il lavoro.

 

Ci sono tre iterazioni, durante le quali si calcolano la velocità ottenuta da ciascun team, e il valore di business.

 

Lezione importante: si può confrontare il valore di business ottenuto dai vari team, ma non ha senso confrontare la velocità. Quest'ultima può essere confrontata solo all'interno di un dato team (la nostra velocità è aumentata, o è diminuita) ma non è confrontabile a quella di un altro team.

 

Questa sera abbiamo formato 2 team di 4 e 5 persone. Il facilitatore del gioco ero io (Matteo) mentre i coach dei due team erano Fabio e Simone.

 

Il coach ha (fra l'altro) il compito di mantenere alto il livello di qualità, verificando che il lavoro presentato dal team passi i test di accettazione.

 

Ho ammaestrato i due coach in dieci minuti; è stato facile perché già sapevano come funziona il planning. Poi ho fatto una breve introduzione alle regole del gioco. Quindi siamo partiti con l'implementazione.

 

All'inizio il team non sa quale sia la sua velocità, per cui si fa una stima: si prende la storia più facile (che per definizione vale due punti) e si stima in quanti secondi si pensa di poterla svolgere. Da qui si stima la velocità con la formula

 

velocità stimata = 2 * 180/(tempo stimato per la storia più facile)

Il team di Fabio ha stimato 18, quello di Simone 9. La dura realtà è stata ben diversa: nella prima iterazione FabioTeam ha ottenuto velocità 5, e SimoneTeam velocità 4.

 

La velocità è un valore misurato, non stimato.

 

E nel nostro caso si misura come somma dei punti difficoltà di tutte le storie realizzate nell'iterazione. E' chiaro che i due team hanno sottostimato alla grande la difficoltà delle storie. Peraltro, il valore di business ottenuto dai due team nella prima iterazione è stato identico.

 

Nella seconda iterazione, i team cominciano a ingranare, particolarmente il team di Simone che ottiene una spettacolare velocità di 14!! Anche l'altro team migliora la sua velocità, portandola da 5 a 7. Il team di Simone guadagna un sonoro vantaggio in termini di valore di business cumulativo (1700 contro 1100 dell'altro team) .

 

Gabriele, nel team di Simone, si è preoccupato per l'alta velocità raggiunta, nel senso che temeva fosse un risultato non riproducibile. Si è dovuto ricredere: nella terza iterazione hanno mantenuto la velocità di 14. Il team di Fabio invece ha continuato il suo miglioramento, recuperando una buona parte dello svantaggio in termini di valore di business. Ma non abbastanza! Alla fine il Team-Simone vince con un totale di 3400 punti-business contro 3000. Ma va tenuto conto che l'altro team era in inferiorità numerica...

 

La serata si è conclusa chiacchierando nel seminterrato di una pizzeria, in attesa che si liberasse un tavolo da 10 che non si è mai liberato. Abbiamo allora ripiegato su un gustoso kebab, che ho digerito grazie a un'abbondante dose di sturalavandini prima di andare a letto :-)

 

La mia impressione della serata è che ci sia stato un intenso coinvolgimento di tutti, e che tutti ci siamo divertiti un bel po'. Credo che questo gioco sia molto utile per

  • imparare a fare team,
  • a capire come si stima per punti anziché in termini di tempo
  • fare pratica con il planning

In pratica capitano, in questa simulazione, molti dei casi che capitano nell'attività reale.

 

Fra i commenti che sono passati in mailing list:

  • che cosa ti è piaciuto? Tutto, in particolare l' immediatezza nel coinvolgimento di tutti.
  • Il mio team mi ha dato l'impressione di Team.
  • Non mi ero mai calato nei panni del committente che guarda solo i punti business: è stato interessante saltare la barricata.
  • L'immediatezza e la naturalezza con la quale si riesce a giocare, poi ti guardi indietro e fai fatica a credere di aver fatto un vero planning, ma e' cosi' :-)
  • Il fatto che si e' creato in tempo zero un team affiatato, che si e' autoorganizzato e che ha saputo raggiungere lo scopo, tutto in un'ora e mezza... cool

 

Un commento ricorrente:

  • Non mi è piaciuto dover fare i "cambi di cappello". squadre più numerose con le divisione in customere developer sarebbero imo più interessanti.

 

Questo è diverso dalle regole dell'XP Game classico. Non so che dire; il razionale dietro i cambi di cappello è che il team dovrebbe essere formato da veri clienti e da veri sviluppatori, mescolati insieme. In questo modo si spera di

  • creare un affiatamento fra clienti e sviluppatori
  • insegnare ai clienti perché è difficile stimare, insegnare agli sviluppatori perché è difficile pianificare
  • insegnare a entrambi a rivestire entrambi i ruoli

 

Il pericolo è creare un antagonismo fra la squadra di clienti e quella di sviluppatori. E poi, la parte di implementazione è la più divertente! (E in questo il gioco mima la realtà...)

Comments (0)

You don't have permission to comment on this page.