Aggiornare un modello di processo personalizzato per accedere alle nuove funzionalità

Se la procedura guidata Configura funzionalità non riesce ad aggiornare il progetto team, significa che il progetto team è stato creato da un modello di processo diverso da quelli disponibili in TFS o che il progetto team è stato personalizzato in modo tale che non è più possibile applicare gli aggiornamenti. In questi casi, per aggiornare i progetti team esistenti, è possibile scegliere tra le opzioni seguenti:

• Opzione A: aggiungere funzionalità al modello di processo personalizzato, quindi eseguire la procedura guidata Configura funzionalità

  Eseguire i passaggi: , , e

  Scegliere questa opzione se sono state applicate molte personalizzazioni al modello di processo.

• Opzione B: applicare le personalizzazioni all'ultimo modello di processo, quindi eseguire la procedura guidata Configura funzionalità

  Eseguire i passaggi: , , e .

  Scegliere questa opzione se sono state applicate poche personalizzazioni al modello di processo.

• Opzione C: Aggiungere funzionalità tramite un processo di aggiornamento manuale

  Scegliere questa opzione se le personalizzazioni applicate al progetto team non sono presenti in altri modelli di processo.

• Opzione D: aggiornare più progetti team a livello di codice. Scegliere innanzitutto l'Opzione A o l'Opzione B per aggiornare il modello di processo personalizzato. A questo punto, per aggiornare in batch tutti i progetti team definiti per una raccolta di progetti team, vedere le informazioni e le risorse seguenti: post di blog su come configurare le funzionalità per decine di progetti team e l'articolo sulla soluzione CodePlex Features4.

  Scegliere questa opzione in presenza di decine di progetti team creati dallo stesso modello di processo.

Per altre informazioni sulle aggiunte apportate agli ultimi modelli di processo predefiniti, vedere Modifiche alla configurazione apportate per aggiungere nuove funzionalità.

1.Scaricare l'ultimo modello di processo

  Copiare o aggiungere i file dalla cartella della versione più recente del modello di processo scaricato nella cartella corrispondente che contiene le definizioni di modello di processo personalizzate.

1. Se si sta aggiornando un modello di processo basato su una versione precedente a MSF 6.0 o a Visual Studio Scrum 2.0, è necessario prima applicare gli aggiornamenti forniti nella versione 2012 di questo argomento.

   È possibile controllare le informazioni sulla versione nel file ProcessTemplate.xml.

2. Se non è stato eseguito l'aggiornamento del server di livello applicazione alla versione di TFS contenente le funzionalità desiderate, aggiornarlo ora. Scaricare e Aggiornare Team Foundation Server.

3. Se non si è membri del gruppo Project Collection Administrators, richiedere di essere aggiunti. Per scaricare e gestire i modelli di processo, è necessario impostare l'autorizzazione Gestisci modello di processo su Consenti.

4. Dopo l'aggiornamento di TFS, scaricare l'ultimo modello di processo da TFS e scegliere il modello di processo il più possibile corrispondente a quello usato per creare il progetto team.

   Vedere Scaricare la versione più recente dei modelli di processo.

   Per scaricare o caricare i modelli di processo, è necessario connettersi a TFS 2013 da Visual Studio 2013 o Team Explorer 2013.

5. Copiare il modello di processo in una nuova cartella dove si applicheranno le personalizzazioni (opzione B) oppure copiare le definizioni XML per aggiungere nuove funzionalità al modello di processo esistente (opzione C).

2.Aggiungere funzionalità al modello di processo personalizzato (opzione A)

   Per aggiornare il modello di processo personalizzato, è possibile aggiungere i tipi di elemento di lavoro seguenti:

• Funzionalità supporta la gestione di backlog di portfolio.

• Parametro condiviso supporta la ripetizione di test con dati diversi.

• Piano di test e Gruppo di test supportano la personalizzazione di questi artefatti e la possibilità di eseguire una query sulla base di questi elementi di tipo di lavoro. Le altre modifiche introdotte sono descritte nei due argomenti seguenti: Nuove funzionalità abilitate per Team Web Access e Pianificare test manuali.

