17 mesures agiles importantes dont votre équipe devrait se soucier

Les métriques ont longtemps été un sujet de débat chez les agilistes.

Malgré le fait que le développement agile est empirique en raison de la livraison continue de logiciels de qualité, les bureaux PMO, les chefs de projet et les clients exigent toujours des rapports d'état détaillés comme ils le feraient pour tout projet basé sur une cascade. Bien que les besoins de l'entreprise soient l'une des raisons de la surveillance, le développement agile lui-même contribue à un niveau d'incertitude que certaines personnes veulent toujours cerner.

Dans un effort pour contrer cette tendance, de nombreux agilistes soutiennent que les mesures ne doivent pas du tout être utilisées et que seule la production de logiciels elle-même doit être considérée comme l'étalon du succès. Les partisans de cette approche soutiennent que les équipes de développement et les chefs de projet joueront instinctivement sur le système en manipulant les user stories et les estimations de manière à produire un semblant de haute efficacité et à masquer les vrais problèmes. Cependant, il y a un adage qui dit que ce qui est mesuré est fait.

La principale raison pour laquelle ce jeu se produit est que les organisations s'appuient trop sur une ou deux métriques au lieu d'avoir une solution de métrique complète. Dans cet article, nous discuterons des mesures éprouvées pour produire les meilleures informations disponibles sur les performances, la qualité, la valeur et même l'agilité de l'équipe. Nous parlerons même de certaines mesures dont vous n'avez peut-être jamais entendu parler, basées sur les dernières recherches et les études de cas les plus innovantes.

A quoi servent les métriques agiles ?

Les métriques agiles sont utilisées pour suivre le statut, la qualité, la productivité, l'efficacité, la valeur et même l'agilité elle-même. Plus important encore, ils sont utilisés pour éclairer les décisions commerciales. Quel que soit le type de projet sur lequel vous travaillez, le reporting sera toujours important pour les parties prenantes externes et internes. Les métriques peuvent avoir un impact sur les décisions à tous les niveaux, de la gestion des produits à la gestion du personnel, et en tant que telles, elles doivent être précises, informatives et impartiales. Avant de plonger dans les métriques, nous devons d'abord établir une base sur laquelle toutes ces mesures sont basées.

Le triangle de fer contre le triangle agile

Dans les approches basées sur des plans, les mesures étaient basées sur l'ancien « triangle de fer » de la portée, du calendrier et du coût. La plupart des mesures appartenaient à l'une de ces trois catégories. Dans le monde agile, ce triangle a été bouleversé. Les projets sont définis en fournissant de la valeur et de la qualité dans certaines contraintes. Le budget ou le coût n'est qu'une de ces contraintes, parmi d'autres, au lieu d'être un objectif principal pour la livraison.

Il est important ici de comprendre la relation entre la valeur et la qualité. Beaucoup de gens ont du mal à définir la valeur. Premièrement, il existe deux types de qualité : intrinsèque et extrinsèque.

• La qualité intrinsèque concerne la perception interne du produit par les équipes de développement, de test et de gestion. Il est généralement illustré par des métriques de défaut, que nous décrivons plus tard.
• La qualité extrinsèque est la qualité du produit telle qu'elle est perçue par l'utilisateur final. Dans quelle mesure le produit répond à leurs besoins et répond aux attentes. Un autre terme pour cette qualité extrinsèque est la valeur.

Il est donc important de comprendre que la qualité telle qu'elle est représentée dans le triangle agile est une qualité intrinsèque ou interne du point de vue du développement, tandis que la valeur dans le triangle est en réalité une forme de qualité extrinsèque. Comprendre cette relation est important pour développer de bonnes mesures agiles.

17 métriques agiles clés à suivre

La liste suivante de dix-sept métriques combine les métriques agiles les plus fréquemment utilisées et consacrées avec des mesures plus récentes basées sur des recherches récentes. La clé à retenir ici est que toute solution de métrique agile doit être complète.

Se fier à un ou deux ne fournira pas une image complète de ce qui se passe. La plus grosse erreur que commettent de nombreux managers est de trop se concentrer sur deux ou trois, ou sur une seule métrique pour l'ensemble de leur projet. Certaines organisations n'utilisent que des graphiques de vélocité ou d'avancement.

