Partager via

Personnalisation et héritage du processus

Azure DevOps Services

Pour adapter le système de suivi du travail Azure DevOps aux besoins de votre organisation, vous pouvez personnaliser un processus hérité via les paramètres de l’organisation. Tous les projets d’une organisation qui utilisent le processus hérité obtiennent les personnalisations que vous apportez à ce processus. Vous pouvez ensuite configurer des backlogs de projet, des sprints et des tableaux pour chaque équipe de projet.

Important

Cet article s’applique uniquement au modèle de processus d’héritage dans Azure DevOps Services. Pour personnaliser des projets locaux ou mettre à jour des fichiers de définition XML, consultez le modèle de processus XML hébergé et personnaliser un processus XML hébergé.

Vous pouvez effectuer plusieurs personnalisations pour les processus hérités. Les plus importants sont la création de types d’éléments de travail personnalisés (WIT) ou la modification de wits existants pour ajouter des champs personnalisés, modifier des dispositions ou modifier des flux de travail. Certaines options d’éléments hérités sont verrouillées et ne peuvent pas être personnalisées.

Cet article fournit une vue d’ensemble des façons de personnaliser les processus hérités. Pour plus d’informations sur les limites relatives au nombre de champs, de wiT, de niveaux de backlog et d’autres objets que vous pouvez personnaliser, voir Suivi du travail, processus et limites de projet.

Remarque

Vous pouvez passer en revue les modifications apportées à un processus hérité à l’aide des fonctionnalités de journal d’audit et d’audit. Pour plus d’informations, consultez Access, exporter et filtrer les journaux d’audit.

Processus système et processus hérités

Les processus systèmeAgile, Basic, Scrum et Capability Maturity Model Integration (CMMI) sont verrouillés et les utilisateurs ne peuvent pas les modifier. Microsoft possède ces processus système et les met à jour régulièrement.

Les processus hérités sont personnalisés à partir de processus système et héritent des définitions du processus système sur lequel ils sont basés. Toutes les mises à jour que Microsoft effectue sur les processus système sont automatiquement appliquées aux processus hérités et à leurs sous-processus hérités.

Tous les projets d’une organisation peuvent partager tous ses processus. Vous personnalisez le processus au lieu de personnaliser les projets uniques.

Une fois que vous avez créé un processus hérité, vous pouvez le personnaliser, le copier, créer des projets en fonction de celui-ci et modifier les projets existants pour l’utiliser. Les modifications apportées au processus hérité mettent automatiquement à jour tous les projets de l’organisation qui utilisent ce processus.

L’exemple suivant montre une liste de projets dans l’organisation fabrikamprime et le processus que chaque projet utilise. Pour modifier les personnalisations du projet Fabrikam Fibre , vous modifiez le processus My Agile , qui hérite du processus système Agile . Les modifications que vous apportez au processus My Agile mettent également à jour le projet Agile par conception qui utilise ce processus. Pour personnaliser les autres projets, vous devez les modifier pour utiliser des processus hérités.

Capture d’écran des projets et des processus qu’ils utilisent.

Modifier le processus d’un projet existant

Vous pouvez basculer le processus qu’un projet utilise d’un processus à un autre. Pour plus d’informations et d’instructions, consultez les articles suivants :

En suivant les conseils généraux des articles répertoriés, vous pouvez apporter d’autres modifications telles que CMMI à Agile ou Agile à CMMI. Avant de modifier un processus de projet, familiarisez-vous avec le processus auquel vous changez. Pour plus d’informations, consultez À propos des processus et des modèles de processus.

Lorsque vous effectuez une transition d’un projet vers un autre processus, certains outils existants ou éléments de travail peuvent devenir non valides. Par exemple, les éléments de travail qui n’ont pas de champ requis dans le nouveau processus peuvent afficher des erreurs. Pour continuer avec les modifications et enregistrer les éléments de travail, vous devez résoudre ces erreurs. Si la modification du processus ajoute, supprime ou masque les états de flux de travail d’un WIT qui apparaît sur une carte, veillez à mettre à jour les configurations de colonne de carte pour toutes les équipes définies dans le projet.

Modifier ou renommer un processus hérité

La modification d’un processus hérité est simple, mais il est préférable de tester les modifications avant de les appliquer à un projet actif. Vous pouvez d’abord copier un processus et apporter vos modifications au processus copié pour éviter d’affecter les projets existants et vous aider à exposer les effets négatifs des modifications du processus.

