Modificare il flusso di lavoro per un tipo di elemento di lavoro

Azure DevOps Server | Azure DevOps Server 2022

Modificare il flusso di lavoro per un tipo di elemento di lavoro (WIT) per supportare i processi aziendali e del team. WiT supporta il rilevamento di tutti i tipi di lavoro, ovvero requisiti, attività, difetti del codice, per supportare lo sviluppo di software.

Il flusso di lavoro determina la progressione logica e la regressione del lavoro che i membri del team eseguono. Specifica inoltre i valori visualizzati nei menu a discesa per i campi Stato e Motivo. Per altre informazioni, vedere Informazioni sui processi e sui modelli di processo.

Flusso di lavoro per elemento backlog prodotto (modello di processo Scrum)

Aggiornare la definizione XML per un tipo di elemento di lavoro

Se non si ha familiarità con la personalizzazione di WIT, tenere presente quanto segue:

• Per personalizzare qualsiasi aspetto di un tipo di elemento di lavoro, aggiornarne la definizione XML. Per altre informazioni, vedere Informazioni di riferimento su tutti gli elementi XML WITD.
• Se si personalizza il web form che usa la nuova esperienza dell'elemento di lavoro, vedere gli elementi WebLayout e Control.
• Se state personalizzando un modulo client da usare con Visual Studio, consultate il riferimento all'elemento XML Layout .
• Seguire la sequenza di passaggi delineati in Personalizzare il modulo web di tracciamento degli elementi di lavoro.

Per personalizzare il flusso di lavoro, seguire questi due passaggi:

1. Modificare la WORKFLOW sezione della definizione del WIT come descritto in questo argomento.

2. Modificare la configurazione del processo per mappare i nuovi stati del flusso di lavoro ai metastati.

   Questo secondo passaggio è necessario quando si modifica il flusso di lavoro per un WIT visualizzato in una pagina degli strumenti Agile. Questi WIT appartengono alle categorie Requisito o Attività. Per altre informazioni sulle categorie di stato, vedere Stati del flusso di lavoro e categorie di stato.

Linee guida per la progettazione del flusso di lavoro

Definire il flusso di lavoro identificando prima gli stati e le transizioni valide tra di esse. La WORKFLOW sezione della definizione del WIT specifica gli stati validi, le transizioni, i motivi delle transizioni e le azioni facoltative eseguite quando un membro del team modifica lo stato di un elemento di lavoro.

In generale, associare ogni stato a un ruolo membro del team e a un'attività che una persona in tale ruolo deve eseguire per elaborare l'elemento di lavoro prima di modificarne lo stato. Le transizioni definiscono le progressione e le regressioni valide tra gli stati. I motivi per cui un membro del team modifica un elemento di lavoro da uno stato a un altro e le azioni supportano l'automazione della transizione di un elemento di lavoro in un punto del flusso di lavoro.

Ad esempio, impostare Stato su Nuovo quando un tester apre un nuovo bug basato sul processo Agile predefinito. Lo sviluppatore modifica lo stato su Attivo durante la correzione del bug e, una volta corretto, lo sviluppatore modifica lo stato in Risolto e imposta il valore del campo Motivo su Fisso. Dopo aver verificato la correzione, il tester modifica lo stato del bug in Chiuso e il campo Motivo cambia in Verificato. Se il tester ha stabilito che lo sviluppatore non ha corretto il bug, il tester modifica lo stato del bug in Attivo e specifica il motivo come Non corretto o Test non riuscito.

Durante la progettazione o la modifica di un flusso di lavoro, prendere in considerazione le linee guida seguenti:

• Usare l'elemento STATE per definire uno stato univoco per ogni ruolo membro del team che esegue un'azione specifica su un elemento di lavoro. Più stati si definiscono, più transizioni è necessario definire. Indipendentemente dalla sequenza in cui si definiscono gli stati, vengono visualizzati in ordine alfanumerico nel menu a discesa per il campo Stato .

  Se si aggiunge uno stato a un tipo di elemento di lavoro visualizzato nel backlog o nelle pagine della bacheca nel portale Web, è anche necessario associare lo stato a una categoria di stato. Per altre informazioni, vedere Stati del flusso di lavoro e categorie di stato.

