Qualité Intrinsèque vs Qualité Extrinsèque
En matière de qualité logicielle, il existe deux visions antagonistes et irréconciliables. La manière historique de gérer la qualité nous vient, dirons-nous, d’un pays fort fort lointain.
Dans cette contrée reculée, les processus règnent en maître, ils sont aux commandes des humains qui doivent les appliquer docilement. Dans de tels processus, la qualité est envisagée comme un événement ponctuel, qui survient dans le flux immuable d’une séquence. Comme les humains sont au service du processus, ils réalisent eux-mêmes les tests, à la main, à la force de leurs poignets, afin que le processus accepte leurs offrandes binaires. Le processus a décidé que les responsabilités devaient être séparées entre humains et que leurs livrables devaient être spécialisés en fonction des étapes-clés du processus. Dans ce monde idéalisé, la politique du zéro bogue est érigée en dogme, et les humains se transmettent des patates chaudes, en priant que leurs livrables ne soient pas entachés d’imperfection. Dans le cas contraire, le dogme ferait d’eux des cibles faciles dans la chasse rituelle et sacrificielle des coupables. Aussi, pour éviter qu’un tel drame ne survienne, l’on voue un véritable culte aux 100% de couverture de tests fonctionnels.
La spécialisation des tâches fait écho au taylorisme, et si d’aucuns emploient leurs mains, d’autres les commandent et contrôlent, dans un dispositif à la structure pyramidale. Bien évidemment, contrôler la qualité, une fois que la non-qualité est inscrite dans le code et sa conception, atteint rapidement ses limites, en plus de manquer d’efficacité.
Pourtant, ce statu quo n’est pas une fatalité. Et il nous appartient en tant que professionnels du développement logiciel d’en changer. Car quand un processus ne convient pas, il devient une question de survie de le remplacer par une meilleure solution. Survie économique certes, mais aussi survie cérébrale tant la répétition assèche l’esprit et l’envie. Or sans esprit créatif et d’initiative, pas d’innovation.
Alors quelle alternative s’offre à nous ? Revenons dans nos contrées, et voyons ce que nous pouvons attendre d’une gestion globalisée de la qualité logicielle — par opposition à une gestion localisée. Le fait d’élever la qualité d’un logiciel rend possible de saisir de nouvelles opportunités, en permettant la mise en place du déploiement continu : sitôt qu’un changement de code apporte de la valeur aux utilisateurs, ce changement leur est livré automatiquement. C’est une dynamique beaucoup plus compétitive. Seulement elle repose sur un prérequis : puisque la frontière temporelle entre développeur et utilisateur devient extrêmement ténue, le code livré doit être irréprochable.
La qualité intrinsèque rend possible le déploiement continu, où un code irréprochable va de pair avec une expérience de l’utilisateur irréprochable.
Pour y parvenir, il faut commencer par remettre l’humain aux commandes : les personnes et les équipes passent au premier plan, de façon à porter une attention continue à la qualité. Dans un écosystème propice au rayonnement de l’expertise et de l’habileté, la qualité va pouvoir prendre une toute autre ampleur.
Comme le potentiel humain est libéré de ses entraves, il peut désormais tirer profit de ce qui se fait de mieux selon les préoccupations à gérer :
- L’humain excelle dans l’exploration, la créativité, l’heuristique.
- Les automates et leurs technologies concomitantes excellent dans la répétition et la précision.
Là où l’un excelle, l’autre est mauvais, et inversement.
En renforçant la collaboration au lieu de saucissonner les tâches et les livrables, les personnes partagent les mêmes objectifs, et de cette appropriation collective résulte une approche des problèmes et difficultés orientée vers la recherche des solutions — plutôt que des coupables.
Enfin, s’agissant de test, l’on teste juste assez, juste ce qu’il faut, afin de minimiser les efforts et de maximiser les résultats. Par ailleurs, adapter l’effort consenti aux tests, qu’ils soient automatisés ou manuels, implique d’anticiper et d’ajuster les risques que nous sommes prêts à prendre. Cette prise de risque est elle-même pondérée par la réduction des impacts des défauts résiduels et une forte réactivité en cas d’incident.
En conclusion, produire de meilleurs logiciels repose notamment sur deux piliers :
- Qualité non-négociable, plutôt que variable d’ajustement.
- Qualité intrinsèque, plutôt qu’extrinsèque.
