Cinq meilleurs KPI d’ingénierie logicielle, et comment ils sont trichés

Par Bill Harding,Programmeur/CEO
Publié le 31 mars 2020.Dernière mise à jour le 17 avril 2020.

Lorsque les gens parlent des KPI d’ingénierie, on entend souvent deux truismes contradictoires :

Ce qui est mesuré s’améliore.-Peter Drucker

Et

Lorsqu’une mesure devient un objectif, elle cesse d’être une bonne mesure.-Peter Drucker

.Loi de Goodhart

Ces deux affirmations décrivent en partie les KPI d’ingénierie, mais prises ensemble, elles impliquent qu’il est simpossible d’utiliser la mesure pour s’améliorer. Comment un gestionnaire axé sur les données peut-il combler ce fossé ?

La mauvaise nouvelle est qu’il faut un certain engagement à l’apprentissage, en particulier pour ceux qui viennent de rôles distants (c’est-à-dire non techniques).La bonne nouvelle est que des mesures soigneusement choisies peuvent continuer à fonctionner et continuent à le faire malgré le fait de « devenir une cible ». La bonne nouvelle, c’est que des indicateurs soigneusement choisis peuvent continuer à fonctionner même s’ils deviennent une cible. En fait, pour de nombreux indicateurs que nous recommandons, plus un employé « joue le jeu », plus les intérêts à long terme de l’entreprise sont servis. L’objectif final est d’obtenir des indicateurs qui continuent à fonctionner correctement tout en étant « manipulés ». Il existe cinq métriques qui répondent à cette barre.

Public cible : Manager soucieux de l’action

Tout manager qui a essayé d’arracher plus de tickets complétés à son équipe d’ingénieurs connaît la lutte.Ils veulent prendre des actions justes, soutenues par des données, qui améliorent leur vélocité. Ils savent que prendre des décisions basées sur des instincts est coûteux et non évolutif. Pourtant, quand ils regardent leur liste de tâches, elle est remplie de tâches qui semblent plus urgentes que « améliorer la mesure ». Dans la pratique, l’adoption de la mesure se produit souvent après un échec catastrophique, comme un build de version bogué ou le fait de remarquer qu’un développeur n’a pas fermé de tickets depuis un mois.

Même lorsqu’il est clair que la mesure doit avoir lieu, il est ambigu de savoir par où commencer. Vous pouvez taper sur Google  » engineering KPIs « , cliquer sur toute la première page de résultats, et rester dans l’incertitude quant aux prochaines étapes à suivre. Prenons l’exemple de la mesure souvent décriée de la « vélocité de l’équipe ». Presque tous les résultats Google recommandent de mesurer la « vélocité de l’équipe », mais personne ne veut dire si elle est mesurée en… tickets fermés ? Lignes de code ? En points d’histoire ? Quoi qu’il en soit, les managers n’ont pas le temps de le découvrir. Ils ont besoin de passer de cette montagne de théorie de 15 000 pieds à quelque chose qu’ils peuvent comprendre, à laquelle ils peuvent faire confiance et dont ils peuvent bénéficier… de préférence immédiatement.

La prémisse organisatrice de cet article est que vous êtes un manager qui veut comprendre la software engineeringmetrics juste assez bien pour rendre votre équipe plus efficace. Être un gestionnaire signifie que vous êtes trop occupé pour apprendre la théorie, sauf lorsqu’elle est directement liée à la façon dont vous pouvez bénéficier de cette théorie.

Les métriques doivent être pratiques pour que les entreprises réelles puissent les essayer

Avant d’écrire cet article, nous avons digéré les métriques proposées par les 20 premiers résultats de Google dans le domaine des métriques logicielles. Comme vous pouvez l’imaginer, chaque source avait ses propres théories sur les métriques les plus importantes.Leurs articles regroupaient souvent les métriques en groupes tels que les « métriques de processus » et les « métriques de projet ». Nous suivrons leur exemple pour regrouper les métriques, mais nos groupes seront « métriques de qualité » et « tout le reste ».