Vous pouvez renommer un processus hérité dans les paramètres de l’organisation en sélectionnant l’icône Autres actions en regard du nom du processus et en sélectionnant Modifier.

Noms de processus

Les noms de processus ont les exigences suivantes :

  • Doit être unique dans l’organisation
  • Doit avoir 128 caractères Unicode ou moins
  • Impossible de contenir l’un des caractères suivants : .,;':~\/*|?"&%$!+=()[]{}<>

Objets hérités et personnalisés

Chaque processus hérité hérite des types d'éléments de travail (WIT) définis dans le processus du système de Base, Agile, Scrum, ou CMMI sous-jacent. Par exemple, les processus qui héritent d’Agile fournissent un bogue, une tâche, un récit utilisateur, une fonctionnalité, une épopée, un problème et des WIT liés aux tests.

Vous pouvez ajouter des champs et modifier le flux de travail et le formulaire d’élément de travail pour tous les wiT qui s’affichent sur la page Types d’éléments de travail d’un processus hérité. Vous pouvez également ajouter des WIT personnalisés.

Si vous ne souhaitez pas que les utilisateurs créent de nouveaux éléments de travail en fonction d’un processus hérité WIT, vous pouvez le désactiver en sélectionnant l’icône Autres actions en regard du nom WIT dans les paramètres de l’organisation et en sélectionnant Désactiver dans le menu contextuel.

Champs d'élément de travail

Cette section décrit les champs d’élément de travail.

Champs et références de champ

Vous utilisez des éléments de travail pour planifier et suivre votre projet. Chaque type d’élément de travail est associé à 31 champs système et plusieurs champs spécifiques au type qui fournissent des informations de suivi sur les éléments de travail. Les valeurs que vous affectez à un champ sont stockées dans le magasin de données de suivi du travail, que vous pouvez interroger pour déterminer l’état et les tendances.

Pour obtenir la description et l'utilisation de chaque champ défini pour les processus système de base Scrum, Agile et l'Intégration du Modèle de Maturité des Capacités (CMMI), consultez l'index des champs des éléments de travail.

Noms de champs

Un nom de champ d'élément de travail identifie uniquement chaque champ d'élément de travail. Vérifiez que vos noms de champs répondent aux exigences suivantes :

  • Doit être unique au sein de l’organisation ou de la collection de projets
  • Doit comporter 128 caractères Unicode ou moins
  • Doit contenir au moins un caractère alphabétique
  • Ne peut pas contenir d’espaces de début ou de fin, ou deux espaces consécutifs ou plus
  • Impossible de contenir l’un des caractères suivants : .,;':~\/*|?"&%$!+=()[]{}<>

Les noms et définitions de champs s’appliquent à l’ensemble de l’organisation. Vous ne pouvez pas ajouter un champ avec un nom de champ qui existe déjà dans l’organisation ou qu’un autre processus hérité a été ajouté à un WIT.

Personnalisations des champs

Les champs sont définis pour tous les projets et processus d’une organisation. Les processus hérités héritent des champs définis dans les processus système et vous pouvez y apporter des modifications limitées. Vous pouvez créer et modifier des champs personnalisés dans les processus hérités.

Vous pouvez ajouter n’importe quel champ personnalisé que vous définissez pour un WIT dans un processus à n’importe quel wit défini pour un autre processus. Vous pouvez également ajouter un champ existant à un autre WIT au sein du même processus. Par exemple, vous pouvez ajouter une date d’échéance à l’article utilisateur ou au bogue WIT.

Personnaliser des champs et des contrôles

Les ressources suivantes décrivent comment implémenter différentes personnalisations pour les champs hérités, les champs personnalisés ou les contrôles personnalisés.

Champs hérités

Champs personnalisés

Contrôle personnalisé

Supprimer ou restaurer des champs supprimés

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 pouvez masquer ou supprimer le champ d’un formulaire d’élément de travail. Pour plus d’informations, consultez Afficher, masquer ou supprimer un champ.

