Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
Azure Boards propose plusieurs processus de gestion des éléments de travail. La sélection du processus approprié permet d’optimiser votre flux de travail de projet et de configurer votre équipe pour réussir. Cet article décrit les processus disponibles dans Azure Boards et vous aide à choisir celui qui correspond à votre projet.
Lorsque vous créez un projet, vous choisissez un processus ou modèle de processus basé sur le modèle de processus pour lequel votre organisation ou votre collection a été créée. Avant de choisir un processus pour votre projet, vous devez comprendre les termes suivants.
| Terme | Description |
|---|---|
| Modèle de processus | Fait référence au modèle utilisé pour prendre en charge les projets créés pour une organisation ou une collection de projets. Un seul modèle de processus est pris en charge pour un projet à la fois. |
| Process | Définit les blocs de construction du système de suivi des éléments de travail et prend en charge le modèle de processus d’héritage pour Azure Boards. Ce modèle prend en charge la personnalisation des projets via un éditeur visuel dans le portail web Azure DevOps. |
| Modèle de processus | Définit les blocs de construction du système de suivi des éléments de travail et d’autres sous-systèmes accessibles via Azure DevOps. Les modèles de processus sont utilisés uniquement avec les modèles de processus XML hébergé et XML local. Vous pouvez personnaliser des projets en modifiant et en important des fichiers de définition XML de modèle de processus. |
Les types de processus par défaut sont Basic, Agile, Capability Maturity Model Integration (CMMI) et Scrum. Les objets de suivi de travail dans les processus et les modèles de processus par défaut sont identiques. Cet article les résume.
Conseil
Avec Azure DevOps Server, vous pouvez sélectionner le modèle de processus hérité ou le modèle de processus XML local. Pour plus d’informations, consultez la section Choisir le modèle de processus pour votre collection de projets. Pour accéder aux dernières versions des processus ou modèles de processus par défaut :
Modèle de processus hérité : ouvrez la page Processus. Pour plus d’informations, consultez Gérer les processus.
Modèle de processus XML local :
- Installer ou mettre à niveau vers la dernière version d’Azure DevOps Server
- Téléchargez le fichier de modèle compressé à l’aide du Gestionnaire de modèles de processus. Utilisez une version de Visual Studio au même niveau de version qu’Azure DevOps Server. Vous pouvez installer gratuitement la dernière version de Visual Studio Community.
- Accédez aux derniers modèles de processus par défaut installés sur Azure DevOps Server, par exemple :
%programfiles%/Azure DevOps Server 2020/Tools/Deploy/ProcessTemplateManagerFiles/1033. Pour obtenir une description de chaque fichier et dossier, consultez Vue d’ensemble des fichiers de modèle de processus.
Processus par défaut
Les processus par défaut diffèrent principalement dans les types d’éléments de travail qu’ils fournissent pour la planification et le suivi du travail. Utilisez le guide suivant pour choisir le processus qui correspond à votre équipe :
- Choisissez Basic pour l’expérience la plus simple : effectuez le suivi du travail en tant qu’épopées, problèmes et tâches.
- Choisissez Agile si votre équipe utilise des méthodes Agile et que vous souhaitez suivre les récits utilisateur avec des activités de développement et de test distinctes.
- Choisissez Scrum si votre équipe suit Scrum et suit les éléments et bogues du backlog des produits.
- Choisissez CMMI si votre équipe a besoin d’une gestion formelle des modifications, d’un enregistrement auditable des décisions et du suivi des exigences, des demandes de modification, des risques et des révisions.
Choisir le bon processus
Si vous ne savez pas quel processus correspond à votre équipe, utilisez les scénarios suivants comme point de départ :
Déterminer le processus de votre projet
Pour trouver le processus que votre projet utilise :
- Connectez-vous à votre projet Azure DevOps.
- Sélectionnez Paramètres du projet>Processus.
Le nom du processus apparaît en haut de la page (par exemple, Agile, Scrum, Basic ou CMMI).
Pour plus d’informations, consultez Gérer les projets.
Choisir le bon processus
Si vous ne savez pas quel processus correspond à votre équipe, utilisez les scénarios suivants comme point de départ :
| Scénario | Procédé recommandé | Pourquoi |
|---|---|---|
| Vous débutez avec Azure Boards ou souhaitez le suivi léger. | Basic | Trois types d’éléments de travail (Épopée, Problème, Tâche) et un flux de travail simpleTo Do / Doing / Done. |
| Votre équipe pratique Agile, suit les récits utilisateur et sépare le développement du travail de test. | Agile | Histoires utilisateur avec suivi des bogues séparé ; états plus détaillés (New, Active, Resolved, Closed, Removed). |
| Votre équipe pratique Scrum avec des sprints, des éléments de backlog de produits et des obstacles. | Scrum | Éléments du backlog produit et bugs sur le tableau ; les états Approved et Committed correspondent directement aux cérémonies Scrum. |
| Vous travaillez dans un environnement réglementé qui nécessite un contrôle formel des modifications, un enregistrement vérifiable des décisions et un suivi des risques et des révisions. | CMMI | Ajoute les types d’éléments de travail Requis, Demande de modification, Risque et Révision et prend en charge les activités formelles de gestion des modifications. |
Importante
Vous ne pouvez pas modifier le processus de base d’un projet après la création du projet. Vous pouvez personnaliser un processus hérité pour ajouter des champs, des états et des types d’éléments de travail, ou créer un projet sur un autre processus et déplacer des éléments de travail entre des projets.
Note
Le choix ou la personnalisation d’un processus nécessite l’appartenance au groupe Administrateurs de collections Project. Pour plus d’informations, consultez Informations de référence rapides sur les autorisations par défaut.
| Process | Hiérarchie des éléments de travail |
|---|---|
|
Basic Choisissez Basic lorsque votre équipe souhaite utiliser le modèle le plus simple qui utilise les types d’éléments de travail Problème, Tâche et Épopée pour suivre le travail. Les tâches prennent en charge le suivi du travail restant. |
|
|
Agile Choisissez Agile lorsque votre équipe utilise des méthodes de planification Agile, notamment Scrum, et effectue le suivi des activités de développement et de test séparément. Ce processus fonctionne parfaitement pour le suivi des récits utilisateur et (éventuellement) des bogues dans le tableau. Vous pouvez également suivre les bogues et les tâches dans le tableau des tâches. Pour plus d’informations sur les méthodologies Agile, consultez Agile Alliance. Les tâches prennent en charge le suivi de l’estimation d’origine, du travail restant et du travail terminé. |
|
|
Scrum Choisissez Scrum lorsque votre équipe pratique la méthodologie Scrum. Ce processus fonctionne parfaitement pour le suivi des éléments de backlog de produit et des bogues dans le tableau. Vous pouvez également décomposer les éléments du backlog produit et les bogues en tâches dans le tableau des tâches. Ce processus prend en charge la méthodologie Scrum, telle qu’elle est définie par l’organisation Scrum. Les tâches prennent uniquement en charge le suivi du travail restant. |
|
|
CMMI Choisissez CMMI quand votre équipe suit des méthodes de projet plus formelles qui nécessitent une infrastructure pour l’amélioration de processus, et un enregistrement des décisions pouvant faire l’objet d’un audit. Avec ce processus, vous pouvez suivre les exigences, les demandes de modification, les risques et les révisions. Ce processus prend en charge les activités formelles de gestion des modifications. Les tâches prennent en charge le suivi de l’estimation d’origine, du travail restant et du travail terminé. |
|
Si vous avez besoin de plus de deux ou trois niveaux de backlog, ajoutez-en d’autres en fonction du modèle de processus que vous utilisez :
- Héritage : Personnaliser vos backlogs ou vos tableaux pour un processus
- XML hébergé ou XML local : ajouter des backlogs de portefeuille
Distinctions principales entre les processus par défaut
Les processus par défaut répondent aux besoins de la plupart des équipes. Si votre équipe a des besoins inhabituels et se connecte à un serveur local, personnalisez un processus, puis créez le projet. Vous pouvez également créer un projet à partir d’un processus, puis le personnaliser.
Le tableau suivant résume les différences majeures entre les types d’éléments de travail et les états utilisés par les quatre processus par défaut.
| Zone de suivi | Basic | Agile | Scrum | CMMI |
|---|---|---|---|---|
| États du flux de travail | - À faire - En cours - Fait |
- Nouveau - Actif - Résolu - Fermé - Supprimé |
- Nouveau -Approuvé - Engagés - Fait - Supprimé |
-Proposé - Actif - Résolu - Fermé |
| Planification des produits (voir note 1) | - Problème | - Récit utilisateur - Bogue (facultatif) |
- Élément de backlog de produit - Bogue (facultatif) |
- Spécification - Bogue (facultatif) |
| Backlogs de portefeuille (voir note 2) | - Épopée | - Épopée - Fonctionnalité |
- Épopée - Fonctionnalité |
- Épopée - Fonctionnalité |
| Planification des tâches et des sprints (voir note 3) | - Tâche | - Tâche - Bogue (facultatif) |
- Tâche - Bogue (facultatif) |
- Tâche - Bogue (facultatif) |
| Gestion du backlog de bogues (voir Note 1) | - Problème | -Punaise | -Punaise | -Punaise |
| Gestion des problèmes et des risques | - Problème | - Problème | - Obstacle | - Demande de modification - Problème - Risque - Révision |
Note
- Ajoutez des éléments de travail à partir du backlog de produit ou du tableau. Le backlog produit affiche une vue unique du backlog actuel des éléments de travail, que vous pouvez réorganiser et regrouper dynamiquement. Les propriétaires de produits peuvent hiérarchiser le travail et décrire les dépendances et les relations. Chaque équipe peut configurer la façon dont elle souhaite que les bogues s’affichent sur leurs backlogs et leurs tableaux.
- Définissez une hiérarchie des backlogs de portefeuille pour comprendre la portée du travail de plusieurs équipes et voir comment le déploiement de ce travail s’inscrit dans le cadre d’initiatives plus larges. Chaque équipe configure les backlogs de portefeuille qui s’affichent en vue de leur utilisation.
- Définissez les tâches à partir du backlog de sprint et du tableau des tâches. Grâce à la planification de la capacité, les équipes peuvent déterminer si leur capacité est supérieure ou inférieure à celle d’un sprint.
États du workflow, transitions et raisons
Les états de workflow prennent en charge le statut du travail à mesure qu’il passe d’un état New à un état Closed ou à un état Done. Chaque workflow comprend un ensemble d’états, les transitions valides entre les états et les raisons de la transition de l’élément de travail à l’état sélectionné.
Importante
Transitions de flux de travail : Les flux de travail par défaut dans Azure DevOps prennent en charge les transitions d’état à n’importe quel état. Vous pouvez personnaliser ces flux de travail pour restreindre des transitions spécifiques en fonction des exigences de votre équipe. Pour plus d’informations, consultez Personnaliser votre expérience de suivi du travail.
Visualisation des flux de travail : Pour afficher les transitions de flux de travail prises en charge pour chaque type d’élément de travail, installez l’extension Place de marché de visualisation de modèle d’état . Cette extension ajoute un hub Visualiseur d’état sous Tableaux dans lesquels vous pouvez sélectionner un type d’élément de travail et afficher son modèle d’état de flux de travail complet.
Les diagrammes suivants montrent la progression classique des types d’éléments de travail utilisés pour suivre les erreurs de code et de travail pour les trois processus par défaut. Ils indiquent également les régressions vers d’anciens états et les transitions vers des états supprimés.
Chaque image présente uniquement la raison par défaut associée à la transition.
Récit utilisateur
Fonctionnalité
Épopée
Bug
Tâche
La plupart des types d’éléments de travail utilisés par les outils Agile, ceux qui apparaissent sur les backlogs et les tableaux, prennent en charge les transitions de et vers n’importe quel état. Mettez à jour l’état d’un élément de travail à l’aide du tableau ou du tableau des tâches. Faites glisser un élément de travail vers sa colonne d’état correspondante.
Modifiez le workflow pour prendre en charge d’autres états, transitions et raisons. Pour plus d’informations, consultez Personnaliser votre expérience de suivi du travail.
Comportement des états supprimés, fermés et terminés sur les backlogs
Lorsque vous modifiez l’état d’un élément de travail en Removed, Closed ou Done, le système répond comme suit :
-
ClosedouDone: les éléments de travail dans cet état n’apparaissent ni dans le backlog de portefeuille ni sur les pages de backlog, mais ils apparaissent sur les pages du backlog de sprint, le tableau et le tableau des tâches. Lorsque vous définissez l’affichage du backlog du portefeuille sur Afficher les éléments du backlog — par exemple, pour afficher les fonctionnalités aux côtés des éléments du backlog de produit —, les éléments de travail dans les étatsClosedetDoneapparaissent également. -
Removed: les éléments de travail dans cet état n’apparaissent dans aucun backlog ou tableau.
Note
Le flux de travail CMMI par défaut n’inclut pas d’état Removed . Pour supprimer un élément de travail CMMI du suivi actif, définissez son état Closed sur et choisissez une raison appropriée (par exemple, Différé ou Rejeté). Vous pouvez personnaliser un processus hérité pour ajouter un Removed état si votre équipe en a besoin.
Votre projet conserve les éléments de travail tant qu’il est actif. Même si vous définissez les éléments de travail sur Closed, Done ou Removed, le magasin de données conserve un enregistrement. Vous pouvez utiliser cet enregistrement pour créer des requêtes ou des rapports.
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.
Si vous devez supprimer définitivement des éléments de travail, consultez Retirer ou supprimer des éléments de travail.
Types d’éléments de travail ajoutés à tous les processus
Les types d’éléments de travail suivants sont ajoutés à tous les processus, à l’exception du processus de base.
Votre équipe peut créer et utiliser les types suivants à l’aide de l’outil correspondant. Ces types d’éléments de travail restent dans le schéma pour la compatibilité historique. Microsoft Gestionnaire de tests et l’expérience Team Explorer My Work sont des outils hérités qui sont largement remplacés par le portail web.
| Outil | Types d’éléments de travail |
|---|---|
| Microsoft Gestionnaire de tests (hérité) |
Test Plan, Test SuiteTest Case Shared Steps, Shared Parameters |
| Obtenir des commentaires |
Feedback Request, Feedback Response |
| Mon travail (dans Team Explorer, version héritée), Revue de code |
Code Review Request, Code Review Response |
Vous ne pouvez pas créer manuellement des éléments de travail à partir de ces définitions de type. Ils sont ajoutés à la Hidden Types catégorie. Les types d’éléments de travail ajoutés à la catégorie Hidden Types n’apparaissent pas dans les menus qui créent des éléments de travail.
Types d’éléments de travail qui prennent en charge l’expérience de test
Les types de liens indiqués dans l’image suivante connectent les types d’éléments de travail qui prennent en charge l’expérience de test et fonctionnent avec le Gestionnaire de tests et le portail web.
À partir du portail web ou Microsoft Gestionnaire de tests, vous pouvez afficher les cas de test définis pour une suite de tests et afficher les suites de tests définies pour un plan de test. Cependant, ces objets ne sont pas connectés entre eux via des types de lien. Personnalisez ces types d’éléments de travail comme vous le feriez pour tous les autres. Pour plus d’informations, consultez Personnaliser votre expérience de suivi du travail.
Si vous modifiez le flux de travail pour le plan de test et la suite de tests, vous devrez peut-être mettre à jour la configuration du processus, comme décrit dans cet article. Pour connaître les définitions de chaque champ de test, consultez Créer une requête basée sur des champs d’intégration de build et de test.