9 mesures qui peuvent faire la différence pour les équipes de développement logiciel d’aujourd’hui

Comme je l’ai noté dans l’article « Pourquoi les mesures n’ont pas d’importance dans le développement logiciel (sauf si vous les associez à des objectifs commerciaux) », le choix des mesures nécessite une réflexion et un soin considérables pour répondre aux questions spécifiques auxquelles une entreprise doit vraiment répondre. Voici le point critique: Les mesures ne doivent être conçues que pour répondre aux questions commerciales. Et ces questions ne sont jamais: « Combien de KLOCs sommes-nous jusqu’à présent? »

Cet article reprend là où le précédent s’était arrêté, en discutant d’abord des métriques spécifiques que chaque équipe devrait commencer à utiliser, ou du moins envisager d’utiliser rapidement comme moyen d’améliorer les performances notables. Notez que le titre de cet article prétend qu’il existe « 9 métriques qui PEUVENT faire la différence… » – car ce qui est vraiment important, ce qui fera vraiment la différence, c’est comment ces métriques sont réellement utilisées pour améliorer la valeur commerciale. Cette utilisation dépend de vous. Ensuite, cet article se termine en expliquant comment combiner ces mesures pour créer du sens, ainsi que formuler et tester une hypothèse de valeur commerciale.

Commencez par mesurer les bonnes choses

Voici neuf métriques objectives (marquées par des puces) que vous devez surveiller en permanence, afin d’apporter des améliorations progressives aux processus et aux environnements de production. L’amélioration de ces chiffres ne garantira pas que les niveaux de satisfaction de vos clients augmenteront à pas de géant. Mais au moins ce sont les bonnes choses à mesurer. Dans une section ultérieure de cet article, « Mettre tout cela ensemble », vous verrez pourquoi.

Métriques de processus agiles

Pour les processus agiles et lean, les métriques de base sont le délai d’obtention, le temps de cycle, la vitesse de l’équipe et les taux d’ouverture/fermeture. Ces mesures facilitent la planification et éclairent les décisions concernant l’amélioration des processus. Bien qu’ils ne mesurent pas le succès ou la valeur ajoutée, et qu’ils n’aient rien à voir avec la qualité objective du logiciel, vous devez quand même les mesurer. Je vais expliquer pourquoi ci-dessous.

• Délai d’obtention — combien de temps il vous faut pour passer de l’idée au logiciel livré. Si vous souhaitez être plus réactif vis-à-vis de vos clients, travaillez à réduire vos délais, généralement en simplifiant la prise de décision et en réduisant le temps d’attente. Le délai d’obtention comprend le temps de cycle.
• Temps de cycle — combien de temps il vous faut pour apporter une modification à votre système logiciel et livrer cette modification en production. Les équipes utilisant la livraison continue peuvent avoir des temps de cycle mesurés en minutes, voire en secondes, au lieu de mois.
• Vitesse de l’équipe — combien d' »unités » de logiciel l’équipe complète généralement en une itération (alias « sprint »). Ce nombre ne doit être utilisé que pour planifier des itérations. Comparer les vitesses de l’équipe est un non-sens, car la métrique est basée sur des estimations non objectives. Traiter la vitesse comme une mesure de succès est inapproprié, et faire d’une vitesse spécifique un objectif fausse sa valeur pour l’estimation et la planification.
• Taux d’ouverture/fermeture – combien de problèmes de production sont signalés et fermés au cours d’une période donnée. La tendance générale compte plus que les chiffres spécifiques.

Lorsque l’une ou l’ensemble de ces mesures sont hors de la plage prévue ou tendent dans des directions alarmantes, ne supposez pas de cause. Parlez à l’équipe, obtenez toute l’histoire et laissez l’équipe décider s’il y a lieu de s’inquiéter et, le cas échéant, comment y remédier.

