Qualité et Agilité : les frères ennemis ?

Qui n’a pas eu ce sentiment un peu diffus, à un moment ou à un autre, de se dire que l’agilité ne rime pas avec qualité ?

Qui n’a pas pensé qu’en seulement 2 semaines il est illusoire de développer, tester et livrer des fonctionnalités à des utilisateurs et, en même temps, obtenir un résultat sans défaut, sans erreur! Est-ce vraiment impossible ?

On peut donc se demander quelle est la voie à prendre pour réconcilier ces « 2 frères » qui ont comme objectif commun de livrer le bon produit, au bon moment, au bon client tout en gardant une totale maîtrise de vos réalisations.

Qualité et/ou Agilité ?

J’accompagne depuis de nombreuses années des organisations dont la majeure partie de l’activité est consacrée au développement logiciel. A l’ère du digital vous me direz quoi de plus banal ! Un état d’esprit AGILE et l’utilisation des pratiques venant de SCRUM ou de SAFe vous permettront de mieux comprendre le contexte dans lequel je « navigue ».

Ainsi, passés les premiers moments où les équipes sont de plus en plus autonomes, où leur quête de sens est (un peu plus) satisfaite et où la réponse aux problématiques des clients est de plus en plus fluide grâce à la réalisation de nombreuses itérations (les plus courtes possibles), arrive le « moment » où ça coince !

A quel niveau me diriez-vous ?

Je dirais principalement au niveau de la qualité des réponses faites aux utilisateurs finaux. Vous savez ceux qui, quotidiennement, ont entre leurs mains les fonctionnalités que des ingénieurs en développement logiciel ont conçues. A ce niveau, régulièrement, ça coince énormément !

Ça coince tellement que ces équipes se demandent s’il ne faut pas tout changer.

• Elles « s’auto-flagellent » en se disant qu’elles n’atteindront jamais l’excellence, que la qualité des livraisons est médiocre.
• Elles partent à la recherche du coupable qu’elles ne trouveront jamais car la responsabilité est bien souvent collective !
• Elles vont remettre en cause les pratiques qu’elles auront nouvellement apprises et qui auront mis beaucoup de temps à infuser au sein de l’organisation.

Elles vont même jusqu’à renier l’agilité, renier les cycles courts, renier l’auto-organisation et l’autonomie si durement acquise !

Quand arrive le moment ou vous avez perdu le contrôle de ce que vous produisez

Arrive même l’instant où les équipes ont peur ou tout du moins ressentent une très forte anxiété « à appuyer sur le bouton ».

Elles savent que passé cette « mise en prod »,

• Elles auront encore beaucoup de travail pour stabiliser le produit.
• Elles craignent l’apparition de nouveaux bugs à corriger le plus vite possible, dans l’urgence au détriment de tout autre chose.
• Elles craignent les régressions qui provoquent un douloureux retour en arrière et augmentent ainsi la frustration des utilisateurs.

Lentement, ce poison, cette anxiété, se propage dans les équipes et aboutit inexorablement à leur démotivation. Mais d’où provient cette anxiété ? Comment est-elle arrivée ? En quelques mots : elle provient principalement d’un manque de maîtrise du produit[1]. Et, ce manque de maîtrise provient principalement de son faible niveau de qualité.

Comment peut-on diminuer cette anxiété ? Comment atteindre une situation où les risques sont calculés à la virgule près, et dans laquelle tout est sous contrôle ?

Doit-on revenir en arrière sur l’agilité, sur nos manières de faire qui serait la source de cette perte de maîtrise ?

Non, car il n’y a pas d’incompatibilité entre l’agilité et cette non-qualité qui conduit à une perte de contrôle. Au contraire, la qualité est un des principes fondamentaux de l’agilité[2]. Et c’est ce qui va permette à nouveau, de contrôler ce que l’on produit.

Une définition de la Qualité

Si je dois donner une définition de la qualité dans les activités de développement logiciel j’éviterai de donner celle d’un dictionnaire. Car, elle peut prendre de nombreuses formes et finalement même dans le Larousse elle n’est pas assez précise pour ce qui nous concerne ici.

Je prendrai plutôt un extrait de la préface écrite par J.O. Coplien du livre « Clean code » (Robert C. Martin, édition : Prentice Hall) : « La qualité, c’est le résultat d’un million d’actes désintéressés de bien faire – et non d’une grande méthode qui descend des cieux. »

