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

È possibile modificare il flusso di lavoro per un tipo di elemento di lavoro per supportare processi dell'azienda e del team. I tipi di elemento di lavoro supportano il rilevamento di tutti i tipi di lavoro (requisiti, attività, difetti di codice) per supportare lo sviluppo software con Team Foundation Server (TFS).

Il flusso di lavoro determina la progressione e regressione logica del lavoro che verrà eseguito dai membri del team. Specifica anche i valori che vengono visualizzati nei menu a discesa dei campi Motivo e Stato.

Flusso di lavoro per Elemento del Backlog di Prodotto (modello di processo Scrum)

Per una panoramica degli stati predefiniti del flusso di lavoro supportati nei modelli di processo predefiniti forniti da TFS, vedere Utilizzare elementi del progetto team, scegliere un modello di processo. Per informazioni sul flusso di lavoro di definizione di compilazione, vedere Personalizzare il modello del processo di compilazione.

Linee guida di progettazione del flusso di lavoro

Per definire il flusso di lavoro, occorre prima di tutto identificare gli stati e le transizioni valide tra di essi. La sezione WORKFLOW della definizione del tipo di elemento di lavoro specifica gli stati validi, le transizioni, i motivi per le transizioni e le azioni facoltative da eseguire quando un membro del team modifica lo stato di un elemento di lavoro.

In generale, ogni stato viene associato a un ruolo di membro del team e a un'attività che un utente con tale ruolo deve eseguire per elaborare l'elemento di lavoro prima di modificare il relativo stato. Le transizioni definiscono le progressioni e regressioni valide tra gli stati. I motivi identificano le ragioni per cui un membro del team modifica un elemento di lavoro da uno stato a altro e le azioni supportano l'automazione della transizione di un elemento di lavoro in un punto nel flusso di lavoro.

Ad esempio, lo stato è impostato su Nuovo quando un tester apre un nuovo bug basato sul modello di processo Agile predefinito fornito da Team Foundation Server (TFS). Lo sviluppatore imposta lo stato su Attivo quando corregge il bug e al termine della correzione lo imposta su Risolto e imposta il valore del campo Motivo su Corretto. Dopo aver verificato la correzione, il tester imposta lo stato del bug su Chiuso e il campo Motivo su Verificato. Se il tester determinasse che lo sviluppatore non ha corretto il bug, imposterebbe lo stato del bug su Attivo e specificherebbe come Motivo Non corretto o Test non superato.

Per la progettazione o la modifica di un flusso di lavoro, tenere presenti le linee guida seguenti:

• Usare l'elemento STATE per definire uno stato univoco per ogni ruolo di membro del team che eseguirà una specifica azione su un elemento di lavoro. Quanti più stati si definiscono, tante più transizioni è necessario definire. Indipendentemente dalla sequenza con cui vengono definiti, gli stati sono elencati in ordine alfanumerico nel menu a discesa del campo Stato.

  Se si aggiunge uno stato a un tipo di elemento di lavoro visualizzato nelle pagine di backlog o dell'area in Team Web Access, è necessario anche mappare lo stato a un metastato. Vedere Riferimento all'elemento XML di configurazione del processo.

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

  Come minimo, è necessario definire una transizione per ogni stato e la transizione dallo stato null allo stato iniziale.

  È possibile definire solo una transizione dallo stato non assegnato (null) allo stato iniziale. Quando si salva un nuovo elemento di lavoro, gli viene assegnato automaticamente lo stato iniziale.

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

• Per ogni transizione, definire un motivo predefinito usando l'elemento DEFAULTREASON. È possibile definire quanti motivi facoltativi si desiderano tramite l'elemento REASON. Questi valori sono visualizzati nel menu a discesa del campo Motivo.

• È possibile specificare le regole che verranno applicate quando l'elemento di lavoro cambia di stato o effettua transizioni oppure quando un utente seleziona un motivo specifico. Molte di queste regole rappresentano un'integrazione delle regole condizionali che possono essere applicate quando si definiscono i campi nella sezione FIELDS nella definizione WORKITEMTYPE. Per altre informazioni, vedere la sezione relativa all'aggiornamento di un campo durante una modifica del flusso di lavoro più avanti in questo argomento.

