Dal Waterfall ai Principi Agili

La nascita della metodologia Waterfall

Molti di noi sapranno già che cosa si intende per metodologia Waterfall nell’ambito dello sviluppo di un progetto software, ma forse non è così nota la sua origine. Nel 1970 Winston W. Royce presentò tale metodologia a una conferenza ingegneristica, IEEE WestCom, come un processo sequenziale in cui ogni fase è completata prima che la successiva sia iniziata. Quello che per oscuri motivi si è perso nelle sabbie del tempo è che Royce stesso affermò che il metodo a cascata sarebbe stato il meno adatto per gestire un processo software e descrisse un processo iterativo molto simile a quello presente oggi in molte metodologie agili.

Sopravvivenza del meno adatto

Alla storia non manca il senso dell’ironia: nel 1985 il Dipartimento della Difesa statunitense adottò il metodo Waterfall come lo standard per tutti i progetti software di livello enterprise, sostenendo la sua diffusione a livello mondiale.

Una cascata di Software

waterfallNel caso specifico del software il Waterfall prevede di dividere il processo di sviluppo in fasi discrete e sequenziali; le principali sono:

  1. Raccolta requisiti
  2. Progettazione
  3. Codifica
  4. Testing

Sono passati ormai più di 40 anni dalla conferenza che introdusse il termine Waterfall e le sue limitazioni nell’ambito dello sviluppo software sono ormai evidenti e ben documentate:

  • alto Time To market: il committente del progetto non riceve nulla se non in fondo al progetto, che spesso dura mesi se non anni, durante i quali non ha modo di godere del vantaggio competitivo sul business che si proponeva di ottenere dalla commessa stessa;
  • rigidità: il committente del progetto, anche a fronte di cambiamenti dello scenario del mercato, ha difficoltà ad influire su quanto richiesto, perché la fase di progettazione è tutta all’inizio e non è previsto un suo coinvolgimento se non alla fine della commessa stessa;
  • costi elevati: quello che appare come un processo lineare ed efficiente diventa spesso (nel caso del software) una serie di cicli turbolenti che fanno perdere tanto tempo e tanti soldi. Questo perché le fasi sono legate tra loro da artefatti che non sono definibili in modo rigoroso e questo scatena tutta una fase di cicli di revisione all’indietro che riducono drasticamente l’efficienza del metodo.

Agilisti alla riscossa

Nel 2001 17 professionisti di spicco si radunarono in una località sciistica dello Utah per discutere assieme del futuro del mondo software, stanchi di assistere ad una percentuale sempre crescente di progetti software che si frantumavano sulle rocce al termine della cascata o rimanevano impantanati in cicli infiniti e fallimentari lungo la strada.

Dall’incontro di queste persone si generò una riflessione profonda e limpida: il metodo ingegneristico applicato al software non è detto che funzioni in quanto lo sviluppo software è una attività creativa e non produttiva, richiede l’apporto di knowledge worker e non di operatori, con una forte componente artigianale e di interazione umana.

Il manifesto Agile

Questa semplice (a posteriori!) rivelazione portò alla stesura di un Manifesto Agile contenente 4 semplici ma rivoluzionari principi:

Consideriamo importanti:

  • Gli individui e le interazioni più che i processi e gli strumenti;
  • Il software funzionante più che la documentazione esaustiva;
  • La collaborazione col cliente più che la negoziazione dei contratti;
  • Rispondere al cambiamento più che seguire un piano;

Una nuova era

Il Manifesto Agile e i Dodici principi dell’agile, che dettagliavano ulteriormente alcuni aspetti, avrebbero cambiato tutto: oggi compagnie come Google, IBM, Microsoft, Yahoo, Amazon e molte altre utilizzano una o l’altra delle tante metodologie Agile che dal 2001 ad oggi sono fiorite e di cui parleremo.

L’infografica di CoseNonJaviste

Per celebrare le illustri persone che hanno firmato il Manifesto Agile, che con il loro contributo hanno radicalmente cambiato il mondo in cui il software viene creato e percepito, e per ringraziare voi, i nostri lettori, che ci seguite così assiduamente, abbiamo pensato di proporre un piccolo regalo: l’ dal nostro sito.

Alla prossima!

Riferimenti

Manuele Piastra

Sono uno Scrum Master e Project Manager i cui skill tecnici sono focalizzati al momento sullo sviluppo di applicazioni Java EE su IBM Websphere 7.0 utilizzando JSF (RichFaces), JPA (EclipseLink) ed EJB3. Presso OmniaGroup ricopro il ruolo di Training Manager: seleziono il personale tecnico, mi occupo della sua crescita formativa organizzando Corsi e Workshop sia interni che esterni, molti dei quali hanno visto me come docente. -