TechnicalDebt TrapToAvoid TooMuchAbstractIndicators 604x270

Les pièges à éviter lors d’un projet de qualimétrie – #1 Déployer des indicateurs trop abstraits

Téléchargez notre avis d’expert

Découvrez comment élaborer des indicateurs qualité pertinents et gérer efficacement la Dette Technique grâce aux tableaux de bord SQUORE.

Lorsque l’on parle de qualité logicielle, nombre d’articles recensent les bonnes pratiques et les processus de développement à mettre en œuvre pour éviter qu’une application ne s’enlise sous le poids de sa dette technique : identifier les composants à risque, réaliser des revues de code régulières, refactorer les artéfacts complexes, corriger les violations de règles bloquantes ou critiques, etc.

Mais paradoxalement, il existe peu de recommandations quant au projet en lui-même :
car oui, la mise en place d’une solution de qualimétrie est un véritable projet, avec ses parties prenantes (DSI, responsable qualité, développeurs, prestataires, directions métiers), ses étapes (évaluation des outils open source ou commerciaux, projet pilote, déploiement) et – comme tout projet – ses pièges à éviter.

L’expérience cumulée des consultants Squoring en matière de qualité logicielle avoisinant le siècle, nous avons participé à la mise en place de nombreux projets de qualimétrie ou pilotage de la dette technique, au sein de départements IT d’entreprises de toutes tailles et de tous secteurs.

Il nous paraissait donc intéressant de synthétiser notre vision et partager les bonnes pratiques sur le sujet, en mettant en lumière quelques pièges que nous avons pu identifier jusqu’à présent.

Débutons donc notre série d’avis d’expert dédiée au sujet « Les pièges à éviter lors d’un projet de pilotage de la qualité des développements » avec notre premier article : Déployer des indicateurs trop abstraits.

Piège #1 : Déployer des indicateurs trop abstraits

C’est sans doute l’un des pièges les plus fréquemment observés. Comme dans tout projet de mesure ou de pilotage, les indicateurs revêtent un caractère stratégique, car ils concrétisent la démarche qualité. L’indicateur est l’un des principaux livrables, et les projets de gouvernance des développements ne dérogent pas à la règle, bien au contraire.

Dans ce contexte, le piège réside dans la tentation de vouloir représenter l’état de la qualité d’un artéfact par un indicateur trop synthétique, conçu à partir d’informations de types différents, parfois contradictoires.
En résumé, mal concevoir ses indicateurs qualité revient à déployer dans un tableau de bord une série de hiéroglyphes dont la signification n’a plus de sens, y compris pour leur propre auteur.

Quand on « tombe dans le piège », l’indicateur est le plus souvent exprimé sous forme d’une valeur non bornée, sans unité. Par exemple : votre projet a une note de qualité globale de 128, sa maintenabilité est de 72 et sa robustesse de 42.
Vous le comprendrez facilement, ces valeurs ne veulent pas dire grand-chose en dehors de leur contexte, et soulèvent des questions assez embarrassantes qui révèlent rapidement la mauvaise conception d’un indicateur et fragilisent la démarche qualité dès ses premières phases :

  • Un problème très probable d’interprétation et de communication entre les développeurs et le management
  • Un indicateur mal compris est un indicateur peu adopté, voire rejeté
  • L’outil produisant l’indicateur sera parfois remis en cause, contourné par des indicateurs « maison » : cette double lecture compromet alors le pilotage des développements et les arbitrages qui en découlent

Ce qui se conçoit bien s’énonce clairement

La conception de vos indicateurs qualité est donc un point crucial de votre démarche qui nécessitera une attention toute particulière. A ce titre, elle doit reposer sur des bases claires, solides et indiscutables. C’est une des garanties pour que votre démarche qualité soit comprise, mise en œuvre, adoptée et améliorée de manière continue.
N’oublions pas le rôle de l’indicateur : il doit permettre de mesurer avec plus ou moins de précision l’écart entre une situation et un objectif. Cet indicateur doit également vous aider à bâtir le plan d’actions correctrices nécessaires pour atteindre l’objectif fixé.

Prenons un exemple concret pour illustrer. Un de mes objectifs qualité pour mon application est qu’elle soit fiable en production :

  • Je vais donc m’assurer qu’elle soit facilement testable
  • Je vais également vérifier qu’elle a été effectivement testée !
  • Mon indicateur de fiabilité contiendra par exemple :
    • Des métriques de code renseignant sur la testabilité du code (complexité des méthodes, couplage entre les classes, etc.)
    • Des informations issues des tests unitaires et d’intégration, comme le taux de couverture de test du code (via des outils comme JaCoCo, Emma, Clover…)
    • Le résultat des campagnes de tests fonctionnels
    • Pour compléter la vision du niveau de fiabilité de mon application, je pourrais également inclure dans mon indicateur les informations issues d’outils de test de montée en charge. Car en effet, si mon application est destinée à servir plusieurs milliers d’utilisateurs simultanés, une indisponibilité causée par une performance dégradée sera perçue comme un manque de fiabilité.

Les caractéristiques d’un indicateur efficace

