Essap 2006, a journal

by Matteo Vaccari

3/7/06, first day

La prima giornata della Essap (http://essap.dicom.uninsubria.it/) si è conclusa, e ho appena l'energia di scrivere un primo report!

Erano presenti tutti i membri dello staff: Uberto Barbini, Pascal Van Cauwenberghe, Francesco Cirillo, Federico Gobbo, Luca Grulla, Matteo Vaccari e i 12 partecipanti. Tempo e Villa splendidi.

Alle 9:15 la giornata inizia con il benvenuto del direttore del DICOM Prof. Lanzarone, che ha detto due cose a) i metodi agili dovrebbero essere la norma più che l'eccezione, e b) ci incita a far sì che questo evento non sia isolato ma riusciamo a creare una struttura più stabile.

Alle 9:45 Francesco Cirillo presenta "Principi, Valori, Pratiche". Una introduzione a XP dall'inizio alla fine. Tanti gli spunti importanti, troppi per rendere giustizia in poche righe.

Le pratiche di XP sono profondamente radicate nella tradizione del sw engineering; il punto più innovativo sono i "valori" di XP.
Il nemico numero uno è la complessità
XP non è un proiettile d'argento o una polvere magica che si possa spargere su un progetto per farlo andare bene. E' un impegno personale e continuo. Il pericolo è di dire "siamo agili", "siamo XP" e poi non fare uno sforzo personale per interiorizzare i principi, i valori e le tecniche.
Il ruolo del coach: quando le cose vanno bene, non fa nulla. Anche quando non vanno bene, non fa lui le cose, tipo "ti mostro io come si fa" ma aiuta il team a trovare un loro modo di risolvere i problemi. Il tutto senza "maieutica", ovvero senza influenzare lo sviluppatore in modo che trovi da solo la strada che io so che deve trovare. Mi sembra molto difficile.

Mi consola Francesco quando io (Matteo) gli passo il lunch bag che gli ho preparato e mi dice che per questa cosa (there must be food!) ho la stoffa del coach :-)

Pausa pranzo alle 13:30. Riprendiamo alle 14:45 con Federico Gobbo, che presenta le mappe mentali, dopo un survey di strumenti concettuali analoghi ma per certi versi meno soddisfacenti.

