Extreme Enthusiasm

English summary: during the last Italian Agile Day the one concrete action that was proposed during the retrospective was to post what concrete successes we would be able to obtain in the next two months. This is my contribution.

Che cosa è cambiato fra il 21 novembre 2008 e il 30 gennaio 2009?

Tommaso Torti ha proposto, durante l’ultimo Agile Day, di raccontarci di lì a due mesi che risultati concreti abbiamo ottenuto nel miglioramento della nostra vita lavorativa.

Una cosa che ho fatto è stato di ridurre i miei impegni di prevendita e altro, e concentrarmi con più attenzione nelle vicende del nostro team in Sourcesense. Il team a questo punto è cresciuto a 12 persone (oggi 13), ed è stato impegnato in questo periodo su due clienti.

Risultato numero 0, delegare e fare emergere un neo-coach

Una cosa che si è rivelata buona è stato splittare temporaneamente il team in due, ed affidare a uno dei membri del team il coaching degli altri. Ho scelto lo sviluppatore con la maggiore esperienza di XP. Mi pare che abbia funzionato bene: io ho avuto il beneficio di riuscire a concentrarmi sulla “mia” metà del team, e l’altra metà ha avuto il beneficio di un coach più attento e concentrato di me. Inoltre sono contento che il neo-coach abbia fatto questa esperienza. Oggi le carte sono rimescolate e le persone si sono suddivise in maniera diversa, ma l’esperienza credo sia stata utile per fare crescere tutti loro.

Risultato numero 1, ho capito che Fertig ist Fertig!

La “mia” metà del team verso Natale si trovava in una situazione di malumore diffuso. Abbiamo fatto una retrospettiva in cui i bigliettini di “Sad” e “Mad” erano di gran lunga più numerosi di quelli nella zona “Glad.” Che cosa stava succedendo?

Il cliente in questione presenta le sue difficoltà, come d’altronde tutti i clienti. Una difficoltà è che il tempo che ci vuole per fare approvare una storia è molto lungo; avevamo le che si accumulavano nella zona “to verify” e non si spostavano da lì. Questo significa che la nostra velocità fluttua selvaggiamente; certe iterazioni non riusciamo a fare approvare nulla, quindi abbiamo velocità zero. L’iterazione successiva facciamo approvare tutte le storie di quella precedente, e la nostra velocità schizza a livelli “irrealistici”.

Inoltre c’è la tentazione di dichiarare “chiusa” una carta quando funziona correttamente nel nostro ambiente di sviluppo, dialogando con i nostri stub invece che con i sistemi veri. Per me è stato decisivo leggere questo articolo di Dave Nicolette, Fertig ist Fertig, dove argomenta che far passare le cose con i mock non vale. Per il cliente una storia ha valore quando è pronta per funzionare correttamente in produzione. Niente di meno di questo ha valore. Per noi, questo significa portare le storie all’approvazione nell’ambiente di PRE-produzione.

E qui succedono le cose strane: portando le cose in preproduzione ci accorgiamo che abbiamo sbagliato completamente alcune scelte architetturali. Colpa nostra? Colpa del cliente che non ci ha avvertiti? Inutile parlare di colpe! Abbiamo imparato che è necessario portare le storie in preproduzione il prima possibile. Abbiamo anche imparato che dobbiamo discutere il nostro piano di implementazione con il personale del cliente più esperto di noi prima di partire a codificare.

Da allora abbiamo aggiunto una nuova colonna nella nostra lavagna. Abbiamo gli stati “To do” -> “In progress” -> “Code complete” -> “Approvato in test” -> “Approvato in PRE” (quest’ultimo abbreviato in “Fertig!”). Lo so che è complicato, ma riflette la realtà del nostro progetto. In questo modo ci ricordiamo di insistere per spostare le carte nelle ultime, critiche colonne.

Niente di nuovo; c’era già nel libro. Approvare le cose in PRE corrisponde a una fase di “integrazione”, e se facciamo sviluppo incrementale, l’integrazione va fatta contemporaneamente a tutto il resto. Dave con il suo “Fertig ist Fertig” me (ce) l’ha fatto capire bene.

