🚉🏗🏭🏦🧪📺🏢 → 👨‍💻

Dans mon travail, depuis des années je traite des besoins Métier. Certes avec l’arrivée des approches agiles il y a 25 ans, la démarche de “recueil des besoins” s’est métamorphosée (et heureusement). Mais la direction de “l’expression de besoins” n’a pas changé :

≃ 1990 : Expression de Besoins → Analyse → Réalisation

≃ 1998 : Client sur Site → Scénarios Utilisateurs → Réalisation

≃ 2005 : Story Mapping → Scénarios Utilisateurs → Réalisation

≃ 2013 : Event Storming → Scénarios Utilisateurs → Réalisation

Ce flot d’information du Métier vers la Technique est cohérent avec le modèle “Développement = Production” : d’abord on conçoit, puis on réalise.

Il y a eu dans le passé des méthodes entièrement câblées sur ce schéma, comme Merise par exemple :

≃ 1985 : Modèle Conceptuel → Modèle Organisationnel → Modèle Logique → Modèle Physique → Système Informatique

Vu depuis un modèle de type production, cette cascade tombe sous le sens : le système informatique (en gros, l’infrastructure, les liaisons, les données, et le code) met en œuvre une logique qui est au service de l’organisation telle qu’elle est conçue au niveau fonctionnel Métier.

(Dans ce modèle, on pourrait voir aussi le conceptuel Métier qui vient informer la matière Technique. Quand nous avons “l’idéation” d’un côté et de l’autre les “mains dans le cambouis”, nous nous faisons les dignes héritiers d’Aristote…) 🏺

Adoptons pour un temps un modèle de traduction : développer c’est traduire des idées formant un système pour certains acteurs en idées qui en forment un autre pour d’autres acteurs. Ces traductions relèvent de processus imbriqués, multiples et réciproques. Le système ainsi créé restera utile, fiable et stable tant que les traductions peuvent avoir lieu.

Dit plus simplement : un logiciel garde (ou augmente) sa valeur tant que sa conception reste vivante.

Dans ce modèle, la notion de besoin a toujours un sens, mais à condition de l’appliquer dans tous les sens, justement : il y a les besoins de l’acteur Métier, et ceux de la Technique, ainsi que ceux du Management.

Par conséquent, notre PO qui déclarait lundi matin :

— Les features d’abord, pas de refactoring. Vous vous ferez plaisir après la mise en prod.

se trompait d’interlocuteur : si les fonctionnalités émanent bien de son besoin Métier, en revanche le refactoring répond aux besoins du Management et non de la Technique.

En effet le Management a pour objectif de préserver les conditions optimales dans lesquelles le système peut évoluer. Les refactorings (un renommage, une extraction de méthode par ex.), ont justement pour but de faciliter un changement de la conception.

Et le besoin de la Technique au fait ? C’est d’abord d’apprendre. Le refactoring est certes lié à ce besoin également, mais pas de façon indissociable. Le monde est rempli de code pas ou très peu refactoré, et la Technique s’en porte très bien.

publié sur LinkedIn le 14/03/2023