• Usare l'elemento TRANSITION per definire una transizione per ogni progressione e regressione valida da uno stato a un altro.

  Definire almeno una transizione per ogni stato e la transizione dallo stato Null allo stato iniziale.

  È possibile definire una sola transizione dallo stato non assegnato (null) allo stato iniziale. Quando si salva un nuovo elemento di lavoro, il processo lo assegna automaticamente allo stato iniziale.

  Quando un membro del team modifica lo stato di un elemento di lavoro, tale modifica attiva la transizione e le azioni definite per lo stato selezionato e la transizione. Gli utenti possono specificare solo gli stati validi in base alle transizioni definite per lo stato corrente. Inoltre, un ACTION elemento, che è un elemento figlio di TRANSITION, può modificare lo stato di un elemento di lavoro.

• Per ogni transizione, definire un motivo predefinito usando l'elemento DEFAULTREASON . È possibile definire tutti i motivi facoltativi desiderati usando l'elemento REASON . Questi valori vengono visualizzati nel menu a discesa del campo Motivo .

• È possibile specificare regole che si applicano quando l'elemento di lavoro cambia stato, quando passa o quando un utente seleziona un motivo specifico. Molte di queste regole integrano le regole condizionali che è possibile applicare quando si definiscono i campi nella FIELDS sezione sotto la WORKITEMTYPE definizione. Per altre informazioni, vedere Aggiornare i campi durante una modifica del flusso di lavoro più avanti in questo argomento.

• I nomi che assegni agli stati e ai motivi non fanno distinzione tra maiuscole e minuscole.

  I menu a discesa per i campi Stato e Motivo all'interno del modulo dell'elemento di lavoro o dell'editor di query visualizzano i valori assegnati nella WORKFLOW sezione del tipo di elemento di lavoro.

Diagramma del flusso di lavoro ed esempio di codice

Nell'esempio di codice seguente viene illustrato il WORKFLOW per la definizione WIT Bug per il modello di processo Agile. Questo esempio definisce tre stati e cinque transizioni. Gli STATE elementi specificano gli stati Active, Resolved e Closed. Tutte le combinazioni possibili per le transizioni di progressione e regressione vengono definite per i tre stati, ad eccezione di uno. La transizione da Closed a Resolved non è definita. Pertanto, i membri del team non possono risolvere un elemento di lavoro di questo tipo se l'elemento di lavoro è chiuso.

Questo esempio non elenca tutti gli elementi per DEFAULTREASON, REASON, ACTIONe FIELD.

Diagramma dello stato del flusso di lavoro di esempio - Agile Bug WIT

<WORKFLOW>
 <STATES>
    <STATE value="Active">
      <FIELDS> . . . </FIELDS>
    </STATE>
    <STATE value="Resolved">
     <FIELDS> . . . </FIELDS>
    </STATE>
    <STATE value="Closed">
     <FIELDS> . . . </FIELDS>
    </STATE>
 </STATES>
 <TRANSITIONS>
    <TRANSITION from="" to="Active">
       <REASONS>
          <REASON value="Build Failure" />
           <DEFAULTREASON value="New" />
       </REASONS>
       <FIELDS> . . . </FIELDS>
    </TRANSITION>
    <TRANSITION from="Active" to="Resolved">
     <ACTIONS> . . . </ACTIONS>
     <REASONS> . . . </REASONS>
    </TRANSITION>
    <TRANSITION from="Resolved" to="Active">
       <REASONS> . . . </REASONS>
    </TRANSITION>
    <TRANSITION from="Resolved" to="Closed">
       <REASONS>
          <DEFAULTREASON value="Verified" />
       </REASONS>
     <FIELDS> . . . </FIELDS>
    </TRANSITION>
    <TRANSITION from="Closed" to="Active">
       <REASONS>
          <REASON value="Reactivated" />
          <DEFAULTREASON value="Regression" />
       </REASONS>
     <FIELDS> . . . </FIELDS>
    </TRANSITION>
 </TRANSITIONS>
 </WORKFLOW>

