Conception du workflow
Vous concevez le flux de travail d'un type d'élément de travail pour permettre la prise en charge de vos processus d'équipe et métier. Le flux de travail détermine la progression logique des tâches qui seront effectuées et identifie la personne chargée de les exécuter. Vous définissez le flux de travail en commençant par identifier les états et les transitions valides entre ceux-ci. La section WORKFLOW de la définition du type d'élément de travail définit les états, les transitions et les raisons des transitions valides, ainsi que les actions facultatives qui seront exécutées lorsqu'un membre de l'équipe modifie l'état d'un élément de travail. Pour plus d'informations sur les définitions de type, consultez Référence de tous les éléments XML WITD.
En général, vous associez chaque état à un rôle de membre de l'équipe et à une tâche qui doit être effectuée par une personne dotée de ce rôle pour traiter l'élément de travail avant de modifier son état. Les transitions définissent les progressions et régressions valides entre des états. Les raisons expliquent pourquoi un membre de l'équipe modifie l'état d'un élément de travail, et les actions prennent en charge l'automatisation de la transition d'un élément de travail à un moment précis dans le flux de travail.
Par exemple, l'état prend la valeur Actif lorsqu'un testeur ouvre un nouveau bogue basé sur le modèle de processus de Microsoft Solutions Framework (MSF) for Agile Software Development 5.0. Après avoir résolu le bogue, le développeur remplace sont état par Résolu et assigne la valeur Corrigé au champ Raison. Après avoir vérifié le correctif, le testeur remplace l'état du bogue par Fermé et ne modifie pas la valeur Corrigé assignée au champ Raison. Si le testeur détermine que le développeur n'a pas résolu le bogue, il remplace l'état du bogue par Actif et assigne la valeur Résolution refusée ou Échec du test au champ Raison.
Notes
Vous pouvez créer et modifier les définitions des types d'éléments de travail et d'autres objets pour effectuer le suivi d'éléments de travail à l'aide de Process Editor, un outil puissant dédié à Visual Studio. Cet outil n'est pas pris en charge Pour plus d'informations, consultez la page suivante sur le site Web Microsoft : Outils puissants dédiés à Team Foundation Server - Avril 2010 (page éventuellement en anglais).
Dans cette rubrique
Règles de conception de flux de travail
Diagramme de flux de travail et exemple de code
Détermination du nombre et des types d'états
Définition des transitions
Spécification des raisons
Spécification d'actions
Mise à jour d'un champ en cas de modification de l'état
Définition d'un champ en cas de modification de l'état
Effacement de la valeur d'un champ
Définition d'un champ à partir du contenu d'un autre champ
Affichage du diagramme d'état de flux de travail
Règles de conception de flux de travail
Lorsque vous concevez ou modifiez un flux de travail, tenez compte des indications suivantes :
L'élément STATE vous permet de définir un état unique pour chaque rôle de membre de l'équipe qui exécutera 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, ils sont répertoriés par ordre alphanumérique dans la liste État.
L'élément TRANSITION vous permet de définir une transition d'un état à un autre pour chacune des progressions et régressions valides.
Vous devez définir au moins une transition pour chaque état et créer la transition entre l'état null et l'état initial.
Pour chaque transition, vous devez définir 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.
Vous ne pouvez définir qu'une seule transition entre l'état non assigné (null) et l'état initial. Lorsque vous enregistrez un nouvel élément de travail, il prend automatiquement l'état initial.
Lorsqu'un membre de l'équipe modifie l'état d'un élément de travail, la transition est déclenchée ainsi que les actions à exécuter pour l'état sélectionné et la transition. Les utilisateurs peuvent spécifier uniquement les états valides pour les transitions que vous définissez pour l'état actuel. En outre, 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.
Vous pouvez définir des règles conditionnelles sur n'importe quel champ. Elles seront appliquées lors de la modification de l'état et de la transition de l'élément de travail ou lors de la sélection d'une raison spécifique par un utilisateur. Un grand nombre de ces règles conditionnelles complètent celles que vous pouvez appliquer lorsque vous définissez des champs dans la section FIELDS sous la définition WORKITEMTYPE. Pour plus d'informations, consultez Mise à jour d'un champ en cas de modification de l'état plus loin dans cette rubrique.
Vous devez tenter de réduire le nombre de conditions que vous définissez pour tout type d'élément de travail. Chaque règle conditionnelle que vous ajoutez accroît la complexité du processus de validation qui s'exécute chaque fois qu'un membre de l'équipe enregistre un élément de travail. Des ensembles de règles complexes peuvent augmenter la durée de l'enregistrement de l'élément de travail.
Les noms que vous assignez aux états et aux raisons ne respectent pas la casse.
Retour au début
Diagramme de flux de travail et exemple de code
Le tableau suivant décrit la section WORKFLOW de la définition d'un type d'élément de travail qui assure le suivi d'erreurs de code et le diagramme d'état de flux de travail qu'elle définit. Dans cet exemple, trois états, six transitions et neuf raisons sont définis. Les éléments STATE 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 une. La transition entre les états Fermé et 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 qui est fermé.
Notes
Dans cet exemple, les éléments pour DEFAULTREASON, REASON, ACTION et FIELD ne sont pas représentés.
|
Exemple de diagramme d'état de flux de travail
.png "Diagramme d'état du récit utilisateur") |
Détermination du nombre et des types d'états
Vous déterminez le nombre et les types d'états valides en fonction du nombre d'états logiques distincts que vous souhaitez définir pour les éléments de travail de ce type. En outre, si différents membres de l'équipe exécutent des actions différentes, vous pouvez envisager de définir un état en fonction d'un rôle de membre. Chaque état correspond à une action qu'un membre de l'équipe doit exécuter sur l'élément de travail pour le faire passer à l'état suivant. Pour chaque état, vous devez définir des actions spécifiques et les membres de l'équipe autorisés à exécuter ces actions.
Le tableau suivant présente des exemples de quatre états définis pour le suivi de la progression d'une fonctionnalité et les utilisateurs valides chargés d'exécuter les actions indiquées :
État |
Utilisateur valide |
Action à exécuter |
|---|---|---|
Proposé |
Chef de projet |
N'importe quel utilisateur peut créer un élément de travail Fonctionnalité. Toutefois, seuls les chefs de projet peuvent approuver ou désapprouver l'élément de travail. Si un chef de projet approuve une fonctionnalité, il remplace l'état de l'élément de travail par Actif, faute de quoi, ce dernier est fermé par un membre de l'équipe. |
Active |
Responsable du développement |
Le responsable du développement surveille le développement de la fonctionnalité. Lorsque la fonctionnalité est achevée, le responsable du développement remplace l'état de l'élément de travail Fonctionnalité par Vérifier. |
Récapitulatif |
Chef de projet |
Le chef de projet vérifie la fonctionnalité que l'équipe a implémentée et remplace l'état de l'élément de travail par Fermé si l'implémentation est satisfaisante. |
Closed |
Chef de projet |
Aucune autre action supplémentaire n'est attendue sur les éléments de travail fermés. Ces éléments demeurent dans la base de données à des fins d'archivage et de création de rapports. |
Notes
Tous les états sont répertoriés par ordre alphabétique dans la liste du formulaire d'un élément de travail d'un type particulier, quel que soit l'ordre dans lequel vous les spécifiez.
Retour au début
Définition des transitions
Le fait de définir les progressions et les régressions d'état valides vous permet de contrôler les états vers lesquels ou à partir desquels des membres d'équipe peuvent modifier un élément de travail. Si vous ne définissez pas une transition entre deux états spécifiques, les membres de l'équipe ne peuvent pas remplacer l'état spécifique d'un élément de travail d'un type particulier par un autre état spécifique.
Le tableau suivant définit les transitions valides pour chacun des quatre états décrits précédemment dans cette rubrique, et indique la raison par défaut pour chacun d'eux.
État |
État vers lequel effectuer la transition |
Raison par défaut |
|---|---|---|
Proposé |
Actif (progression) |
Approuvé pour développement |
Fermé (progression) |
Non approuvé |
|
Active |
Vérifier (progression) |
Critères d'acceptation satisfaits |
Récapitulatif |
Fermé (progression) |
Fonctionnalité achevée |
Actif (régression) |
Ne répond pas aux spécifications |
|
Closed |
Proposé (régression) |
Soumettre à une nouvelle approbation |
Actif (régression) |
Fermé avec erreur |
Vous pouvez limiter le nombre de personnes autorisées à effectuer une transition d'un état vers un autre à l'aide des attributs for et not de l'élément TRANSITION. Comme le montre l'exemple suivant, seuls les testeurs peuvent rouvrir un bogue, et non les développeurs.
<TRANSITION from="Closed" to="Active"
for="[Project]\Testers"
not="[Project]\Developers">
. . .
</TRANSITION>
Retour au début
Spécification des raisons
Lorsqu'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 spécifier une seule raison par défaut. Vous devez spécifier des raisons supplémentaires uniquement si elles sont destinées à aider les membres de l'équipe pour l'exécution du suivi ou la création de rapports concernant des données.
Par exemple, un développeur peut spécifier l'une des raisons suivantes lorsqu'il résout un bogue : Corrigé (valeur par défaut), Différé, Dupliqué, Correspond aux spécifications, Reproduction impossible ou Obsolète. Chaque raison spécifie une action particulière que le testeur doit exécuter sur le bogue.
Notes
Toutes les raisons sont répertoriées par ordre alphabétique dans la liste du formulaire des éléments de travail d'un type particulier, quel que soit l'ordre dans lequel vous avez spécifié les éléments REASON.
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>
Retour au début
Spécification d'actions
En général, les membres de l'équipe modifient l'état d'un élément de travail en commençant par indiquer une autre valeur pour le champ État, puis en enregistrant 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 lorsque cette transition se produit. Comme le montre l'exemple suivant, vous pouvez indiquer que des éléments de travail Bogue doivent être résolus automatiquement s'ils sont associés à des fichiers archivés dans le contrôle de version par un 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 d'éléments de travail d'un type particulier lorsque des événements se produisent ailleurs dans Microsoft Visual Studio Application Lifecycle Management ou au sein de Visual Studio Application Lifecycle Management (par exemple, à partir d'un outil qui assure le suivi d'appels). Pour plus d'informations, consultez Automatisation des assignations des champs par état, transition ou raison.
Retour au début
Mise à jour d'un champ en cas de modification de l'état
Vous pouvez définir des règles qui mettent à jour des champs chaque fois que les événements suivants se produisent :
Assignez une règle de champ sous STATE lorsque vous souhaitez que cette règle s'applique à toutes les transitions vers cet état et à toutes les raisons relatives à la saisie de cet état.
Assignez une règle de champ sous TRANSITION lorsque vous souhaitez que cette règle s'applique à cette transition et à toutes les raisons relatives à l'exécution de cette transition.
Assignez une règle de champ sous DEFAULTREASON ou REASON lorsque vous souhaitez que cette règle s'applique uniquement à cette raison.
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, consultez Définition de conditions sur un champ d'élément de travail.
Les exemples suivants illustrent quelques-unes des règles qui s'appliquent aux champs système du modèle de processus pour MSF for Agile Software Development v5.0.
Modification de la valeur d'un champ en cas de modification de l'état
Effacement de la valeur d'un champ en cas de modification de la valeur d'un autre champ
Définition d'un champ à partir du contenu d'un autre champ
Retour au début
Modification de la valeur d'un champ en cas de modification de l'état
Lorsque le champ État d'un élément de travail a pour valeur Actif et que ce dernier est enregistré, les champs Activé par et Assigné à prennent automatiquement 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>
Retour au début
Effacement de la valeur d'un champ en cas de modification de la valeur d'un autre champ
Lorsque le champ État d'un élément de travail a pour valeur Actif et que ce dernier est enregistré, les champs Date de fermeture et Fermé par prennent automatiquement la valeur null et deviennent accessibles en lecture seule si vous utilisez l'élément EMPTY, comme illustré dans 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>
Retour au début
Définition d'un champ à partir du contenu d'un autre champ
Lorsque la valeur du champ État d'un élément de travail devient Résolu et que ce dernier est enregistré, le champ Motif de résolution prend la valeur que l'utilisateur a spécifiée 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>
Retour au début
Affichage du diagramme d'état de flux de travail
Vous pouvez afficher la définition de flux de travail de n'importe quel type d'élément de travail si vous utilisez Team Web Access pour ouvrir le diagramme d'état de n'importe quel élément de travail de ce type. Pour plus d'informations, consultez Gestion du travail à l'aide de Team Web Access.
Conseil
Vous pouvez également afficher le diagramme d'état de flux de travail que vous définissez à l'aide de Process Editor, un outil puissant dédié à Visual Studio. Cet outil n'est pas pris en charge Pour plus d'informations, consultez la page suivante sur le site Web Microsoft : Outils puissants dédiés à Team Foundation Server - Avril 2010 (page éventuellement en anglais).
Retour au début
Voir aussi
Autres ressources
Définition et personnalisation du flux de travail des éléments de travail
Historique des modifications
Date |
Historique |
Motif |
|---|---|---|
|
Janvier 2011 |
Tableau des éléments WORKFLOW déplacé vers une nouvelle rubrique, Référence de tous les éléments XML WORKFLOW. |
Améliorations apportées aux informations. |
|
Juillet 2010 |
Entièrement réécrit pour fournir davantage d'informations et d'exemples, ainsi qu'un résumé de tous les éléments et attributs WORKFLOW. |
Améliorations apportées aux informations. |