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

Azure Boards | Azure DevOps Server 2020 | Azure DevOps Server 2019

Pour personnaliser le système de suivi du travail, vous Personnalisez un processus hérité par le biais de l’interface utilisateur d’administration de l’organisation. Tous les projets qui utilisent un processus hérité obtiennent les personnalisations apportées à ce processus. En revanche, vous configurez les journaux des travaux — en souffrance, les sprints, les tableaux kanban etle tableau de tâches des outils agile — 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 modèle de processus XML local. Cet article s’applique à Azure DevOps Services et Azure DevOps Server 2019 uniquement.

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

Notes

Vous pouvez passer en revue les modifications apportées à un processus hérité par le biais du journal d’audit. Pour plus d’informations, consultez accès, exportation et filtrage des journaux d’audit.

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

Notes

Pour obtenir des conseils sur la configuration et la personnalisation de votre projet et des équipes afin de prendre en charge les besoins de votre entreprise, passez en revue la configuration et la personnalisation des Azure Boards.

Processus système et processus hérités

Vous verrez deux types de processus :

  • icône verrouillée traite — agile, basique, Scrum et CMMI — qui sont verrouillés contre la modification.
  • icône héritée Les 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 périodiquement par Microsoft. Toutes les mises à jour apportées à un processus système entraînent automatiquement une mise à jour de vos processus hérités.

Notes

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 des projets existants pour l’utiliser.

Par exemple, comme indiqué dans l’image suivante, vous voyez une liste des projets définis pour l’organisation Fabrikam . La deuxième colonne indique 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 ). Toute modification apportée au processus MyScrum met également à jour d’autres projets qui utilisent ce processus. Vous ne pouvez pas personnaliser le projet de test de requête , en revanche, tant que vous ne le modifiez pas en un processus qui hérite de agile.

Contexte d’administration, paramètres de l’organisation, liste des projets et processus qu’ils utilisent

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, puis choisissez modifier.

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

Si vous souhaitez changer le processus utilisé par un projet à partir d’un processus système à un autre, vous pouvez le faire. Pour apporter ces modifications, vous devez créer un processus hérité basé sur le 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 ci-dessus, vous pouvez également apporter des modifications supplémentaires, par exemple, de CMMI à agile ou agile à CMMI.

Avant de procéder à cette modification, nous vous recommandons de vous familiariser avec le processus que vous passez à. Les processus système sont résumés dans choisir un 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 — Basic, agile, Scrum ou CMMI. Par exemple, le processus agile fournit des éléments de travail Bogue, tâche, récit utilisateur, fonctionnalité, Epic, problème et test.

Types d’élément de travail Agile

Vous pouvez ajouter des champs et modifier le flux de travail et le formulaire d’élément de travail pour tous les types d’éléments de travail 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 de champs

Les champs définis dans le processus système apparaissent avec une icône héritée, ce qui indique 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, notez les limites suivantes :

  • Un maximum de 64 champs peuvent être définis pour chaque WIT
  • Un maximum de 512 champs peut être défini par processus

En outre, vous pouvez Ajouter un champ existant à un autre Wit au sein du processus. Par exemple, vous pouvez ajouter la date d’échéance au récit utilisateur ou au Wit bogue.

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 de 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 locaux et XML hébergés. Pour plus d’informations, 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 de zone et chemin d’itération.
  • En ce qui concerne les listes déroulantes, vous ne pouvez pas effectuer les opérations suivantes :
    • Modifier la liste déroulante d’un champ hérité, tel que le champ activité ou discipline
    • Modifier l’ordre de liste déroulante, les listes déroulantes sont affichées par ordre alphabétique
  • Vous ne pouvez pas modifier le texte d’aide de description des champs hérités
  • Importez ou définissez une liste globale prise en charge par les modèles de processus XML locaux et XML hébergés. Pour plus d’informations, consultez définir des listes globales.

Notes

Avec le processus hérité, vous ne pouvez pas modifier les listes déroulantes de champs prédéfinis, — tels que activité, État Automation, discipline, priorité, etc.

Listes déroulantes configurables

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

