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é ? Comment progresser efficacement sur les nouvelles fonctionnalités et traiter 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 gérer vos défauts de code de manière cohérente avec vos pratiques Agile.

Pour soutenir ces scénarios, Azure Boards fournit un type d’élément de travail spécifique pour suivre les défauts de code nommé Bug. Les éléments de travail bogue partagent toutes les fonctionnalités standard des autres types d’élément de travail, avec quelques ajouts. Pour un aperçu des fonctionnalités standard, veuillez consulter la section À propos des éléments de travail et des types d’éléments de travail.

Les bugs offrent également les fonctionnalités 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

Prérequis

• Accès au projet : être membre du projet.

• Autorisations :

  • Vos autorisations Afficher vos éléments de travail dans ce nœud et Modifier les éléments de travail dans ce nœud doivent être définies sur Autoriser. Par défaut, le groupe des contributeurs dispose de ces permissions. Pour plus d’informations, consultez Définir les autorisations de suivi du travail.

  • Pour ajouter de nouvelles balises aux éléments de travail, disposez au moins d’un accès de base et de l’autorisation Créer une définition de balise au niveau du projet sur Autoriser. Par défaut, ce jeu d’autorisations est défini sur le groupe Contributeurs.

    Remarque

    Les parties prenantes ne peuvent pas ajouter de nouvelles balises, même si l’autorisation est définie explicitement en raison de leur niveau d’accès. Pour plus d’informations, consultez Référence rapide sur l’accès de partie prenante.

• Envoyer des éléments de travail par e-mail : Tous les membres du projet, y compris ceux du groupe Lecteurs, peuvent envoyer des e-mails contenant des éléments 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 Bug pour les processus Agile et Capability Maturity Model Integration (CMMI) suit des informations similaires. Il apparaît dans le backlog du produit avec les exigences ou dans le Taskboard avec les tâches.

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 de reproduction (nom convivial = Étapes de repro)

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.

---

Infos systèmeTrouvé dans le 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 est complété 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 sur site, pour accéder à un menu déroulant de tous les builds qui ont été exécutés, vous pouvez mettre à jour les définitions FIELD pour Trouvé dans le build et Intégré dans le build pour faire 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 des informations sur la façon de définir des numéros de build, veuillez consulter la section Configuration des pipelines classiques.

---

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, en fonction 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 dans l’interface utilisateur (un événement rare) provoque le crash d’une application ou d’une page web (une expérience client sévère), 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. Il n’existe aucune méthode alternative 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. Une méthode alternative 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é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.

---

Notes

¹ 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.
• Organisation du travail de votre équipe. 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

• Priorisez, ou classez les bugs avec les exigences
• Estimer l’effort du bogue pour la prévision
• Mettre à jour l’état du bogue sur le tableau
• Inclusion des bogues dans les graphiques de vélocité et les diagrammes de flux cumulé
• Soyez en mesure d’utiliser l’outil de prévision pour soutenir la planification des sprints
• Faites glisser les bugs vers le volet Planification pour assigner les bugs à un sprint
• Afficher les bugs dans les plans de livraison

Remarque

• 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
• Faites glisser les bugs vers le volet Planification pour assigner les bugs à un sprint

Remarque

• 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 bugs ne sont pas visibles dans les plans de livraison

---

Les bogues n’apparaissent pas dans les backlogs et tableaux

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

Remarque

• Les bugs sont associés à la catégorie Bugs et n’apparaissent ni dans les backlogs ni dans les tableaux
• Les bugs ne sont pas visibles dans les backlogs, tableaux, backlogs de sprint, tableaux de tâches, ou plans de livraison
• Vous ne pouvez pas faire glisser les bugs vers le volet Planification pour les assigner à 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. Pour tous les types d’éléments 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 la section À propos de la configuration et de la personnalisation des Azure Boards.

Ajouter ou capturer des bogues