Copiare o aggiungere i file dalla cartella della versione più recente del modello di processo scaricato nella cartella corrispondente che contiene le definizioni di modello di processo personalizzate.

Aggiungere il supporto per il backlog di portfolio e Funzionalità (obbligatorio TFS 2013)

1. Copiare il file Feature.xml dalla cartella WorkItem Tracking/TypeDefinitions alla cartella corrispondente del modello di processo personalizzato.

2. Aggiungere Feature Category al file Categories disponibile nella cartella WorkItem Tracking.

   <CATEGORY name="Feature Category" refname="Microsoft.FeatureCategory">
       <DEFAULTWORKITEMTYPE name="Feature" />
     </CATEGORY>
   

3. Aprire il file di plug-in WorkItems che si trova nella cartella WorkItem Tracking.

   1. Aggiungere un'attività per caricare il tipo di elemento di lavoro Funzionalità nella sezione <WORKITEMTYPES>.

      <WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\Feature.xml" />
      

   2. Sostituire le due attività di configurazione del processo all'interno dell'elemento PROCESSCONFIGURATION

      <PROCESSCONFIGURATION>
         <CommonConfiguration fileName="WorkItem Tracking\Process\CommonConfiguration.xml"/>
         <AgileConfiguration fileName="WorkItem Tracking\Process\AgileConfiguration.xml"/>
      </PROCESSCONFIGURATION>
      

      .. con la sola istruzione dell'elemento che fa riferimento al file ProcessConfiguration.

      <PROCESSCONFIGURATION>
         <ProjectConfiguration fileName="WorkItem Tracking\Process\ProcessConfiguration.xml"/>
      </PROCESSCONFIGURATION>
      

4. Copiare il file ProcessConfiguration dalla cartella WorkItem Tracking/Process del modello di processo scaricato alla cartella del modello personalizzato nello stesso percorso.

   Includere tutte le personalizzazioni apportate al file AgileConfiguration o CommonConfiguration in ProcessConfiguration. Per altre informazioni, vedere Riferimento XML alla configurazione di processo.

5. Eliminare i file AgileConfiguration e CommonConfiguration dalla cartella WorkItem Tracking/Process.

   La configurazione del processo è supportata ora dal singolo file ProcessConfiguration.

6. Sostituire i file Backlog/Stories/Requirement Overview.rdl e Stories/Requirements Progress.rdl nella cartella Reports della cartella del modello personalizzato con i file del modello di processo scaricato nello stesso percorso.

   Questi aggiornamenti riflettono le modifiche richieste con l'introduzione del tipo di elemento di lavoro del backlog di portfolio Feature come descritto in questo post di blog: Aggiornare i report Panoramica e Stato di avanzamento per supportare i backlog di portfolio.

7. Sostituire la cartella Process Guidance, situata nella cartella Windows SharePoint Services, con il contenuto della cartella più recente.

   Questi file forniscono collegamenti diretti al contenuto più recente delle linee guida per il processo.

Aggiungere il supporto per Parametri condivisi (obbligatorio TFS 2013.2)

1. Copiare il file SharedParameter.xml dalla cartella WorkItem Tracking/TypeDefinitions alla cartella corrispondente del modello di processo personalizzato.

2. Aggiungere Shared Parameter Category al file Categories disponibile nella cartella WorkItem Tracking.

   <CATEGORY name="Shared Parameter Category" refname="Microsoft.SharedParameterCategory">
       <DEFAULTWORKITEMTYPE name="Shared Parameter" />
     </CATEGORY>
   

3. Aggiungere Shared Parameter a Hidden Types Categories.

   <CATEGORY name="Hidden Types Category" refname="Microsoft.HiddenCategory">
       <DEFAULTWORKITEMTYPE name="Code Review Request" />
       <WORKITEMTYPE name="Code Review Response" />
       <WORKITEMTYPE name="Feedback Request" />
       <WORKITEMTYPE name="Feedback Response" />
       <WORKITEMTYPE name="Shared Steps" />
       <WORKITEMTYPE name="Shared Parameter" />  </CATEGORY>
   

