Extreme Enthusiasm

Un altro Agile Day è passato.

Tutto di corsa

Purtroppo quest’anno non ho assistito a molte sessioni; sono partito da Amsterdam con l’aereo delle 7, e sono riuscito ad arrivare a Bologna verso le 11:30, quindi dopo la sessione di apertura e il panel. Poi quando sono arrivato, mi ha fatto un enorme piacere rivedere tante persone che non vedevo da un po’, quindi ho passato un po’ di tempo a chiacchierare e un po’ di tempo a completare le slide della mia presentazione. Come risultato, al mattino non ho seguito alcuna sessione.

Retrospective, Standup and Journal

Al pomeriggio ho seguito la presentazione di Piero Di Bello e Jacopo Franzoi su “Retrospective, Standup e Journal”. Si parlava di queste tre pratiche meno “tecniche” ma di enorme importanza nella vita del team. Se uno vuole rendere agile un team, e dovesse scegliere di iniziare con una sola pratica, farebbe bene a iniziare con le retrospettive. Perché è nella retrospettiva che il team inizia il processo di miglioramento continuo, che è uno dei due obiettivi dell’agilità. (L’altro è “soddisfare il cliente con rilasci rapidi e continui di software che ha valore.”) Il libro di riferimento sulle retrospettive è sempre quello di Derby e Larsen, Agile Retrospectives.

Piero e Jacopo non si sono limitati a raccontare quello che c’è nel libro; hanno raccontato episodi, pattern e antipattern vissuti nella loro esperienza di mentori, di cui ho parlato nella sessione successiva io. Esempi di antipattern: quando non si parla (il “silenzio degli innocenti”), quando si parla troppo, e conviene rimandare le discussioni tecniche in altra sede; quando si parla delle stesse cose, e conviene cercare di smuovere lo status quo variando il formato della retrospettiva, oppure facendola meno spesso.

Lo stand-up meeting è un’altro momento fondamentale nella vita del team. E’ così “facile” implementarlo che si dà per scontato che tutti lo facciano bene, ma non è così. Anche qui bisogna stare attenti ad alcune cose, di cui secondo me la più importante è che l’orario deve essere fissato e si deve assolutamente iniziare all’ora stabilita, anche se manca qualcuno. Anche di questa pratica Piero e Jacopo hanno raccontato un po’ della loro esperienza vissuta.

Infine hanno parlato del journal, ovvero il diario del team. Questa è una pratica di cui non si parla molto in letteratura. Piero e Jacopo l’hanno appresa lavorando nel team XPlayers in Quinary. (Oggi lavorano con me nel team Orione in Sourcesense.) Nel nostro team il diario viene tenuto regolarmente. E’ un’ottima maniera di tenersi aggiornati su quello che succede nel team, di riflettere a fine giornata su quello che si è fatto, e dà uno spunto al mattino per lo stand-up meeting.

La nostra esperienza di mentoring

Poi ho fatto la mia sessione, in cui ho raccontato l’esperienza degli ultimi 9 mesi del team Orione. Abbiamo fatto due episodi di mentoring, in cui una parte del nostro team ha affiancato il team del cliente, allo scopo di trasmettere il metodo XP lavorando su un progetto vero del cliente. I due episodi sono stati molto diversi; nel primo avevamo un team di 4 sviluppatori rumeni, dipendenti di una banca italiana. Nel secondo avevamo un team di circa 15 sviluppatori per lo più italiani, che erano stati arruolati in “time & material” da un’importante istituzione finanziaria italo-britannica per un progetto web. Mentre nel primo caso gli orionisti erano circa metà del totale, nel secondo eravamo in netta minoranza. La profondità della trasmissione del metodo ne risente; puoi agilizzare poche persone in profondità, oppure tante in maniera più superficiale. Questa è una regola generale del mentoring: la tua capacità è limitata, se la rivolgi a più persone sarà più sottile.

Ciononostante, l’applicazione di alcune pratiche chiave del metodo agile ha portato dei grossi benefici anche per questo cliente. Abbiamo aiutato a creare un team coeso; a tracciare e pianificare in maniera realistica il progetto, fornendo numeri affidabili per poter prendere decisioni importanti in maniera tempestiva; a migliorare la qualità tecnica del software prodotto.

Sono molto d’accordo con i punti che Gabrielle Benefield ha riportato dalla sua esperienza della agilizzazione di Yahoo, che ho letto sul blog di Pascal:

• Go deep Agile with a few of the most important teams, rather than spread Agile thinly over a lot of teams.
• Technical excellence, attention to quality and good engineering practices are essential.
• Grow slowly with teams that volunteer. Don’t overstretch your coach capacity.
• Involve management. Inform, address fears and explain “what’s in it for them”.
• There will always be people who don’t like or want Agile.
• Don’t just change the process; change the structure of the company.
• Bribe people with snacks.

