Accueil Nos publications Blog Workshop «Modelling Heuristics» à DDD Europe 2017

Workshop «Modelling Heuristics» à DDD Europe 2017

Lors de l’évènement Domain Driven Design Europe, j’ai eu le plaisir d’assister au workshop «Modelling Heuristics» animé par Mathias Verraes.
Certains pensent qu’il faut avoir un talent inné pour faire de bonnes modélisations, Mathias et les participants à son workshop sont convaincus du contraire.

Cependant, il faut reconnaitre qu’il est souvent difficile d’expliquer pourquoi nous avons fait/choisi un design en particulier plutôt qu’un autre. Ce qui a guidé notre choix est souvent un ressenti, une habitude liée à notre expérience ou un comportement que l’on a acquis au fil des années.

Ces aides ne sont en rien des règles absolues. Il est possible qu’elles fonctionnent admirablement bien dans certains cas et s’effondrent misérablement dans d’autres cas.
Il s’agit là de ce que l’on appelle des heuristiques.

Le but du workshop était de mettre en commun les heuristiques que nous utilisons lorsque nous modélisons (les «Modelling Heuristics»). Pour cela, nous avons noté au fur et à mesure les heuristiques évoquées.
Nous avons donc commencé par partager celles auxquelles nous pensions dans un format de table ronde. Ce simple échange a déjà produit, à lui seul près des 30 premiers points.
Nous avons ensuite alterné entre séances de modélisation et échanges. Nous avons notamment fait un event storming ainsi qu’un context mapping.
Lors des séances de modélisation, un petit groupe de personnes ne prenait pas part aux échanges et avait pour rôle d’observer ceux qui modélisent. Cela a permis de noter les heuristiques utilisées par certains alors qu’ils n’en avaient pas conscience.

Au final, le groupe aura noté 63 heuristiques :










Je vais ici détailler quelques heuristiques qui m’ont particulièrement plu ou marqué.

1) «Make the implicit explicit» : Il s’agit là d’un des motos du Domain Driven Design. Il est fréquent que certaines choses paraissent évidentes au métier mais pas du tout aux dévelopeurs et inversement. Forcer l’expression de ces choses permet très souvent d’identifier des incompréhensions qui auraient eu un impact fort et néfaste au design. En bref : il n’y a pas de questions stupides.

7) «Model it wrong» : l’idée ici est d’arriver à faire parler la personne qui sait sans particulièrement oser le dire. En montrant un modèle que l’on sait faux à cette personne, il y a de forte chance que le modèle soit corrigé et que l’on gagne alors beaucoup d’informations à forte valeur.

17) «Find 3 different ways to solve the problem» : le but est de ne pas s’arrêter à la première solution que l’on trouve mais de se forcer à trouver d’autres solutions afin d’être certain d’avoir fait de notre mieux au moment où l’on prend une décision. Même dans le cas où le premier modèle est le bon, en faire d’autres nous permet de le valider.

24) «How can I sabotage it ?» : si l’on retire quelque chose qui nous semble essentiel, que deviendrait le modèle ? que resterait-il ? Est-ce toujours cohérent ?

30) «Avoid upfront consensus» : le but ici est de tout faire pour ne pas s’arrêter à la première solution qui semble correct. Un brainstorming bien mené permet souvent d’éviter de tomber dans ce piège.

37) «Change order of events» : que se passe-t-il si un utilisateur essaie d’acheter un produit pendant qu’un administrateur essaie de le retirer de la vente ? Changer l’ordre des événements peut donner différentes solutions et générer des conversations à forte valeur.

48) «Personas and scenario» : il s’agit là d’une technique bien connue aux pratiquants du BDD. Les participants imaginent, de manière assez détaillée, des personnes (aka personas). Il est ensuite possible de choisir l’un de ces personas et d’imaginer son interaction avec le système.

55) «Retrospect» : les rétrospectives utilisées dans le monde agile ont aussi beaucoup de valeur lors de la modélisation en groupe. Il s’agit alors de prendre quelques minutes régulièrement pour répondre à la question «Comment pouvons-nous être plus efficaces ensemble ?»

En conclusion, ce workshop a été très riche en idées et nous a permis à tous de prendre conscience de nos heuristiques de modélisation. Nous sommes tous ressortis de cet évènement avec plus d’outils que quand nous y sommes arrivés.

Crédits photos © Mathias Verraes et Romeu Mourra

© SOAT
Toute reproduction interdite sans autorisation de la société SOAT