Agile vs Waterfall: metodologie a confronto

Lo sviluppo Agile a confronto con il classico Waterfall. Pro e Contro.

Non c’è alcun dubbio che l’approccio “Agile” sia affascinante e potenzialmente vincente, però sono necessarie alcune condizioni che non sempre è possibile replicare all’interno del gruppo di lavoro, specialmente in quelli composti da persone poco esperte o poco cooperative.

Di seguito, i propositi dell’introduzione delle metodologie agili:

  1. Realizzare prodotti di alta qualità: l’attenzione di un esperto dovrebbe garantire la massima qualità, motivando il gruppo e negoziando scelte adeguate a budget e tempo.
  2. Time to Market: per definizione una soluzione con approccio “Agile” dovrebbe rispettare o bruciare i tempi.
  3. Maggiore produttività: la semplicità dell’approccio richiede decisioni veloci e cicli di revisioni molto stretti per soddisfare le aspettative dell’utente.
  4. Minima manutenzione: la soluzione dovrebbe includere tutte le esigenze dell’utente, in modo da ridurre la manutenzione ai soli cambiamenti di legge.
  5. Allineamento architetturale: l’approccio “Agile” consente di sviluppare soluzioni perfettamente allineate alle tecnologie disponibili, sfruttandone le capacità, a garanzia del ritorno degli investimenti.
  6. Riduzione della complessità: disegnare e sviluppare solo ciò che serve, con la possibilità di potenziare l’applicazione con nuove funzioni.
  7. Aumento delle prestazioni: i team di progetto devono imparare ad interagire con l’utente, migliorando continuamente le prassi, in modo da evitare discussioni inutili e pretese impossibili. Le prestazioni sono strettamente legate ai prodotti di alta qualità.
  8. Aumento della cultura aziendale: focus alla soluzione piuttosto che alle singole attività.

Lo sviluppo “Agile” è fortemente indicato quando esiste un senso di appartenenza e tutti gli individui coinvolti sono motivati a realizzare un prodotto di qualità.

Non è adatto agli ambienti troppo burocratizzati o conflittuali, perché in tali circostanza mancherebbero i presupposti per costruire un gruppo di lavoro che possa sostenere lo sviluppo agile.

Affinché le metodologie agili abbiano successo occorre che ci sia piena consapevolezza da parte di tutti rispetto a quali benefici possono scaturire a fronte di certi sacrifici, quali dover comprendere le necessità altrui, dialogare con un tecnico per il committente, immedesimarsi nel committente per interpretarne le esigenze.

Un’opportunità per diffondere questo concetto è attraverso la formazione, perché coinvolge i singoli individui, offrendo loro l’opportunità di comprendere i benefici di un approccio che aiuta ad esprimere le proprie potenzialità. Attraverso la formazione è possibile trasmettere principi e metodologie, ovvero cambiare la mentalità, e solo a quel punto introdurre gli strumenti utili al conseguimento di tali obiettivi.

Per quanto riguarda lo sviluppo software, Waterfall e Agile costituiscono due ipotesi antitetiche, ma esistono anche soluzioni intermedie molto più aderenti alla realtà dei clienti, dove si deve fare i conti con

  • la ritrosia al cambiamento,
  • l’attaccamento all’illusione del pieno controllo dato dall’approccio Waterfall
  • i timori nel dare potere decisionale al team di sviluppo, spesso costituito da persone esterne all’azienda.

Nella realtà, prima di poter approcciare qualunque metodologia di gestione del team di lavoro, è opportuno che il project manager conosca:

  • I principi di base del project management,
  • Il settore in cui opera, altrimenti difficilmente riuscirà a valutare le ripercussioni delle proprie decisioni,
  • Le basi di problem solving e di analisi del business,
  • I processi di gestione dei livelli di qualità per garantire i risultati del progetto.

 

Approccio tradizionale e agile a confronto

Di seguito alcune peculiarità di entrambi gli approcci:

  • L’approccio Waterfall cerca di acquisire ed analizzare tutti i requisiti del progetto prima di avviare il disegno dell’applicazione.
  • L’approccio Agile, invece, pianifica per fasi successive rinviando le decisioni quanto più possibile.
  • L’approccio a cascata prevede tempi e costi in anticipo, controllando il contenuto per rispettarli.
  • L’approccio adattivo è molto più flessibile, consente di modificare i requisiti per soddisfare tutte le esigenze di business.

I due estremi sono da una parte il controllo esasperato di costi e tempi, dall’altra la soddisfazione del cliente a qualsiasi costo. Tale contrapposizione ha contribuito a creare alcuni stereotipi riguardo le due metodologie di lavoro spesso ingiustificati.

L’approccio tradizionale non valorizza le persone

Un primo luogo comune è che le metodologie tradizionali hanno poca attenzione alla motivazione delle persone, mentre l’approccio Agile valorizza pienamente il singolo individuo.

Tale visione scaturisce forse dal fatto che, essendo stata fatta un’analisi approfondita a monte, lo sviluppatore si trova spesso ad eseguire semplici task. Tuttavia tale visione non è del tutto corretta: da una parte è vero che l’approccio agile tende a valorizzare il ruolo del singolo individuo, coinvolgendolo nelle attività di decisione, ma il fatto che lo sviluppatore nel caso tradizionale si trovi spesso ad eseguire attività a lui assegnate non significa certo che il ruolo dell’individuo è svalutato. Prima di tutto perché l’esecuzione di un attività, secondo specifiche, di per sé valorizza chi l’ha portata a termine, ma soprattutto perché la definizione delle attività, la loro stima e pianificazione, viene supportata dal parere del singolo individuo.

 

L’approccio agile non ha pianificazione/non ha costi di pianificazione