Vous ne pouvez pas connaître ou supposer les causes profondes des chiffres, mais ces métriques vous donnent un aperçu de l’endroit où vos processus essentiels nécessitent une attention particulière. Un taux d’ouverture élevé et un taux de clôture faible sur quelques itérations, par exemple, peuvent signifier que les problèmes de production sont actuellement une priorité inférieure aux nouvelles fonctionnalités, ou peut-être que l’équipe se concentre sur la réduction de la dette technique pour résoudre des classes entières de problèmes, ou que la seule personne qui savait comment les résoudre quitte, ou autre chose. Vous ne pouvez pas connaître ou supposer les causes profondes des chiffres.

Analyse de production

• Temps moyen entre les pannes (MTBF)
• Temps moyen de récupération/ réparation (MTTR)

Les deux sont des mesures globales des performances de votre système logiciel dans son environnement de production actuel.

• Taux de plantage de l’application – combien de fois une application échoue divisé par combien de fois elle a été utilisée. Cette métrique est liée à MTBF et MTTR.

Notez qu’aucune de ces trois mesures ne vous indique les fonctionnalités individuelles ou les utilisateurs concernés. Pourtant, plus les chiffres sont petits, mieux c’est. Un logiciel moderne de surveillance des opérations facilite la collecte de mesures détaillées sur des programmes et des transactions individuels, mais il faut du temps et une réflexion approfondie pour configurer des plages appropriées pour les alertes et / ou les déclencheurs de montée ou de descente (pour les systèmes basés sur le cloud).

Nous aimerions que notre logiciel n’échoue jamais, mais c’est statistiquement improbable. Lorsque notre logiciel échoue, nous aimerions qu’il ne perde jamais de données critiques et qu’il récupère instantanément, mais cela peut être extrêmement difficile à réaliser. Si votre logiciel est votre source de revenus, cependant, l’effort en vaut la peine.

Au-delà du MTBF et du MTTR, des mesures plus fines sont basées sur des transactions individuelles, des applications, etc., et elles reflètent la valeur métier fournie et le coût de la correction des défaillances. Si votre application de traitement des transactions se bloque une fois sur cent, mais récupère en une seconde ou deux et ne perd aucune information critique, ce taux de crash de 1% peut suffire. Mais si chaque crash concerne une application qui exécute 100 000 transactions par jour, perd une vente de 100 $ et coûte 50 $ à corriger sur le back-end, ce taux de crash de 1% sera une priorité. Sa fixation aura un impact significatif sur le résultat net.

Mesures de sécurité

La sécurité est un aspect de la qualité logicielle qui est souvent négligé jusqu’à plus tard (ou trop tard). Des outils d’analyse de sécurité peuvent être utilisés dans le processus de construction, en plus d’évaluations plus spécialisées et de tests de résistance. Les exigences de sécurité sont souvent simples et sensuelles, mais l’équipe de développement de logiciels doit les prendre en compte et prendre en compte les mesures qui en découlent.

La gamme complète des pratiques de sécurité et des métriques associées dépasse le cadre de cet article, mais comme pour les métriques de processus agiles et les métriques de production, il existe quelques métriques spécifiques qui peuvent représenter beaucoup pour la satisfaction globale de vos clients.

• Incidents de point de terminaison – combien de points de terminaison (appareils mobiles, postes de travail, etc.) avez-vous subi une infection virale sur une période de temps donnée?
• MTTR (mean time to repair) — dans les métriques de sécurité, il s’agit du délai entre la découverte d’une faille de sécurité et un remède opérationnel déployé. Comme pour la mesure MTTR de production mentionnée ci-dessus, le MTTR de sécurité doit être suivi sur des intervalles de temps spécifiques. Si la valeur MTTR diminue avec le temps, les développeurs sont de plus en plus efficaces pour comprendre les problèmes de sécurité tels que les bogues et comment les résoudre.

Pour ces deux métriques, des nombres plus petits au fil du temps signifient que vous allez dans la bonne direction. Moins d’incidents de point de terminaison parlent d’eux-mêmes. À mesure que la valeur MTTR diminue, les développeurs sont de plus en plus efficaces pour comprendre les problèmes de sécurité tels que les bogues et comment les corriger.

