— Midi dix : c’était rapide, pour une fois, ta rétro.
— Oui, 2 dévs sont en vacances, donc on a été un peu plus vite.

— En effet.
— Toi qui milites pour les tests, sois content : on vient de prendre une décision importante. À partir de maintenant, tests auto. obligatoires sur chaque story. C’est dans la DoD.
— OK…
— Tu comprends, on a eu trop de 💩 en prod’. JM veut un changement.
— Euh, c’est qui JM déjà ?
— Le sponsor. Il a eu une longue discussion avec la PO et le Tech Lead. Dis tu aurais un tuto à me conseiller sur BDD ?
— BDD ?
— Behavior Driven Development. C’est ce qu’on va utiliser pour les tests.
— Ouais, mais… Vous n’aviez pas déjà décidé en début de projet d’écrire des tests systématiquement sur tout le code de production ?
— Hein ? Ah oui. Tu veux dire les tests unitaires. On laisse tomber les TUs.
— Ah bon ?
— Ça prend trop de temps, ce n’est pas rentable. Et en plus ça remet le design en question. Déjà, dans l’équipe on n’était plus que 3 à en écrire, et encore, pas sur tout le code.
— …
— Quoi ? Tu penses que ça ne va pas marcher ?
— Euh, je ne suis pas devin.
— N’empêche : tu n’as pas l’air convaincu. Tu connais BDD au moins ?
— Ce n’est pas BDD le problème. C’est l’amélioration continue.
— C’est à dire ?
— Tu te rapelles mon exemple de la dernière fois ? La patinette électrique ?
— Vaguement…
— Disons que vous étiez en train d’apprendre à faire du roller. Avec plus ou moins de succès…
— Clairement les TUs ça ne marche pas.
— Alors maintenant vous essayez le scooter.
— Oui ! C’est plus rapide !
— Mais ça ne s’utilise pas dans les mêmes conditions.
— Certes. Mais toi qui est si malin : comment tu ferais avec ton équipe ?
— On ne ferait pas les changements de cette façon. On suit un cycle PDCA.
— Un cycle quoi ?
— Plan → Do → Check → Act :

📐 Plan : observer, comprendre le problème en vue de définir une expérimentation. Qu’est-ce qui varie dans la qualité du produit ? Pourquoi ? D’où vient le problème ? Si une technique permet d’en venir à bout et qu’on décide de l’essayer, à quoi saura-t’on qu’elle fonctionne ? Avec quelle mesure ? Au bout de combien de temps ?

— Rien ne te dit qu’on ne s’est pas posé toutes ces questions, mais admettons.
— Ensuite :

🧑🏽‍💻 Do : expérimenter la technique, confronter la solution théorique à la réalité du terrain, en notant ce qui marche et ce qui ne marche pas.

— Ok, BDD, on l’a pas encore essayé mais justement, c’est parti : on va essayer.
— En ayant déjà validé le changement avec le Sponsor ? Vous mettez la charrue avant les bœufs…
— Qu’est-ce tu veux, c’est comme ça que ça marche ici.
— 3ème étape :

🔎 Check : débriefer l’expérimentation, en vérifiant si nos prédictions sont justes ou à côté, et de combien.

— Pour ça il y a la prochaine rétro.
— Dans 2 semaines ?
— …
— et enfin :

📝 Act : valider (ou pas) la technique, et l’ajouter au standard. P,D,C,A.

— Bon. C’est ce qu’on fait, en gros.
— Non. En gros vous faites A,C : Act → Check.
— 🤷‍♂️

publié sur Linked In le 11/05/2023