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
|
-
Abilitare il feedback distribuendo il valore utente incrementale ad ogni
iterazione.
-
Adattare i piani utilizzando un processo iterativo
-
Accogliere e gestire una modifica
-
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.
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.
|