Extreme Enthusiasm

Summary: report of my test-driven development talk at the friday afternoon club of the Milano University C.S. Dept.

Venerdì 19 scorso ho parlato di test-driven development ai vecchi amici della scuola di dottorato in informatica, in via Comelico a Milano. Loro hanno questa simpatica abitudine di fare seminari informali al venerdì pomeriggio, e mi hanno gentilmente invitato. Ho modificato la mia presentazione standard; ho inserito del materiale introduttivo da “A metric leading to agility” di Ron Jeffries, soprattutto prendendo spunto dalla bella intervista che hanno pubblicato su InfoQ.

Di solito come demo uso il kata del bowling di Robert Martin; questa volta, per cambiare, ho presentato il kata del supermercato di Dave Thomas. In Ruby, perché lo trovo più divertente, oltre che conciso.

Devo dire che gli astanti hanno colto subito il punto della cosa, che sarebbe l’idea di fare design durante e non prima. Lo dimostra il fatto che mi hanno fatto numerose obiezioni… La più interessante è stata quella di Andrea, che obietta che lui fa design prima, e riesce ad evitare i problemi di over-design, design eccessivamente anticipatorio, e design semplicemente errato perché, lui dice, è bravo e non fa di questi errori.

Sono il primo a sostenere che la prima cosa che fa la differenza in un progetto è la qualità delle persone; sono perfettamente convinto che un team di waterfallisti capaci possano dare la birra a un gruppo di XPer inesperti (vedi per esempio la copertina di Boehm, Software Engineering Economics.) Detto questo… l’approccio “sono bravo quindi non sbaglio” è rischioso. Tanto per cominciare, come fai a trasmettere questa tua bravura agli altri? Come fai a lavorare in team? Essere l’elemento trainante stufa dopo un po’. Significa che fai la gran parte del lavoro e non riesci a distribuirlo. Mentre tu ti stai impegnando per il tuo ottimo design, gli altri che fanno?

Non mi piace questo approccio direttivo. Io faccio il design, gli altri lo eseguono; mi pare che l’unico risultato possa essere di allevare un team di mediocri. Io vorrei che il design fosse una cosa condivisa da tutti i membri del team. Quando il design piomba dall’alto, chi lo deve eseguire lo subisce. Magari nel tuo team c’è uno veramente in gamba che vorrebbe fare in maniera diversa; ma non può, perché è costretto a fare come dice il design che gli è piombato dall’alto. Il risultato è che presto o tardi questo elemento in gamba se ne va altrove! E’ dura ammettere che quello che vuoi fare tu si possa fare funzionare anche in un’altra maniera. Ma è necessario se si vuole fare un team.

E il tuo cliente, comunque, non potrà toccare con mano la tua bravura fino a quando non avrai finito il tuo design e il team non potrà cominciare a implementare.

Resto convinto che il design evolutivo sia la maniera più efficace di fare design.

(Slide della presentazione)

This entry was posted on 22 January 2007 at 11:48 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.