L'iterazione è stata definita come un mini progetto abbastanza completo, che spazia attraverso tutte le maggiori
discipline e che, nella maggior parte dei casi, ha come risultato un sistema eseguibile, ancora incompleto, cioè una
versione. Sebbene il ciclo [modifica, compilazione, verifica, debug] sembri simile ad un'iterazione, non è ciò che si
intende in questo documento. Anche i build giornalieri o settimanali, che integrano in modo incrementale e verificano
sempre più elementi del sistema, potrebbero sembrare un'integrazione, ma questa è solo una parte di un'iterazione, così
come viene intesa in questo documento.
Un'iterazione inizia con la pianificazione e i requisiti, e termina con una versione, interna o esterna.
La velocità con cui è possibile realizzare un'iterazione dipende principalmente dalla dimensione
dell'organizzazione dello sviluppo.
Per esempio:
-
Cinque persone possono stabilire una pianificazione il lunedì mattina, pranzare insieme ogni giorno per discutere e
controllare l'avanzamento, riallocare i compiti, eseguire dei build il giovedì e completare l'iterazione il venerdì
sera.
-
Tutto questo, però, può diventare molto difficile da raggiungere con venti persone. Occorre più tempo per
distribuire il lavoro, sincronizzarlo tra i gruppi secondari, etc... Per un'iterazione possono essere necessarie
dalle tre alle quattro settimane.
-
Con quaranta persone, occorre già una settimana per passare dalla pianificazione alla realizzazione effettiva dei
piani. Esistono livelli di gestione intermedi, la comprensione comune dell'obiettivo richiederà una documentazione
e relazioni più formali. In una tale situazione è più probabile che l'iterazione duri tre mesi.
Entrano in gioco altri fattori: il grado di familiarità dell'organizzazione con l'approccio iterativo, compreso l'avere
un'organizzazione stabile e matura, il livello di automazione utilizzato dal team per la gestione del codice (ad
esempio, il CM distribuito), le informazioni distribuite (ad esempio, la rete interna), la verifica automatica, etc...
Essere anche consapevoli del fatto che esistono delle spese fisse in un'iterazione, nella pianificazione,
sincronizzazione, analisi dei risultati, etc...
Pertanto, se da un lato si è convinti degli enormi vantaggi dell'approccio iterativo e quindi si potrebbe essere
tentati dall'effettuare iterazioni accanitamente, dall'altro i limiti umani dell'organizzazione, che si ha
disposizione, potrebbero far diminuire tanto entusiasmo.
Alcuni dati empirici:
SLOC
|
Numero di sviluppatori
|
Durata di un'iterazione
|
10.000
|
5
|
1 settimana
|
50.000
|
15
|
1 mese
|
500.000
|
45
|
6 mesi
|
1.000.000
|
100
|
1 anno
|
-
Le iterazioni superiori ai 6 mesi probabilmente devono avere dei punti cardine intermedi incorporati per
mantenere i progetto nell'ambito previsto. Ridurre l'ambito dell'iterazione per ridurne la lunghezza ed assicurare
un punto chiaro.
-
Le iterazioni superiori ai 12 mesi creano dei rischi, poiché l'iterazione abbraccia il ciclo di fondi
annuale. Un progetto, che non ha prodotto nulla di tangibile in 12 mesi, rappresenta un rischio di perdita dei
fondi.
-
Le iterazioni inferiori ad 1 mese devono essere definite con cautela. In genere, le iterazioni brevi sono
più adatte alla fase di costruzione, dove il grado di nuove funzionalità da aggiungere e il grado di novità è
basso. In iterazioni brevi è possibile che si effettui un'analisi formale o una progettazione scarsa o nulla, e che
si effettui semplicemente un miglioramento incrementale della funzionalità già chiare.
-
Le iterazioni non devono essere della stessa lunghezza: la loro lunghezza varierà in base agli obiettivi. In
genere, le iterazioni di elaborazione saranno più lunghe delle iterazioni di costruzione. All'interno di una fase,
le iterazioni hanno in genere la stessa lunghezza (ciò rende più semplice la pianificazione).
Quando è chiaro il numero di iterazioni del piano abbozzato, occorre definire il contenuto di ciascuna iterazione. È
anche una buona idea trovare un nome o un titolo per qualificare il prodotto, che verrà realizzato alla fine di ogni
iterazione, per aiutare le persone a mettere meglio a fuoco il processo.
Esempio Iterazioni per uno switch telefonico privato
-
Iterazione 1: telefonate locali.
-
Iterazione 2: aggiunta di telefonate esterne e di gestione degli abbonati telefonici.
-
Iterazione 3: aggiunta di posta vocale e di teleconferenze.
Un progetto molto semplice può avere solo un'iterazione per fase:
-
Un'iterazione nella fase di inizio, che produce forse un prototipo proof-of-concept, oppure interfacce utente
fittizie, oppure nessuna iterazione, nel caso, ad esempio, di un ciclo di evoluzione.
-
Un'iterazione nella fase di elaborazione per produrre un prototipo strutturale.
-
Un'iterazione nella fase di costruzione per effettuare il build del prodotto (fino ad una versione "beta").
-
Un'iterazione nella transizione per terminare il prodotto (versione completa del prodotto).
Per progetti più sostanziosi, nel ciclo di sviluppo iniziale la norma sarebbe:
-
Un'iterazione nella fase di inizio (possibilmente producendo un prototipo).
-
Due iterazioni nella fase di elaborazione; una per un prototipo strutturale e una per la linea di base strutturale.
-
Due iterazioni nella fase di costruzione per esporre un sistema parziale e per maturarlo.
-
Una iterazione nella fase di transizione per passare dalla capacità operativa iniziale al versione del prodotto
completa.
Per progetti ampi, con molte nuove tecnologie sconosciute, etc.., potrebbe essere il caso per:
-
Un'iterazione aggiuntiva nella fase di inizio, per consentire la creazione di più prototipi.
-
Un'iterazione aggiuntiva nella fase di elaborazione, per consentire di esplorare differenti tecnologie.
-
Un'iterazione aggiuntiva nella fase di costruzione a causa della dimensione del prodotto.
-
Un'iterazione aggiuntiva nella fase di transizione, per consentire feedback operativo.
Pertanto, in un ciclo di sviluppo, si hanno:
-
Basso: 3 iterazioni [0,1,1,1]
-
Tipico: 6 [1, 2, 2, 1]
-
Elevato: 9 [1, 3, 3, 2]
-
Molto elevato: 10 [2, 3, 3, 2]
Pertanto, in generale, si pianifichino dalle tre alle dieci iterazioni. Tuttavia si noti che i due valori
estremi connotano circostanze inusuali, pertanto la maggior parte degli sviluppi utilizzeranno dalle sei alle
otto iterazioni.
Sono possibili molte variazioni a seconda dei rischi, della dimensione e della complessità:
-
Se il prodotto è previsto per un dominio totalmente nuovo, occorre aggiungere delle iterazioni nella fase di
inizio per consolidare i concetti, per mostrare vari oggetti fittizi in una sezione incrociata di clienti o utenti,
oppure per rispondere in modo sostanzioso ad una richiesta di proposte.
-
Se occorre sviluppare una nuova architettura oppure esiste una grande quantità di modelli di casi d'uso,
oppure esistono rischi reali, occorre pianificare almeno due o tre iterazioni nella fase di elaborazione.
-
Se un prodotto è ampio e complesso e sviluppato durante un lungo periodo, occorre pianificare tre o più
iterazioni nella fase di costruzione.
-
Occorre pianificare varie iterazioni nella fase di transizione se occorre distribuire il prodotto con una serie di
funzionalità ridotte, poiché è necessario ridurre al minimo i tempi di commercializzazione, oppure se si ritiene
che occorrano molti piccoli adattamenti per l'utente finale dopo un periodo di utilizzo.
La sequenza di analisi predefinita per un progetto con un ciclo di vita waterfall possiede una sola analisi principale
al completamento dei prodotti di lavoro importanti, ad esempio:
-
SRR (System Requirements Review), al completamento della specifica del sistema;
-
SSR (Software Specification Review), al completamento della specifica dei requisiti software;
-
PDR (Preliminary Design Review), al completamento delle sezioni di progettazione strutturale della
descrizione di progettazione software;
-
CDR (Critical Design Review), al completamento delle sezioni di progettazione dettagliata della descrizione
di progettazione software;
Nel RUP (Rational Unified Process), parti di prodotti di lavoro equivalenti vengono analizzate come se fosse complete
in ciascuna iterazione, ma i punti cardine principali (e pertanto le analisi) sono allineati al completamento delle
fasi di inizio, elaborazione, costruzione e transizione. Un responsabile progetto, che desideri adottare RUP potrebbe
trovare un modo di far quadrare questo conflitto apparente, a causa di obblighi contrattuali. Idealmente, il
responsabile progetto deve convincere il cliente che l'approccio, basato su fasi e iterazioni, fornisce una maggiore e
reale visibilità all'interno del progetto e riduce i rischi, per cui non sono necessari SRR, SSR, etc... Tuttavia, ciò
non è sempre possibile e il responsabile progetto deve pianificare queste analisi in punti appropriati. Nel RUP è
possibile individuare i punti dove questi prodotti di lavoro importanti (i loro equivalenti in RUP) sono
sostanzialmente completi, sebbene ciò non si allinei sempre in modo ordinato con le fasi e le iterazioni.
Pertanto qui si presuppone che lo sforzo relativo, che verrà impiegato sui requisiti, la progettazione, etc..., sarà
nel RUP approssimativamente uguale a quello nel ciclo di vita waterfall (ideale), ma lo sforzo verrà distribuito in
modo differente. Il risultato è il seguente:
-
L'SRR (che si occupa principalmente della Visione) può essere pianificato al termine della fase di inizio;
-
L'SSR (che si occupa principalmente della Specifica di requisiti software) può essere pianificato a circa
un terzo della fase di elaborazione;
-
Il PDR (che si occupa principalmente del Documento dell'architettura software) può essere pianificato al
termine della fase di elaborazione;
-
Il CDR (che si occupa principalmente del Modello di progettazione) può essere pianificato a circa un terzo
della fase di costruzione.
Per efficienza, il responsabile progetto, nelle consultazioni con il cliente, deve cercare di combinare queste analisi
con le analisi RUP proposte. Ciò è chiaramente possibile per l'SRR e il PDR, poiché possono essere combinati
rispettivamente con l'Analisi del Punto
cardine Obiettivi del ciclo di vita e con l'Analisi dell'Architettura del ciclo di vita .
Come il processo software viene influenzato dalle caratteristiche del progetto, così accade per l'organizzazione del
progetto. La struttura predefinita presentata qui (consultare la seguente figura) deve essere adattata per riflettere
gli effetti dei fattori quali quelli elencati:
-
Il contesto del business
-
La dimensione dell'impegno lavorativo per lo sviluppo software
-
Il grado di novità
-
Il tipo di applicazione
-
Il processo di sviluppo corrente
-
I fattori organizzativi
-
La complessità tecnica e manageriale
Questi sono i fattori caratteristici quando si analizza il modo in cui un'organizzazione, nel complesso, adotta un
nuovo processo di sviluppo; in questo documento se ne analizzano gli effetti sulla scelta della struttura del progetto.
La figura qui di seguito presenta un'organizzazione predefinita del progetto, che illustra il modo in cui le
responsabilità vengono assegnate alla struttura del team.
Figura che illustra l'organizzazione predefinita del progetto. Si noti che l'orine dei ruoli non dipende dall'anzianità
o dall'autorità.
La figura rappresenta un punto di partenza per considerare il modo in cui i ruoli e le responsabilità a livello di
progetto devono essere mappati ad una struttura di team. Inoltre la figura serve ad enfatizzare che i ruoli (mostrati
nelle caselle gialle) non sono individui, ma "cappelli" che possono indossare gli individui (o un team) nel progetto.
Per questo motivo alcuni ruoli (ad esempio, il responsabile progetto) sono presenti più di una volta. In tal modo si
indica che, in un certo momento, il comportamento del responsabile progetto, come definito in RUP, può essere presente
in più team. Ad esempio, in un progetto di ampie dimensioni, il compito di preparare un report sullo stato, basato su
un WBS (Work Breakdown Structure), potrebbe essere delegato ad un individuo nel team di gestione. Tuttavia,
questa è una responsabilità che RUP assegna al ruolo chiamato responsabile progetto.
In un progetto di piccole dimensioni, è probabile che un individuo, nominato responsabile progetto, eseguirà
tutti i compiti del ruolo chiamato responsabile progetto, nel qual caso il team di gestione si mescola con il
team di gestione software. La selezione della struttura del team verrà influenzata dalla natura e dalla dimensione del
progetto, ma deve essere moderata da alcuni ruoli di ampio senso comune:
-
Piccoli team sono di solito più produttivi; tuttavia, in un progetto di ampie dimensioni, occorre che vi sia un
bilanciamento con le iterazioni incrociate tra team.
-
Forti gerarchie sono da evitare
-
La portata del controllo di qualsiasi responsabile o leader del team deve essere limitata a più sette o meno due
-
la struttura del team dello sviluppo software deve essere
guidata dall'architettura software; una buona architettura, con un'elevata coesione e con una bassa dipendenza tra
sistemi secondari, consentirà ai team di lavorare in parallelo
-
Una verifica, diversa dal test di unità, deve idealmente essere effettuata da un team separato dal team di
sviluppo. Si noti, tuttavia, che ciò non ha senso, da un punto di vista economico, in un progetto di piccole
dimensioni
-
La struttura deve consentire a tutti i team e agli individui di avere autorità e responsabilità chiaramente
definite. Questo è particolarmente importante se la gerarchia supera tre livelli. I responsabili e i leader del
team in questo tipo di strutture devono comprendere cosa gli viene richiesto nel bilanciamento dei compiti tecnici
e manageriali.
-
La struttura deve supportare le capacità, l'esperienza e le motivazioni dello staff; ad esempio, se un singolo team
deve effettuare analisi, progettazione e implementazione senza alcun passaggio di mani intermedio, occorreranno
tutte le competenze intermedie. Gli analisti esperti non sono necessariamente dei buoi implementatori;
-
Le strutture del team non devono essere rigide; gli individui devono migrare tra team durante la durata del
progetto e le responsabilità del team cambieranno appena l'enfasi del progetto passerà da una fase ad un'altra.
Il fondamento logico dell'organizzazione predefinita viene discussa ampiamente in [ROY98]. In
particolare, nell'assegnazione delle responsabilità per la distribuzione al team di valutazione del software viene
riconosciuto che, tra tutti i team di un progetto di sviluppo, il team di valutazione del software ha la maggiore
esposizione al software poiché questo viene sottoposto all'utente.
Durante la vita di un progetto, l'organizzazione evolverà in un supporto alla struttura di partizionamento del lavoro,
catturata nel piano del progetto. Ciò viene illustrato nella figura qui di seguito, che viene tratta da [ROY98].
Questa evoluzione enfatizza una serie differente di compiti in ciascuna fase:
-
Il team di inizio: un'organizzazione focalizzata sulla pianificazione, con sufficiente supporto, proveniente dagli
altri team, per assicurare che i piani rappresentino un consenso a tutte le prospettive;
-
Il team di elaborazione: un'organizzazione basata sulla struttura, in cui le forze portanti del progetto sono
presenti nel team di architettura software e vengono supportate dallo sviluppo software e dai team di valutazione
del software come necessario per acquisire una linea di base strutturale stabile;
-
Il team di costruzione: un'organizzazione bilanciata in cui la maggior parte dei compiti è nello sviluppo software
e nei team di valutazione del software;
-
Il team di transizione: un'organizzazione, focalizzata sul cliente, in cui il feedback degli utenti conduce i
compiti dello sviluppo.
La migrazione tra team durante questa evoluzione assicurerà che vengano conservate conoscenza e capacità. Ad esempio,
una volta completata l'elaborazione, alcuni membri del team dell'architettura potrebbero essere suddivisi nei vari team
di sviluppo, forse per agire come leader del team, oppure per realizzare la 'visione' strutturale. In seguito, verso il
termine della fase di costruzione, l'attenzione passa al team di valutazione e viene spostato lo staff dal team di
sviluppo a quello di valutazione. Inoltre, è importante, a questo punto, che, per evitare una perdita strutturale
durante costruzione, non si consenta il calo d'influenza del team dell'architettura appena viene spostato il 'centro di
gravità' del progetto. Un modo per fare questo è quello di spostare alcuni membri del team dell'architettura al team di
valutazione.
|