Voici ce que l’on peut qualifier de métrique de qualité :

  • Valeur commerciale.Est-il possible de tracer une ligne droite à partir de métrique => valeur commerciale créée ?
  • Mesurable.Peut-on définir un nombre spécifique et ses unités de mesure (par ex, points, pourcentage), afin qu’il puisse être suivi dans le temps et corrélé avec des événements et des expériences ?
  • Actionnable.Peut-il régulièrement informer une action qui conduit à des résultats positifs ? De préférence avec un minimum de faux positifs ?
  • Disponible/convenable.Une équipe moyenne de génie logiciel peut-elle avoir accès à cette métrique sans modifier ses processus de développement existants ?
  • Populaire.A-t-elle suffisamment d’adeptes pour être bien documentée et crédible ?
  • L’inclusion dans la catégorie des « mesures de qualité » requiert les cinq critères ci-dessus, ainsi qu’une réponse satisfaisante à la question suivante : si nous faisons confiance à cette mesure et que les développeurs l’optimisent, que se passe-t-il ensuite ? Au cours des années passées à construire et à itérer notre propre mesure de développement (« Line Impact »), nous avons appris que les sous-produits toxiques sont une conséquence attendue de la mesure, à moins que la mesure ne soit précisément alignée sur la valeur commerciale à long terme.A titre d’exemple, nous montrerons plus tard comment les développeurs qui essaient de jouer la métrique « Lead Time » causent une transparence réduite pour la direction.

    KPIs d’ingénierie de qualité

    Voici cinq métriques logicielles qui cochent toutes les cases pour aider les Managers à gérer une équipe plus efficace.

    🏦 OKR-driven

    Exemple de modèle OKR

    Un des nombreux exemples de modèles OKR disponibles via Weekdone à Okrexamples.com

    Toute liste qui se concentre sur la maximisation de la valeur commerciale devrait commencer ici. Des entreprises de premier plan comme Google utilisent les OKR comme un axe principal sur lequel évaluer les ingénieurs seniors. L’inconvénient des mesures basées sur les OKR est qu’elles sont, par définition, spécifiques aux particularités de l’entreprise. Il est donc impossible de généraliser une formule permettant de les capturer, ou de généraliser le chemin par lequel ils seront joués.

    Comment le jouer ? Le risque que les OKR soient joués est faible car ils sont généralement centrés sur l’entreprise. Le principal danger des mesures axées sur les OKR est que, comme elles sont généralement formulées de manière ponctuelle (ou périodique), elles sont peut-être moins fiables que les mesures qui ont été passées au crible pendant des années. Il y a toujours des cas de figure possibles : par exemple, fixer un OKR à « introduire moins de 10 bogues par mois » peut être détourné en ne lançant aucune nouvelle fonctionnalité. En supposant que les deux parties agissent de bonne foi, les jeux d’OKR devraient en pratique être rares.

    Comment l’obtenir ? Via les tableaux de bord de mesure existants, ou en travaillant avec des entreprises commeWeekdonequi aident à fournir une inspiration OKR.

    📐Line Impact

    Exemple de KPI d'ingénierie Line Impact : métrique fiable du code source

    10 repos représentés graphiquement par leur Line Impact, une métrique qui quantifie le rythme auquel le code source évolue,image gracieusement fournie par GitClear

    Line Impact est une métrique conçue pour mesurer la quantité d’énergie cognitive déployée dans le développement de logiciels.Cette vidéo offre une explication illustrée de la façon dont cela est possible. En bref, l’impact de ligne annule toute l’activité interstitielle ( » churn « ) qui se produit lorsqu’une fonctionnalité est développée, laissant une incarnation concentrée du travail qui a eu lieu. L’impact de ligne est conservé à travers les langages, de sorte qu’il faut une quantité constante de temps pour générer l’impact de ligne si le développeur écritJava, Python, Javascript, ou tout autre langage de programmation majeur (30 + pris en charge).

    En termes de valeur commerciale, l’impact de ligne est parallèle à Story Points : il illustre comment le coût d’une tâche fluctue en fonction du développeur à qui il est attribué. A partir de là, un manager engagé peut utiliser le rapport Domain Experts pour faire correspondre les Jiras aux experts en la matière, ce qui peut accélérer considérablement la vélocité du produit.

    Comment la jouer ? Toute métrique qui revendique les « lignes de code » (LoC) comme source de données (comme le fait Line Impact) mérite d’être abordée avec prudence. C’est la raison pour laquelle GitClear a conçu les meilleurs outils de revue de code du marché : les responsables et les développeurs peuvent vérifier comment l’impact de ligne est distribué par commande et par fichier. La transparence est un antidote puissant pour combattre le jeu.

    Une protection supplémentaire est fournie sous la forme de notifications qui se déclenchent lorsqu’un développeur contribue à un travail à une vitesse inhabituelle. Ces mesures, ainsi que d’autres, ont rendu la manipulation de Line Impact suffisamment difficile pour que GitClear n’ait pas encore reçu de client signalant que Line Impact a été manipulé avec succès par son équipe.Cela dit, il serait malhonnête de prétendre que la mesure est en quelque sorte imperméable à la manipulation, alors voici une liste de chemins connus par lesquels accumuler un impact de ligne rapide.L’essentiel est que si un développeur écrit des tests, supprime le vieux code et ajoute de la documentation, il gagnera une part importante de l’impact de ligne.

    Comment l’obtenir ? Inscrivez-vous pour un essai gratuit de 15 jours. Si vous aimez, les prix commencent à 9 $ par développeur actif.Voir une brève vidéo explicative sur Line Impact ici.Version on prem disponible.

    🎲 Story Points

    ingénierie KPIs : Rapport de burndown Jira

    Rapport de « burndown de version » basé sur les Story Points,disponible via Jira

    Les Story Points pourraient prétendre être le plus « classique » des KPI d’ingénierie. Il existe plusieurs façons de calculer les Story Points. Toutes les formes ramènent à une estimation du temps prévu par le développeur pour accomplir une certaine tâche. Les managers peuvent utiliser les Story Points pour calculer les coûts impliqués par une tâche, par exemple, si un développeur gagne 10k$/mois, le ticket est estimé à 10 Story Points = la moitié d’un mois, alors le coût est de 10 000$ * 0,5 = 5 000$.L’utilisation d’une certaine version de ce calcul aide à prioriser les tâches basées sur celles qui donnent le ratio le plus élevé de Valeur projetée/Coût d’implémentation projeté.

    Comment le jouer ? La plus grande attention ici appartient à la façon dont les Story Points sont calculés. La façon la plus simple de « jouer » les Story Points est pour l’équipe de développement de biaiser l’échelle de notation, généralement en surestimant la difficulté. Une option pour remédier à ce problème est de permettre aux tâches d’être sélectionnées sur un « marché des tâches », où les tâches surévaluées peuvent être réparties équitablement entre les développeurs pour maintenir un calibrage relatif. Une autre façon de résoudre ce problème est de recalibrer régulièrement la constante utilisée pour traduire les Story Points en « jours développeurs ». Notez que puisque la mise en œuvre des Story Points diffère souvent par équipe, il n’est pas conseillé de les utiliser pour comparer les performances inter-équipes.

    Comment l’obtenir ? La plupart des Issue Tracker de ce côté de GitHub permettent de spécifier des Story Points. En termes de visualisation, Jirapropose un « rapport de vélocité next-gen « dédié à l’objectif de montrer les Story Points complétés au fil du temps.Ils offrent également un « rapport de burndown de libération » qui utilise les Story Points pour estimer comment l’équipe se rapproche de ses objectifs pour le sprint. GitClear offre également des graphiques rudimentaires (pour le moment) qui illustrent les Story Pointscomplétés au fil du temps.

    🐞 Bug Rate / Escaped Defects

    Cette métrique est définie de différentes manières par différentes sources, mais elles obtiennent toutes la même question essentielle:combien de bugs sortent dans le monde, et comment bien répondons-nous à eux ?Stackify le relate en termes numériques spécifiques :

    Votre taux d’échappement aux défauts est exprimé en pourcentage en fonction du nombre de défauts que vous trouvez avant qu’ils n’arrivent en production ou du nombre de défauts qui arrivent en production, selon votre préférence. Chaque projet logiciel et chaque équipe seront différents, mais nous suggérons de s’efforcer de trouver 90% de tous les défauts avant qu’ils n’arrivent en production.

    La définition de Stackify part du principe que l’on va désigner un champ dans son issue trackerto capturer à quelle phase de développement le bogue s’est produit. Pour les équipes qui n’ont pas le temps de mettre en place et de suivre les phases de développement, une définition de substitution peut être :

    À quelle fréquence le code rédigé dans une nouvelle fonctionnalité devient-il du code modifié au cours de la résolution d’un bug ?

    Une réponse liée aux données à cette question est fournie aux utilisateurs de GitClear, mais elle est difficile à calculer manuellement (si vous n’êtes pas un utilisateur de GitClear).Une mesure de repli du taux de bogues disponible et garantie peut être « quel est le rapport entre les bogues créés et les bogues résolus » ?

    Comment la jouer ? Cette métrique est difficile à jouer. Un développeur peut prendre plus de petits tickets, mais chaque ticket introduit un risque incrémental de bugs s’il n’est pas prudent. Ce risque d’utiliser le taux de bug est qu’il a besoin d’un contrepoids pour le « progrès » comme les points d’histoire ou l’impact de ligne, sinon un développeur pourrait s’attarder sur un seul problème pour le sprint entier, assurant un taux de bug de 0%.

    Comment l’obtenir ? Si votre équipe a la bande passante pour étiqueter les problèmes par la phase de développement à laquelle ils se sont produits, alors les défauts échappés peuvent être calculés manuellement à travers n’importe quel traqueur de problèmes. GitClear est une autre option disponiblepour calculer le pourcentage de fonctionnalités qui deviennent des bogues.

    ✅ Taux d’achèvement des demandes de tirage

    Exemple de KPI d'ingénierie Demandes de tirage : statistiques sur GitClear

    Un échantillon des statistiques de demandes de tirage fournies par GitClear

    Quel pourcentage de demandes de tirage ont été fermées dans la semaine suivant leur ouverture ? Cela fait remonter plusieurs questions plus granulaires, comme  » l’équipe s’engage-t-elle à répondre rapidement aux nouvelles pull requests « ,  » est-elle capable de coopérer  » et  » les développeurs ont-ils peaufiné leur code avant de le soumettre à la fusion ? « 

    Comment le jouer ? Acquérir le test  » Pull request completion rate  » signifie toujours fermer les PR en une semaine. C’est relativement difficile à jouer, mais il doit être contrebalancé par une force propulsive telle que les points d’histoire ou l’impact de ligne, sinon toutes les incitations de l’équipe seront de polir le travail plutôt que de l’expédier (ou de le soumettre à l’examen des PR).

    Comment l’obtenir ?Tous les fournisseurs d’Engineering Insight de « marque » (GitClear, Pluralsight, Code Climate, Pinpoint) offrent des statistiques qui illustrent l’efficacité du processus de demande de pull d’une équipe.Nous aidons à comparer les fournisseurs ici.

    Mentions honorables

    Sous les métriques de « niveau supérieur », nous trouvons un niveau interstitiel. Il s’agit de métriques qui possèdent des caractéristiques souhaitables à côté de lacunes importantes. Elles peuvent encore apporter de la valeur, tant qu’un gestionnaire en sait assez pour tenir compte de leurs limites.

    Temps d’avance/Temps de cycle

    Graphe du temps d’avance tel que visualisé via Azure Devops

    Bien qu’il soit répertorié (deux fois !) dans la liste des 5 principales mesures dePluralsight,le temps de cycle est une bonne idée qui est très susceptible d’être jouée.

    Le « Lead Time » est le plus souvent défini comme « Quel est l’intervalle entre le moment où une tâche est déposée dans l’issue trackeret le moment où elle est livrée au client ? » Son cousin, le « Cycle Time », est un sous-ensemble du Lead Time, défini comme « le temps entre le moment où l’équipe produit l’a sorti de la file d’attente et le moment où il a atteint la production. »

    Comment le jouer ? Les performances du Lead Time dépendent dans une certaine mesure du mécanisme par lequel les Jiras sont classés, ce qui signifie que son applicabilité à travers les équipes est faible. Le temps de cycle dépend des conventions par lesquelles le committer choisit de faire son premier commit. Ainsi, cette mesure est facile à manipuler si un développeur sauvegarde ses commits localement et les publie en une seule fois juste avant de soumettre le PR. Cet échec est ce qui relègue le temps de cycle dans la section « Mentions honorables ». Ce n’est pas non plus l’idéal : en incitant un développeur à sauvegarder ses commits sans les pousser, il est impossible pour les coéquipiers d’intervenir pendant que le travail est en cours.Cet effet secondaire réduit la transparence entre un gestionnaire et ses développeurs.

    Comment l’obtenir ? Azure Devops Services fournit le graphique présenté ci-dessus.Jira en propose également une version.Toutes les principales offres d’Engineering Insight (GitClear, Pluralsight, Code Climate Velocity, Pinpoint) mettent en œuvre une certaine version du calcul du délai d’exécution.

    Couverture des tests

    Essayer de capturer une certaine mesure de la couverture des tests est un objectif raisonnable à envisager de poursuivre. Cependant, il ne fait pas tout à fait la coupe comme une métrique Top Tier pour deux raisons:

  1. C’est une solution incomplète. Un test adéquat doit inclure des tests fonctionnels et d’intégration aux côtés des tests unitaires, et aucune solution automatisée ne peut savoir quelles pages doivent être visitées au sein de l’application ou du site Web, cela nécessite toujours une direction humaine
  2. Il est très difficile de le rattacher à des mesures commerciales de premier plan. La couverture des tests mérite d’être évaluée dans le cadre du plan d’un développeur principal pour surveiller la qualité du code, mais elle n’est pas assez directement liée à la valeur commerciale pour faire l’affaire toute seule. Une métrique connexe mais plus fonctionnelle pour le suivi des défauts du code est le « taux de bogues / défauts échappés ».

