Personnaliser votre expérience de suivi du travail

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

Lorsque vous planifiez et suivez votre projet, envisagez de configurer des fonctionnalités ou de personnaliser votre expérience pour vous aligner sur les exigences de suivi de votre équipe. L’approche de personnalisation des projets, qui affecte toutes les équipes, dépend du modèle de processus que vous utilisez.

Cet article vous donne une vue d’ensemble des personnalisations disponibles et de la façon dont elles varient entre les trois modèles de processus. Pour obtenir des conseils spécifiques sur les personnalisations pour prendre en charge les décisions métier, consultez Configurer et personnaliser Azure Boards. Pour plus d’informations, consultez Qu’est-ce qu’Azure Boards ? et À propos des éléments de travail.

Présentation des niveaux de personnalisation

Vous pouvez personnaliser le suivi du travail aux niveaux suivants :

• Ressources partagées au niveau du projet : définissez les chemins d’accès de zone et d’itération que les équipes sélectionnent pour configurer leurs backlogs et leurs tableaux. Les requêtes partagées et les balises d’élément de travail sont d’autres objets qui, une fois définis, peuvent être partagés dans le projet.
• Ressources ou outils d’équipe : chaque équipe peut configurer ses outils spécifiques, tels que les backlogs, les tableaux de bord et les tableaux de bord. Pour plus d’informations, consultez À propos des équipes et des outils Agile.
• Autorisations au niveau du projet et des objets : gérez l’accès aux outils de suivi du travail, qui incluent la définition des autorisations pour les objets et le projet et l’affectation d’utilisateurs ou de groupes à des niveaux d’accès spécifiques.
• Personnalisation du processus au niveau de l’organisation : personnalisez les champs, les types d’éléments de travail et les backlogs et les tableaux disponibles pour toutes les équipes.

Étendue de personnalisation et impact

Comprendre l’étendue de chaque niveau de personnalisation vous aide à prendre des décisions éclairées :

Niveau de personnalisation	Scope	Impact	Examples
Au niveau du projet	Toutes les équipes du projet	Affecte les configurations d’équipe	Chemins d’accès de zone, chemins d’itération, requêtes partagées
Niveau équipe	Équipes individuelles	Paramètres spécifiques à l’équipe	Colonnes du backlog, voies de bain de bord, capacité
Niveau d’autorisation	Accès utilisateur/groupe	Contrôle la visibilité des fonctionnalités	Autorisations de requêtes, accès aux chemins d’accès des zones
Niveau processus	Organisation/collection	Tous les projets utilisant le processus	Champs personnalisés, types d’éléments de travail, workflows

Ressources partagées au niveau du projet

Chaque projet fournit de nombreuses ressources partagées qui prennent en charge toutes les équipes au sein du projet. Vous configurez ces fonctionnalités via l’interface utilisateur ou le contexte d’administrateur du portail web.

Ressources partagées principales

Les ressources partagées suivantes constituent la base du suivi des travaux dans votre projet :

• Chemins d’accès aux zones : organiser les éléments de travail par zone de fonctionnalité ou responsabilité d’équipe
• Chemins d’itération : Définir des sprints et des versions pour la planification et le suivi
• Requêtes partagées : Créer des requêtes réutilisables auxquelles tous les membres de l’équipe peuvent accéder
• Balises de tâche : Ajouter des métadonnées pour la catégorisation et le filtrage
• Groupes de sécurité : Gérer les autorisations d’accès dans le projet

Pour plus d’informations, consultez les articles suivants :

• À propos des chemins de zone et d’itération
• Définir les chemins d’accès aux zones
• Modifier la liste de sélection d’un chemin d’itération
• Créer et modifier des requêtes
• Ajouter des balises à des éléments de travail

Meilleures pratiques pour les ressources partagées

• Planifier les chemins de zone tôt : Concevoir la structure des chemins de zone pour refléter l'appropriation par l'équipe et l'organisation du produit.
• Établir une cadence d’itération : configurer des longueurs de sprint cohérentes et des planifications de mise en production
• Créer une structure de dossiers : organiser les requêtes partagées dans les dossiers pour améliorer la détectabilité
• Utiliser des balises descriptives : Établir des conventions d’étiquetage pour les métadonnées cohérentes
• Passer en revue régulièrement les autorisations : vérifiez les niveaux d’accès appropriés pour tous les membres de l’équipe

