L’Example Mapping, la pratique agile la plus sous-estimée
On l'a tous vécu, en tant que développeurs : le Product Manager (PM) vous confie une User Story dont l'énoncé tient en une ligne, "parce que c'est évident". Ah bon, ben si c'est évident, allons-y. Évidemment, vos neurones se connectent avant la première ligne de code et là, rien n'est plus évident. Des cas-limites en veux-tu en voilà, des trous dans la raquette et, à bien y regarder, une fois sur deux, une User Story qui n'a aucun sens in the first place.
On réfléchit mieux à plusieurs
Est-ce à dire que le PM est mauvais ? Non. Est-ce à dire que le PM a mal travaillé ? Oui, parce qu'il (ou elle) a travaillé seul. À plusieurs, on réfléchit mieux que seul. Ainsi, la conception n'est pas l'affaire du seul PM. Il en a la responsabilité, certes, mais la conception fonctionnelle est aussi l'affaire des développeurs. On ne le dira jamais assez : un bon développeur est, entre autres, un fin connaisseur du métier. Et avant cela, pour bien développer, il est important de comprendre ce qu'on cherche à développer, et pourquoi on veut le développer. Permettre aux développeurs de s'impliquer sur la conception fonctionnelle, c'est faire émerger bien plus rapidement toute la contradiction dont vous avez besoin.
Partant de ce principe, l'Example Mapping, introduit en 2015 par Matt Wynne, propose justement de mettre autour de la table les différents profils impliqués dans le développement d'une User Story : PM, Dev et QA. Même si la pratique ne garantit pas une conception fonctionnelle parfaite – elle pourrait être modifiée à la marge, l'Example Mapping évite tout de même bien des allers-retours en phase de développement, de recette ou, plus coûteux encore, une fois l'incrément logiciel en production. Disons que votre conception sera bonne à 90% plutôt qu'à 20% sans Example Mapping.
Travailler sur des exemples
Pour cela, l'Example Mapping nous invite à travailler sur des exemples. Nous avons la fâcheuse tendance à raisonner de manière abstraite, ce qui est hasardeux, parce que les abstractions que nous manipulons sont rarement bien définies. Dire que Jean-Luc Mélanchon et Olivier Faure sont de gauche est probablement vrai, mais dans les faits, ils seront rarement d'accord. Il y a gauche et gauche.
Les exemples permettent donc d'éprouver les règles de gestion et d'appréhender toute la complexité du sujet. Un exemple, justement : que signifie additionner des fractions ?
1/3 + 1/3 = 2/31/2 + 1/3 = 5/61/2 + 1/2 = 1/1Ah, et puis il y a le cas
1/0Enfin, ces exemples constituent autant de tests d'acceptation. Pour un développeur souhaitant tester ses développements, la première difficulté est de savoir quelles valeurs choisir, même pour un test manuel. Très probablement, je ne prendrai pas les mêmes valeurs que celles du PM, si bien que je livrerai en toute bonne foi des développements dont il trouvera peut-être qu'ils ne fonctionnent pas. Ces exemples, ces tests peuvent donc être vus comme un contrat liant le PM au développeur. Un contrat qui fait partie intégrante de la Definition of Done.
4 couleurs pour structurer la discussion
Le formalisme de l'Example Mapping est basé sur 4 couleurs :
- Jaune 🟡 : la User Story qui est l'objet de la session ;
- Bleu 🔵 : les règles de gestion ;
- Vert 🟢 : les exemples (a priori plusieurs par règle) ;
- Rouge 🔴 : les questions sans réponse immédiate.
Vous pouvez découvrir le sujet comme bon vous semble, en commençant soit par les règles, soit par les exemples. À la fin, il vous faudra de toute façon les deux :
- Une règle ne vaut rien tant qu'elle n'a pas été éprouvée par des exemples : sans exemple, il est probable que des incompréhensions majeures subsistent, et vous aurez besoin d'exemples/tests pour pouvoir valider les développements.
- Un exemple seul ne vaut rien, car sur base d'un exemple, on pourrait inférer plusieurs règles (que déduire par exemple de
? La fonctionf(1, 1) = 1
est-elle une multiplication ? une division ? autre chose ?)f
Un outil qui vous offre du feedback rapide
L'Example Mapping nous offre un feedback visuel immédiat, utile pour mener l'atelier efficacement :
- Trop de Rouge 🔴 : le sujet n'est pas mûr, vous risquez de développer des choses à côté de la plaque, il est urgent d'attendre ;
- Trop de Vert 🟢 : il faut passer à l'abstraction, une succession d'exemples ne remplaçant pas une règle ;
- Trop de Bleu 🔵 : vous êtes dans la théorie pure, vous pensez vous comprendre, mais rien n'est moins certain. Prenez des exemples, pour éprouver vos règles de gestion et faire probablement émerger de nombreux cas limites.
Et beaucoup de jaune ? Cela signifie que vous avez bien travaillé, en remettant à plus tard tous les sujets à l'exception d'un seul, l'objet du prochain développement. Car oui, l'Example Mapping est tout à la fois un outil de conception, de découpage et de priorisation. Ces activités sont indissociables.
Conclusion
L'Example Mapping est une pratique concrète et actionnable de l'Agilité . Plutôt que de vous échiner à vouloir faire des sprints qui, même bien menés, demeurent d'un intérêt contestable, investissez dans cette pratique concrète et simple à mettre en œuvre, elle vous aidera à coup sûr.
Car à bien y regarder, la discovery et la conception fonctionnelle sont à l'entrée du flux de production logiciel. Réussir cette étape n'est pas une garantie de succès en bout de chaîne (condition non suffisante), en revanche elle reste nécessaire.
Autrement dit : 💩 in ➡️ 💩 out.