Définir, capturer, trier et gérer les bogues logiciels dans Azure Boards

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

Comment suivez-vous et gérez-vous les défauts dans votre code ? Comment vous assurez-vous que les problèmes logiciels et les commentaires des clients sont traités rapidement pour assurer des déploiements logiciels de haute qualité ? Et comment optimisez-vous votre progression sur les nouvelles fonctionnalités et la résolution de votre dette technique ?

Au minimum, vous avez besoin d’un moyen de capturer vos problèmes logiciels, de les hiérarchiser, de les affecter à un membre de l’équipe et de suivre la progression. Vous souhaitez également gérer vos défauts de code d’une manière qui s’aligne sur vos pratiques Agile.

Pour prendre en charge ces scénarios, Azure Boards fournit un type d’élément de travail spécifique pour suivre les défauts de code : Bogue. Les éléments de travail bogue partagent toutes les fonctionnalités standard des autres types d’élément de travail, avec quelques ajouts. Pour obtenir une vue d’ensemble des fonctionnalités standard, consultez Suivre le travail avec des récits d’utilisateur, problèmes, bogues, fonctionnalités et épopées.

Les bogues fournissent également les fonctionnalités supplémentaires suivantes :

• Options permettant à chaque équipe de choisir la façon dont elle souhaite effectuer le suivi des bogues
• Outils de test pour capturer les bogues
• Intégration dans Azure DevOps pour suivre les bogues liés aux builds, aux versions et aux tests

Notes

Les types d’éléments de travail bogue ne sont pas disponibles avec le processus de base. Le processus de base suit les bogues en tant que problèmes et est disponible lorsque vous créez un projet à partir d’Azure DevOps Services ou Azure DevOps Server 2019.1 ou versions ultérieures.

Prérequis

• Vous devez être ajouté à un projet.
• Pour afficher ou modifier des éléments de travail, vous devez régler vos autorisations Afficher les éléments de travail dans ce nœud. et Modifier les éléments de travail dans ce nœud sur Autoriser. Cette autorisation est définie par défaut pour le groupe Contributeurs. Pour plus d'informations, consultez Définir les autorisations et l'accès pour le suivi du travail.
• Pour pouvoir ajouter de nouvelles étiquettes à des éléments de travail, vous devez disposer d’un accès de base ou supérieur et avoir défini les autorisations de création d’étiquettes sur Autoriser. Par défaut, ce jeu d’autorisations est défini sur le groupe Contributeurs. Même si l’autorisation est définie explicitement pour une partie prenante, celle-ci n’a pas l’autorisation d’ajouter de nouvelles étiquettes, car c’est interdit par son niveau d’accès. Pour plus d’informations, consultez Référence rapide sur l’accès de partie prenante.
• Tous les membres du projet, même les membres du groupe Lecteurs, peuvent envoyer des e-mails contenant des éléments de travail.

Conseil

Pour signaler un bogue, les utilisateurs doivent disposer au minimum de l’accès Partie prenante et de l’autorisation Modifier des éléments de travail dans ce nœud définie sur Autoriser pour le Chemin de zone où ils ajoutent le bogue. Pour plus d'informations, consultez Définir les autorisations et l’accès pour le suivi de travail

Type d’élément de travail bogue

L’image suivante montre le type d’élément de travail bogue pour le processus Scrum. Le type d’élément de travail bogue pour les processus Agile et CMMI suit des informations similaires. Il est conçu pour apparaître sur le backlog de produit avec les exigences ou sur le tableau des tâches avec les tâches.

Notes

Les images que vous voyez à partir de votre portail web peuvent différer de celles que vous voyez dans cet article. Ces différences résultent des mises à jour apportées à votre application web, des options que vous ou votre administrateur avez activées et du processus choisi lors de la création de votre projet : Agile, Basic, Scrum ou CMMI. Le processus de base est disponible avec Azure DevOps Server 2019 Update 1 et versions ultérieures.

Champs spécifiques aux bogues

