Agile è più efficiente di Waterfall?

Uno degli Scrum Master che seguiamo spesso ci chiama regolarmente per problemi con cui si confronta. Ha scherzato dicendo che dovremmo rispondere al telefono con “Agile Hotline, come possiamo aiutarti?”. Abbiamo pensato fosse un'ottima idea e quindi iniziamo una serie di articoli del blog chiamata Agile Hotline. Qui troverai le nostre risposte alle domande che riceviamo da altri su Agile o Scrum. Speriamo che anche tu possa imparare qualcosa.

Di recente mi è stato chiesto un consiglio su una discussione che qualcuno aveva avuto con un collega. Si trattava di capire se Agile e Scrum possano funzionare in ogni scenario di sviluppo software. Il collega sosteneva di no.

Lo scenario

Supponiamo che si debba costruire un prodotto software che permetta agli utenti di effettuare valutazioni mentre leggono un e-book. Dovranno esserci almeno due tipi diversi di queste valutazioni.

Con Agile o Scrum si cercherebbe di consegnare il prima possibile un prodotto funzionante e di valore – quindi l'obiettivo è fornire solo uno dei tipi di valutazione, che però possa già essere utilizzato precocemente dagli utenti. Questa sarebbe la v1.0. Alcuni Sprint dopo si tenta di implementare il secondo tipo di valutazione come v2.0.

Con il modello Waterfall ci si prenderebbe tutto il tempo necessario per fornire entrambe le valutazioni nella prima versione.

Il collega argomentava in questo caso che Waterfall fosse più sensato, perché altrimenti il rischio di dover rifattorizzare l'intero codice per supportare il secondo tipo di valutazione v2.0 sarebbe molto alto. Con Waterfall entrambi i tipi di valutazione verrebbero sviluppati insieme. Anche se ci vorrebbe più tempo per consegnare la prima versione funzionante, ci sarebbero meno rilavorazioni.

Secondo lui, il metodo Waterfall risparmia tempo ed è più efficiente, perché si deve rifattorizzare meno quando si inizia lo sviluppo con i requisiti attuali e futuri contemporaneamente. Con Agile il nostro focus è però sul “qui e ora” e su un solo tipo di valutazione.

Cosa ne pensi? Come gestiresti un gruppo di sviluppatori che pensa di dover rivedere molto in seguito con Agile perché “non potevano pianificare troppo avanti”?

Cosa crediamo noi

Ci sono tre punti principali che bisogna comprendere per rispondere a questa domanda:

• Primo: Agile e Waterfall hanno entrambi il proprio ambito di applicazione. Agile è progettato per sistemi complicati/complessi, ad esempio quando c'è un certo grado di incertezza nei requisiti e/o nella tecnologia. Waterfall è più adatto per progetti semplici, ad esempio quando c'è una buona comprensione dei requisiti e della tecnologia e queste cose non cambiano. Utilizziamo la Stacey Matrix per chiarire quando usare quale approccio. Il fatto è che Waterfall in un ambiente complesso fallisce completamente, mentre Agile in un ambiente semplice comporta più impegno ma funziona comunque. Il nostro esempio preferito è l'organizzazione di una conferenza. Si può usare Agile, anche se potrebbe sembrare uno sforzo non necessario.

• Secondo: Agile NON è più efficiente di Waterfall. È più efficace. Questo significa che potresti aver bisogno di più ore-persona per consegnare qualcosa con Agile, ma il prodotto può molto probabilmente essere portato sul mercato prima (perché dovrebbe esserci un rilascio alla fine di ogni Sprint e non solo alla fine del progetto). Inoltre, il costo totale di proprietà è probabilmente inferiore (perché qualità e design sono migliori e la conoscenza è condivisa, rendendo la manutenzione più semplice).

• Terzo: Agile non riguarda lo sviluppare qualcosa di specifico più velocemente. Riguarda l'arte di massimizzare la quantità di lavoro non fatto. Lo studio Chaos afferma che il 65% di un software non viene mai o raramente utilizzato. Con Agile si cerca di identificare e sviluppare il restante 35%, quello più probabile che venga utilizzato; poi ci si ferma. Quindi, anche se potrebbe volerci un po' più di tempo per sviluppare il primo 35%, ci siamo risparmiati di sviluppare l'altro 65% che nessuno utilizzerà.

Come si applica al nostro esempio? Innanzitutto, non si completerebbe prima l'intera prima valutazione e poi la seconda. Si identificherebbe la parte più preziosa della valutazione. Potrebbe essere un determinato tipo di domanda (ad esempio una domanda a scelta multipla). Si inserirebbe quindi solo una domanda nella valutazione, la si farebbe testare agli utenti e si scoprirebbe se funziona. Si potrebbe persino fornire la prima opzione di valutazione solo con domande a scelta multipla. Poi si aggiungerebbe il tipo di domanda successivo più importante. Oppure si decide che è abbastanza buono e si inizia con un nuovo progetto.
Se la portata delle valutazioni è davvero fissata, se si sa inoltre che funzionerà davvero per gli utenti e non c'è incertezza riguardo alla tecnologia, Waterfall potrebbe essere la scelta migliore per questo progetto. Agile funzionerebbe comunque, solo non necessariamente risparmierebbe tempo. Per esperienza posso dire che la maggior parte delle persone pensa di conoscere e comprendere tutti i requisiti – ma normalmente non è così. Il maggior impegno di Agile si ripaga quindi nella maggior parte dei casi.

Questo testo proviene dal blog di Growing Agile ed è stato tradotto in italiano.