Poi Federico ci propone due possibili temi per il progetto che svolgeremo nel corso della scuola. Sono entrambe applicazioni di cui il DICOM ha effettivamente bisogno. La prima deve permettere ai docenti di scegliere le date per gli appelli senza collisioni di data con esami dello stesso anno di corso. (C'è un sacco di altre cose che deve fare, questo è un minimo sommario.) La seconda deve gestire tutti gli aspetti dell'organizzazione di un seminario o scuola estiva (servirebbe a me!)

La scelta ricade sulla prima, in parte perché ha suscitato un maggiore entusiasmo fra gli studenti insubri, ma soprattutto perché secondo il cliente-Federico è quella che per il DICOM ha maggiore valore. E in XP ovviamente si sviluppa quello che ha valore per il cliente, non quello che ci piace di più.

Ci rendiamo subito conto dell'efficacia delle mind maps quando Federico traccia una mind map dei requisiti dell'applicazione sviluppanda.

Dopo la pausa, ci trasferiamo in una stanza dotata di un tavolone centrale. Distribuiamo cartoncini bianchi a tutti, e iniziamo a scrivere le storie. Abbiamo scritto tutti la nostra versione della prima storia, e poi ciascuno l'ha letta, più o meno come abbiamo fatto nel secondo meeting ( http://milano-xpug.pbwiki.com/ReportMeet2) del Milano XP UG. Il cliente-Federico ha scelto la versione secondo lui meglio formulata. Siccome era parecchio complessa, l'abbiamo splittata in tre.

Poi ho insistito perché Federico ci desse i test di accettazione per la prima di queste tre storie splittate. Siccome F. non sapeva come scriverle, ho fatto qualche esempio. Dopo un po' Uberto e Pascal mi hanno interrotto, obiettando che non è così che si fa una sessione di scrittura di storie. Stavamo perdendo troppo tempo ad analizzare, a disquisire. Invece quando si va dal cliente per scrivere le storie bisogna solo scrivere, scrivere, scrivere, stracciare qualche storia e continuare a scrivere. Mentre si discute con il cliente si continuano a scrivere cartoncini.

Sono sicuro che hanno ragione loro; però non so come si possa, didatticamente, portare un gruppo così grosso di persone a fare il lavoro di scrittura delle storie. Voglio dire, il meccanismo di fare scrivere a tutti la stessa storia mi garantisce che tutti fanno qualcosa; però a un passo molto più lento di quanto si farebbe nella realtà, e in tutto il tempo che avanza è inevitabile che si inizi a disquisire di dettagli di analisi. E questi dettagli è bene rimandarli... questa era una sessione di brainstorming.

Insomma mi sfugge il formato didattico per questa cosa. Probabilmente a quest'ora (verso le 17) eravamo comunque tutti troppo stanchi. Alle 18:00 abbiamo raccolto i cartoncini scritti e abbiamo rimandato il planning game a domani, dopo che Pascal ci avrà insegnato come farlo.

Siamo tornati a casa stanchi ma molto, molto contenti ed energizzati.

4/7 martedì

Seconda giornata della Essap. Presenti Federico, Luca, Matteo, Pascal, e 11 studenti.

Alle 9:10 standup meeting, facilitato da Luca Grulla. Un giro di "che problema ho avuto ieri?" ha mostrato un consenso che la scrittura di user stories in 20 non è stata produttiva: gruppo troppo grosso. Il che mi fa venire in mente una soluzione: dividere il gruppo in 2 o più gruppi. Occorre che qualcuno faccia da proxy (sostituto) del cliente negli altri gruppi. Emergono alcuni spunti di discussione, per esempio il ruolo di UML in tutto ciò. Su suggerimento di Luca, le discussioni vengono rimandate, perché lo standup meeting non è il momento adatto.

Alle 9:30 inizia il gioco XP (http://www.xp.be/xpgame.html) di Pascal (http://blog.nayima.be/ ). Posso solo dire che il planning agile è assurdamente semplice e assurdamente utile. E il gioco XP è geniale per come ti insegna tutti i vari aspetti del planning, divertendosi un sacco! Mi chiedo gli studiosi di passaggio a Villa Toeplitz che cosa hanno pensato di tutto il rumore dei palloncini che scoppiavano.... Bravissimo Pascal.

Dopo pranzo, abbiamo suddiviso gli studenti in due team e, in stanze separate, abbiamo ripreso il planning per l'applicazione di Federico. Io (Matteo) ho fatto il proxy del cliente-Federico, con Luca coach, per un team. Federico ha fatto il cliente, con Pascal coach, per l'altro.

L'intento è che ciascun team sviluppi la propria applicazione indipendentemente. Apparentemente uno spreco, ma in questo modo posso, dopo qualche tempo, far confrontare i due team. Penso che impareranno un bel po' dal vedere come altri hanno fatto le stesse cose in maniera diversa. E io posso scegliere il meglio fra quello che entrambi i team hanno realizzato. Tutti vincono.

Devo dire che oggi il planning è stato divertente! Ho smesso di scrivere le storie e le ho fatte scrivere al team. Ho introdotto di nuovo l'applicazione, con una narrativa orale dei tre scenari. Il team ha scritto le carte, e poi le ha stimate, usando il metodo di Pascal:

prima le mettiamo in fila dalla più facile alla più difficile;
poi assegnamo un punteggio 2 alla più facile;
poi assegnamo un punteggio alle altre, fino a un massimo di 5.

(Ora che ci penso, il team in realtà ha assegnato anche dei "6". Questo punteggio 6 però indica che il team non si sente confidente di riuscire a stimare bene questa storia. Siccome era una delle più importanti, ho chiesto al team di splittarla. Ne sono venute fuori una storia da 4 e una da 3. Come cliente, apparentemente ci ho perso; ma in realtà ci ho guadagnato, perché ci tengo veramente a quelle due storie e ora sono più confidente anch'io che me le realizzino.)

Dopo una pausa (il customer era un po' stanchino) ho cominciato --da customer-- ad assegnare il valore di business. Ho fatto un po' di tentativi per ordinarle in ordine di valore, ma non riuscivo. Allora le ho raggruppate per area di funzionalità. Poi ho preso le aree di funzionalità più importanti, e da queste ho preso la storia più importante. Alla fine ho identificato 3 storie fondamentali e 3 da attaccare subito dopo. Tutte le altre sono rimandate.

Le storie che ho chiesto sono un po' strane dal punto di vista di chi progetta un'applicazione prima di realizzarla. Ad esempio, ho dovuto rinunciare a chiedere un CRUD per gli insegnamenti; il tempo che il team ha per lavorare è veramente esiguo. Quindi quando il docente prenota una data per un appello, scriverà in un campo di testo libero il nome dell'insegnamento. Non è ottimale, ma già mi dà il valore che mi serve di più, di prenotare una data.

La mia idea è di suddividere lo sviluppo in tre iterazioni di mezza giornata l'una: mercoledì pomeriggio, giovedì pomeriggio e venerdì mattina. Quindi giovedì e venerdì misureremo la velocità e faremo un nuovo planning.

Chiaro che sono iterazioni molto in miniatura rispetto a una situazione di lavoro reale; però il problema è reale e se riusciamo ad avere alla fine una app funzionante mi farà non solo piacere ma mi sarà anche utile. Sto pensando a come ottenere il massimo valore dal team date le condizioni di tempo limitato. Ci eravamo dati un limite fino alle 16:30 per il planning, che abbiamo rispettato. Poi siamo scesi nel seminterrato per provare le macchine con la nostra distro Linux per agilisti. Abbiamo purtroppo constatato che i PC di Villa Toeplitz sono scarsi di RAM e Eclipse gira troppo piano. Domani cercheremo di usare i nostri portatili per sopperire.

Come ieri, la mia sensazione alla fine della giornata è di entusiasmo, stanchezza e al tempo stesso energia!

mercoledì 5 luglio

Al mattino, tocca a me parlare di TDD. Spiego di che si tratta e perché è importante. Faccio una demo con il classico esercizio del punteggio del bowling di Uncle Bob. Poi continuo con un randori, ovvero, si propone un tema, e una coppia inizia a lavorare in TDD per 5 minuti, proiettando quello che fanno con il videoproiettore. Quando scadono, il driver della coppia torna al posto, il navigator diventa driver, e si prosegue per altri 5 minuti.

Come tema ho proposto la conversione di cifre romane in arabe. L'esercizio ha suscitato un buon interesse e partecipazione. Però ho notato due cose:

è troppo difficile; la gente tende a pensare troppo all'algoritmo, e troppo poco al tdd o al design OO
la gente (in generale) fa fatica a ragionare su array e indici, più di quello che tendo a immaginare io.

Comunque in quasi un ora hanno risolto il problema. L'ultimo driver è stato Pascal.

Nel pomeriggio abbiamo incominciato la codifica del progetto agile. Qui abbiamo avuto qualche problema; abbiamo perso troppo tempo per mettere in piedi un laboratorio con i nostri portatili (un ora e mezza.) Poi ho visto che l'esercizio, così come lo avevamo formulato, non era efficace. Gli studenti non conoscono bene Java, e tendono a perdersi in un bicchier d'acqua sull'uso di GregorianCalendar? o quant'altro. Oppure si perdono a cercare di far funzionare Tomcat o a connettersi a un DB.

Errore mio. Dietro front. Siamo andati a casa un po'insoddisfatti dell'esito dell'esercizio. Ciononostante, mi pare che gli studenti siano convinti ed entusiasti di tdd. Probabilmente sono abituati alle difficoltà :)

Alla sera torniamo da Varese io, Pascal e Luca. Andiamo alla riunione bisettimanale dello user group XP di Milano. Non abbiamo preparato nessun talk particolare. Pascal vuole che gli raccontiamo quello che facciamo nello UG. Però passiamo molto più tempo a chiedere a lui del suo UG di Brussel. Loro sono molto più avanti! D'altronde il loro UG è partito nel 2001.

giovedì 6 luglio

Allo standup meeting ho spiegato che oggi proseguiremo il tdd, ma in modo diverso. Separiamo i requisiti funzionali da quelli non funzionali. Ci occuperemo solo dei requisiti funzionali, mentre gli altri, come il database, la gui, le servlet, li ignoreremo. In questo modo potremo occuparci di sviluppare le classi del modello in tdd. Mi sembra la cosa didatticamente più fruttuosa. E poi, voglio che abbiano un esercizio che tutti possano risolvere, secondo le loro capacità. Tutti si stanno impegnando, e voglio che tutti portino a casa un successo. Sto seguendo i consigli di Pascal, che ha molta più esperienza di me nell'insegnare XP.

Verso le 9:30 Uberto Barbini ha fatto una presentazione sugli Acceptance Test molto semplice e chiara, illustrandoli con Fitnesse e un progetto di esempio. Nella demo era supportato da Renzo Borgatti. Sono riusciti a parlare anche di design. Avevo già usato Fitnesse in precedenza, ma questa presentazione mi ha chiarito le idee.

Al pomeriggio, proseguiamo con il nostro progetto in tdd. E oggi l'atmosfera è completamente cambiata rispetto a ieri. Finalmente tutti gli studenti fanno progressi sulla loro user story. Si concentrano sul dominio e fanno tdd. Facciamo ben 5 pomodori (ovvero periodi di lavoro di 25 minuti, intervallati da 5-10 min di pausa.) Mi è chiaro ora che sperare che i nostri studenti riuscissero a produrre un'applicazione completa di gui e persistenza era velleitario.

Merito del cambio in positivo di atmosfera è stato anche del nostro staff, rinforzato oggi da Uberto, Renzo e Gabriele Lana (membri storici del Milano XP User Group). Abbiamo avuto così abbastanza occhi per seguire con più attenzione tutte le coppie, perché restassero focalizzate sul compito di tdd.

Devo dire che la coppia che ho seguito io ha fatto grandi progressi, e ha non solo completato la sua prima storia, ma ha anche rifattorizzato il codice fino ad avere un livello di qualità che mi sembra buono (e non sono facilissimo da soddisfare!)

Sono rimasto piacevolmente sorpreso dallo scoprire su agilemovement.it che la distro live per agilisti di Thoughtworks è finalmente stata pubblicata. Se fosse stata pubblicata 10 giorni prima avrei fatto a meno di costruirmene una io.... :)

Alle 17:30 andiamo a casa molto soddisfatti (ed esausti!) sotto l'acquazzone.

Essap, venerdì 7 luglio

Ultimo giorno! Al mattino incontriamo traffico e arriviamo alle 9:45, io e alcuni altri che vengono con me da Milano. Comunque lo standup meeting si è svolto senza di noi all'orario regolare, e quando arriviamo le coppie sono già al lavoro, esercitandosi con TDD. Luca, facilitando lo standup, ha chiesto ai partecipanti di spiegare che cosa hanno fatto ieri per il progetto, che cosa hanno intenzione di fare oggi, e se prevedono problemi; proprio come si fa con i team durante l'attività lavorativa.

Dopo pranzo, alle 14:00 si svolge una sessione di domande e risposte. Alcuni argomenti che erano rimasti in sospeso dagli standup meeting vengono discussi. Molto gettonato il discorso sulla progettazione preventiva. Molti hanno obiettato che vorrebbero avere un documento UML a disposizione prima di iniziare il lavoro di sviluppo. La risposta dello staff Essap è stata che non è vietato fare disegni, ci mancherebbe! Ma quello che conta è la comprensione condivisa di un design, non il documento. E mentre alcuni metodi agili, come Crystal Clear di Cockburn, prevedono una fase di design preventiva, XP raccomanda di fare il design non prima, ma durante lo sviluppo in stile TDD.

Verso le 15:00 inizia la retrospettiva, facilitata da Luca, che ha disegnato sulla lavagna la linea temporale di questa settimana. Poi ha distribuito blocchetti di postit. Luca ci ha chiesto di descrivere su un foglietto un momento di questa settimana in cui è successo qualcosa di particolarmente interessante, durante la scuola o anche a casa. Poi abbiamo attaccato i nostri postit sulla linea temporale della scuola, avvicinando i biglietti che descrivevano lo stesso evento. Abbiamo osservato che molti hanno ritenuto topico lo XP game di Pascal. Cluster più piccoli di biglietti sono apparsi in corrispondenza delle altre sessioni mattutine.

Poi Luca ci ha girato la lavagna e ci ha chiesto di scrivere suggerimenti per migliorare la prossima edizione della Essap. Abbiamo ricevuto numerosissimi suggerimenti pertinenti. Mi rendo conto ora di come facciano i team XP a migliorare così velocemente. E' una combinazione di avere molta comunicazione sincera, un'attenzione conscia a identificare i problemi, provare soluzioni, e verificarne l'efficacia.

Verso le 16:30, party! E incontro con il prof. Lanzarone, che ci ha di nuovo incoraggiati a proseguire con un'attività anche lavorativa in questa direzione.