DORA Metrics : utiliser la technologie pour piloter la valeur du business

Pour qui ?

Avant d’attaquer le sujet concrètement, commençons par définir la cible de ces métriques.

Contre toute attente, elles sont transverses. Moyennant une bonne application, les métriques peuvent être consultées par la DSI , le CTO ou le management top level mais elles sont belles et bien pilotées par les équipes techniques.

‍

Pourquoi ?

Assez simplement ce sont des métriques, des KPI, des nombres qui portent plus ou moins de contexte et permettent de quantifier la performance des équipes techniques (software team). Bien souvent, la littérature retient 4 métriques au total bien qu’il en existe une 5ème qu’on évoquera rapidement mais qu’on exclura par la suite.

‍

• DF (Deployment Frequency)‍

Il s’agit de la fréquence à laquelle du code est déployé en production sur une période de temps. Précisions tout de même que le code doit être déployé avec succès. S’il faut rollback chaque déploiement ça compte pas.

C’est également un indicateur de fréquence à laquelle les ingénieurs délivrent de la valeur aux utilisateurs finaux.

Plus elle est élevée et plus les utilisateurs profitent vite des incréments de code.

A titre indicatif, une valeur moyenne est de 1 déploiement par semaine.

‍

• MLTC (Mean Lead Time for Changes)‍

Il s’agit du temps moyen entre le premier commit et le déploiement en production.

Souvent les développeurs doivent repasser plusieurs fois sur le code produit initialement suite notamment à la re-lecture par d’autre développeurs ou pour apporter des corrections demandées par le product owner.

Dans un autre domaine, cette métrique correspond au temps d’immobilisation (stock).

A titre indicatif, une valeur moyenne est de 1 semaine.

‍

• CFR (Change Failure Rate)

Il s’agit du pourcentage de déploiements en production qui causent un problème.

On le calcule en divisant le nombre d’incident par le nombre de déploiements.

A titre indicatif, une valeur moyenne se situe entre 16 et 30%.

‍

• MTTR (Mean Time To Recovery)

Il s’agit du temps moyen nécessaire pour réparer un problème et remettre le système dans un état stable.

A titre indicatif, une valeur moyenne se situe à moins d’un jour.

‍

• Reliability

Cinquième métrique du panel, souvent oubliée. Elle est plus orienté DevOps/SRE et reprend des objectifs existants plus opérationnels/contractuels (SLA) qui peuvent être atteints voire excédés.

‍

‍

Comment fait-on ?

Il existe plusieurs approches pour mettre en places ces métriques. La plus simple reste de s’appuyer sur un outil qui les intègre déjà, comme LinearB.

‍

Qu’importe le flacon l’outil, pourvu que vous commenciez à mesurer.

‍

Et si cela ne marche pas dans mon cas  ?

“Oui mais moi ma feature est complexe, il me faut plusieurs semaines pour terminer, je vais biaiser la moyenne gneu gneu gneu …”

• Découpe ta feature et utilise des feature flags pour délivrer de façon incrémentale.

‍

"Oui mais c’est long de tout tester à chaque fois gneu gneu gneu …"

• Sois flemmard et écris des tests pour automatiser ton job.

‍

TL;DR

Les métriques DORA sont des indicateurs de la production de valeur produit/business.

Elles sont applicables aux DevOps comme aux développeurs et intéressent toute la software team. Pour être pertinentes, les développeurs doivent être acteurs du pilotage de ces métriques car aucun manager ne pourra les forcer à cela.

Une observation macro est que les DORA poussent naturellement à réduire les incréments de code. En effet, en envoyant moins de code à chaque déploiement, on mitige le risque et les déploiements sont naturellement plus rapide.

Notons aussi que les DORA ne se suffisent pas à elle même, elles appellent à d’autre bonnes pratiques que sont le respect du manifeste agile https://agilemanifesto.org/, l’ajout de tests ou encore les principes LEAN de Toyota.

Enfin, avis aux néophytes avides de tableau Excel, si les DORA permettent de quantifier un problème, une lame de fond, elles ne le qualifie pas pour autant. Le sujet central reste un sujet humain, on parle d’équipes d’homme et de femme qui ont leur code, leur cohésion, leur problématique propre. Piloter uniquement les DORA pour présenter un Excel “tout au vert” serait naïf et pourrait compromettre l’équipe ciblée.

‍

Et Yield Studio là dedans ?

Selon la classification mentionnée en annexe Yield Studio se situe en “high performer” et s’améliore en continu pour atteindre prochainement le grade “elite”. Et vous, vous vous situez où dans ce tableau ? Aujourd'hui les DORA Metrics nous permettent de garantir une réelle qualité auprès de nos clients dans les projets qu'ils nous confient.

‍

Source

Valeurs indicatives pour chaque DORA metric

Source: Google Cloud https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance?hl=en

‍