Navigando sul sito
http://agilemanifesto.org mi sono accorto che sono passati otto anni da quando firmai il manifesto sullo
sviluppo agile.
Cos'è successo in questi otto anni? Si fa un gran parlare, è vero, delle tecniche di sviluppo agili e termini come
Scrum ed
eXtreme Programming sono molto di moda, ma di fatto nella realtà
enterprise - specie in quella italiana - continuano a non vedersi progetti sviluppati secondo la filosofia Agile dello sviluppo del software. Viceversa, nel mondo
Open Source, l'Agile è di fatto la norma.
Spesso si vedono applicate le tecniche agili, come ad esempio
Pair programming o
Feature Driven Programming, ma in contesti che sono quelli tradizionali, e cioè quelli dello
sviluppo waterfall, che nella realtà
enterprise è tuttora l'unico modello supportato.
Frequentemente ho proposto di utilizzare un approccio Agile in diversi progetti reali, ma al di là di un qualche superficiale apprezzamento non si è mai andati.
Perché dunque, nonostante l'entusiasmo, specie degli addetti ai lavori, la metodologia Agile non ha preso piede? Io credo che le cause siano principalmente tre.
1. Il sistema non recepisce processi iterativi
Quello che caratterizza principalmente l'approccio Agile rispetto al Waterfall è il suo essere iterativo by design. Il progettista Agile sa che lo sviluppo software è spesso un processo "prima volta-primo uso", caratterizzato da un altissimo grado di incertezza, per affrontare il quale deve applicarsi una metodologia di gestione del rischio che non può che essere iterativa. L'iterazione tipica dell'Agile è quella indicata in figura:
Normalmente, in un progetto complesso, le iterazioni possono essere decine. Ma il "sistema" non è in grado di gestire le iterazioni! Se da una parte il Cliente vuole subito sapere quanto costerà il suo nuovo sistema informativo e quanto durerà il suo sviluppo, anche dall'altra il Fornitore ha tutta una serie di strumenti che funzionano solo se vengono immessi valori "a preventivo": quante risorse il progetto occuperà e per quanto tempo. Come ho riportato
in altri post, la stima del costo (tempo, denaro e altre risorse) di un progetto "
prima volta-primo uso" è un esercizio di fantasia destinato al fallimento. Tipicamente perciò chi fornisce un servizio di sviluppo software applica dei coefficienti di rischio molto alti proprio per cercare di assorbire questa incognita. Di fatto, nei sistemi dove è "necessaria" una stima dei costi a preventivo, il metodo Agile è escluso a priori.
2. Un processo che ricicla è considerato un processo di "serie B"
Nella concezione del Project Management classico, il "riciclo" - quindi la re-iterazione - è considerato come un "difetto", o meglio come la "conseguenza di un difetto". Il progetto perfetto non presenta ricicli: viene eseguito così com'era stato pensato la prima volta. Per chi non possiede una cultura informatica (direi, una cultura informatica recente) l'idea stessa che una metodologia preveda molti ricicli è semplicemente orrenda. E' orrendo dover immaginare di avere stime riviste, nuove implementazioni e nuovi test ad ogni riciclo. Impensabile immettere ad ogni nuova iterazione nuove funzioni e quindi nuovi bug! Il Cliente percepisce il metodo Agile come una mancanza di professionalità (non sviluppano: provano a sviluppare!) e lo staff non tecnico del Fornitore la percepisce come una intollerabile mancanza di certezze: quanto ci costerà il progetto, quante risorse impiegherà e per quanto tempo.
Bisogna però fare i conti con la dura realtà: che è tanto più vera e documentata quanto più i progetti aumentano in complessità e novità: all'inizio nessuno può sapere quanto costerà il progetto, nemmeno a grandi linee. Si possono fare delle stime, sulle quali però non può essere calcolato il prezzo al Cliente. Proprio per la grande aleatorietà di queste stime "a-priori", il prezzo sarà o largamente esagerato per assorbire il rischio, o sottostimato destinato cioè ad andare in perdita. Come dicevo, i sistemi (finanziari, di controllo e gestione e via dicendo) aziendali prevedono che questo prezzo venga calcolato all'inizio, sulla base del quale verranno poi derivati tutti i driver economici dell'azienda. Un calcolo basato, il più delle volte, sulla fantasia.
3. La metodologia Agile presuppone il Time&Materials
Esistono tipicamente due modi per vendere un servizio informatico: a pacchetto (
turn-key o
fixed bid) o a tempo (
time&materials, T&M). Nel primo, chi offre "scommette" su quanto effettivamente gli costerà il servizio: applica alla scommessa il proprio coefficiente di profitto e ottiene il prezzo. Nel secondo, semplicemente vengono erogati dei servizi e il Cliente paga "il tempo" di erogazione.
Per quanto abbiamo detto sin qui, la metodologia Agile presuppone la seconda opzione. Perché per poter vendere qualcosa
turn-key occorre essere confidenti sulla stima dei costi, cosa che abbiamo visto è molto difficile nel caso di progetti complessi. E perchè l'Agile è iterativo di suo.
Il committente di un progetto informatico complesso è molto poco propenso a iniziare a lavorare T&M, perché anche lui deve fornire una stima di quali saranno i suoi costi/tempi, e questo a priori! La naturale conseguenza di questo stato di cose è che si formulerà un'offerta
turn-key molto sovrastimata nei costi, ed esageratamente lunga nei tempi.
Io credo che queste tre siano le cause principali che hanno bloccato l'introduzione dei modelli Agili nella pratica dello sviluppo software a livello
enterprise. Sono convinto che un approccio iterativo e T&M possa permettere significative economie sia per chi vende, sia per chi compra soluzioni software. Tuttavia, perché lo sviluppo Agile possa essere effettivamente utilizzato, occorrono notevoli cambiamenti in termini di cultura, processi e strumenti di supporto aziendali.
