À propos de la personnalisation des processus et des processus hérités

  • Article

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

Pour personnaliser le système de suivi du travail, vous personnalisez un processus hérité via l’interface utilisateur administrative de l’organisation. Tous les projets qui utilisent un processus hérité obtiennent les personnalisations apportées à ce processus. En revanche, vous configurez vos outils Agile ( Backlogs, Sprints, Tableaux Kanban et Taskboard) pour chaque équipe.

Important

Pour personnaliser un projet local ou mettre à jour des fichiers de définition XML pour prendre en charge la personnalisation, consultez le modèle de processus XML local. Cet article s’applique uniquement à Azure DevOps Services et Azure DevOps Server 2019.

Il existe un certain nombre de personnalisations que vous pouvez effectuer. Les principaux sont l’ajout de types d’éléments de travail personnalisés (WIT) ou la modification d’un WIT existant pour ajouter des champs personnalisés, modifier la disposition ou modifier le flux de travail.

Remarque

Vous pouvez passer en revue les modifications apportées à un processus hérité via le journal d’audit. Pour plus d’informations, consultez Accéder, exporter et filtrer les journaux d’audit.

Vous trouverez ci-dessous un index pour ces tâches que vous pouvez effectuer pour personnaliser un processus hérité. Certaines options d’éléments hérités sont verrouillées et ne peuvent pas être personnalisées.

Processus système et hérités

Vous verrez deux types de processus :

  • locked icon Processus système ( Agile, Basic, Scrum et CMMI) qui sont verrouillés d’être modifiés.
  • inherited icon Processus hérités, que vous pouvez personnaliser et qui héritent des définitions du processus système à partir duquel ils ont été créés. Les processus système sont détenus et mis à jour régulièrement par Microsoft. Toutes les mises à jour apportées à un processus système provoquent automatiquement une mise à jour de vos processus hérités et de leurs processus hérités enfants. Mises à jour aux processus sont documentés dans le Notes de publication pour Azure DevOps Server.

Remarque

Le processus de base est disponible avec Azure DevOps Server 2019 Update 1 et versions ultérieures.

En outre, tous les processus sont partagés. Autrement dit, un ou plusieurs projets peuvent utiliser un seul processus. Au lieu de personnaliser un projet unique, vous personnalisez un processus. Les modifications apportées au processus mettent automatiquement à jour tous les projets qui utilisent ce processus. Une fois que vous avez créé un processus hérité, vous pouvez le personnaliser, créer des projets en fonction de celui-ci, en faire une copie et modifier les projets existants pour l’utiliser.

Par exemple, comme illustré dans l’image suivante, vous voyez une liste de projets définis pour l’organisation fabrikam . La deuxième colonne montre le processus utilisé par chaque projet. Pour modifier les personnalisations du projet Fabrikam Fiber , vous devez modifier le processus MyScrum (qui hérite du processus système Scrum ). Toutes les modifications apportées au processus MyScrum mettent également à jour d’autres projets qui utilisent ce processus. Vous ne pouvez pas personnaliser le projet de test de requête, d’autre part, tant que vous ne le modifiez pas en un processus qui hérite d’Agile.

Screenshot of Admin context, Organization settings, Project list and the process they use.

Restrictions de nom de processus

Les noms de processus doivent être uniques et 128 caractères Unicode ou moins. En outre, les noms ne peuvent pas contenir les caractères suivants : .,;'`:~\/\*|?"&%$!+=()[]{}<>.

Pour renommer un processus, ouvrez le ... menu contextuel du processus et choisissez Modifier.

Modifier le processus de référence d’un projet

Si vous souhaitez basculer le processus qu’un projet utilise d’un processus système à un autre, vous pouvez le faire. Pour apporter ces modifications, vous devez créer un processus hérité en fonction du processus vers lequel vous souhaitez basculer. Par exemple, des instructions sont fournies pour prendre en charge les modifications suivantes :

