Ecco, sento che adesso qualcuno si risentirà. Beh, se chi si adombra è il tipo umano che dico io, allora della qual cosa non mi può interessare di meno.
Nei suoi ultimi anni, Giorgio Gaber diceva a proposito degli yuppies: non è che giocare a squash faccia diventare imbecilli… Però aiuta, eh?
Bene, siccome parliamo di Agile, ora che ho fatto la battuta dovrebbero essere scappate le persone che approcciano le cose ridicole in modo serio, ma spero che siano rimaste a leggere le persone che approcciano in modo divertente le cose serie.
La metodologia Agile, in qualsivoglia declinazione, è fantastca. Davvero. A patto che… A patto che:
– signori, non è che prima che scrivessero i libri su Agile certe idee i vecchi informatici non le avessero maturate. L’esperienza le aveva suggerite anche a loro; semplicemente non c’era ancora stato nessuno che avesse deciso di farne un business, e uno strumento di potere, e quindi non c’era ancora una terminologia di riferimento. Tutto qui
– che la riunione sia uno strumento di lavoro che occorre sapere usare e che deve fornire in output risultati certi è elemento che qualsiasi corso di comunicazione aziendale cercava di infilare a viva forza nella dura cervice degli informatici almeno dagli anni ’80
– che “ciò che non c’è non si rompe”, e che il software, per sua natura, è una cosa leggera in cui si gioca a togliere, non ad aggiungere, i più svegli lo avevano capito da un pezzo (e molti altri no, equamente ripartiti tra ingegneri, matematici, fisici e statistici: la pesantezza è attributo maledettamente democratico che non passa mai di moda)
– che il software non testato è un software che non funziona, e che quanto più è piccola l’unità da testare tanto più facile è il compito di test, si sapeva da molto prima che si parlasse di Agile. Che si passasse più tempo a programmare le “contro-macchine” (questo uno dei tanti nomi che prima di Agile si dava alle unit) che non il software per il cliente, era notizia che i manager armati di GANTT non dovevano assolutamente venire a sapere, ma che gli informatici conoscevano benissimo e di cui custodivano gelosamente il segreto per il bene di tutta l’azienda
– che comunque il test fatto tramite unit non sia esaustivo è una verità che va ululata a squarciagola, perchè finchè dobbiamo vendere pentole sul sito di e-commerce tutti i santi aiutano, ma se dobbiamo gestire il traffico ferroviario la musica è diversa
– che il committente “capisce ciò che vuole solo quando vede ciò che non vuole”, e da qui la necessità di confronti ravvicinati, è aforisma che sento da ben prima degli anni ’00
– che il software prodotto tramite metodologia Agile sia di qualità migliore rispetto a quello prodotto tramite altri metodi è una tautologia autoreferenziale non corroborata da alcun dato. Certo, avere un quadro di riferimento aiuta a non disperdersi, avere dei momenti di verifica ravvicinati aiuta a non lasciare impaludare il progetto, pericolo sempre presente nel nostro mestiere. Ma la qualità è un’altra cosa. Agile aiuta a non stare fermi, ma se dobbiamo muoverci per scavare una buca e poi riempirla, allora forse anche andare al bar non è soluzione da scartare
– non c’è nulla nella metodologia Agile che aiuti a capire il problema del committente; anche se le verifiche sono ravvicinate, quando un certo informatico è partito per il suo progetto non lo fermi più. Ammesso che a un certo punto capisca di avere sbagliato strada, piuttosto che buttare via 3 settimane di sprint porta a termine un progetto inutilmente complesso che costerà un occhio della testa in manutenzione al committente. Capire le necessità del committente, di fatto, è un dono, o ce l’hai o non ce l’hai. Forse ti hanno fatto bene le lezioni di storia, di filosofia, di latino, o i tre mesi a raccogliere le pere. Ma se conoscete qualcuno che ha imparato a capire le esigenze del cliente tramite un manuale Apogeo, presentatemelo che vi pago da bere.
Potrei andare avanti per altri 20 capoversi, ma il pippone mi pare già fin troppo chiaro. Agile è fantastico, se non diventa un rituale, il dito che indica la luna. Se resta quello che è, un quadro di riferimento, una raccolta di regole – poche chiare e condivise – allora è un buon modo di lavorare. Per chi ha in testa l’equivalenza Agile=Informatica… buona partita di squash.