Processo al database relazionale

Il mitico XP User Group di Bologna ha presentato in forma di pantomima un argomento molto interessante: il Processo al database relazionale. Con carisma di attori consumati, hanno portato in scena l’imputato (sotto forma di un cilindro di polistirolo, come viene rappresentato negli schizzi), il giudice Roberto Bertazzoni, il pubblico ministero Paolo Perrotta, l’avvocato difensore Finelli, e due testimoni! I testimoni sono stati interrogati dalle due parti, e hanno raccontato tristi storie di stored procedure lunghe 30 pagine (in Monaco 10), o di stored procedure che prelevano frammenti di query da una tabella di query (!!!). L’avvocato dell’accusa sembrava avere gioco facile nel dimostrare a quali disastri architetturali possa portare l’uso dissennato del database, ma l’avvocato difensore ha giustamente puntualizzato che lo strumento non ha colpa del fatto di essere utilizzato male; e che comunque i due sistemi in questione funzionano bene, e se l’imputato Sig. Relazionale Database non ci fosse, sarebbe forse più difficile ottenere gli stessi risultati.

L’arringa dell’accusa (introdotta da una slide che rappresentava un aringa), è stata molto convincente, con un esilarante citazione dal geek padre di noi tutti, Leonardo Da Vinci, e dei suoi consigli sull’architettura delle applicazioni. Paolo, voglio stamparmi tutto lo scritto leonardesco su una maglietta!! Il succo: separate le applicazioni nei tre laièri, ovvero strati, e mantenete l’intelligenza fuori dallo strato di persistenza.

L’arringa della difesa è stata pure molto convincente. Usate lo strumento nella maniera appropriata. Non ha fatto uso però di un argomento che per me è decisivo, e cioè: se non ci fosse il Sig. Relazionale a gestire l’accesso concorrente ai dati, saremmo nella cacca. Ci toccherebbe trafficare con semafori, thread e mutex, il che secondo me, nella programmazione applicativa, è un gravissimo antipattern. Non però nella programmazione di sistema, che è poi quella che si occupa di costruire strumenti come il Sig. Relazionale.

Alla fine l’imputato è stato dichiarato colpevole dalla giuria (il pubblico) di due su tre dei capi d’accusa.

Mi tolgo il cappello di fronte a uno user group che è capace di a) discutere di argomenti tecnici con passione fino alle due di notte, e b) realizzare una simile messa in scena.

Retrospettiva italiana

Luca Minudel ha condotto la retrospettiva italiana, in cui quelli del pubblico che applicano in pratica un metodo agile sono stati invitati a raccontare una cosa buona e una cattiva che è capitata in quest’ultimo anno. Abbiamo lavato un po’ di panni sporchi in pubblico, cosa che al pubblico magari interessava poco. Abbiamo parlato anche di azioni che possiamo fare per migliorare la qualità della comunità agile italiana.

Ci sono state diverse proposte; la migliore è stata quella di Tommaso che ha proposto un check-up fra due mesi: il 31 gennaio tutti noi siamo chiamati a scrivere un messaggio sulla mailing list extremeprogramming-it, per raccontare in che cosa è migliorata la nostra attività lavorativa dal 21 novembre. Questa proposta mi piace perché: è semplice, attuabile, è un piccolo passo, ed è efficace; realizza un proseguimento della retrospettiva italiana. Risponde anche al problema percepito da Simone che diceva che la mailing list è un po’ smorta (davvero? a me pare così trafficata che fatico a seguire tutto.)

La mia proposta era di proporre in Italia un numero maggiore di workshop di formazione, del tipo di quello di Tommaso e Fabiana sul refactoring, che è andato completo in pochi secondi da quando è stato reclamizzato. E’ evidente che c’è fame di questo tipo di eventi. Io proporrei di fare una giornata dedicata ai workshop (ovvero a seminari di formazione pratici, dedicati a un numero limitato, tipo 20 persone.) Si potrebbe fare o attaccata all’Agile Day dell’anno prossimo, oppure separata di circa sei mesi. Purtroppo Marco Abis non è stato presente alla retrospettiva. Mi sarebbe piaciuto sentire il suo parere.

Conclusione…

Mi dolgo di non avere partecipato alla canonica cena organizzata dagli amici del Bologna XPUG. Peggio per me! Sono felice di avere partecipato al quinto Agile Day, di avere rivisto tutti, e di avere portato un contributo. Sono felice che il mio intervento sia stato apprezzato da tante persone. Sono orgoglioso che tanti del mio team abbiano portato presentazioni o workshop.

Grazie a Marco, e tutti quanti hanno partecipato. Cerchiamo di mantenere viva quest’energia e di migliorare sempre!

This entry was posted on 24 November 2008 at 10:13 and is filed under Agile. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.