À propos des états de flux de travail dans les backlogs et les tableaux
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Les flux de travail sont essentiels pour la gestion des éléments de travail, constitués d’états, de transitions et de raisons. Chaque flux de travail est défini pour un type d’élément de travail spécifique. Les transitions permettent le déplacement entre les états, à la fois vers l’avant et vers l’arrière. Lorsque vous ajoutez un état personnalisé, le système inclut automatiquement les transitions vers tous les autres états hérités, à l’exception de l’état Supprimé.
Chaque état est classé pour prendre en charge les backlogs d’outils Agile et les vues de tableau, ce qui garantit un processus de flux de travail rationalisé et organisé.
États de flux de travail
Les états de workflow définissent la progression d’un élément de travail de sa création à la fermeture. Pour le processus User Story (Agile), les états principaux sont Nouveaux, Actifs, Résolus et Fermés. L’état supprimé est utilisé pour supprimer un élément de travail du backlog ; pour plus d’informations, consultez Déplacer, modifier ou supprimer des éléments de travail.
Les progressions naturelles et les régressions pour les types d’éléments de travail (agiles), le problème (De base), l’élément de backlog produit (Scrum) et l’exigence (CMMI) sont comme indiqué.
États de workflow : Récit utilisateur, Processus Agile
États de catégorie
Les états de catégorie déterminent la façon dont les outils de planification Agile et les widgets de tableau de bord traitent chaque état de flux de travail. Les types d’éléments de travail utilisent des catégories d’état pour suivre la progression. Ces états s’appliquent à tous les projets à l’aide du même processus et affectent la façon dont les éléments de travail apparaissent sur les backlogs et les tableaux. Les catégories d’état utilisées par les backlogs, les tableaux et les widgets sont proposées, en cours, résolues et terminées.
Le tableau suivant montre comment les états hérités par défaut sont mappés aux catégories d'états pour les quatre processus du système, y compris les types d'éléments de travail du plan de test. Les états de workflow pour Cas de test, Conception de test et Suite de tests sont les mêmes pour les quatre processus système.
Catégories
Suivi du travail
Suivi des coûts
Proposé : Affecté aux états associés aux éléments de travail nouvellement ajoutés afin qu’ils apparaissent dans le backlog. La première colonne des tableaux et des taskboards correspond à la catégorie d'état Proposé.
Nouvelle
Conception (cas de test)
En cours : Affecté aux états qui représentent le travail actif. Les éléments de travail affectés aux états mappés à cette catégorie apparaissent dans le carnet de commandes (à moins que vous ne choisissiez de les masquer) et constituent les colonnes centrales des tableaux.
Actif (Bogue, Épopée, Fonctionnalité, Récit utilisateur)
Actif (plan de test) Planification en cours (suite de tests) En cours (suite de tests) Prêt (cas de test)
Résolu : Attribué aux États qui représentent une solution a été mise en œuvre, mais pas encore vérifiée. En règle générale, ces états s’appliquent aux bogues. Les éléments de travail dans un état de catégorie Résolu apparaissent sur le backlog par défaut. Vous pouvez également inclure les états Résolus dans les burndown charts, ce qui permet un suivi plus précis de la progression. Les outils Agile traitent l’état de catégorie Résolu exactement comme l’état En cours.
Résolu (bogue)
n/a
Terminé : Attribué aux états qui représentent un travail terminé. Les éléments de travail dont l'état appartient à cette catégorie n'apparaissent pas dans le carnet de commandes, mais dans la dernière colonne du tableau. Vous ne pouvez pas modifier les états de cette catégorie, et vous ne pouvez pas y ajouter d’états.
Fermé (Bogue, Épopée, Fonctionnalité, Récit utilisateur)
Fermé (cas de test) Terminé (suite de tests) Inactif (plan de test)
Supprimé : Affecté à l’état Supprimé. Les éléments de travail dans un état mappé à la catégorie Supprimé sont masqués dans les expériences du backlog et du tableau.
Supprimé (Épopée, Fonctionnalité, Récit utilisateur)
n/a
Types d’éléments de travail et leurs tableaux
Découvrez où chaque type d’élément de travail s’affiche pour que vous puissiez gérer efficacement votre travail.
Catégorie de type d’élément de travail | Les éléments de travail s’affichent ici |
---|---|
Exigence | Uniquement sur le tableau des produits. |
Fonctionnalité | Uniquement sur le tableau du portefeuille de fonctionnalités. |
Epic | Uniquement sur le tableau du portefeuille Epic. |
Personnalisée | Uniquement sur un tableau du portefeuille personnalisé. |
Conseil
Nous vous recommandons de faire correspondre chaque état du flux de travail à une colonne. S'il n'est pas mappé, il n'apparaît pas sur le tableau.
Remarque
Les éléments de travail terminés ou fermés ne s’affichent pas sur les backlogs et les tableaux à partir du moment où leur Date de modification remonte à plus de 183 jours (environ six mois). Vous pouvez toujours répertorier ces éléments à l’aide d’une requête. Si vous souhaitez qu’ils apparaissent dans un backlog ou un tableau, vous pouvez y apporter une modification mineure qui réinitialise l’horloge.
Remarque
Les éléments de travail terminés ou fermés ne s’affichent pas sur les backlogs et les tableaux à partir du moment où leur Date de modification remonte à plus d’un an. Vous pouvez toujours répertorier ces éléments à l’aide d’une requête. Si vous souhaitez qu'ils apparaissent dans un backlog ou un tableau, vous pouvez y apporter une modification mineure qui réinitialise l'horloge.
Champs Activé par/Date et Résolu par/Date
Le système met à jour ces champs (Activé par, Date d’activation, Résolu par et Date de résolution) lorsqu’une modification se produit en fonction des états de catégorie de workflow correspondants. Lorsque l’état du workflow passe à une catégorie d’état En cours, Activé par et Date d’activation sont mis à jour. Lorsque l’état du workflow passe à une catégorie d’état Résolu, Résolu par et Date de résolution sont mis à jour.
Pour en savoir plus sur la façon dont les états de workflow sont mappés aux catégories d’état, consultez Utilisation des états de workflow et des catégories d’état dans les backlogs et tableaux.
Notes
La logique régissant les champs décrits ici s’applique à Azure DevOps Services, Azure DevOps Server 2020.1 et versions ultérieures.
Étant donné que ces champs référencent les catégories d’état de workflow, les états de workflow personnalisés que vous ajoutez sont référencés lors de la mise à jour des champs. Pour en savoir plus sur la personnalisation, consultez Personnaliser le workflow pour un processus.
Informations complémentaires :
- Les champs sont mis à jour chaque fois qu’un élément de travail change à partir d’un état de catégorie autre que celui défini. Par exemple, si vous mettez à jour un élément de travail de Nouveau vers Résolu, les champs Résolu par/Date de résolution sont mis à jour. Toutefois, si vous effectuez une mise à jour à partir de Fixe et Prêt pour les tests, qui sont dans le même état de catégorie, les champs Résolu par/Date de résolution ne sont pas mis à jour.
- Lorsque vous effectuez une transition vers l’arrière, comme passer d’un état Résolu à un état Actif, le système efface les valeurs des champs Résolu par/Date de résolution. Si vous passez d’Actif à Nouveau, le système efface les valeurs des champs Activé par/Date d’activation.
- Ne modifiez pas manuellement les valeurs de ces champs. Il s’agit de champs système régis par des règles système. Toute valeur que vous tentez de définir est écrasée.
Quand ajouter un état ou une colonne ?
Utilisez les états et les colonnes pour suivre l’état du travail. Les états de flux de travail sont partagés dans un projet, tandis que les colonnes sont partagées au sein d’une équipe. Seuls les administrateurs de la collection de projets peuvent ajouter des états personnalisés, tandis que les administrateurs d'équipes peuvent ajouter des colonnes.
Ajoutez des états personnalisés pour aligner toutes les équipes avec le flux de travail métier de l’organisation. La personnalisation du processus personnalise automatiquement les projets et les types d’éléments de travail qui le référencent.
Les états personnalisés permettent d’éviter toute confusion des différentes équipes créant des requêtes basées sur des colonnes. Étant donné que les équipes peuvent personnaliser des colonnes de tableau et des couloirs, les valeurs des éléments de travail peuvent différer entre les tableaux. Conservez une propriété unique des éléments de travail par chemin d’accès de zone d’équipe ou formalisez des colonnes en ajoutant des états personnalisés partagés entre les équipes.
Achèvement automatique d’éléments de travail avec des demandes de tirage
Lorsque vous liez un élément de travail à une demande de tirage, vous pouvez achever automatiquement ces éléments de travail lorsque vous terminez la demande de tirage. Pour plus d’informations, consultez Compléter automatiquement les éléments de travail avec des demandes d’extraction.
Automatiser les transitions d’état des éléments de travail
Vous pouvez mettre à jour automatiquement l’état d’un élément de travail en fonction de l’état de ses tâches enfants. Pour plus d’informations, consultez Automatiser les transitions d’état des éléments de travail.
Articles connexes
Modèle de processus d’héritage
- Personnaliser votre flux de travail
- Appliquer des règles aux états de flux de travail
- Évaluer les règles
- Explorer des scénarios de règle personnalisées
Modèle de processus XML local
Widgets du tableau de bord