Processus par défaut et modèles de processus

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

Azure Boards propose différents processus de gestion des éléments de travail. La sélection du processus approprié permet d’optimiser le flux de travail du projet et de garantir la réussite de votre projet. Dans cet article, explorez les différents processus disponibles avec Azure Boards. Cet article fournit 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.
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 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 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. Nous les résumons dans cet article.

Conseil

Avec Azure DevOps Server, vous pouvez choisir entre utiliser 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 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 :

De base : est le plus léger.
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.

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.

Le diagramme montre les types d’éléments de travail de base dans une hiérarchie.

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é.

Diagramme montrant les types d’éléments de travail Agile dans une hiérarchie.

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.

Diagramme montrant les types d’éléments de travail Scrum dans une hiérarchie.

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é.

Capture d’écran montrant les types d’éléments de travail CMMI dans une hiérarchie.

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

Principales distinctions entre le 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

Basic

Agile

Scrum

CMMI

États de workflows

À faire
En cours
Terminé

Nouveau
Actif
Résolu
Fermée
Supprimé(e)

Nouveau
Approuvée
Committed
Terminé
Supprimé(e)

Proposé
Actif
Résolu
Fermée

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)

Spécification
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

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 de produit ou du tableau. 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 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 transitions de flux de travail par défaut prennent en charge n’importe quel état vers n’importe quelle transition d’état pour Azure DevOps. 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

Diagramme montrant les états du flux de travail User Story à l’aide du processus Agile.

Fonctionnalité

Diagramme montrant les états de flux de travail des fonctionnalités à l’aide du processus Agile.

Épopée

Diagramme montrant les états de flux de travail Epic à l’aide du processus Agile.

Bug

Diagramme montrant les états du workflow Bogue à l’aide du processus Agile.

Tâche

Diagramme montrant les états de flux de travail de tâche à l’aide du processus Agile.

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.

É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 ou Done : les éléments de travail dans cet état n’apparaissent pas dans les pages du backlog de portefeuille et du backlog. Toutefois, ils apparaissent sur les pages du backlog sprint, le tableau de bord et le tableau des tâches. 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’état Closed etDone apparaissent.
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. Vous pouvez utiliser cet enregistrement pour créer des requêtes ou des rapports.

Note

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.

Note

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.

Diagramme montrant les types d’éléments de travail utilisés par les plans de test, Microsoft Test Manager, My Work et Feedback.

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.

Diagramme montrant les types d’éléments de travail de gestion des tests.

À 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 votre expérience de suivi du travail.

Si vous modifiez le workflow du plan de test et de la suite de tests, vous devrez peut-être mettre à jour la configuration du processus comme indiqué ici. 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.