In Inizio, i rischi principali sono spesso quelli tecnici o di business. Un iniziale rischio di business dominante in
genere assicura i fondi per il progetto. Quindi una prova del prototipo di concetti spesso è il risultato della fase di
inizio. La prova del prototipo di concetti dimostra la funzionalità chiave o la tecnologia essenziale.
La prima iterazione di un nuovo prodotto è la più difficile. I nuovi aspetti che una prima iterazione deve ottenere
sono molti, oltre alla produzione software: ad esempio, allestire il processo, creare il team, capire il nuovo dominio,
familiarizzare con i nuovi tool e così via. E' necessario essere prudenti nelle aspettative relative a quanta
architettura è possibile creare o il grado di funzionalità utilizzabile che è possibile ottenere. Se si punta troppo in
alto, si rischia il ritardo nel completamento della prima iterazione, riducendo il numero totale di iterazioni, e
quindi diminuendo il vantaggio di un approccio iterativo. Le prime iterazioni devono incentrarsi sull'ottenimento di
un'architettura adatta. È necessario quindi coinvolgere gli architetti di software nel processo di pianificazione delle
prime iterazioni.
In Elaborazione, le iterazioni focalizzano l'attenzione sulla definizione di un'architettura stabile, sulla
progettazione e l'implementazione del comportamento essenziale del sistema e sull'esplorazione delle problematiche
strutturali tecniche mediante una serie di prototipi di architetture. Gli scenari "strutturalmente significativi" sono
dei flussi secondari che sperimentano l'architettura del sistema nella definizione dei modi.
Verso la fine dell'Elaborazione e durante la Costruzione e transizione, le richieste di modifica (note anche come SCO,
o Software Change Order) iniziano a condurre il processo di iterazione. Gli SCO risultano da:
-
richieste di miglioramento
-
richieste di modifica il cui ambito va oltre il pacchetto individuale o la classe
-
modifiche all'ambito dell'iterazione e agli obiettivi
-
modifiche nei requisiti proponendo il cambiamento della linea di base dei requisiti oppure inserendo nella linea di
base una modifica accettata.
Gli SCO sono bilanciati rispetto al piano del progetto esistente, ai piani di iterazione e all'elenco di rischi
esistente. Gli SCO possono provocare una rivalutazione delle priorità dei requisiti oppure possono guidare una
riassegnazione di priorità del rischio. Gli SCO devono essere gestiti con attenzione, per evitare di non perdere il
controllo del progetto.
Durante la Costruzione e la Transizione, l'attenzione è rivolta al miglioramento dell'architettura e
all'implementazione dei restanti requisiti.
Diversamente dal modello a cascata, dove l'intero sistema viene considerato nell'insieme, si considera solo una parte
della funzionalità del sistema in ogni iterazione. Durante ciascuna iterazione, un sottoinsieme del sistema totale
viene analizzato, progettato ed implementato. La scelta di quale sottoinsieme deve trattarsi e quanto a fondo andare è
critica per ridurre i rischi nelle iterazioni successive. Esistono due strategie principali: Ampia/Superficiale e
Stretta/Profonda.
Nella strategia Ampia/Superficiale, viene analizzato l'intero dominio del problema ma vengono considerati solo i
dettagli di superficie. Vengono definiti tutti i casi d'uso e la maggior parte vengono riempiti di dettagli, per
ottenere una comprensione chiara del problema presente. Anche l'architettura viene definita ampiamente, e vengono
definiti i meccanismi chiave ed i servizi offerti dai componenti strutturali; vengono definite le interfacce dei
sottosistemi ma i loro dettagli interni sono presenti solo quando deve essere gestito un rischio o un'incertezza
significativi. Viene implementato molto poco fino alla Costruzione, dove avviene la gran parte dell'iterazione.
La strategia Ampia/Superficiale è appropriata quando:
-
Il team non è esperto, o relativamente al dominio del problema o all'area della tecnologia (inclusa la metodologia
o il processo).
-
Un'architettura solida è un requisito chiave per la capacità futura e l'architettura è senza precedenti.
La strategia, tuttavia, ha dei potenziali trabocchetti:
-
Il team potrebbe rimanere intrappolato nella paralisi da analisi (la sensazione illogica che a meno che la
progettazione non sia perfetta, non è possibile implementare nulla).
-
I primi risultati sono spesso necessari per acquisire fiducia e credibilità; più a lungo il team del progetto
avanza senza produrre qualcosa di eseguibile, meno fiducia provano riguardo la loro abilità di produrre qualcosa.
-
Non sono esposti sufficienti dettagli tecnici e sfide dell'architettura per ottenere il senso dei reali rischi
tecnici
Nella strategia Stretta/Profonda, viene analizzata a fondo una fetta del dominio del problema. I casi d'uso
correlati a questa stretta fetta vengono definiti e espressi con dovizia di dettagli, per ottenere una chiara
comprensione del problema presente. L'architettura richiesta per supportare il comportamento desiderato è definita ed
il sistema viene progettato ed implementato. Le iterazioni successive concentrano l'attenzione sull'analisi, la
progettazione e l'implementazione di ulteriori fette verticali.
La strategia Stretta/Profonda è appropriata quando:
-
I primi risultati devono essere dimostrati per superare un rischio dominante, raccogliere supporto o provare la
viabilità.
-
I requisiti evolvono continuamente, rendendo difficile definire completamente tutti i requisiti prima di iniziare
la progettazione dettagliata ed il lavoro di implementazione.
-
La data di scadenza è obbligatoria, quindi iniziare presto lo sviluppo è un punto chiave per una produzione
con esito positivo.
-
E' possibile un alto grado di riutilizzo, consentendo un grado maggiore di produzione incrementale.
La strategia non è priva svantaggi:
-
C'è una tendenza con questa strategia a sviluppare in ogni iterazione del software integrato verticalmente ma
incompatibile orizzontalmente. Questo a volte viene denominato come la sindrome del tubo della stufa e rende
un sistema difficile da integrare.
-
Non è consono sviluppare dei sistemi in un dominio di problemi completamente nuovo o basato si un'architettura
senza precedenti, poiché una gran parte della funzionalità di un sistema deve essere provata, per poter ottenere
un'architettura equilibrata.
In genere, le prime iterazioni saranno più di tipo Ampia/Superficiale, mentre quelle successive (una volta sviluppata
un'architettura stabile) tendono a seguire la strategia Stretta/Profonda.
La prima iterazione in genere è la più difficoltosa, poiché richiede che siano pronti l'intero ambiente di sviluppo e
la maggior parte del team del progetto. Le problematiche di integrazione dei tool e della creazione del team sono
ulteriori elementi che determinano la complessità della prima iterazione. Concentrare l'attenzione sulle problematiche
strutturali mantiene la concentrazione ed impedisce al team di rimanere imbrigliati nei dettagli troppo presto.
-
Strategia Stretta/Profonda utilizzata in Inizio
Dove l'utilizzo di una nuova tecnologia è essenziale alla viabilità fondamentale del progetto. Molti
progetti e-business richiedono l'esplorazione di nuove tecnologie in maniera di gran lunga più profonda
rispetto a quella effettuata tradizionalmente. Il prototipo prova-del-concetto viene ancora considerato
"spazzatura", ed esplora semplicemente la viabilità del concetto del progetto.
-
Strategia Ampia/Superficiale in Inizio
Questa stratega viene perseguita per ottenere una comprensione dell'ambito del sistema e per provare la portata
della funzionalità del sistema per garantire che l'architettura sia in grado di produrre le capacità
desiderate.
-
Strategia Ampia/Superficiale utilizzata in Elaborazione
Questo approccio può essere utile per lo sviluppo di un'architettura solida, con il punto focale
Stretta/Profonda selettivo per risolvere degli specifici rischi tecnici. Nella Costruzione, con un'architettura
solida stabilita, il punto focale può tornare su Stretta/Profonda dove la funzionalità viene sviluppata e
distribuita in una serie di incrementi integrati.
-
Strategia Stretta/Profonda utilizzata in Costruzione
Le iterazioni Costruzione sono sempre Strette/Profonde, con i team che lavorano in parallelo per sviluppare e
distribuire la funzionalità richiesta.
I team nuovi in genere all'inizio sono ottimisti su cosa possono ottenere. Per controbilanciare questa sensazione e per
prevenire eventuali problemi morali che si verificano quando i risultati effettivi ricadono al di sotto delle
aspettative ottimistiche, è necessario essere modesti sulla quantità di funzionalità che può essere ottenuta nella
prima iterazione. Tentare di formarsi un'esperienza quando si crea un senso di adempimento e di soddisfazione nel
progetto.
Se l'ambiente di sviluppo e/o i metodi sono nuovi per il team, ridurre al minimo la funzionalità della prima
iterazione. Concentrare l'attenzione sull'integrazione e l'ottimizzazione dell'ambiente, e sul divenire esperto nei
tool, quindi aumentare il contenuto della funzionalità nelle successive iterazioni.
Fino ad un certo punto la rilavorazione è un fattore positivo. Uno dei maggiori vantaggi di uno sviluppo iterativo è
precisamente di consentire gli errori e la sperimentazione, ma abbastanza presto da poter intraprendere delle azioni
correttive. Tuttavia i tecnici in particolare tendono ad ottenere il massimo e rieseguono il lavoro alla perfezione fra
una iterazione e quella successiva.
Al termine di ogni iterazione, durante la valutazione dell'iterazione il team deve decidere quale parte del rilascio
corrente deve essere rilavorata. Prevedere la rilavorazione nelle diverse fasi con le seguenti percentuali, relative al
sistema totale:
-
Inizio, 40%-100% - questa è la fase in cui è possibile sviluppare prototipi esplorativi 'spazzatura'
-
Elaborazione, 25%-60% nelle prime iterazioni; meno del 25% in quelle successive o per un ciclo di evoluzione.
-
Costruzione, dopo la linea base dell'architettura, 10% o meno per iterazione e 25% in totale.
-
Transizione, meno del 5%.
La rilavorazione è inevitabile. Quando nessuno vede la necessità di una rilavorazione, devono nascere dei sospetti. Ciò
potrebbe essere dovuto a:
-
Una pianificazione con eccessiva pressione.
-
Mancanza di un vero test o di una valutazione.
-
Mancanza di motivazione o di concentrazione.
-
Percezione negativa della rilavorazione come evento non positivo, perdita di risorse o un'ammissione di
incompetenza o fallimento.
Troppa rilavorazione è preoccupante. Ciò potrebbe essere dovuto al perfezionismo o ad un livello non accettabile di
modifiche ai requisiti. Deve essere creato uno scenario di business per valutare la necessità di alcune rilavorazioni.
Nella categoria 'rilavorazione' non viene incluso il lavoro eliminato dall'ambito durante l'iterazione
precedente (a causa dell'approccio soggetto a timeboxing nella gestione delle iterazioni). Il responsabile di progetto
deve includere il lavoro tolto dall'ambito nel pool di funzionalità da cui definire il contenuto dell'iterazione
successiva. Ovviamente questo tipo di lavoro avrà in genere una priorità elevata. Il responsabile del progetto deve
inoltre rilevare e considerare attentamente le ragioni del fallimento dell'iterazione precedente nell'ottenere i suoi
obiettivi pianificati. Ad esempio, anche se non è consigliabile l'aggiunta arbitraria di personale in un disperato
tentativo di rispettare i tempi, non è auspicabile nemmeno mandare avanti un progetto costantemente con personale
sottodimensionato (continuando a fare piani ambiziosi ad ogni iterazione). In genere porta ad un abbassamento del
morale del team e ad un cliente arrabbiato. Deve essere trovato il giusto equilibrio e dei modelli di stima, come
COCOMO II (consultare [BOE00]) possono
essere di aiuto. Con ogni iterazione, un progetto crea una cronologia di conseguimenti - di produttività e qualità. Un
forte indicatore per il responsabile di progetto per la pianificazione dell'iterazione successiva è cosa è stato
conseguito in quella precedente.
Quando il piano di iterazione inizialmente è completo, i leader del team, forse insieme al responsabile di progetto,
possono perfezionarlo in un piano di lavoro a livello di compiti. Le maschere di progetti Microsoft® incluse (a livello
di compiti) mostrano come potrebbe apparire. Questi piani di lavoro, però, sono derivati dal piano di iterazione, non
si tratta di prodotti di lavoro indipendenti prodotti separatamente. E' importante, se il responsabile di progetto deve
detenere il controllo, che i piani di lavoro possano essere riportati allo stadio iniziale per attestare il piano di
iterazione del responsabile di progetto.
|