Italian Agile Day 2009


Italian Agile Day 2009

E' stata annunciata la data per lo svolgimento del sesto Italian Agile Day: si terrà il 20 novembre 2009 a Bologna. Come sempre la conferenza si annuncia interessantissima: vi darò aggiornamenti nei prossimi giorni.

La tessera mancante

E' stata una coincidenza fortunata. Nei giorni scorsi stavo scrivendo del codice, per la prima volta da tempo del codice altamente algoritmico. Da bravo scolaretto XP, avevo creato una serie completa di test, avevo rifattorizzato estraendo metodi, rinominando variabili, abbassando il numero ciclomatico. Le classi erano piccole, i metodi corti, eppure il codice, pur funzionando egregiamente, in qualche modo mi infastidiva.
Poi alla scorsa riunione dell'XP-UG di Milano, Matteo Vaccari ha parlato brevissimamente dell'argomento, ed è stato illuminante. Da qui il suo interessante post.
In particolare una frase pesa come un macigno su quanti, come me, pensano di essere agili solo perché fanno TDD (o qualche altra pratica XP):
"TDD could be a crouch that allows you to give up finding a good design and settle for a mediocre one".
Puoi fare tutto quello che dice il libro bianco di Kent Beck, ma forse non ti accorgi che c'è una tessera mancante....

Quello che gli agilisti non dicono

I vantaggi dei test unitari sono ben noti a tutti: miglioramento del design, documentazione del codice, aumento della qualità tramite la diminuzione dei bachi e la possibilità di ristrutturare il codice in modo sicuro. Quello che gli agilisti (a volte) non dicono è che i test unitari, pur portando tutti questi benefici, rappresentano anche un costo nel processo di sviluppo. Un primo costo è banalmente rappresentato dal tempo necessario per il loro sviluppo, ma questo non è l'aspetto principale del problema. L'onere principale dei test, forse più difficile da cogliere, ci è indicato proprio dalle metodologie agili: tutto il codice prodotto comporta un costo di manutenzione, anche lo stesso codice di test.
Occorre quindi saper capire quando il prezzo dei test sia ripagato dai benefici e quando no. La mia opinione è che la creazione di test approfonditi per le interfacce grafiche non è quasi mai "economicamente" conveniente. Riprendo qui alcuni esempi che ho portato in una discussione nata con Matteo Vaccari sulla lista dell'XP User group di Bergamo.

Qualche anno fa, penso fosse il 2003, assistetti ad una presentazione al Webbit nella quale Bruno Bossola mostrò come fosse possibile applicare il TDD alla realizzazione di interfacce Swing, andando a testare lo stato dei vari "model" dei componenti. Tornai a casa entusiasta e provai a mettere in pratica la lezione: fu un disastro! Questo per due motivi. In primo luogo non sono un programmatore valido come Bossola (e allora ero ancora molto meno esperto). Secondariamente lo sforzo per cercare di domare le idiosincrasie di Swing non portava alcun vantaggio. I problemi della GUI sono al 90% del tipo: "Se visualizzo la mia maschera a 800x600 anziché a 1024x768 i bottoni scompaiono", oppure "Se passo a 1280x1024 il carattere è così piccolo che non si legge una fava". Certo, il debugging di questi aspetti si può fare anche con il TDD, ma penso che il debugging umano sia insostituibile, più efficace e molto meno costoso.

