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

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

Les flux de travail sont essentielles à la façon dont Azure Boards effectue le suivi des éléments de travail. Chaque type d’élément de travail a son propre flux de travail qui définit les états, les transitions et les raisons. Les transitions déplacent les éléments de travail vers l’avant et vers l’arrière entre les états. Lorsque vous ajoutez un état personnalisé, Azure DevOps ajoute des transitions par défaut en fonction des règles de processus.

Azure Boards utilise des catégories d’état pour appliquer le comportement de flux de travail de manière cohérente entre les backlogs, les tableaux et les widgets. Cet article explique comment les états sont associés à des catégories et comment cette correspondance affecte la visibilité des éléments, les colonnes du tableau et le fonctionnement des rapports.

États du flux de travail

Les états de flux de travail définissent la façon dont un élément de travail passe de la création à la fermeture. Dans le processus Agile, un récit utilisateur passe généralement par New, Active, Resolved et Closed. Pour supprimer un élément de travail du backlog, utilisez l’état Supprimé. Pour plus d’informations, consultez Déplacer, modifier ou supprimer des éléments de travail.

Le diagramme suivant montre les chemins de progression et de régression classiques pour les types d’éléments de travail courants : récit utilisateur (Agile), problème (de base), élément de backlog de produit (Scrum) et exigence (CMMI).

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

Diagramme montrant les états du flux de travail User Story pour le processus Agile.

États de catégorie

Les catégories d’état normalisent la façon dont les outils de planification Agile et les widgets de tableau de bord interprètent les états de flux de travail. Teams mappe les états de flux de travail à ces états de catégorie : Proposé, En cours, Résolu et Terminé.

Le tableau suivant montre comment les états hérités par défaut correspondent aux états de catégorie sur les quatre processus système, y compris les types d’éléments de travail du plan de test. Les flux de travail Test Case, Test Design et Test Suite utilisent les mêmes mappages sur les quatre processus.

Categories

Suivi du travail

Suivi des tests

Proposé: Utilisez cette catégorie pour les états d’élément de travail nouvellement ajoutés. Les éléments apparaissent dans le backlog, et la première colonne des tableaux et des tableaux des tâches correspond à Proposé.

New

Conception (cas de test)

En cours : Utilisez cette catégorie pour les états de travail actifs. Les éléments apparaissent dans le backlog (sauf s’ils sont masqués) et correspondent aux colonnes centrales du tableau.

Actif (Bogue, Épopée, Fonctionnalité, Récit utilisateur)

Actif (plan de test) ; In Planning (Test Suite) ; En cours (Suite de tests) ; Prêt (cas de test)

Résolu: Utilisez cette catégorie pour les états dans lesquels une solution est implémentée, mais pas encore vérifiée (généralement pour les bogues). Les éléments résolus apparaissent par défaut dans le backlog, peuvent être inclus dans les graphiques de burndown et se comportent comme « En cours » dans de nombreux outils.

Résolu (anomalie)

n/a

Terminé: Utilisez cette catégorie pour les états de travail terminés. Des éléments n’apparaissent pas dans le backlog et sont associés à la dernière colonne du tableau final. Chaque type d’élément de travail ne peut avoir qu’un seul état mappé à cette catégorie.

Fermé (Bogue, Épopée, Fonctionnalité, Récit utilisateur)

Fermé (cas de test) ; Terminé (Suite de tests) ; Inactif (plan de test)

Enlevé : utilisez cette catégorie avec l’état Enlevé pour masquer les éléments du backlog et des expériences de carte.

Supprimé (Épopée, Fonction, Récit utilisateur)

n/a

Où les types d’éléments de travail apparaissent

Utilisez le tableau suivant comme référence rapide pour chaque catégorie de type d’élément de travail.

Catégorie de type d’élément de travail Apparaît sur
Requirement Carte de produit uniquement
Feature Tableau du portefeuille de fonctionnalités uniquement
Epic Carte de portefeuille Epic uniquement
Custom Tableau de portefeuille personnalisé uniquement

Tip

Mappez chaque état de flux de travail à une colonne de tableau. Si un état n’est pas mappé, il n’apparaît pas sur la carte.