Vous trouverez d’autres moyens d’appliquer des métriques de sécurité au développement logiciel dans les articles Sécurité des applications pour les projets Agiles et Modèles de menaces de sécurité : Une introduction Agile.

Une note sur les métriques de code source

Aujourd’hui, il est facile de brancher un scanner de code source dans votre pipeline de génération et de produire des quantités de métriques objectives. Il existe des moyennes empiriques et des plages suggérées et des arguments logiques sur l’importance relative de ces mesures. Mais dans la pratique, ces outils sont les plus utiles pour appliquer des styles de codage, signaler certains anti-modèles et identifier les valeurs aberrantes et les tendances.

Cela ne vaut tout simplement pas la peine de se raccrocher aux chiffres. Voici un exemple, à titre d’explication.

Supposons que vous trouviez une méthode dans une classe avec une métrique ridicule, telle qu’une complexité NPATH de 52 millions. Cela signifie qu’il faudrait 52 millions de cas de test pour exercer pleinement chaque chemin à travers le code. Vous pouvez refactoriser le code dans une structure plus simple, mais avant de le faire, considérez quel serait l’impact commercial. Il y a de fortes chances que l’ancien code laid fonctionne assez bien (bien que sa couverture de test puisse être insuffisante). Appeler l’anti-modèle à l’équipe afin qu’elle puisse éviter de le répéter est un apprentissage précieux, mais le corriger ne ferait probablement pas bouger l’aiguille sur toute mesure commerciale pertinente.

Il est préférable que l’équipe accepte le niveau de conformité et les règles auxquelles leur code est soumis, mais sachez que l’examen des valeurs aberrantes et l’inquiétude face aux changements de tendance peuvent perdre beaucoup de temps.

Puis mettez tout ensemble: Le succès est la mesure ultime

La joie d’utiliser des outils automatisés pour suivre et mesurer les mesures de qualité et l’analyse des utilisateurs est qu’elle libère du temps pour se concentrer sur les mesures qui comptent vraiment : les mesures de réussite.

Comment utiliser les indicateurs de réussite

Les entreprises ont des objectifs. Les objectifs impliquent des questions, telles que « À quoi ressemble le succès? » ou  » Comment cela affectera-t-il le comportement des clients? »Des questions correctement quantifiées impliquent des mesures.

Autrement dit, les métriques ne doivent être utilisées que pour répondre à des questions, pour tester des hypothèses qui soutiennent un objectif commercial spécifique. Et cela ne devrait être fait que tant que les questions et les réponses aident à conduire des changements positifs.

Maintenant, tous les projets en général n’ont-ils pas un ensemble d’objectifs, de questions et d’hypothèses invariants, et donc de métriques?

Oui, mais seulement du point de vue de l’entreprise. Les mesures au niveau de l’entreprise d’éléments tels que l’engagement des utilisateurs, les taux de clôture, la génération de revenus, etc. fournissent des commentaires sur la façon dont l’entreprise se porte dans le monde réel. Les modifications apportées aux logiciels qui affectent l’entreprise affecteront également ce type de mesures.

À un niveau de résolution plus fin, chaque fonctionnalité et histoire d’utilisateur peut avoir sa propre mesure de réussite — de préférence une seule, et une qui est directement liée à une mesure de la valeur fournie au client. Terminer neuf histoires sur dix dans un sprint pour des fonctionnalités qui ne sont jamais livrées est du gaspillage, pas du succès. Livrer des histoires que les clients ne veulent pas ou n’utilisent pas est du gaspillage, pas du succès. Livrer une histoire qui améliore certains aspects du bonheur des utilisateurs est un succès. Livrer une histoire qui n’améliore manifestement pas l’engagement des utilisateurs est également un succès, car vous aurez appris quelque chose qui n’a pas fonctionné, invalidé une hypothèse commerciale et libéré des ressources pour poursuivre d’autres voies.

Comment formuler une hypothèse de valeur