Les listes déroulantes associées à des champs de noms de personnes, tels que Affecté à 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 changement de nom d’un champ ou la modification du type de données ne sont pas des actions prises en charge. Toutefois, vous pouvez modifier l’étiquette qui s’affiche pour un champ sur le formulaire d’élément de travail à partir de 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 du champ.

Puis-je supprimer ou restaurer un champ supprimé ?

Vous pouvez supprimer un champ et le restaurer ultérieurement. La suppression d’un champ entraîne la suppression de toutes les données associées à ce champ, y compris les valeurs d’historique. Une fois supprimée, vous pouvez uniquement restaurer le champ et récupérer les données à l’aide de l' API REST de mise à jour des champs.

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.

Qu’est-ce qu’un champ ? Comment les noms de champs sont-ils utilisés ?

Chaque type d’élément de travail est associé à 31 champs système et à plusieurs champs spécifiques au type. Vous utilisez des éléments de travail pour planifier et suivre votre projet.

Chaque champ prend en charge le suivi d’une information sur le travail à effectuer. Les valeurs que vous affectez à un champ sont stockées dans le magasin de données de suivi des tâches, ce qui vous permet de créer des requêtes pour déterminer l’État et les tendances.

Pour obtenir une description et l’utilisation de chaque champ défini pour les processus système de base — , les processus système Scrum, agile et CMMI, — consultez Index des champs d’é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 les noms de champs sont conformes aux indications suivantes :

  • Les noms de champs doivent être uniques au sein de l’organisation ou de la collection de projets
  • Les noms de champs doivent comporter 128 caractères Unicode ou moins
  • Les noms de champs ne peuvent pas contenir d’espaces de début ou de fin, ni deux ou plusieurs espaces consécutifs
  • Les noms de champs doivent contenir au moins un caractère alphabétique
  • Les noms de champs ne peuvent 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é avec le même nom de champ qui existe déjà dans l’organisation ou qui a été ajouté à un type d’opération dans un autre processus hérité.

Notes

Lorsque vous modifiez un projet pour utiliser un processus hérité, vous pouvez trouver un ou plusieurs outils agile ou éléments de travail dans un État non valide. Par exemple :

  • Si vous rendez 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 s’affiche dans le tableau kanban, vous devez mettre à jour les configurations des colonnes du tableau kanban pour toutes les équipes définies dans le projet.

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

Chaque — bogue de Wit, tâche, récit utilisateur, etc. — a plusieurs règles système déjà définies. Certains sont simples, comme le fait de rendre le champ de titre obligatoire ou la définition d’une valeur par défaut pour le champ de la zone de valeur. En outre, un certain nombre de règles système définissent les actions à entreprendre lorsqu’un état de flux de travail change.

Par exemple, plusieurs règles existent pour copier l’identité de l’utilisateur actuel 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 ont priorité sur toute règle personnalisée que vous définissez et qui la remplacerait.

Les règles personnalisées prennent en charge un certain nombre de cas d’utilisation d’entreprise, 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 obligatoire. 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 les types de scénarios suivants :

  • Quand une valeur est définie pour Priority, alors rendre le champ de risque obligatoire
  • Quand une modification est apportée à la valeur de release, désactivez la valeur de « jalon ».
  • Quand une modification a été apportée à la valeur du travail restant, le champ de travail terminé est obligatoire
  • Lorsque la valeur de approuvé est true, faire approuver par un champ obligatoire
  • Quand un récit utilisateur est créé, modifiez les champs suivants : priorité, risque et effort

Conseil

Vous ne pouvez pas définir une formule à l’aide d’une règle. Toutefois, vous pouvez trouver une solution adaptée à vos besoins via l' extension Marketplace de l’agrégateur TFS (service Web). Voir aussi cumul du travail et d’autres champs.

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

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

À l’aide de l’une des deux conditions suivantes, vous pouvez faire en sorte que les champs sélectionnés soient obligatoires 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 faire en sorte que le champ titre ou État soit accessible en lecture seule pour sélectionner des utilisateurs ou des groupes.

Restreindre la modification des éléments de travail en fonction du chemin de la zone

