La serata è stata molto energica nonostante la maggior parte delle persone arrivassero da una giornata lavorativa, ed è stata anche molto popolata (forse perchè l'abbiamo chiamato Pair Programming Party :-)

Abbiamo provato un approcio organizzativo alternativo, ovvero invece di lavorare per 3/4 pomodori e poi andare al ristopizzaro a cenare, abbiamo portato il ristopizzaro da noi, facendoci consegnare direttamente le pizze a domicilio, con le bevande gentilmente offerte da Alessandro Mercanti e Matteo Vaccari

Per scandire il tempo abbiamo usato il "pomodoro" di Matteo, di cui abbiamo una diapositiva :-)

Direi che ha funzionato, i più duri hanno resistito fino alle 11:00, ed è stata una serata divertente

Ma veniamo alle cose serie, pare proprio che il nostro progetto non voglia decollare, neanche questa volta siamo riusciti a produrre qualcosa di consegnabile e questo è male. La sensazione è quella di girare un po' a vuoto, di aver commesso degli errori di organizzazione, e di non essere riusciti ad applicare XP in modo produttivo, scadendo, come ha detto Renzo, in tutte le cattive abitudini classiche:

• fare innervosire il cliente :-)
• accampare scuse producendo documenti come la white board che abbiamo realizzato quando il cliente ci ha chiesto cosa stavamo facendo (Gabriele: anche se a me personalmente non dispiace come strumento di tracking a livello di storia)
• non produrre nulla di funzionante se non alla fine
• big bang integration spiazzante del tipo "...ahhh, ma questo non doveva essere cosi, ...ahh, ma questo non lo avevamo considerato, ecc..." non l'integrazione a livello di codice, ma l'integrazione a livello funzionale)

Ieri sera sul finale abbiamo fatto un po' di retrospettiva, e abbiamo concordato che i problemi sono stati i seguenti:

• scarsa conoscenza reciproca: eravamo un team molto di meno di quanto non lo siamo ora
• notevole diversità di background: alcune persone del team erano totalmente digiune delle tecnologie utilizzate nel progetto, e sappiamo quanto java possa essere "pesante" senza le conoscenze adeguate
• dimensione del team rispetto alla ridotta dimensione del progetto: questo ci ha portato a dividere le storie, le quali una volta ultimate avrebbero dato valore al cliente, in tanti task tecnologici che sono stati distribuiti e completati, senza però portare al completamento della storia di riferimento, e quindi senza consegnare valore al cliente
• scarsità di tempo a disposizione: 2 ore effettivamente sono un po' pochine, ma per questo la nuova organizzazione dell'incontro potrebbe venirci in aiuto

A mio parare il progetto è stato troppo azzardato come mossa iniziale del gruppo, sarebbe forse stato più prudente conoscerci applicando le

pratiche con degli esercizi mirati, e solo dopo, con un po' piu' di confidenza, realizzare un progetto proprio come farebbe un team XP

Ma ci siamo buttati e qualcosa l'abbiamo portata a casa:

• abbiamo approfondito le nostre conoscenze delle pratiche XP attraverso la loro applicazione
• ci siamo conosciuti e siamo più team ora di quanto non lo eravamo all'inizio
• stiamo sperimentando l'adattamento di XP alle caratteristiche del team e del progetto (Gabriele: io sinceramente ho apprezzato la possibilità di poter affrontare queste problematiche in modalità "simulazione", anzichè subirle direttamente "in the wild" (anche perchè di progetti senza "problematiche particolari" ne vedo pochi in giro)

E' vero, non abbiamo soddisfatto il nostro cliente, ma grazie all'esperienza che abbiamo fatto, grazie alle conoscenze che abbiamo acquisito, siamo confidenti di poter far meglio

Giustamente però Uberto ha fatto notare che probabilmente se non ci "adatteremo" non adremo molto lontani rispetto a dove siamo ora con il progetto, e subito sono state fatte alcune proposte:

• come nel microciclo così anche nel macrociclo, quando sei imbrigliato in una situazione che ti sta richiedendo troppe energie rispetto al suo valore, "stacca dal problema ed eventualmente inizia da zero"
• manteniamo la divisione in storie e in task che abbiamo già fatto (magari ristimando il tutto alla luce delle nostre esperienze), ma dividendoci in più team formati al più da due coppie, ognuno dei quali (team) si prenderà in carico tutte le storie, ogni coppia lavorerà ad una storia alla volta che si concluderà con il superamento dei test di accettazione della stessa
• preparare meglio l'ambiente di sviluppo: dovrebbe essere già un semilavorato che ci permetta di eseguire test di accettazione, di fare il deploy del progetto in qualsiasi momento, che abbia degli stub di servlet e jsp pronti per essere modificati ed usati, ecc... in stostanza un ambiente che ci permetta di non pensare a tutti quegli inutili dettagli tecnologici che java tanto amorevolmente ci regala :-)
• anche se i team sono più di uno, la rotazione delle coppie deve essere incoraggiata, in modo da favorire la successiva e progressiva integrazione dei "micro team" in un team unico (due team formati da una coppia ciascuno, si potrebbero fondere attraverso la scelta di una base di codice, oppure attraverso la fusione di due basi di codice)

Alla luce di tutto ciò, "Caro Cliente" se la sente di darci un'altra possibilità? Vuole esprime la sua opinione?

Infine durante la serata, la chiamata alle armi da parte di Gabriele per una nuova attività del grupo:

stimolati dall'esperienza ESSAP e dai consigli di Pascal, volevamo iniziare un'attività di "marketing" del nostro gruppo e di XP rivolta alle aziende che potrebbero essere interessate

Si pensava di realizzare questo in riunioni diverse da quelle principali, la prima probabilmente si terrà 26/07/2006, chiunque è interessato, batta un colpo