Limites

  • Vous ne pouvez pas modifier un nom de champ ou un type de données une fois que vous l’avez défini. 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 utiliser le nom du champ et non l’étiquette de champ.
  • Vous ne pouvez pas modifier la zone grise du formulaire qui contient les champs État, Motif, Chemin d’accès à la zone et chemin d’itération .
  • Les chemins d’accès de zone et les listes de sélection des chemins d’itération sont configurés pour chaque projet et ne sont pas personnalisables par le biais d’un processus hérité.
  • Les listes de sélection associées aux champs d’identité utilisateur, tels que Affectés à et Modifié par, sont renseignées en fonction des utilisateurs ajoutés au projet ou à l’équipe.
  • Un maximum de 64 champs peut être défini pour chaque WIT et un maximum de 512 champs peut être défini par processus.
  • 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.

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

Chaque WIT a plusieurs règles système définies, comme exiger le champ Titre ou définir une valeur par défaut pour le champ Zone de valeur . Les règles système définissent également des actions à entreprendre lorsqu’un état de flux de travail change.

Par exemple, plusieurs règles copient l’identité de l’utilisateur actuel dans le champ Modifié par lorsqu’un élément de travail est modifié ou vers le champ Fermé par lorsque l’état du flux de travail passe à Fermé ou Terminé. Les règles système prédéfinies sont prioritaires sur toutes les règles personnalisées qui les remplaceraient.

Les règles personnalisées prennent en charge plusieurs cas d’usage métier, vous permettant d'aller au-delà de la définition d'une valeur par défaut pour un champ ou de le rendre obligatoire. Les règles personnalisées vous permettent d’effacer la valeur d’un champ, de copier une valeur dans un champ ou d’appliquer des valeurs basées sur des dépendances entre différentes valeurs de champ.

Avec des règles personnalisées, vous pouvez définir différentes actions en fonction de conditions spécifiques. Par exemple, vous pouvez appliquer des règles pour prendre en charge les scénarios suivants :

  • Lorsqu’une valeur est définie pour Priority, définissez le champ Risque comme champ obligatoire.
  • Lorsqu’une modification est apportée à la valeur de Release, effacez la valeur de Jalon.
  • Lorsqu’une modification est apportée à la valeur du travail restant, rendez le travail terminé obligatoire.
  • Lorsque la valeur Approuvée est True, définissez Approuvé par un champ obligatoire.
  • Lorsqu’un récit utilisateur est créé, définissez les champs Priorité, Risque et Effort requis.

Pour plus d’informations sur la définition de règles personnalisées, consultez Ajouter une règle à un type d’élément de travail (processus d’héritage).

Conseil

Vous ne pouvez pas définir de formule à l’aide d’une règle. Toutefois, vous pouvez trouver une solution qui répond à vos besoins avec Power Automate. Pour plus d’informations, consultez Récapitulatif du travail et d’autres champs.

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

En utilisant les conditions current user is a member of a group... ou current user is not a member of a group..., vous pouvez exiger ou configurer des champs sélectionnés pour les utilisateurs membres ou non membres d’un groupe ou d’un groupe de sécurité. Par exemple, vous pouvez effectuer le titre ou le champ État en lecture seule pour les utilisateurs ou groupes sélectionnés.

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

Envisagez de conserver une propriété unique des éléments de travail par chemin d’accès de zone d’équipe ou de formaliser des colonnes avec des états personnalisés partagés entre les équipes.

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 de zone. Ce paramètre n’est pas une règle, mais un paramètre d’autorisation. Pour plus d'informations, consultez Créer des nœuds enfants, modifier des éléments de travail dans un chemin d'itération ou de zone.

Personnalisations de type d’élément de travail

Les ressources suivantes décrivent les options de personnalisation pour les wiT hérités et personnalisés.

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

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

La modification du WIT par défaut pour un backlog entraîne l’affichage par défaut du WIT dans le panneau d’ajout rapide. Par exemple, Custom Story apparaît par défaut dans le panneau d’ajout rapide suivant pour un backlog de produit.

Capture d’écran du panneau d’ajout rapide avec un type d’élément de travail personnalisé par défaut.

Limites

  • Vous ne pouvez pas ajouter ou supprimer un WIT hérité à 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 modifier le nom d’un WIT personnalisé une fois que vous l’avez défini.

Personnalisations des formulaires d’élément de travail

Vous pouvez effectuer les personnalisations suivantes sur un formulaire WIT :

Groupes hérités

Groupes personnalisés

Pages héritées

Pages personnalisées

Disposition et redimensionnement

La disposition de formulaire web pour un élément de travail est organisée en trois colonnes, comme illustré dans l’image suivante.

Illustration de la mise en page en trois colonnes pour le formulaire d’élément de travail.