4. Aprire il file di plug-in WorkItems che si trova nella cartella WorkItem Tracking.

5. Aggiungere un'attività per caricare il tipo di elemento di lavoro Parametro condiviso alla sezione <WORKITEMTYPES>.

   <WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\SharedParameter.xml" />
   

Aggiungere i tipi di elemento di lavoro Piano di test e Gruppo di test (obbligatorio TFS 2013.3)

Quando si aggiorna il server a livello applicazione a TFS 2013.3, l'Aggiornamento guidato di TFS aggiorna automaticamente i progetti team esistenti per supportare i nuovi oggetti di rilevamento di elementi di lavoro per piani di test e gruppi di test.

Sono apportate modifiche al progetto team, ma eventuali modelli di processo personalizzati non sono modificati. È tuttavia possibile aggiornare manualmente i modelli di processo personalizzati. I motivi per l'aggiornamento includono il supporto di aggiornamenti futuri di TFS che richiedono l'uso della procedura guidata Configura funzionalità oppure la volontà di creare progetti team con il modello di processo personalizzato nel server aggiornato. Questi oggetti devono essere aggiunti manualmente ai modelli di processo personalizzati.

1. Copiare i file TestPlan.xml e TestSuite.xml dalla cartella WorkItem Tracking/TypeDefinitions alla cartella corrispondente del modello di processo personalizzato.

2. Aggiungere Test Plan Category e Test Suite Category al file Categories disponibile nella cartella WorkItem Tracking.

   <CATEGORY name="Test Plan Category" refname="Microsoft.TestPlanCategory">
       <DEFAULTWORKITEMTYPE name="Test Plan" />
     </CATEGORY>
     <CATEGORY name="Test Suite Category" refname="Microsoft.TestSuiteCategory">
       <DEFAULTWORKITEMTYPE name="Test Suite" />
     </CATEGORY>
   

3. Aggiungere Test Plan Category e Test Suite Category a Hidden Types Categories.

   <CATEGORY name="Hidden Types Category" refname="Microsoft.HiddenCategory">
       <DEFAULTWORKITEMTYPE name="Code Review Request" />
       <WORKITEMTYPE name="Code Review Response" />
       <WORKITEMTYPE name="Feedback Request" />
       <WORKITEMTYPE name="Feedback Response" />
       <WORKITEMTYPE name="Shared Steps" />
       <WORKITEMTYPE name="Shared Parameter" />
       <WORKITEMTYPE name="Test Plan" />
       <WORKITEMTYPE name="Test Suite" />
     </CATEGORY>
   

4. Aprire il file di plug-in WorkItems che si trova nella cartella WorkItem Tracking.

5. Aggiungere un'attività per il caricamento dei tipi di elementi di lavoro Piano di test e Gruppo di test alla sezione <WORKITEMTYPES>.

   <WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\TestPlan.xml" />
   <WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\TestSuite.xml" />
   

3.Applicare le personalizzazioni al modello di processo (opzione B)

Con questa opzione, si applicano le personalizzazioni apportate al progetto team o al modello di processo all'ultimo modello di processo il più possibile corrispondente al modello usato per creare il progetto team.

1. Applicare le personalizzazioni alla nuova cartella del modello di processo:

   • Applicare le personalizzazioni apportate alle definizioni di tipo di elemento di lavoro predefinito. Possono essere incluse aggiunte di campi o modifiche al flusso di lavoro o al form.

   • Aggiungere i tipi di elemento di lavoro personalizzato alla cartella di gestione di elementi di lavoro e, se necessario, aggiornare il file di definizione WorkItems. Vedere Aggiungere definizioni di tipi per elementi di lavoro a un modello di processo.

     Se si vuole usare un tipo di elemento di lavoro personalizzato contenente lo stesso nome di quelli nel modello di processo predefinito, assicurarsi di sostituire i file di definizione dei tipi di elemento di lavoro. Se si desidera usare un tipo di elemento di lavoro personalizzato con un nome diverso da quello fornito nel modello di processo predefinito, è necessario modificare le categorie e i file di definizione della configurazione di processo prima dell'importazione per riflettere la denominazione diversa.

   • Applicare le personalizzazioni al file di definizione Categories.

   • Applicare le personalizzazioni al file di definizione ProcessConfiguration. Controllare che i tipi di elemento di lavoro desiderati siano rappresentati nelle categorie corrette e che tutti gli stati del flusso di lavoro siano mappati ai metastati.

   • Copiare eventuali altri file modello di processo personalizzati nella cartella di modello di processo appropriata. Per un elenco completo di file modello di processo e per informazioni sulla personalizzazione di questi file, vedere Cenni preliminari sui file di modello di processo.