Le type d’élément de travail bogue utilise certains champs spécifiques aux bogues. Pour capturer à la fois le problème initial et les découvertes en cours, utilisez les champs décrits dans le tableau suivant. Pour plus d’informations sur les champs spécifiques au bogue définis pour le processus CMMI (Capability Maturity Model Integration), consultez Informations de référence sur les bogues, les problèmes et les risques. Pour plus d’informations sur tous les autres champs, consultez Index des champs d’élément de travail.

---

Champ, Groupe ou Onglet

Utilisation

---

Étapes à reproduire
(nom convivial=étapes de reproduction)

Utilisez pour capturer suffisamment d’informations afin que les autres membres de l’équipe puissent comprendre pleinement le défaut de code. Inclut les actions entreprises pour rechercher ou reproduire le bogue et le comportement attendu.

---

Informations système
Trouvé dans la build

Informations sur la configuration logicielle et système qui se rapporte au bogue, et les tests à appliquer. Les champs Informations système et Trouvé dans la build sont automatiquement renseignés lorsque vous créez un bogue via un outil de test. Ces champs spécifient des informations sur l’environnement logiciel et créent l’emplacement où le bogue s’est produit. Pour plus d’informations, consultez Tester différentes configurations.

---

Critères d'acceptation

Fournissez les critères à respecter avant que le bogue puisse être fermé. Avant le début du travail, décrivez les critères d’acceptation des clients aussi clairement que possible. Les équipes doivent utiliser ces critères comme base pour les tests d’acceptation et pour évaluer si un élément a été terminé de manière satisfaisante.

---

Intégré dans la build

Spécifie le nom de la build qui contient le code permettant de résoudre le bogue. Ce champ doit être spécifié lorsque vous résolvez le bogue. Pour Azure DevOps local Pour accéder à un menu déroulant de toutes les builds qui ont été exécutées, vous pouvez mettre à jour les définitions FIELD pour Trouvé dans la build et Intégré dans la build pour qu’elles fassent référence à une liste globale. La liste globale est mise à jour automatiquement à chaque exécution d'une build. Pour plus d’informations, consultez Requête basée sur les champs de génération et d’intégration de test.
Pour plus d’informations sur la définition des numéros de build, consultez Options de format de numéro de build.

---

Priorité¹

• 1 : Le produit nécessite une résolution réussie et rapide de l’élément de travail avant d’être expédié.
• 2 : Le produit nécessite une résolution réussie de l’élément de travail avant son expédition, mais il n’a pas besoin d’être traité immédiatement.
• 3 : la résolution de l’élément de travail est facultative et dépend des ressources, du temps et des risques.

---

Gravité¹

Évaluation subjective de l’impact d’un bogue ou d’un élément de travail sur le projet ou le système logiciel. Par exemple : si un lien distant au sein de l’interface utilisateur (un événement rare) provoque un blocage d’une application ou d’une page web, une expérience client grave peut être spécifiée. Vous pouvez spécifier Gravité = 2 - Élevée et Priorité = 3. Les valeurs autorisées et les recommandations suggérées sont les suivantes :

• 1 - Critique : doit être résolu. Défaut qui provoque l’arrêt d’un ou plusieurs composants système ou du système complet, ou provoque une altération importante des données. Et il n’existe aucune autre méthode acceptable pour obtenir les résultats requis.
• 2 - Élevé : envisager de corriger. Défaut qui provoque l’arrêt d’un ou plusieurs composants système ou du système complet, ou provoque une altération importante des données. Toutefois, une autre méthode acceptable existe pour obtenir les résultats requis.
• 3 - Moyen : (par défaut) un défaut qui amène le système à produire des résultats incorrects, incomplets ou incohérents.
• 4 - Faible : un défaut mineur ou esthétique pour lequel il existe des solutions de contournement acceptables pour obtenir les résultats requis.

---

Déploiement

Le contrôle Déploiement prend en charge les liens vers et l’affichage des versions qui contiennent des éléments de travail. Pour utiliser le contrôle, vous devez activer les paramètres pour la mise en production. Pour plus d’informations, consultez Lier des éléments de travail à des versions plus loin dans cet article.

---

Développement

