Waterfall vs Agile nello sviluppo software su misura

Nella cosiddetta “letteratura della materia” (parliamo di computer science, per la precisione di ingegneria del software) vengono descritte diverse modalità per procedere allo sviluppo di un sistema; per semplificare diciamo che sono due: la prima è in uso dagli anni ‘70, la seconda dal 2000 circa. La prima è detta waterfall model (modello a cascata), la seconda agile software development (metodologia agile).

La modalità waterfall adotta la struttura della progettazione industriale e prevede delle fasi lunghe e monolitiche: analisi dei requisiti, progettazione, sviluppo, collaudo, manutenzione.

Questa modalità prevede di passare alla fase successiva solo dopo aver “blindato” la fase precedente. Ciò ad esempio significa che è impossibile procedere fino a che non si ha contezza precisa completa di tutte le caratteristiche. I tempi di ogni fase sono spesso molto lunghi, i costi sono mediamente molto alti. Il risultato finale inoltre potrebbe non soddisfare appieno il committente che, di fatto, non “vede nulla” fino alla fase di collaudo. Il collaudo viene fatto usando griglie di prossimità/verifica ai requisiti espressi nel documento iniziale dei requisiti (che era stato “congelato” dopo averlo stilato).

La modalità agile prevede invece il coinvolgimento del committente durante tutto lo svolgimento del processo di sviluppo. Lo sviluppo è caratterizzato da microrilasci (per “rilascio” si intende quando il software viene dato in uso all’utente) i quali permettono al cliente di toccare con mano singole funzionalità e di procedere, fianco a fianco al team tecnico, indicando i successivi raffinamenti e modellando i componenti che assieme portano alla conclusione del progetto stesso. A differenza del modello a cascata, dove il rilascio si ha solo alla fine dell’intero processo, qui il periodo di sviluppo prevede rilasci settimanali con piccoli incrementi i quali assomigliano ad un mini modello a cascata comprendendo ogni volta anche una fase di test.

Il nostro team di sviluppo adotta la modalità agile da più di 15 anni e, in base alla nostra esperienza, possiamo dire che:

la modalità agile permette di velocizzare l’intero processo: si può iniziare a sviluppare il software anche in assenza di un documento SRS (Software Requirements Specification) completo, che il cliente stesso viceversa non sarebbe in grado di redigere autonomamente a meno di avere al proprio interno grandi skill tecnico-analitiche
la modalità agile permette di adeguare i requisiti in itinere: spesso il committente riesce a comprendere effettivamente le proprie necessità solamente quando vede e utilizza nella pratica quanto realizzato: i processi immaginati a tavolino, nel confronto con la realtà che si presenta e con le proprie persone che ci lavorano quotidianamente
la modalità agile permette di ottenere risultati migliori: la stretta e regolare interazione fra il team del committente e il team di sviluppo, porta ad aumentare la conoscenza della realtà e dei processi da parte degli sviluppatori, che potranno proattivamente accompagnare il cliente nel processo di trasformazione digitale: un processo che deve necessariamente coinvolgere tutte le persone in azienda

Però poi l’azienda committente si trova ad operare in un mondo completamente diverso da quello in cui era prima:

non deve dipendere da un fornitore impersonale che ragiona secondo logiche di numeri (prima le modifiche venivano fatte solo se il fornitore riteneva commercialmente valida l’operazione, oppure avevano dei costi fuori scala)
ha un rapporto di partnership con il fornitore: il team interno ha lavorato per mesi fianco a fianco con il team di sviluppo, per cui qualunque problematica si presentasse viene gestita nel miglior modo possibile; inoltre i due gruppi possono costituire un team unico di ricerca e sviluppo in cui progettare proattivamente e realizzare strumenti unici, ancora più performanti e concorrenziali, sfruttando tutti i benefici della digital transformation
può decidere di modificare o adeguare il proprio business model (pensiamo ad esempio a quanto è successo durante la pandemia) essendo sicuro di reagire in maniera molto più rapida di prima: le modifiche richieste vengono fatte in tempi veloci e certi ed a un costo concorrenziale