Partager via

À 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, qui prend en charge les vues du carnet de commandes et du tableau de bord de l'outil Agile.

É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 Retiré permet de supprimer un élément de travail du carnet de commandes ; pour plus d'informations, voir 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 manière dont les outils de planification Agile et les widgets de tableau de bord spécifiques traitent chaque état du workflow. Les types d'éléments de travail utilisent les catégories d'état pour suivre l'avancement du travail. Les états s'appliquent à tous les projets qui utilisent le même processus et affectent la façon dont les éléments de travail apparaissent dans les carnets de commandes et les tableaux de bord. Les catégories d'état utilisées par les backlogs, les tableaux et les widgets sont Proposé, En cours, Résolu et Terminé.

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

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 à la fois des états et des colonnes pour suivre l'état du travail. Les états de workflow sont partagés au sein d'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 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 du workflow que plusieurs équipes souhaitent suivre permet d'éviter la confusion qui en résulte lorsque différentes équipes créent des requêtes basées sur une colonne. Étant donné que chaque équipe peut personnaliser les colonnes et les couloirs du tableau, 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.