Les métriques DORA sont à peu près un iceberg, avec les cinq indicateurs dépassant de la surface et de nombreuses recherches cachées sous les vagues. Avec la quantité de travail qui a été investie dans ce programme, tout cela peut sembler assez opaque lorsque vous commencez à travailler avec eux. Essayons de jeter un coup d’œil sous la surface et de voir ce qui se passe là-bas.
Après notre dernier article sur les métriques, nous avons pensé qu’il pourrait être intéressant d’examiner comment les métriques sont utilisées à différents niveaux organisationnels. Si nous commençons par le haut, DORA est l’un des projets les plus populaires aujourd’hui. Ici, nous allons vous dire quelques idées que nous avons eues sur la façon d’utiliser les métriques DORA, mais d’abord, il y a eu quelques questions que nous nous sommes posées sur la recherche et sa méthodologie. Nous aimerions partager ces questions avec vous, en commençant par :
Qu’est-ce que DORA ?
DevOps Research and Assessment est une entreprise fondée en 2015. Depuis lors, ils publient des rapports sur l’état de DevOps, dans lesquels ils analysent les tendances de développement dans l’industrie du logiciel.
En 2018, les personnes derrière cette recherche ont publié un livre (Accélération : la science des logiciels Lean et DevOps : création et mise à l’échelle d’organisations technologiques hautement performantes) où ils ont identifié les indicateurs clés qui ont le plus d’influence sur les performances de l’entreprise :
- Fréquence de déploiement (DF): la fréquence à laquelle votre équipe se déploie en production.
- Délai moyen de modification (MLT): Combien de temps il faut pour qu’un commit arrive en production. Avec DF, ce sont des mesures de vitesse.
- Changer le taux d’échec (CFR): nombre de fois où vos utilisateurs ont été négativement affectés par des modifications, divisé par le nombre de modifications.
- Temps moyen de restauration (MTTR): la rapidité avec laquelle le service a été restauré après chaque panne. Ceci et le CFR sont des mesures de stabilité.
- Fiabilité: La mesure dans laquelle une équipe peut tenir ses promesses et ses affirmations concernant le logiciel qu’elle exploite. C’est le plus récent ajout à la liste.
L’équipe DORA a réalisé un travail vraiment impressionnant. Ils ont fait de solides recherches universitaires et, dans les rapports, ils présentent toujours honnêtement tous les résultats, même lorsque ceux-ci semblent contredire leurs hypothèses. Tout ce travail et le volume de données traitées sont vraiment impressionnants, mais, ironiquement, cela pourrait présenter une limitation. Lorsque l’équipe DORA applique ses mesures, elle les appuie avec des connaissances détaillées ; ceci est absent lorsque quelqu’un d’autre les utilise. Ce n’est pas une situation hypothétique car, à l’heure actuelle, ces métriques sont si populaires que des outils ont été écrits spécifiquement pour les mesurer, comme Fourkeys. Des outils plus généraux, comme GitLab ou Codefresh, peuvent également les suivre hors de la boîte.
Les questions que nous allons poser pourraient être interprétées comme des critiques, mais ce n’est pas l’intention. Nous essayons simplement de montrer que DORA est un outil complexe, qu’il convient, comme on dit, de manier avec précaution.
Les indicateurs clés fonctionnent-ils partout ?
Le principal argument de vente des mesures clés est leur importance universelle. DORA les a trouvés importants pour tous les types d’entreprises, qu’il s’agisse d’une startup de la Silicon Valley, d’une multinationale ou d’un gouvernement. Cela impliquerait que ces mesures pourraient fonctionner comme une norme de l’industrie. D’une certaine manière, c’est ainsi qu’elles sont présentées : les entreprises des enquêtes DORA sont regroupées en clusters (généralement quatre), de faible à élite, et les valeurs du cluster d’élite ressemblent à quelque chose que tout le monde devrait imiter.
Mais, en réalité, tout cela est plus descriptif qu’impératif. La valeur promue, par exemple, le délai moyen pour les changements, est simplement la valeur des entreprises qui ont été regroupées dans le cluster d’élite, et cette valeur peut changer d’année en année. Par exemple, en 2019, c’était moins d’un jour. En 2018 et 2021, moins d’une heure, et en 2022, entre un jour et une semaine. Soit dit en passant, ce dernier est dû au fait qu’il n’y avait pas du tout de cluster «élite» cette année-là, les données semblaient plus pratiques dans trois clusters. Donc, si nous nous arrêtons à ce stade et ne regardons pas plus loin que les indicateurs clés, nous comprenons simplement le message : voici une image de ce à quoi ressemble une équipe DevOps d’élite, soyons plus comme eux, tout le monde.
En fin de compte, nous revenons à la simple vérité que la corrélation n’implique pas la causalité. Si les leaders de l’industrie qui ont adopté DevOps affichent tous ces statistiques, cela signifie-t-il qu’en obtenant ces statistiques, vous deviendrez également un leader ? Le faire sans une bonne compréhension ou sans tenir compte du contexte peut entraîner des efforts inutiles. Combien cela vous coûtera-t-il de faire passer chacune de ces mesures au niveau élite et de les y maintenir indéfiniment ? Quel sera le retour sur cet investissement ? Pour répondre à ces questions, vous devrez creuser plus profondément, et il en va de même pour la question suivante sur notre liste.
Nous savons à quelle vitesse nous allons, mais dans quelle direction ?
Non seulement vous aurez besoin de quelque chose de niveau inférieur pour compléter les métriques DORA, mais vous aurez également besoin de quelque chose de niveau supérieur. Comme nous l’avons déjà dit précédemment, une bonne métrique devrait en quelque sorte être liée au bonheur de l’utilisateur. Le problème est que les métriques DORA ne vous disent rien sur le contexte commercial, que vous répondiez ou non à une demande réelle quelconque. Utiliser uniquement DORA pour définir les OKR brossera un tableau très incomplet des performances de l’entreprise. Vous saurez à quelle vitesse vous roulez, mais vous conduisez peut-être dans la direction opposée à celle où vous devez être, et les mesures DORA ne vous en avertiront pas.
Qu’est-ce que la fiabilité ?
C’est ce que nous nous sommes demandé lorsque nous avons recherché la cinquième métrique DORA. Si vous avez lu les rapports 2021 et 2022, vous saurez que c’est quelque chose qui a été inspiré par l’ingénierie de fiabilité du site (SRE) de Google, mais vous ne saurez toujours pas sur quelles mesures spécifiques il est basé, comment il est calculé exactement ou comment vous pourriez mesurer votre propre fiabilité.
Les rapports ne montrent aucune valeur pour cela, il n’apparaît pas dans les jolis tableaux où ils comparent les clusters, et le Quick Check proposé par DORA ne mentionne aucunement la fiabilité dans ses questions principales. Le dernier rapport sur l’état du DevOps indique que l’investissement dans le SRE n’améliore la fiabilité « qu’une fois qu’un seuil d’adoption a été atteint », mais ne nous dit pas quel est ce seuil. Cela laisse une entreprise dans l’ignorance quant à savoir si elle gagnera quelque chose en investissant dans le SRE.
Cela ne doit pas être considéré comme une critique de SRE – la façon dont il est présenté dans les rapports est opaque, et si vous voulez prendre des décisions significatives dans votre équipe, vous devrez explorer des mesures plus exploitables.
Idée : Vérifiez les métriques DORA les unes par rapport aux autres
La grande chose à propos des métriques clés de DORA est la façon dont elles peuvent servir de vérifications les unes pour les autres ; chacun d’eux pris isolément mentirait par omission. Une équipe de développeurs très prudents qui sont diligents avec leurs tests unitaires et qui sont soutenus par une équipe QA qualifiée pourraient avoir la même fréquence de déploiement et le même délai pour les changements qu’une équipe qui ne fait aucun test.
Évidemment, les produits livrés par ces équipes seraient très différents. Nous avons donc besoin d’une mesure de la mesure dans laquelle l’expérience utilisateur est affectée par le changement. Time to Restore nous dit quelque chose à ce sujet, mais en soi, il est inutile, comme mesurer la distance au lieu de la vitesse. Passer deux heures à réparer une panne survenue une fois par mois ou une fois par jour sont deux choses complètement différentes. Changer le taux d’échec à la rescousse : il nous indique à quelle fréquence les changements se produisent. Un autre problème avec le MTTR : vous pourriez avoir une valeur faible obtenue en réparant chaque catastrophe avec un hack d’urgence. Ou vous pouvez avoir une fréquence de déploiement élevée, ce qui vous permet de déployer des correctifs stables de manière rapide et fiable. C’est un avantage extrêmement important d’un DF élevé : être capable de répondre à des situations sur le terrain de manière non urgente. Encore une fois, les métriques servent de vérifications les unes pour les autres.
De plus, si nous essayons d’évaluer les dommages causés par les pannes, nous devons savoir combien nous coûte chaque minute d’indisponibilité. Le comprendre nécessitera des recherches supplémentaires, mais cela mettra les chiffres dans leur contexte et nous permettra enfin de prendre une décision basée sur les chiffres. Ainsi, pour que les métriques DORA soient utilisées, elles doivent être jugées les unes par rapport aux autres et par rapport à des métriques techniques, produit et marketing supplémentaires.
Idée : Connaître les limites d’applicabilité
Pour aller plus loin, il existe des situations où les métriques DORA n’indiquent pas nécessairement le succès ou l’échec. L’exemple le plus évident ici est que votre fréquence de déploiement dépend non seulement de vos performances internes mais aussi de la situation de votre client. S’ils n’acceptent les modifications qu’une fois par trimestre, vous ne pouvez pas y faire grand-chose.
Le dernier rapport State of DevOps recommande d’utiliser le cloud computing pour améliorer les performances organisationnelles (ce qui inclut la fréquence de déploiement). Cela a du sens, bien sûr, mais les nuages ne sont pas toujours une option, et cela doit être pris en compte lors de l’évaluation de votre DF. Si nous prenons Qameta Software comme exemple, Allure TestOps a une version basée sur le cloud, où la mise à jour est une affaire relativement facile.
Cependant, si vous souhaitez mettre à jour une version sur site, vous devrez travailler avec les administrateurs et cela prendra un certain temps. De plus, certains clients décident simplement de conserver une ancienne version de TestOps par crainte de problèmes de rétrocompatibilité. Wrike propose environ 70 000 tests, qui sont lancés plusieurs fois par jour avec TestOps. Toute interruption de ce processus aura un coût extrêmement élevé, ils ont donc pris la décision de ne pas mettre à jour. Il existe d’autres applications pour lesquelles la fréquence de mise à jour n’est pas non plus une priorité, comme les jeux informatiques hors ligne.
Dans l’ensemble, il existe des situations où la poursuite du statut d’élite mesuré par DORA pourrait faire plus de mal que de bien. Cela ne signifie pas que les mesures elles-mêmes deviennent inutiles, mais simplement qu’elles doivent être utilisées avec précaution.
Idée : Utiliser les métriques DORA comme sonnette d’alarme
Les métriques DORA sont des indicateurs retardés, pas des indicateurs avancés. Cela signifie qu’ils…