Tipi di elemento di lavoro e flusso di lavoro del modello di processo CMMI

I team usano i tipi di elemento di lavoro (WIT) forniti con il modello di processo MSF for CMMI Process Improvement 2013 per pianificare e tenere traccia dello stato di avanzamento dei progetti software. I team definiscono i requisiti per gestire il backlog di lavoro, quindi tramite la bacheca Kanban tengono traccia dello stato di avanzamento aggiornando lo stato dei requisiti.

Per ottenere informazioni su un insieme di requisiti, i proprietari del prodotto possono eseguire il mapping dei requisiti alle funzionalità. Quando i team lavorano in iterazioni, definiscono le attività che vengono collegate automaticamente ai requisiti.

Usando Microsoft Test Manager e Team Web Access (TWA), i tester creano ed eseguono test case e definiscono bug per tenere traccia dei difetti del codice.

Per supportare altri processi CMMI, i team possono tenere traccia di richieste di modifica, rischi, problemi e note acquisiti nelle riunioni di revisione.

Pianificare un progetto definendo i requisiti e stimando l'entità di lavoro richiesto

Creare i requisiti dal pannello di aggiunta rapida nella pagina di backlog di prodotto. In alternativa, è possibile aggiungere in blocco i requisiti tramite Excel o Project.

Successivamente, è possibile aprire ogni requisito per fornire altri dettagli e stimarne le dimensioni.

I requisiti specificano le funzioni e gli elementi di prodotto che i team devono creare. I proprietari del prodotto in genere definiscono i requisiti dell'ordine di priorità nella pagina di backlog di prodotto. Il team stima quindi l'entità del lavoro richiesto per distribuire gli elementi con la priorità più elevata.

Con la definizione del valore del campo Dimensioni per i requisiti, i team possono usare le funzionalità di previsione e i grafici velocità per valutare le iterazioni future o il lavoro richiesto. Acquisire le informazioni essenziali usando le schede e i campi seguenti. Per altre istruzioni, vedere Pianificare un progetto.

Campo/scheda	Utilizzo
Dimensioni (vedere nota 1)	Stima la quantità di lavoro necessaria per completare un requisito usare qualsiasi unità di misura preferita dal team, quali le misure delle magliette, i punti della storia o il tempo. I grafici velocità e gli strumenti di previsione Agile fanno riferimento ai valori in questo campo. Si tratta di un campo obbligatorio per generare i grafici velocità.
Priorità [obbligatorio] (2)	Valutazione soggettiva del requisito in relazione all'azienda. I valori consentiti sono: 1: il prodotto non può essere rilasciato senza l'elemento. 2: (impostazione predefinita) il prodotto non può essere rilasciato senza l'elemento, ma non è necessaria una risoluzione immediata. 3: l'implementazione dell'elemento è facoltativa in base alle risorse, al tempo e al rischio.
Valutazione [obbligatorio] (2)	Indica il tipo di decisione di valutazione che è in sospeso per l'elemento di lavoro. Usare questo campo quando l'elemento di lavoro si trova nello stato Proposto e specificare uno dei seguenti valori: In sospeso (impostazione predefinita), Altre informazioni, Informazioni ricevute e Valutato.
Bloccato (2)	Indica se a un membro del team viene impedito di procedere nell'implementazione di un requisito o di un'attività o nel risolvere un bug, una richiesta di modifica o un rischio. Se è stato aperto un problema per tenere traccia di un problema che causa il blocco, è possibile creare un collegamento al problema. È possibile specificare Sì o No.
Commit eseguito [obbligatorio] (2)	Indica se viene eseguito o meno il commit del requisito nel progetto. È possibile specificare Sì o No (impostazione predefinita).
Ordine di priorità (1)	Usato per tenere traccia della classificazione dei requisiti. La sequenza di elementi nella pagina di backlog di prodotto viene determinata in base al punto in cui sono stati aggiunti gli elementi o a quello in cui sono stati spostati gli elementi nella pagina. Quando si trascinano elementi, un processo in background aggiorna questo campo, che è assegnato a type="Order" nel file ProcessConfiguration.
Tipo (di requisito) [obbligatorio] (2)	Tipo di requisito da implementare. È possibile specificare uno dei valori seguenti: Obiettivo di business Funzionalità (impostazione predefinita) Funzionale Interfaccia Operativo Qualità del servizio Protezione Scenario Sicurezza
Descrizione	Fornisce dettagli sufficienti per stimare la quantità di lavoro richiesta per implementare il requisito. Concentrarsi sui destinatari dei requisiti, su cosa gli utenti vogliono ottenere e sul motivo. Non descrivere la modalità di sviluppo dei requisiti. Fornire dettagli sufficienti in modo che il team possa scrivere attività e test case per implementare l'elemento. Nei campi HTML è possibile aggiungere testo e immagini in formato RTF.
Analisi (Valutazione impatto)	Impatto sul cliente della mancata implementazione di questo requisito. È possibile includere dettagli dal modello Kano per indicare se il requisito è incluso nella categoria Sorpresa, Obbligatorio oppure Ovvio. Queste informazioni vengono acquisite nel campo RTF HTML che corrisponde alla valutazione impatto.
Altro	I campi seguenti, disponibili nella scheda Altro, non sono obbligatori. Integrato in: numero di build del prodotto che incorpora il requisito o la richiesta di modifica o corregge un bug. Test di accettazione utente [obbligatorio] (2): stato del test di accettazione utente. Superato Fail Non pronto (impostazione predefinita) Pronto Ignorato Informazioni ricevute Specificare Non pronto quando il requisito è nello stato Attivo e Pronto quando il requisito è nello stato Risolto. Stima originale(3): quantità di ore o giorni richiesti per completare un'attività. Esperti in materia: nomi dei membri del team che hanno familiarità con l'area del cliente rappresentata da questo requisito. Data di inizio, Data di fine (3): date di destinazione che indicano quando il lavoro inizia o finisce. Questi campi vengono compilati da Microsoft Project quando viene usato per la pianificazione.