Le contrôle Développement prend en charge les liens vers et l’affichage des liens créés vers des objets de développement. Ces objets incluent les validations et les demandes de tirage Git, ou les ensembles de modifications TFVC et les éléments avec version. Vous pouvez définir des liens à partir de l’élément de travail ou des validations, des demandes de tirage ou d’autres objets de développement. Pour plus d’informations, consultez Lier des éléments de travail au développement plus loin dans cet article.

---

Remarques :

¹ Pour modifier la sélection de menu ou la liste de choix, consultez Personnaliser l’expérience de suivi du travail. La méthode de personnalisation dépend du modèle de processus utilisé par votre projet.

Choisir la façon dont votre équipe effectue le suivi des bogues

Votre équipe peut suivre les bogues en tant qu’exigences ou tâches. Pour prendre en charge le choix de l’équipe, tenez compte des facteurs suivants.

• Taille de votre équipe. Les petites équipes peuvent maintenir une empreinte légère en suivant les bogues comme exigences.
• Exigences de l’organisation pour suivre le travail. Si votre équipe est tenue de suivre les heures, choisissez de suivre les bogues en tant que tâches.
• Comment votre équipe organise le travail. Si votre équipe s’appuie sur le backlog de produit pour hiérarchiser le travail et ajouter des bogues, suivez les bogues en tant qu’exigences.
• Les outils que votre équipe souhaite utiliser, comme le volet Planification, le graphique de vélocité, les prévisions, le cumul et les plans de livraison. Le suivi des bogues en tant que tâches empêche l’utilisation de plusieurs de ces outils.

Le tableau suivant récapitule les trois options dont disposent les équipes pour suivre les bogues. Pour en savoir plus et définir l’option pour votre équipe, consultez Afficher les bogues dans les backlogs et les tableaux.

---

Option

Choisir quand vous souhaitez...

---

Suivre les bogues en tant qu’exigences

• Hiérarchiser (rang dans la pile) les bogues ainsi que les exigences
• Estimer l’effort du bogue pour la prévision
• Mettre à jour l’état du bogue sur le tableau Kanban
• Inclusion des bogues dans les graphiques de vélocité et les diagrammes de flux cumulé
• Possibilité d’utiliser l’outil Prévision pour prendre en charge la planification de sprint
• Possibilité de glisser-déplacer des bogues dans le volet Planification pour affecter des bogues à un sprint
• Possibilité d’afficher des bogues sur les Plans de livraison

Notes

• Les bogues sont attribués à la catégorie de configuration requise

---

Effectuer le suivi des bogues en tant que tâches

• Estimer le travail pour les bogues similaires, comme pour les tâches
• Mettre à jour l’état du bogue sur les tableaux de tâches de sprint
• Lier les bogues aux exigences en tant qu’éléments enfants
• Possibilité de glisser-déplacer des bogues dans le volet Planification pour affecter des bogues à un sprint

Notes

• Les bogues sont affectés à la catégorie de tâche
• Récits utilisateur (Agile), Élément de backlog de produit (Scrum) ou Exigences (CMMI) sont les types d’élément de travail parent naturels pour les bogues
• Les bogues ne seront pas visibles sur les plans de livraison

---

Les bogues n’apparaissent pas dans les backlogs et tableaux

• Gérer les bogues à l’aide de requêtes

Notes

• Les bogues sont associés à la catégorie Bogues et n’apparaissent pas sur les backlogs ou les tableaux
• Les bogues ne sont pas visibles sur les backlogs, les tableaux de bord, les backlogs de sprint, les tableaux de tâches ou les plans de livraison
• Impossible de glisser-déplacer des bogues dans le volet Planification pour affecter des bogues à un sprint

---

Personnaliser un type d’élément de travail

Vous pouvez personnaliser le bogue et d’autres types d’élément de travail. Vous pouvez également créer des types personnalisés pour suivre les problèmes logiciels ou les commentaires des clients. Avec tous les types d’élément de travail, vous pouvez personnaliser les éléments suivants :

• Ajouter ou supprimer des champs personnalisés
• Ajouter des contrôles personnalisés ou des onglets personnalisés dans le formulaire d’élément de travail
• Personnaliser les états du workflow
• Ajouter des règles conditionnelles
• Choisir le niveau de backlog dans lequel les éléments de travail s’affichent