En parlant « de millions d’actes de bien faire » pour atteindre l’excellence, l’industrie est le parfait exemple de la mise en place d’un système qualité éprouvée par le temps (et les pratiques) et qui conduit à une grande confiance dans l’utilisation des produits fabriqués.

Personnellement, j’ai plutôt confiance quand je prends l’avion ou quand je conduis une voiture. Les astronautes qui montent dans la capsule Dragon de SpaceX en direction de la station internationale ont une grande confiance dans ce vaisseau où le moindre court-circuit peut s’avérer très problématique et où le moindre petit manquement sur un détail peut être dramatique : les astronautes d’Apollo XIII s’en souviennent encore ou plus tragiquement ceux d’Apollo I.

Voici quelques exemples dans l’industrie :

• Un technicien sur une ligne de montage a l’obligation, le pouvoir et le devoir d’arrêter la chaîne de production si une pièce lui arrive défectueuse.
• A la suite de cet arrêt, des « contre-mesures » seront décidées collectivement et directement sur la chaîne par les « sachants» pour régler le problème.
• Dans le même ordre d’idée, la création de poka-yoke, permet, d’être sûr à 100% de ne pas se tromper quand on réalise une tâche. Et vous utiliser tous le jours ce procédé quand vous branchez un appareil électronique à une prise USB ou bien quand le distributeur de billet vous rend votre carte avant de vous donner votre argent. Vous êtes ainsi sûr d’avoir branché votre câble dans le bon sens ou de ne pas avoir oublier votre carte dans la machine !
• Les « check-list » qui existent à tous les niveaux de la réalisation d’un produit, atteignent un niveau de finesse qui permet aux équipes de maîtriser ce qu’elles réalisent.

Tous ces points trouvent une concordance dans le développement logiciel :

• « L’arrêt de chaîne» et les « contre-mesures » peuvent s’apparenter à une reprise en main par les développeurs, les « sachants ». Ce sont eux qui décident comment faire les choses.
• Les « poka-yoke» peuvent s’apparenter aux tests automatiques. On « délègue » la vérification d’un nombre très important de « petite choses » à la machine pour nous enlever la « charge mentale » de vérifier constamment la justesse et la qualité des réalisations incorporées à d’autres éléments construits antérieurement.
• Les « check-list» trouvent leur similitude dans la « définition du fini » qui permet de vérifier et de contrôler, qu’à toutes les étapes du processus, les actions réalisées sont véritablement finies avec un niveau de qualité optimal.

Les bonnes pratiques pour atteindre l’excellence…

Cependant, à la différence d’un produit standardisé élaboré dans l’industrie, le développement logiciel à sa part de variabilité et d’inconnue(s) qui demande des adaptations dans la mise en place d’un système qualité. L’agilité permet de maîtriser cette variabilité. Cependant si vous entrez dans cette « voie », vous êtes bien conscient qu’il faut changer vos habitudes !

En effet, vous aviez pris l’habitude de réserver beaucoup de temps à la qualité, après avoir développé le produit. Je me souviens encore, dans une de mes anciennes vies, ces (très) longues phases de recettes positionnées juste après la phase de développement.

Mais maintenant si vous utilisez des itérations courtes (de l’ordre de quelques jours) et que vous condensez, dans ce laps de temps, les activités de développement, de test et de livraison alors vous devrez changer votre organisation et la façon de faire les choses.

Vous devez atteindre un niveau de rigueur extrêmement élevé et la qualité doit faire partie du produit dès ses premières étapes de conception. Avec une approche agile, il est illusoire de contrôler la qualité une fois que vous aurez tout terminé. Vous n’aurez tout simplement pas le temps de réaliser cette tâche et vous retardez d’autant plus votre livraison de valeur.

Pour vous aider à atteindre cette excellence vous pouvez vous aider de techniques et de pratiques spécifiques au développement logiciel tout au long de la vie du produit. Certaines ont plus de 25 ans, d’autres sont plus récentes du fait des progrès technologiques mais elles servent toutes un but commun : maîtriser votre produit pour livrer au plus tôt de la valeur.

Cette maîtrise vous permettra d’obtenir la confiance de vos utilisateurs et diminuera sensiblement cette peur ou cette anxiété de l’inconnu lorsque vous lancerez des nouvelles fonctionnalités ou si vous devez vous adapter à un changement quelconque.

Ces pratiques peuvent être synthétisées par cette image :