Note:

1. Per modificare l'assegnazione di campo, vedere Configurare e personalizzare gli strumenti di pianificazione Agile per il progetto team.

2. Per modificare la selezione dei menu, vedere Personalizzare un elenco di selezione.

3. È possibile specificare il lavoro in ore o in giorni. Nessuna unità di tempo inerente è associata a questo campo.

   Se si usa Microsoft Project per assegnare risorse e tenere traccia di una pianificazione, è possibile aggiornare questi campi usando Project.

Tenere traccia dello stato di avanzamento

I team possono usare la bacheca Kanban per tenere traccia dello stato di avanzamento dei requisiti e la lavagna delle attività sprint per tenere traccia dello stato di avanzamento delle attività. Con il trascinamento degli elementi in una nuova colonna relativa allo stato vengono aggiornati i campi Stato e Motivo del flusso di lavoro.

È possibile personalizzare la bacheca Kanban affinché supporti corsie o colonne aggiuntive. In alternativa, è possibile personalizzare il flusso di lavoro per il requisito e i tipi di elemento di lavoro di attività, che modificheranno le intestazioni delle colonne predefinite.

Di seguito viene indicata una progressione tipica del flusso di lavoro per un requisito.

• Il proprietario del prodotto crea un requisito nello stato Proposto con il motivo predefinito Nuovo requisito.

• Il proprietario del prodotto aggiorna lo stato su Attivo all'inizio del lavoro per implementarlo.

• Il team aggiorna lo stato impostandolo su Risolto quando ha completato lo sviluppo del codice e i test di sistema sono stati superati.

• Infine, il team o il proprietario del prodotto sposta il requisito su Chiuso quando il proprietario del prodotto accetta che sia stato implementato in base ai criteri di accettazione e che abbia superato tutti i test di convalida.

Eseguire il mapping dei requisiti alle funzionalità

Quando si gestisce una famiglia di prodotti o esperienze utente, può essere opportuno visualizzare l'ambito e lo stato di avanzamento del lavoro per l'intera famiglia di prodotti. Questa operazione può essere eseguita definendo le funzionalità ed eseguendo il mapping dei requisiti alle funzionalità.

Dalla pagina di backlog delle funzionalità, è possibile aggiungere rapidamente le funzionalità, nello stesso modo in cui sono stati aggiunti i requisiti.

L'elemento di lavoro della funzionalità contiene campi analoghi forniti per i requisiti e include campi aggiuntivi, come descritto nella tabella seguente.

Nella scheda Requisiti vengono acquisiti i collegamenti ai requisiti mappati.

