Partager via

À 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 de bord et tableaux de tâches) 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

Passez en revue les modifications apportées à un processus hérité par le biais du journal d’audit. Pour plus d’informations, consultez Access, 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 :

  • icône verrouillée Processus système ( Agile, Basic, Scrum et CMMI) qui sont verrouillés d’être modifiés.
  • icône héritée 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. Les mises à jour des processus sont documentées dans les notes de publication d’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.

Capture d’écran du contexte administrateur, des paramètres de l’organisation, de la liste de projets et du 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 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.

Image conceptuelle de la hiérarchie des éléments de travail du processus Agile.

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 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 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 plus d’informations, 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 effectuez la transition d’un projet vers un processus hérité, vous pouvez rencontrer des outils Agiles ou des éléments de travail dans un état non valide conformément aux exemples suivants :

  • Si vous désignez un champ comme requis, les éléments de travail qui manquent de ce champ affichent un message d’erreur. Pour poursuivre les modifications et enregistrer l’élément de travail, résolvez ces erreurs.
  • Si vous ajoutez, supprimez ou masquez des états de flux de travail pour un wiT qui apparaît sur la carte, veillez à mettre à jour les configurations de colonnes de carte pour toutes les équipes définies dans le projet. En outre, 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.

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 de la mise en page de 3 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 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 varient en fonction du processus système que vous avez sélectionné pour créer votre processus personnalisé. Les options sont 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.

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

Types d’état

Personnalisations prises en charge

États hérités

États personnalisés

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

  • Définissez au moins un état pour les catégories d’état Proposé ou En cours .

    Remarque

    Avant d’ajouter un état de flux de travail, 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 d’état.

  • Définissez au moins deux états de flux de travail.
  • Définissez 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

  • Masquer les états hérités si vous ne souhaitez pas qu’ils soient visibles (vous ne pouvez pas modifier leur nom, leur couleur ou leur catégorie).
  • Vérifiez qu’un seul état existe dans la catégorie d’état Terminé . L’ajout d’un état personnalisé à cette catégorie supprime ou masque tout autre état.
  • Conservez le nom des états personnalisés tels qu’ils le sont ; vous ne pouvez pas les modifier.
  • Utilisez des raisons par défaut pour les transitions d’état, telles que Déplacé vers l’état Triaged et Déplacé hors état Triaged ; vous ne pouvez pas spécifier de raisons personnalisées.
  • Acceptez l’emplacement par défaut des champs État et Motif du formulaire ; vous ne pouvez pas changer leur placement.
  • Utilisez les noms de catégorie d’état par défaut ; vous ne pouvez pas les personnaliser.
  • Masquer les états hérités si vous ne souhaitez pas qu’ils soient visibles (vous ne pouvez pas modifier leur nom, leur couleur ou leur catégorie).
  • Vérifiez qu’un seul état existe dans la catégorie d’état Terminé ; le système interdit l’ajout d’un état personnalisé à cette catégorie.
  • Conservez le nom des états personnalisés tels qu’ils le sont ; vous ne pouvez pas les modifier.
  • Acceptez la séquence naturelle d’états dans la liste déroulante du formulaire d’élément de travail ; vous ne pouvez pas modifier leur ordre.
  • Utilisez des raisons par défaut pour les transitions d’état, telles que Déplacé vers l’état Triaged et Déplacé hors état Triaged ; vous ne pouvez pas spécifier de raisons personnalisées.
  • Acceptez l’emplacement par défaut des champs État et Motif du formulaire ; vous ne pouvez pas changer leur placement.
  • Autoriser les transitions d’un état à un autre ; vous ne pouvez pas restreindre les transitions.

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

Personnalisations non prises en charge :

  • Suppression d’un niveau de portefeuille hérité :
    • Bien que vous ne puissiez pas directement supprimer un niveau de portefeuille hérité d’un produit, vous avez deux options :
      • Renommez le niveau de portefeuille : vous pouvez renommer le niveau de portefeuille hérité en fonction de vos besoins.
      • Désactivez un WIT hérité : si le niveau de portefeuille hérité inclut des WIT que vous ne souhaitez pas utiliser, vous pouvez les désactiver. Cette action empêche les équipes de créer de nouveaux éléments de travail de ces types.
  • Insertion d’un niveau de backlog :
    • Vous ne pouvez pas insérer un nouveau niveau de backlog dans l’ensemble existant de backlogs définis. Les niveaux de backlog prédéfinis sont généralement fixes (par exemple, Épopées, Fonctionnalités, Récits utilisateur, Tâches) et vous ne pouvez pas ajouter de niveaux personnalisés entre eux.
  • Réorganiser les niveaux de backlog :
    • Malheureusement, 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 leur ordre n’est pas prise en charge.
  • Ajout d’un WIT à plusieurs niveaux de backlog :
    • Chaque WIT ne peut appartenir qu’à un seul niveau de backlog. Vous ne pouvez pas ajouter un WIT à deux niveaux de backlog différents simultanément.
  • Création d’un niveau de backlog de tâches personnalisé :
    • Bien que vous ne puissiez pas créer un niveau de backlog spécifique à une tâche personnalisée, 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.
  • Gestion des bogues :
  • Ajout ou suppression d’un WIT hérité d’un backlog :
    • Vous ne pouvez pas ajouter ou supprimer directement un WIT hérité vers ou à partir d’un backlog. Par exemple, l’ajout du WIT « Problème » au backlog du produit n’est pas pris en charge.
    • Toutefois, vous pouvez :
      • Renommez le niveau de portefeuille : si le niveau de portefeuille hérité inclut des WIT que vous ne souhaitez pas utiliser, envisagez de le renommer pour mieux répondre à vos besoins.
      • Désactivez un WIT hérité : s’il existe des WIT hérités que vous souhaitez exclure, vous pouvez les désactiver. Cette action empêche les équipes de créer de nouveaux éléments de travail de ces types.
  • Suppression d’un niveau de portefeuille hérité :
    • Bien que vous ne puissiez pas supprimer un niveau de portefeuille hérité d’un produit, vous avez deux options :
      • Renommez le niveau de portefeuille : donnez-lui un nom plus approprié.
      • Désactiver les WIT hérités : empêcher les équipes d’utiliser des WIT hérités spécifiques.
  • Insertion d’un niveau de backlog :
    • Malheureusement, vous ne pouvez pas insérer un nouveau niveau de backlog dans l’ensemble existant de backlogs définis. Les niveaux de backlog prédéfinis restent fixes (par exemple, Épopées, Fonctionnalités, Récits utilisateur, Tâches).
  • Réorganiser les niveaux de backlog :
    • Les niveaux de backlog suivent généralement une hiérarchie prédéfinie et la modification de leur ordre n’est pas prise en charge. Vous ne pouvez pas les réorganiser.
  • Ajout d’un WIT à plusieurs niveaux de backlog :
    • Chaque WIT (par exemple, Bogue, Tâche, Récit utilisateur) ne peut appartenir qu’à un seul niveau de backlog. Vous ne pouvez pas ajouter un WIT à deux niveaux de backlog différents simultanément.
  • Création d’un niveau de tâche personnalisé :
    • Bien que vous ne puissiez pas créer un niveau de backlog spécifique à une tâche personnalisée, vous pouvez toujours ajouter des WIT personnalisés au backlog d’itération. Par exemple, créez un WIT personnalisé appelé « Amélioration » ou « Maintenance » et associez-le au backlog d’itération.
  • Gestion des bogues :

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.

Capture d’écran du backlog produit, panneau Ajout rapide, affichage wit par défaut pour un niveau de backlog

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.