Les métriques DevOps sont essentielles pour déterminer les processus et les flux de travail d’un projet de développement logiciel. Écrire un code réussi est important, bien sûr, mais il est également essentiel d’analyser les processus impliqués pour maximiser l’efficacité et réduire les pertes.
Cependant, toutes les métriques DevOps ne se valent pas. Leurs résultats peuvent aller de « D’accord, c’est bon à savoir » à des informations précieuses et exploitables qui comptent vraiment. Examinons quelques métriques DevOps qui sont universellement importantes et qui comptent vraiment pour presque toutes les équipes modernes.
Des délais de livraison plus courts démontrent l’efficacité
Le délai de livraison (lead time) est le temps qui s’écoule entre le moment où une équipe de développement dit : « Nous allons implémenter/réparer ‘X’ » et le moment où le travail est réellement terminé. Il s’agit d’une métrique importante car elle démontre l’efficacité du flux de travail de votre équipe.
Comme l’explique Ioannis Moustakis dans un article récent, « Des délais de livraison plus courts montrent qu’une équipe peut s’adapter rapidement aux exigences changeantes et livrer de la valeur rapidement. Des délais de livraison longs indiquent souvent des inefficacités dans le processus de développement ou de test, ralentissant l’ensemble du pipeline de livraison. »
Cela dépend également de la taille et de la portée de votre projet. Si le projet de l’équipe est un logiciel haute performance qui fonctionne selon un modèle SaaS, vous aurez besoin de délais de livraison très rapides pour éviter que les utilisateurs ne migrent vers des logiciels qui se mettent à jour plus fréquemment.
En revanche, imaginons que le projet soit une application mobile qui publie des mises à jour tous les lundis à 16 h. Dans ce cas, la durée réelle est légèrement moins importante, mais la métrique fournit toujours des informations précieuses. Si le nouveau code en question comporte moins de 100 lignes et qu’il faut trois jours pour le tester et l’implémenter, il y a un problème majeur.
Évaluer le taux de défaillance des changements dans votre logiciel
Le taux de défaillance des changements suit le nombre de changements qui doivent être annulés, corrigés en urgence ou, d’une manière ou d’une autre, rétablis dans une version fonctionnelle. C’est l’une des métriques les plus essentielles de DevOps, car elle montre à quel point votre équipe est efficace dans l’accomplissement de sa tâche.
Un taux élevé de défaillance des changements peut détruire une base d’utilisateurs. Selon une étude de Qualitest en 2017, 88 % des répondants ont déclaré qu’ils arrêteraient d’utiliser une application ou un logiciel s’ils rencontraient trop de bugs ou de dysfonctionnements. Pour une petite ou moyenne entreprise, cela pourrait conduire à la faillite.
Comme l’explique Pruthviraj Haral, cofondateur et PDG de DevDynamics : « Des rollbacks fréquents ou des incidents en production endommagent la confiance des clients, surtout si vous proposez des services critiques. Une grande fiabilité peut être un avantage concurrentiel, renforçant votre image de marque comme stable et fiable. »
Le temps moyen de récupération le plus bas possible
Une autre métrique absolument essentielle est le temps moyen de récupération (Mean Time to Recovery, ou MTTR). Cela mesure le temps nécessaire pour résoudre une défaillance du système, un problème de serveur ou un autre problème majeur. Cependant, il y a quelques éléments à prendre en compte avant d’utiliser cette métrique.
Tout d’abord, vous pouvez choisir d’exclure les anomalies et les problèmes mineurs. Par exemple, si une panne de serveur a été causée par une coupure de courant, vous pouvez l’exclure, car il n’y avait pas de réelle réponse à apporter. Votre équipe a simplement attendu le retour de l’alimentation, puis a redémarré le système. Il n’y avait rien d’autre à faire, et inclure ce point de données pourrait fausser la métrique.
Comme l’explique Philippe Heilman : « Réduire le temps moyen de récupération est crucial pour minimiser l’insatisfaction des clients, maintenir la productivité et protéger les revenus. En comprenant et en améliorant à la fois le temps moyen de restauration et le temps moyen de récupération, vous pouvez vous assurer que vos systèmes sont non seulement réparés rapidement, mais également totalement opérationnels et fiables, offrant ainsi une expérience fluide à vos clients. »
Qu’ont en commun ces métriques ?
Si vous êtes familier avec DevOps, vous avez probablement remarqué que ces trois métriques font partie des quatre métriques DORA. La quatrième est la fréquence des déploiements, mais son importance n’est pas universelle. Certains projets plus petits, comme les applications mobiles qui ne publient des mises à jour que quelques fois par mois, ont un calendrier de déploiement défini et n’ont généralement pas besoin de builds nocturnes, rendant ainsi cette métrique pratiquement irrélevante pour ces projets.
Ce sont les trois métriques les plus importantes qui s’appliquent à tout type d’équipe de développement logiciel, car elles mesurent l’efficacité. Comme une grande partie du codage et de la programmation est désormais réalisée par des employés à distance travaillant de chez eux, les entreprises doivent s’assurer que leurs équipes logicielles fonctionnent aussi bien qu’elles ne le faisaient lorsqu’elles étaient en bureau.
Si une équipe obtient systématiquement de mauvais scores sur l’une de ces métriques, cela signifie qu’il y a des erreurs à corriger. Une entreprise qui produit un code 100 % efficace, qui fonctionne à chaque fois avec des sauvegardes et des dispositifs de sécurité en place pour réduire ou éliminer les temps d’arrêt des serveurs aurait de nombreuses raisons de se sentir réussie.
Cependant, si ce code prend une semaine à produire au lieu d’un jour, l’entreprise fonctionne de manière inefficace. Les clients finiront par constater que vos concurrents proposent des mises à jour plus rapides et des options que vous n’avez pas encore mises en place, ce qui peut entraîner une réduction de la base d’utilisateurs et, à terme, une insolvabilité financière.
Ces trois métriques ont été choisies parce qu’elles sont les plus universelles, mais les métriques DevOps qui comptent vraiment pour votre équipe sont celles qui vous affectent directement. Les équipes des entreprises multinationales de plusieurs milliards de dollars auront des exigences différentes de celles d’une entreprise beaucoup plus petite. Mais si votre équipe, quelle que soit sa taille ou la portée de son projet, a de bons résultats sur ces trois métriques, vous êtes beaucoup plus susceptible de réussir.
Aucun commentaire