Croyez-le ou non, ça arrive. Une bonne solution de métrique doit couvrir les trois points du triangle agile. Ces 17 vous donneront les outils pour faire exactement cela et bien plus encore.

Temps bloqué

Le temps bloqué est défini comme la durée pendant laquelle une user story particulière - ou parfois une tâche - est bloquée. La résolution des bloqueurs est essentielle pour faciliter le flux de travail dans un environnement agile, et cette métrique peut aider à mesurer le temps qu'ils prennent pour les résoudre. Les bloqueurs doivent être résolus rapidement.

L'augmentation du temps bloqué peut signifier qu'une user story n'a pas été correctement décomposée ou qu'il existe une dépendance à l'égard d'une ressource externe qui n'était pas planifiée. Le temps bloqué peut être réduit grâce à une décomposition, une hiérarchisation et une planification des sprints plus soigneuses.

Dynamique commerciale

Bon nombre des mesures discutées ici existent depuis un certain temps. La plupart se concentrent sur le projet, l'équipe ou le niveau WIP (travail en cours). Cependant, à mesure que la technologie est plus intégrée dans notre vie quotidienne et que les marchés de ces produits deviennent hyper-accélérés, les organisations recherchent des mesures plus sophistiquées capables d'identifier les tendances du marché, d'évaluer l'amélioration des processus, de prévoir la concurrence et, essentiellement, de mesurer l'agilité. La dynamique commerciale en fait partie. La dynamique dans ce contexte peut être exprimée comme le nombre total de points d'histoire pour une version multiplié par sa chronologie.

À mesure qu'une organisation devient plus agile, elle prend de l'ampleur à chaque version. Les temps de cycle ont tendance à se raccourcir et les attentes concernant la livraison augmentent. La dynamique commerciale peut être utilisée pour le timing du marché ou comme marqueur de la santé d'une gamme de produits ou d'un programme particulier. Si l'élan commence à ralentir, c'est un indicateur pour la direction qu'un marché particulier commence à jouer et qu'une nouvelle gamme de produits doit être développée. Les organisations agiles doivent continuellement rechercher de nouveaux marchés pour rester compétitives.

Couverture de code

La couverture de code est une mesure de la quantité de code réellement exécutée pendant les tests. Ceci est généralement instrumenté et calculé dans le cadre d'une stratégie de test automatisée. La métrique doit fournir le pourcentage global de code exécuté au cours de chaque phase de test (unité, système, etc.) ainsi qu'un total de toutes les phases.

La couverture du code ne doit pas être utilisée à mauvais escient comme marqueur de la qualité des tests d'un produit. L'objectif de cette métrique est plutôt de faciliter l'automatisation des tests et de surveiller la livraison continue. Les mesures d'assurance qualité doivent inclure une variété de métriques, dont les moindres ne sont pas les occurrences de défauts discutées plus loin.

Carte de contrôle

Parfois appelée carte de comportement de processus ou carte de Shewhart, une carte de contrôle surveille les performances d'un processus pour déterminer s'il est sous contrôle ou hors de contrôle, en fonction des limites de contrôle supérieures, inférieures et moyennes qui ont été définies.

Ces limites sont calculées en estimant l'écart type des données de l'échantillon, en multipliant cet écart par trois, puis en l'ajoutant à la moyenne pour créer la limite supérieure et en le soustrayant de la moyenne pour créer la limite inférieure. L'axe Y du graphique est le nombre d'occurrences ou de problèmes dans un échantillon particulier tandis que l'axe X énumère chaque échantillon. Les cartes de contrôle sont nées dans la fabrication comme une forme de contrôle de la qualité et existent depuis près de 100 ans.

Populaires auprès des disciples de Six Sigma, les cartes de contrôle peuvent mesurer l'échec ou le succès du contrôle qualité ou d'autres processus de fabrication. Bien qu'elles ne soient pas popularisées dans le monde agile, les cartes de contrôle pourraient être utilisées pour mesurer les défauts trouvés par itération ou par version afin d'identifier les problèmes de test d'assurance qualité, ou pour évaluer les temps de cycle sur une série de versions afin de s'assurer qu'ils se situent dans des niveaux acceptables.

Diagramme de flux cumulé

