Bien que les DORA metrics soient couramment utilisées pour mesurer la productivité, il n’est pas toujours facile de les interpréter.
La mesure et l’amélioration de la productivité des développeurs ont longtemps été un défi de taille. Des métriques purement techniques à celles plus orientées business, le choix des métriques reste souvent un sujet préoccupant, surtout qu’il peut finir par des choix totalement obsolètes.
À l’ère de la généralisation des pratiques DevOps, des standards prennent place dans le domaine du développement, et c’est le cas des DORA metrics !
Ces métriques se popularisent et deviennent un refuge pour ceux à la recherche d’une approche de quantification de la productivité. Alors la question devient inévitable : pouvons-nous compter sur les DORA metrics, et comment interpréter et mettre en place ces métriques ?
Qu’est-ce que les DORA metrics ?
Popularisé par le framework SPACE, les DORA (DevOps Research and Assessment) metrics sont un ensemble de métriques clés de performance (Key Performance Indactors – KPI) utilisées pour évaluer et mesurer les pratiques DevOps.
Si les pratiques DevOps sont multiples et méritent à elles seules plus d’un article, ce qu’il faut en retenir c’est avant tout leur capacité à encourager la collaboration entre les développeurs et les équipes opérationnelles. Et c’est ainsi qu’on leur reconnaît une capacité d’amélioration de la vitesse, de la qualité et de la fiabilité des déploiements logiciels.
Pour traduire ces avantages du DevOps, les DORA metrics se concentrent sur quatre dimensions :
- Change Failure Rate
- Deployment Frequency
- Lead Time For Changes
- Time To Restore Service
Une histoire de subtilité et d’interprétation
Bien que les DORA metrics mettent en évidence que les approches simplistes basées sur une seule métrique globale ne suffisent plus, l’interprétation concrète de ces métriques dans les différents contextes reste un sujet de complexité et met en évidence les nuances qui doivent être prises en compte lors de leur utilisation et de leur interprétation.
Ce point m’oblige à m’arrêter afin de vous partager les interprétations que j’ai observées durant ces dernières années pour chacune de ces métriques.
Change Failure Rate :
Le taux d’échec peut être attribué à la fois aux bugs et aux incidents. Par conséquent, il est possible de calculer cette métrique en utilisant l’une ou l’autre de ces définitions, voire en les incluant toutes les deux, c’est-à-dire en prenant en compte à la fois le nombre de bugs et d’incidents.
Cependant, il est important de reconnaître que dans un environnement peu mature en ce qui concerne les processus d’escalade et de déclaration d’incident, la distinction entre ces deux notions peut devenir floue. En d’autres termes, certains incidents peuvent être considérés comme des bugs et vice versa.
Alors le choix de calculer cette métrique sur la notion de bugs versus celle des incidents devient non seulement subtil mais nécessaire à clarifier afin de garantir la fiabilité de la métrique et pouvoir évaluer la réelle maturité des processus.
Deployment Frequency :
La fréquence de déploiement peut englober à la fois les nouvelles fonctionnalités et les correctifs (hot fixes). Tout comme le taux d’échec des changements, cette métrique peut être calculée selon différentes interprétations.
Si l’objectif initial de cette métrique est de suivre la capacité à innover, inclure le nombre de correctifs dans le calcul peut donner une perspective peu claire. En effet, si la fréquence des déploiements reflète principalement une augmentation des correctifs plutôt que des nouvelles fonctionnalités, cela peut indiquer un problème majeur de qualité.
Cependant, l’inclusion du nombre de correctifs peut également démontrer la capacité à résoudre continuellement et de manière proactive les problèmes. Cela met en évidence la capacité de l’équipe à prendre des mesures rapides et à garantir la stabilité et la fiabilité du système.
Lead Time for Changes :
La mesure du délai de mise en œuvre des changements peut englober différentes étapes telles que le temps du cycle (cycle time), le temps de mise en production (release time) et le délai de mise sur le marché (time-to-market – TTM).
Chacune de ces dimensions apporte une perspective différente sur l’efficacité des processus de développement, plus ou moins étendue dans l’organisation.
Le choix de partir, par exemple, sur le TTM peut offrir une vision d’ensemble des délais de mise sur le marché, permettant ainsi de comprendre les éventuels ralentissements dans les processus de production. Cela peut aider à identifier les goulots d’étranglement et à améliorer l’efficacité des opérations.
Cependant, il convient de noter que le TTM peut également être trop large pour cibler des problématiques de productivité précises. En se concentrant uniquement sur cette métrique, il est donc possible de passer à côté d’autres KPIs spécifiques à chaque étape du processus de développement.
Time To Restore Service :
Le temps de résolution peut être mesuré à travers le temps moyen de réparation (Mean Time to Repair) ou le temps moyen de récupération (Mean Time to Recovery). Ces deux notions peuvent prêter à confusion.
Si la première définit une réparation des causes fondamentales ayant produit le problème, la seconde notion s’arrête sur la remise en marche. Cela veut dire une réparation des symptômes et non forcément des causes.
Toute la subtilité réside dans ce point.
Si le Time to Recovery est une traduction unique de la récupération, son efficacité peut ne pas forcément traduire uniquement la réactivité, mais également le nombre de problèmes non traités à la source, et cela peut nous amener à poser la question de l’accumulation de dette technique, des solutions de contournement, etc.
Ces subtilités d’interprétation influencent le calcul et la mise en place des DORA metrics. Bien que ces dernières soient aujourd’hui des standards du marché, leur définition exacte l’est moins.
Cela rend l’exercice complexe et intéressant, car la quête aux chiffres se fait à travers la compréhension du contexte et des besoins.
Relever le défi de compréhension des DORA metrics
Pour une meilleure compréhension de l’environnement, il est souvent intéressant d’examiner les différentes interprétations de ces métriques et de les recalculer pour chaque variation.
Les subtilités peuvent dissimuler des incohérences, mettant ainsi en évidence les difficultés à résoudre. Si l’environnement dispose déjà de ces métriques, cela nécessite de comprendre la logique qui a conduit à faire certains choix et d’être prêt à les remettre en question.
La recherche des métriques dépasse souvent le simple aspect quantitatif, elle est avant tout une réflexion profonde visant à donner du sens à ce qui compte pour votre organisation, en établissant des normes internes qui servent de guide dans une approche mesurable. Il est donc primordial de mener une réflexion approfondie avant de se lancer dans l’action et de généraliser l’utilisation des métriques. Il est également essentiel d’examiner attentivement leur signification et leur pertinence dans un contexte spécifique.
Enfin, cette étape préliminaire de réflexion est d’une importance cruciale, car elle garantit que les métriques sélectionnées sont en adéquation avec les objectifs, permettant de prendre des décisions éclairées et d’engager les équipes vers la bonne direction.