Avant de personnaliser votre processus, nous vous recommandons de consulter Configurer et personnaliser Azure Boards.

Pour personnaliser votre processus particulier, consultez Personnaliser un processus d’héritage.

Ajouter ou capturer des bogues

Vous pouvez définir des bogues à partir de plusieurs outils Azure DevOps différents. Il s’agit notamment des backlogs et des tableaux et des outils de test.

Conseil

Par défaut, le champ Titre est le seul champ obligatoire lors de la création d’un bogue. Vous pouvez rapidement ajouter des bogues de la même façon que vous ajoutez des récits utilisateur ou des éléments de backlog de produit à l’aide d’Azure Boards. Si vous souhaitez rendre certains champs obligatoires, ajoutez des règles conditionnelles basées sur un changement d’état. Pour plus d’informations, consultez Ajouter une règle à un type d’élément de travail (processus d’héritage).

Ajouter un bogue à partir de votre backlog ou de votre tableau

Si votre équipe a choisi de gérer les bogues avec les exigences, vous pouvez définir des bogues à partir de votre backlog de produit ou tableau Kanban. Pour plus d’informations, consultez Créer votre backlog de produit ou Commencer à utiliser votre tableau Kanban.

• Ajouter un bogue à partir du backlog de produit

  

• Ajouter un bogue à partir du backlog de produit

  

Conseil

Lorsque vous ajoutez un bogue à partir de votre backlog de produit ou tableau Kanban, le bogue se voit automatiquement attribuer le chemin de zone et le chemin d’itération par défaut définis pour l’équipe. Pour plus d’informations, consultez Valeurs par défaut de l’équipe référencées par les backlogs et les tableaux.

Ajouter un bogue à partir de votre backlog de sprint ou de votre tableau des tâches

Si votre équipe a choisi de gérer les bogues avec des tâches, vous pouvez définir des bogues à partir de votre tableau Kanban, du backlog de produit, du backlog de sprint ou du tableau des tâches Sprint. Vous ajoutez un bogue en tant qu’enfant à un élément de travail du backlog de produit.

• Ajouter un bogue enfant lié à partir du tableau Kanban
  Vous ajoutez un bogue de la même façon que vous ajoutez une tâche à un élément de backlog. Pour obtenir plus d’informations, consultez Ajouter des tâches ou des éléments enfants en tant que listes de contrôle.

  

• Ajouter un bogue enfant lié à partir du backlog de sprint
  Vous ajoutez un bogue de la même façon que vous ajoutez une tâche à un backlog de sprint. Pour plus d’informations, consultez Ajouter des tâches aux éléments de backlog.

  

Créer un bogue à partir d’un outil de test

Les deux outils de test que vous pouvez utiliser pour ajouter des bogues lors du test sont l'exécuteur de tests du portail Web et l'extension de test et de retour d'expérience.

• Exécuteur de tests : lorsque vous exécutez des tests manuels, vous pouvez choisir de Créer un bogue. Pour plus d'informations, consultez Planifier des tests manuels.

  

• Extension Test & Feedback : lors de l’exécution de tests exploratoires, vous pouvez choisir de créer un bogue ou de créer une tâche. Pour plus d'informations, consultez Tests exploratoires avec extension de test et de retour d'expérience

Cycle de vie des bogues et états de workflow

Comme pour tous les autres types d’élément de travail, le type d’élément de travail bogue a un workflow bien défini. Chaque workflow se compose de trois États ou plus et d’une Raison. Les raisons spécifient la raison pour laquelle l’élément est passé d’un état à un autre. Les images suivantes illustrent le workflow de bogue par défaut défini pour les processus Agile, Scrum et CMMI.

Agile	Scrum	CMMI

Pour les bogues Scrum, vous modifiez l’État de Validé (similaire à Actif) à Terminé. Pour Agile et CMMI, vous devez d’abord résoudre le bogue et sélectionner une raison qui indique que le bogue est résolu. En règle générale, la personne qui a créé le bogue vérifie ensuite le correctif et met à jour l’État de Résolu à Fermé. Si davantage de travail a été trouvé après la résolution ou la fermeture d’un bogue, vous pouvez le réactiver en définissant l’État sur Validé ou Actif.