2. Esaminare le modifiche in base a questo elenco di controllo per assicurarsi di aver applicato tutte le personalizzazioni necessarie:

   Personalizzazione	Aggiornare o verificare la definizione dei tipi di elemento di lavoro	Aggiornare o verificare la definizione della configurazione del processo
   Aggiungere un elemento di lavoro alla Categoria requisiti Un elemento di lavoro può appartenere alla Categoria requisiti o alla Categoria attività, ma non a entrambe.	Per includere i campi seguenti: Valore del campo assegnato a type=Order nel file di configurazione del processo (Priorità del Backlog in Scrum, Ordine di priorità in Agile o CMMI) Valore del campo assegnato a type=Effort nel file di configurazione del processo (Lavoro richiesto (Scrum), Punti della storia (Agile) o Dimensione (CMMI)) Percorso area o valore del campo assegnato a type=Team nel file di configurazione del processo. Tutti i campi inclusi nella sezione AddPanel del file di configurazione del processo (i campi devono essere definiti nella sezione FIELDS ma non devono essere necessariamente inclusi nella sezione FORM).	Per includere i mapping a metastati necessari nella sezione RequirementBacklog: Mappare gli stati iniziali di ciascun elemento di lavoro nella Categoria requisiti a type="Proposed" Mappare ogni stato di flusso di lavoro intermedio da visualizzare nell'area Kanban a type="InProgress" Mappare la fine di ogni stato di flusso di lavoro a type="Complete" È possibile avere più di uno stato mappato a type="Complete" Per includere una voce per definire i codici colore associati al tipo di elemento di lavoro. Ad esempio: <WorkItemColor primary="FF009CCC" secondary="FFD6ECF2" name="Product Backlog Item" />
   Modificare il flusso di lavoro di un elemento di lavoro nella Categoria requisiti	N/D	Per inserire i mapping a metastati necessari come descritto in precedenza per l'aggiunta di un elemento di lavoro alla Categoria requisiti.
   Aggiungere un tipo di elemento di lavoro alla Categoria attività	Per includere i campi seguenti: Valore del campo assegnato a type=Order nel file di configurazione del processo (Priorità del Backlog in Scrum, Ordine di priorità in Agile o CMMI) Valore del campo assegnato a type=Activity nel file di configurazione del processo (Attività (Scrum o Agile) o Disciplina (CMMI) ) Percorso di area o valore di campo assegnato a type=Team nel file di configurazione del processo Valore del campo assegnato a type=RemainingWork nel file di configurazione del processo (Lavoro rimanente) (Facoltativo) Lavoro originale e Lavoro completato (solo Agile e CMMI)	Per includere i mapping a metastati necessari nella sezione TaskBacklog: Mappare gli stati iniziali di ciascun elemento di lavoro nella Categoria attività a type="Proposed" Mappare ogni stato di flusso di lavoro intermedio da visualizzare nella lavagna delle attività a type="InProgress" Mappare la fine di ogni stato di flusso di lavoro a type="Complete" È possibile avere più di uno stato mappato a type="Complete" Per includere una voce per definire i codici colore associati al tipo di elemento di lavoro. Ad esempio: <WorkItemColor primary="FFF2CB1D" secondary="FFF6F5D2" name="Task" />
   Modificare il flusso di lavoro di un tipo di elemento di lavoro nella Categoria attività	N/D	Per includere i mapping a metastati necessari illustrati in precedenza per l'aggiunta di un tipo di elemento di lavoro alla Categoria attività.
   Aggiungere un elemento di lavoro alla Categoria bug o modificare il flusso di lavoro di un elemento di lavoro nella Categoria bug (solo Agile e CMMI) (Vedere la Nota a)	Per supportare l'impostazione configurabile dal team per l'aggiunta di bug al backlog, includere i seguenti campi: Valore del campo assegnato a type=Order nel file di configurazione del processo (Priorità del Backlog in Scrum, Ordine di priorità in Agile o CMMI) Valore del campo assegnato a type=Effort nel file di configurazione del processo (Lavoro richiesto (Scrum), Punti della storia (Agile) o Dimensione (CMMI))	Per includere i mapping a metastati necessari nella sezione BugWorkItems: Mappare lo stato iniziale di ciascun elemento di lavoro nella Categoria bug a type="Proposed" Mappare tutti gli stati del flusso di lavoro intermedi da visualizzare nella bacheca Kanban o per Lavoro personale a type="InProgress" Mappare la fine di ogni stato di flusso di lavoro a type="Complete" È possibile avere più di uno stato mappato a type="Complete" Per altre informazioni, vedere Supportare lo stato di aggiornamento dei bug tramite la funzionalità Lavoro personale.
   Rimuovere un elemento di lavoro dalla Categoria requisiti o dalla Categoria attività	N/D	Per rimuovere eventuali mapping a metastati associati solo a tale tipo di elemento di lavoro
   Rimuovere un elemento di lavoro	Rimuovere l'elemento di lavoro dal file delle categorie	Per rimuovere eventuali mapping a metastati associati solo al tipo di elemento di lavoro rimosso e l'elemento WorkItemColor che definisce il codice colore per il tipo di elemento di lavoro rimosso.
   Rinominare un tipo di elemento di lavoro	Aggiornare il file delle categorie con i nuovi nomi	Aggiornare il file di configurazione del processo con i nuovi nomi

   Note:

   1. Se si è effettuato l'aggiornamento a TFS 2013.4, vedere Aggiungere bug all'area attività o al backlog. TFS 2013.4 introduce un'impostazione che consente a tutti i team di visualizzare i bug nel proprio backlog e sulla bacheca Kanban. Questa funzionalità fa riferimento ai mapping a metastati eseguiti in BugWorkItems.