Champs du sélecteur de personnes et de l’identité

La fonctionnalité sélecteur de personnes prend en charge les champs d’identité dans Azure DevOps :

• Le champ Affecté à et d’autres champs Identité utilisent la fonctionnalité sélecteur de personnes.
• Activation : lorsque vous choisissez le champ Affecté à dans un formulaire d’élément de travail, le sélecteur de personnes s’active automatiquement.
• Sélection de l’utilisateur : pour sélectionner un utilisateur, commencez à entrer son nom et à effectuer une recherche jusqu’à ce que vous trouviez une correspondance.
• Sélections récentes : les utilisateurs précédemment sélectionnés apparaissent automatiquement dans la liste pour un accès rapide.
• Intégration d’annuaire : pour les organisations utilisant l’ID Microsoft Entra ou Active Directory, les sélecteurs de personnes permettent de rechercher tous les utilisateurs et groupes ajoutés à l’annuaire (pas seulement ceux ajoutés à un projet spécifique).
• Limitation de l’étendue : pour limiter l’étendue des identités disponibles pour la sélection aux utilisateurs spécifiques au projet, utilisez le groupe UtilisateursProject-Scoped .
• Restrictions personnalisées : les règles personnalisées peuvent restreindre davantage les valeurs disponibles pour les champs Identity au sein d’un élément de travail.

Configuration du champ Identité

Vous pouvez configurer des champs d’identité de plusieurs façons :

• Utilisateurs limités au projet : limiter la sélection d'identité uniquement aux membres du projet
• Règles personnalisées : Implémenter des règles métier qui limitent les valeurs de champ
• Restrictions basées sur les groupes : utiliser des groupes Azure AD pour contrôler les identités disponibles
• Autorisations au niveau du champ : Définir qui peut modifier les champs d’identité

Pour plus d’informations, consultez les articles suivants :

• Ajoutez Des utilisateurs ou des groupes Active Directory / Microsoft Entra à un groupe de sécurité intégré.

• Limitez la recherche d’identité.

Personnalisation du processus au niveau de l’organisation

Votre projet définit les types d’éléments de travail (WIT) disponibles pour le suivi du travail et configure les outils Agile. Il spécifie les récits utilisateur, les tâches, les bogues et les champs de données utilisés pour capturer des informations. Les objets personnalisés sont partagés entre les équipes au sein du projet.

Remarque

La méthode que vous utilisez pour personnaliser le suivi du travail dépend du modèle de processus auquel vous vous abonnez :

• Héritage : prend en charge la personnalisation WYSIWYG, disponible pour Azure DevOps Services, Azure DevOps Server 2019 et Azure DevOps Server 2020.
• XML hébergé : prend en charge la personnalisation par le biais de l’importation/exportation de modèles de processus, disponible pour un certain nombre de clients d’Azure DevOps Services qui ont choisi ce modèle.
• XML local : prend en charge la personnalisation par le biais de l’importation/exportation de fichiers de définition XML pour les objets de suivi du travail et est disponible pour tous les déploiements locaux.

Comparaison des modèles de processus

Le tableau suivant résume les différences entre les trois modèles de processus pris en charge. Pour connaître les définitions des principaux objets de suivi de travail, consultez glossaire Agile. Pour obtenir des liens vers des articles de personnalisation, consultez l’index de référence rapide pour les paramètres Azure Boards.

---

Fonctionnalité

Héritage

XML hébergé

XML local

---

Modification WYSIWYG

✔️

---

Créer des processus personnalisés hérités, Hériter des modifications dans les processus système (Agile, Basic, Scrum, CMMI)

✔️

---

Créer des modèles de processus personnalisés (voir la note 1)

✔️

✔️

---

Les modifications de processus mises à jour s’appliquent automatiquement à tous les projets référençant le processus

✔️

✔️

---

Prise en charge de la personnalisation des champs, types d’éléments de travail, mise en page de formulaire, flux de travail, règles personnalisées, niveaux de backlog, contrôles personnalisés, gestion des tests

✔️

✔️

✔️

---