En suivant les instructions fournies dans les articles répertoriés ci-dessus, vous pouvez également apporter des modifications supplémentaires, par exemple, de CMMI à Agile ou Agile à CMMI.

Avant d’effectuer cette modification, nous vous recommandons de vous familiariser avec le processus vers lequel vous changez. Les processus système sont résumés dans À propos des processus et des modèles de processus.

Meilleures pratiques lors de l’apport de modifications

Apporter des modifications à un processus hérité est tout à fait clair et sûr. Toutefois, il est toujours recommandé de tester ces modifications avant de les appliquer à un projet actif. Le suivi de ces étapes vous aidera à exposer les effets négatifs sur vos modifications de processus.

Objets hérités et objets personnalisés

Chaque processus hérité que vous créez hérite des WIT définis dans le processus système : De base, Agile, Scrum ou CMMI. Par exemple, le processus Agile fournit un bogue, une tâche, un récit utilisateur, une fonctionnalité, une épopée, un problème et des WIT liés aux tests.

Conceptual image of Agile process work item hierarchy.

Vous pouvez ajouter des champs et modifier le flux de travail et le formulaire d’élément de travail pour tous les WIT hérités qui s’affichent sur la page Types d’éléments de travail. Si vous ne souhaitez pas que les utilisateurs créent un WIT, vous pouvez le désactiver. En outre, vous pouvez ajouter des WIT personnalisés.

Personnalisations des champs

Les champs définis dans le processus système apparaissent avec une icône héritée, indiquant que vous pouvez y apporter des modifications limitées dans votre processus hérité.

Les champs sont définis pour tous les projets et processus de l’organisation. Cela signifie que tout champ personnalisé que vous avez défini pour un WIT dans un processus peut être ajouté à n’importe quel autre WIT défini pour un autre processus.

Type de champ

Prise en charge de la personnalisation

Champs hérités

Champs personnalisés

Contrôle personnalisé

Lorsque vous ajoutez des champs personnalisés, tenez compte des limites suivantes :

  • 64 champs maximum peuvent être définis pour chaque type d’élément de travail.
  • 512 champs maximum peuvent être définis pour chaque processus.

En outre, vous pouvez ajouter un champ existant à un autre WIT au sein du processus. Par exemple, vous pouvez ajouter une date d’échéance à l’histoire de l’utilisateur ou à des wits de bogues.

Ce que vous ne pouvez pas personnaliser

  • Vous ne pouvez pas modifier le nom du champ ou le type de données une fois que vous l’avez défini
  • Vous ne pouvez pas modifier la zone grise sur le formulaire où se trouvent les champs État, Raison, Chemin d’accès à la zone et chemin d’itération.
  • Vous ne pouvez pas importer ou définir une liste globale prise en charge par les modèles de processus XML hébergés et XML locaux. Pour en savoir plus, consultez Définir des listes globales.
  • Vous ne pouvez pas modifier le nom du champ ou le type de données une fois que vous l’avez défini
  • Vous ne pouvez pas modifier la zone grise sur le formulaire où se trouvent les champs État, Raison, Chemin d’accès à la zone et chemin d’itération.
  • En ce qui concerne les listes de sélections, vous ne pouvez actuellement pas effectuer ces opérations :
    • Modifier la liste de sélection d’un champ hérité, tel que le champ Activité ou Discipline
    • Modifier l’ordre de sélection, les listes de sélection s’affichent dans l’ordre alphabétique
  • Vous ne pouvez pas modifier le texte d’aide description des champs hérités
  • Importez ou définissez une liste globale comme prise en charge par les modèles de processus XML hébergés et XML locaux. Pour en savoir plus, consultez Définir des listes globales.

Remarque

Avec le processus hérité, vous ne pouvez pas modifier les listes de sélection de champs prédéfinis, tels que l’activité, l’état Automation, la discipline, la priorité, ainsi que d’autres.

