Partager via

Modifier le flux de travail pour un type d'élément de travail

  • Article

Azure DevOps Server 2022 – Azure DevOps Server 2019

Vous pouvez modifier le flux de travail d’un type d’élément de travail (WIT) pour prendre en charge vos processus métier et d’équipe. Les WIT prennent en charge le suivi de tous les types de travail (exigences, tâches, défauts de code) pour prendre en charge le développement de logiciels.

Le flux de travail détermine la progression logique et la régression du travail que les membres de l’équipe effectueront. Il spécifie également les valeurs qui apparaissent dans les menus déroulants pour les champs État et Raison. Pour plus d’informations, consultez À propos des processus et des modèles de processus.

Flux de travail pour l’élément du backlog de produit (modèle de processus Scrum)

Flux de travail de l'élément de Backlog de produit, processus Scrum

Remarque

Cet article explique comment personnaliser un état de flux de travail. Si, au lieu de cela, vous souhaitez modifier l’état affecté à un élément de travail spécifique, consultez l’un des articles suivants : Tableau, Suivi du travail en cours ou Tableau des tâches, Mise à jour de l’état de la tâche. Vous pouvez également effectuer une mise à jour en bloc de l’état pour de nombreux éléments de travail.

Pour plus d’informations sur les flux de travail de pipeline de génération, consultez Prise en main de CI/CD.

Mettre à jour la définition XML d’un type d’élément de travail

Si vous débutez avec la personnalisation WIT, notez les points suivants :

Pour personnaliser le flux de travail, procédez comme suit :

  1. Modifiez la WORKFLOW section de la définition WIT, comme décrit dans cette rubrique.

  2. Modifiez la configuration du processus pour mapper les nouveaux états de flux de travail aux métastates.

    Cette deuxième étape est requise lorsque vous modifiez le flux de travail d’un WIT qui s’affiche sur une page d’outils Agile. Ces WIT appartiennent aux catégories Conditions requises ou Tâches. Pour plus d’informations sur les catégories d’état, consultez Les états de flux de travail et les catégories d’état.

Recommandations en matière de conception de flux de travail

Vous définissez le flux de travail en identifiant d’abord les états et les transitions valides entre eux. La WORKFLOW section de la définition WIT spécifie les états, les transitions, les raisons des transitions et les actions facultatives qui seront effectuées lorsqu’un membre de l’équipe modifie l’état d’un élément de travail.

En général, vous associez chaque état à un rôle membre d’équipe et une tâche qu’une personne dans ce rôle doit effectuer pour traiter l’élément de travail avant de modifier son état. Les transitions définissent les progressions et régressions valides entre les états. Les raisons d’identification d’un membre de l’équipe modifient un élément de travail d’un état à un autre, et les actions prennent en charge l’automatisation de la transition d’un élément de travail à un point dans le flux de travail.

Par exemple, l’état est défini sur Nouveau lorsqu’un testeur ouvre un nouveau bogue basé sur le processus Agile par défaut. Le développeur change l’état sur Actif lors de la résolution du bogue, et une fois résolu, le développeur change son état en Résolu et définit la valeur du champ Motif sur Résolu. Après avoir vérifié le correctif, le testeur modifie l’état du bogue sur Fermé et le champ Motif passe à Vérifié. Si le testeur a déterminé que le développeur n’avait pas corrigé le bogue, le testeur changeait l’état du bogue sur Actif et spécifie la raison comme Non résolu ou Échec du test.

Lorsque vous concevez ou modifiez un flux de travail, tenez compte des instructions suivantes :

  • Utilisez l’élément STATE pour définir un état unique pour chaque rôle membre d’équipe qui prendra une action spécifique sur un élément de travail. Plus vous définissez d’états, plus vous devez définir les transitions. Quelle que soit la séquence dans laquelle vous définissez les états, elles sont répertoriées dans l’ordre alphanumérique dans le menu déroulant du champ État .

    Si vous ajoutez un état à un type d’élément de travail qui apparaît sur le backlog ou les pages de tableau du portail web, vous devez également mapper l’état à une catégorie d’état. Pour plus d’informations, passez en revue les états de flux de travail et les catégories d’état.

  • Utilisez l’élément TRANSITION pour définir une transition pour chaque progression et régression valides d’un état à un autre.

    Au minimum, vous devez définir une transition pour chaque état et la transition de l’état null à l’état initial.

    Vous ne pouvez définir qu’une seule transition entre un état non attribué (null) et l’état initial. Lorsque vous enregistrez un nouvel élément de travail, il est automatiquement affecté à l’état initial.

    Lorsqu’un membre de l’équipe modifie l’état d’un élément de travail, cette modification déclenche la transition et les actions que vous définissez pour l’état sélectionné et la transition. Les utilisateurs peuvent spécifier uniquement les états valides en fonction des transitions que vous définissez pour l’état actuel. En outre, un ACTION élément, qui est un élément enfant, TRANSITIONpeut modifier l’état d’un élément de travail.

  • Pour chaque transition, vous définissez une raison par défaut à l’aide de l’élément DEFAULTREASON . Vous pouvez définir autant de raisons facultatives que vous le souhaitez à l’aide de l’élément REASON . Ces valeurs apparaissent dans le menu déroulant du champ Motif .

  • Vous pouvez spécifier des règles qui seront appliquées lorsque l’élément de travail change d’état, lorsqu’il passe ou lorsqu’un utilisateur sélectionne une raison spécifique. La plupart de ces règles complètent les règles conditionnelles que vous pouvez appliquer lorsque vous définissez les champs de la FIELDS section sous la WORKITEMTYPE définition. Pour plus d’informations, consultez Mettre à jour les champs lors d’une modification de flux de travail plus loin dans cette rubrique.

  • Les noms que vous attribuez à des états et des raisons ne respectent pas la casse.

    Les menus déroulants pour les champs État et Motif dans le formulaire d’élément de travail ou l’éditeur de requête affichent les valeurs affectées dans la WORKFLOW section du type d’élément de travail.