4.Rinominare e caricare il modello di processo in TFS

   Per far selezionare alla procedura guidata Configura funzionalità l'ultima versione di un modello di processo, è necessario aggiornare l'istruzione version per poter distinguere la versione del modello di processo aggiornata da quelle precedenti.

1. Aprire il file del plug-in ProcessTemplate che si trova nella cartella di primo livello.

   1. Aggiornare il nome per riflettere le modifiche apportate nella versione. Ad esempio:

      <name>MyCompany Custom Scrum 2013.3  </name>
      

   2. Aggiornare il frammento di codice dopo l'elemento description. Aumentare la versione secondaria per indicare che sono stati eseguiti aggiornamenti al modello di processo esistente e distinguerlo dal modello di processo TFS predefinito.

      La scelta dei frammenti di codice si basa sulla categoria di modello che si sta aggiornando:

      Categoria	Istruzione della versione
      Agile	<version type="ADCC42AB-9882-485E-A3ED-7678F01F66BC" major="7" minor="20"/>
      CMMI	<version type="27450541-8E31-4150-9947-DC59F998FC01" major="7" minor="10"/>
      Scrum	<version type="6B724908-EF14-45CF-84F8-768B5384DA45" major="3" minor="10"/>

2. Caricare il modello di processo.

   Per verificare le modifiche, creare un progetto di test. Vedere Creare un progetto team.

5.Eseguire la procedura guidata Configura funzionalità

Dopo aver verificato che il modello di processo supporti le personalizzazioni, eseguire la procedura guidata Configura funzionalità per aggiornare i progetti team esistenti. Vedere Configurare funzionalità dopo un aggiornamento di TFS.

Domande e risposte

