Alors que la revue commence, un portable sonne bruyamment.

— Oups, pardon.

Dans la salle de réunion, 4 autres participants vérifient leur portable. 2 d’entre eux le mettent en sourdine.

⚙️

Vers le milieu de la revue :

— C’est intéressant : jusqu’ici sur ce legacy on avait d’un côté le code de production, de l’autre, un word expliquant comment il fonctionne…
— Oui, alors, “expliquant” : très vaguement, et surtout, pas à jour.
— Expliquant vaguement comment il a fonctionné dans le passé.
— Voilà.
— Maintenant, c’est à dire, à partir du moment où tu as réussi à mettre au point ce script de tests, et vu qu’on va l’adjoindre au repository, on a quelque chose de plus.
— Je ne vois pas.
— On a d’un côté, le code de prod, et de l’autre du code de test, précis, à jour, correct, qui nous parle du code de prod. On est mieux !
— Correct ? Ce n’est pas sûr. Excuse-moi, mais si le code de test est faux, on n’est pas mieux.
— On n’est pas mieux qu’avec un pauvre doc word vague et pas à jour ?
— Non. On a juste pris plus de temps à écrire des tests.
— Donc, parce que des tests autovérifiants peuvent à l’occasion comporter une erreur de test, ils valent moins que ce doc ?
— Un test cassé, ça se répare. Un doc pas à jour…
— Faut reconnaître.

⚙️

Fin de revue :

— Donc : module OK pour aller en prod. Et on ajoute le script de test dans le repo.
— Est-ce qu’on pourrait aussi acter le procédé de test dans l’ADR (suivi des décisions) ?
— Qu’est-ce que tu voudrais acter ?
— On reprend ton code de test, et on en fait un exemple simple de script avec le même tooling.
— Pourquoi pas.
— Et je propose qu’on l’ajoute au standard.
— Tu ne veux pas qu’on voie si c’est applicable partout, d’abord ?
— Je propose qu’on l’applique, avec exceptions documentées.
— Plus un.
— Go.
— Ça me va.
— Non.
— Qu’est-ce qu’il faudrait ajouter pour que tu sois d’accord ?
— Il faudrait se former sur l’outil avant de le mettre au standard.
— Ok… Je propose qu’on fasse une session pour s’améliorer sur l’outil, et ensuite on acte.
— Ok.

⚙️

Cette équipe part de loin (premier test auto en 7 ans de production) mais une force l’aide à s’améliorer en continu : elle utilise des cliquets.

Un cliquet est un mécanisme qui maintient un système en l’état, ou plus généralement l’empêche de revenir en arrière et le force à avancer. (Wikipedia)

⚙️ la 1ère sonnerie de portable “vaccine” le groupe contre les futures sonneries durant la réunion
⚙️ chaque nouveau test auto-vérifiant sécurise un peu plus le code existant contre les régressions
⚙️ chaque revue de code améliore le standard
⚙️ le processus de décision de l’équipe consiste à raffiner la décision proposée au lieu de la contrecarrer

La force que cela procure à leur système vient de l’effet cliquet :

  • aller dans un sens demande peu de mouvement et donc d’énergie
  • pour aller dans le sens contraire, il faut “casser” le cliquet ce qui demande une énergie plus importante.

Quels sont vos “cliquets” ?

publié sur LinkedIn le 20/04/2023