Campo	Utilizzo
Valore di business	Specificare un numero tramite cui viene acquisito il valore relativo di una funzionalità rispetto ad altre funzionalità. Quanto più alto è il numero, maggiore è il valore di business.
Data di destinazione	Specificare la data entro cui la funzionalità deve essere implementata.

Dalla pagina di backlog con il campo Mapping abilitato, è possibile trascinare i requisiti nella funzionalità che implementano.

Tale mapping crea collegamenti padre-figlio dalla funzionalità ai requisiti, riportati nella scheda Requisiti.

Se si usano i backlog di portfolio è possibile eseguire il drill-down da un backlog all'altro per visualizzare il livello di dettaglio preferito. È anche possibile usare i backlog di portfolio per visualizzare un rollup del lavoro in corso in diversi team quando si configura una gerarchia di team.

Definire le attività necessarie per implementare i requisiti e tenere traccia della capacità e del burn-down del team

Quando il team gestisce il proprio lavoro in una serie di iterazioni, può usare la pagina di backlog sprint per suddividere il lavoro da portare a termine in attività distinte.

Assegnare un nome all'attività e valutare il lavoro che sarà accettato.

Quando i team stimano il lavoro, definiscono attività e stimano le ore o i giorni necessari per completare le attività. I team prevedono il lavoro e definiscono le attività all'inizio di ogni iterazione e ogni membro del team esegue un subset di queste attività. Le attività possono includere sviluppo, test e altri tipi di lavoro. Uno sviluppatore può definire ad esempio alcune attività per l'implementazione di requisiti, mentre un tester può definire attività da scrivere ed eseguire test case. Collegando le attività ai requisiti e ai bug, sviluppatori e tester sono in grado di vedere i progressi effettuati su questi elementi. Per altre istruzioni, vedere la pagina relativa alle attività di iterazione.

Campo	Utilizzo
Tipo di attività (vedere nota 1)	Selezionare il tipo di attività da implementare dai valori consentiti: Azione correttiva Attenuazione Pianificato
Disciplina (1)	Selezionare la disciplina rappresentata da questa attività quando il team valuta la capacità dello sprint in base all'attività. Analisi Sviluppo Test Formazione utenti Esperienza utente Questo campo viene usato per calcolare la capacità per disciplina. Viene assegnato a type="Activity" nel file ProcessConfiguration. (2) Per altre istruzioni, vedere Implementare le attività di sviluppo.
Stima originale (3)	Quantità stimata di lavoro richiesto per completare un'attività. In genere, questo campo non viene modificato dopo l'assegnazione.
Lavoro rimanente (3)	Indicare il numero di ore o di giorni di lavoro rimanenti per il completamento di un'attività. Con l'avanzamento del lavoro, aggiornare il campo. Viene usato per calcolare i grafici di capacità, il grafico burn-down sprint e il report Rapporto Burn-down e velocità. Se si divide un'attività in sottoattività, specificare le ore solo per le sottoattività. È possibile specificare il lavoro in qualsiasi unità di misura scelta dal team.
Lavoro completato (3)	Quantità di lavoro eseguita per l'implementazione di un'attività.

Note:

1. Per modificare la selezione dei menu, vedere Personalizzare un elenco di selezione.

2. Per modificare l'assegnazione di campo, vedere Configurare e personalizzare gli strumenti di pianificazione Agile per il progetto team.

3. È possibile specificare il lavoro in ore o in giorni. Nessuna unità di tempo inerente è associata a questo campo.

   Se si usa Microsoft Project per assegnare risorse e tenere traccia di una pianificazione, è possibile aggiornare questi campi usando Project.

Tenere traccia dello stato di avanzamento del test nelle storie utente e acquisire i difetti del codice

Requisiti test

Da Test Manager o da TWA, è possibile creare i test case che si collegano automaticamente a un requisito o a un bug.

Il test case contiene diversi campi, molti dei quali sono automatizzati e integrati con Test Manager e il processo di compilazione. Per la descrizione di ciascun campo, vedere Riferimento ai campi Integrare test e compilare.

Nella scheda Requisiti testati sono elencati tutti i requisiti e i bug di un test case. Usando il collegamento, il team può tenere traccia dei progressi effettuati nel test di ogni elemento e supporta le informazioni visualizzate nel report Rapporto Panoramica requisiti (CMMI).