Prise en charge de la personnalisation des types de liens, des champs d’équipe, du flux de travail global et de la configuration des processus (voir la note 3)

✔️

---

Configuration initiale des chemins d’accès de zone, chemins d’itération, requêtes d’éléments de travail, groupes de sécurité et autorisations (voir la note 3)

✔️

✔️

---

Listes globales

Listes de sélections

(voir la note 2)

✔️

---

Utiliser des az boards outils en ligne de commande pour modifier des projets et des équipes et des informations de liste

✔️

✔️

✔️

---

Utiliser les outilswitadmin

✔️

✔️

✔️

---

API REST (lecture)

✔️

✔️

✔️

---

API REST (écriture)

✔️

✔️

(voir la note 5)

---

Conseils de sélection de modèle de processus

Choisissez votre modèle de processus en fonction des besoins de votre organisation :

Modèle de processus d’héritage (recommandé)

• Idéal pour : Teams souhaitant une personnalisation intuitive basée sur le web
• Avantages : modification WYSIWYG, mises à jour automatiques, maintenance facile
• Utiliser quand : Vous avez besoin d’une personnalisation modérée avec une complexité minimale

Modèle de processus XML hébergé

• Idéal pour : organisations avec des exigences de processus complexes
• Avantages : contrôle de modèle de processus complet, personnalisation étendue
• Utiliser quand : Vous avez besoin d’une personnalisation avancée du processus, mais souhaitez héberger le cloud

Modèle de processus XML local

• Idéal pour : déploiements locaux avec des exigences de contrôle total
• Avantages : Flexibilité complète de la personnalisation, intégration d’entreprise
• Utiliser quand : Vous avez besoin d’un contrôle maximal et d’exécuter une infrastructure locale

Remarques :

1. Un processus détermine les blocs de construction utilisés pour suivre le travail. Un modèle de processus spécifie un ensemble interdépendant de fichiers de définition XML qui fournissent les blocs de construction et la configuration initiale pour le suivi du travail et d’autres domaines fonctionnels.
2. La personnalisation XML hébergée prend en charge l’ajout et la mise à jour de listes globales avec une mise à jour de processus (sous réserve de limites sur la taille maximale de chaque liste). Pour plus d’informations, consultez Limites des objets de suivi de travail.
3. Le modèle de processus hérité ne prend pas en charge la personnalisation des fonctionnalités suivantes disponibles avec la personnalisation des modèles de processus. Au lieu de cela, vous personnalisez ces zones dans le portail web sur une base de projet par projet.
   • Chemins d'accès d'itération et de zone
   • Requêtes d’élément de travail
   • Groupes de sécurité et autorisations
   • Autorisations et accès aux zones fonctionnelles telles que le contrôle de version et la génération
   Vous pouvez également utiliser des API REST ou l’outil de commande Azure DevOps CLI.
4. Utilisez l’API REST pour importer et exporter des modèles de processus.

Personnaliser l’expérience de test

Plusieurs types d’éléments de travail prennent en charge l’expérience de test dans les pages de test du portail web et le client Test Manager.

Personnalisation du processus d’héritage

Pour un processus hérité, vous pouvez personnaliser les types d’éléments de travail suivants, comme vous le feriez pour n’importe quel autre type d’élément de travail :

• Plan de test : organiser et gérer les suites de tests
• Suite de tests : Regrouper les cas de test associés
• Cas de test : Définir des scénarios de test individuels

Personnalisation XML sur site

Pour un processus XML local, vous pouvez personnaliser tous les types d’éléments de travail liés aux tests, notamment :

• Plan de test : organisation de test de haut niveau
• Suite de tests : regroupements de cas de test
• Cas de test : définitions de test individuelles
• Étapes partagées : procédures de test réutilisables
• Paramètres partagés : données de test paramétrables

Tester les relations d’élément de travail

L’exemple suivant montre les relations de liaison prises en charge entre les types d’éléments de travail de test :

Scénarios de personnalisation de test

Les personnalisations courantes de l’expérience de test sont les suivantes :

• Champs de test personnalisés : ajouter des métadonnées de test spécifiques à l’organisation
• États de flux de travail de test : définir des états d’exécution de test personnalisés
• Suivi des résultats des tests : Personnaliser le rapport de résultats des tests
• Champs d’intégration : Connecter des tests avec des exigences et des défauts