Vous pouvez empêcher les utilisateurs de modifier certains éléments de travail en définissant des autorisations sur un chemin de 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 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 (vous pouvez toutefois 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 de formulaire d’élément de travail

Vous pouvez effectuer les personnalisations suivantes dans 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 du formulaire Web est organisée en trois colonnes, comme indiqué dans l’image ci-dessous.

disposition de page à 3 colonnes

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 à une colonne.

Le formulaire Web est redimensionné en fonction de la largeur disponible et du nombre de colonnes dans la mise en page. À 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 se redimensionne proportionnellement comme suit :

  • Pour les trois colonnes suivantes : 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 située à gauche.

Personnalisations de flux de travail

Vous pouvez personnaliser le flux de travail d’un 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 selon le processus système — agile, de base, Scrum ou CMMI — . vous avez choisi de 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, émettre un WIT est caractérisé par les trois États — pour effectuer, faire et effectuer des transitions, ainsi que des transitions , — présentées dans l’image suivante.

Processus de base, type d’élément de travail problème, modèle d’état de flux de travail


Types d’État

Personnalisations prises en charge


Icône héritée États hérités

États personnalisés


Les États de flux de travail doivent respecter les règles suivantes

  • Vous devez définir au moins un État pour les catégories d’état proposé ou en cours

    Notes

    Avant d’ajouter un état de flux de travail, examinez les États de workflow et les catégories d’État pour savoir comment les États de flux de travail sont mappés 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 état terminé . Si vous ajoutez un état personnalisé à la catégorie terminé, tout autre État est supprimé ou masqué.
  • Vous ne pouvez pas modifier le nom d’un état personnalisé
  • Vous ne pouvez pas spécifier de raison pour un État. en revanche, les raisons par défaut sont définies comme étant déplacées vers l’État triage, déplacées hors de l’État en triage
  • Vous ne pouvez pas modifier l’emplacement des champs État et raison sur le formulaire
  • 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 état terminé . Le système n’autorise pas 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 de raison pour un État. en revanche, les raisons par défaut sont définies comme étant déplacées vers l’État triage, déplacées hors de l’État en triage
  • Vous ne pouvez pas modifier l’emplacement des champs État et raison sur le formulaire
  • Vous ne pouvez pas restreindre les transitions, toutes les transitions sont définies d’un État à un autre.

Personnalisations du backlog et du tableau

Les journaux des travaux en souffrance et les tableaux sont des outils agiles essentiels pour la création et la gestion du travail pour une équipe. Le produit, l’itération et le portefeuille des journaux des travaux en souffrance standard — — hérités du processus système sont entièrement personnalisables. En outre, vous pouvez ajouter des journaux des travaux en souffrance du portefeuille personnalisés pour un total de cinq journaux des travaux en souffrance du portefeuille.


Types de Backlog

Prise en charge de la personnalisation


Journaux des travaux en souffrance hérités


Journaux des travaux en souffrance du portefeuille personnalisé


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 journaux des travaux en souffrance 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 des itérations
  • Vous ne pouvez pas ajouter le Wit bogue à un niveau de 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 journaux des travaux en souffrance 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 problème au backlog de 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 journaux des travaux en souffrance 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é, bien que vous puissiez ajouter des types d’éléments de travail personnalisés au backlog des itérations
  • Vous ne pouvez pas ajouter le Wit bogue à un niveau de 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 journaux des travaux en souffrance et les tableaux.

Notes

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

Lorsque vous modifiez le type d’opération de travail par défaut pour un niveau de backlog, cela entraîne l’affichage par défaut de ce WIT dans le panneau d’ajout rapide. Par exemple, le ticket client s’affiche par défaut dans le panneau d’ajout rapide suivant pour le backlog de produit.

Journal des travaux en souffrance du produit, panneau d’ajout rapide, affiche le WIT par défaut pour un niveau de Backlog

Limites des objets

Pour obtenir la liste des limites imposées au nombre de champs, d’Wit, de niveaux de backlog et d’autres objets que vous pouvez personnaliser, consultez limites des objets de suivi du travail.