Tenere traccia dei difetti del codice

È possibile creare bug da TWA o Visual Studio o durante l'esecuzione di test con Test Manager. Per altre istruzioni, vedere Tenere traccia dei bug.

Campo/scheda	Utilizzo
Causa radice	Selezionare la causa dell'errore dai valori consentiti: Errore di codifica Errore di progettazione Errore di specificazione Errore di comunicazione Sconosciuto Per modificare la selezione dei menu, vedere Personalizzare un elenco di selezione.
Passi da riprodurre	Acquisire informazioni sufficienti per consentire agli altri membri del team di comprendere l'impatto complessivo del problema e l'eventuale correzione del bug. Ciò include le azioni intraprese per trovare o riprodurre il bug e il comportamento previsto. Descrivere i criteri che il team deve usare per verificare se l'errore del codice è stato corretto.
Gravità	Selezionare uno dei valori consentiti che rappresentano una classificazione soggettiva dell'impatto di un bug sul progetto: 1 - Critico 2 - Alto 3 - Medio 4 - Basso Per modificare la selezione dei menu, vedere Personalizzare un elenco di selezione.
Info sistema Rilevato in compilazione Integrato nella compilazione	Quando Test Manager crea bug, popola automaticamente Informazioni sistema e Rilevato in compilazione con le informazioni sull'ambiente software e sulla compilazione in cui si è verificato il bug. Per altre informazioni sulla definizione degli ambienti software, vedere Configurazione di computer di test per l'esecuzione di test o la raccolta di dati. Quando si risolve un bug, usare Integrato nella compilazione per indicare il nome della compilazione che incorpora il codice che corregge il bug. Per accedere a un menu a discesa con tutte le compilazioni che sono state eseguite, è possibile aggiornare le definizioni FIELD per Rilevato in compilazione e Integrato nella compilazione per fare riferimento a un elenco globale. L'elenco globale viene aggiornato automaticamente quando ognuna delle compilazioni viene eseguita. Per altre informazioni, vedere Campi che supportano l'integrazione con il test, la compilazione e il controllo della versione. Per altre informazioni sulla definizione dei nomi di compilazione, vedere Utilizzare i numeri di build per assegnare nomi significativi alle compilazioni completate.

Tenere traccia di richieste di modifica, rischi, problemi e note acquisiti nelle riunioni di revisione

Con i seguenti tipi di elemento di lavoro, i team possono tenere traccia delle informazioni fornite dal processo CMMI.

• Creare una richiesta modifiche tutte le volte che viene proposta una modifica a qualsiasi prodotto di lavoro incluso nel controllo delle modifiche. Per altre linee guida sull'uso, vedere Gestire le modifiche e Riferimento ai campi di richiesta modifiche (CMMI).

  

  Nella scheda Analisi fornire dettagli relativi all'impatto determinato dalla richiesta modifiche sull'architettura, l'esperienza utente, i test, la progettazione e lo sviluppo o le pubblicazioni tecniche.

• Creare un problema per tenere traccia di un evento o di una situazione che blocca o potrebbe bloccare il lavoro sul prodotto. I problemi si differenziano dai rischi perché vengono identificati spontaneamente dal team nel corso delle riunioni giornaliere.

  

  Per altre istruzioni, vedere Gestire i problemi e Riferimento ai campi che tengono traccia di bug, problemi e rischi (CMMI).

• Creare un rischio per tenere traccia di un evento o di una situazione che blocca o potrebbe bloccare il lavoro sul prodotto. I problemi si differenziano dai rischi perché vengono identificati spontaneamente dal team nel corso delle riunioni giornaliere.

  

  Per altre istruzioni, vedere Gestire i rischi e Riferimento ai campi che tengono traccia di bug, problemi e rischi (CMMI).

• Creare una revisione per documentare i risultati di una revisione della progettazione o del codice. I membri del team possono acquisire dettagli sul modo in cui la progettazione o il codice soddisfa gli standard nelle aree relative a correttezza del nome, attinenza del codice, estensibilità, complessità del codice, complessità algoritmica e sicurezza del codice.

  

  Per altre istruzioni, vedere Implementare le attività di sviluppo e Riferimento ai campi della riunione dedicata alla revisione (CMMI).

Definire i campi e le schede di elemento di lavoro comuni

