Concetto: Dimostrazione del valore in modo iterativo
Questo principio dimostra il valore dello sviluppo iterativo.
Descrizione principale

Introduzione

Questo principio spiega perché lo sviluppo di software beneficia largamente dall'essere iterativo. Un processo iterativo rende possibile accogliere facilmente una modifica, ottenere un feedback e catalogarlo nel progetto, ridurre i rischi precocemente e adattare il processo dinamicamente.

        
Vantaggi
  • Riduzione precoce dei rischi
  • Maggiore prevedibilità in tutto il progetto
  • Fiducia fra gli stakeholder
Pattern
  1. Abilitare il feedback distribuendo il valore utente incrementale ad ogni iterazione.
  2. Adattare i piani utilizzando un processo iterativo
  3. Accogliere e gestire una modifica
  4. Affrontare precocemente i principali rischi tecnici, di business e programmatici
Anti-pattern
  • Pianificare l'intero ciclo di vita in dettaglio, tenere traccia delle variazioni rispetto al piano (in realtà può contribuire alla non riuscita del progetto).
  • Valutare lo stato nei primi due terzi del progetto basandosi sulle revisioni delle specifiche, piuttosto che valutare lo stato dei risultati dei test e delle dimostrazioni del software funzionante.

Discussione  

Esistono diversi imperativi dietro questo principio. Il primo è che è necessario distribuire un valore incrementale per consentire un feedback precoce e continuo. Ciò si ottiene suddividendo il progetto in un insieme di iterazioni. In ogni iterazione vengono eseguiti dei requisiti, progettazione, implementazione e verifica dell'applicazione, producendo quindi un componente distribuibile che è di un passo più vicino alla soluzione finale. Ciò consente di effettuare una dimostrazione dell'applicazione agli utenti finali e agli altri stakeholder oppure di lasciarli direttamente utilizzare l'applicazione, abilitandoli a fornire un veloce feedback su come sta andando. Si sta procedendo nella giusta direzione? Gli stakeholder sono soddisfatti del risultato attuale? E' necessario modificare le funzioni implementate fino a questo momento?  E infine, quali altre funzioni devono essere implementate per aggiungere valore di business? Se le risposte a queste domande sono soddisfacenti, aumenterà probabilmente la certezza degli stakeholder che il sistema in fase di sviluppo si occuperà di tutte le loro esigenze. E più difficilmente l'approccio verrà caricato di progettazione inutile o verranno aggiunte capacità non necessarie all'utente finale.

Il secondo imperativo è di potenziare le dimostrazioni ed i feedback per adattarli ai piani. Piuttosto che basarsi sulla valutazione delle specifiche, come le specifiche dei requisiti, i modelli di progettazione o i piani, è necessario invece valutare quanto sia valido il codice sviluppato fino a quel momento. Ciò significa che è necessario utilizzare i risultati dei test e delle dimostrazioni, per gli stakeholder, del codice funzionante per determinare come si sta procedendo. Questo fornisce una buona comprensione del punto in cui si è, quanto velocemente il team sta andando avanti e se è necessario effettuare delle correzioni per portare a termine con esito positivo il progetto. E' possibile poi utilizzare queste informazioni per aggiornare il piano globale del progetto e sviluppare i piani dettagliati della successiva iterazione.

Il terzo imperativo è di accogliere e gestire la modifica. Le applicazioni odierne sono troppo complesse perché i requisiti, la progettazione, l'implementazione ed il test si allineino perfettamente la prima volta. Invece, i metodi di sviluppo applicazioni più efficaci accolgono l'inevitabilità della modifica. Mediante un feedback precoce e continuo, si apprende come migliorare l'applicazione e l'approccio iterativo fornisce l'opportunità di implementare quelle modifiche in maniera incrementale. Tutto questo mutamento deve essere gestito avendo a disposizione i processi ed i tool, in modo da poter gestire la modifica in maniera efficace senza ostacolare la creatività.

Il quarto imperativo dietro a questo principio è la necessità di evidenziare i rischi chiave all'inizio del ciclo di vita, come illustrato nel diagramma riportato di seguito. E' necessario occuparsi il prima possibile dei principali rischi tecnici, di business e programmatici, piuttosto che rimandare la risoluzione del rischio alla fine del progetto. Ciò si ottiene valutando continuamente quali rischi si hanno di fronte ed indirizzando i principali restanti rischi alla successiva iterazione. Nei progetti di successo, le prime iterazioni implicano la partecipazione degli stakeholder ad una visione e a dei requisiti ad alto livello, incluso la progettazione strutturale, l'implementazione e la verifica per diminuire i rischi tecnici. E' importante anche conservare le informazioni richieste per forzare le decisioni relative a quali principali risorse riutilizzabili o software COTS (commercial-of-the-shelf) usare.

Diagramma che illustra che un processo iterativo può ottenere una riduzione dei rischi più rapida del processo a cascata

Profili di riduzione dei rischi per lo sviluppo a cascata e iterativo.

Un obiettivo importante nello sviluppo iterativo è di ridurre il rischio precocemente. Ciò si ottiene analizzando, assegnando una priorità ed affrontando i rischi principali in ciascuna iterazione (consultare: Materiale di supporto: Sviluppo iterativo).  Una ulteriore guida utile per organizzare il ciclo di sviluppo relativo alle iterazioni viene fornita in  Concetto: Iterazione e  Concetto: Fase.