• I nomi che si assegnano a stati e motivi non fanno distinzione tra maiuscole e minuscole.

  I menu a discesa dei campi Stato e Motivo, all'interno del form elemento di lavoro o di un editor di query, includono i valori assegnati nella sezione WORKFLOW del tipo di elemento di lavoro.

Diagramma del flusso di lavoro e codice di esempio

Il seguente esempio di codice mostra la sezione WORKFLOW della definizione del tipo di elemento di lavoro Bug per il modello di processo Agile. Questo esempio definisce tre stati e cinque transizioni. Gli elementi STATE specificano gli stati Attivo, Risolto e Chiuso. Sono definite tutte le possibili combinazioni per le transizioni di progressione e di regressione per i tre stati, tranne una. La transizione da Chiuso a Risolto non è definita. Di conseguenza, i membri del team non possono risolvere un elemento di lavoro di questo tipo se l'elemento di lavoro è chiuso.

Nell'esempio non sono elencati gli elementi per DEFAULTREASON, REASON, ACTION e FIELD.

<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>

Esempio di diagramma di stato del flusso di lavoro – Tipo di elemento di lavoro Bug di Agile

Determinare il numero e i tipi di stati

Il numero e tipi di stati validi vengono determinati in base al numero di stati logici distinti in cui si vuole che esistano gli elementi di lavoro di tale tipo. Inoltre, se diversi membri del team eseguono azioni diverse, è possibile definire uno stato basato su un ruolo di membro. Ogni stato corrisponde a un'azione che un membro del team deve eseguire sull'elemento di lavoro per impostarlo sullo stato successivo. Per ogni stato, è necessario definire le azioni specifiche e i membri del team a cui è consentito eseguire tali azioni.

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

Stato	Utente valido	Azione da eseguire
Proposto	Responsabile di progetto	Chiunque può creare un elemento di lavoro funzionalità. Tuttavia, solo i responsabili di progetto possono approvare o disapprovare l'elemento di lavoro. Se un responsabile di progetto approva una funzionalità, imposterà lo stato dell'elemento di lavoro su Attivo; in caso contrario, un membro del team lo chiuderà.
Attivo	Responsabile dello sviluppo	Il responsabile dello sviluppo supervisiona lo sviluppo della funzionalità. Quando la funzionalità viene completata, il responsabile dello sviluppo imposta lo stato dell'elemento di lavoro funzionalità su Revisione.
Verifica	Responsabile di progetto	Il responsabile di progetto esamina la funzionalità che il team ha implementato e imposta lo stato dell'elemento di lavoro su Chiuso se l'implementazione è soddisfacente.
Chiuso	Responsabile di progetto	Sugli elementi di lavoro chiusi non è prevista l'esecuzione di alcuna azione aggiuntiva. Questi elementi rimangono nel database per fini di archiviazione e di creazione di report.

Nota

Tutti gli stati vengono visualizzati in ordine alfabetico nell'elenco sul form per un elemento di lavoro di un particolare tipo, indipendentemente dalla sequenza in cui sono stati specificati.

Definire le transizioni

È possibile controllare gli stati di origine e destinazione su cui i membri del team possono impostare un elemento di lavoro se si definiscono progressioni e regressioni di stato valide. Se non si definisce una transizione da uno stato a un altro stato, i membri del team non possono impostare un elemento di lavoro di un particolare tipo da uno stato a altro.

La tabella seguente illustra le transizioni valide per ognuno dei quattro stati descritti precedentemente in questo argomento, insieme al motivo predefinito per ciascuna transizione.

Stato	Stato di destinazione della transizione	Motivo predefinito
Proposto	Attivo (progressione)	Approvato per lo sviluppo
	Chiuso (progressione)	Non approvato
Attivo	Revisione (progressione)	Criteri di accettazione soddisfatti
Verifica	Chiuso (progressione)	Funzionalità completata
	Attivo (regressione)	Non soddisfa i requisiti
Chiuso	Proposto (regressione)	Riconsiderare per l'approvazione
	Attivo (regressione)	Chiuso per errore

