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

  • Articolo

Azure DevOps Server 2022 - Azure DevOps Server 2019

È possibile 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 verranno eseguiti dai membri del team. 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)

Flusso di lavoro degli elementi di backlog del prodotto, processo Scrum

Nota

Questo articolo descrive come personalizzare uno stato del flusso di lavoro. Se invece si vuole modificare lo stato assegnato a un elemento di lavoro specifico, vedere uno degli articoli seguenti: scheda Kanban, Tenere traccia del lavoro in corso o Scheda attività, Aggiornare lo stato dell'attività. È anche possibile eseguire un aggiornamento bulk dello stato per molti elementi di lavoro.

Per informazioni sui flussi di lavoro della pipeline di compilazione, vedere Introduzione a CI/CD.

Aggiornare la definizione XML per un tipo di elemento di lavoro

Se non si ha ancora una volta la personalizzazione di WIT, tenere presente quanto segue:

  • Per personalizzare qualsiasi aspetto di un tipo di elemento di lavoro, è necessario aggiornarne la definizione XML. La definizione XML è descritta in Informazioni di riferimento su tutti gli elementi XML WITD
  • Se si personalizza il web form che usa la nuova esperienza dell'elemento di lavoro, è necessario fare riferimento agli elementi WebLayout e Control
  • Se si personalizza un modulo client da usare con Visual Studio, è necessario fare riferimento al riferimento all'elemento XML layout
  • Seguire la sequenza di passaggi descritti in Personalizzare il web form di rilevamento 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 eseguire il mapping dei nuovi stati del flusso di lavoro ai metastate.

    Questo secondo passaggio è necessario quando si modifica il flusso di lavoro per un WIT visualizzato in una pagina degli strumenti Agile. Questi tipi di criteri di accesso utente 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

Per definire il flusso di lavoro, identificare 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 che verranno eseguite quando un membro del team modifica lo stato di un elemento di lavoro.

In generale, ogni stato viene associato a un ruolo membro del team e a un'attività che deve essere eseguita da una persona in tale ruolo 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, lo stato è impostato 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 eseguirà 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 elencati 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 lavagna nel portale Web, è anche necessario eseguire il mapping dello 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.

    È necessario 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, viene assegnato 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, si definisce 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 verranno applicate 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 assegnati a stati e 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 per WORKFLOW la definizione bug WIT 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

Stati del flusso di lavoro di bug, modello di processo Agile

<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

È possibile determinare 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 tale tipo esistano. Inoltre, se diversi membri del team eseguono azioni diverse, è possibile valutare la possibilità di 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, è necessario definire le azioni specifiche e i membri del team autorizzati a eseguire tali azioni.

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

Provincia Utente valido Action to perform
Proposto Responsabile di progetto Chiunque può creare un elemento di lavoro di funzionalità. Tuttavia, solo i project manager possono approvare o annullare l'approvazione dell'elemento di lavoro. Se un project manager approva una funzionalità, il project manager modifica lo stato dell'elemento di lavoro su Attivo; in caso contrario, un membro del team lo chiude.
Attive Responsabile dello sviluppo Il responsabile dello sviluppo supervisiona lo sviluppo della funzionalità. Al termine della funzionalità, il responsabile dello sviluppo modifica lo stato dell'elemento di lavoro della funzionalità in Rivedi.
Revisione Responsabile di progetto Il project manager esamina la funzionalità implementata dal team e modifica lo stato dell'elemento di lavoro su Chiuso se l'implementazione è soddisfacente.
Chiusa Responsabile di progetto Non è prevista alcuna azione aggiuntiva sugli elementi di lavoro chiusi. Questi elementi rimangono nel database per scopi di archiviazione e creazione di report.

Nota

Tutti gli stati vengono visualizzati in ordine alfabetico nell'elenco del modulo per un elemento di lavoro di un particolare tipo, indipendentemente dalla sequenza in cui vengono specificate.

Definire le transizioni

È possibile controllare gli stati da e verso cui i membri del team possono modificare un elemento di lavoro se si definiscono 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.

Provincia Transizione allo stato Motivo predefinito
Proposto Attivo (progressione) Approvato per lo sviluppo
Chiuso (progressione) Non approvato
Attive Revisione (progressione) Criteri di accettazione soddisfatti
Revisione Chiuso (progressione) Funzionalità completa
Attivo (regressione) Non soddisfa i requisiti
Chiusa Proposta (regressione) Riconsiderare l'approvazione
Attivo (regressione) Chiuso in errore

È 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, tale utente può mantenere il motivo predefinito per tale transizione o specificare un motivo diverso se si definiscono opzioni aggiuntive. È necessario utilizzare l'elemento DEFAULTREASON per specificare un solo motivo predefinito. È consigliabile specificare motivi aggiuntivi 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.

Nota

Tutti i motivi vengono visualizzati in ordine alfabetico nell'elenco nel modulo di lavoro per gli elementi di lavoro di un particolare tipo, indipendentemente dalla sequenza in cui si specificano gli REASON elementi.

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 dei bug devono essere risolti automaticamente se sono associati ai file controllati da uno sviluppatore nel controllo della versione:

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

È possibile 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 di campo in STATE quando si desidera che la regola si applichi a tutte le transizioni a e motivi per l'immissione di tale stato.

  • Assegnare una regola di campo in TRANSITION quando si desidera che la regola si applichi per tale transizione e per tutti i motivi per eseguire 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.

    È consigliabile provare a ridurre al minimo il numero di condizioni definite per qualsiasi tipo di elemento di lavoro. Con ogni regola condizionale aggiunta, si aumenta la complessità del processo di convalida che si verifica ogni volta che un membro del team salva un elemento di lavoro. I set di regole complessi possono 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 il valore del campo Stato per un elemento di lavoro è impostato su Attivo e l'elemento di lavoro viene salvato, 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 attivata 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 il valore del campo State per un elemento di lavoro è impostato su Attivo e l'elemento di lavoro viene salvato, i campi Closed Date e Closed By vengono automaticamente impostati su Null e resi di sola lettura se si utilizza l'elemento, come illustrato nell'esempio EMPTY 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 il valore del campo Stato per un elemento di lavoro viene modificato in Risolto e l'elemento di lavoro viene salvato, 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>

Supporto degli strumenti

È possibile supportare gli utenti per visualizzare il flusso di lavoro installando l'estensione Visualizzazione modello di stato da Visual Studio Marketplace.