Notes

Le type d’élément de travail bogue du processus Agile avait précédemment une règle qui réaffectait le bogue à la personne qui l’a créé. Cette règle a été supprimée du processus système par défaut. Vous pouvez rétablir cette automatisation en ajoutant une règle. Pour un processus d’héritage, consultez Appliquer des règles aux états de workflow, Automatiser la réaffectation en fonction du changement d’état.

Vérifier un correctif

Pour vérifier un correctif, un développeur ou un testeur tente de reproduire le bogue et recherche d’autres comportements inattendus. Si nécessaire, ils doivent réactiver le bogue.

Lors de la vérification d’un correctif de bogue, vous pouvez constater que le bogue n’a pas été résolu ou que vous n’êtes pas d’accord avec la résolution. Dans ce cas, discutez du bogue avec la personne qui l’a résolu, trouvez un accord et réactivez éventuellement le bogue. Si vous réactivez un bogue, incluez les raisons de la réactivation dans la description du bogue.

Fermer un bogue

Vous fermez un bogue une fois qu’il a été vérifié comme corrigé. Toutefois, vous pouvez également fermer un bogue pour l’une des raisons suivantes. Les raisons disponibles à la sélection dépendent du processus de projet et des états de transition du bogue.

Processus Agile :

• Différé : reporter la correction du bogue jusqu’à la prochaine version du produit.
• Résolu : le bogue est vérifié comme étant résolu.
• Doublon : le bogue suit un autre bogue actuellement défini. Vous pouvez lier chaque bogue avec le type de lien Doublon/Doublon de et fermer l’un des bogues.
• Correspond aux spécifications : la fonctionnalité fonctionne comme prévu.
• Reproduction impossible : les tests prouvent que le bogue ne peut pas être reproduit.
• Obsolète : la fonctionnalité du bogue n’est plus dans le produit.
• Copié dans backlog : un récit utilisateur a été ouvert pour suivre le bogue.

Processus Scrum :

• Pas un bogue : il a été vérifié qu’il ne s’agit pas d’un bogue.
• Doublon : le bogue suit un autre bogue actuellement défini. Vous pouvez lier chaque bogue avec le type de lien Doublon/Doublon de et fermer l’un des bogues.
• Supprimé du backlog : il a été vérifié qu’il ne s’agit pas d’un bogue. Supprimez le bogue du backlog.
• Travail terminé : le bogue a été vérifié comme corrigé.

Processus CMMI :

• Différé : reporter la correction du bogue jusqu’à la prochaine version du produit.
• Doublon : le bogue suit un autre bogue actuellement défini. Vous pouvez lier chaque bogue avec le type de lien Doublon/Doublon de et fermer l’un des bogues.
• Rejeté : il a été vérifié qu’il ne s’agit pas d’un bogue.
• Vérifié : le bogue est vérifié comme corrigé.

Conseil

Une fois qu’un bogue a été fermé et que le correctif est activement publié dans les déploiements, il est recommandé de ne jamais le rouvrir en raison d’une régression. Au lieu de cela, vous devez envisager d’ouvrir un nouveau bogue et d’établir un lien vers l’ancien bogue fermé.

Il est toujours judicieux de décrire d’autres détails pour la fermeture d’un bogue dans le champ Discussion afin d’éviter toute confusion future quant à la raison pour laquelle le bogue a été fermé.

Automatiser la fermeture des bogues lors de la fusion des demandes de tirage

Si votre équipe utilise un dépôt Git, vous pouvez définir l’état dans les bogues liés et d’autres éléments de travail pour qu’il se ferme en cas de fusion réussie des demandes de tirage. Pour plus d’informations, consultez Définir l’état de l’élément de travail dans une demande de tirage plus loin dans cet article.

Répertorier et trier les bogues

