Utilizzare elementi del progetto team, scegliere un modello di processo

Quando si crea un progetto team, è necessario scegliere il modello di processo. Il modello di processo definisce il set dei tipi di elemento di lavoro (WIT), le query e i rapporti che verranno usati per pianificare il progetto e tenerne traccia. Scegliere il modello che offre gli strumenti di cui il team ha bisogno e che riduce il sovraccarico, in modo che il team possa concentrarsi sulla qualità.

Per creare un progetto team, vedere qui.

Per accedere alle versioni più recenti dei modelli di processo di Team Foundation Server (TFS), installare Visual Studio Team Foundation Server 2013 (TFS). Sarà quindi possibile scaricarli usando Gestione modelli di processo.

Le principali distinzioni tra i tre modelli di processo predefiniti sono nei tipi di elementi di lavoro forniti dai modelli per pianificare e tenere traccia del lavoro. Scrum di Visual Studio è il più leggero e MSF per CMMI (Capability Maturity Model Integration) fornisce la maggior parte del supporto per i processi formali e la gestione dei cambiamenti.

Microsoft Visual Studio Scrum 2013 Scegliere Visual Studio Scrum se il team gestisce i bug con gli elementi backlog di prodotto durante la pianificazione dello sprint. Il modello Scrum è progettato per supportare la metodologia Scrum definita dall'organizzazione Scrum. Questo modello di processo tiene traccia dei bug allo stesso livello degli elementi backlog di prodotto e tiene traccia anche delle stime tramite un campo denominato Lavoro richiesto. Il sistema azzera automaticamente il campo Lavoro rimanente quando l'attività dello stato è impostata su Fine.
MSF for Agile Software Development 2013 Scegliere Agile se l'organizzazione valuta i bug separatamente dal backlog di prodotto e risolve gli elementi di lavoro prima di chiuderli. Inoltre, scegliere Agile se il team assegna il tempo per i bug a ogni sprint. Il modello Agile è progettato per supportare lo sviluppo Agile per i team che non vogliono essere limitati dallo Scrum. Supporta la stima di storie utente usando punti della storia. Le attività contengono campi per tenere traccia dei campi Stima originale, Lavoro rimanente e Lavoro completato. Non viene tenuta traccia dei bug in alcuna pagina di backlog. Per altre informazioni sulle metodologie Agile, vedere http://www.agilealliance.org/.
MSF for CMMI Process Improvement 2013 Scegliere CMMI se l'organizzazione valuta i bug separatamente dal backlog di prodotto, risolve gli elementi di lavoro prima di chiuderli e tiene traccia formalmente delle modifiche apportate ai requisiti. Il modello CMMI è progettato per supportare i processi formali di gestione dei cambiamenti. Questo modello supporta la stima dei requisiti tramite l'uso di un campo di dimensione. Le attività contengono campi per tenere traccia dei campi Stima originale, Lavoro rimanente e Lavoro completato. Non viene tenuta traccia dei bug in alcuna pagina di backlog. Per altre informazioni sui processi CMMI, vedere qui.

Differenze principali tra i modelli di processo predefiniti

I modelli predefiniti sono progettati per soddisfare le esigenze della maggior parte dei team. Tutte supportano l'uso degli strumenti di pianificazione Agile per creare il backlog di prodotto e lavorare in sprint con la lavagna delle attività. Se il team ha esigenze insolite, è possibile personalizzare un modello, quindi creare il progetto team oppure creare un progetto team da un modello e personalizzare il progetto.

Nella tabella seguente vengono riepilogate le distinzioni principali tra i tipi e gli stati degli elementi di lavoro usati dai tre modelli di processo predefiniti.

Note:

1. È possibile definire questi tipi di elemento di lavoro usando Backlog di prodotto. La pagina di backlog di prodotto mostra una sola visualizzazione del backlog di lavoro corrente che può essere riordinato e raggruppato in modo dinamico. I proprietari del prodotto possono classificare il lavoro in ordine di priorità e descrivere le dipendenze e le relazioni rapidamente.

2. È possibile creare funzionalità e collegarle agli elementi di backlog per gestire il backlog di portfolio. Con i backlog di portfolio, è possibile definire una gerarchia di backlog per determinare l'ambito di lavoro tra i diversi team e vedere il modo in cui il lavoro può essere ampliato fino a includere iniziative più ampie.

3. È possibile definire attività usando Backlog sprint e lavagna delle attività. La pagina di backlog sprint riflette in tempo reale i dati che vengono inseriti. I dati includono gli elementi di lavoro assegnati al percorso di iterazione, al lavoro rimanente, alla capacità di lavoro individuale e alle interruzioni di lavoro sia per il team che per gli utenti. I team possono ottenere un feedback istantaneo sulla frequenza del burn-down e sulla posizione in cui superano la capacità.

