Qualcuno si ricorda come si facevano le foto prima dell’avvento del digitale? Dovevi avere ben chiare le condizioni, il set, i soggetti e poi via a scattare a raffica consumando tutto il rullino! Una volta finito aspettavi con impazienza lo sviluppo e una volta pronte scoprivi se erano usciti dei grandi scatti, delle ciofeche o delle belle foto bruciate….
Ma torniamo ai giorni nostri e riprendiamo la stessa situazione: preparate le condizioni per fare una buona foto, fate lo scatto e.. controllate immediatamente il risultato! Se non è soddisfacente rivedete le condizioni, aggiustate la luce, spostate i soggetti, cambiate i filtri, gli effetti e siete pronti per un nuovo scatto. Non va bene? Ricominciate da capo fino ad ottenere lo foto perfetta che vi faccia ottenere milioni di like sui social. Agile, no?
Ma che c’entra questo con lo sviluppo di software? Moltissimo, ma forse è il caso di fare un po’ di chiarezza e raccontare una storia…
In principio fu il Waterfall
Il metodo a cascata (“Waterfall” appunto) vede le sue origini nell’industria manifatturiera e nel settore delle costruzioni, ambienti in cui il processo di lavoro è stato ed è tutt’ora per forza di cose lineare. Pensate ad esempio alla costruzione di una casa: prima bisogna trovare il terreno, poi fare le fondamenta, poi passare ai muri, ecc.. seguendo uno schema decisamente lineare fino al raggiungimento del prodotto finito. Quando lo sviluppo del software cominciò a essere concepito come attività industriale, questa metodologia venne declinata anche in questo settore.
Nel 1970 l’informatico Winston W. Royce fu il primo a proporre l’applicazione di questo approccio anche nei processi di sviluppo del software. Il nome “waterfall” invece venne coniato poco più tardi, la prima apparizione ufficiale infatti risale ad un paper del 1976 di T.E. Bell e T.A. Thayer.
Il modello a cascata (waterfall model) originale, detto anche ciclo di vita a cascata (waterfall lifecycle) o ciclo di vita del software, prevedeva una sequenza lineare delle fasi:
- Analisi dei requisiti
- Progettazione
- Sviluppo
- Collaudo
- Manutenzione
Inizialmente l’introduzione del modello a cascata fu una grande innovazione tra i sviluppatori di software, considerando che si arrivava da una situazione in cui l’approccio allo sviluppo era definito “code and fix”, un modo molto artigianale di procedere per tentativi ed errori.
Attorno agli anni ‘80 questo metodo iniziò ad essere messo in discussione, i principali difetti emersero particolarmente nell’affrontare progetti molto grossi e i cui requisiti non erano ben chiari fin dal principio. La linearità del metodo non consentiva infatti di tornare facilmente (o agilmente..) sui propri passi e ogni fase doveva essere conclusa prima di poter affrontare la successiva.
Nel tempo il modello waterfall venne rivisto e migliorato, infatti l’industria relativa allo sviluppo di software se ne avvale ancora ad oggi. La linearità e la semplicità di implementazione del modello lo rendono ancora un approccio valido, ad esempio quando si affrontano progetti di piccole dimensioni con specifiche precise e chiare fin dal principio, con dei limiti di tempo e di budget restrittivi o con vincoli di legge stringenti.
Vi ricordate quando parlavamo di fotografia? È innegabile che anche prima dell’arrivo della fotografia digitale siano stati realizzati dei veri e propri capolavori! Certo, per ottenere tali risultati i fotografi più esperti non lasciavano nulla al caso: tutto doveva essere organizzato nei minimi dettagli prima di mettersi dietro la macchina fotografica…
E venne l’Agile
Ma oggi? Come ci comportiamo in questo mondo in continua evoluzione, dove le esigenze di mercato mutano di giorno in giorno e la concorrenza corre alla velocità della luce? La risposta è una: bisogna sapersi adattare agilmente!
Verso la metà degli anni ‘90 l’industria di sviluppo software iniziò a interrogarsi su come affrontare questa situazione e come sfornare in tempi brevi software funzionante, di qualità e che sapesse reggere nel mercato in continua evoluzione. Si iniziò a parlare di approcci “agili”, snelli, iterativi e focalizzati sulle reali necessità dei committenti. Il processo di sviluppo non era più visto come una sequenza rigida e lineare, ma suddiviso in fasi ripetute dette sprint. In ogni sprint c’era infatti la possibilità di analizzare piccole parti di richieste e valutare il modo migliore di svilupparle, per poi passare direttamente a sviluppo, test e rilascio.
Fu così che nel febbraio del 2001, in una località sciistica dello Utah, diciassette “thinker” del settore si incontrano per “parlare, sciare, rilassarsi e cercare di trovare un terreno comune e, naturalmente, per mangiare”. Da questo idilliaco incontro nacque la “Agile Alliance”, una sorta di Avengers dello sviluppo del software, che incise sulla pietra il famoso “Manifesto for Agile Software Development”.
Il manifesto sposta il focus su nuove tematiche, considerate di maggiore importanza rispetto agli aspetti considerati fondamentali nel metodo Waterfall. Principi come le persone e le iterazioni, il software funzionante, la collaborazione continua con il cliente e la capacità di adattamento vengono anteposti a questioni più tecniche come i processi, gli strumenti, la documentazione, la negoziazione e la linearità. Nel manifesto trovano inoltre spazio i famosi 12 principi sottostanti al Manifesto Agile, principi che vanno a rafforzare i concetti base dell’approccio Agile.
L’attenzione alle necessità, alle iterazioni, alle relazioni e alla collaborazione ha portato come ovvia conseguenza a dover rivedere il processo definito nel metodo Waterfall, passando quindi da un processo rigido e lineare ad un processo appunto più agile, snello e adattabile basato su singole fasi di sviluppo iterative, i cosiddetti Sprint.
Ma come funzionano queste fasi? Ogni Sprint consente di rilasciare una parte di applicativo contenente specifiche funzionalità concordate all’inizio dello sprint stesso. Il cliente ha quindi la possibilità di utilizzare e testare il software, restituendo preziosi feedback al team di sviluppo utili per continuare l’implementazione negli sprint seguenti, avvicinandosi di volta in volta ad un prodotto finale qualitativamente più alto e più vicino alle sue esigenze.
Ad oggi quando si parla di approccio Agile allo sviluppo del software in realtà si fa riferimento a vere e proprie metodologie Agile che condividono la stessa filosofia, le stesse caratteristiche e spesso gli stessi strumenti. Questo permette alle aziende che vogliono seguire la via dell’Agile di scegliere le tecniche che fanno al caso loro, progetto per progetto, situazione per situazione.
Le principali metodologie Agile utilizzate ad oggi sono:
- Agile Scrum Methodology (o semplicemente Scrum) – scoprila qui
- Lean Software Development
- Kanban
- Extreme Programming (XP)
- Crystal
- Dynamic Systems Development Method (DSDM)
- Feature Driven Development (FDD)
Torniamo alla nostro esempio iniziale: di sicuro un approccio “agile” alla fotografia non ci fa diventare gli Oliviero Toscani di turno, ma di sicuro ci permette di fare un gran figurone con i nostri scatti, di risparmiare soldi in pellicole (che ormai sono state tolte dal mercato..) e un sacco di tempo!