Sans entrer dans les détails des normes prévues à cet effet (NF X50 -171, ISO 9001:2008…), nous pouvons dire d’un indicateur qu’il est efficace, dès lors qu’il présente les caractéristiques suivantes :

  • Utilité et pertinence : En quoi l’information apportée par un indicateur est-elle pertinente et nécessaire pour mesurer l’écart et atteindre mon objectif ?
  • Simplicité : un indicateur doit être facile à expliquer et simple à mettre en œuvre. Dire ce que l’on fait, faire ce l’on dit et le vérifier. Un indicateur doit alors indiquer si l’objectif est atteint ou non (cf. l’approche « Goal Question Metric » de Victor Basili).
  • Un indicateur doit être représentatif et doit être :
    • Exhaustif : un indicateur doit, dans l’idéal, être disponible pour tous les artéfacts entrant dans le champ de l’analyse. C’est d’ailleurs l’une des caractéristiques permise notamment grâce aux outils d’analyse de code.
    • Quantifiable : par exemple, le taux de couverture des tests, le nombre de défauts en production, le total de violations, l’écart aux délais de livraison initialement prévus, etc.
    • Objectif : la mesure ne doit pas être sujette à polémique. Quid du nombre de ligne de code pour indiquer la volumétrie d’un logiciel : devons-nous compter les lignes blanches ? les commentaires ? uniquement les instructions compilées ? le code généré doit-il être compté dans la volumétrie ?
  • Opérationnalité : Concevoir un indicateur « sur papier » est une chose, le déployer et le faire vivre avec des données réelles en est une autre. Bien souvent, les données nécessaires à son calcul sont de format différents, dans des outils divers, voire même n’existent pas pour certains artéfacts. Il faudra donc s’assurer de la disponibilité et du caractère industrialisable de l’indicateur à grande échelle.

Un indicateur pertinent, simple à mettre en place et directement opérationnel : la Dette Technique

Pour éviter de tomber dans le piège des indicateurs abstraits, les indicateurs de type « Dette Technique » sont particulièrement adaptés pour débuter un projet de pilotage de la qualité des développements.
La dette technique est une métaphore initialement exprimée par Ward Cunningham en 1990. Il s’agit d’un emprunt, volontaire ou non, des parties prenantes d’un produit logiciel (ex : décaler la livraison d’une fonctionnalité au sprint suivant, remettre à une release majeure la refonte du modèle d’architecture, etc.), qui impliquera forcément
– tôt ou tard – le remboursement de cette dette avec des intérêts.

Autrement dit, la fonctionnalité décalée (emprunt), qui coûterait 100 unités d’œuvre à délivrer à un instant T (capital), coûtera en réalité 100 + X (intérêts) unités d’œuvres à T+1. Et comme pour un crédit bancaire, plus la durée de l’emprunt est longue, plus les intérêts sont élevés.

Convaincus de l’intérêt de cette approche, nombres d’acteurs du domaine (éditeurs de solutions comme Squoring Technologies ou sociétés de conseil comme Inspearit avec sa méthode SQALE) en ont implémenté la mesure, afin de pouvoir quantifier le montant de la dette technique d’une application, généralement exprimée en unité de temps.
Grâce à cette mesure, le concept de Dette Technique accède au rang des indicateurs privilégiés en devenant un véritable outil pour piloter les développements par la qualité.

  • Utilité: la Dette Technique peut avoir un impact négatif sur l’agilité des équipes de développement et leur capacité d’innovation. Une Dette Technique élevée implique des efforts de maintenance corrective importants. Des efforts certes nécessaires, mais qui se feront au détriment des nouvelles fonctionnalités à forte valeur ajoutée.
  • Simplicité de compréhension : du DSI jusqu’au développeur en passant par le DevOp, la dette technique, dès lors qu’elle est exprimée en unités d’œuvre, parle à tout le monde. La charge de tout ce qui était prévu et décalé, de ce qui est livré mais non conforme aux exigences initiales, est cumulée pour mesurer la dette d’une application, d’un projet ou d’un artéfact.
  • Facilité de mise en oeuvre : dans les modèles les plus simples, la dette technique est calculée en additionnant les charges des non conformités. Ainsi, les premiers essais de cet indicateur peuvent parfaitement tenir dans un tableur Excel.
  • Conciliation des visions techniques et managériales : l’indicateur étant exprimé en unité d’œuvre (heures, jours / homme ou devises), l’ensemble des parties prenantes dialoguent avec un référentiel commun. Les ambiguïtés générées par un indicateur abstrait sont évitées. Les équipes se concentrent alors sur les problèmes de qualité, plutôt que sur la définition de l’indicateur en lui-même !
  • Un indicateur naturellement orienté « plan d’actions » : c’est l’un des énormes avantages liés à la simplicité de l’indicateur de Dette Technique. Calculé à partir des éléments non conformes aux exigences, l’indicateur permet avec une extrême facilité d’identifier les actions à mener pour atteindre le niveau d’exigence souhaité et réduire ainsi la dette technique d’un projet de manière efficiente et objectivée.

Téléchargez notre avis d’expert

Découvrez comment élaborer des indicateurs qualité pertinents et gérer efficacement la Dette Technique grâce aux tableaux de bord SQUORE.

Laisser un commentaire

Current day month ye@r *