Un diagramme de flux cumulatif illustre la quantité de travail, segmentée par type, allouée à une équipe au fil du temps. Son but est de surveiller la qualité du travail dans tout le système. Dans ce diagramme, le travail est divisé en différents types, par exemple : à faire, en cours et terminé. Il pourrait également être divisé en exigences, développement, tests, etc. Quelle que soit sa segmentation, le diagramme de flux cumulé affiche une ligne pour chaque type de travail, le nombre d'éléments de travail sur l'axe Y et l'axe X étant une fonction du temps.

Un bon écoulement est illustré par toutes ces lignes fonctionnant en parallèle. Si l'une des lignes connaît une forte reprise ou en croise une autre, cela pourrait indiquer un goulot d'étranglement. Atteindre un bon flux est le concept central du kanban. Le diagramme de flux cumulatif aide à identifier les goulots d'étranglement pour faciliter le flux continu et garantir que WIP ne devient pas hors de contrôle à un point quelconque du système.

Temps d'un cycle

Le temps de cycle peut être défini comme le temps nécessaire pour produire une version logicielle, du concept à l'achèvement. Avec le délai et la vélocité, le temps de cycle est un très bon indicateur de haut niveau de la santé agile et du succès de la transformation agile. Au fur et à mesure qu'une organisation progresse dans son parcours agile, les temps de cycle devraient progressivement diminuer, généralement à six mois ou beaucoup moins. Les augmentations du temps de cycle, en particulier lorsqu'elles sont observées de manière constante sur une ou deux versions, devraient être une source de préoccupation et d'examen.

Burndown d'épopée et de sortie

Les graphiques de burndown d'épopée et de release sont similaires au burndown de sprint toujours populaire décrit ci-dessous. Un graphique burndown illustre la quantité de travail restant pour une période donnée ou, dans cet exemple, pour une certaine épopée. Dans le développement agile, une epic est une user story plus large composée de user stories plus petites ou de morceaux de travail.

Au fur et à mesure que le travail est terminé, le nombre d'histoires d'utilisateurs dans l'épopée est progressivement réduit jusqu'à ce qu'il atteigne zéro. Cela peut être utile dans les cas où des jalons doivent être atteints pour répondre aux exigences contractuelles et facturer le client. De même, un burndown de version peut suivre la progression du travail validé pour une version spécifique. Cela peut être utilisé pour garantir une livraison à temps ou pour identifier un besoin de modifier une date limite plus tôt.

Échec des déploiements

Un déploiement ayant échoué est un déploiement qui entraîne l'un des éléments suivants :

• Service affectant la panne
• Ne répond pas aux attentes des clients, entraînant souvent le rejet de la version.
• Affecte gravement la convivialité, le fonctionnement ou l'expérience utilisateur du produit.
• Entraîne un retour à la version précédente.

Évidemment, le taux de déploiement échoué, affiché en pourcentage du nombre total de déploiements, doit être réduit au minimum. Tout pic de cette métrique devrait être préoccupant. Les taux de changement et les occurrences de défauts doivent être examinés pour isoler les causes profondes.

Délai de mise en œuvre

Le délai d'exécution mesure le temps qu'il faut pour terminer une tâche, à partir du moment où elle est créée jusqu'au point où elle est terminée. En bref, il identifie le temps qu'il faut pour faire avancer les choses. Populaire auprès des praticiens kanban, cette métrique peut aider à identifier les gains d'efficacité pour déplacer les tâches plus rapidement dans le système. Il peut également être utilisé comme métrique de haut niveau pour déterminer le bon fonctionnement de la livraison continue. Le délai d'approvisionnement, ainsi que le temps de cycle et la vélocité, peuvent être utilisés ensemble pour fournir une vue globale des performances de livraison.

Net Promoter Score (NPS)

Un score de promoteur net est destiné à aider à évaluer la satisfaction des clients. Il est généralement calculé sur la base de données obtenues via une enquête. L'objectif est de savoir combien de clients recommanderaient votre produit. Le pourcentage de répondants qui votent « non » est soustrait des votants « oui » pour créer le score.

En plus d'évaluer la satisfaction des clients, le score net du promoteur peut aider à identifier les clients les plus disposés à collaborer sur des produits ou des technologies innovants pour les versions futures. Ces clients peuvent devenir un avantage concurrentiel car leurs commentaires et leur soutien peuvent aider les entreprises à commercialiser de nouveaux produits avant la concurrence.

