lunedì 30 luglio 2012

Non molto Agili... fin qui!

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.



5 commenti:

Anonimo ha detto...

Interessanti spunti Alessio. Personalmente mi trovi un po' "dissonante" sulla questione agile, soprattutto su come l'hai posta. Non tutti gli approcci iterativi (fortunatamente) sono agili, quindi la contrapposizione waterfall-iterativo non è necessariamente una contrapposizione tradizionale-agile.
Le osservazioni che poni sono poi prevalentemente di tipo "manageriale". Personalmente ho visto fallimenti dell'approccio agile causati principalmente dalla scarsa qualità tecnica all'interno dei gruppi di lavoro. Agile sembra facile, sembra bello, sembra intuitivo, sembra economico. Se non hai un team di bravi programmatori, è quasi sicuramente un fallimento. Come dici giustamente, è anche una questione di cultura. E la cultura, come la qualità, non si improvvisa, né si ottiene per caso. Il guaio, agile o meno, è che lo sviluppo del software è ancora troppo artigianale. E ciò vale sia per la programmazione, sia per la gestione dei progetti.

Guildenstern70 ha detto...

Vero: waterfall non è necessariamente tradizionale e iterativo non è necessariamente Agile. Ma Agile presuppone iterativo, e se tutti gli strumenti di controllo e gestione aziendale non prevedono ricicli, diventa difficile... Certo Agile non è la panacea, non deve essere "la soluzione" a tutti i problemi dello sviluppo software, ma un'alternativa credibile...

Massimiliano ha detto...

Alessio, forse questo l'hai già letto. Te ne avrei parlato a voce, ma purtroppo non siamo riusciti a incontrarci a Diano ;-)
http://www.sviluppoagile.it/ho-avvistato-un-contratto-agile-sano-esistono

Guildenstern70 ha detto...

No, non avevo letto, ma vedo che parliamo delle stesse cose. E' evidente che il problema è sentito, quanto alla soluzione... bisognerebbe che qualcuno un po' Agile arrivasse alla stanza dei bottoni!

Jacopo Jakuza Romei ha detto...

Tra 13 giorni inizio a pubblicare i capitoli del libro che, dopo 5 anni dall'articolo pubblicato, ho deciso di scrivere su contratti e negoziazione per programmatori e tutti i 'knowledge worker'.

Questa newsletter è zero-spam e sarà il mezzo principale di comunicazione: http://eepurl.com/bOOvCr

Ti aspetto lì Alessio! :-)