À propos des processus par défaut et des modèles de processus
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Azure Boards propose différents processus pour la gestion des éléments de travail. Il est essentiel de sélectionner le processus approprié pour optimiser le workflow d’un projet et garantir sa réussite. Dans cet article, nous explorons les différents processus disponibles avec Azure Boards. Cet article fournit également des conseils sur la façon de choisir le processus le plus approprié pour 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. |
| Processus | 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 une interface utilisateur WYSIWYG (tel écrit, tel écran). |
| 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 objets de suivi du travail contenus dans les processus et les modèles de processus par défaut (Basic, Agile, Capability Maturity Model Integration (CMMI) et Scrum) sont identiques. Nous les résumons dans cet article.
Conseil
Avec Azure DevOps Server, vous pouvez choisir entre 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 dans Personnaliser votre expérience de suivi du travail. Pour accéder aux dernières versions des processus/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. Vous devez utiliser une version de Visual Studio qui se trouve au même niveau de version qu’Azure DevOps Server. Vous pouvez installer gratuitement la dernière version de Visual Studio Community.
- Vous pouvez accéder aux dernières versions des 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 par les types d’élément de travail qu’ils fournissent pour la planification et le suivi du travail. Les processus par défaut sont les suivants :
- Basic : est le plus léger et est en préversion sélective.
- Scrum : est le deuxième plus léger.
- Agile : prend en charge de nombreuses conditions de la méthode Agile.
- CMMI : fournit la plus grande prise en charge des processus formels et de la gestion des changements.
Remarque
Le processus de base est disponible avec Azure DevOps Server 2019 Update 1 et versions ultérieures.
De base
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 histoires utilisateur et (éventuellement) bogues sur 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 sur la carte. 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 sont conçus pour répondre 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
De base
Agile
Scrum
CMMI
États de flux de travail
- À faire
- En cours
- Terminé
- Nouveau
- Actif
- Résolu
- Fermés
- Supprimé
- Nouveau
- Approved
- Committed
- Terminé
- Supprimé
- Proposed
- Actif
- Résolu
- Fermés
Planification de produit (voir remarque 1)
- Problème
- Récit utilisateur
- Bogue (facultatif)
- Élément du journal des travaux en souffrance du produit
- Bogue (facultatif)
- Condition requise
- Bogue (facultatif)
Backlogs de portefeuille (voir remarque 2)
- Épopée
- Épopée
- Fonctionnalité
- Épopée
- Fonctionnalité
- Épopée
- Fonctionnalité
Planification des tâches et des sprints (voir remarque 3)
- Tâche
- Tâche
- Bogue (facultatif)
- Tâche
- Bogue (facultatif)
- Tâche
- Bogue (facultatif)
Gestion du backlog de bogues (voir remarque 1)
- Problème
- Bug
- Bug
- Bug
Gestion des problèmes et des risques
- Problème
- Problème
- Obstacle
- Problème
- Risque
- Révision
Remarques :
- Ajoutez des éléments de travail à partir du backlog ou du tableau du produit. Le backlog de produit montre une vue unique du backlog actuel du travail, qu'il est possible de réorganiser et de regrouper de façon dynamique. Les propriétaires de produits peuvent rapidement classer par ordre de priorité le travail et esquisser des dépendances et des relations. En outre, chaque équipe peut configurer la façon dont elle souhaite que les bogues apparaissent dans ses backlogs et 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 rapidement déterminer si leur capacité est supérieure ou inférieure à celle d’un sprint.
États du flux de travail, transitions et raisons
Les états de flux de travail prennent en charge le statut du travail à mesure qu’il passe d’un état New à un état Closed ou à un état Done. Chaque flux de travail 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é.
Important
Pour Azure DevOps Services et Azure DevOps Server 2019, les transitions de workflow par défaut prennent en charge les transitions de et vers n’importe quel état. Personnalisez ces workflows pour limiter certaines transitions. Pour plus d’informations, consultez Personnaliser les objets de suivi de travail pour prendre en charge les processus de votre équipe.
Installez l’extension de la Place de marché Visualisation du modèle d’état pour afficher également les transitions de workflow prises en charge pour chaque type d’élément de travail. Cette extension ajoute un nouveau hub sous Tableaux, étiqueté Visualiseur d’état. Sur cette page, choisissez un type d’élément de travail et affichez le modèle d’état du workflow.
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é
Epic
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 en le faisant glisser 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.
États d’élément de travail
Lorsque vous modifiez l’état d’un élément de travail en Removed, Closed ou Done, le système répond comme suit :
Closed/Done: les éléments de travail dans cet état n’apparaissent pas dans les pages du backlog de portefeuille et du backlog. Ils apparaissent sur les pages du backlog sprint, le tableau d’administration et le tableau des tâches. Par ailleurs, lorsque vous modifiez l’affichage du backlog de portefeuille pour afficher les éléments de backlog, par exemple pour afficher les fonctionnalités des éléments de backlog de produit, les éléments de travail dans l’étatClosedetDoneapparaissent.Removed: les éléments de travail dans cet état n’apparaissent dans aucun backlog ou tableau.
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. Utilisez un enregistrement pour créer des requêtes ou des rapports.
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.
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.
| Outil | Types d'éléments de travail |
|---|---|
| Microsoft Test Manager | Test Plan, , Test SuiteTest Case Shared Steps, ,Shared Parameters |
| Obtenir des commentaires | Feedback Request, Feedback Response |
| Mon travail (à partir de Team Explorer), Révision du code | Code Review Request, Code Review Response |
Les éléments de travail de ces définitions de type ne sont pas destinés à être créés manuellement, et sont ensuite ajoutés à la catégorie Hidden Types. 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 d’éléments de travail prenant en charge l’expérience de test et fonctionnant avec Test Manager et le portail web sont liés entre eux à l’aide des types de lien illustrés dans l’image suivante.
À partir du portail web ou de Microsoft Test Manager, affichez les cas de test définis pour une suite de tests, ainsi que 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 les objets de suivi de travail pour prendre en charge les processus de votre équipe.
Si vous modifiez le flux de travail du plan de test et de la suite de tests, vous devrez peut-être mettre à jour la configuration du processus comme indiqué ici. Pour les définitions de chaque champ de test, consultez Requête basée sur des champs d’intégration de build et de test.