Listes de choix configurables

Les listes de sélection suivantes sont configurées pour chaque projet et ne peuvent pas être personnalisables par le biais d’un processus hérité.

Les listes de sélection associées aux champs de nom de personne, tels que Affectés à et Modifié par, sont gérées en fonction des utilisateurs que vous ajoutez à un projet ou à une équipe.

Puis-je renommer un champ ou modifier son type de données ?

Le renommage d’un champ ou la modification du type de données ne sont pas pris en charge. Toutefois, vous pouvez modifier l’étiquette qui s’affiche pour un champ du formulaire élément de travail sous l’onglet Disposition. Lorsque vous sélectionnez le champ dans une requête, vous devez sélectionner le nom du champ et non l’étiquette de champ.

Puis-je supprimer ou restaurer un champ supprimé ?

Vous pouvez supprimer un champ et le restaurer ultérieurement. La suppression d’un champ supprime toutes les données associées à ce champ, y compris les valeurs historiques. Une fois supprimé, vous pouvez uniquement restaurer le champ et récupérer les données à l’aide de l’API REST Champs - Mettre à jour.

Au lieu de supprimer un champ, vous souhaiterez peut-être masquer ou supprimer le champ d’un formulaire d’élément de travail. Pour plus d’informations, consultez Ajouter et gérer des champs, Afficher, masquer ou supprimer un champ.

Définition et contexte d’utilisation des champs

Chaque type d’élément de travail est associé à 31 champs système ainsi qu’à d’autres champs qui lui sont propres. Les éléments de travail permettent de planifier et de suivre un projet.

Chaque champ prend en charge le suivi d’une information sur le travail à effectuer. Les valeurs affectées à un champ sont stockées dans le magasin de données de suivi du travail, dont vous pouvez déterminer l’état et les tendances à l’aide de requêtes.

Pour obtenir des descriptions et l’utilisation de chaque champ défini pour les processus système principaux ( Processus système Scrum, Agile et CMMI), consultez l’index du champ Élément de travail.

Noms de champs

Un nom de champ d'élément de travail identifie uniquement chaque champ d'élément de travail. Assurez-vous que le nom de vos champs respecte les règles suivantes :

  • Les noms de champs doivent être uniques au sein de l’organisation ou de la collection de projets
  • Il doit comporter 128 caractères Unicode maximum.
  • Il ne doit pas contenir ni espaces de début et de fin, ni espaces consécutifs.
  • Il doit contenir au moins un caractère alphabétique.
  • Il ne doit pas contenir les caractères suivants : .,;'`:~\/\*|?"&%$!+=()[]{}<>.

Étant donné que tous les champs sont définis pour l’organisation, vous ne pouvez pas ajouter un champ personnalisé portant le même nom de champ que celui qui existe déjà dans l’organisation ou qui a été ajouté à un WIT dans un autre processus hérité.

Remarque

Lorsque vous modifiez un projet pour utiliser un processus hérité, un ou plusieurs outils agiles ou éléments de travail peuvent apparaître dans un état non valide. Par exemple :

  • Si vous créez un champ obligatoire, les éléments de travail avec ce champ non défini affichent un message d’erreur. Vous devez résoudre les erreurs pour apporter des modifications supplémentaires et enregistrer l’élément de travail.
  • Si vous ajoutez ou supprimez/masquez les états de flux de travail d’un WIT qui apparaît sur le tableau Kanban, vous devez mettre à jour les configurations de colonne du tableau Kanban pour toutes les équipes définies dans le projet.

Règles personnalisées et règles système

Chaque WIT (bogue, tâche, récit utilisateur, etc.) comporte plusieurs règles système déjà définies. Certains sont simples, comme rendre le champ Titre requis ou définir une valeur par défaut pour le champ Zone de valeur. En outre, un certain nombre de règles système définissent des actions à entreprendre lorsqu’un état de workflow change.