Si vous ajoutez uniquement des groupes et des champs aux deux premières colonnes, la disposition affiche deux colonnes. Si vous ajoutez uniquement des groupes et des champs à la première colonne, la disposition affiche 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. Lorsque la largeur d’affichage ne prend pas en charge toutes les colonnes, les colonnes apparaissent empilées dans la colonne à gauche.

À mesure que la largeur d’affichage diminue, les colonnes sont redimensionnées proportionnellement comme suit :

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

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 varient en fonction du processus système utilisé pour créer le processus personnalisé : Agile, Basic, Scrum ou Capability Maturity Model Integration (CMMI). Pour plus d’informations, consultez les états, les transitions et les raisons du flux de travail.

Le 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. Par exemple, le WIT Issue du processus de base comprend trois états : To Do, Doing et Done.
  • Raisons par défaut de chaque transition d’état.

Les flux de travail hérités et personnalisés doivent être conformes aux règles suivantes :

  • Définissez au moins deux états de flux de travail.
  • Définissez au moins un état pour les catégories d’état Proposé ou En cours .
  • Définissez un maximum de 32 états de flux de travail par type d’élément de travail.

Remarque

Avant d’ajouter un état de flux de travail personnalisé, consultez À propos des états de flux de travail dans les backlogs et les tableaux pour découvrir comment les états de flux de travail correspondent aux catégories.

Pour connaître les personnalisations des états de flux de travail hérités et personnalisés, consultez les ressources suivantes :

États hérités

États personnalisés

Limites

  • Vous ne pouvez pas modifier le nom, la couleur ou la catégorie d’états hérités, mais vous pouvez les masquer si vous ne voulez pas qu’ils soient visibles.
  • Vous ne pouvez pas modifier les noms des états personnalisés une fois définis.
  • Vous ne pouvez pas modifier ou personnaliser les noms de catégorie d’état par défaut.
  • Un seul état peut exister dans la catégorie d’état Terminé . L’ajout d’un état personnalisé à cette catégorie supprime ou masque tout autre état de cette catégorie.
  • Vous ne pouvez pas spécifier de raisons personnalisées pour les transitions d’état. Utilisez les raisons par défaut, telles que Déplacé vers l’état Triaged et Déplacé hors de l’état Triaged.
  • Vous ne pouvez pas modifier l’emplacement des champs État et Raison dans le formulaire élément de travail.

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 de produits, d’itération et de portefeuille standard hérités des processus système sont entièrement personnalisables. Vous pouvez également ajouter des backlogs de portefeuille personnalisés jusqu’à un total de cinq backlogs de portefeuille.

Pour plus d’informations sur la personnalisation des backlogs de portefeuille hérités et personnalisés, consultez les ressources suivantes :

Backlogs hérités

Backlogs de portefeuille personnalisés

Limites

  • Vous ne pouvez pas supprimer un niveau de portefeuille hérité d’un produit. Vous pouvez renommer le niveau ou désactiver les wiT pour empêcher les équipes de créer de nouveaux éléments de travail de ces types.
  • Vous ne pouvez pas insérer un nouveau niveau de backlog personnalisé dans l’ensemble existant de backlogs définis. Les niveaux de backlog prédéfinis sont généralement fixes, par exemple des épopées, des fonctionnalités, des récits utilisateur et des tâches.
  • Vous ne pouvez pas réorganiser les niveaux de backlog. Ils suivent généralement une hiérarchie prédéfinie et la modification de l’ordre n’est pas prise en charge.
  • Vous ne pouvez pas ajouter un WIT à deux niveaux de backlog différents. Chaque WIT ne peut appartenir qu’à un seul niveau de backlog.
  • Vous ne pouvez pas créer de niveau de backlog spécifique à une tâche personnalisée, mais vous pouvez toujours ajouter des WIT personnalisés au backlog d’itération. Par exemple, vous pouvez créer un WIT personnalisé appelé Amélioration ou maintenance et l’associer au backlog d’itération.
  • Le bogue WIT n’appartient à aucun niveau de backlog spécifique par défaut. Chaque équipe peut décider comment elle souhaite gérer les bogues. Vous pouvez choisir d’afficher des bogues sur les backlogs et les tableaux ou de les gérer séparément. Pour plus d’informations, consultez Présentation des bogues dans les backlogs.

Contenu connexe

  • Last updated on