Intelligence de qualité

Au début de l'article, nous avons discuté du triangle agile et du rôle qu'y joue la qualité. L'intelligence de la qualité peut prendre de nombreuses formes, mais elle est généralement composée d'une variété de mesures de suivi des défauts. Les défauts peuvent être surveillés en fonction de l'endroit et du moment où ils se produisent, de leur fréquence et de leur gravité.

L'un des plus populaires est le taux d'échappement des défauts, qui est le rapport des défauts trouvés par le client au nombre total de défauts découverts dans une version. Bien qu'un nombre élevé de défauts soit préoccupant, quelle que soit la manière dont ils sont détectés, il est toujours préférable de les détecter avant que le client ne le fasse.

Burndown de sprint

Les graphiques de burndown de sprint fournissent une mesure quotidienne du travail qui est terminé et du travail qui reste à faire dans un sprint donné. Il compare la quantité de travail achevée aux estimations initiales. En raison de la nature empirique du développement agile, la valeur du burndown chart est assez limitée.

Malgré sa popularité, de nombreux coachs agiles ne l'utilisent plus autant qu'avant. Il peut servir de bon guide ou de point de statut pour savoir où les équipes de développement se situent par rapport à leurs engagements, mais il doit être utilisé en tandem avec d'autres mesures pour obtenir une vue d'ensemble de ce qui se passe.

Débit

