Attività di iterazione
In MSF for CMMI Process Improvement è possibile pianificare un progetto come 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 Pianificare 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 Scrivere il nuovo codice per una storia utente.
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.
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 Configurare e gestire il sistema di compilazione.
Riunione rapida
L'intero team conduce una breve revisione giornaliera dello stato delle attività dell'iterazione. I membri del team possono utilizzare l'area attività o proiettare sul muro Dashboard di stato, condividerlo utilizzando Office Live Meeting o eseguire entrambe le attività.
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 Gestire i 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 Burn-down e velocità.
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 Tenere traccia dei bug.
Alla fine di un'iterazione
Verifica
I requisiti vengono considerati completati solo dopo il superamento dei test associati. Per ulteriori informazioni, vedere Verificare i 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 un programma più vasto, ogni team esegue il proprio lavoro in un branch del sistema di controllo della versione. Il branch principale è riservato per l'integrazione del lavoro dei team. Alla fine di un'iterazione, il team potrebbe eseguire un'integrazione con il branch principale. Per ulteriori informazioni, vedere Utilizzare i branch per isolare il rischio nel controllo della versione di Team Foundation.
L'integrazione è costituita da due passaggi:
Un'integrazione in avanti, per unire il codice più recente dal branch principale nel branch 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 branch locale viene unito nel branch principale e vengono eseguiti la compilazione e il gruppo di test completo nel branch principale. Se si verifica qualsiasi errore, le modifiche vengono annullate. L'introduzione di errori nel branch 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 branch 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.