À propos des états de flux de travail dans les backlogs et les tableaux

  • Article

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Tous les workflows se composent d’états, de transitions et de raisons. Les workflows sont définis pour un type d’élément de travail. Une transition prend en charge le mouvement vers l’avant et vers l’arrière entre deux états. Lorsque vous ajoutez un état personnalisé, le système ajoute automatiquement des transitions de l’état personnalisé à tous les autres états hérités (à l’exception de Supprimé).

Chaque état appartient à une catégorie d’état (concept précédemment appelé méta-état). Les catégories d’état prennent en charge le backlog d’outils Agile et les vues de tableau.

É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. Les quatre états principaux définis pour le récit utilisateur (processus Agile) décrivent la progression d’un récit utilisateur. Les états de workflow sont Nouveau, Actif, Résolu et Fermé. (L'état Supprimé prend en charge la suppression d'un élément de travail de l'apparition du backlog ; pour plus d'informations, consultez Déplacer, modifier ou supprimer des éléments de travail.)

Les progressions et régressions naturelles pour les types d'éléments de travail – user story (Agile), problème (Basic), élément de backlog de produit (Scrum) et exigence (CMMI) – sont telles qu'indiquées.

États de workflow : Récit utilisateur, Processus Agile

États du workflow du 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 sélectionnés traitent chaque état de workflow. Les catégories d’état utilisées par les backlogs, les tableaux et les widgets sont Proposé, En cours, Résolu et Terminé.

Voici comment les états hérités par défaut sont mappés aux états de catégorie pour les quatre processus système, y compris les types d’élément de travail 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 Kanban et des tableaux des tâches est mappée à une catégorie d’état Proposé.

Nouveau

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 backlog (sauf si vous choisissez de les masquer) et constituent les colonnes du milieu sur les tableaux Kanban.

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. Les outils Agile traitent l’état de catégorie Résolu exactement comme l’état En cours.

Résolu (bogue)

n/a

Terminé : Affecté aux états qui représentent le travail terminé. Les éléments de travail dont l’état est dans cette catégorie n’apparaissent pas dans le backlog et apparaissent dans la dernière colonne du tableau Kanban. 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

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 une colonne d’état ou une colonne Kanban

Utilisez les colonnes États et Kanban pour suivre l’état du travail. Les états de workflow sont partagés dans un projet, tandis que les colonnes Kanban sont partagées au sein d’une équipe. Seuls les administrateurs de collection de projets peuvent ajouter des états personnalisés, tandis que les administrateurs d’équipe peuvent ajouter des colonnes Kanban.

Ajoutez des états personnalisés lorsque vous souhaitez que toutes les équipes effectuent le suivi de l’état en fonction du workflow métier adopté par l’organisation. En personnalisant le processus, vous personnalisez automatiquement les projets et les types d’élément de travail qui référencent ce processus.

L’ajout d’états personnalisés pour prendre en charge les états de workflow que plusieurs équipes souhaitent suivre permet d’éviter la confusion résultante de différentes équipes créant des requêtes basées sur une colonne Kanban. Étant donné que chaque équipe peut personnaliser les colonnes et les couloirs de tableau Kanban, les valeurs attribuées aux éléments de travail qui apparaissent sur différents tableaux peuvent ne pas être les mêmes. La solution de contournement principale pour ce problème consiste à conserver la propriété unique des éléments de travail par chemin de zone d’équipe. Une autre solution de contournement consiste à formaliser les colonnes en ajoutant des états personnalisés qui peuvent être 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.