- Article
- 12 minutes de lecture
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018
Chaque fois que vous créez un projet, vous devez choisir un modèle de processus ou de processus basé sur le modèle de processus sélectionné pour votre organisation ou collection. Lorsque vous choisissez un processus pour votre projet, il est important de comprendre les termes suivants :
- Un modèle de processus fait référence au modèle utilisé pour prendre en charge les projets créés pour une organisation (Azure DevOps Services) ou une collection de projets (Azure DevOps Server). Un seul modèle de processus est pris en charge pour un projet à la fois. Une comparaison des trois modèles de processus (Héritage, XML local et XML hébergé) est fournie dans Personnaliser le suivi du travail.
- Un 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.
- Un 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 personnalisez des projets en modifiant et en important des fichiers de définition XML de modèle de processus.
Notes
Pour obtenir des conseils sur la configuration et la personnalisation de votre projet et de vos équipes pour répondre aux besoins de votre entreprise, consultez Configuration et personnalisation de Azure Boards.
Pour plus d’informations sur la création d’un projet à l’aide du processus de votre choix, consultez Créer un projet. Pour en savoir plus sur les modèles de processus, consultez Personnaliser votre expérience de suivi du travail.
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 Personnaliser votre expérience de suivi du travail, Choisir le modèle de processus pour votre collection de projets. Pour accéder aux dernières versions des processus/modèles de processus par défaut :
- Pour modèle de processus hérité : ouvrez la page Processus à partir des paramètres de l’organisation. Pour plus d’informations, consultez Gérer les processus.
- Pour le modèle de processus XML local :
- Installer ou mettre à niveau vers la dernière version de 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 que 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.
Conseil
Pour accéder aux dernières versions des modèles de processus par défaut :
- Installez ou mettez à niveau vers la dernière version de TFS.
- 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 que TFS. 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 TFS 2018 ici :
%programfiles%/TFS 16.0/Tools/Deploy/ProcessTemplateManagerFiles/1033. Pour obtenir une description de chaque fichier et dossier, consultez Vue d’ensemble des fichiers de modèle de processus.
Les objets de suivi du travail contenus dans les processus et les modèles de processus par défaut (De base, Agile, CMMI et Scrum) sont identiques et résumés ci-dessous. Le processus de base est disponible à partir de Azure DevOps Server 2019.1 et versions ultérieures. Par souci de simplicité, ils sont appelés « processus ».
Conseil
Pour afficher et gérer les modèles de processus hérités, consultez Gérer les processus.
Choisir un processus De base, Agile, Scrum et CMMI
Les processus par défaut diffèrent principalement par les types d’éléments de travail (WIT) qu’ils fournissent pour la planification et le suivi du travail.
Basic est le plus léger et se trouve dans une préversion sélective.Scrum est le deuxième plus léger. Agile prend en charge de nombreux termes de méthode Agile, et CMMI, qui signifie Capability Maturity Model Integration, fournit la prise en charge la plus efficace des processus formels et de la gestion des changements.
Notes
Le processus de base est disponible avec Azure DevOps Server 2019 Update 1 et versions ultérieures.
Choisissez le processus qui convient le mieux à votre équipe.
De base
Choisissez De base lorsque votre équipe souhaite utiliser le modèle le plus simple qui utilise les problèmes, les tâches et les épopées 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 très bien si vous souhaitez suivre les récits utilisateur et (éventuellement) les bogues sur le tableau Kanban, ou suivre les bogues et les tâches dans le tableau des tâches.
Pour en savoir plus 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 Scrum. Ce processus fonctionne très bien si vous souhaitez suivre les éléments de backlog de produits (PBIs) et les bogues sur le tableau Kanban, ou décomposer les PBIs et les bogues en tâches dans le tableau des tâches.
Ce processus prend en charge la méthodologie Scrum telle que définie par l’organisation Scrum.
Les tâches prennent uniquement en charge le suivi du travail restant.
CMMI
Choisissez CMMI lorsque votre équipe suit des méthodes de projet plus formelles qui nécessitent une infrastructure pour l’amélioration des processus et un enregistrement vérifiable des décisions. 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, vous pouvez en ajouter 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.
Principales distinctions 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, vous pouvez personnaliser un processus, puis créer le projet.Vous pouvez également créer un projet à partir d’un processus, puis le personnaliser.
Le tableau suivant récapitule les principales distinctions entre les WIT 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 remarque1)
- 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 (2)
- Épopée
- Épopée
- Fonctionnalité
- Épopée
- Fonctionnalité
- Épopée
- Fonctionnalité
Planification des tâches et des sprints (3)
- Tâche
- Tâche
- Bogue (facultatif)
- Tâche
- Bogue (facultatif)
- Tâche
- Bogue (facultatif)
Gestion du backlog des bogues (1)
- Problème
- Bug
- Bug
- Bug
Gestion des problèmes et des risques
- Problème
- Problème
- Obstacle
- Problème
- Risque
- Révision
Notes
- Vous pouvez ajouter ces WIT à partir du backlog produit ou du tableau Kanban. Le backlog produit affiche une vue unique du backlog actuel du travail qui peut être ré-ordonné dynamiquement et regroupé. Les propriétaires de produits peuvent rapidement hiérarchiser le travail et décrire les dépendances et les relations.
En outre, chaque équipe peut configurer la façon dont elle souhaite que les bogues s’affichent sur ses backlogs et ses tableaux. - En utilisant les backlogs de portefeuille, vous pouvez définir une hiérarchie de backlogs pour comprendre la portée du travail entre plusieurs équipes et voir comment ce travail se déroule avec une perspective plus large. Chaque équipe peut configurer les backlogs de portefeuille qui s’affichent pour leur utilisation.
- Vous pouvez définir des 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 elles sont en sur-capacité ou en dessous 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 nouvel état à un état fermé ou terminé. 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 flux de travail par défaut prennent en charge n’importe quel état vers n’importe quelle transition d’état. Vous pouvez personnaliser ces flux de travail pour limiter certaines transitions . Consultez Personnaliser les objets de suivi du travail pour prendre en charge les processus de votre équipe.
Vous pouvez également afficher les transitions de flux de travail prises en charge pour chaque type d’élément de travail en installant l’extension Markeplace de visualisation du modèle d’état. Cette extension ajoute un nouveau hub sous Tableaux étiquetés Visualiseur d’état. Sur cette page, vous pouvez choisir un type d’élément de travail et afficher le modèle d’état du flux de travail.
Les diagrammes suivants illustrent la progression vers l’avant typique des WIT utilisés pour suivre les défauts de travail et de code 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.
- Processus Agile
- Processus De base
- Processus Scrum
- Processus CMMI
Récit utilisateur
Fonctionnalité
Épopée
Bug
Tâche
La plupart des WIT utilisés par les outils Agile, ceux qui apparaissent sur les backlogs et les tableaux, prennent en charge les transitions n’importe où. Vous pouvez mettre à jour l’état d’un élément de travail à l’aide du tableau Kanban ou du tableau des tâches en le faisant glisser vers sa colonne d’état correspondante.
Vous pouvez modifier le flux de travail pour prendre en charge d’autres états, transitions et raisons. Pour plus d’informations, consultez Personnaliser votre expérience de suivi professionnel.
États Supprimé, Fermé et Terminé
Quand vous faites passer un élément de travail à l'état Supprimé, Fermé ou Terminé, le système répond comme suit:
- Fermé ou terminé : les éléments de travail dans cet état n’apparaissent pas sur les pages backlog et backlog du portefeuille. Toutefois, ils s’affichent sur les pages du backlog de sprint, le tableau Kanban et le tableau des tâches. En outre, lorsque vous modifiez l’affichage du backlog de portefeuille pour afficher les éléments du backlog, par exemple, pour afficher les fonctionnalités des éléments du backlog de produit, les éléments de travail à l’état fermé et terminé s’affichent.
- Supprimé : les éléments de travail dans cet état n’apparaissent sur aucun backlog ou tableau.
Les éléments de travail sont conservés dans un projet tant que le projet est actif.Même si vous leur attribuez l'état Fermé, Terminé ou Supprimé, un enregistrement est conservé dans le magasin de données.Vous pouvez utiliser un enregistrement pour créer des requêtes ou des rapports.
Notes
Les éléments de travail terminés ou fermés ne s’affichent pas sur les backlogs et les tableaux une fois leur date de modification supérieure à 183 jours (environ un demi-an). Vous pouvez toujours répertorier ces éléments à l’aide d’une requête. Si vous souhaitez qu’ils s’affichent sur un backlog ou un tableau, vous pouvez y apporter une modification mineure qui réinitialise l’horloge.
Notes
Les éléments de travail terminés ou fermés ne s’affichent pas sur les backlogs et les tableaux une fois leur date de modification supérieure à un an. Vous pouvez toujours répertorier ces éléments à l’aide d’une requête. Si vous souhaitez qu’ils s’affichent sur 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 Supprimer ou supprimer des éléments de travail.
Types d’éléments de travail ajoutés à tous les processus
Les WIT suivants sont ajoutés à tous les processus, à l’exception du processus de base.
Les équipes créent et utilisent les types suivants à l'aide de l'outil correspondant:
- Plan de test, suite de tests, étapes partagées de cas de test et paramètres partagés : Microsoft Test Manager.
- Demande de commentaire et réponse aux commentaires: Demande de commentaire.
- Demande de révision du code et Réponse de révision du code: Mon travail (Team Explorer) et Demande de révision du code.
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 Types masqués.Les types d’éléments de travail ajoutés à la catégorie Types masqués n’apparaissent pas dans les menus qui créent de nouveaux éléments de travail.
Types d'éléments de travail prenant en charge l'expérience de test
Les WIT qui prennent en charge l’expérience de test et fonctionnent avec le Gestionnaire de tests et le portail web sont liés à l’aide des types de liens illustrés dans l’image suivante.
À partir du portail web ou du Gestionnaire de tests Microsoft, vous pouvez afficher les cas de test définis pour une suite de tests. Vous pouvez également voir quelles suites de test sont définies pour un plan de test.Toutefois, ces objets ne sont pas connectés les uns aux autres par le biais de types de liens.Personnalisez ces WIT comme vous le feriez pour tout autre WIT.Consultez Personnaliser les objets de suivi du 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 obtenir les définitions de chaque champ de test, consultez Requête basée sur des champs d’intégration de build et de test.
Articles connexes
Vous pouvez personnaliser un processus avant ou après la création d’un projet qui utilise le processus. Les méthodes que vous utilisez dépendent du modèle de processus que vous utilisez. Pour plus d’informations, consultez Personnaliser votre expérience de suivi professionnel.
- Modèles de processus de chargement/téléchargement
- Modifications apportées aux modèles de processus
- Configurer les fonctionnalités après une mise à niveau de Azure DevOps Server
Si vous avez d’autres questions, consultez la page de support Azure DevOps.