Attività di iterazione

In MSF for CMMI Process Improvement v6.0, si prevede un progetto come una serie di iterazioni.Ogni iterazione dura in genere da quattro a sei settimane, durante le quali il team di sviluppo implementa un set specificato di requisiti.

All'inizio di un'iterazione

La pianificazione delle iterazioni viene eseguita all'inizio o prima dell'inizio di ogni iterazione.Sono incluse le attività seguenti:

• Revisione dei requisiti assegnati all'iterazione e definizione più dettagliata di tali requisiti.

• Creazione di elementi di lavoro attività per le attività da eseguire per implementare e testare ogni requisito.Collegare le attività all'elemento di lavoro requisito utilizzando il tipo di collegamento padre.

• Impostazione del campo Stima originale di ogni attività.Dividere le attività le cui stime prevedono tempi più estesi di alcuni giorni.

• Confronto delle stime con il tempo disponibile per l'iterazione.Se il totale della stima prevede tempi troppo lunghi, semplificare alcuni dei requisiti o rinviarli alle iterazioni successive.

Per ulteriori informazioni, vedere Pianificazione di un'iterazione (CMMI).

Durante un'iterazione

Esecuzione delle attività

I membri del team iniziano e completano le attività, registrando questi eventi in elementi di lavoro.Il completamento di un'attività può includere l'archiviazione del codice programma e di altri elementi.Ogni attività non deve durare più di alcuni giorni e quelle più grandi vengono suddivise durante la pianificazione delle iterazioni.Per ulteriori informazioni, vedere Creazione, copia e aggiornamento degli elementi di lavoro e Completing Development Tasks.

Se un membro del team si imbatte in un ostacolo al proprio lavoro che non può essere risolto immediatamente, dovrà registrare un elemento di lavoro problema.Per ulteriori informazioni, vedere Problema (CMMI).

Test

È necessario sviluppare test manuali o automatici e collegare test case ai requisiti del prodotto.Un requisito del prodotto non può essere considerato completato fino a quando l'elemento di lavoro non viene collegato ai test case superati e che ne dimostrano il funzionamento.

Le attività di sviluppo per i test devono essere incluse nelle attività collegate al requisito del prodotto.

Compilazioni in sequenza e notturne

Il sistema di compilazione compila il prodotto dagli aggiornamenti archiviati di recente ed esegue test automatizzati.È possibile impostare i test principali per l'esecuzione continua e impostare invece un gruppo completo di test per l'esecuzione notturna.Questa prassi consente di evitare che più incrementi comportino la presenza di un numero eccessivo di bug.Per ulteriori informazioni, vedere Configurazione e gestione del sistema di compilazione.

Riunione rapida

L'intero team conduce una breve revisione giornaliera dello stato delle attività dell'iterazione.I membri del team possono proiettare il dashboard di stato su un muro, condividerlo utilizzando Office Live Meeting o eseguire entrambe le attività.Per ulteriori informazioni, vedere Dashboard di stato (CMMI).

• Ogni membro del team segnala brevemente i progressi recenti, il lavoro del giorno e qualsiasi fattore di impedimento.

• Il responsabile del progetto o il responsabile del team segnala i progressi relativi alla risoluzione dei problemi.Per ulteriori informazioni, vedere Gestione dei problemi (CMMI).

• Viene esaminato il numero di bug.È necessario assegnare la priorità ai bug rispetto alle nuove attività di sviluppo.Cercare di mantenere basso il numero di bug durante tutto il progetto.Se il numero di bug aumenta, discuterne le cause e il possibile impatto sulle attività di sviluppo.

• Viene esaminata la frequenza di burn-down.

Modifiche dell'ambito

Il grafico del burn-down potrebbe indicare che le attività non verranno completate entro la fine dell'iterazione.In tal caso, il responsabile del progetto o il responsabile del team avvia una discussione su come semplificare i requisiti in modo da ridurre le attività.Per ulteriori informazioni, vedere Rapporto Burndown e velocità (CMMI).

Vengono modificati i requisiti e i test corrispondenti.Nel piano del progetto viene inserito un nuovo requisito per la funzionalità mancante.Durante la revisione del piano del progetto eseguita verso la fine dell'iterazione, è possibile che la funzionalità venga assegnata a un'iterazione successiva o annullata.

Le richieste di modifica e i rischi non vengono considerati durante un'iterazione.

Valutazione

Alcuni membri del team, ma in genere non tutto il team, si riuniscono regolarmente per esaminare i bug.Ogni membro del team deve registrare un bug quando individua un difetto.Lo stato di un bug registrato è inizialmente impostato su Proposto e lo scopo della riunione di valutazione consiste nel decidere se correggerlo, rinviarlo a un'iterazione successiva o rifiutarlo.

Per ulteriori informazioni, vedere Gestione dei bug.

Alla fine di un'iterazione

Verifica

I requisiti vengono considerati completati solo dopo il superamento dei test associati.Per ulteriori informazioni, vedere Verifica dei requisiti.

Analisi retrospettiva

Il miglioramento del processo è un importante obiettivo in CMMI.

Un'analisi retrospettiva dell'iterazione riflette sui successi e gli insuccessi dell'iterazione e considera i miglioramenti da apportare al processo e agli strumenti utilizzati dal team.Nel Web è disponibile un volume significativo di materiale sulle analisi retrospettive.

I membri del team devono evitare qualsiasi responsabilità individuale.Provare a migliorare il processo in modo che gli errori compiuti dai singoli abbiano una minore probabilità di produrre conseguenze.

Quando si introduce una modifica nel processo, verificare che il team concordi sulle decisioni seguenti:

• Come determinare se la modifica ha rappresentato un miglioramento.

• Quando eseguire la valutazione.

• Azioni da adottare di conseguenza.

Integrazione

Se il progetto fa parte di più grande programma, ogni team esegue il lavoro in un ramo del sistema di controllo della versione.Il ramo principale è riservato per l'integrazione del lavoro dei team.Alla fine di un'iterazione, il team potrebbe eseguire un'integrazione con il ramo principale.Per ulteriori informazioni, vedere Isolare il rischio tramite il branch.

L'integrazione è costituita da due passaggi:

• Un'integrazione in avanti, per unire il codice più recente dal ramo principale nel ramo del progetto locale.Al termine dell'unione, vengono eseguiti test automatici e manuali.Questi test creano alcuni difetti.I difetti vengono corretti con priorità alta.

• Un'integrazione inversa.Il codice del ramo locale viene unito nel ramo principale e vengono eseguiti la compilazione e il gruppo di test completo nel ramo principale.Se si verifica qualsiasi errore, le modifiche vengono annullate.L'introduzione di errori nel ramo principale è motivo di disapprovazione.Se non si verificano errori, l'integrazione viene dichiarata completata.

È consigliabile eseguire un'integrazione alla fine di ogni iterazione.In caso di rinvio, l'elenco di bug da correggere dopo l'integrazione in avanti sarà più lungo.Se la correzione dei bug richiede molto tempo, il ramo principale riceverà nuovo materiale e sarà necessario eseguire un'altra integrazione in avanti.

Preparazione dell'iterazione successiva

Alla fine o verso la fine di un'iterazione, vengono eseguite numerose attività di gestione del progetto.Tali attività includono la revisione dei rischi e la revisione del piano rispetto alle richieste di modifica e alle stime di sviluppo modificate.

Per ulteriori informazioni, vedere Attività del progetto.