La plupart des équipes, quelle que soit l’option choisie pour suivre les bogues, définissent une ou plusieurs requêtes de bogues. Avec les requêtes, vous pouvez répertorier les bogues actifs, les bogues non attribués, les bogues obsolètes, les tendances des bogues, etc. Vous pouvez ensuite ajouter des requêtes et des graphiques de requête aux tableaux de bord de votre équipe pour surveiller l’état et la progression des bogues.

Requêtes de bogue

Ouvrez une requête partagée ou utilisez l’éditeur de requête pour créer des requêtes de bogue utiles, comme les options suivantes :

• Bogues actifs par priorité (State <> Done ou State <> Closed)
• Bogues en cours (State = Committed ou State = Active)
• Bogues à corriger pour une version cible (Tags Contains RTM)
• Bogues récents : bogues ouverts au cours des trois dernières semaines (Created Date > @Today-21)

Une fois que vous avez les requêtes qui vous intéressent, vous pouvez créer des graphiques d’état ou de tendance. Vous pouvez également ajouter le graphique que vous créez à un tableau de bord.

Mode de tri dans les résultats de la requête

Une fois que vous avez commencé à coder et à tester, vous pouvez organiser des réunions de tri périodiques pour examiner et classer vos bogues. En règle générale, le propriétaire du projet est en charge des réunions de triage des bogues. Les responsables d’équipe, les analystes d’entreprise et d’autres parties prenantes qui peuvent parler des risques spécifiques du projet assistent aux réunions de triage.

Le propriétaire du projet peut définir une requête partagée pour les bogues nouveaux et rouverts afin de répertorier les bogues à trier.

À partir de la page des résultats de la requête, vous pouvez rapidement monter et descendre dans la liste des éléments de travail bogue à l’aide des flèches haut et bas. Lorsque vous passez en revue chaque bogue, vous pouvez l’affecter, lui ajouter des détails ou définir sa priorité.

Organiser et affecter des bogues à un sprint

Si votre équipe effectue le suivi des bogues en tant qu’exigences, affichez la liste des bogues actifs de votre backlog. Avec la fonction de filtre, vous pouvez vous concentrer uniquement sur les bogues. À partir du backlog de produit, vous pouvez également effectuer les tâches suivantes :

• Organiser les bogues sur votre backlog, classer la pile par rapport à d’autres éléments (le classement de la pile est désactivé lorsque le filtrage est activé)
• Affecter des bogues à un sprint à partir de votre backlog à l’aide du volet Planification
• Apparenter des bogues à des fonctionnalités ou d’autres éléments du backlog de portefeuille à l’aide du volet Mappage
• Afficher le cumul du travail sur les éléments du backlog de portefeuille.

Si votre équipe effectue le suivi des bogues en tant que tâches, utilisez des requêtes managées pour répertorier et trier les bogues. Ensuite, dans chaque sprint, vous verrez les bogues affectés au sprint à partir du backlog de sprint ou du tableau des tâches.

Éléments du tableau des tâches et éléments de liste de requête

Vous pouvez remarquer et vous demander pourquoi les éléments affichés dans un tableau des tâches de sprint peuvent différer d’une liste de requêtes créée dans un backlog de sprint correspondant.

Il est possible d’assigner des tâches ou bogues à une itération sans les lier à un élément du backlog parent. Ces éléments apparaissent dans la requête créée, mais peuvent ne pas s’afficher dans le tableau des tâches proprement dit. Le système exécute la requête, puis applique quelques processus en arrière-plan avant d’afficher les éléments du tableau de tâches.

Ces raisons peuvent entraîner l’absence des éléments de travail appartenant à la catégorie de tâche dans un backlog des sprints ou un tableau de tâches :

• La tâche ou le bogue n’a pas été lié à un élément parent du backlog. Seuls les bogues et tâches que vous avez liés à un élément de backlog du produit parent (Scrum), à un récit utilisateur (Agile) ou à une spécification (CMMI) dont le chemin d’accès d’itération est défini sur le sprint apparaîtront dans la page du backlog des sprints.
• La tâche ou le bogue est un parent d’une autre tâche ou d’un autre bogue, ou le récit utilisateur est un parent d’un autre récit utilisateur. Si vous avez créé une hiérarchie de tâches, de bogues ou de récits utilisateur, seules les tâches de niveau enfant ou les récits de niveau enfant en bas de la hiérarchie apparaissent.
• Le parent lié à la tâche ou au bogue correspond à un élément de backlog défini pour une autre équipe, ou le chemin de zone de l’élément parent du backlog de la tâche ou du bogue est différent du chemin de zone de la tâche ou du bogue.

