Par exemple ?

On l'a tous vécu, en tant que développeurs : le PM (Product Manager) 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à, ça n'est plus évident du tout. Des cas-limites en veux-tu en voilà, des trous dans la raquette et, à bien y regarder, parfois, une fois sur deux, une user story qui n'a aucun sens "in the first place".

Est-ce à dire que le PM est mauvais ? Non. Est-ce à dire que le PM a mal travaillé ? Oui, parce qu'il (ou elle d'ailleurs) a travaillé seul. À plusieurs, on réfléchit mieux que seul. L'example mapping, que nous allons voir juste après, est une occasion unique de faire de la "shared discovery".

De là nous déduisons sans plus attendre que la conception n'est pas l'affaire du seul PM. Il en a la responsabilité, certes, mais elle implique les développeurs. On ne le dira jamais assez : un bon développeur est, entre autres, un fin connaisseur du métier.

L'example mapping, donc, nous invite à travailler sur des exemples, du concret. En effet, nous avons la fâcheuse tendance à raisonner de manière abstraite, ce qui ne serait pas un problème si les abstractions que nous manipulons étaient parfaitement définies. Or c'est rarement le cas : dire que Jean-Luc Mélanchon et Dominique Strauss-Kahn sont de gauche est peut-être vrai, mais dans les faits, ils seront rarement d'accord.

Les exemples sont nécessaires en ce qu'ils permettent d'éprouver les règles de gestion. Un exemple, justement : que signifie additionner des fractions ? 1/3 + 1/3 = 2/3, c'est OK : je peux découper un gâteau en 3 parts égales et prendre 2 parts. Mais 1/2 + 1/3 = 5/6, c'est déjà autre chose. Et 1/2 + 1/2 = 1/1 c'est encore autre chose.

Ah, et puis il y a le cas 1/0, que l'on ne devrait même pas pouvoir écrire. Le fait de choisir de vraies valeurs – par opposition à des variables, telles que "numérateur" ou "dénominateur" — fait tout de suite émerger des cas-limites.

Enfin, ces exemples constituent autant de tests d'acceptation, et ça c'est essentiel. À supposer que j'aie une conscience professionnelle et sois disposé à tester mes développements, je ne sais malheureusement pas toujours quelles valeurs choisir. Très probablement, je ne prendrai pas les mêmes que celles du PM, si bien que je livrerai en toute bonne foi des développements dont il trouvera qu'ils ne fonctionnent pas. Ces tests peuvent être vus comme un contrat entre PM et dev, contrat dont le respect évite bien des allers-retours ➡️ Definition of Done.

Le formalisme de l'example mapping est basé sur 4 couleurs : 🟡 (la user story sur laquelle on travaille), 🔵 (règles), 🟢 (exemples) et 🔴 (questions sans réponse immédiate). Il offre un feedback visuel immédiat :

• Trop de 🟢 : il faut passer à l'abstraction (ça n'arrive jamais) ;
• Trop de 🔵 : dans "example mapping" il y a… il y a… ? "exemples", oui ;
• Trop de 🔴 : le sujet n'est pas mûr, il est urgent d'attendre.

Et trop de 🟡 ? Cela signifie que vous avez bien bossé, en remettant à plus tard tous les sujets à l'exception d'un seul, sur lequel vous êtes en train de travailler. Oui, vous découvrez ce faisant que l'example mapping est tout à la fois un outil de conception, de découpage et de priorisation.

L'example mapping est un outil que j'apprécie particulièrement tant il est simple, concret et utile. Je ne compte plus les équipes que j'ai "débloquées" grâce à lui. Pas étonnant si l'on considère que la conception fonctionnelle est à l'entrée du flux de production d'un incrément logiciel.

Autrement dit : 💩 in ➡️ 💩 out.