Secondo esempio. All'XP UG di Milano tentammo di sviluppare l'UG-Aggregator, una mini applicazione web per inserire e visualizzare gli eventi dei vari XP-UG. Questa applicazione non aveva alcun tipo di logica significativa, ma noi, essendo agilisti DOC, dovevamo scrivere i test! Ci venne quindi l'idea di testare la struttura dell'HTML prodotto, per vedere che ci fossero determinati tag con attributi che dovevano identificarne il contenuto. Il risultato fu circa il seguente, correggimi se sbaglio: tempo per scrivere il codice 1, tempo per scrivere il test 2, tempo per debuggare il test (e non il codice) che non funzionava 4. (OK ho un po' esagerato, ma penso che la mia ricostruzione non sia troppo lontana dalla realtà). Questo a mio avviso è un esempio di programma senza logica per cui il TDD può non essere efficace. Inoltre in questa situazione modificammo non solo la struttura interna dell'applicazione per renderla più testabile, ma anche il suo comportamento. Questa ritengo sia una "puzza" del processo di test!

In questo senso mi ha confortato l'esempio di TDD presentato nell'ultima riunione dell'XP User Group di Bergamo da Alessandro melchiori e Emanuele DelBono. Partendo dai test è stata abbozzata una banale applicazione Windows secondo il paradigma Model - View - Presenter. Ebbene, tutto il codice risultava coperto da test, ad eccezione della parte di view!
(Un unico neo nella presentazione dei due amici bresciani: tutto in C#!!!) ;-)

Pleasures of boilerplate code

In a very interesting interview, Martin Odersky said that Scala could be a little more difficult than Java for newcomers because in it you have not to write boilerplate code, but you have to think at your problem just from the first line of code. In some way, boilerplate code could be a kind of "warming up" for beginners. Writing some code, even if it's only syntactic noise, could give confidence to the programmer, generating a feeling of accomplishment.

But, is there a way to warm up without writing silly code? The best way of doing this is with unit testing. In TDD by example , Kent Beck describes "Starting tests": Start by testing a variant of an operation that doesn't do anything. Using these tests, not only you can start exploring your design, but you can also break the "white sheet syndrome".

Agile day 2008 - appunti di viaggio


Agile day

Sì, va bene, avrei voluto commentare in diretta l'Agile day 2008, ma non ci sono riuscito per merito degli organizzatori: troppe le cose interessanti da seguire per poterle riportare immediatamente!
Cercherò quindi di dare il mio personalissimo riassunto a posteriori, che intende essere più un taccuino di viaggio che un'analisi accurata dei tantissimi stimoli ricevuti nella manifestazione. I protagonisti dei vari incontri non me ne vogliano se non sono riuscito a recepire esattamente quanto volevano esprimere :-)

Agile e pragmatic: sinonimi o contrari?

La giornata è iniziata discutendo su "Agile e pragmatic: sinonimi o contrari?". Stimolo per il dibattito è stato un comune sentire che si sta facendo strada nell'ambiente Agile, emergente anche dagli ultimi thread della mailing list XP-it (e su cui mi sono permesso di scrivere un breve post). La sensazione è che nelle pratiche agili ci sia qualcosa da rivedere, pur non essendoci accordo sul cosa. Qualcuno pone l'accento sul dogmatismo con il quale esse sono a volte presentate. Altri sul fatto che, come in tutti i fenomeni diventati di massa, ci siano state delle cattive interpretazioni. Un altro dubbio riguarda la possibiltà di applicare solo in parte queste tecniche, senza che la mancata introduzione di una renda inutili tutte le altre. I più maligni (che però non hanno preso parte all'Agile Day ;-) ) arrivano a supporre che qualcuno abbia sfruttato la moda per interesse personali. La mia modestissima opinione è che effettivamente alcuni punti cardine dello Sviluppo Agile possano generare dei dubbi. In primo luogo mi chiedo se il design emergente sia in ogni situazione un valido sostituto del design preventivo, termine con cui non intendo la produzione di valanghe di documentazione e grafi UML che descrivono ogni metodo del progetto, ma una fase di analisi del "cosa fare" e "come farlo" proporzionale all'entità dell'impresa, analisi che potrebbe richiedere anche la generazione di documentazione di corredo. Mi domando inoltre se la programmazione agile sia veramente alla portata del programmatore medio, o richieda delle capacità fuori dal comune.
La maggiore prova a sostegno della bontà dell'approccio agile penso comunque sia stata portata da Simone Genini. Se un imprenditore come lui, che non fonda il proprio business sulla evangelizzazione dell'agilismo, bensì sulla consegna al cliente di codice funzionate, continua a scommettere da anni, pare anche con successo, su questi metodi di lavoro, allora si potrebbe financo pensare che funzionino veramente! ;-)

Refactoring di codice Legacy

La mia seconda tappa è stata il bellissimo workshop di Tommaso Torti e Fabiana Romagnoli su "Refactoring di codice Legacy". Cosa ho imparato? Che anche il refactoring deve misurarsi con il tempo e le risorse a disposizione. Il codice proposto presentava infatti diversi aspetti suscettibili di miglioramento, ma un limite insuperabile era costituito dai venti minuti a disposizione. Ci si poteva concentrare sull'eliminazione di numerosi "if" tramite l'utilizzo del polimorfismo, oppure lavorare sulla chiarezza del codice cancellando duplicazioni, rinominando variabili ed assegnando correttamente le responsabilità alle classi. Il primo refactoring sarebbe stato sicuramente più pirotecnico, ma probabilmente non avremmo avuto né il tempo, né le energie (ci siamo alzati alle cinque) per portarlo a termine. Il secondo, molto più banale, aveva invece il vantaggio di riuscire comunque a consegnare valore al cliente (nel nostro caso Tommaso e Fabiana) nel tempo stabilito.

Tool for agile planning and estimation

Altro workshop molto interessante è stato quello condotto da Simone Casciaroli. Lo strumento per la pianificazione agile proposto, chiamato ora Stuffplanner, pur essendo in versione alpha, ci è sembrato molto potente. Cosa ho imparato? Tutto, dato che sono assolutamente un novizio della pianificazione agile. Ecco i miei appunti ad uso principianti.

- E' importante suddividere il progetto in "storie" quanto più indipendenti fra loro al fine di evitare che una di esse costituisca un collo di bottiglia per lo sviluppo delle altre. Esse dovrebbero inoltre essere "verticali", ovverosia comprendere una funzionalità completa, dalla GUI al DB, per rappresentare una unità atomica di valore rilasciabile al cliente. In tal modo questi potrà valutarne correttamente la priorità all'interno della fase di pianificazione ed avremo sempre dei rilasci che aggiungono valore al prodotto.

- Un formato standard per le storie è: As a....I want...so that.....
As a... indica lo scenario di utilizzo che si immagina per la storia, per esempio Come utente esperto.
I want... indica il contenuto vero e proprio della storia, per esempio io voglio cercare un libro per ISBN.
Nella clausola so that.. si dovrebbe rendere esplicito il valore che la storia possiede per il cliente, al fine di aiutarlo nell'attribuzione del giusto peso durante la fase di pianificazione. Nel nostro esempio avremmo così da poter comprare un libro in brevissimo tempo.

- Una storia non dovrebbe occupare il team per più di due giorni, per evitare che il grafico di avanzamento lavoro (burndown chart) rimanga stabile per troppo tempo, abbassando il morale degli sviluppatori.

- La stima di una storia dovrebbe essere svolta preferibilmente in "story point", una misura di difficoltà relativa. Per esempio, "se si indica con 1 la difficoltà di sviluppo della storia più semplice, allora la storia X avrà peso 7". Il passaggio dagli "story points" al tempo reale dovrebbe essere realizzato analizzando lo storico delle iterazioni precedenti. Alla prima iterazione occorre solo confidare nell'esperienza dei membri del team. :-)

- La stima di una storia non è un valore singolo, ma una curva di probabilità di consegna: suppongo che non ci sia alcuna probabilità di realizzare la storia in meno di x story point (valore minimo), mi aspetto che ne serviranno y (valore atteso), penso di essere certo di consegnarla dopo z story point (valore massimo). Tutti gli elementi del team esprimono queste tre valutazioni. Per determinare il peso da assegnare alla storia, che è un singolo numero, si possono scegliere diverse funzioni di interpolazione di questi dati, fissando inoltre una soglia di rischio: ad esempio potrei scegliere il valore della curva di probabilità che mi garantisca una affidabilità dell'80%. Uno strumento come Stuffplanner è di ausilio in questa fase.

- Se è ovviamente importante non sottostimare le storie, è altrettanto pericoloso sovrastimarle. Il team, infatti, vedendo che la propria velocità è molto maggiore del previsto potrebbe rilassarsi troppo e perdere concentrazione.

Processo al database server relazionale

Purtroppo ho potuto assistere solo ai momenti finali di questa divertente presentazione/rappresentazione, svolta con notevole capacità teatrale. Due brevi note da innocentista.
Come prova a carico del DB relazionale è stata portata una stored procedure, realmente messa in produzione, che occupava diverse pagine. A mio avviso le stored procedure non hanno un legame essenziale, oserei dire ontologico, con la struttura di un DB relazionale. Sono solo un posto, quasi sempre sbagliato, dove mettere del codice che lavora sui dati relazionali. La loro esistenza non è strutturalmente legata a tale modello. Il fatto che molti programmatori poco avveduti ne abbiano abusato non è sufficiente a dire che il modello relazionale sia negativo.
Un'altra critica mossa al DB è quella che lo vorrebbe d'impiccio nella fase di stesura dei test. Se da un lato questo è sicuramente vero, dall'altro occorre forse ristabilre una giusta proporzione tra le cose. Ricordiamo sempre che i test non sono un fine, ma solo un mezzo. Dobbiamo trovare il modo per testare meglio l'uso del DB, cercando di evitare che la parte di accesso ai dati contenga troppa logica, ma ciò non può scalfire la validità dell'approccio relazionale nella grande maggioranza dei casi.
Quando qualcuno parla male dei database, io ricordo sempre che lavoro da anni su un DB che è stato alimentato, interrogato e spippolato da programmi scritti in una decina di linguaggi diversi. I linguaggi sono cambiati, i programmi sono stati riscritti, ma la struttura del DB, ben congegnata, è rimasta. Diceva Cicerone Programmata volant, Datarum Basae manent :-D

Uso dei Kanban, ovvero quando stimare è impossibile

Questo è stato il titolo di un open space fuori programma tenuto da Gabriele Lana.
Se non ho inteso male, il punto di vista di Gabriele è il seguente. In particolari situazioni, dove ad esempio il dominio del problema sia particolarmente difficile o inusuale, oppure dove vi sia una grossa dipendenza da programmi o prodotti sviluppati da terzi fuori dal nostro controllo, effettuare delle stime dei tempi di realizzazione è semplicemente impossibile. Non solo, ma la stima potrebbe risultare controproducente rispetto all'affidabilità del software. I programmatori potrebbero infatti cercare di abbassare la qualità (copia e incolla selvaggio, mancata stesura di test, design approssimativo e mancanza di refactoring) pur di rimanere all'interno dei tempi previsti. In questi casi l'approccio migliore sarebbe quello di stendere delle user story, che potremmo ora definire Kanban, che avrebbero solo la funzione di ordinare i lavori in base alla priorità e determinare lo stato di avanzamento degli stessi.
E la stima di tempi e costi? Visto che in ogni caso in queste situazioni una qualsiasi stima sarebbe solo una bugia, meglio concordare con il cliente un tipo di contratto flessibile, con punti di verifica frequenti ove poter eventualmente cambiare direzione.

Conclusioni

L'agile day si è confermato un grande evento. Un grosso ringraziamento a chi si è preso l'onere dell'organizzazione ed un arrivederci all'anno prossimo!!!