Créer des tests inline liés à des bogues

Lorsque votre équipe effectue le suivi des bogues en tant qu’exigences, vous pouvez utiliser le tableau Kanban pour ajouter des tests afin de vérifier les correctifs de bogues.

Mettre à jour l’état du bogue

Vous pouvez mettre à jour l’état du bogue en faisant glisser et en déposant des bogues dans une nouvelle colonne sur une carte.

• Si votre équipe effectue le suivi des bogues en tant qu’exigences, vous utilisez le tableau Kanban comme illustré dans l’image suivante. Pour plus d’informations, consultez Prise en main de votre tableau Kanban.

  

• Si votre équipe suit les bogues en tant que tâches, vous utilisez le tableau des tâches. Pour obtenir plus d’informations, consultez Mettre à jour et analyser votre tableau des tâches.

  

Personnaliser votre tableau pour suivre les états intermédiaires

Vous pouvez ajouter des colonnes intermédiaires pour suivre l’état de votre bogue sur la carte. Vous pouvez également définir des requêtes qui filtrent en fonction de l’état d’une colonne de tableau. Pour plus d’informations, consultez les articles suivants :

• Ajouter des colonnes à votre tableau Kanban
• Personnaliser un tableau des tâches de sprint
• Requêtes de modification du tableau Kanban

Automatiser la réaffectation des bogues en fonction de l’état du workflow

Pour automatiser les actions de sélection, ajoutez des règles personnalisées à votre type d’élément de travail bogue. Par exemple, ajoutez une règle comme illustré dans l’image suivante. Cette règle spécifie de réaffecter un bogue à la personne qui a ouvert le bogue une fois qu’il est résolu. En règle générale, cette personne vérifie que le bogue est résolu et ferme le bogue. Pour plus d’informations, consultez Appliquer des règles aux états de flux de travail (processus d’héritage).

Définir l’état de l’élément de travail dans la demande de tirage

Lorsque vous créez une demande de tirage, vous pouvez définir la valeur d’État des éléments de travail liés dans la description. Suivez la syntaxe : {state value}: #ID. Lorsque vous fusionnez la demande de tirage, le système lit la description et met à jour l’état de l’élément de travail. Dans l’exemple suivant, nous définissons les éléments de travail #300 et #301 sur Résolu, et #323 et #324 sur Fermé.

Intégration dans Azure DevOps

L’une des méthodes utilisées par Azure DevOps pour prendre en charge l’intégration consiste à lier des objets à d’autres objets. En plus de lier des éléments de travail entre eux, vous pouvez également lier des éléments de travail à d’autres objets. Créez un lien vers des objets, comme les builds, les versions, les branches, les validations et les demandes de tirage, comme illustré dans l’image suivante.

Vous pouvez ajouter un lien à partir de l’élément de travail ou des objets de build et de mise en production.

Lier des éléments de travail au développement

Le contrôle Développement prend en charge la liaison vers et l’affichage des liens créés vers les builds, les validations Git et les demandes de tirage. Ou, lorsqu’un dépôt TFVC est utilisé, il prend en charge les liens vers les ensembles de modifications et les éléments avec version. Choisir le lien ouvre l’élément correspondant dans un nouvel onglet de navigateur. Pour plus d’informations, consultez Diriger le développement Git depuis un élément de travail .

Lier des éléments de travail à des versions

Le contrôle Déploiement prend en charge les liens vers et l’affichage des versions qui contiennent des éléments de travail. Par exemple, l’image suivante montre plusieurs versions qui contiennent des liens vers l’élément de travail actuel. Vous pouvez développer chaque version pour afficher des détails sur chaque étape. Vous pouvez choisir le lien pour chaque version et étape pour ouvrir la version ou phase correspondante. Pour plus d’informations, consultez Lier des éléments de travail aux déploiements.

