🏷 Patterns et Conflits ⚔️

À propos de mon exemple d’hier :

prixTTC = prixHT * 1.20 partout dans le code,

j’ai un peu simplifié le “technical debt item”, parce que le propos n’est pas de faire de la technique.

En revanche :

“Pas de refactorings dans ce sprint : vous vous ferez plaisir après la mise en prod.”

est une phrase qu’a réellement prononcé un PO dans un projet. Lorsque je l’ai entendue ma première réaction était de revenir à mes définitions. C’est une réaction typique que j’ai lorsque je détecte un conflit. J’ai beau dire, comme tous les agilistes :

📜

Les individus et leurs interactions, de préférence aux processus et aux outils

📜

il reste qu’en cas de conflit, je refais toujours un petit tour du côté des processus et des outils, en mode “qu’est-ce qu’on s’était dit, déjà”. Détail intéressant : la plupart du temps “ce qu’on s’était dit”, on ne se l’était pas dit, ces définitions ne sont pas partagées, et je fais des projections. C’est à dire que je navigue dans le monde, et en l’occurrence dans ce conflit, avec ma propre carte, qui n’est pas nécessairement la même que celles de mes interlocuteurs.

Où ça, un conflit ?

C’est un conflit d’idées (ouf!) et aussi un conflit d’objectifs (mais je classe les objectifs et les intérêts comme des idées ici) :

🏷 Merciless Refactoring : règle de travail consistant à modifier le code d’un programme afin d’en améliorer la facilité d’évolution, sans modifier son comportement, dès que le besoin s’en fait sentir

⚔️

🏷 Product Owner : rôle définissant les responsabilités et prérogatives liées à la traduction en application, des idées élaborées avec le Métier

NB: dans le Guide Scrum la définition du PO est légèrement différente :

🔖 Le Product Owner est redevable de maximiser la valeur du produit résultant du travail de la Scrum Team.

cependant je préfère ma définition car cette dernière fait référence à une activité de traduction et non de production. (Comme je l’ai dit, je navigue avec mes cartes 🤓)

La règle Merciless Refactoring sert à lutter efficacement contre une forme de dette technique, par détection et résolution rapide des “Code Smells”. 💩

Bien sûr et comme toujours, le conflit d’idées repose sur un conflit de ressources fondamental auquel pas un projet n’échappe :

Quantité de tâches à réaliser

⚔️

Temps alloué pour les tâches à réaliser

La Tech voudrait améliorer la maintenabilité du code pendant qu’il en est encore temps, mais aussi respecter les prérogatives de l’acteur Métier. Elle fait une brèche à l’état de l’art, en passant de “Merciless Refactoring” à “Permission to Refactor”.

Le Métier voudrait atteindre l’objectif de livraison, en sacrifiant temporairement la maintenabilité. Il fait une brèche à l’état de l’art en décidant à la place de la Technique de ce qui est bon pour le code à l’instant t.

Que décider ?

publié sur LinkedIn le 10/03/2023