À propos des processus par défaut et des modèles de processus

  • Article

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 :

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.

Types d’élément de travail de base

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

Types d’élément de travail Agile

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

Types d’élément de travail Scrum

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

Types d'élément de travail CMMI

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 :

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 :

  1. Ajoutez des éléments de travail à partir du backlog de produit ou du tableau Kanban. 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.
  2. 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.
  3. 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

Capture d’écran montrant les états du flux de travail Récit utilisateur à l’aide du processus Agile.

Fonctionnalité

Capture d’écran montrant les états du flux de travail Fonctionnalité à l’aide du processus Agile.

Épopée

Capture d’écran montrant les états du flux de travail Épopée à l’aide du processus Agile.

Bug

Capture d’écran montrant les états du flux de travail Bogue à l’aide du processus Agile

Tâche

Capture d’écran montrant les états du flux de travail 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 Kanban ou du tableau des tâches en le faisant glisser vers la 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 de sprint, le tableau Kanban et le tableau de 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’é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. 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.

Capture d’écran montrant les types d’éléments de travail utilisés par Test Plans, Microsoft Test Managers, 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 Suite, Test 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.

Capture d’écran montrant les types d’éléments de travail de gestion de test.

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