Par exemple, plusieurs règles existent pour copier l’identité utilisateur actuelle dans les conditions suivantes :

  • Lorsqu’un élément de travail est modifié, copiez l’identité de l’utilisateur dans le champ Modifié par
  • Lorsque l’état du flux de travail passe à Fermé ou Terminé, copiez l’identité de l’utilisateur dans le champ Fermé par.

Important

Les règles système prédéfinies prennent un précédent sur toute règle personnalisée que vous définissez qui le remplacerait.

Les règles personnalisées prennent en charge un certain nombre de cas d’usage métier, ce qui vous permet d’aller au-delà de la définition d’une valeur par défaut pour un champ ou de la rendre nécessaire. Les règles vous permettent d’effacer la valeur d’un champ, de copier une valeur dans un champ et d’appliquer des valeurs en fonction des dépendances entre les valeurs des différents champs.

Avec une règle personnalisée, vous pouvez définir un certain nombre d’actions en fonction de conditions spécifiques. Par exemple, vous pouvez appliquer une règle pour prendre en charge ces types de scénarios :

  • Lorsqu’une valeur est définie pour Priority, faites en sorte que le champ Risque soit obligatoire
  • Lorsqu’une modification est apportée à la valeur de Release, effacez la valeur de « Jalon »
  • Lorsqu’une modification a été apportée à la valeur du travail restant, effectuez le travail terminé comme champ obligatoire
  • Lorsque la valeur Approuvé est True, effectuez l’approbation par un champ obligatoire
  • Lorsqu’un récit utilisateur est créé, effectuez les champs suivants : Priorité, Risque et Effort

Conseil

Vous ne pouvez pas définir de formule à l’aide d’une règle. Toutefois, vous trouverez peut-être une solution qui répond à vos besoins avec l’extension Power Automate ou TFS Aggregator (Web Service) Marketplace. Voir également Cumul du travail et d’autres champs.

Pour plus d’informations sur la définition de règles personnalisées, consultez Règles et évaluation des règles.

Restreindre la modification des champs sélectionnés pour sélectionner des groupes d’utilisateurs

À l’aide de l’une des deux conditions suivantes, vous pouvez définir des champs sélectionnés requis pour un utilisateur d’un groupe de sécurité ou qui ne sont pas membres d’un groupe de sécurité.

  • current user is a member of a group...
  • current user is not a member of a group...

Par exemple, vous pouvez effectuer le titre ou le champ État en lecture seule pour sélectionner des utilisateurs ou des groupes.

Restreindre la modification des éléments de travail en fonction du chemin d’accès à la zone

Vous pouvez interdire aux utilisateurs de modifier les éléments de travail sélectionnés en définissant des autorisations sur un chemin d’accès à la zone. Il ne s’agit pas d’un paramètre de règle, mais d’un paramètre d’autorisation. Pour plus d’informations, consultez Créer des nœuds enfants, modifier des éléments de travail sous un chemin d’accès de zone.

Personnalisations de type d’élément de travail (WIT)

Voici vos options de personnalisation pour les WIT hérités et personnalisés.

Type d'élément de travail

Prise en charge de la personnalisation

Types d’éléments de travail hérités

Types d’éléments de travail personnalisés

Ce que vous ne pouvez pas personnaliser

  • Vous ne pouvez pas ajouter ou supprimer un WIT hérité dans ou à partir d’un backlog
  • Vous ne pouvez pas modifier la position d’un champ hérité dans la disposition du formulaire (toutefois, vous pouvez masquer le champ dans une zone du formulaire et l’ajouter ailleurs dans le formulaire)
  • Vous ne pouvez pas supprimer le niveau de portefeuille hérité du produit (mais vous pouvez les renommer)
  • Vous ne pouvez pas modifier le nom d’un WIT personnalisé.

Personnalisations des formulaires d’élément de travail

Vous pouvez effectuer les personnalisations suivantes sur un formulaire WIT.