4. Le cartelle di lavoro sono disponibili solo quando il progetto team è configurato con un portale del progetto SharePoint. È possibile tuttavia creare una cartella di lavoro aprendo una query corrispondente in Excel.

Stati del flusso di lavoro

Gli stati del flusso di lavoro supportano il rilevamento dello stato del lavoro durante il passaggio da uno stato nuovo a uno stato chiuso o completato. I diagrammi seguenti mostrano la tipica progressione in avanti dei tipi di elemento di lavoro usati per tenere traccia del lavoro e dei difetti del codice per i tre modelli di processo TFS predefiniti. Essi mostrano anche alcune delle regressioni agli stati precedenti e alle transizioni agli stati rimossi. Ogni immagine mostra solo il motivo predefinito associato alla transizione.

Scrum	Agile	CMMI
Funzionalità	Funzionalità	Funzionalità
Elemento del Backlog di Prodotto	Storia utente	Requisiti
Bug	Bug	Bug
Attività	Attività	Attività

I tipi di elemento di lavoro Scrum e Agile usati dagli strumenti di pianificazione Agile supportano le transizioni any-to-any. È possibile aggiornare lo stato di un elemento di lavoro mediante la bacheca Kanban o la lavagna delle attività trascinando l'elemento nella colonna stato corrispondente.

Stati, motivi e transizioni del flusso di lavoro

Il flusso di lavoro definisce la progressione logica delle attività da eseguire e l'autore. Ogni flusso di lavoro è costituito da un set di stati, dalle transizioni valide tra gli stati e dai motivi per la transizione dell'elemento di lavoro allo stato selezionato. È possibile modificare il flusso di lavoro per supportare altri stati, transizioni e motivi.

Stati Rimosso, Chiuso e Completato

Quando si modifica lo stato di un elemento di lavoro in Rimosso, Chiuso o Completato, il sistema risponde come indicato di seguito:

• Chiuso o Completato: gli elementi di lavoro in questo stato non vengono visualizzati nelle pagine di backlog e di backlog di portfolio. Tuttavia, vengono visualizzati nelle pagine di backlog sprint, nella bacheca Kanban e nella lavagna delle attività. Inoltre, quando si modifica la visualizzazione del backlog di portfolio per mostrare gli elementi di backlog, ad esempio per visualizzare le funzionalità negli elementi del backlog di prodotto, verranno visualizzati gli elementi nello stato chiuso e completato.

• Rimosso: gli elementi di lavoro in questo stato non vengono visualizzati né nei backlog né nelle aree attività.

Gli elementi di lavoro vengono gestiti in un progetto team, purché il progetto team sia attivo. Anche se gli elementi di lavoro vengono impostati su Chiuso, Completato o Rimosso, un record viene conservato nell'archivio dati. Tali record possono essere usati per creare query o report. Se è necessario eliminare in modo permanente gli elementi di lavoro, è possibile usare lo strumento da riga di comando witadmin destroywi.

Tipi di elemento di lavoro aggiunti a tutti i modelli di processo

I seguenti tipi di elemento di lavoro sono uguali in tutti i modelli di processo.

I team creano e usano questi tipi usando lo strumento corrispondente:

• Piano di test, gruppo di test, passi condivisi di test case e parametri condivisi: Microsoft Test Manager..

  I parametri condivisi diventano disponibili quando si effettua l'aggiornamento della distribuzione locale a TFS 2013.2.

  I tipi di elementi di lavoro del piano di teste del gruppo di test diventano disponibili quando si aggiorna la distribuzione locale a TFS 2013.3.

• Richiesta feedback e risposta feedback - Richiesta feedback.

• Richiesta di revisione e risposta di revisione del codice - Lavoro (da Team Explorer) e Richiesta di revisione del codice.

Gli elementi di lavoro da queste definizioni dei tipi non possono essere creati manualmente, pertanto vengono aggiunti alla categoria dei tipi nascosti. I tipi di elemento di lavoro aggiunti alla categoria Tipi nascosti non vengono visualizzati nei menu usati per creare nuovi elementi di lavoro.

Tipi di elementi di lavoro che supportano l'esperienza di test

I tipi di elementi di lavoro che supportano l'esperienza di test e funzionano con Test Manager e Team Web Access sono collegati reciprocamente tramite i tipi di collegamento mostrati nell'immagine seguente.