Personnalisations moins courantes

Vous pouvez uniquement effectuer les personnalisations suivantes lors de l’utilisation des modèles de processus XML hébergés ou XML locaux. Les personnalisations apportées à la configuration du processus s’appliquent à toutes les équipes au sein d’un projet.

Limites du backlog et de la carte (XML hébergé, XML local)

Pour limiter le temps de chargement d’affichage aux paramètres acceptables, le tableau des tâches est limité à un maximum de 1 000 éléments de travail. Pour plus d’informations, consultez la référence des éléments XML de configuration de processus.

Vous pouvez augmenter cette valeur jusqu’à un maximum de 1500 en spécifiant une valeur pour l’attribut de l’élément workItemCountLimitTaskBacklog . Pour plus d’informations, consultez la référence des éléments XML de configuration de processus.

<TaskBacklog category="Microsoft.TaskCategory" pluralName="Tasks" singularName="Task" workItemCountLimit="800" >
    . . .
</TaskBacklog>

Considérations relatives aux performances pour les limites du tableau

Lorsque vous personnalisez les limites du tableau, tenez compte des éléments suivants :

• Impact sur le temps de chargement : des limites plus élevées peuvent augmenter les temps de chargement de page
• Expérience utilisateur : Équilibrer les fonctionnalités avec les performances
• Limitations du navigateur : certains navigateurs gèrent les jeux de données volumineux différemment
• Bande passante réseau : tenez compte des membres de l’équipe ayant des connexions plus lentes

Modifier les affectations de champs (XML hébergé, XML local)

Vous pouvez modifier les champs d’élément de travail que le système utilise dans le calcul de la capacité, des graphiques d’avancement, des prévisions et de la vitesse. Toute modification apportée à l’une des affectations par défaut doit correspondre à une modification apportée au WIT utilisé pour définir et capturer des informations pour cette valeur.

Par exemple, si vous modifiez l’affectation refname , type="Activity" vous devez inclure le même champ dans la définition WIT affectée à la catégorie de tâche qui capture les informations d’activité. Pour plus d’informations, consultez la référence des éléments XML de configuration de processus.

Outils utilisant des affectations de champs

Les champs que vous affectez sont utilisés par les outils suivants :

Outil	Type de champ	Objectif
Tableau des tâches, outils de capacité, burndown sprint	Travail restant	Suivre l'avancement du travail
Backlogs de produit et de portefeuille	Priorité du backlog	Ordre des éléments de travail
Vitesse et prévision	Effort (mappe aux points d’histoire, à l’effort ou à la taille)	Estimer la taille du travail
Outils de capacité	Activité (activité de tâche ou discipline)	Planifier la capacité de l’équipe

Meilleures pratiques d’attribution de champ

• Maintenir la cohérence : vérifier que les affectations de champs correspondent aux définitions de type d’élément de travail
• Modifications de test : valider que les outils fonctionnent correctement après les réaffectations de champs
• Personnalisations de document : Enregistrer les modifications d’affectation de champ pour une référence ultérieure
• Prendre en compte l’impact : comprendre comment les modifications affectent les données et les rapports existants

Gérer l’accès aux outils de suivi du travail

Vous gérez l’accès à des fonctionnalités spécifiques via les paramètres d’autorisation. Lorsque vous ajoutez des comptes d’utilisateur à votre équipe, ils sont automatiquement ajoutés au groupe Contributeur. Ils ont ensuite accès à la plupart des fonctionnalités dont ils ont besoin pour contribuer au code, au suivi des travaux, aux builds et aux tests. Toutefois, le groupe Contributeur n’autorise pas les utilisateurs à créer des requêtes partagées ou à ajouter des chemins d’itération ou de zone. Vous devez accorder ces autorisations séparément.

Structure d’autorisation par défaut

Le système d’autorisation fonctionne sur ces principes :

• Accès par défaut : les nouveaux membres de l’équipe rejoignent automatiquement le groupe Contributeur
• Autorisations principales : le groupe Contributeur fournit l’accès à la plupart des fonctionnalités nécessaires pour le travail de développement
• Autorisations supplémentaires : certaines fonctionnalités nécessitent des octrois d’autorisations distincts
• Accès administratif : les administrateurs de projet ont un contrôle total sur les autorisations

