Linea guida: Piano di iterazione
Le iterazioni sono il punto focale dello sviluppo software moderno. Queste linee guida propongono le strategie per la pianificazione delle iterazioni.
Relazioni
Elementi correlati
Descrizione principale

Pattern di iterazione

Iterazioni Inizio

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.

Iterazioni Elaborazione

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.

Iterazioni Costruzione e transizione

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.

Strategie di iterazione

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.

Ampia e superficiale

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

Stretta e profonda

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.

Lezioni imparate dall'esperienza

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.

Strategie ibride

  • 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.  

Considerazioni speciali i team nuovi

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.

Rilavorazione prevista

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.

Livello di pianificazione

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.