Mon histoire de création d’un tableau de bord avancé de métriques de flux à l’aide de MS Excel et Jira
Depuis que je suis passé de développeur à temps plein à scrum master ou coach agile, j’ai constamment introduit des éléments d’analyse de données lors de discussions et de coaching dans divers scénarios. Cela peut avoir été en équipe, sur un projet ou même au niveau organisationnel. Parallèlement à mes expériences, différentes situations et contraintes m’ont amené à explorer comment accéder aux données et les préparer pour la discussion.
Dans certains cas, les contraintes étaient financières ; dans d’autres cas, elles étaient bureaucratiques. Mon objectif étant de fournir des informations efficaces et efficientes à mon public, ces contraintes sont devenues des défis que j’aime relever.
Dans cet article, je partagerai mon expérience dans la création d’un outil d’analyse de données à l’aide d’outils disponibles à l’échelle de l’industrie : Microsoft Excel et l’API Jira Rest. Ma motivation dans cette expérience était de ne pas utiliser de macros et de me limiter à des moyens potentiellement configurables via l’interface utilisateur « prête à l’emploi ». Tout d’abord, je vais vous donner un aperçu rapide de la façon dont j’ai assemblé ces technologies, puis je vous ferai un tour des données que j’ai analysées à l’aide de cet outil.
La logique derrière l’outil d’analyse que j’ai construit peut se résumer à ces séquences d’étapes :
- Identifier les données spécifiques à l’organisation (par exemple, les terminaux)
- Authentifier l’utilisateur
- Capturer les données montrant les mouvements de travail
- Filtrer et transformer les données dans un format qui permet l’analyse
- Transformez davantage les données afin qu’elles soient visibles lorsque chaque travail individuel a commencé et s’est arrêté
Dans les sections suivantes, je partagerai brièvement ce que ces étapes ont signifié dans mon parcours exploratoire avec Excel et Jira.
D’après mon expérience précédente, je savais qu’un discriminateur principal entre les instances spécifiques à l’organisation pour Atlassian Jira réside dans le sous-domaine. Il n’y a aucun moyen de l’obtenir sauf en demandant à l’utilisateur de le saisir.
En ce qui concerne l’authentification, j’ai exploré deux options : une que j’ai construite et une autre qui s’appuie sur MS Excel pour faciliter l’authentification. Les deux conduisent aux mêmes méthodes d’authentification.
Tout d’abord, un utilisateur doit créer une clé API pour accéder à l’API Jira REST. C’est quelque chose que tout utilisateur peut faire via la gestion de profil Atlassian.
Deuxièmement, selon qu’une organisation dispose de solutions sur site ou dans le cloud, la méthode d’authentification changerait entre l’authentification au porteur et l’authentification de base. D’une manière ou d’une autre, la solution nécessite que l’utilisateur configure tout ce qui précède.
Les défis de l’authentification
Dans ma première solution, j’ai créé une feuille de paramètres de connexion avec un tableau que l’utilisateur devrait remplir, y compris la méthode d’authentification. J’ai trouvé cette approche simple et intuitive pour la plupart des utilisateurs.
À l’exception de ces méthodes d’authentification de base, l’utilisateur doit coder sa clé API base64. Aussi facile et simple que cela puisse être pour les développeurs, les personnes non techniques pourraient trouver cela inutilement complexe.
L’autre solution consistait donc à déclencher les pouvoirs PowerQuery de MS Excel pour demander les détails d’authentification (similaire à ce que Nick Brown fait dans sa solution PowerBI, FlowViz). C’est très propre et ça marche.
Mais pas pour les utilisateurs de Mac. Malheureusement, et c’est un thème commun tout au long de cet article, les utilisateurs de Mac ont des fonctionnalités PowerQuery limitées.
Dans mon cas, j’ai décidé de m’en tenir à la première approche, qui comporte une table Paramètres de connexion qui reçoit les paramètres requis.
Avec l’authentification réglée, j’avais besoin de deux autres choses. Tout d’abord, j’avais besoin de l’ensemble de données à analyser. Cela pourrait être défini par une déclaration dans le langage de requête Jira (JQL) d’Atlassian. Lors de l’analyse de données historiques, vous devez généralement pouvoir capturer des données qui ont été créées, modifiées ou fermées sur une période. Ensuite, j’avais besoin de comprendre la portée (la profondeur, si vous voulez) des données interrogées sur les serveurs Jira. Cela nécessite des recherches supplémentaires dans la documentation de l’API Jira, mais heureusement, il s’agit principalement d’un effort ponctuel. Une fois que vous aurez compris la structure de l’API Jira, il vous sera facile de vous y retrouver. (Astuce : la plupart des informations se trouvent dans le changelog).
Une fois les données importées dans un tableau de données MS Excel, le dernier défi consiste à créer des marqueurs qui indiquent le début et la fin d’un travail. La bonne chose est que lorsque je préparais l’importation de données, j’avais trié le journal des modifications en fonction de la tâche et de la chronologie, donc une fois dans le tableau de données, je pouvais facilement supposer que tous les enregistrements suivaient un ordre clair.
Dans mon cas, j’ai décidé d’ajouter deux colonnes – une pour le début et une autre pour l’arrêt. Sur la base du changement de clé, j’ai pu repérer ces deux jalons. Avec cela en main, avec un simple FILTER
fonction, je pouvais construire les données dont j’avais besoin.
PowerQuery de MS Excel permet de nettoyer et de transformer facilement les données. Avant que les données importées ne soient déversées dans une feuille Excel, PowerQuery vous permet d’appliquer des étapes de transformation (comme le filtrage, le tri, l’extraction de dates, etc.). Malheureusement, PowerQuery n’est pas aussi avancé sur le Web et Mac que sur la version Windows de MS Excel. Les utilisateurs peuvent se retrouver coincés si quelque chose ne va pas dans la préparation lors de la réutilisation de cette feuille.
Enfin, j’ai dû adapter ma solution pour interroger plusieurs pages (jusqu’à 1 000 enregistrements) en raison des limites de Jira Cloud sur l’API. Essentiellement, pour obtenir ces 1 000 enregistrements, j’exécute dix appels de service Web de 100 enregistrements chacun. Ce n’est pas aussi propre que je l’aurais souhaité, mais c’est un prix raisonnable pour un outil pratique.
La longue histoire ci-dessus décrit brièvement comment j’ai mis des données dans une plate-forme et construit un tableau de bord d’équipe avec des transformations simples.
Avec les données start-stop en main, je pouvais continuer et créer des graphiques présentant les métriques de flux typiques : débit, temps de cycle, travail en cours et analyse de phase (percentiles dans différentes phases).
Dans l’image ci-dessous, vous pouvez voir comment j’ai réussi à façonner les données en me donnant des centiles ventilés pour les états individuels traversés par les différents tickets (ce que j’appelle l’analyse de phase). Cela, combiné à la capacité de réajuster le JQL pour s’assurer que nous capturons le bon ensemble de données, a créé les bons points de déclenchement pour des discussions fructueuses avec les équipes.
Je peux dire des choses similaires à propos d’un diagramme de dispersion du temps de cycle que j’ai produit. Dans ce cas, j’ai également profité de l’occasion pour expliquer comment j’éliminais les valeurs aberrantes (en utilisant l’intervalle interquartile). Même lorsque cette méthode était obscure ou peu convaincante, nous avons discuté et remodelé les données au fur et à mesure que nous parlions.
Excel avait certaines limites, et c’est là que j’ai décidé de ne pas promouvoir le résultat de mon expérience comme un outil que je pourrais partager avec le monde. Je partagerai ici deux défis.
Premièrement, les types de graphiques sont bons mais pas aussi étendus ou plastiques que je le souhaiterais lors de la construction de quelque chose de « sur mesure ». Par exemple, si l’on considère les limites WIP, qui sont généralement présentées sous la forme d’un diagramme à moustaches avec des références à la médiane, à la moyenne, aux quartiles et à l’IQR, le diagramme à boîtes dans Excel n’est pas aussi simple à configurer. Cela m’a poussé à improviser. J’ai apprécié le défi, mais il m’a fait produire des artefacts de qualité douteuse.
Le deuxième défi concerne les limitations des versions Web et Mac d’Excel, qui ont rendu très difficile pour les utilisateurs non Windows le débogage et la configuration des feuilles de calcul avec PowerQuery.
Aussi ardue qu’elle ait pu être une tâche, je crois avoir débloqué les réalisations suivantes :
- La tâche m’a permis de commencer à regarder au-delà des horizons des outils auxquels nous sommes si habitués
- Cela m’a bien servi d’entrer en contact avec les subtilités de l’analyse des données, de mieux comprendre l’histoire à laquelle j’assisterais lors de la discussion de l’analyse des données
- J’ai prouvé à moi-même, à mes collègues et à vous aussi, je l’espère, que l’analyse de données Agile / Lean peut être effectuée avec des outils et des ressources qui sont à votre portée. Ceux-ci peuvent servir de démarreurs efficaces et à faible barrière d’entrée dans votre parcours d’analyse des données d’équipe.
La possibilité de se connecter à une API REST externe ouvre la porte à d’autres améliorations. Voici quelques idées sur lesquelles je travaille actuellement :
- Appliquer la même connectivité au tableau de bord de l’équipe en troy.magennis
2. Interfaces similaires pour Google Sheets pour un public de capture plus large
3. Connexion à d’autres sources de données (GitHub, services CI/CD, Trello, etc.)