Toutes ces pratiques vous permettront de gagner en qualité et en rapidité. Pour atteindre une qualité optimale, il faut réussir à maîtriser toutes ces pratiques.

Concernant la rapidité, même si cela à l’air contre intuitif, plus vous irez vite (à livrer des fonctionnalités), plus la qualité sera au rendez-vous car cela vous forcera à mettre en place des actions qui vous garantiront une stabilité optimale dans vos livraisons.[3]

Pour ne prendre qu’un seul exemple dans ce tableau j’irais plus dans le détail avec la pratique du TDD : Test Driven Development.

Certain compare le TDD avec un GPS[4] de voiture qui vous permet d’aller d’un point A à un point B alors que vous ne connaissez pas le chemin pour relier ces 2 points. Un GPS vous « guide » (driven) vers une destination. Et surtout, si vous vous trompez de route il vous dira de faire demi-tour immédiatement. Il teste à chaque croisement si vous êtes dans la bonne direction. Et surtout, il n’attend pas la fin du parcours pour vous dire que finalement vous n’êtes pas arrivé au bon endroit. Et bien le TDD c’est pareil, il vous guide vers la meilleure manière de coder un problème et il vous dit pas à pas si vous êtes toujours dans la bonne direction.

…Et retrouver la maîtrise de votre produit

D’autre, le compare à un « bouton magique »[5]. Un bouton, qui lorsque vous appuyer dessus, fait apparaître une lumière VERTE (ou ROUGE) pour vous dire que votre code est correct (ou non) par rapport à un comportement attendu (le résultat d’un test par exemple) et, surtout, ce bouton vous dit si vous n’avez rien cassé ailleurs. Magique non ? Et très pratique si vos développeurs héritent d’une application créée il y a de nombreuses années (cf. Legacy code).

Pour faire comprendre la pratique, vous pouvez donner un exercice, à des développeurs, un exercice très simple. Il consiste à coder un programme informatique qui compte les points lors d’une partie de bowling. Le cadre est simple. Les règles sont claires. Bien évidemment, il existe une multitude de chemin pour arriver au bon résultat. Mais une seule vous permettra de :

• Coder de manière incrémentale, petit PAS par petit PAS, pour arriver au résultat final.
• Chaque PAS sera validé de manière unitaire mais aussi testera continuellement tous les autres petits PAS que vous avez déjà réalisé précédemment.
• Il vous dira, ainsi, si un PAS précédant est encore valide ou non.
  • Si tout est vert, vous passez à la suite.
  • Sinon vous revenez en arrière sur ce que vous venez juste de faire sans remettre en cause ce qui a déjà était entrepris et qui été validé précédemment…Vous me suivez …
• And last but not least : le “design” de votre code, c’est-à-dire la manière dont ont émergé vos lignes de code, la façon dont il a été écrit, ainsi que le « jeu de test » accolé à ce code, qui permet de valider chaque étape, permettra à n’importe qui de reprendre vos travaux sans difficulté et ce même plusieurs années après l’avoir rédigé.
• Et ne je ne parle même pas de la robustesse de votre code.

Toutes ces pratiques ne s’improvisent pas. Il faut beaucoup d’entraînement pour arriver à un résultat optimal. Le chemin sera long et compliqué. Vous voudrez abandonner et tout laisser tomber car les premiers résultats ne seront pas forcément au rendez-vous.

Mais gardez en tête l’objectif principal de l’utilisation de toutes ces pratiques : atteindre un niveau de QUALITE qui vous permet de (RE) MAITRISER ce que vous entreprenez et donc que votre produit apporte le maximum de valeur à vos utilisateurs.

Franck Arsene, Consultant Senior Agilité à l’échelle

Découvrez nos formations en agilité : Nos Formations Agile « made in Inspearit » | Inspearit France

Et nos formations officielles SAFe : Nos formations Safe & Agile@Scale | Inspearit France

[1] Robert C. Martin : How TDD is related to the quality of code (fearless competence part : 0’00’’ à 1’15’’)

[2] Agile manifesto : Principe n°9 “Continuous attention to technical excellence and good design enhances agility”

Scrum Guide 2021 p.6/8/10/12;

SAFe : Agile framework safe core values et Scaled Agile Framework built In quality

[3] Rapport Accelerate sur l’état du DevOps en 2021

[4] Michaël Azerhad

[5] Robert C. Martin