I campi e le schede seguenti vengono visualizzati nella maggior parte dei form di elemento di lavoro. Ogni scheda viene usata per tenere traccia di informazioni specifiche, ad esempio Cronologia, Collegamenti o Allegati. Questi tre campi forniscono una cronologia delle modifiche, la visualizzazione degli elementi di lavoro collegati e la possibilità di visualizzare e associare file, rispettivamente.

L'unico campo obbligatorio è Titolo. Quando viene salvato, all'elemento di lavoro viene assegnato automaticamente un ID univoco.

Campo/scheda	Utilizzo
Titolo (obbligatorio)	Immettere una descrizione con una lunghezza massima di 255 caratteri. È sempre possibile modificare in seguito il titolo.
Assegnato a	Assegnare l'elemento di lavoro al membro del team responsabile dell'esecuzione del lavoro. A seconda del contesto che si usa, nel menu a discesa verranno elencati solo i membri del team o i collaboratori del progetto team.
Stato	Usare innanzitutto il valore predefinito. Con l'avanzamento del lavoro, aggiornarlo in modo tale che rifletta lo stato corrente. Per modificare l'elenco a discesa degli stati, vedere Modificare il flusso di lavoro per un tipo di elemento di lavoro.
Motivo	Usare prima il valore predefinito e aggiornarlo quando si modifica lo stato. Ogni stato è associato a un motivo predefinito. Per modificare l'elenco a discesa dei motivi, vedere Modificare il flusso di lavoro per un tipo di elemento di lavoro.
Area	Scegliere il percorso area associato al prodotto o al team oppure lasciare vuoto il campo fino a quando non viene assegnato un valore durante una riunione di pianificazione. Per modificare l'elenco a discesa delle aree, vedere Aggiungere e modificare percorsi di area e di iterazione.
Iterazione	Scegliere lo sprint o l'iterazione in cui il lavoro deve essere completato oppure lasciare vuoto il campo e assegnare un valore in un secondo momento, durante una riunione di pianificazione. Per modificare l'elenco a discesa delle iterazioni, vedere Aggiungere e modificare percorsi di area e di iterazione.
Tutti i collegamenti	Aggiungere tutti i tipi di collegamenti, quali collegamenti ipertestuali, insiemi di modifiche, file di origine e così via. In questa scheda vengono elencati inoltre tutti i collegamenti definiti per l'elemento di lavoro, anche quelli definiti in altre schede di controllo dei collegamenti.
Allegati	Condividere informazioni più dettagliate aggiungendo file all'elemento di lavoro, ad esempio thread di posta elettronica, documenti, immagini, file di log o altri tipi di file.
Cronologia	Rivedere l'itinerario di controllo acquisito dal sistema e acquisire informazioni aggiuntive. Ogni volta che l'elemento di lavoro viene aggiornato, le informazioni vengono aggiunte alla cronologia. Nella cronologia sono inclusi la data e l'autore della modifica e i campi modificati. Al campo della cronologia è anche possibile aggiungere testo formattato.

Per trovare informazioni su altri campi, vedere Indice dei campi elemento di lavoro.

Iniziare a tenere traccia del lavoro

Prima di iniziare a tenere traccia del lavoro, è necessario avere creato un progetto team. Per crearne uno, vedere qui.

Per iniziare a tenere traccia del lavoro, eseguire una o più delle attività seguenti:

• Per acquisire familiarità con attività elemento di lavoro comuni, vedere Introduzione all'utilizzo di elementi di lavoro.

• Per creare un backlog, usare TWA. Vedere Creare il backlog.

• Per creare una struttura di suddivisione del lavoro, usare Project o Excel.

• Per informazioni sul client da usare, vedere Scegliere il client di Team Foundation per eseguire le attività.

Domande e risposte

D: Quali stati del flusso di lavoro sono supportati da CMMI?

R: I diagrammi mostrano i principali stati di progressione e regressione per Funzionalità, Requisiti, Bug e Attività. Per personalizzare il flusso di lavoro, vedere questa pagina.

Funzionalità

Requisiti

Bug

Attività

D: Come fare per risolvere un bug come duplicato?

R: Impostare lo stato su Rimosso e specificare Duplicato nel motivo.

D: Come fare per collegarsi a un bug esistente da Test Runner?

R: Vedere Aggiornare un bug esistente durante l'uso di Test Runner.