Determinare il numero e i tipi di stati

Decidere il numero e i tipi di stati validi in base al numero di stati logici distinti in cui si desidera che gli elementi di lavoro di quel tipo esistano. Inoltre, se membri del team diversi eseguono azioni diverse, è consigliabile definire uno stato in base a un ruolo membro. Ogni stato corrisponde a un'azione che un membro del team deve eseguire sull'elemento di lavoro per spostarlo nello stato successivo. Per ogni stato, definire le azioni specifiche e i membri del team autorizzati a eseguire tali azioni.

La tabella seguente fornisce un esempio di quattro stati che tengono traccia dello stato di avanzamento di una funzionalità e degli utenti validi che devono eseguire le azioni indicate:

Definire le transizioni

È possibile controllare gli stati da e verso cui i membri del team possono modificare un elemento di lavoro definendo le progressione e le regressioni di stato valide. Se non si definisce una transizione da uno stato a un altro stato, i membri del team non possono modificare un elemento di lavoro di un determinato tipo da uno stato specifico a un altro stato specifico.

La tabella seguente definisce le transizioni valide per ognuno dei quattro stati descritti in precedenza in questo argomento, insieme al motivo predefinito per ognuno di essi.

È possibile limitare gli utenti autorizzati a eseguire una transizione da uno stato a un altro usando gli attributi per e non dell'elemento TRANSITION . Come illustrato nell'esempio seguente, i tester possono riaprire un bug, ma gli sviluppatori non possono.

<TRANSITION from="Closed" to="Active"  
   for="[Project]\Testers"  
   not="[Project]\Developers">  
   . . .  
</TRANSITION>  

Specificare i motivi

Quando un membro del team modifica il campo Stato, può mantenere il motivo predefinito per tale transizione o specificare un motivo diverso se si definiscono opzioni aggiuntive. Utilizzare l'elemento DEFAULTREASON per specificare un solo motivo predefinito. Aggiungere altri motivi solo se aiutano il team a tenere traccia o a segnalare i dati.

Ad esempio, uno sviluppatore può specificare uno dei motivi seguenti quando risolve un bug: Corretto (impostazione predefinita), Posticipato, Duplicato, Come progettato, Non è possibile riprodurre o Obsoleto. Ogni motivo specifica un'azione specifica che il tester deve eseguire per quanto riguarda il bug.

L'esempio seguente illustra gli elementi che definiscono i motivi per cui un membro del team potrebbe risolvere un bug:

<TRANSITION from="Active" to="Resolved">  
      . . .  
      <REASONS>  
      <DEFAULTREASON value="Fixed"/>  
      <REASON value="Deferred"/>  
      <REASON value="Duplicate"/>  
      <REASON value="As Designed"/>  
      <REASON value="Unable to Reproduce"/>  
      <REASON value="Obsolete"/>  
      </REASONS>  
      . . .  
</TRANSITION>  

Specificare le azioni

In generale, i membri del team modificano lo stato di un elemento di lavoro specificando un valore diverso per il campo Stato e quindi salvando l'elemento di lavoro. Tuttavia, è anche possibile definire un ACTION elemento che modifica automaticamente lo stato di un elemento di lavoro quando si verifica tale transizione. Come illustrato nell'esempio seguente, è possibile specificare che gli elementi di lavoro relativi ai bug devono essere risolti automaticamente se sono associati ai file che uno sviluppatore inserisce nel sistema di controllo della versione.

<TRANSITION from="Active" to="Resolved">  
      <ACTIONS>  
      <ACTION value="Microsoft.VSTS.Actions.Checkin"/>  
      </ACTIONS>  
. . .  
</TRANSITION>  

Usare l'elemento ACTION per modificare automaticamente lo stato degli elementi di lavoro di un particolare tipo quando si verificano eventi altrove in Microsoft Visual Studio Application Lifecycle Management o all'esterno di Visual Studio Application Lifecycle Management(ad esempio, da uno strumento che tiene traccia delle chiamate). Per altre informazioni, vedere ACTION.

Aggiornare un campo durante una modifica del flusso di lavoro