Secondo un altro luogo comune sembra anche che l’approccio Agile non preveda alcun piano, mentre le metodologie tradizionali abbiano troppa pianificazione preventiva. Non è vero.

Innanzi tutto perché l’approccio Agile si basa sicuramente sulla pianificazione, anche se in un modo differente. La differenza sta nel modo in cui la si fa: la pianificazione Agile è “just-in-time” poiché riguarda orizzonti temporali mobili e relativi, mentre quella delle metodologie tradizionali è preventiva e riguarda in maniera assoluta l’intero orizzonte temporale.

Entrambi gli approcci hanno l’obiettivo di gestire i rischi del progetto e rimuovere le incertezze, solo che lo fanno attraverso metodologie diverse. Quali siano le condizioni in cui un approccio è vincente rispetto ad un altro è un altro tema.

 

L’approccio agile fa andare più veloci

No, assolutamente no. Aderire ai principi agili non permette di finire prima, per finire prima occorre più forza lavoro.

L’approccio agile dice di consegnare ad intervalli regolari e brevi il software, ma ovviamente non “tutto subito”. Se ne consegnano solo alcune feature, che vengono completate possibilmente “a velocità costante”, funzionanti e visionabili dall’utente. In questo modo si riesce ad essere pronti rispetto a variazioni di specifiche ed a minimizzare il lavoro da rifare.

 

I potenziali benefici dell’approccio Agile sono:

 

  • Maggiore attenzione ai risultati e alla logica di business – l’utente è molto più coinvolto: difficilmente rimarrà insoddisfatto.
  • Maggiore time to market: l’approccio iterativo accelera lo sviluppo,
  • Maggiore efficienza organizzativa e team motivato: attraverso il coinvolgimento diretto nelle decisioni e tramite la comprensione del disegno complessivo che avvolge il progetto.
  • Maggiore produttività e costi più bassi: cooperazione tra il tecnico esperto e l’utente. La loro compartecipazione evita la formulazione di specifiche errate e la mancata comprensione di tali specifiche.
  • Potenziale qualità più alta: il test è parte integrante dello sviluppo.

 

Difficoltà dell’approccio Agile:

 

  • Non è facile creare un ambiente realmente collaborativo. Dipende dalle persone, dagli stakeholder e delle condizioni specifiche del progetto.
  • È necessario un forte coinvolgimento del management dell’organizzazione (collaborazione dello Sponsor, cambiamento culturale, adeguata formazione dei partecipanti).
  • Il tipo di business può presentare dei vincoli (leggi particolari, controlli specifici).
  • Bisogna ridisegnare l’approccio al project management.

 

Conclusioni

Il movimento “Agile”, nato negli anni 80, riassunto in un “Manifesto” nel 2001, consiste in estrema sintesi in un insieme di principi e pratiche che consentono di sviluppare un progetto software per approssimazioni successive.

Innanzi tutto viene istituito il concetto di “team”, che rappresenta il gruppo di lavoro. L’insieme di persone che ne fanno parte è estremamente eterogeneo e non comprende solo gli sviluppatori, ma include anche il committente e gli utilizzatori, al fine di raggiungere collettivamente l’obiettivo preposto.

In questa ottica il team inizia al lavorare al progetto o a realizzare un prodotto, sulla base di specifiche molto generiche, ottenute senza approfondire l’analisi in dettaglio, ma concentrandosi sulle necessità e sulle richieste avanzate dal committente. In questo modo si riesce ad ottenere un risultato in tempi brevi, mostrando quanto prodotto all’utente fin dal principio, fino a raggiungere la soluzione per via iterativa. Gli sviluppatori si propongono l’obiettivo di rilasciare versioni del programma funzionanti, seppur incomplete, ad intervalli regolari, in modo da poter mostrare al committente le varie evoluzioni.

Insieme sviluppatore e utente sono molto più produttivi di un team tradizionale, perché questo approccio non necessita di un grosso investimento iniziale nell’analisi, e a fronte di un errore nella definizione delle specifiche, il lavoro buttato via è minimo poiché si rischia al massimo un’iterazione (che generalmente è nell’ordine di una o due settimane, rispetto al progetto che va nell’ordine dei sei mesi- un anno).

Se l’obiettivo è controllare costi e schedulazione in un ambiente altamente prevedibile e certo, l’approccio a cascata resta ancora una buona scelta.

Dalla pratica quotidiana si evince che è molto irrealistico credere che si possa avere successo anche in un ambiente reale, ed incerto per definizione, dove è più importante soddisfare le esigenze dell’utente.

La vera sfida è trovare il giusto bilanciamento tra controllo e agilità, nel soddisfare determinate esigenze in un determinato ambiente, ricordandosi di:

 

  • Non forzare l’utilizzo di una metodologia standard in qualsiasi ambiente, ma cercare di personalizzarla e contestualizzarla.
  • Valutare elementi positivi e negativi dell’approccio Agile e dell’approccio non-Agile.
  • Nel caso si decida di cambiare approccio, permettere un adeguato periodo di transizione di un processo da un approccio all’altro.
  • Non concentrare troppi cambiamenti nello stesso periodo, le persone hanno bisogno di tempo per assimilarli.
danielefontani

Actually CTO in Sintra Consulting s.r.l, I'm senior developer and architect specialized on portals, intranets, and others business applications. Particularly interested in Agile developing and open source projects, I worked on some of this as project manager and developer. My experience include: Frameworks \Technlogies: .NET Framework (C# & VB), ASP.NET, Java, php, Spring Client languages: XML, HTML, CSS, JavaScript, Angular.js,Angular. jQuery Platforms: Sharepoint,Liferay, Drupal Databases: MSSQL, ORACLE, MYSQL, Postgres

Lascia un commento