Qual è la Differenza tra Sviluppo Iterativo e Incrementale?
Nelle mie lezioni di formazione, noto spesso che gli studenti confondono lo sviluppo iterativo con quello incrementale (IID). L'obiettivo di questo articolo è fornire una comprensione della relazione tra sviluppo incrementale e sviluppo iterativo.
Inizierò con un confronto tra un approccio a cascata e uno agile, utilizzando l'esempio della realizzazione di un'app di pagamento. È incluso anche un mini webinar corrispondente su questi approcci. Nella seconda parte di questo articolo, posizionerò la metodologia a cascata e quella agile in una matrice che mostra l'intersezione tra sviluppo incrementale e iterativo, spiegando tutti e quattro i quadranti della matrice.
Agile vs Waterfall: Lo sviluppo di un'app di pagamento
L'approccio Waterfall
Se questa app viene sviluppata secondo un modello tradizionale a cascata, i seguenti passaggi possono essere osservati nella figura 1.
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
Figura 1: Questo diagramma mostra un tipico ciclo di vita a cascata, tramite l'esempio della consegna di un'app.
Avvio del progetto
Tutto parte con uno sponsor del progetto dal dipartimento marketing, che è riuscito a ottenere i fondi necessari per quest'app. Era sua convinzione che l'app avrebbe migliorato la fidelizzazione dei clienti e l'acquisizione di nuovi. Aveva visualizzato tre gruppi funzionali di alto livello.
Una volta approvato il progetto, viene assegnato un project manager e costruito un team di progetto. Dopo molte discussioni e workshop di raccolta dei requisiti, si è concordato di realizzare un'app di pagamento con 250 funzionalità. Tutte queste caratteristiche vengono registrate in un documento di requisiti software molto dettagliato e firmato dallo sponsor del progetto, dal rappresentante del cliente (e da altre figure chiave).
Fase di progettazione del progetto
Nella fase successiva, il team di progetto traduce i requisiti in un progetto per l'app. L’architetto verifica che il disegno rispetti i principi di progettazione. Controlla anche se tutti gli attributi di dati richiesti sono disponibili anche nel sistema backend.
Siamo ora a due mesi dall'inizio e il cliente non ha ancora visto nulla di funzionante, solo qualche report di avanzamento. E questi report probabilmente includono qualche tipo di reportistica ‘anguria’, lasciando il cliente senza alcuna idea se il progetto sia in linea o meno.
Fase di sviluppo del progetto
Ci vogliono sei mesi per sviluppare l'app e quando è pronta, si chiede al rappresentante del cliente di fornire delle persone che possano aiutare con il test di accettazione utente. Durante il test, emerge che alcune funzionalità non funzionano.
Il team di progetto non capisce il motivo. È esattamente ciò che era descritto nel documento dei requisiti. Questo porta a molte discussioni, rifacimenti e ritardi, e i clienti non sono soddisfatti dei risultati. Inoltre, se guardiamo il risultato finale, potremmo notare che molte delle funzionalità sviluppate non vengono usate o sono poco utilizzate dal cliente.
Potrebbe andare anche peggio. Supponiamo che lo sviluppo dell'app sia durato un anno e mezzo e che un’altra banca rilasci un'app di pagamento quando tu sei a metà strada. Cosa faresti in quel momento? Avresti ancora un solido business case per continuare e completare la tua app?
Guardando la figura 1, appare chiaro che con un approccio a cascata, lo scope e i criteri di qualità sottostanti sono fissi con una singola consegna. Tutti i passaggi vengono svolti una sola volta sull’intero progetto e il controllo di gestione è focalizzato su costo e tempo. La consegna di valore al cliente avviene solo dopo il rilascio della versione completa dell’app.
L'approccio Agile
Se sviluppiamo l’app utilizzando un approccio di project management agile, vediamo il seguente schema:
- Il team di sviluppo afferma di poter consegnare le prime due funzionalità prioritarie decise dal product owner nella prima iterazione.
- Il team consegna ogni tre settimane (sprint, iterazione o timebox) un incremento del prodotto.
- Dopo le prime consegne, o incrementi, notiamo un cliente che ha fiducia che il progetto riuscirà. Ha già un'app funzionante, sa che non ci sono ancora tutte le funzionalità, ma quelle presenti funzionano.
Guardando all’ultima release e alle funzionalità offerte, menzionano una caratteristica completamente nuova. Una che nessuno aveva previsto all’inizio del progetto, ma che potrebbe rendere la vita del cliente più produttiva.
Dopo ogni incremento, il feedback del cliente porta a nuove funzionalità (che non erano nella lista originale) o all’adattamento di caratteristiche potenziali. Il prodotto diventa sempre più maturo. Ad ogni incremento, il cliente riceve una nuova versione ed è più soddisfatto.
Figura 2: Il diagramma mostra il ciclo di sviluppo agile, utilizzando lo stesso esempio della consegna di un'app.
Se guardiamo la figura 2, vediamo un flusso costante di consegne entro una durata fissa e utilizzando team agili permanenti (questi sono costi fissi). L'ambito e i criteri di qualità sottostanti sono flessibili (dinamici) con frequenti piccole consegne (questi sono gli incrementi).
Tutti i passaggi finalizzati alla consegna di una funzionalità o di una user story vengono eseguiti ripetutamente (rendendo il processo iterativo) fino al raggiungimento della qualità richiesta. Il controllo manageriale è focalizzato sulla consegna di valore al cliente. La consegna di valore al cliente avviene dopo ogni rilascio di un incremento.
Waterfall Vs Agile: Risultati della Consegna
Se diamo uno sguardo più approfondito ai due prodotti, sia con l'approccio waterfall che con il metodo di sviluppo software agile, vediamo un prodotto con 250 funzionalità e un cliente non così soddisfatto e un prodotto con solo 150 funzionalità e un cliente molto soddisfatto (vedi figura 3).
Figura 3: Questo diagramma confronta le differenze nei tempi, nel numero di funzionalità e nella soddisfazione del cliente tra gli approcci waterfall e agile.
E se guardiamo ancora più in dettaglio il prodotto realizzato con l'approccio agile, vediamo solo un sottoinsieme di 100 funzionalità dall'elenco originale e 50 funzionalità che sono nuove o modificate. Questo è in linea con alcuni importanti principi del Manifesto Agile, tra cui:
- Semplicità, cioè l'arte di massimizzare la quantità di lavoro non svolto: solo 150 funzionalità invece di 250
- Accogliere il cambiamento dei requisiti, anche in fase avanzata di sviluppo: adattarsi ai feedback dei clienti dopo ogni iterazione e incremento
I processi di sviluppo agile sfruttano il cambiamento per ottenere un vantaggio competitivo per il cliente (sono state consegnate 50 funzionalità nuove o modificate). Di conseguenza, il cliente è molto soddisfatto. La massima priorità del team è soddisfare il cliente tramite la consegna precoce e continua di sistemi software di valore.
Mini Webinar: Consegna Waterfall Vs Agile
Ecco un breve webinar di approfondimento sulle differenze tra la consegna di tipo waterfall e quella agile.
Differenze tra sviluppo iterativo e incrementale
Ora che ho illustrato le differenze tra un approccio waterfall e uno agile usando l'esempio della creazione di un'app per i pagamenti, posizionerò waterfall e agile in una matrice che confronta sviluppo iterativo e incrementale.
Come ultimo step, parlerò del minimum viable product (MVP) e del minimum marketable product (MMP) e mostrerò come si inseriscono nei diversi approcci e in una story map. Ho incluso anche un mini webinar corrispondente.
Matrice di sviluppo iterativo e incrementale
Come già detto, ho notato che spesso gli studenti confondono sviluppo iterativo e incrementale. Nella figura 4 si trovano quattro quadranti risultanti da una linea orizzontale che presenta la presenza o meno di incrementi e da una linea verticale incrociata che rappresenta la presenza o meno di iterazioni. Guarda questo video YouTube per una versione molto semplice di questa figura.
Figura 4: Questa matrice mostra diversi approcci di sviluppo e se i membri dei team che li seguono devono iterare e/o lavorare per incrementi.
Quadrante in basso a sinistra
Nell'angolo in basso a sinistra vediamo l'approccio in cui non ci sono iterazioni né incrementi. Questo è l'approccio waterfall. Tutte le attività (progettazione, analisi, sviluppo, test e rilascio) sono eseguite una volta sola per tutto il progetto.
In questo caso, si ha una singola consegna del prodotto finale basata su un ambito fisso. Il valore per il cliente si può ottenere solo dopo la consegna del prodotto finale. Uno degli obiettivi principali in questo approccio è la gestione dei costi.
Quadrante in basso a destra
Nell’angolo in basso a destra, vediamo un approccio incrementale senza iterazioni. Si tratta di una consegna a tappe o incrementale di parti più piccole del prodotto. Tutte le attività per una determinata fase (progettazione, analisi, realizzazione, test e rilascio) vengono eseguite una sola volta.
All'interno di una specifica fase l’ambito è fisso, ma il prodotto totale si basa su un ambito più dinamico o flessibile. Si può ottenere valore per il cliente dopo ogni consegna del prodotto. Uno degli obiettivi principali di questo approccio è la velocità di consegna.
Quadrante in alto a sinistra
Nell’angolo in alto a sinistra, vediamo un approccio a spirale o iterativo senza incrementi. Si tratta di una singola consegna in cui il prodotto finale viene creato attraverso diverse iterazioni. Un buon esempio di questo approccio è il design thinking. Nel grafico si vede una sequenza di attività: contestualizzazione, analisi, generazione di idee, realizzazione e riflessione.
Questa sequenza verrà ripetuta o eseguita in modo iterativo, e ad ogni iterazione ci si avvicina sempre di più al prodotto finale, corretto o richiesto. In molti casi, questo prodotto finale è un prototipo o un modello. In questo approccio a spirale abbiamo un ambito dinamico o flessibile. Il valore per il cliente può essere raggiunto solo dopo la consegna del prodotto finale. Uno degli obiettivi principali in questo approccio è la correttezza della soluzione.
Quadrante in alto a destra
Nell’angolo in alto a destra vediamo l’approccio agile, che utilizza incrementi e un metodo iterativo. Scrum è un buon esempio di questo approccio.
Al termine di ogni incremento, spesso chiamato sprint o timebox, viene consegnato un incremento del prodotto. Questo incremento è il risultato di molte iterazioni per sviluppare piccole ma corrette parti, spesso chiamate user story o elementi del backlog, del prodotto. Il progetto finale iterativo verrà consegnato pezzo dopo pezzo.
In questo approccio agile abbiamo un ambito dinamico o flessibile. Il valore per il cliente può essere ottenuto dopo ogni consegna del prodotto. Uno degli obiettivi principali di questo approccio è fornire valore al cliente tramite consegne frequenti e feedback degli utenti.
MVP o MMP?
Nella figura 4, trovi anche gli acronimi MVP e MMP. MVP sta per minimum viable product (prodotto minimo funzionante) e rappresenta una versione di un nuovo prodotto o servizio che consente a un team di raccogliere la massima quantità di informazioni sui clienti e ottenere la convalida col minimo sforzo. L’MVP per il servizio Dropbox era un semplice video. Questo significa che la P di MVP può essere un prodotto completamente diverso da quello che diventerà il prodotto finale.
Un esempio che illustra MVP e MMP
Spesso uso il seguente esempio di un nuovo prodotto finanziario. Un direttore commerciale entusiasta ha una grande idea in merito a un nuovo prodotto finanziario. Ritiene che possano vendere almeno 100.000 pezzi di questo prodotto.
Insieme ad alcuni esperti finanziari, progettano il prodotto in un paio di mesi. Viene assegnato un team di sviluppo e servono 4 mesi per sviluppare il prodotto. In parallelo vengono creati materiali promozionali e il prodotto viene lanciato con un grande evento.
Purtroppo, poche persone acquistano il prodotto. Se seguiamo l’approccio MVP, potremmo ipotizzare che il 10% degli utenti web sia interessato al prodotto. Svilupperemmo quindi un MVP per testare questa ipotesi.
In questo caso, l’MVP potrebbe essere un semplice pulsante sulla homepage. Se lo si clicca si apre una schermata con un messaggio relativo a questo nuovo prodotto e la possibilità di lasciare il proprio indirizzo email se interessati. Supponiamo che meno dell’1% dei visitatori prema il pulsante: il prodotto non verrebbe sviluppato e l’azienda avrebbe risparmiato molte risorse preziose.
Se guardiamo più da vicino la figura 4, vediamo il potenziale utilizzo degli MVP in tutti i quadranti. Se usi un approccio a cascata, puoi creare un MVP nella prima fase di progettazione del software per verificare se esiste una giustificazione commerciale per il progetto.
Lo stesso può essere fatto nella prima fase del primo incremento quando si segue una consegna a tappe. In alcuni casi, il risultato del design thinking può essere un MVP. Anche all’inizio di un approccio agile, l’MVP può essere molto utile.
Molte persone considerano il primo prodotto consegnato alla fine della consegna a tappe come l’MVP. Può essere così, ma nella maggior parte dei casi non si tratta di un MVP bensì di un MMP. MMP, o minimum marketable product (prodotto minimo commercializzabile), è il prodotto più piccolo che può portare valore al cliente.
Come appare una consegna agile?
Ora che è chiaro che i modelli incrementali e i modelli iterativi non sono la stessa cosa e abbiamo capito cosa sono MVP e MMP, possiamo esplorare in maggiore dettaglio come sono fatte le consegne incrementali e iterative.
Probabilmente hai visto il celebre esempio di Jeff Patton della Monna Lisa, dove il dipinto viene realizzato pezzo dopo pezzo (consegna a tappe). Un altro modo per procedere è partire dal primo incremento in cui si crea solo uno schizzo approssimativo e, con ogni nuova iterazione, si aggiungono dettagli allo schizzo, fino a ottenere il dipinto finale (consegna incrementale e iterativa o agile).
Nella prima situazione è necessario avere già un’idea dettagliata del prodotto finale; nella seconda è sufficiente una traccia ad alto livello, in quanto le modifiche sono molto più facili da apportare. Se guardiamo la figura 5, vediamo una story map per un nuovo prodotto chiamato ABC.
Figura 5: Un esempio di story map per un prodotto esemplificativo.
Il product owner ha immaginato sette funzionalità per questo prodotto. Le prime quattro funzionalità sono indispensabili. Le funzionalità 5 e 6 sono raccomandate e l'ultima funzionalità è facoltativa. Molti chiamerebbero questa una priorizzazione MoSCoW (indispensabili, raccomandate, facoltative e non necessarie).
Ogni funzionalità può essere suddivisa in parti più piccole. Nella figura si vedono funzionalità o user story classificate come indispensabili, raccomandate e facoltative. Una funzionalità può essere indispensabile, ma ciò non significa che tutte le user story sottostanti siano anch’esse indispensabili. Oppure una funzionalità può essere raccomandata, ma se la implementi alcune user story saranno indispensabili e altre potrebbero essere raccomandate o facoltative.
Per implementare questo prodotto ABC, si individuano cinque incrementi o release. La prima è il prodotto minimo commerciabile. Questo MMP consiste nelle prime due user story indispensabili della funzionalità 1 e nelle prime user story indispensabili delle funzionalità 2 e 3.
La release 2 contiene le due successive user story indispensabili delle funzionalità 1, 2 e 3 (sviluppo iterativo). Lo sviluppo del prodotto continua con l’implementazione delle release successive. Ad ogni release il valore per il cliente aumenta.
Dopo la release 5 il product owner interrompe l’implementazione delle user story. Il feedback ricevuto dai clienti gli ha dimostrato che il prodotto ABC è "adatto allo scopo" e applica il principio della semplicità del manifesto Agile, decidendo di interrompere ulteriori sviluppi.
Mini Webinar: Sviluppo Iterativo e Incrementale
Ecco un webinar approfondito sullo sviluppo software iterativo e incrementale.
Considerazioni Finali
Il tuo team di sviluppo software ha ben chiaro cosa significhi sviluppo iterativo e incrementale? Come lo stai applicando alle tue metodologie agile o waterfall?
Faccelo sapere nei commenti, oppure unisciti al nostro programma di membership DPM e discuti con gli altri membri nel nostro forum esclusivo!