Limitations du groupe contributeur

Le groupe Contributeur n’autorise pas automatiquement les utilisateurs à :

• Créer des requêtes partagées : nécessite des autorisations de requête supplémentaires
• Ajouter des chemins d’accès de zone ou d’itération : nécessite des autorisations d’administration au niveau du projet
• Modifier les paramètres de sécurité : nécessite un accès administratif
• Configurer les paramètres d’équipe : nécessite un rôle d’administrateur d’équipe

Approche de gestion des autorisations

Pour gérer efficacement les autorisations :

1. Commencer par les valeurs par défaut : utiliser des groupes intégrés comme base
2. Accorder des autorisations spécifiques : Ajouter des autorisations pour des besoins spécifiques
3. Utiliser des groupes de sécurité : tirer parti des groupes Azure AD pour faciliter la gestion
4. Révisions régulières : auditer régulièrement les autorisations pour l’adéquation
5. Décisions relatives aux documents : Conserver les dossiers des octrois d’autorisations et des justifications

Pour obtenir une vue d’ensemble simplifiée des autorisations et affectations d’accès par défaut courantes, consultez Autorisations et accès.

Si vous débutez avec la gestion des autorisations, explorez Bien démarrer avec les autorisations, l’accès et les groupes de sécurité, l’héritage des autorisations et les groupes de sécurité.

Zones d’autorisation spécifiques

Pour gérer l’accès à des fonctionnalités spécifiques, consultez les articles suivants :

---

Gérer l’accès

• À propos des niveaux d’accès
• Ajouter des membres d’équipe (Azure DevOps Services)
• Modifier les niveaux d’accès (déploiements locaux)
• Ajouter des membres d’équipe (déploiements locaux)

autorisations

• Autorisations de chemin d’accès à la zone
• Autorisations de traitement
• Autorisations de requête et de dossier d’élément de travail
• Autorisations du tableau de bord
• Autorisations du plan de remise
• Autorisations d’étiquetage
• Autorisations de test

Ressources partagées

• Alertes
• Chemins d’accès à la zone
• Chemins d’itération
• Requêtes
• Balises

---

Autres options de personnalisation

Au-delà des fonctionnalités de personnalisation intégrées, envisagez ces options supplémentaires pour étendre les fonctionnalités Azure DevOps :

Extensions de la Place de marché

• Parcourir les solutions : consultez les extensions de la Place de marché pour voir s’il existe un outil disponible à vos fins
• Catégories populaires : Rechercher des extensions dans le suivi des travaux, la création de rapports et la gestion des projets
• Contributions de la communauté : Tirer parti des solutions développées par la communauté Azure DevOps

Options de développement personnalisées

• Créer des extensions : Développer votre propre extension pour des besoins spécifiques de l'organisation
• Outils d’intégration : Créer des intégrations personnalisées à l’aide d’API REST
• Hooks de service : déterminez si un hook de service satisfait vos besoins d’automatisation

Engagement de la communauté

• Demandes de fonctionnalités : ajouter une demande de fonctionnalité à notre page Communauté des développeurs
• Commentaires des utilisateurs : partager vos expériences et suggestions avec l’équipe produit
• Meilleures pratiques : Découvrir les approches de personnalisation d’autres organisations

Planification de votre stratégie de personnalisation

Avant d’implémenter des personnalisations, tenez compte des éléments suivants :

1. Exigences métier : définissez clairement ce que vous souhaitez réaliser
2. Évaluation d’impact : Comprendre comment les modifications affectent les flux de travail existants
3. Surcharge de maintenance : tenez compte du coût à long terme de la maintenance des personnalisations
4. Solutions alternatives : Évaluer si les fonctionnalités existantes répondent à vos besoins
5. Chemin de migration : Planifier les futures mises à jour et migrations

Étapes suivantes

Configurer et personnaliser Azure Boards

Articles connexes

• Index des champs Élément de travail
• outil en ligne de commande witAdmin
• Gérer les modèles de processus
• Vue d’ensemble des modèles de processus
• Limites du suivi du travail, des processus et des projets
• Index de référence rapide pour les paramètres Azure Boards