Type de groupe ou de page

Prise en charge de la personnalisation

Groupes hérités

Groupes personnalisés

Pages héritées

Pages personnalisées

Disposition et redimensionnement

La disposition de formulaire web est organisée en trois colonnes, comme illustré dans l’image ci-dessous.

Illustration of 3-column page layout for work item form.

Si vous ajoutez uniquement des groupes et des champs aux deux premières colonnes, la disposition reflète une disposition à deux colonnes. De même, si vous ajoutez uniquement des groupes et des champs à la première colonne, la disposition reflète une disposition d’une colonne.

Le formulaire web est redimensionné en fonction de la largeur disponible et du nombre de colonnes dans la disposition. À la largeur maximale, dans la plupart des navigateurs web, chaque colonne d’une page s’affiche dans sa propre colonne. À mesure que la largeur d’affichage diminue, chaque colonne est redimensionnée proportionnellement comme suit :

  • Pour trois colonnes : 50 %, 25 % et 25 %
  • Pour deux colonnes : 66 % et 33 %
  • Pour une colonne : 100 %.

Lorsque la largeur d’affichage ne prend pas en charge toutes les colonnes, les colonnes apparaissent empilées dans la colonne à gauche.

Personnalisations des workflows

Vous pouvez personnaliser le flux de travail de n’importe quel type d’élément de travail (WIT) en masquant les états hérités ou en ajoutant des états personnalisés. Les états hérités diffèrent en fonction du processus système (Agile, Basic, Scrum ou CMMI), que vous avez choisi pour créer votre processus personnalisé.

Chaque flux de travail par défaut pour chaque WIT définit entre deux et quatre États et spécifie les opérations de flux de travail suivantes :

  • Transitions vers l’avant et vers l’arrière entre chaque état
  • Raisons par défaut de chaque transition d’état

Par exemple, le processus de base, Issue WIT est caractérisé par les trois États (To Do, Doing et Done) et les transitions présentées dans l’image suivante.

Basic Process, Issue work item type, workflow state model

Types d’état

Personnalisations prises en charge

Inherited icon États hérités

États personnalisés

Les états de flux de travail doivent être conformes aux règles suivantes

  • Vous devez définir au moins un état pour les catégories Proposées ou En cours

    Remarque

    Avant d’ajouter un état de flux de travail, passez en revue les états de flux de travail et les catégories d’état pour découvrir comment les états de flux de travail correspondent aux catégories d’état.

  • Vous devez définir au moins deux états de flux de travail
  • Vous pouvez définir un maximum de 32 états de flux de travail par type d’élément de travail

Personnalisations de flux de travail non prises en charge

  • Vous ne pouvez pas modifier un état hérité (vous ne pouvez pas modifier son nom, sa couleur ou sa catégorie), mais vous pouvez le masquer
  • Vous ne pouvez avoir qu’un seul état dans la catégorie d’état Terminé . Si vous ajoutez un état personnalisé à la catégorie Terminée, tout autre état est supprimé ou masqué
  • Vous ne pouvez pas modifier le nom d’un état personnalisé
  • Vous ne pouvez pas spécifier une raison d’un état, à la place, les raisons par défaut sont définies comme Déplacé vers l’état Triaged, Déplacé hors état Triaged
  • Vous ne pouvez pas modifier l’emplacement des champs État et Raison dans le formulaire
  • Vous ne pouvez pas personnaliser les noms des catégories d’état
  • Vous ne pouvez pas modifier un état hérité (vous ne pouvez pas modifier son nom, sa couleur ou sa catégorie), mais vous pouvez le masquer
  • Vous ne pouvez avoir qu’un seul état dans la catégorie d’état Terminé . Le système interdit l’ajout d’un état personnalisé à cette catégorie
  • Vous ne pouvez pas modifier le nom d’un état personnalisé
  • Vous ne pouvez pas modifier l’ordre des états, les états sont répertoriés dans leur séquence naturelle en fonction de leur catégorie d’état dans la liste déroulante d’un formulaire d’élément de travail
  • Vous ne pouvez pas spécifier une raison d’un état, à la place, les raisons par défaut sont définies comme Déplacé vers l’état Triaged, Déplacé hors état Triaged
  • Vous ne pouvez pas modifier l’emplacement des champs État et Raison dans le formulaire
  • Vous ne pouvez pas restreindre les transitions, toutes les transitions sont définies d’un état à un autre état.