Note

  • Les backlogs et les tableaux masquent les éléments de travail terminés ou fermés lorsque leur Date de modification est antérieure à 183 jours (soit environ six mois).
  • Recherchez des éléments masqués en exécutant une requête.
  • Affichez à nouveau un élément sur un backlog ou une carte en effectuant une mise à jour mineure pour actualiser sa date de modification.

Note

  • Les backlogs et les tableaux masquent les éléments de travail terminés ou fermés lorsque leur date de modification est antérieure à un an.
  • Recherchez des éléments masqués en exécutant une requête.
  • Affichez à nouveau un élément sur un backlog ou une carte en effectuant une mise à jour mineure pour actualiser sa date de modification.

Champs Activé par/Date et Résolu par/Date

Le système met à jour ces champs : Activé par, Date activée, Date résolue et Date résolue, en fonction des modifications d’état de catégorie de flux de travail :

  • Lorsque l’état du flux de travail passe à une catégorie En cours , le système met à jour activé par et date activée.
  • Lorsque l’état du flux de travail passe à une catégorie Résolue, le système met à jour Résolu par et Date de résolution.

Pour plus d’informations sur la façon dont les états de flux de travail correspondent aux catégories d’état, consultez Comment les états de flux de travail et les catégories d’état sont utilisés dans Backlogs et Boards.

Note

Cette logique s’applique à azure DevOps Services, à la mise à jour d’Azure DevOps Server 2020.1 et aux versions ultérieures.

Étant donné que ces champs font référence à des catégories d’état de flux de travail, tous les états de flux de travail personnalisés que vous ajoutez déclenchent également les mises à jour des champs. Pour plus d’informations, consultez Personnaliser le flux de travail pour un processus.

Notes supplémentaires

  • Les champs sont mis à jour chaque fois qu’un élément de travail passe d’un état de catégorie autre que celui défini. Par exemple, si vous déplacez un élément de travail de Nouveau vers Résolu, les champs Date résolue par/date résolue sont mis à jour. Si vous passez de Fixed à Ready for Testing (qui se trouvent dans le même état de catégorie), les champs Date résolue par/date résolue ne sont pas mis à jour.
  • Lorsque vous effectuez une transition vers l’arrière, par exemple, d’un état résolu à un état Actif , le système efface les champs Date résolue par/résolu . Si vous passez d’Actif à Nouveau, le système efface les champs Date activée par/activé .
  • Ne modifiez pas manuellement ces valeurs de champ. Ces champs sont des champs système régis par des règles système et Azure DevOps remplace toutes les valeurs manuelles.

Quand ajouter un état ou une colonne ?

Utilisez des états et des colonnes ensemble pour suivre l’état du travail, mais utilisez chacun d’eux pour une étendue différente :

  • État : logique de flux de travail au niveau du projet, partagée entre les équipes.
  • Colonne : Visualisation du tableau à l’échelle de l’équipe.

Les utilisateurs disposant d’autorisations de modification de processus (généralement Project Administrateurs de regroupement ou éditeurs de processus délégués) peuvent ajouter des états personnalisés. Les administrateurs d’équipe et les administrateurs Project peuvent ajouter des colonnes de tableau.

Ajoutez des états personnalisés lorsque les équipes ont besoin d’une définition de flux de travail partagée pour les requêtes, la création de rapports et la cohérence entre les équipes. Les états personnalisés se propagent aux types d’éléments de travail qui référencent le processus.

Ajoutez ou ajustez des colonnes lorsqu’une équipe a besoin d’une vue du travail spécifique au tableau sans modifier le flux de travail partagé.

Pour éviter toute confusion, veillez à aligner la responsabilité des éléments de travail sur les chemins de zone d’équipe, ou à standardiser les flux de travail partagés à l’aide d’états personnalisés lorsque plusieurs équipes suivent le même processus.

Compléter automatiquement les éléments de travail avec des pull requests

Lorsque vous liez un élément de travail à une pull request (PR), Azure DevOps peut automatiquement marquer l’élément de travail lié comme terminé lorsque la PR est terminée. 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

Azure DevOps peut automatiquement mettre à jour l’état d’un élément de travail parent en fonction de l’état de ses tâches enfant. Pour plus d’informations, consultez Automatiser les transitions d’état d’élément de travail.

Contenu connexe

Modèle de processus d’héritage

Modèle de processus XML local

Widgets de tableau de bord

  • Last updated on