Sulla sessione “Is Software Evolution Really Effective” di Francesco Cirillo
Francesco Cirillo ha presentato questa sessione sabato scorso all’Italian Agile Day. Ho letto su http://joind.in/talk/view/4508 diversi commenti che non mi tornavano; allora ho scritto questa mia personale esegesi, perché penso che il messaggio di FC sia molto importante e mi secca vedere che viene spesso frainteso.
Quindi vi do la mia personale interpretazione, senza pretendere di parlare per Francesco. Fatto: se proviamo a leggere un qualsiasi libro in tema Metodi Agili, si dà per assodato che usando i Metodi Agili si diventa più bravi.
La realtà dei fatti, che ho personalmente riscontrato nelle mie esperienze, è che spesso questo non è vero. Diversi team agili di mia conoscenza hanno fallito progetti, o comunque hanno conseguito una fama di essere troppo cari. Fama immeritata? Che importa! Se il risultato finale è che il cliente non ti sceglie più hai fallito. E poi è facile che la fama non sia poi così immeritata.
E’ vero che molte pratiche agili producono un beneficio immediato; quel problema che facevi fatica a debuggare si risolve brillantemente con gli unit test, la comunicazione con il cliente migliora se andiamo a chiedergli che cosa pensa veramente, ecc. ecc. Ma c’è un grosso MA. Ci vuole molta, molta fatica per rendere questi benefici permanenti. E’ sulla distanza che si vede la differenza.
Tanti che credono di programmare a oggetti scrivono invece codice procedurale, e la differenza sulla distanza si traduce in codice ingarbugliato. Tanti che si rifiutano di fare big design upfront, non hanno capito che devono fare invece tanto design in maniera continua. E magari non sarebbero in grado di farlo neanche se volessero, il design upfront, né big né small. E poi, ci vuole tanto coraggio per continuare a mantenere un vero contatto con il cliente nel lungo periodo.
Kent Beck ha detto “What does it mean to be agile? My definition is that you accept input from reality and you respond to it”. Allora facciamola per davvero questa follia di accettare l’input dalla realtà! Misuriamo quanto ci costa sviluppare. E’ da qui che si vede se quello che facciamo funziona veramente.
E già che ci siamo, da quanto tempo non andiamo dal cliente a chiedergli “sei contento di come lavoriamo?”
Update 2011/12/11: updated link to HD video
November 21st, 2011 at 11:40
Concordo perfettamente e mi metto tra quei team che non fanno Agile nel migliore dei modi e che hanno ancora molto da imparare, ma che per lo meno hanno tratto beneficio da tutta una serie di pratiche….
Quello che sicuramente posso testimoniare è che Agile è difficile, specialmente se non sei immerso in un team che lo fa da tempo.
Quello che Cirillo non dice, perché probabilmente se lo vuole “vendere”, è quali possono essere le soluzioni. Come ci si accerta di essere su un percorso di miglioramento continuo?
Evidentemente le retrospettive non bastano altrimenti ogni buon team agile non smetterebbe mai di migliorare….
November 21st, 2011 at 21:28
Francesco è molto bravo a farci riflettere sulla nostra professione e sui noi stessi. Il fatto che accenda gli animi secondo me è positivo perché vuol dire che ha toccato le corde giuste.
Ho scritto un post (http://blogs.ugidotnet.org/AntonioGanci/archive/2011/11/21/la-fabbrica-delle-giustificazioni.aspx) per esprimere il mio punto di vista.
November 22nd, 2011 at 16:26
“Fatto: se proviamo a leggere un qualsiasi libro in tema Metodi Agili, si dà per assodato che usando i Metodi Agili si diventa più bravi.” -> mi fai un esempio, uno solo di un libro un minimo decente che dice che usando agile si diventa piu’ bravi?
Io questa cosa, che e’ una boiata pazzesca, l’ho sentita spesso da agile-taleban ma mai da veri esperti o su libri.
Anzi a memoria su Schwaber dice di Scrum che degli incapaci con scrum produrranno spazzatura, regolarmente ad ogni sprint. Stesso discorso sui libri di UncleBob, Poppendieck ecc.
Sul discorso finale pero’ non sono d’accordo con Francesco.
10000 euro come costi vivi per una app su iphone sono uno sproposito, posso trovare 10 programmatori italiani che me la fanno per meno della meta’, compresi ragazzi del mio team. Quindi non capisco il senso dell’esempio.
November 22nd, 2011 at 17:17
Ahem…. ho preso tre libri a caso:
JB Rainsberger, JUnit Recipes:
Test-Driven Development, By Example, dal retro del libro (lo so che è un colpo basso, ma hei! E’ scritto sul libro)
Extreme Programming Installed, from the preface:
Etc etc. Sarai d’accordo con me che leggere queste cose può riempirti di entusiasmo! Ma anche creare delle illusioni. E’ contro di questo che credo che Francesco si sia scagliato, contro le facili illusioni. OK che poi tutti quelli veramente bravi come Beck, Jeffries, Rainsberger saranno i primi a esprimere cautela; resta il fatto che uno può fraintendere e illudersi.
Il discorso dei 10K-20K euro Francesco l’ha presentato come un dato: l’offerta più bassa e la più alta. Sono offerte fatte da aziende, non da singoli. E’ chiaro che è uno sproposito e proprio per questo Francesco lo segnala come tale. Traine tu le tue conclusioni.
November 22nd, 2011 at 17:30
Altra piccola nota: non ho capito se il Code Monster di Francesco era di un team agile o no. Se la risposta fosse si’, allora come fanno a definirsi agili? Come fanno a cambiare quel mostro?
Cioe’ alla fine mi pare che Francesco abbia detto che ci sono tanti team che pensano di essere agili ma non lo sono, cosa su cui sono d’accordissimo.
November 22nd, 2011 at 17:42
Le prime due mi paiono ragionevoli: usando TDD puoi migliorare il tuo codice. –> vero
Sulla terza invece Chapeau! Ma in fondo e’ la prefazione e il povero Ron Jeffreys vorra’ vendere qualche copia del libro. :)
Pero’ nessuno (neanche Ron) ha mai detto che “usando i Metodi Agili si diventa più bravi.”
November 22nd, 2011 at 17:43
Sulla questione del costo dell’app per iPhone vorrei però sottolineare una cosa.
Se chiedi ad un’azienda quanto costa fare l’app non puoi aspettarti una cifra tipo 1.000 euro per vari motivi.
Un’azienda non si scomoda nemmeno per 1.000 euro, non prende proprio il lavoro.
Ammesso che sia comunque interessata al lavoro ha due possibilità:
a) prende una persona nuova a tempo determinato per sviluppare l’app e quindi sopporta il costo una tantum della persona e dell’infrastruttura che gli mette a disposizione. Non credo che 1000 euro siano sufficienti (magari l’azienda non possiede un iphone e quindi come minimo deve comprare quello). Il costo da sopportare secondo me si avvicina facilmente ai 5.000 euro.
b) L’alternativa è utilizzare personale interno, ma il personale interno non è che sta lì ad aspettare mentre prende un caffè. Sicuramente è impegnato in altre cose, quindi oltre al costo del personale interno (pro quota per il tempo necessario) ci sarà anche il costo dovuto al distogliere tale personale da altri progetti.
Quello che voglio dire è che sviluppare un prodotto anche piccolo come il Pomodoro ha comunque uno zoccolo di costi e questo zoccolo non è che necessariamente si abbassa al diminuire della complessità del prodotto.
Quindi l’esempio di Cirillo secondo me non è particolarmente rilevante.
Molto più rilevante sarebbe chiedere: quanto mi costa sviluppare questo prodotto complesso? Quanto mi costa aggiungere o modificare una feature a prodotto finito?
Probabilmente è in questi casi che il team agile vince, ed è in questi casi che il team anziano e competente vince sul team giovane ed inesperto.
Per quanto riguarda le illusioni dell’Agile mi ricordo perfettamente di aver letto su un libro (cercherò quale perché non mi viene in mente.., ma sicuramente è di un autore importante, perché ho solo quelli di libri….) una frase del tipo “il tdd funziona anche perché non richiede sviluppatori particolarmente bravi, mette in grado tutti di scrivere codice decente”.
Sul fatto che un medio Agile è meglio di un medio Waterfall non mi sembra ci siano particolari dubbi, il problema che Cirillo pone è: fare Agile a livello medio non è particolarmente difficile, farlo ad alti livelli, con continuità e migliorando costantemente è molto difficile. Rimane la domanda: come si fa a sapere su che strada si è? Come si imbocca quella giusta? Come ci si rimane?
November 22nd, 2011 at 17:55
“Il discorso dei 10K-20K euro Francesco l’ha presentato come un dato: l’offerta più bassa e la più alta. Sono offerte fatte da aziende, non da singoli. E’ chiaro che è uno sproposito e proprio per questo Francesco lo segnala come tale. Traine tu le tue conclusioni.”
-> Ma e’ ovvio che se chiedo ad un’azienda di fare una cavolatina i costi vanno alle stelle. Come chiedere ad un’impresa di attaccarmi le tende alle finestre.
Ma quello che diceva Francesco era che 10k non erano il preventivo dell’azienda ma i loro costi interni (ma come fa a saperli?). A questo punto se quella azienda e’ ancora in commercio significa che evidentemente riesce a rivendere a 20k l’applicazioncina (40k per l’azienda agile), quindi o ha degli ottimi commerciali oppure ci sono altri fattori che non sappiamo.
Pero’ sarebbe interessante sapere come sono arrivati ai 10k… hanno stimato 3 mesi uomo? strapagano i loro dev (improbabile)? boh detta cosi’ e’ un’informazione che mi e’ poco utile.
November 22nd, 2011 at 19:35
Ho avuto l’opportunità di applicare in team molte singole pratiche derivanti dal mondo Agile, ma non di lavorare in un team il cui processo si possa definire così. Quello che abbiamo estratto dalle pratiche sono quei benefici immediati di cui parla Matteo.
Quello che non sono riuscito a capire è se il costo alto di cui parla Francesco è di un team che crede di fare Agile o del team Agile anche quando lavora bene. Il suo talk di better software mi pare fosse riferito al prima caso, così come nell’esempio team nuovo/team vecchio che costa di più.
November 23rd, 2011 at 17:34
@Giorgio: se un team ha un costo esorbitante, cioè sproporzionato rispetto al valore che produce, allora (evidentemente) non sta lavorando bene. La scommessa su cui si basa XP è che prendersi il tempo per fare le cose bene produrrà un migliore ROI. Il risultato della scommessa non è scontato :)
November 23rd, 2011 at 17:41
@Andrea: d’accordo che un’azienda ha i costi fissi, ma dipende anche dal prodotto che devi fare. Se un lavoro piccolo costa uno sproposito, quante sono le probabilità che un prodotto grande costi il giusto? Il fatto che un prodotto piccolo costi un botto potrebbe essere un’indicazione che l’azienda non ha un processo che funziona bene per la produzione di software.
E sai perché per me è particolarmente importante questa capacità di fare pagare poco un prodotto piccolo? Perché sul prodotto piccolo ci sono poche possibilità di alzare una cortina di fumo. Il successo o il fallimento sono molto più evidenti. Su un progetto di un anno non c’è lo stesso livello di attenzione, non c’è lo stesso feedback rapido fra l’azione e il risultato.
Es. è entrato un lavoro da 1000 euro che ci viene a costare 2000 euro: risultato, dobbiamo capirci meglio; o impariamo a farlo costare di meno o impariamo a farlo pagare di più.
Se entra un lavoro da 100.000 euro che ci viene a costare 130.000 euro, il risultato è molto più grave ma le possibilità di ignorare la realtà e dare la colpa al commerciale, al dirigente, al cliente, alla tecnologia, al maltempo, al governo, a Steve Jobs o a Bill Gates sono infinite. Risultato –> non si impara e non si migliora.
Per questo i progetti piccoli sono interessanti :-)
November 25th, 2011 at 08:14
Matteo, le tue osservazioni sul prodotto piccolo e l’impossibilità di alzare la cortina di fumo le trovo corrette.
Quello che secondo me però va tenuto presente è che normalmente un’azienda (e qui escludo le partite iva “personali”) è una macchina tarata su prodotti di una certa dimensione ed è quindi inefficiente su prodotti troppo piccoli.
E’ come chiedere alla Barilla: quanto mi costa un sacchetto di pasta personalizzato? Secondo me verrebbe uno sproposito.
Con questo non voglio dire che Cirillo sbagli, anzi come ho scritto mi sento di condividere le sue osservazioni, quello che non mi convince è lo strumento di misura che ha usato. E quello che mi rimane è quindi solo una sensazione, in parte comprovata anche dalla mia limitata esperienza personale, ma nessuna statistica oggettiva.
November 25th, 2011 at 12:19
OK Andrea, ma se è vero che l’azienda non riesce a fare prezzi competitivi su un prodotto personalizzato piccolo, vuol dire che perde un’opportunità di business che verrà colta forse da qualcun’altro. Vuol dire che l’azienda non ha un processo che le consenta di cogliere queste opportunità. E fin qui può anche starci. Quello che non mi chiedo è se invece nel caso di un prodotto grande il processo ci sia, o non si tratti semplicemente del fatto che nel prodotto grande il danno prodotto dal processo carente si nota di meno :-)
November 25th, 2011 at 22:19
Sono daccordo, nel caso di un prodotto grande è più facile mascherare le inefficienze anche perchè c’è maggiore probabilità di effetti di mutua cancellazione. Immagino però che sia proprio su un progetto grande che un team efficiente possa riuscire a dare il meglio di se.
Se questo è vero però dovranno pur esistere delle statistiche che lo dimostrano.
In realtà non mi è ancora capitato di trovare una citazione di una statistica veramente autorevole che dimostri che, per lo meno su certi prodotti, Agile vince su Waterfall. Al di la delle sensazioni, dei gusti e anche della propria esperienza personale, sono questo genere di statistiche che possono smuovere un management ancorato a vecchie idee e pratiche.
Anche il Chaos Report che viene spesso citato per confutare Watrfall in realtà mi sembra alquanto controverso….