Racontez l’histoire de votre projet à l’aide des requêtes Azure DevOps et des tableaux de bord / blogs / perficient%

Parfois, regarder purement un backlog ou une planche Azure DevOps peut ne pas raconter la bonne histoire en termes de progrès réalisés vers un objectif spécifique. À première vue, cela peut sembler une histoire d’horreur, mais en réalité, ce n’est pas le cas. Les données doivent être lues de la bonne manière.

Bien qu’Azure DevOps fournit plusieurs façons de visualiser les éléments de travail, il offre également une puissante capacité de rapport en termes d’écriture de requêtes et de configuration de tableaux de bord.

Les éléments de travail dans Azure DevOps contiennent divers champs qui peuvent permettre des rapports de données. Cependant, pour rendre ces données significatives, les bonnes requêtes et l’utilisation de tableaux de bord peuvent aider à présenter l’état précis des travaux.

Auteur

Chaque requête Azure DevOps devrait avoir un motif. Les champs sur les éléments de travail sont des attributs qui peuvent aider à fournir une réponse. Examinons quelques cas d’utilisation et comment ces requêtes sont configurées.

Exemple 1: Je veux trouver tous les bogues de mon projet qui ne sont pas dans un état de «fermé» ou «supprimé» et qui contiennent une balise «CMS». Je peux utiliser le type d’élément de travail des champs de travail, «état» et «tags» pour trouver des correspondances.

Exemple 2: Je veux trouver tous les bogues qui sont la gravité 1 ou la gravité 2 qui ne sont pas fermés ou résolus (je veux voir uniquement la gravité 1 ou 2 bogues qui sont à l’état nouveau ou actif.) Dans cet exemple, j’ai regroupé les 2 lignes pour que la gravité soit une condition «ou». Cela me permet d’obtenir des résultats qui incluent à la fois les résultats de la gravité 1 et de la gravité 2.

Exemple 3: Je veux trouver tous les bogues qui contiennent la balise «exigence manquante» qui ont été créées le 5 novembre 2024 ou après ou après le rapport sur le rapport est par rapport à cet exemple, je demande des résultats créés après une date spécifique , mais vous pouvez modifier l’opérateur ou définir une plage de dates pour un contrôle supplémentaire des résultats.

Conseils:

• • Dans ces exemples, j’utilise des types de champs hors boîte, cependant, il existe des moyens de créer des champs personnalisés pour un projet Azure DevOps, pour enrichir ou personnaliser davantage vos rapports.
  • Passez en revue les colonnes que vous avez montrées une fois que vous avez exécuté une requête. Vous devrez peut-être utiliser les «options de colonne» pour activer des colonnes supplémentaires pour des points de données supplémentaires.
  • Enregistrez votre requête en tant que requête partagée, afin que ses résultats puissent être consultés par d’autres membres de l’équipe.

Avoir ces requêtes est excellent si vous avez besoin d’une liste d’éléments de travail ou si vous souhaitez effectuer des mises à jour en vrac pour les éléments qui correspondent à vos critères. Cependant, nous pouvons aller plus loin ces résultats en visualisant les données sur un tableau de bord.

Publiez vos résultats avec des tableaux de bord

Parfois, les visuels peuvent aider à mieux représenter une histoire; La même chose peut être vraie lors de la signalement des progrès d’un projet.

Aux casque, Azure DevOps fournit une variété de types de widgets qui peuvent être utilisés pour configurer un tableau de bord. Certains widgets nécessitent l’utilisation d’une requête, tandis que d’autres sont purement basés sur les paramètres que vous définissez.

Voici quelques exemples de widgets que j’utilise le plus souvent:

• Brûlure: Ce widget ne nécessite pas de requête. Lorsque vous placez le widget, vous pourrez contrôler comment les données sont tirées:
  • Type d’élément de travail
  • Dates
  • Équipe (le cas échéant)
  • Critères sur le terrain
  • Intervalle de temps (jours / semaines / mois)
• Tableau des articles de travail: Ce widget est basé sur une requête. Je trouve que ce widget est très polyvalent, car vous pouvez choisir le type de graphique et les points de données que vous souhaitez afficher.
• Résultats de la requête: Ce widget est basé sur une requête et affichera simplement les résultats dans une liste, cependant, vous pouvez sélectionner les colonnes de données à afficher / masquer dans le widget.
• Carreaux de requête: Ce widget est basé sur une requête et affichera le nombre de résultats correspondant à une requête. Vous pouvez encore personnaliser ce widget pour montrer dynamiquement dans les couleurs uniquesbasé sur des critères de comptage spécifiques.

Conseils:

• • Il n’y a pas de limite au nombre de tableaux de bord que vous pouvez avoir. Pensez à créer des tableaux de bord à des fins uniques ou à des publics uniques, qui ne contiennent que les données pertinentes nécessaires.
  • Les requêtes et les tableaux de bord sont aussi bons que vos données. Assurez-vous que vous maintenez régulièrement vos articles de travail pour vous assurer qu’ils sont étiquetés, parentaux et prioritaires de manière appropriée.
  • Il existe également une option pour exporter les résultats de la requête dans les fichiers Excel, si vous constatez que les widgets de tableau de bord ne répondent pas à tous vos besoins de rapport.

Transmettre l’histoire

Identifiez ce qui est le plus important pour votre équipe ou votre client de connaître, de surveiller ou de connaître. Une fois que vous avez les données dont vous avez besoin, vous serez mieux équipé pour expliquer les progrès et le statut à votre équipe et au client.

Dans mon expérience personnelle, certains types de tableaux de bord uniques que j’ai trouvés efficaces pour mes clients ou mes membres de l’équipe:

• Tableau de bord lié aux activités de l’UAT
• Tableau de bord pour la surveillance de la maintenance du backlog
• Tableau de bord pour les cadres
• Tableau de bord pour les activités basées sur le sprint QA
• Tableau de bord pour Dépendance surveillance

Exemple d’un tableau de bord exécutif, en utilisant Burndown, un graphique pour les articles de travail et des widgets de carreaux de requête:

Avec chacun de ces tableaux de bord, j’ai écrit des requêtes uniques pour trouver des données que mon équipe ou mon client avait le plus souvent besoin de référencer. Cela leur a permis de savoir si nous étions sur la bonne voie ou si une action est nécessaire.

En ayant un moyen précis d’expliquer l’histoire de votre projet, vous constaterez que votre équipe est en mesure de prendre de meilleures décisions lorsque les bonnes données sont à leur disposition, afin de mener à une fin de projet heureux.