Buon Compleanno! eXtreme Programming User Group di Milano

Non sembra vero ma è passato un anno dal nostro primo meeting e siamo ancora belli freschi e carichi di voglia di imparare. Tiriamo un po' le somme di quest'anno passato insieme:

• Abbiamo organizzato 24 meeting
• Abbiamo svolto diverse attività che ci hanno portato a crescere le nostre conoscenze sull'eXtreme Programming
• In tutte le aziende in cui siamo stati ospitati siamo sempre stati accolti bene e abbiamo con successo diffuso l'eXtreme Programming
• "Last but not Least" abbiamo fatto nuove amicizie e ci siamo divertiti :-)

Grazie a tutte le persone che hanno partecipato e che hanno reso possibile quest'anno di soddisfazioni e che sono sicuro contribuiranno a rendere il prossimo anno ancora migliore del primo :-)

Dopo questa sviolinata veniamo all'ottima serata che abbiamo trascorso. Uberto ci ha proposto un piccolo esercizio per rivalutare l'uso della metafora come pratica XP (nella seconda edizione di "eXtreme Programming eXplained" Beck ha tolto la metafora dall'elenco delle pratiche) tratto da una conferenza alla quale ha assistito all'XpDay di Londra e ad un paper degli stessi autori della conferenza

L'utilizzo della metafora dovrebbe aiutare i componenti del team a raggiungere una visione comune del progetto e della sua implementazione, infatti la metafora può essere sia una metafora d'uso del prodotto (da utilizzare come supporto o come "vision" stessa del prodotto), oppure come metafora interna con lo scopo di comunicare in maniera più effciente e astratta le relazioni e le interazioni fra le sue componenti. Uberto ritiene più utile ed interessante quest'ultimo utilizzo

Dopo una breve introduzione che ci ha aiutato a capire quale relazione dovrebbe esserci fra gli "oggetti" della metafora e gli "oggetti" del progetto da realizzare, passiamo senza indugio all'esercizio. Dato un progetto software elencare almeno 10 metafore che lo descrivano e valutarne l'accuratezza attraverso:

• Falsi positivi, ovvero oggetti appartenenti alla metafora ma non al progetto
• Falsi negativi, ovvero oggetti appartenenti al progetto ma non alla metafora
• Matching perfetti

Ci siamo divisi in due squadre ognuna delle quali ha scelto un progetto/prodotto da descrivere con una metafora:

• squadra 1 = un browser
• squadra 2 = un sistema di versioning (ex. CVS)

Le metafore identificate dalla squadra 1 per descrivere un browser sono state:

• televideo
• ? (nd.Gabriele: prego i componenti della squadra 1 di elencare le metafore che avete trovato, io mi ricordo solo quella che alla fine ha vinto)

Le metafore identificate dalla squadra 2 per descrivere un sistema di versioning sono state:

• macchina del tempo
• universi paralleli
• biblioteca
• grappolo d'uva
• vigna
• albero
• cantastorie
• scambio di figurine
• ? (nd.Gabriele: Uberto hai ancora il foglio con le nostre metafore ;-P)

I vincitori sono stati:

• il televideo per la squadra 1
• la macchina del tempo/scambio di figurine per la squadra 2. Due vincitori in quanto a seconda della strategia adottata dal sistema di versioning (repository condiviso = SVN, repository distribuito = darcs) calzava meglio una o l'altra metafora

L'esperimento è stato divertente ed istruttivo, l'uso della metafora è sicuramente un ottimo strumento per aumentare la comunicazione fra i componenti del team, ammesso e non concesso che la metafora sia condivisa!

La serata è stata più che altro un festeggiamento ed un divertimento, complice la cucina e le birre del mullingas