Lier des éléments de travail à des exécutions de pipeline

Des pipelines sont souvent définis pour s’exécuter automatiquement lorsqu’une nouvelle validation se produit dans un dépôt Git. Les éléments de travail associés aux pipelines de validation s’affichent dans le cadre de l’exécution du pipeline si vous personnalisez les paramètres de votre pipeline. Pour plus d’informations, consultez Personnaliser votre pipeline.

Créer ou modifier un élément de travail en cas d’échec de build

Si vous utilisez des pipelines classiques (non YAML), vous pouvez créer des éléments de travail en cas d’échec de build. Pour plus d’informations, consultez Options de génération, créer un élément de travail en cas d’échec.

Surveiller l’état des bogues, les affectations et les tendances

Vous pouvez suivre l’état des bogues, les affectations et les tendances à l’aide de requêtes que vous pouvez ensuite représenter visuellement et ajouter à un tableau de bord. Par exemple, voici deux exemples montrant les tendances des bogues actifs par état et les bogues actifs par priorité au fil du temps.

Pour en savoir plus sur les requêtes, les graphiques et les tableaux de bord, consultez À propos des requêtes managées et Graphiques et Tableaux de bord.

Utiliser les vues Analytics et le service Analytics pour créer des rapports de bogues

Le service Analytics est la plateforme de création de rapports pour Azure DevOps ; elle remplace la plateforme précédente basée sur SQL Server Reporting Services.

Les vues Analytics fournissent des filtres prédéfinis pour afficher les éléments de travail. Quatre vues analytiques sont prises en charge pour la création de rapports de bogues. Vous pouvez utiliser ces vues telles qu’elles sont définies, ou les modifier davantage pour créer une vue filtrée personnalisée.

• Bogues - Ensemble de l’historique par mois
• Bogues - Dernières 26 semaines
• Bogues - 30 derniers jours
• Bogues - Aujourd’hui

Pour en savoir plus sur l’utilisation des vues Analytics, consultez Que sont les vues Analytics et Créer un rapport de bogues actif dans Power BI basé sur une vue Analytics personnalisée.

Vous pouvez utiliser Power BI pour créer des rapports plus complexes que ce que vous pouvez obtenir à partir d’une requête. Pour plus d’informations, consultez Se connecter avec Power BI Data Connector.

Extensions de la Place de marché

Il existe plusieurs extensions de la Place de marché liées aux bogues. Consultez Place de marché pour Azure DevOps.

Pour plus d’informations sur les extensions, consultez Extensions Azure Boards développées par Microsoft.

Étapes suivantes

Utiliser des modèles pour ajouter et mettre à jour des éléments de travail

Articles connexes

• Déplacer, modifier le type ou supprimer des éléments de travail
• Copier ou cloner un élément de travail

Backlog de produit et tableau Kanban

• Backlogs, portefeuilles et gestion de projet Agile
• Créer votre backlog
• Définir des fonctionnalités et des épopées
• Organiser votre backlog, mapper les éléments de travail enfants aux parents
• Filtrer de manière interactive les backlogs, les tableaux, les requêtes et les plans
• Prévoir votre backlog de produit

Tableau Kanban

• À propos des tableaux et de Kanban
• Démarrage rapide du tableau Kanban
• Réorganiser les cartes
• Ajouter des tâches ou des éléments enfants en tant que listes de contrôle

Backlog de sprint et tableau des tâches

• Bonnes pratiques Scrum et utilisation des sprints
• Affecter des éléments de backlog à un sprint
• Ajouter des tâches
• Mettre à jour le tableau des tâches

Intégration dans Azure DevOps

• Lier des récits utilisateur, des problèmes, des bogues et d’autres éléments de travail
• Suivre un élément de travail ou une demande de tirage
• Configurer des numéros d’exécution ou de build

Ressources du secteur

• Good and Bad Technical Debt (and how TDD helps) par Henrik Kniberg
• Managing Technical Debt publié par Sven Johann & Eberhard Wolff