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

Pour prendre en charge vos processus d'entreprise et d'équipe, vous devez modifier le flux de travail d'un type d'élément de travail. Les types d'éléments de travail prennent en charge le suivi de tous les types de travail (spécifications, tâches, erreurs de code) pour permettre le développement de logiciels à l'aide de Team Foundation Server (TFS).

Le flux de travail détermine la progression et la régression logiques du travail à effectuer par les membres de l'équipe. Il spécifie également les valeurs qui s'affichent dans les menus déroulants des champs État et Raison.

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

Pour obtenir une vue d'ensemble des états de flux de travail par défaut pris en charge dans les modèles de processus par défaut fournis par TFS, consultez Choisir un modèle de processus, utiliser des artefacts de projet d'équipe. Pour plus d'informations sur le flux de travail de définition de build, consultez Personnaliser votre modèle de processus de génération.

Recommandations en matière de conception de flux de travail

Pour définir un flux de travail, vous devez commencer par identifier les états et les transitions valides entre eux. La section WORKFLOW de la définition d'un type d'élément de travail spécifie les états valides, les transitions, les raisons des transitions et les actions facultatives qui sont exécutées quand un membre de l'équipe modifie l'état d'un élément de travail.

En général, chaque état est associé à un rôle de membre d'équipe et à une tâche que la personne occupant ce rôle doit effectuer pour traiter l'élément de travail avant qu'il ne change d'état. Les transitions définissent les progressions et régressions valides entre les états. Les raisons expliquent pourquoi un membre d'équipe fait passer 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 du flux de travail.

Par exemple, l'état a la valeur Nouveau quand un testeur ouvre un nouveau bogue basé sur le modèle de processus Agile par défaut fourni par Team Foundation Server (TFS). Le développeur fait passer l'état à Actif pendant la résolution du bogue. Une fois ce dernier résolu, le développeur fait passer l'état à Résolu et assigne au champ Raison la valeur Corrigé. Après avoir vérifié le correctif, le testeur fait passer l'état du bogue à Fermé et le champ Raison passe à Vérifié. Si le testeur détermine que le développeur n'a pas résolu le bogue, le testeur peut faire repasser l'état du bogue à Actif et assigner au champ Raison la valeur Pas corrigé ou Échec du test.

Quand vous concevez ou modifiez un flux de travail, tenez compte des points suivants :

• Utilisez l'élément STATE pour définir un état unique pour chaque rôle de membre d'équipe qui effectuera une action spécifique sur un élément de travail. Plus vous définissez d'états, plus vous devez définir de transitions. Quel que soit l'ordre dans lequel vous définissez les états, ceux-ci sont répertoriés par 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 dans les pages du backlog ou du tableau dans Team Web Access, vous devez également mapper l'état à un méta-état. Consultez Informations de référence sur les éléments XML de configuration de processus.

• Utilisez l'élément TRANSITION pour définir une transition pour chaque progression et chaque 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 à son état initial.

  Vous pouvez définir une seule transition de l'état non assigné (null) à l'état initial. Lorsque vous enregistrez un nouvel élément de travail, l'état initial est automatiquement assigné à celui-ci.

  Quand un membre d'équipe modifie l'état d'un élément de travail, cette modification déclenche la transition et les actions que vous avez définies pour l'état et la transition sélectionnés. Les utilisateurs peuvent spécifier uniquement des états valides en fonction des transitions que vous avez définies pour l'état actuel. Par ailleurs, un élément ACTION, qui est un élément enfant de l'élément TRANSITION, peut 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 s'affichent dans le menu déroulant du champ Raison.

• Vous pouvez spécifier des règles qui seront appliquées quand un élément de travail change d'état, lors d'une transition ou quand un utilisateur sélectionne une raison spécifique. Bon nombre de ces règles viennent compléter les règles conditionnelles que vous pouvez appliquer quand vous définissez les champs dans la section FIELDS sous la définition WORKITEMTYPE. Pour plus d'informations, consultez Mettre à jour un champ lors de la modification d'un flux de travail plus loin dans cette rubrique.

• Les noms que vous assignez aux états et aux raisons respectent la casse.

  Les menus déroulants pour les champs État et Raison dans le formulaire d'élément de travail ou l'éditeur de requête répertorient les valeurs assignées dans la section WORKFLOW du type d'élément de travail.

Exemple de code et diagramme d'un flux de travail