È possibile definire regole che aggiornano i campi ogni volta che si verificano gli eventi seguenti:

• Assegnare una regola relativa al campo sotto STATE quando si desidera che la regola si applichi a tutte le transizioni e ai motivi di accesso a quello stato.

• Assegnare una regola di campo in TRANSITION quando si desidera che la regola si applichi a tale transizione e a tutti i motivi per effettuare tale transizione.

• Assegnare una regola di campo in DEFAULTREASON o REASON quando si desidera che le regole si applichino solo per quel motivo specifico.

  Se un campo deve contenere sempre lo stesso valore, definire la regola sotto l'elemento FIELD che definisce tale campo. Per altre informazioni sull'utilizzo delle regole, vedere Regole e valutazione delle regole.

  Ridurre al minimo il numero di condizioni definite per qualsiasi tipo di elemento di lavoro. Ogni regola condizionale aggiunge complessità al processo di convalida che si verifica ogni volta che un membro del team salva un elemento di lavoro. I set di regole complessi potrebbero aumentare il tempo necessario per salvare l'elemento di lavoro.

  Gli esempi seguenti illustrano alcune delle regole applicate ai campi di sistema nel modello di processo per MSF Agile Software Development.

Modificare il valore di un campo quando lo stato cambia

Quando si imposta il valore del campo Stato per un elemento di lavoro su Attivo e si salva l'elemento di lavoro, i valori dei campi Attivato da e Assegnato a vengono impostati automaticamente sul nome dell'utente corrente. L'utente deve essere membro del gruppo Team Foundation Server Utenti validi. Il valore del campo Data di Attivazione viene impostato automaticamente. L'esempio seguente illustra gli elementi che applicano questa regola:

<STATE value="Active">  
<FIELDS>  
      <FIELD refname="Microsoft.VSTS.Common.ActivatedBy">  
      <COPY from="currentuser"/>  
      <VALIDUSER/>  
      <REQUIRED/>  
      </FIELD>  
      <FIELD refname="Microsoft.VSTS.Common.ActivatedDate">  
      <SERVERDEFAULT from="clock"/></FIELD>  
      <FIELD refname="System.AssignedTo">  
      <DEFAULT from="currentuser"/>  
      </FIELD>  
. . .  
</FIELDS>  
</STATE>  

Cancellare il valore di un campo quando il valore di un altro campo cambia

Quando si imposta il valore del campo State per un elemento di lavoro su Attivo e si salva l'elemento di lavoro, l'elemento EMPTY imposta automaticamente i campi Closed Date e Closed By su null e li rende di sola lettura, come illustrato nell'esempio seguente.

<STATE value="Active">  
      <FIELDS>  
. . .  
      <FIELD refname="Microsoft.VSTS.Common.ClosedDate"><EMPTY/></FIELD>  
      <FIELD refname="Microsoft.VSTS.Common.ClosedBy"><EMPTY/></FIELD>  
      </FIELDS>  
</STATE>  

Definire un campo in base al contenuto di un altro campo

Quando si modifica il valore del campo Stato per un elemento di lavoro in Risolto e si salva l'elemento di lavoro, il valore del campo Motivo risolto viene impostato sul valore specificato dall'utente nel campo Motivo . L'esempio seguente illustra gli elementi che applicano questa regola:

<STATE value="Resolved">  
      <FIELDS>  
. . .  
      <FIELD refname="Microsoft.VSTS.Common.ResolvedReason">  
         <COPY from="field" field="System.Reason"/>  
      </FIELD>  
      </FIELDS>  
</STATE>  

Contenuti correlati

• Stati del flusso di lavoro e categorie di stato
• Personalizzare l'esperienza di monitoraggio del lavoro
• Eseguire query in base alle modifiche di assegnazione, flusso di lavoro o scheda
• Progettare il modulo dell'elemento di lavoro
• Importare, esportare e gestire i tipi di elementi di lavoro

Supporto degli strumenti

Per consentire agli utenti di visualizzare il flusso di lavoro, installare l'estensione Visualizzazione Modello di Stato dal Visual Studio Marketplace.