Comprendre le Temps Jusqu’à la Qualité
Il existe aujourd’hui de nombreux indicateurs pour suivre l’avancement de l’assurance qualité (QA). La plupart sont très utiles, mais ils ont tendance à n’être qu’unidimensionnels, au sens où ils ne sont que les instantanés d’un moment, ou d’un sprint, dans le temps. C’est vrai même pour les indicateurs de taux et de tendance, extrêmement importants, mais qui restent, eux aussi, des instantanés.
Lorsque je travaillais chez Symantec, j’ai remarqué ceci :
De nombreux indicateurs étaient utilisés pour déterminer le niveau de qualité atteint (prétendument) à la date de sortie. Mais aucun indicateur n’était recueilli, ni en cours de processus ni a posteriori, pour mesurer le coût de l'obtention de cette qualité.
Autrement dit, nous ne nous préoccupions pas de l’efficacité avec laquelle cette qualité avait été atteinte durant la vie du projet.
Envie d'en avoir plus avec The CTO Club ?
Créez un compte gratuit pour terminer cet article et rejoindre une communauté de CTO et de leaders en ingénierie partageant des cadres pratiques, des outils et des conseils pour concevoir, déployer et faire évoluer des technologies alimentées par l'IA.
Have an account? Log In
Votre produit a peut-être été livré avec une grande qualité, mais était-il vraiment nécessaire d’y consacrer autant de temps et d’efforts pour y parvenir ?
Il s’agit ici d’une question d’efficacité, et non de qualité à proprement parler, mais ces deux notions sont étroitement liées.
L’intersection entre qualité et efficacité
Qualité et efficacité se croisent car l'une des principales raisons pour lesquelles les projets logiciels dépassent souvent largement leur planning initial (et cet « échec » surgit généralement de façon inattendue dans la dernière phase du projet) est la mauvaise qualité du code. Pas seulement la qualité initiale, mais tout au long du projet.
Une autre raison, qui découle inévitablement de cette mauvaise qualité de code, ce sont les anomalies nécessitant plusieurs tentatives de correction, s’étalant sur plusieurs passages de test ou sprints, avant que le défaut soit réellement corrigé. Si jamais il l’est…
Ces itérations interminables de correction, de test et d’échec à nouveau ajoutent d’innombrables semaines de travail à presque tous les projets logiciels.
Pourtant, il est intéressant de noter que ce schéma d’échec n’est identifié dans aucun autre indicateur de projet ou de qualité que j'ai pu voir. En effet, comme évoqué plus haut, ces indicateurs sont des instantanés et ne parviennent donc pas à capter ce phénomène.
Il m’est alors venu à l’esprit qu’il existait un moyen simple de capturer ce schéma d’échec. J’ai donc imaginé un indicateur que j’ai appelé « Time to Quality », ou TTQ.
Présentation d’un nouvel indicateur : Time To Quality (TTQ)
L’indicateur lui-même est très simple. Il fonctionne ainsi :
À chaque passage de test (quelle que soit sa définition), il ne suffit pas de mesurer le nombre de tests réussis ou échoués, mais de compter aussi combien de tests sont passés du premier coup. Et combien ont nécessité deux, trois, ou davantage de tentatives avant que ces mêmes tests aboutissent finalement à un succès.
À titre d’exemple simple, si vous lancez 20 tests et que 5 réussissent du premier coup, votre ratio TTQ est de 25 %. Plus le chiffre est élevé, mieux c’est. C’est un indicateur simple, calculable et facilement accessible de votre qualité de code globale.
Cet indicateur donne une excellente indication de la qualité initiale du code.
Car plus le code est de qualité, moins vous aurez à relancer des tests avant qu’ils ne passent. Et inversement. Cet indicateur est bien plus fiable que les simples comptes et tendances de bugs.
Le TTQ est aussi un excellent indicateur de suivi de projet.
Par exemple, si, lors du premier passage, 70 % de vos tests réussissent et 30 % échouent, vous pouvez raisonnablement estimer que le projet reste dans les temps. Mais si seuls 20 % de vos tests passent du premier coup, alors, pour le dire en termes techniques, « là, tu as un gros souci ! »
Car cela signifie que vous n’avez en réalité pas effectué un premier passage fructueux. Et il faudra donc réattribuer ce temps à un passage futur, comme une dette de qualité.
L’indicateur TTQ est extrêmement utile en tant que “déclencheur d’alerte”.
Si vous l’utilisez de façon régulière, il fournit des données très précises permettant au chef de projet de savoir si le projet commence à déraper bien avant qu’il ne soit trop tard.
Cela signifie qu’il est possible d’agir plus tôt pour reprendre la situation en main. En évitant les moments embarrassants où, très tardivement, il faut avouer que le planning est totalement explosé. En d’autres termes, définissez un seuil TTQ pour établir si le projet est toujours en « vert », en « jaune » ou sur le point de passer au « rouge ». Faites-en un indicateur essentiel du statut même du projet.
Car, soyons honnêtes, l’une des pathologies récurrentes dans le développement logiciel est la dénégation persistante des difficultés, même flagrantes, dès les premiers signes. Chacun craint d’être taxé de « négatif », ou de passer pour quelqu’un de paresseux, de démotivé ou qui n’est pas « team player ». Le parallèle avec les familles dysfonctionnelles est assez troublant.
Cette dénégation, cette répression de ce que tout le monde sait pertinemment, crée cette dynamique de refus d’admettre que le projet est déjà très largement hors délais, jusqu’au tout dernier moment.
Lorsque cela ne peut plus être caché à la direction, la mauvaise surprise que cela crée n’a pour résultat que de saper—parfois définitivement—la confiance de la hiérarchie dans ses équipes de développement. Et qui pourrait les blâmer ?
Mais si vous intégrez le TTQ de façon constante dans vos suivis et votre gestion de projet—et agissez d’après ce que cet indicateur révèle—vous pouvez éviter ce genre de situation.
La mesure du Temps Vers la Qualité dépersonnalise la décision de reconnaître que des risques de calendrier et de qualité s’accumulent sur le projet dès ses premières phases.
Tout devient très simple et factuel, une question de chiffres. Ce n'est plus une question d'héroïsme personnel, qui se fait souvent au détriment de la personne concernée.
Le métrique TTQ est également très utile pour la rétro/post mortem d’un projet.
Cela permettra à l’équipe d’identifier précisément quelles parties du code étaient, et sont restées, faibles tout au long du projet. Et, par extension, d’évaluer l’efficacité de l’équipe à produire de la qualité. Ou combien cela a coûté.
C’est une question qui est largement évitée lors des rétrospectives de projet. En partie parce que les équipes ne disposent pas du vocabulaire conceptuel pour la formuler, et en partie parce qu’il est souvent politiquement sensible de signaler une mauvaise qualité de code persistante dans l’ingénierie.
En résumé
Le TTQ offrira une transparence et une prévisibilité énormes à vos projets pour presque aucun coût en temps ou en efforts, puisqu’il s’agit simplement d’une méta-analyse des métriques que vous collectez déjà.
J’utilise le TTQ sur mes projets QA depuis deux décennies, et il a reçu une large adhésion de la part des chefs de projet que j’ai formés à cette approche, pour toutes les raisons évoquées ci-dessus.
Testez-le, et vous verrez par vous-mêmes. Ce sera vraiment un changement de paradigme pour votre équipe. Comme toujours, bonne chance.
P.S. Si vous souhaitez entendre plus d’anecdotes de terrain et comprendre les raisons derrière le TTQ, j’en ai parlé avec Jonathon Wright dans le podcast QAL.
