Agile Day 2011

Anche quest'anno eccomi a stilare il mio personalissimo resoconto dell'Agile Day.
In primo luogo vorrei ringraziare gli organizzatori, che hanno svolto un lavoro perfetto. Se non ci siamo "accorti" di voi è perché tutto ha funzionato al meglio: bravi!
Ed ora mia una interpretazione delle sessioni a cui ho partecipato.

Back to basics: OOP and design

Il senso dell'intervento di Paolo Polce sta tutto nel titolo: dopo anni spesi a concentrarsi sul processo, abbiamo forse perso di vista i problemi tecnici, quasi fossero semplici dettagli implementativi. Scrum masters, sprints, story points, sì, vabbè, ma il codice? Beh, al codice ci penseranno le "risorse"... :-)
E' tempo di tornare a focalizzarsi sulle "risorse", ovvero sui programmatori, e sulle loro competenze, che devono costantemente essere allenate, come i muscoli di un atleta.
Come ottenere lo scopo? Con buone letture, buoni strumenti, ed un continuo esercizio volto a creare design realmente ad oggetti. Una buona architettura Object Oriented modularizza i problemi tramite gli oggetti, ed evita quindi classi "Star gate" (spesso incarnate da dei Singleton), che leggono attraverso una pioggia di getter le informazioni più disparate, collassando al loro interno l'intera logica applicativa. Occorre quindi evitare i getter, scrivendo sempre più metodi che restituiscono void. Ma come testare queste architetture? La chiave consiste nel passare da test sullo stato degli oggetti, a test che ne verificano le interazioni.

Codice legacy: usciamo dal pantano!

Bel workshop di Stefano Leli e Simone Casciaroli. I partecipanti sono stati invitati a fare refactoring su un piccolo progetto, che nella gerarchia Bird-Duck-Chicken mostra un caratteristico caso di violazione del Principio di sostituzione di Liskov, il complesso edipico irrisolto della programmazione ad oggetti.
La sessione, terminata con la presentazione della soluzione dei relatori, è stata interessante, anche se avrebbe richiesto sicuramente almeno un'altra ora per riuscire al meglio.

Lean, A3 e kaizen

Claudio Perrone nel suo intervento ha illustrato i i Kaizen Memo ed il medoto A3.
I Kaizen Memo sono piccoli fogli di carta da appendere su una parete per dare evidenza ai miglioramenti raggiunti nel processo produttivo. Dovrebbero riportare il problema affrontato, la misura intrapresa per risolverlo e le conseguenze ottenute.
Il metodo A3 prevede di utilizzare un modulo di carta, solitamente di dimensione appunto A3, sul quale presentare in modo oggettivo:

  • la situazione corrente;
  • l'obiettivo da raggiungere (ciò definisce il problema come differenza tra situazione corrente ed obiettivo da realizzare);
  • l'analisi delle cause del problema;
  • l'elenco delle contromisure da adottare;
  • una matrice what-who-where-how per realizzare le contromisure;
  • un elenco di azioni supplementari (follow-up) da intreprendere in caso di problemi.

L'intervento è proseguito definendo la figura del manager ideale, che non dovrebbe essere né un poliziotto che punisce chi si comporta male, né una mamma che coccola i suoi figli, e neppure una figura assente. Il vero manager dovrebbe invece essere una persona che si occupa di eliminare i problemi che ostacolano il processo produttivo. La domanda che un manager dovrebbe rivolgere ai suoi sottoposti non è "cosa hai prodotto ieri", ma "quali problemi hai avuto".
Claudio Perrone ha concluso dando una bella definizione dei metodi lean/agili: strumenti per fare soldi attraverso la crescita delle persone.

Back to basics hands-on

Antonio Carpentieri e Paolo Polce hanno condotto un efficace workshop sul design ad oggetti. Utilizzando come esempio il gioco del monopoli, hanno mostrato nella pratica come realizzare software ad oggetti senza abusare di getters e favorendo composizione, basso accoppiamento ed alta coesione.
Molto importante la sottolineatura finale di Antonio Carpentieri che ha ripreso il keynote di Paolo Polce: un programmatore non può crescere lavorando solo su codice di produzione. Come un atleta non migliora solo con le partite, ma soprattutto con gli allenamenti, anche chi sviluppa software non può non allenarsi praticando i kata.

Unit Tests VS End to End Tests

Probabilmente il mio giudizio su questo intervento è falsato dalla fatica accumulata alla fine di una giornata così intensa, ma dalla presentazione di Domenico Musto non sono riuscito a trarre nessuna informazione interessante. Chiedo venia.

Conclusioni

Anche questa edizione dell'Agile Day è stata all'altezza delle aspettative. Mi è piaciuta molto l'enfasi sul codice, dopo troppo tempo speso sui problemi di processo. Grazie ancora agli organizzatori ed arrivederci al 2013!

Lascia un commento

You must be logged in to post a comment.