Guest post di Omar Milini, full stack developer di Monade.
Introduzione
Ti ricordi come si facevano le foto prima dell’avvento del digitale? Dovevi avere ben chiare le condizioni, il set, i soggetti e 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.
Torniamo ai giorni nostri e riprendiamo la stessa situazione: prepari le condizioni per fare una buona foto, fai lo scatto e controlli immediatamente il risultato!
Se non è soddisfacente rivedi le condizioni, aggiusti la luce, sposti i soggetti, cambi i filtri, gli effetti e sei pronto per un nuovo scatto.
Non va bene? Ricominci da capo fino a ottenere lo foto perfetta che ti faccia ottenere milioni di like sui social.
Agile, no?
Ma che c’entra questo con lo sviluppo del 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.
Pensa, ad esempio, alla costruzione di una casa: prima bisogna trovare il terreno, poi fare le fondamenta, poi passare ai muri, e così via. 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 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, 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 del 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.
Ti ricordi quando parlavo 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 poi 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 del 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”.
Stava ufficialmente nascendo il metodo Agile.
Il manifesto sposta il focus su nuove tematiche, considerate di maggiore importanza rispetto agli aspetti considerati fondamentali nel metodo Waterfall.
Princìpi 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 del metodo 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 metodo 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.
Più che un solo metodo Agile, ne esistono vari. Al momento i principali metodi e framework Agile sono:
- Agile Scrum Methodology (o semplicemente Scrum)
- 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 e un sacco di tempo.
Guest post di Omar Milini, full stack developer di Monade.