La quantité de produit (nombre d'éléments de travail) livrée au client par unité de temps particulière est appelée débit. Cela pourrait être mesuré mensuellement, trimestriellement, par version, itération, etc. La valeur de cette métrique est qu'elle peut être utilisée pour déterminer la quantité de logiciels pouvant être livrés pour une période de temps spécifique. Il peut également être utilisé pour suivre la cohérence de la livraison du point de vue de l'équipe et de l'organisation.

L'analyse empirique des données historiques peut être utilisée pour prévoir les performances de livraison. Plus il y a de données historiques disponibles, plus les projections sont susceptibles d'être précises. Plus important encore, cette métrique peut également être utilisée pour prévoir les revenus, étant donné que la valeur de la fonctionnalité fournie est bien comprise en termes financiers. Pour que cette mesure fonctionne, la définition de « terminé » doit être bien définie. Seuls les logiciels livrés au client répondent à cette exigence.

Valeur livrée

Au début de l'article, nous avons expliqué comment la valeur consiste en une qualité extrinsèque ou la perception du produit par l'utilisateur final. Quel est l'impact du produit sur l'activité du client ? Les bonnes métriques agiles sont basées sur les résultats, et dans le monde des affaires, cela se traduit généralement en dollars et en cents. Tout comme nous attribuons des points d'histoire à chaque histoire d'utilisateur pour estimer le travail nécessaire, nous pouvons également ajouter des points de valeur en tant que mesure relative pour indiquer ce que l'utilisateur final obtient lorsque le travail est terminé.

Une façon de le faire est d'utiliser un graphique de combustion qui illustre le nombre de points de valeur accumulés à mesure que chaque histoire est terminée. Des points de valeur peuvent être attribués à chaque histoire ou fonctionnalité en fonction de la perception du client lors de la création des critères d'acceptation. Le revenu attendu (ou l'argent économisé) pour le client sur le projet peut être divisé par le nombre total de points de valeur dans la version.

Par exemple, s'il y a 200 points de valeur dans un projet et que le client devrait gagner 1 million de dollars de revenus, alors chaque point de valeur vaut 5 000 $. La somme totale de chaque histoire et leur valeur cumulée peuvent être illustrées dans le graphique de combustion. Bien que l'impact réel du produit puisse ne pas être apparent avant sa sortie, cette méthode peut fournir des informations financières convaincantes à la fois à la direction et aux clients.

Rapidité

La vélocité est probablement la première métrique dont la plupart d'entre nous entendons parler après avoir été initié au développement agile. Bien que sans doute la métrique agile la plus populaire, elle est aussi la plus mal utilisée. Les équipes de sprint sont réputées pour leur vitesse de jeu, car elles sont si fortement utilisées pour rendre compte de leurs performances. La vélocité est définie comme la quantité de logiciels produits à chaque itération, ou sprint. Cette quantité est généralement exprimée en points d'histoire et le logiciel produit doit être une tranche de code fonctionnelle prête à la production.

Les équipes jouent souvent la vitesse en manipulant la taille et l'estimation des user stories, ou en décomposant le travail horizontalement, plutôt que verticalement, en créant des histoires pour les modifications de base de données, le travail frontal, le middleware, etc. pour éliminer les dépendances vis-à-vis des autres et obtenir le mérite d'avoir terminé le travail. Le problème avec cette approche est que ces types de récits d'utilisateurs sont en réalité des tâches, et bien que les équipes obtiennent un crédit, la valeur commerciale pour le client n'a pas été fournie.

La vitesse de jeu peut être évitée en utilisant une foule d'autres mesures comme contrôle et équilibre les unes par rapport aux autres. Trop souvent, les organisations s'appuient uniquement sur la vélocité ou sur un très petit ensemble de mesures au lieu d'une suite plus large de mesures pour former une solution PPM, de gestion de programme et de projet.

Tourbillon (agile)

Une question avec laquelle de nombreux agilistes et chefs de projet se débattent est "à quel point sommes-nous agiles?" En fait, la recherche de la réponse à la mesure de l'agilité elle-même a été le Saint Graal des agilistes du monde entier. La vorticité agile est une nouvelle mesure qui fait exactement cela. Sur la base de plus de 10 ans de recherche d'études de cas, la vorticité agile a été développée grâce à une méthode qualitative sophistiquée appelée théorie ancrée.

À l'aide d'un ensemble complet de mesures, l'agilité du marché et du processus organisationnel peut être mesurée l'une par rapport à l'autre pour déterminer leur vorticité, ou le point auquel ils convergent. Zéro vorticité signifie que l'agilité de l'organisation correspond au marché. Une vorticité élevée signifie que le marché évolue beaucoup plus rapidement que votre organisation ou vos équipes, et qu'il y a donc beaucoup de travail à faire. L'infographie ci-dessous illustre cette relation à l'aide d'une expérience de pensée en tourbillon pour illustrer les marchés hyper-accélérés d'aujourd'hui.

Âge de l'élément de travail

Un élément de travail peut être défini comme un package de travail, une fonctionnalité utilisable ou, comme dans la plupart des contextes agiles, une user story. L'horloge commence à compter sur l'âge d'un élément de travail dès qu'il est conçu pour la première fois. Le suivi de l'âge des éléments de travail, qu'ils soient en cours ou en attente, peut aider à identifier les problèmes liés aux exigences.

Si un élément de travail semble vieillir par rapport à son parent parce qu'il est repoussé d'un sprint à l'autre, il peut y avoir un problème de décomposition. Peut-être doit-il être redéfini ou mieux compris ? Les éléments de travail qui restent dans le backlog pendant de longues périodes peuvent devoir être éliminés ou redéfinis.

La préparation continue du backlog est essentielle à la planification et à la priorisation des sprints. Un nombre croissant d'exigences vieillissantes dans le backlog pourrait signifier des problèmes avec la façon dont les exigences sont développées et décomposées. Une mauvaise gestion des exigences est l'une des principales causes d'échec des transformations agiles.

Des exigences mal écrites peuvent rendre la hiérarchisation et l'estimation extrêmement difficiles, entraînant une dette technique incontrôlable, une faible utilisation des fonctionnalités et des pertes financières. Développer des exigences bien comprises, hiérarchisées et de grande valeur est une forme d'art et est mal comprise, même par les meilleurs agilistes. En effet, c'est sans doute l'un des plus grands obstacles au succès de la transformation agile.

Conclusion

Dans cet article, nous avons établi les bases des métriques agiles, la nécessité d'une solution complète et 17 recommandations pour en créer une. Que vous utilisiez toutes les mesures décrites ou seulement un sous-ensemble, il est important que toute solution prenne en compte l'audience des données. Certaines mesures, telles que la vélocité, sont mieux conservées au sein des équipes Scrum. D'autres mesures telles que la vorticité agile et la dynamique commerciale sont conçues respectivement pour la direction ou la gestion des produits.

Assurez-vous toujours de bien comprendre et de communiquer avec précision ce que disent les métriques, et de suivre où mènent les données. Une façon de générer et de prendre en charge de bonnes métriques consiste à utiliser un cadre agile robuste.