Métriques « tout le reste »

La liste ci-dessus est relativement courte par rapport au corpus de métriques passées qui ont été proposées par d’autres auteurs.Par souci d’exhaustivité, passons en revue certaines des métriques les plus couramment mentionnées ailleurs, et pourquoi elles n’ont pas été retenues.

Vélocité de l’équipe

C’était l’une des métriques les plus populaires citées par d’autres articles. Elle est recommandée parTechBeacon, InfoPulse et SeaLights.io.Cependant, les auteurs semblent hésiter à définir les unités de cette importante métrique.TechBeacon la définit comme « le nombre d' »unités » de logiciel que l’équipe termine généralement dans une itération. » Pas sotangible. InfoPulse n’essaie pas de spécifier les unités. SeaLights dit que les unités sont des « Story Points ». Ainsi, nous concluons que la notion de « vélocité » est adéquatement capturée par les Story Points, ou l’impact de ligne par procuration.

Code Churn

Le PDG de GitPrime (maintenant acquis par Pluralsight) était parmi ceux qui ont plaidé pour la prise en compte du Code Churn.Nous soutenons en réponse que les implications du Code Churn sont partout sur la carte,ce qui rend très difficile d’agir sur un churn élevé. Les métriques doivent être actionnables.

Release/Sprint Burndown

SeaLights et InfoPulse recommandent de prêter attention à la façon dont une équipe tend vers ses objectifs de sprint.Nous convenons que c’est important, mais c’est déjà couvert par la section « Story Points » ci-dessus.

Temps moyen de réparation / Temps moyen entre les pannes

Parmi la poignée d’articles qui défendent ces mesures, aucun ne s’aventure à décrire dans quelles unités la mesure est basée, ou quel service peut être utilisé pour recueillir ces points de données.La recherche trouve qu’Atlassian offre un article d’aide sur le sujet.Si cet article n’était pas déjà long de 2500 mots, MTTR pourrait faire la section « Mentions honorables ». Mais il n’est pas facile de le relier à la valeur commerciale, et il n’est pas simple pour une équipe moyenne d’y avoir accès sans changer ses routines.

Nous avons manqué quelque chose ?

Leave a Reply

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.