Diagramme de flux de travail et exemple de code

L’exemple de code suivant montre la WORKFLOW définition WIT de bogue pour le modèle de processus Agile. Cet exemple définit trois états et cinq transitions. Les STATE éléments spécifient les états Actif, Résolu et Fermé. Toutes les combinaisons possibles pour les transitions de progression et de régression sont définies pour les trois états, sauf un. La transition de Closed to Resolved n’est pas définie. Par conséquent, les membres de l’équipe ne peuvent pas résoudre un élément de travail de ce type si l’élément de travail est fermé.

Cet exemple ne répertorie pas tous les éléments pour DEFAULTREASON, REASON, ACTIONet FIELD.

Exemple de diagramme d’état du flux de travail – Bogue Agile WIT

États du flux de travail du bogue, modèle de processus 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>

Déterminer le nombre et les types d’états

Vous déterminez le nombre et les types d’états valides en fonction du nombre d’états logiques distincts dans lesquels vous souhaitez que les éléments de travail de ce type existent. En outre, si différents membres de l’équipe effectuent différentes actions, vous pouvez envisager de définir un état en fonction d’un rôle membre. Chaque état correspond à une action qu’un membre de l’équipe doit effectuer sur l’élément de travail pour le déplacer vers l’état suivant. Pour chaque état, vous devez définir les actions spécifiques et les membres de l’équipe autorisés à effectuer ces actions.

Le tableau suivant fournit un exemple de quatre états définis pour suivre la progression d’une fonctionnalité et les utilisateurs valides qui doivent effectuer les actions indiquées :

State Utilisateur valide Action to perform
Proposé Chef de projet Tout le monde peut créer un élément de travail de fonctionnalité. Toutefois, seuls les responsables de projet peuvent approuver ou désapprouver l’élément de travail. Si un responsable de projet approuve une fonctionnalité, le responsable de projet modifie l’état de l’élément de travail en actif ; sinon, un membre de l’équipe le ferme.
Activé Responsable développement Le responsable de développement supervise le développement de la fonctionnalité. Une fois la fonctionnalité terminée, le prospect de développement modifie l’état de l’élément de travail de fonctionnalité en révision.
Révision Chef de projet Le responsable de projet examine la fonctionnalité que l’équipe a implémentée et modifie l’état de l’élément de travail sur Fermé si l’implémentation est satisfaisante.
Fermée Chef de projet Aucune action supplémentaire n’est censée se produire sur les éléments de travail fermés. Ces éléments restent dans la base de données à des fins d’archivage et de création de rapports.

Remarque

Tous les états apparaissent par ordre alphabétique dans la liste du formulaire pour un élément de travail d’un type particulier, quelle que soit la séquence dans laquelle vous les spécifiez.

Définir des transitions

Vous contrôlez les états vers et à partir desquels les membres de l’équipe peuvent modifier un élément de travail si vous définissez les progressions et régressions d’état valides. Si vous ne définissez pas de transition d’un état à un autre état, les membres de l’équipe ne peuvent pas modifier un élément de travail d’un type particulier d’un état particulier à un autre état particulier.

Le tableau suivant définit les transitions valides pour chacun des quatre états décrits précédemment dans cette rubrique, ainsi que la raison par défaut de chacun d’eux.

State Transition vers l’état Raison par défaut
Proposé Actif (progression) Approuvé pour le développement
Fermé (progression) Non approuvée
Activé Révision (progression) Critères d’acceptation remplis
Révision Fermé (progression) Fonctionnalité terminée
Actif (régression) Ne répond pas aux exigences
Fermée Proposé (régression) Reconsidérer l’approbation
Actif (régression) Fermé dans l’erreur

