Progettazione del flusso di lavoro

Il flusso di lavoro per un tipo di elemento di lavoro viene progettato per supportare le operazioni aziendali e i processi del team. Il flusso di lavoro determina la progressione logica delle attività che verranno eseguite e chi è incaricato di tali attività. Si definisce il flusso di lavoro identificando prima gli stati e le transizioni valide tra gli stati. La sezione WORKFLOW della definizione per il tipo di elemento di lavoro definisce gli stati, le transizioni e i motivi per le transizioni validi, nonché le azioni facoltative che saranno eseguite quando un membro del team modifica lo stato di un elemento di lavoro. Per ulteriori informazioni sulle definizioni di tipi, vedere Riferimento a tutti gli elementi XML WITD.

In generale, ciascuno stato viene associato a un ruolo di membro del team e a un'attività che una persona che riveste tale ruolo deve eseguire per elaborare l'elemento di lavoro prima di modificarne lo stato. Le transizioni definiscono le progressioni e le 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 un altro, mentre le azioni supportano l'automazione della transizione di un elemento di lavoro a un punto nel flusso di lavoro.

Ad esempio, lo stato viene impostato su Attivo quando un tester apre un nuovo bug basato sul modello di processo di Microsoft Solutions Framework (MSF) per Agile Software Development 5.0. Dopo aver corretto il bug, lo sviluppatore imposta lo stato su Risolto, quindi imposta il valore del campo Motivo su Corretto. Dopo aver verificato la correzione, il tester imposta lo stato del bug su Chiuso, quindi lascia il valore del campo Motivo impostato su Corretto. Se il tester determinasse che lo sviluppatore non ha corretto il bug, imposterebbe lo stato del bug su Attivo e specificherebbe come Motivo Risoluzione negata o Test non riuscito.

Nota

È possibile creare e modificare le definizioni per tipi di elemento di lavoro e per altri oggetti per tenere traccia degli elementi di lavoro utilizzando l'Editor di processo (Process Editor), un power tool per Visual Studio. Questo strumento non è supportato. Per ulteriori informazioni, vedere la pagina seguente sul sito Web Microsoft: Power Tool di Team Foundation Server, aprile 2010.

In questo argomento

• Linee guida per la progettazione del flusso di lavoro

• Diagramma di flusso di lavoro ed esempio di codice

• Determinare il numero e i tipi di stati

• Definizione delle transizioni

  • Specifica dei motivi

  • Specifica delle azioni

• Aggiornamento di un campo quando lo stato viene modificato

  • Definizione di un campo quando lo stato viene modificato

  • Cancellazione del valore di un campo.

  • Definizione di un campo basato sul contenuto di un altro campo

• Visualizzazione del diagramma di stato del flusso di lavoro

Linee guida per la progettazione del flusso di lavoro

Per la progettazione o la modifica di un flusso di lavoro, considerare le linee guida riportate di seguito:

• Tramite l'elemento STATE, si definisce 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, verranno elencati in ordine alfanumerico nell'elenco Stati.

• Tramite l'elemento TRANSITION, si definisce una transizione per ogni progressione e regressione valida da uno stato a un altro.

• Come minimo, è necessario definire una transizione per ogni stato, oltre alla transizione dallo stato Null allo stato iniziale.

• Per ogni transizione, è necessario definire un motivo predefinito tramite l'elemento DEFAULTREASON. È possibile definire quanti motivi facoltativi si desiderano tramite l'elemento REASON.

• È possibile definire una sola 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 che devono essere eseguite in base a quanto si definisce per lo stato e la transizione selezionati. Gli utenti possono specificare solo gli stati validi in base alle transizioni che si definiscono per lo stato corrente. Inoltre, un elemento ACTION, figlio dell'elemento TRANSITION, può modificare lo stato di un elemento di lavoro.

• È possibile definire regole condizionali per qualsiasi campo 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 complemento delle regole condizionali che possono essere applicate quando si definiscono i campi nella sezione FIELDS sotto la definizione WORKITEMTYPE. Per ulteriori informazioni, vedere Aggiornamento dei campi quando lo stato viene modificato più avanti in questo argomento.

• È necessario tentare di ridurre al minimo il numero di condizioni che si definiscono per un qualsiasi 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.

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

Torna all'inizio

Diagramma di flusso di lavoro ed esempio di codice

Nella tabella seguente viene mostrata la sezione WORKFLOW della definizione per un tipo di elemento di lavoro che rileva i difetti del codice, nonché il diagramma di stato del flusso di lavoro che definisce. In questo esempio vengono definiti tre stati, sei transizioni e nove motivi. Gli elementi STATE specificano gli stati Attivo, Risolto e Chiuso. Vengono definite tutte le possibili combinazioni delle transizioni di progressione e di regressione per i tre stati, salvo una. La transizione da Chiuso a Risolto non è definita. Pertanto, i membri del team non possono risolvere un elemento di lavoro di questo tipo se l'elemento di lavoro è chiuso.

Nota

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" /> </STATES> <TRANSITIONS>   <TRANSITION from="" to="Active">     <REASONS>       <DEFAULTREASON value="New" />     </REASONS>     <FIELDS> . . . </FIELDS>   </TRANSITION>   <TRANSITION from="Active" to="Resolved">     <REASONS> . . . </REASONS>     <FIELDS> . . . </FIELDS>     < ACTIONS > . . . </ ACTIONS > </TRANSITION> <TRANSITION from="Resolved" to="Closed">     <REASONS> . . . </REASONS>     <FIELDS> . . . </FIELDS>     < ACTIONS > . . . </ ACTIONS > </TRANSITION> <TRANSITION from="Resolved" to="Active">     <REASONS> . . . </REASONS>     <FIELDS> . . . </FIELDS> </TRANSITION> <TRANSITION from="Active" to="Closed ">     <REASONS> . . . </REASONS>     <FIELDS> . . . </FIELDS> </TRANSITION> <TRANSITION from="Closed" to="Active">     <REASONS> . . . </REASONS>     <FIELDS> . . . </FIELDS> </TRANSITION> </TRANSITIONS> </WORKFLOW>