Tramite Team Web Access o Test Manager è possibile visualizzare i test case definiti per un gruppo di test e i gruppi di test definiti per un piano di test. Questi oggetti, tuttavia, non sono connessi reciprocamente tramite tipi di collegamento.

Come indicato in precedenza, i tipi di elemento di lavoro del piano di test e del gruppo di test vengono visualizzati dopo aver effettuato l'aggiornamento del server a livello di applicazione a TFS 2013.3. È possibile personalizzare questi tipi di elemento di lavoro analogamente a qualsiasi altro tipo di elemento di lavoro. Vedere Personalizzare oggetti di rilevamento degli elementi di lavoro per supportare i processi del team.

Se si modifica il flusso di lavoro per il piano di test e il gruppo di test, è necessario aggiornare la configurazione del processo come descritto qui.

Per le definizioni di ciascun campo di test, vedere Riferimento ai campi Integrare test e compilare.

Per informazioni sulle modifiche apportate a Team Manager e Team Web Access con l'aggiornamento a TFS 2013.3, vedere Opening test plan and test suite work item types.

Domande da porre al team

Per tenere traccia del lavoro in modo efficiente, i membri del team devono concordare sulla modalità di uso dei tipi di elemento di lavoro e degli strumenti. Di seguito vengono riportate alcune domande cui il team deve rispondere.

Domande e risposte

D: Che cosa accade se si aggiorna un progetto team?

R: Per usare le nuove funzionalità aggiunte quando si installa l'ultima versione di TFS, vedere Aggiornare un progetto team aggiornato per accedere alle nuove funzionalità.

Per personalizzare i progetti team esistenti, vedere Personalizzare oggetti di rilevamento degli elementi di lavoro per supportare i processi del team.

D: Quale modello di processo è consigliabile usare con la bacheca Kanban?

R: È possibile usare la bacheca Kanban con qualsiasi modello di processo, predefinito o personalizzato.

D: Come è possibile ottenere gli ultimi modelli di processo?

R: Le versioni più recenti dei modelli di processo predefiniti vengono caricate automaticamente quando si installa o si esegue l'aggiornamento alla versione più recente di TFS. Usare Caricare, scaricare ed eliminare i modelli di processo per una raccolta di progetti team per eseguire il download.

Inoltre, è possibile scaricare Esempi di modelli di processo di Team Foundation Server 2013 - Supporto di Scaled Agile Framework (SAFe). I modelli contengono le personalizzazioni descritte in questo white paper: Scaled Agile Framework: Using TFS to support epics, release trains, and multiple backlogs.

D: Esiste uno strumento che supporta la visualizzazione del diagramma di stato del flusso di lavoro?

R: Sì. È possibile usare l'Editor di processo fornito con Power Tools di Team Foundation Server.

D: Quali sono gli altri aspetti definiti in un modello di processo?

R: Oltre a definire gli elementi del progetto team, il modello di processo definisce la configurazione iniziale di molti elementi usati per tenere traccia del lavoro e supportare le attività di test. Questi elementi includono:

• Percorsi di area e iterazione

• Query elemento di lavoro

• Variabili di test, configurazioni, stati di risoluzione e impostazioni di test predefinite

• Definizioni di gruppi e membri e assegnazioni di autorizzazioni

• Come i campi di Microsoft Project vengono mappati ai campi di Team Foundation

Tutti gli elementi possono essere configurati o personalizzati dopo la creazione di un progetto team dal modello di processo.

D: È possibile personalizzare un modello di processo?

R: Sì. I modelli predefiniti sono progettati per soddisfare le esigenze della maggior parte dei team. Se il team ha esigenze insolite, è possibile personalizzare un modello, quindi creare il progetto team oppure creare un progetto team da un modello e personalizzare il progetto.

D: Quali sono le modifiche apportate ai modelli di processo rispetto alla versione precedente?

R: Vedere Modifiche apportate ai progetti team e ai modelli di processo predefiniti durante l'aggiornamento di Team Foundation Server.

D: Quali operazioni eseguire se sono necessari più backlog di portfolio?

R: È possibile definire altri backlog di portfolio per un totale di cinque backlog di portfolio.

D: Dove è possibile ottenere altre informazioni sullo storyboard?

R: La scheda Storyboard nel form dell'elemento del backlog di prodotto consente il collegamento agli storyboard che sono stati caricati su un percorso di rete condiviso. È possibile collegare qualsiasi URL cui il team può accedere. È possibile inoltre collegarsi agli storyboard creati tramite Storyboard di PowerPoint.

D: A chi rivolgersi per eventuali domande?

R: È possibile porre una domanda o cercare una risposta nel forum relativo a progetti team ed elementi di lavoro in Team Foundation Server forum.