D: Quali tipi di personalizzazioni impediscono alla procedura guidata Configura funzionalità di aggiornare un progetto team?

R: Le modifiche seguenti apportate a un modello di processo possono interferire con la possibilità della procedura guidata Configura funzionalità di eseguire:

• Elementi di lavoro rinominati o rimossi appartenenti alla Categoria requisiti o alla Categoria attività.

• Stati rinominati o stati del flusso di lavoro personalizzati definiti per gli elementi di lavoro appartenenti alla Categoria requisiti o alla Categoria attività. I metastati definiscono come gli strumenti di pianificazione considerino ogni stato del flusso di lavoro. Almeno uno stato del flusso di lavoro deve mappare ai metastati InProgress e Completed

• Rimozione dei campi definiti per gli elementi di lavoro appartenenti alla Categoria requisiti o alla Categoria attività. Questi campi vengono definiti nel file di definizione ProcessConfiguration e includono i campi usati per gestire la priorità del backlog, il lavoro richiesto, l'attività o la disciplina e il lavoro rimanente.

Per altre informazioni, vedere Riferimento all'elemento XML di configurazione del processo.

D: Come viene usata l'istruzione della versione nei modelli di processo?

R: La procedura guidata Configura funzionalità usa l'istruzione version per determinare il modello di processo con la versione più recente all'interno di una categoria, quindi seleziona automaticamente tale versione.

Se l'istruzione version non è presente, la procedura guidata Configura funzionalità non può selezionare il modello di processo per aggiornare un progetto team. Inoltre, se in TFS sono stati caricati più modelli di processo che specificano lo stesso numero di versione più alto, nessuno di questi modelli di processo potrà essere selezionato per aggiornare un progetto team.

D: L'uso dei modelli di processo non è familiare.Cosa è necessario conoscere sull'esecuzione di aggiornamenti manuali?

R: Tenere presenti questi suggerimenti quando si modificano i file modello di processo:

• Per una panoramica dei modelli di processo e dei relativi file e cartelle, vedere Personalizzare un modello di processo e Cenni preliminari sui file di modello di processo.

• Non rimuovere un file o un'attività per caricare un file a meno di non essere certi di che cosa sia il file e che non verrà usato.

• Per trovare le personalizzazioni apportate, è possibile eseguire un'operazione diff sui file paragonabili esistenti nei due modelli. Si possono però ricevere alcuni falsi positivi perché la sequenza di definizioni di elementi potrebbe essere cambiata da una versione all'altra.

• È possibile cercare l'elemento dependency in tutti i file dei plug-in per sapere quali attività dipendono da altre attività da completare. Ad esempio, Microsoft Test Manager e Lab Management richiedono i tipi di elemento di lavoro SharedSteps e TestCase, i tipi di collegamento SharedSteps e TestedBy e le categorie. Vedere Definire le dipendenze per attività e gruppi di attività in file di plug-in.

D: Come si rinomina un tipo di elemento di lavoro?

R: Usare il comando witadmin renamewitd per cambiare il nome e quindi aggiornare il file di definizione delle categorie. Per altre informazioni, vedere Modificare o aggiungere un tipo di elemento di lavoro personalizzato (WIT).

D: Che cosa accade se si desidera usare più di un livello di backlog di portfolio?

R: È possibile aggiungere fino a cinque backlog di portfolio. È incluso il backlog predefinito della funzionalità. È possibile aggiungerlo a un modello di processo personalizzato o dopo aver aggiornato il progetto team. Per un'introduzione, vedere l'argomento Aggiungere un backlog di portfolio.

D: Dove è possibile reperire altre informazioni sui file di definizione da modificare?

R: Per altre informazioni, vedere questi argomenti:

• Personalizzare un modello di processo

• Riferimento a tutti gli elementi XML WITD

• Riferimento agli elementi XML delle categorie

• Riferimento all'elemento XML di configurazione del processo

D: A chi rivolgersi per eventuali domande?

R: È possibile pubblicare una domanda o trovare le risposte in uno dei seguenti forum: Team Foundation Server - Gestione elementi di lavoro oppure Team Web Access.