Vous pouvez définir des bogues à partir de plusieurs outils Azure DevOps différents. Ces outils incluent des backlogs, des tableaux et des outils de test.

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. Pour plus d’informations, veuillez consulter la section Créer votre backlog produit ou Utiliser votre tableau.

• Ajouter un bogue à partir du backlog de produit

  

• Ajouter un bug depuis le tableau

  

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, 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 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.

  

• Ajouter un bogue enfant lié à partir du tableau

  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.

  

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, veuillez consulter la section Test exploratoire avec l’extension Test & Feedback.

  

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 vous découvrez plus de travail après avoir résolu ou fermé un bug, réactivez-le en définissant l’État sur Engagé ou Actif.

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 bug lorsqu’un membre de l’équipe le vérifie comme étant corrigé. Toutefois, vous pouvez également fermer un bogue pour l’une des raisons suivantes. Les raisons disponibles dépendent du processus du projet et des états de transition du bug.

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é.

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é.

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 ajouter des requêtes et des graphiques de requêtes à vos tableaux de bord d’équipe pour surveiller le statut et l’avancement des bugs.

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)
• Des bugs récents, comme des bugs ouverts dans les trois dernières semaines (Created Date > @Today-21).

Lorsque vous avez les requêtes d’intérêt pour votre équipe, vous pouvez créer des graphiques de statut 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

Après avoir commencé à coder et à tester, tenez des réunions périodiques de triage pour réviser et classer vos bugs. 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.

Depuis la page de résultats de requête, vous pouvez naviguer dans la liste des éléments de travail de type bug en utilisant les 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 :

• Organisez les bugs dans votre backlog. Classez par rapport aux autres éléments. Le classement est désactivé lorsque le filtrage est activé.
• Assignez des bugs à un sprint depuis votre backlog en utilisant le volet Planification.
• Mappez les bugs parentaux aux fonctionnalités ou à d’autres éléments du backlog portfolio en utilisant le 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. Dans chaque sprint, vous voyez les bugs assignés au sprint depuis le backlog de sprint ou le Taskboard.

É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 des bugs à une itération mais de ne pas les lier à un élément de backlog parental. 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 bug n’est pas lié à un élément de backlog parental. Seuls les bugs et les tâches liés à un élément de backlog produit parental (Scrum), une user story (Agile) ou une exigence (CMMI) avec un chemin d’itération défini sur le sprint apparaissent dans la page du backlog de sprint.
• 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 créez une hiérarchie de tâches, bugs ou user stories, seuls les tâches de niveau enfant ou les stories de niveau enfant au bas de la hiérarchie apparaissent. Pour plus d’informations, consultez Résoudre les problèmes de réorganisation et d’imbrication.
• 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 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 comme illustré dans l’image suivante. Pour plus d’informations, veuillez consulter la section Mettre à jour le statut d’un élément de travail.

  

• 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 :

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 bug à la personne qui l’a ouvert lorsqu’un membre de l’équipe le résout. 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

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 et l’affichage des liens créés vers les builds, les commits Git et les pull requests. Lorsqu’un référentiel TFVC est utilisé, il prend en charge les liens vers les ensembles de modifications et les éléments versionnés. 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, veuillez consulter la section Créer un élément de travail en cas d’échec.

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

Vous pouvez suivre le statut des bugs, les assignations et les tendances en utilisant des requêtes que vous pouvez afficher sous forme de graphique 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 plus d’informations sur les requêtes, graphiques et tableaux de bord, veuillez consulter requêtes gérées, graphiques et tableaux de bord.

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

Articles connexes

• Retirer, supprimer ou restaurer des éléments de travail
• Copier ou cloner un élément de travail

Backlog de produit et tableau

• Utiliser des backlogs pour gérer des projets
• Créer votre backlog
• Définir des fonctionnalités et des épopées
• Organiser votre backlog et 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

Board

• À propos des tableaux et de Kanban
• Utiliser votre tableau
• 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

• Apprendre les bonnes pratiques Scrum
• Affecter des éléments de backlog à un sprint
• Ajouter des tâches
• Mettre à jour votre Taskboard

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