1. Prima dell’iterazione 1, si tiene il primo workshop timeboxed dei requisiti, per esempio
   di due giorni esatti. Sono presenti i responsabili dell’organizzazione e dello sviluppo
   (compreso il chief architect, il capo architetto).
   • La mattina del primo giorno si esegue un’analisi dei requisiti di alto livello, per esempio identificando solo i nomi dei casi d’uso e le caratteristiche, oltre ai requisiti non funzionali più importanti. L’analisi non sarà perfetta.
   • Si chiede al chief architect e ai responsabili dell’organizzazione di scegliere da questo elenco di alto livello il 10% (per esempio il 10% dei 30 nomi dei casi d’uso identificati) che possegga una miscela delle seguenti tre qualità:
     1. significatività dal punto di vista dell’architettura (per implementarlo, richiede di progettare, costruire e testare il nucleo dell’architettura);
     2. elevato valore di business (si tratta di caratteristiche importanti per l’organizzazione);
     3. rischio elevato (per esempio che “sia in grado di gestire 500 transazioni concorrenti”). Procedendo in questo modo potrebbero essere identificati tre casi d’uso: UC2, UC11 e UC14. (UC#: Used Case#)
   • Per il rimanente giorno e mezzo, si esegue un’analisi intensa e dettagliata dei requisiti funzionali e non funzionali per questi tre casi d’uso. Al termine, il 10% dei requisiti è stato analizzato in profondità e il rimanente 90% solo ad alto livello.
2. Prima dell’iterazione 1, si tiene una riunione di pianificazione dell’iterazione in cui si sceglie un sottoinsieme di requisiti da UC2, UC11 e UC14 su cui fare progettazione, implementazione e test entro un tempo specificato (per esempio, un’iterazione timeboxed di tre settimane). Si noti che potrebbe non essere possibile sviluppare interamente i tre casi d’uso scelti, perché questo potrebbe richiedere troppo lavoro. Dopo aver scelto un sottoinsieme specifico di obiettivi, questi vanno suddivisi in un insieme di compiti più dettagliati da svolgere nell’iterazione, anche sulla base delle indicazioni del team di sviluppo.
3. Si esegue l’iterazione 1 in tre settimane (occorre attenersi al timebox scelto).
   • I primi due giorni, gli sviluppatori e gli altri fanno modellazione e progettazione a coppie, abbozzando diagrammi UML su più lavagne (abbozzando eventualmente anche altri tipi di modelli) nella stanza comune del progetto, guidati e istruiti dal chief architect.
   • Poi gli sviluppatori si levano il “cappello da modellatore” e si mettono il “cappello da programmatore”, passando dunque dalla modellazione alla programmazione. Iniziano a programmare, fare test e integrazione in modo continuo nelle settimane rimanenti dell’iterazione, utilizzando i modelli abbozzati come punto di partenza e di ispirazione, sapendo però che i modelli sono parziali e spesso solo approssimativi.
   • Contestualmente viene eseguito un grosso lavoro di test: unitari, di accettazione, di carico, di usabilità e così via.
   • Una settimana prima della fine, si chiede al team se gli obiettivi originari dell’iterazione possono essere raggiunti; in caso contrario, si riduce la portata dell’iterazione, rimettendo gli obiettivi secondari nell’elenco delle cose da fare nelle iterazioni successive.
   • Il martedì dell’ultima settimana il codice viene congelato; tutto il codice deve essere caricato, integrato e testato per creare la baseline dell’iterazione.
   • Il mercoledì mattina viene fatta una dimostrazione del sistema parziale alle parti interessate esterne, per rendere visibili i progressi iniziali. Alle parti interessate viene richiesto un feedback.
4. Si esegue il secondo workshop sui requisiti verso la fine dell’iterazione 1, per esempio
   l’ultimo mercoledì e giovedì. Tutto il materiale dell’ultimo workshop viene rivisto e raffinato. Viene quindi scelto un altro 10% o 15% dei casi d’uso significativi dal punto di vista dell’architettura e di elevato valore di business, lo si analizza in dettaglio per uno o due giorni. Al termine, probabilmente il 25% dei casi d’uso e dei requisiti non funzionali sarà stato scritto in modo dettagliato. Ma non sarà perfetto.
5. Il venerdì si tiene un’altra riunione di pianificazione dell’iterazione, per l’iterazione successiva.
6. Si esegue l’iterazione 2, con gli stessi passi.
7. Si ripete il tutto, per quattro iterazioni e cinque workshop dei requisiti, di modo che alla fine dell’iterazione 4 probabilmente l’80% o 90% dei requisiti sia stato scritto in modo dettagliato; solo il 10% o il 15% del sistema sarà stato implementato.
   • Si noti che questo grande e dettagliato insieme di requisiti è basato su feedback ed evoluzione, ed è pertanto di qualità molto superiore rispetto a delle specifiche a cascata puramente speculative.
8. Si è probabilmente solo al 20% della durata dell’intero progetto. In termini di UP, questa è la
   fine della fase di elaborazione. A questo punto, vengono fatte delle stime più dettagliate dei tempi e dei costi, con riferimento ai requisiti di qualità elevata in possesso. Grazie all’indagine significativa e realistica svolta in termini di programmazione, test e feedback iniziali, le stime di ciò che si può fare e di quanto tempo occorrerà sono molto più affidabili.
9. Da questo punto in poi, è poco probabile che si tengano altri workshop sui requisiti; i requisiti sono stabili, anche se non vanno mai considerati completamente congelati. Si continua con una serie di iterazioni di tre settimane, scegliendo gli obiettivi di lavoro successivi in modo adattivo in ciascuna riunione di pianificazione dell’iterazione tenuta l’ultimo venerdì, chiedendosi di nuovo a ogni iterazione: “Considerando ciò che sappiamo oggi, quali sono le caratteristiche tecniche e di business più critiche che dovremmo affrontare e implementare nelle prossime tre settimane?”.

Ecco uno schema visivo di ciò che è successo nel corso della progettazione del sistema d'esempio visto sopra