DevOoops : des indicateurs clés de performance mal définis
La manière dont nous définissons les indicateurs clés de performance peut faire toute la différence.
Prenons l'exemple d'une équipe d'ingénieurs qualité qui utilise le nombre de tests exécutés par sprint comme mesure de réussite. Que se passe-t-il alors ? Obnubilée par cette statistique, l'équipe a naturellement tendance à ajouter toujours plus de tests, sans même penser à mettre de côté ceux qui sont obsolètes. Il est primordial de considérer que nous pourrions avoir un impact bien plus significatif en réalisant moins de tests, d'autant plus qu'une quantité réduite de tests diminuerait la durée du cycle de test. Ainsi, au lieu de miser sur la simple quantité, nous devons nous concentrer sur la couverture et l'efficacité des tests. Une équipe de release engineering utilise quant à elle le nombre de release par sprint comme mesure de réussite. Évidemment, ce nombre influe sur la vitesse. Seulement, les releases déplacent des données d'un point A à un point B sans évaluer la valeur ajoutée pour l'entreprise. Il est nécessaire de relier le facteur vitesse avec les KPI de l'entreprise (nombre de nouveaux clients, pourcentage d'augmentation du chiffre d'affaires, etc.), afin d'être sûr que les gains de rapidité sont source de profits et n'envoient pas l'entreprise droit dans le mur.
Peter Drucker, conseiller en management, résume sa philosophie par ces mots : "Ce qui ne peut pas être mesuré ne peut pas être amélioré".
Cette phrase est prise très au sérieux par les leaders du DevOps. Pour comprendre leurs objectifs, comment les atteindre et où ils en sont, ils savent qu'il est essentiel de définir des indicateurs clés de performance adaptés aux objectifs généraux de leurs initiatives de transformation DevOps. Les KPI fournissent un flux continu d'informations pertinentes qui aident à établir une feuille de route.
Mesurez-vous ce qu'il faut ?
Pour éviter cette erreur, ou "DevOoops", l’entreprise doit commencer par établir des indicateurs clés de performance qui reflètent ses objectifs, mais qui permettent également d'obtenir une boucle de retours continue. À mesure que le projet avance et que les enjeux se dessinent plus clairement, il est important de mesurer et surveiller ces KPI, mais aussi de les adapter.
Quel serait un objectif approprié pour la couverture des tests ? Toutes les équipes cherchent à améliorer la qualité. Mais de combien ? Soixante-dix pour cent ? Quatre-vingt pour cent ? Cent pour cent ? Il s'agit ici d'un indicateur clé de performance qu'il convient de considérer en fonction des besoins et de l’objectif réel.
Il est possible d’avoir 70 % de couverture sur les tests ou le code, mais si l’entreprise considère uniquement ce nombre comme une mesure qualitative, destinée à tester le plus de code possible, elle pourrait rater son objectif. Si elle couvre 70 % du mauvais code et que les 30 % restants sont des éléments cruciaux, tous ses efforts n’auront finalement rien rapporté en matière de qualité.
En ce qui concerne les objectifs, l'amélioration et la surveillance de la couverture des tests peuvent constituer un indicateur de qualité, mais elles ne mesurent pas nécessairement la véritable qualité du travail. Dans ce cas de figure, l’entreprise a besoin d'un indicateur clé de performance qui mesure le résultat plutôt que l'activité. L’entreprise doit alors examiner les niveaux de gravité 1 et 2 de son taux de défaillance. La couverture de code peut bien monter jusqu'à 90 %, si l’entreprise ne constate pas de baisse des défaillances significative, alors il n'y a pas de réel progrès.
Les entreprises ne mettent pas en place une approche DevOps juste pour le plaisir d'en parler, il est nécessaire d’établir des objectifs précis pour ces initiatives et de s’y tenir. Une fois ces objectifs définis, l’entreprise doit aligner les indicateurs clés de performance et les mesures de réussite. La définition correcte de ces mesures de réussite et de ces indicateurs clés de performance déterminera les priorités.