È possibile limitare i membri a cui è consentito effettuare una transizione da uno stato a un altro mediante gli attributi for e not dell'elemento TRANSITION. Come mostrato nell'esempio seguente, un bug può essere riaperto dai tester ma non dagli sviluppatori.

<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 oppure specificare un motivo diverso se si definiscono opzioni aggiuntive. È necessario usare l'elemento DEFAULTREASON per specificare solo un motivo predefinito. È opportuno specificare motivi aggiuntivi solo se consentono al team di tenere traccia o di creare report dei dati.

Ad esempio, uno sviluppatore può specificare uno dei motivi seguenti quando risolve un bug: Corretto (Impostazione predefinita), Posticipato, Duplicato, Come da progetto, Non riproducibile o Obsoleto. Ogni motivo specifica una particolare azione che il tester deve eseguire relativamente al bug.

Nota

Tutti i motivi vengono visualizzati in ordine alfabetico nell'elenco sul form di lavoro per gli elementi di lavoro di un particolare tipo, indipendentemente dalla sequenza in cui gli elementi REASON sono stati specificati.

L'esempio seguente mostra 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 salvando quindi l'elemento di lavoro. Tuttavia, è anche possibile definire un elemento ACTION che modifica automaticamente lo stato di un elemento di lavoro quando si verifica quella specifica transizione. Come mostrato nell'esempio seguente, è possibile specificare che gli elementi di lavoro bug devono essere risolti automaticamente se vengono associati a file che uno sviluppatore archivia 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 al di fuori di Visual Studio Application Lifecycle Management, ad esempio da uno strumento che tiene traccia delle chiamate. Per altre informazioni, vedere Rendere automatiche le assegnazioni dei campi in base a stato, transizione o motivo.

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 vuole che la regola sia applicabile a tutte le transizioni e a tutti motivi per il passaggio a tale stato.

• Assegnare una regola di campo in TRANSITION quando si vuole che la regola sia applicabile alla transizione specifica e a tutti motivi per l'esecuzione della transizione.

• Assegnare una regola di campo in DEFAULTREASON o REASON quando si vuole che la regola sia applicabile solo al motivo specifico.

Se un campo deve contenere sempre lo stesso valore, si definisce la regola nell'elemento FIELD che definisce il campo. Per altre informazioni sull'uso delle regole, vedere Applicare una regola a un campo elemento di lavoro.

Cercare di ridurre al minimo il numero di condizioni definite per ogni tipo di elemento di lavoro. Con ogni regola condizionale che si aggiunge, aumenta la complessità del processo di convalida che viene eseguito ogni volta che un membro del team salva un elemento di lavoro. Set di regole complessi possono aumentare il tempo richiesto per salvare l'elemento di lavoro.

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

Modificare il valore di un campo al cambiamento dello stato

Quando il valore del campo Stato per un elemento di lavoro viene 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. Tale utente deve essere un membro del gruppo di utenti validi di Team Foundation Server. Viene impostato automaticamente anche il valore del campo Data di attivazione. L'esempio seguente mostra 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 cambia il valore di un altro campo

Quando il valore del campo Stato per un elemento di lavoro viene impostato su Attivo e l'elemento di lavoro viene salvato, i campi Data di chiusura e Chiuso da vengono automaticamente impostati su Null e resi di sola lettura se si usa l'elemento EMPTY, come mostrato 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 il valore del campo Stato per un elemento di lavoro viene impostato su Risolto e l'elemento di lavoro viene salvato, il valore del campo Motivo di risoluzione viene impostato sul valore specificato dall'utente nel campo Motivo. L'esempio seguente mostra 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>

Domande e risposte

D: Esiste uno strumento per modificare il flusso di lavoro o per visualizzare i diagrammi di stato del flusso di lavoro?

R: Sì. Per modificare il flusso di lavoro o visualizzare il diagramma di stato del flusso di lavoro che si sta definendo, è possibile usare l'Editor processo, uno degli strumenti Power Tools di Visual Studio. Per altre informazioni, vedere la pagina del sito Web Microsoft relativa ai Power tool di Team Foundation Server.

D: Dove è possibile ottenere una panoramica degli elementi XML di definizione del tipo di elemento di lavoro?

R: Vedere Riferimento a tutti gli elementi XML WITD.