Esempio di Diagramma di stato del flusso di lavoro

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 desidera che gli elementi di lavoro di tale tipo esistano. Inoltre, se membri del team diversi eseguono azioni diverse, è possibile considerare di 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.

Nella tabella riportata di seguito viene fornito un esempio di quattro stati, definiti per tenere traccia dello stato di avanzamento di una funzionalità, e gli 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 di una funzionalità. Tuttavia, solo i responsabili del progetto possono approvare o disapprovare l'elemento di lavoro. Se un responsabile del progetto approva una funzionalità, imposterà lo stato dell'elemento di lavoro su Attivo; in caso contrario, un membro del team lo chiuderà.
Active	Coordinatore dello sviluppo	Il coordinatore dello sviluppo supervisiona lo sviluppo della funzionalità. Quando la funzionalità viene completata, il coordinatore dello sviluppo imposta lo stato dell'elemento di lavoro della funzionalità su Revisione.
Revisione	Responsabile di progetto	Il responsabile del progetto esamina la funzionalità che il team ha implementato e imposta lo stato dell'elemento di lavoro su Chiuso se l'implementazione è soddisfacente.
Closed	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 rapporti.

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.

Torna all'inizio

Definizione delle 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 un particolare stato su un altro particolare stato.

Nella tabella riportata di seguito vengono definite le transizioni valide per ognuno dei quattro stati descritti precedentemente in questo argomento, insieme con il motivo predefinito per ciascuna transizione.

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

È possibile limitare i membri a cui è consentito effettuare una transizione da uno stato a un altro utilizzando gli attributi for e not 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>

Torna all'inizio

Specifica dei 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 utilizzare l'elemento DEFAULTREASON per specificare un e solo un motivo predefinito. È opportuno specificare motivi aggiuntivi solo se consentono al team di tenere traccia o di creare rapporti 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.

Nell'esempio riportato di seguito vengono mostrati 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>

Torna all'inizio

Specifica delle 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 automaticamente modifica lo stato di un elemento di lavoro quando si verifica quella specifica transizione. Come illustrato nell'esempio riportato di seguito, è 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 utilizzare 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 rileva le chiamate). Per ulteriori informazioni, vedere Automazione delle assegnazioni dei campi in base a stato, transizione o causa.

Torna all'inizio

Aggiornamento di un campo

È possibile definire regole che aggiornano i campi ogni qualvolta si verificano gli eventi riportati di seguito:

• Assegnare una regola del campo sotto STATE quando si desidera che la regola venga applicata per tutte le transizioni e per tutti motivi per il passaggio a tale stato.

• Assegnare una regola del campo sotto TRANSITION quando si desidera che la regola venga applicata per tale specifica transizione e per tutti motivi per l'esecuzione di tale transizione.

• Assegnare una regola del campo sotto DEFAULTREASON o REASON quando si desidera che le regole vengano applicate solo per tale motivo specifico.

Se un campo deve contenere sempre lo stesso valore, si definisce la regola sotto l'elemento FIELD che definisce quel campo. Per ulteriori informazioni, vedere Impostazione di condizioni su un campo elemento di lavoro.

Negli esempi riportati di seguito vengono illustrate alcune delle regole applicate ai campi di sistema nel modello di processo per MSF Agile Software Development v5.0.

• Modifica del valore di un campo al cambiamento dello stato

• Cancellazione del valore di un campo al cambiamento del valore di un altro campo

• Definizione di un campo basato sul contenuto di un altro campo

Torna all'inizio

Modifica del 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 Team Foundation Server. Viene inoltre impostato automaticamente il valore del campo Data attivazione. Nell'esempio riportato di seguito vengono illustrati 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>

Torna all'inizio

Cancellazione del valore di un campo al cambiamento del 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 utilizza l'elemento EMPTY, 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>

Torna all'inizio

Definizione di un campo basato sul 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 risoluzione viene impostato sul valore specificato dall'utente nel campo Motivo. Nell'esempio riportato di seguito vengono illustrati 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>

Torna all'inizio

Visualizzazione del diagramma di stato del flusso di lavoro

È possibile visualizzare la definizione del flusso di lavoro di qualsiasi tipo di elemento di lavoro se si utilizza Team Web Access per aprire il diagramma di stato per qualsiasi elemento di lavoro di tale tipo. Per ulteriori informazioni, vedere Gestione del lavoro tramite Team Web Access.

Suggerimento
È inoltre possibile visualizzare il diagramma di stato del flusso di lavoro che si definisce utilizzando l'Editor di processo, un power tool per Visual Studio. Questo strumento non è supportato. Per ulteriori informazioni, vedere la pagina seguente sul sito Web Microsoft: Power Tool di Team Foundation Server, aprile 2010.

Torna all'inizio

Vedere anche

Altre risorse

Definizione e personalizzazione del flusso di lavoro degli elementi di lavoro

Cronologia delle modifiche

Data	Cronologia	Motivo
Gennaio 2011	Spostata la tabella di elementi WORKFLOW in un nuovo argomento, Riferimento a tutti gli elementi XML WORKFLOW.	Miglioramento delle informazioni.
Luglio 2010	Completamente riscritto per fornire ulteriori informazioni, esempi e un riepilogo di tutti gli elementi WORKFLOW e degli attributi relativi.	Miglioramento delle informazioni.