Risultato numero 2, la formazione interna funziona

Da tempo avevamo deciso di organizzare lo studio internamente al team concentrandolo in 2,5 ore settimanali. Ma in pratica, con il caos del lavoro quotidiano, nessuno le prendeva, e se le prendeva era studiando da solo.

Un’azione che abbiamo fatto è stata di decidere che queste 2,5 ore sono sempre il mercoledì dalle 14 alle 16:30. Poi abbiamo affrontato alcuni argomenti di studio in comune, che ci sono serviti per colmare alcune lacune che avevamo noi come team, e per formare un corpo di conoscenze condivise a livello di team. Abbiamo fatto il Kata degli Auguri di Compleanno, per imparare e approfondire l’architettura esagonale. Lo stesso kata è stato poi ripetuto con il Milano XP User Group, e pare sia piaciuto.

La volta dopo abbiamo fatto uno dei “mini-etude” di Shore e Warden. Si trattava di analizzare un pezzo a scelta della nostra applicazione, fare un reverse engineering per produrne un modello UML o simili, e poi proporre modifiche. Questo esercizio ha avuto un grande successo, perché c’erano nel team numerosi malumori riguardo alla qualità del design di questa applicazione. Dedicare del tempo esplicitamente a ragionare sul design, senza la pressione di dovere finire la carta, ha permesso, credo, di ragionare serenamente sul design.

Uno degli effetti positivi è stato che abbiamo (ri-)imparato che i refactoring architetturali devono essere fatti in maniera incrementale. Le idee che erano nate nel mini-etude, abbiamo tentato di applicarle con un passo troppo grosso, e poi abbiamo dovuto buttare via le modifiche e ricominciare un passo alla volta. Il team ora ha una cultura di committare ogni due pomodori, e questo mi sembra un ottimo risultato!!

Risultato numero 3, il design emergente non è uno scherzo

Francesco Cirillo in mailing list spesso ci bacchetta perché si tende a sottovalutare la difficoltà di abbassare il costo del cambiamento. E’ facile appendere cartoncini alla lavagna e fare il planning game; ma se non si è bravi a fare il design incrementale, non si riesce a mantenere basso il costo del cambiamento.

Questo l’abbiamo sperimentato sulla nostra pelle, perché nel corso dei mesi di lavoro, non riuscivamo ad arrivare a un punto in cui si ha la sensazione che aggiungere nuove storie diventa “facile.” In teoria, quando il design emergente funziona bene, il costo di aggiungere una nuova storia dovrebbe restare costante, oppure diminuire nel caso la storia sia simile a una già implementata. Nel nostro caso non era così. E questa era una delle fonti del malumore di cui parlavo prima.

Effettivamente il nostro codice conteneva diversi “smell”. Costruttori con una decina di parametri. Lunghi palleggi fra classi dai nomi simili (tipo FooExecutor, FooManager, FooHandler). L’antipattern Registry Object.

Come l’abbiamo risolta? Le azioni che ho applicato io sono state

1. Ruotare le persone. Abbiamo fatto ruotare sul progetto alcune persone che erano particolarmente appassionate di design. Non perché le persone che c’erano prima non ne sapessero niente, anzi, abbiamo avuto dei contributi tecnici di prim’ordine. Ognuno ha il suo personale contributo da dare. Avere diversità di skill, carattere, atteggiamento è importante per il team.
2. Organizzare gli eventi di formazione che dicevo sopra.

Il resto lo hanno fatto gli sviluppatori. Devo dire che ora il tempo che ci mettono le carte ad andare in “code complete” è crollato, e anche tutte le modifiche architetturali che ci sono piovute addosso quando abbiamo portato le storie in preproduzione sono state implementate con una certa nonchalance.

L’umore del team Orione oggi è decisamente migliorato :-)

Ci sarebbe ancora parecchio da dire (è stato un inverno intenso) ma per ora chiudo.

This entry was posted on 30 January 2009 at 14:04 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.