Oggi si sente spesso parlare di Agile come la metodologia ideale per realizzare un prodotto o sviluppare un progetto. Agile, però, non è esattamente una metodologia.
Perché questa precisazione? Ve lo spieghiamo subito.
Il modello Waterfall: l’organizzazione del lavoro e le criticità della “cascata”
Fino all’inizio degli anni 2000, l’organizzazione del lavoro rientrava quasi sempre nella cosiddetta metodologia a cascata (Waterfall), lontana derivazione della catena di montaggio.
Il modello Waterfall si basa su una struttura sequenziale di fasi, che sicuramente vi sarà familiare: ogni nuova fase del progetto può partire solo dopo il completamento della precedente. Un esempio semplificato risulterebbe così:
- Analisi dei requisiti e studi di fattibilità (anche sui costi);
- Progettazione completa;
- Sviluppo completo;
- Implementazione e collaudo;
- Correzioni e manutenzione.
Una struttura poco elastica
Il primo limite del modello Waterfall sta proprio in questa struttura: il prodotto viene consegnato solamente alla fine del processo. E se qualcosa non funziona? Esatto: se l’errore è nelle fasi “alte”, bisognerà ricominciare daccapo.
Tutte le fasi vengono infatti organizzate prima dell’inizio del progetto e ogni completamento di fase va dettagliatamente documentato al committente con pagine e pagine di documentazione tecnica.
Siamo sicuri di riuscire a prevedere, in anticipo, tutto quello che può accadere durante ogni singola fase?
Una gerarchia rigida
Il secondo elemento che viene normalmente contestato nel modello Waterfall è l’organigramma.
Il team ha una leadership gerarchica, con il capogruppo che deve approvare i singoli passaggi e si interfaccia con il committente in una mentalità top-down (chi commissiona è in alto, chi esegue è in basso).
Un modello, questo, che tiene poco conto delle esigenze reciproche e che impedisce al committente di partecipare alle fasi della progettazione.
Nessuno deve dimenticare l’importanza del modello Waterfall nella storia dell’industrializzazione. Ma in seguito, com’è giusto che sia, se ne sono evidenziate le criticità. Waterfall è in più parti troppo macchinoso, consente un confronto e una crescita molto limitati e, soprattutto, è statico.
Ma il mondo di oggi non è più statico. Siete d’accordo?
Durante il periodo di sviluppo di un software, infatti, il mercato e le esigenze possono cambiare, anche radicalmente. Un metodo che organizza tutto prima e poi segue sempre lo stesso progetto non è in grado di star dietro ai cambiamenti e agli imprevisti. Perlomeno, non è in grado di farlo mantenendo la velocità che il mercato di oggi richiede.
Lo sviluppo di un software (ma questo discorso è applicabile a qualsiasi prodotto) risente del metodo utilizzato per svilupparlo.
Ecco che subentra il modello Agile.
Agile: un nuovo approccio allo sviluppo di software e prodotti
Non siamo ancora arrivati a spiegarvi perché Agile non è una metodologia. Ci arriveremo.
Iniziamo a raccontarvi come nasce Agile, in contrapposizione con il modello Waterfall.
La nascita di Agile
Nell’aprile 2001, un gruppo di progettisti software ed esperti informatici si riunisce per discutere della situazione del momento.
Molte aziende vogliono aggredire il mercato del web, in cui vedono ottime possibilità di crescita. Richiedono sistemi e software, sono pronte a investire. Ma il mercato evolve veloce, e sviluppando a cascata, è impossibile stargli al passo.
Questo gruppo si interroga su come poter oltrepassare questi limiti e rispondere al meglio alle necessità delle imprese. Tutti sono concordi su una cosa: è necessario cambiare mentalità.
Ecco che si iniziano a elaborare i primi principi di un nuovo mindset, che si tradurranno in seguito nel Manifesto Agile→ e nei valori che governano questo nuovo approccio:
- 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.
Il Manifesto Agile non sminuisce processi, strumenti, documentazione, contratti e piani. Afferma che, fermo restando l’importanza delle voci a destra, quelle a sinistra sono più rilevanti e prioritarie.
Agile come filosofia
Ma, oltre a questo, Agile non dice nulla. Non indica procedimenti, no elenca fasi, non definisce iter. In pratica, non vi dice “come si fa”.
Per questo Agile non è un metodo. Agile è, appunto, un modo di pensare e approcciarsi ai progetti in maniera flessibile e proattiva.
Per questo Agile è la filosofia che sta alla base di moltissime metodologie e framework, come ad esempio Scrum→.
Ma Agile si può applicare ovunque?
In linea teorica, sì. Proprio a fronte del fatto che siamo dinnanzi a un modello di pensiero e non a un metodo rigido.
D’altro canto, però, non significa che le metodologie che ne derivano siano adatte a tutti. Anzi, possiamo dire che per una certa tipologia di progetti è molto più adatto il Waterfall.
Ma di una cosa siamo sicuri: per qualsiasi progetto digitale, Agile è la scelta migliore.
Applicazioni e framework della mentalità Agile
Un esempio di approccio Agile: costruire una barca
Fra i 12 principi del Manifesto Agile→, ve n’è uno che serve a comprendere meglio perché Agile è particolarmente indicato per lo sviluppo di progetti digitali (e perché, invece, il modello Waterfall non lo è):
Consegnamo frequentemente software funzionante,
con cadenza variabile da un paio di settimane a un paio di mesi,
preferendo i periodi brevi.
Ora, immaginate di avere bisogno di una barca e che chiamate un costruttore per realizzarvela.
Secondo Waterfall, il costruttore vi mostrerà il progetto completo, costruirà lo scafo, aggiungerà la vela, poi, perché no, il motore (non si sa mai), poi vi metterà le boe, l’ancora ecc… Tra circa un anno avrete la vostra barca completa: prendere o lasciare. D’altronde avete approvato il progetto.
Agile, invece, partirebbe da un principio leggermente diverso. Ossia, che in realtà non vi serve una barca: vi serve qualcosa che vi permetta di attraversare l’acqua e raggiungere l’altra sponda del fiume.
Per questo il “costruttore agile” vi consegnerà dopo pochissimo tempo una zattera: non sarà bellissima, ma la potrete utilizzare sin da subito per raggiungere il vostro obiettivo (arrivare all’altra sponda del fiume).
Mettiamo caso che, mentre remate sulla vostra zattera, vi rendete conto che avete bisogno di più velocità rispetto a quanto permesso dai remi ma, al contempo, realizzate che non c’è vento. Bene, il costruttore vi aggiungerà un motore: non solo avrete aggiunto una funzione utile, ma avrete risparmiato su cose inutili (se non c’è vento, perché mettere una vela?).
E via dicendo. Grazie ad Agile, i prototipi consegnati dopo poche settimane sono già funzionanti e, nel tempo, perfezionabili anche sulla base di esigenze che in fase progettuale non sono state previste, per svariati motivi.
La progettazione Agile
Le fasi Agile
Dal punto di vista processuale, Agile è strutturato in molti cicli che si susseguono uno dopo l’altro. Il lavoro completo è diviso in tanti piccoli obiettivi e ogni ciclo ne realizza uno. La peculiarità è che in ogni ciclo ci sono tutte le fasi (che nella cascata erano realizzate una sola volta):
- analisi
- progettazione
- realizzazione
- test
- correzioni.
Agile realizza il software assicurandosi che ogni pezzo di obiettivo sia ben completato. Finito un ciclo che ha raggiunto un mini-obiettivo, si passa ai successivi. Questa metodologia si aggiorna continuamente, e soprattutto, può verificare molte volte eventuali criticità e mancanze (perché la fase di test è presente in ogni ciclo!).
L’approccio Agile alla prevedibilità
Nell’ottica delle rapide evoluzioni attuali, Agile ha il vantaggio di non trascinarsi mai i problemi non calcolati all’inizio del progetto. Se il contesto è cambiato, li risolve poco dopo che si sono presentati, potendosi così fregiare di un software finale già aggiornato.
ll team Agile
Agile si traduce in team di sviluppo piccoli ma già dotati di tutte le professionalità realmente necessarie, cioè auto-organizzati.
Le dinamiche sono di interazione e c’è una vera e propria mentalità di gruppo: non esiste un approvatore “supremo”, bensì figure in grado di rimuovere gli ostacoli del progetto (facilitatori), così come altre che sanno interfacciarsi con il committente.
Un framework Agile: Scrum
Un ottimo esempio di pensiero Agile è il framework Scrum: il nome deriva dalla mischia del rugby, poiché i componenti del team si trascinano continuamente a vicenda verso la meta finale. Una processualità estremamente empirica, iterativa e ripetuta, dove ogni piccolo obiettivo viene riprovato e ritestato fino a raggiungerne un livello ottimale.
I software sviluppati secondo Scrum, come i progetti my.custom di Ardesia→, sono estremamente personalizzabili e si adattano in modo naturale ai cambiamenti.
Non va dimenticato, infine, che tutta la filosofia Agile rappresenta una modalità graduale e poco aggressiva di implementare la Digital Transformation→ nell’ambiente aziendale. È quindi applicabile anche in altre divisioni, come il marketing, l’operation, il sales. Può, cioè, diventare un approccio vincente per digitalizzare in modo fluido e senza stress.
Cerchi un partner per sviluppare il tuo software custom? Scopri cosa possiamo fare per te!