Une hypothèse de valeur est une déclaration sur ce que vous pensez se produire à la suite de la livraison d’une caractéristique spécifique. La relation entre le logiciel, le résultat souhaité et les métriques forme l’hypothèse de valeur pour la fonctionnalité (ou le système, ou l’histoire, ou la mise à niveau, etc.). L’hypothèse devrait exprimer comment la mesure ciblée devrait changer, sur quelle période de temps et dans quelle mesure être considérée comme efficace. Vous devrez parler à l’équipe et au propriétaire du produit, au minimum, pour comprendre la chose spécifique que cette fonctionnalité ou cette histoire est destinée à créer ou à améliorer par rapport à l’entreprise afin de formuler son hypothèse de valeur. Vous devrez peut-être demander « pourquoi » plusieurs fois (comme un enfant de trois ans) pour éplucher les couches d’hypothèses non datées; soyez patient. Lorsque vous comprenez quelle est la valeur commerciale, vous pouvez commencer à poser les questions qui vous mèneront aux mesures qui répondent à la question.

Par exemple, une histoire « technique » visant à améliorer la vitesse d’un processus de paiement en ligne peut avoir comme hypothèse sous-jacente qu’un paiement plus rapide entraînera plus de ventes. Mais pourquoi pensons-nous cela? Beaucoup de gens abandonnent-ils leur panier pendant le processus de paiement? Si tel est le consensus (car ce consensus est soutenu par des données de base), l’hypothèse de valeur peut être « Nous pensons qu’un processus de paiement plus rapide entraînera une diminution des taux d’abandon de panier, entraînant une augmentation des ventes et une amélioration de l’expérience utilisateur. »

Vous pouvez probablement supposer que les utilisateurs aimeront un paiement plus rapide, mais cela ne fait pas de mal de demander s’ils l’ont remarqué. Les taux d’abandon de panier et les ventes peuvent être mesurés avant et après la mise en place du nouveau processus, pendant une certaine période. Si le taux d’abandon de chariot diminue et que les ventes augmentent (au-delà des fluctuations statistiques), les preuves appuient l’hypothèse et vous pourriez vous demander si d’autres améliorations de la vitesse sont justifiées. Si ce n’est pas le cas, laissez cette métrique s’estomper en arrière-plan (ou supprimez-la, si elle est distrayante), et concentrez votre attention sur l’hypothèse suivante. Si le taux d’abandon de panier diminue mais que les ventes restent inchangées, mesurez pendant une période plus longue ou repensez le lien supposé entre abandon de panier et ventes. En d’autres termes, utilisez des métriques pour apprendre, et seulement tant qu’elles s’avèrent utiles pour conduire des améliorations.

Dans certains cas, l’hypothèse peut être clairement fausse, nous abandonnons donc les métriques (et annulons les modifications logicielles!) après quelques jours. Dans d’autres cas, l’hypothèse peut être correcte, nous continuons donc à améliorer ce domaine pendant des années.

Six heuristiques pour une utilisation efficace des métriques

Nous avons vu à quel point les métriques logicielles subjectives comptent beaucoup plus pour le succès de l’entreprise que les métriques de qualité objectives traditionnelles. L’effort requis pour trouver et mesurer des mesures métier pertinentes pour les fonctionnalités est compensé par les connaissances et les opportunités d’apprentissage acquises. Les conditions et les opportunités commerciales changent constamment, alors plutôt que de résumer une formule à suivre, qui peut être fragile, voici six règles empiriques, ou heuristiques, pour aider à maintenir la concentration et la flexibilité. Puissent-ils vous guider sur votre chemin vers des logiciels de qualité et le succès commercial!

1. Les métriques ne peuvent pas vous raconter l’histoire; seule l’équipe peut le faire (avec un bout de chapeau à Todd DeCapula).
2. Comparer les flocons de neige est un gaspillage.
3. Vous pouvez mesurer presque n’importe quoi, mais vous ne pouvez pas faire attention à tout.
4. Les indicateurs de réussite de l’entreprise stimulent les améliorations logicielles, et non l’inverse.
5. Chaque fonctionnalité ajoute de la valeur ; mesurez-la ou ne le faites pas.
6. Mesurez uniquement ce qui compte maintenant.