Un'esperienza di fallimento 
venerdì, aprile 21, 2006, 03:09 PM - TDD, Diario di bordo

Piccola esperienza di fallimento che vorrei condividere con voi riguardo il progetto di cui vi ho parlato nel mio post precedente. Data: qualche giorno fa, a pochi giorni dalla produzione.

Una carta è sulla lavagna da qualche tempo: rendere thread safe, per poter essere utilizzati come singleton da Spring, gli oggetti che nel nostro piccolo framework (per vari motivi fatto in casa e che si occupa del supporto ai webservice e di flusso delle pagine web) rappresentano i servizi. Stima della carta: 2 giorni. Se tale intervento non dovesse essere effettuato, un servizio che va in errore rende permanente tale errore anche su sessioni differenti.
Durante le sessioni di pianificazione ad ogni iterazione questa attività viene scavalcata sistematicamente da altre storie, sicuramente con maggiore valore di business perché orientate a nuove funzionalità dell'applicativo.
Continuando a rimandare arriviamo a 3 giorni dalla produzione: ora è necessario effettuare l'intervento, pena il procrastinare la produzione.
Io e Marco in pair lavoriamo alla carta, terminandola in 2 giorni. Il framework "originale" (circa 1400 DLOC) è stato sviluppato due anni fa, quando ancora la pratica dei test non faveva parte del nostro quotidiano. Io e Marco comunque ci facciamo guidare dalla scrittura dei primi test del framework per esprimere le intenzioni già modellate con carta e penna in UML. Inoltre testando l'applicazione che utilizza il framework, facciamo emergere gli errori introdotti con le modifiche. Tali errori diventano lo spunto per scrivere i test che dimostrano tali bug, ed una volta risolti, per rifattorizzare il codice scritto. Così via fino a che non emergono errori e gli oggetti sono thread safe rispetto ad errori(fault di un webservice) ed eccezioni(sollevate dagli stessi). In questo modo abbiamo scritto più di 40 casi test.
Rilasciamo quindi in ambiente di test l'applicazione con il nuovo jar: i nostri tester di fiducia non trovano nessun comportamento anomalo nell'applicazione: possiamo andare in produzione. Io e Marco ci sentiamo soddisfatti. In realtà siamo al corrente del fatto che c'è un altro piccolo problema, ma la probabilità che si verifichi è molto bassa: non vorremo mica far rimandare la produzione per colpa nostra?

Qualche giorno dopo la messa in produzione le prime sorprese. Il forward alle pagine non rispetta le specifiche! Da una transazione si viene inviati ad un'altra in modo non deterministico! Marco ormai (il giorno dopo la produzione) è stato messo su un altro progetto perché per la post produzione bastano due persone(sic!) ed io mi ritrovo con questa patata bollente sul groppone. Del resto non c'è molto da pensare nè strade da "scegliere": l'unica via possibile è continuare, mantenendo la calma(!), il ciclo virtuoso del bug->test->codice->refactoring che ci ha portato a costruire una rete di protezione per risolvere gli stessi bug e progredire.
Dai primi due test mi accorgo di essere alle prese con un problema che richiederà almeno qualche giorno. Inutile dire che non è stato così facile mantenere la calma, ma la scrittura di altri 20 test mi ha dato la confidenza della bontà della strada intrapresa.
Per concludere i due giorni di stima iniziale sono diventati ben 6...

Cosa ho imparato in questi sei giorni:
. fare attenzione a rimandare interventi strutturali sull'applicazione: è che vero che non è il reale valore aggiunto dell'applicazione, ma dargli una priorità talmente bassa da arrivare addirittura a ridosso della produzione è stato un errore.
. il valore dei test automatici è davvero inestimabile: scriverli facendosi guidare dagli stessi è SEMPRE una grande arma per ridurre il numero di bug che ci saranno o per risolverli quando si presenteranno scrivendo i test a-posteriori
. Test First rocks!
. sganciare su un altro progetto un membro del team appena il giorno dopo dalla messa in produzione non è mai una buona azione (se ci fosse stato Marco sicuramente in pair avremmo risparmiato almeno un paio di giorni)
. ho imparato una volta di più che dai fallimenti si impara spesso più che dai successi

3 commenti ( 635 visite )   |  permalink   |   ( 3 / 1155 )


Indietro Altre notizie