Personnalisations du backlog et de la carte

Les backlogs et les tableaux sont des outils Agile essentiels pour créer et gérer le travail d’une équipe. Les backlogs standard (produit, itération et portefeuille) hérités du processus système sont entièrement personnalisables. En outre, vous pouvez ajouter des backlogs de portefeuille personnalisés pour un total de cinq backlogs de portefeuille.

Types de backlog

Prise en charge de la personnalisation

Backlogs hérités

Backlogs de portefeuille personnalisés

Ce que vous ne pouvez pas personnaliser

  • Vous ne pouvez pas supprimer un niveau de portefeuille hérité du produit (mais vous pouvez renommer le niveau de portefeuille et désactiver un type d’élément de travail hérité)
  • Vous ne pouvez pas insérer un niveau de backlog dans l’ensemble existant de backlogs définis
  • Vous ne pouvez pas réorganiser les niveaux de backlog
  • Vous ne pouvez pas ajouter un type d’élément de travail à deux niveaux de backlog différents
  • Vous ne pouvez pas créer un niveau de backlog de tâches personnalisé, bien que vous puissiez ajouter des WIT personnalisés au backlog d’itération
  • Vous ne pouvez pas ajouter le bogue WIT au niveau du backlog. Au lieu de cela, le système permet à chaque équipe de décider de la façon dont elle souhaite gérer les bogues. Pour plus d’informations, consultez Afficher les bogues sur les backlogs et les tableaux.
  • Vous ne pouvez pas ajouter ou supprimer un WIT hérité dans ou à partir d’un backlog, par exemple, vous ne pouvez pas ajouter le wit de problème au backlog du produit.
  • Vous ne pouvez pas supprimer un niveau de portefeuille hérité du produit (mais vous pouvez renommer le niveau de portefeuille et désactiver un type d’élément de travail hérité)
  • Vous ne pouvez pas insérer un niveau de backlog dans l’ensemble existant de backlogs définis
  • Vous ne pouvez pas réorganiser les niveaux de backlog
  • Vous ne pouvez pas ajouter un type d’élément de travail à deux niveaux de backlog différents
  • Vous ne pouvez pas créer un niveau de tâche personnalisé, même si vous pouvez ajouter des types d’éléments de travail personnalisés au backlog d’itération
  • Vous ne pouvez pas ajouter le bogue WIT au niveau du backlog. Au lieu de cela, le système permet à chaque équipe de décider de la façon dont elle souhaite gérer les bogues. Pour plus d’informations, consultez Afficher les bogues sur les backlogs et les tableaux.

Remarque

Certaines fonctionnalités nécessitent l’installation de la mise à jour d’Azure DevOps Server 2020.1. Pour plus d’informations, consultez Notes de publication d’Azure DevOps Server 2020 Update 1 RC1, Tableaux.

Lorsque vous modifiez le WIT par défaut pour un niveau de backlog, il entraîne l’affichage de WIT par défaut dans le panneau d’ajout rapide. Par exemple, le ticket client apparaît par défaut dans le panneau d’ajout rapide suivant pour le backlog du produit.

Screenshot of Product backlog, Quick Add Panel, Displays Default WIT for a backlog level

Limites des objets

Pour obtenir la liste des limites placées sur le nombre de champs, wiTs, niveaux de backlog et autres objets que vous pouvez personnaliser, consultez les limites des objets de suivi du travail.