L'exemple de code suivant montre la section WORKFLOW de la définition du type d'élément de travail Bogue pour le modèle de processus Agile. Cet exemple définit trois états et cinq transitions. Les éléments STATE spécifient les états Active (Actif), Resolved (Résolu) et Closed (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 l'état Closed (Fermé) à Resolved (Résolu) 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, ACTION et 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>

Diagramme des états de flux de travail de l'exemple – Type d'élément de travail Bogue Agile

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

Le nombre et les types d'états valides varient 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 d'équipe effectuent des actions différentes, vous pouvez songer à définir un état basé sur le rôle d'un membre. Chaque état correspond à une action qu'un membre de l'équipe doit effectuer sur l'élément de travail pour le faire passer à l'état suivant. Pour chaque état, vous devez définir les actions spécifiques et les membres de l'équipe qui sont autorisés à effectuer ces actions.

Le tableau suivant répertorie quatre états définis pour suivre la progression d'une fonctionnalité et les utilisateurs valides qui doivent exécuter les actions indiquées :

Définir des transitions

En définissant des progressions et des régressions d'état valides, vous pouvez contrôler les états à partir desquels ou vers lesquels les membres de l'équipe peuvent faire passer un élément de travail. Si vous ne définissez pas une transition d'un état à un autre, les membres de l'équipe ne peuvent pas faire passer un élément de travail d'un type particulier d'un état donné à un autre état donné.

Le tableau suivant répertorie les transitions valides pour chacun des quatre états décrits précédemment dans cette rubrique, et la raison par défaut pour chacun d'eux.

Vous pouvez limiter les personnes autorisées à effectuer une transition d'un état à un autre à l'aide des attributs for et not de l'élément TRANSITION. Comme le montre l'exemple suivant, les testeurs peuvent rouvrir un bogue, mais pas les développeurs.

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

Spécifier les raisons

Quand un membre de l'équipe modifie le champ État, il peut conserver la raison par défaut de cette transition ou en spécifier une autre si vous définissez des options supplémentaires. Vous devez utiliser l'élément DEFAULTREASON pour ne spécifier qu'une seule raison par défaut. Vous ne devez spécifier des raisons supplémentaires que si elles aident l'équipe à faire le suivi des données ou à créer des rapports.

Par exemple, un développeur peut spécifier l'une des raisons suivantes quand il résout un bogue : Fixed (Corrigé, valeur par défaut), Deferred (Différé), Duplicate (Dupliqué), As Designed (Comme prévu), Cannot Reproduce (Impossible à reproduire) ou Obsolete (Obsolète). Chaque raison spécifie une action particulière que le testeur doit effectuer en rapport avec le bogue.

L'exemple suivant illustre 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 assignant au champ État une valeur différente avant d'enregistrer l'élément de travail. Toutefois, vous pouvez également définir un élément ACTION qui modifie automatiquement l'état d'un élément de travail quand cette transition se produit. Comme dans l'exemple suivant, vous pouvez spécifier que les éléments de travail de bogue soient résolus automatiquement s'ils sont associés à des fichiers archivés dans le contrôle de version par le développeur :

<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 quand 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 de suivi des appels). Pour plus d'informations, consultez Automatiser les assignations des champs par état, transition ou raison.

Mettre à jour un champ lors de la modification d'un flux de travail

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

• Assigner une règle de champ sous STATE pour appliquer la règle à toutes les transitions vers cet état et à toutes les raisons d'entrée dans cet état

• Assigner une règle de champ sous TRANSITION pour appliquer la règle à cette transition et à toutes les raisons de cette transition

• Assigner une règle de champ sous DEFAULTREASON ou REASON pour appliquer uniquement les règles à cette raison spécifique

Si un champ doit toujours contenir la même valeur, définissez la règle sous l'élément FIELD qui définit ce champ. Pour en savoir plus sur l'utilisation des règles, consultez Appliquer une règle à un champ d'élément de travail.

Essayez de réduire le nombre de conditions que vous définissez pour un type d'élément de travail donné. Chaque fois que vous ajoutez une règle conditionnelle, vous augmentez la complexité du processus de validation qui se produit quand un membre de l'équipe enregistre un élément de travail. Plus un ensemble de règles est complexe, plus vous risquez d'augmenter la durée d'enregistrement d'un élément de travail.

Les exemples suivants présentent des règles qui sont appliquées à des champs système dans le modèle de processus pour MSF Agile Software Development.

Modifier la valeur d'un champ quand l'état change

Quand le champ État d'un élément de travail a la valeur Actif et que cet élément de travail est enregistré, les champs Activé par et Assigné à prennent automatiquement pour valeur le nom de l'utilisateur actuel. Cet utilisateur doit être membre du groupe Team Foundation Server Valid Users. La valeur du champ Date d'activation est également définie automatiquement. L'exemple suivant illustre 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 quand la valeur d'un autre champ change

Quand le champ État d'un élément de travail a la valeur Actif et que cet élément de travail est enregistré, les champs Date de fermeture et Fermé par prennent automatiquement la valeur null et passent en lecture seule si vous utilisez l'élément EMPTY, comme le montre 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

Quand le champ État d'un élément de travail passe à la valeur Résolu et que cet élément de travail est enregistré, le champ Motif de résolution se voit assigner la valeur spécifiée par l'utilisateur spécifié dans le champ Raison. L'exemple suivant illustre 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>

Q et R

Q : Existe-t-il un outil permettant de modifier le flux de travail ou d'afficher des diagrammes d'état de flux de travail ?

R : oui. Vous pouvez modifier le flux de travail ou afficher le diagramme d'état de flux de travail que vous définissez à l'aide de l'outil Process Editor pour Visual Studio. Pour plus d'informations, consultez la page suivante sur le site web de Microsoft : Team Foundation Server Power Tools.

Q : Où puis-je obtenir une vue d'ensemble des éléments XML utilisés pour définir les types d'éléments de travail ?

R : consultez Référence de tous les éléments XML WITD.