Vous pouvez restreindre les personnes autorisées à effectuer une transition d’un état à l’autre à l’aide des attributs pour et non de l’élément TRANSITION . Comme l’illustre l’exemple suivant, les testeurs peuvent rouvrir un bogue, mais les développeurs ne peuvent pas.

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

Spécifier les raisons

Lorsqu’un membre de l’équipe modifie le champ État, cet utilisateur peut conserver la raison par défaut de cette transition ou spécifier une autre raison si vous définissez des options supplémentaires. Vous devez utiliser l’élément DEFAULTREASON pour spécifier une seule raison par défaut. Vous devez spécifier des raisons supplémentaires uniquement s’ils aident l’équipe à suivre ou à signaler les données.

Par exemple, un développeur peut spécifier l’une des raisons suivantes lorsqu’il résout un bogue : résolu (par défaut), différé, dupliqué, conçu, impossible de reproduire ou obsolète. Chaque raison spécifie une action particulière pour le testeur à effectuer en ce qui concerne le bogue.

Remarque

Toutes les raisons s’affichent par ordre alphabétique dans la liste du formulaire de travail pour les éléments de travail d’un type particulier, quelle que soit la séquence dans laquelle vous spécifiez les REASON éléments.

L’exemple suivant montre les éléments qui définissent les raisons pour lesquelles un membre de l’équipe peut résoudre un bogue :

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

Spécifier des actions

En général, les membres de l’équipe modifient l’état d’un élément de travail en spécifiant une valeur différente pour le champ État , puis en enregistrant l’élément de travail. Toutefois, vous pouvez également définir un ACTION élément qui modifie automatiquement l’état d’un élément de travail lorsque cette transition se produit. Comme l’illustre l’exemple suivant, vous pouvez spécifier que les éléments de travail de bogues doivent être résolus automatiquement s’ils sont associés aux fichiers qu’un développeur vérifie dans le contrôle de version :

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

Vous pouvez utiliser l’élément ACTION pour modifier automatiquement l’état des éléments de travail d’un type particulier lorsque des événements se produisent ailleurs dans Microsoft Visual Studio Application Lifecycle Management ou en dehors de Visual Studio Application Lifecycle Management (par exemple, à partir d’un outil qui effectue le suivi des appels). Pour plus d’informations, consultez ACTION.

Mettre à jour un champ lors d’une modification de flux de travail

Vous pouvez définir des règles qui mettent à jour les champs chaque fois que les événements suivants se produisent :

  • Affectez une règle de champ sous STATE quand vous souhaitez que la règle s’applique à toutes les transitions vers et pour des raisons d’entrer cet état.

  • Attribuez une règle de champ sous TRANSITION laquelle vous souhaitez que la règle s’applique à cette transition et toutes les raisons de cette transition.

  • Attribuez une règle de champ sous DEFAULTREASON ou REASON lorsque vous souhaitez que les règles s’appliquent uniquement pour cette raison spécifique.

    Si un champ doit toujours contenir la même valeur, vous définissez la règle sous l’élément FIELD qui définit ce champ. Pour plus d’informations sur l’utilisation des règles, consultez Règles et évaluation des règles.

    Vous devez essayer de réduire le nombre de conditions que vous définissez pour n’importe quel type d’élément de travail. Avec chaque règle conditionnelle que vous ajoutez, vous augmentez la complexité du processus de validation qui se produit chaque fois qu’un membre de l’équipe enregistre un élément de travail. Les ensembles de règles complexes peuvent augmenter le temps nécessaire pour enregistrer l’élément de travail.

    Les exemples suivants montrent certaines des règles qui sont appliquées aux champs système dans le modèle de processus pour msf Agile Software Development.

Modifier la valeur d’un champ lorsque l’état change

Lorsque la valeur du champ État d’un élément de travail est définie sur Active et que l’élément de travail est enregistré, les valeurs des champs Activé par et Affecté à sont automatiquement définies sur le nom de l’utilisateur actuel. Cet utilisateur doit être membre du groupe Utilisateurs valides Team Foundation Server. La valeur du champ Date activée est également définie automatiquement. L’exemple suivant montre les éléments qui appliquent cette règle :

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

Effacer la valeur d’un champ lorsque la valeur d’un autre champ change

Lorsque la valeur du champ État d’un élément de travail est définie sur Active et que l’élément de travail est enregistré, les champs Date fermée et Fermé par sont automatiquement définis sur Null et effectués en lecture seule si vous utilisez l’élément EMPTY , comme l’illustre l’exemple suivant.

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

Définir un champ en fonction du contenu d’un autre champ

Lorsque la valeur du champ État d’un élément de travail est résolue et que l’élément de travail est enregistré, la valeur du champ Motif résolu est définie sur la valeur spécifiée par l’utilisateur dans le champ Motif . L’exemple suivant montre les éléments qui appliquent cette règle :

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

Outils pris en charge

Vous pouvez prendre en charge vos utilisateurs pour visualiser le flux de travail en installant l’extension Visualisation de modèle d’état à partir de Visual Studio Marketplace.