Cet article fait partie d’un groupe d’articles visant à bien préparer le backlog du premier sprint d'un projet avant de commencer à développer. C’est le premier article de la série :) Bonne lecture !

Quand on a un nouveau projet en tête, on peut se retrouver dans deux situations extrêmes :

on se lance tête la première dans notre IDE et on code tout de suite, sans trop savoir par où commencer
on se pose des semaines afin de préparer tout en amont pour qu’il n’y ait plus qu’à développer une fois tout le projet mis sur papier.

Évidemment, il existe une infinité de nuances entre ses deux extrêmes.

C’est pourquoi je vais vous proposer une méthodologie que j’applique qui permet de mettre rapidement le pied à l’étrier, tout en réfléchissant un minimum en amont, pour finalement optimiser le feedback tout au long du processus.

Nous allons ainsi voir au cours des prochaines semaines :

Comment dégrossir son projet et comprendre le domaine métier grâce au Domain Storytelling
Comment établir une liste des fonctionnalités pour un premier MVP grâce au User-Story Mapping
Comment découper verticalement ces user-stories pour livrer le plus souvent possible, et se passer d’estimations
Comment définir les critères d’acceptation de nos user-stories grâce à l’Example Mapping
(Et la suite ça se passera en vidéos en TDD 🤐🙊)

Tout un programme !

On commence donc cette semaine par le Domain Storytelling !

Qu’est-ce que le Domain Storytelling ?

Le Domain Storytelling est une technique de modélisation collaborative de la façon dont les gens travaillent ensemble. L’objectif principal est de transformer cette connaissance en logiciel.

Cet atelier s’inscrit dans la mouvance des ateliers de brainstorming, ou de “knowledge crunching” comme le User-Story Mapping ou l’EventStorming par exemple.

Il est à ce sens complémentaire de ces ateliers, comme nous les verrons dans les prochaines semaines.

L’intérêt principal de cet atelier, lorsque l’on commence un projet, est d’établir un langage commun entre les parties prenantes : les développeurs, le product owner, les responsables métiers, etc. Bref : limiter les quiproquos en mettant en évidence les notions et termes clés.

Le vecteur de connaissances ici, comme son nom l’indique, est le “storytelling”. On va littéralement raconter l’histoire des “acteurs” de notre produit.

Pour Stefan Hofer et Henning Schwentner, les auteurs du livre Domain Storytelling : Collaborative Modeling for Agile and Domain-Driven Design, raconter et écouter ces “histoires” aide à :

… comprendre le domaine métier
… établir un langage partagé entre le métier et l’IT
… parler des besoins fonctionnels
… implémenter le bon logiciel
… structurer correctement le logiciel
… architecturer des process métiers viables à long terme

Les 3 éléments du Domain Storytelling

Le Domain Storytelling se base sur des schémas très simples, à base de pictogrammes.

Nous allons avoir besoin de trois types de pictogramme :

Les Actors

Les Domain Stories sont racontées depuis le point de vue d’un “acteur”. Cela peut dont être une personne ou un système externe par exemple.

Les Work Objects

Les “actors” crées, travaillent avec, échangent des “work objects” comme des documents ou des objets physiques ou digitaux par exemple.

Les Activities

Les “activities” correspondent aux actions des acteurs et sont représentées sous forme de flèches.

Les Actors et les Work Objects sont donc des noms, alors que les Activities sont des verbes.

Le tout crée ainsi une séquence, lisible, sans jargon technique.

Pour comprendre, laissez-moi vous présenter le miniprojet qui servira de support aux articles de cette série.

CraftOverflow

Comme son nom le laisse supposer, CraftOverflow est une copie de StackOverflow. En infiniment plus simple évidemment.

Nous allons nous concentrer sur deux fonctionnalités principales :

trouver une réponse à une question que l’on se pose
poser une question en espérant obtenir une réponse des autres utilisateurs

Voyons comment nous pourrions raconter ces “Domain Stories”.

Trouver la réponse à une question

Première étape : positionner l’acteur de notre Domain Story. Ici, c’est un-e développeur-euse.

J’ajoute une note à côté pour indiquer que c’est un développeur déjà inscrit, même si pour ce scénario précis ce n’est pas forcément pertinent, c’est simplement pour vous montrer qu’il est recommandé d’ajouter des annotations de ce genre.

À partir de cet acteur, nous allons dérouler plusieurs séquences d’actions, qui vont donc former notre Domain Story.

Ces séquences vont être numérotées, afin de pouvoir les relire dans l’ordre chronologique et ainsi “raconter” l’histoire.

Qu’est-ce que fait un développeur arrivant sur CraftOverflow pour trouver la réponse à sa question ? Eh bien il va tout simplement consulter cette question :

Avec cette première séquence, en partant de l’acteur, on peut donc lire :

“dev consulte une question dans la liste des questions”

Comme vous pouvez le voir, le but ici n’est pas de rentrer dans les détails. On commence par dégrossir.

Ce qui peut ressembler à un exemple trivial et donc futile nous a tout de même permis de poser le terme “question”. Cela peut paraître bête, mais c’est un concept fondamental de CraftOverflow, et différents développeurs auraient pu lui trouver un nom différent, comme “post” ou “thread” par exemple.

Continuons avec la deuxième séquence :

Un nouveau “work object” fait son apparition : la réponse.

La nouvelle séquence se lit donc :

“dev consulte la réponse à la question”

Voyons maintenant la dernière séquence :

Encore un nouveau “work object”, le vote !

Nous avons terminé notre première Domain Story que l’on pourrait intituler : “Trouver la réponse à une question”.

Le périmètre de cette Story est volontairement très large, l’idée est de rapidement dégrossir une fonctionnalité pour faire naitre un langage commun en racontant une histoire.

Voyez plutôt :

“dev consulte une question dans la liste des questions”
“dev consulte la réponse à la question”
“dev exprime son accord avec la réponse grâce à son vote”

C’est une Domain Story très claire n’est-ce pas ? Et nous avons créé un premier lexique des termes importants de notre domaine : question, réponse, vote.

Voyons la prochaine fonctionnalité :

Poser une question afin d'obtenir une réponse

Maintenant que vous connaissez le principe, ça va être plus rapide :

“Dev rédige une question depuis l’éditeur de texte”

“Dev ajoute des tags sur la question depuis la liste des tags”

“Dev soumet sa question dans la liste des questions”

Avec cette deuxième Domain Story, le lexique s’est agrandi des termes : éditeur de texte, tags, liste des tags

Plusieurs niveaux de granularités

Le fait d’avoir raconté ces deux Domain Stories de façon grossière nous a permis de sortir du syndrome de la feuille blanche.

Ce genre d’atelier se fait normalement avec toutes les personnes concernées par le projet, mais c’est un exercice qu’il est intéressant de pouvoir faire seul aussi lorsqu’on démarre un nouveau projet. A fortiori quand on ne sait pas par où commencer.

Cependant, cela reste un peu “léger” pour concrètement remplir notre premier backlog.

Pour remédier à cela, nous pouvons “zoomer” pour obtenir un niveau de granularité plus fin.

Pour la première fonctionnalité, on pourrait ainsi se retrouver avec cette nouvelle Domain Story, plus détaillée (cliquez sur l’image pour l’afficher en plus gros) :

On peut ainsi “raconter” cette Domain Story de la sorte :

“dev consulte la liste des tags pour y trouver un tag”
“dev sélectionne un tag pour consulter la liste des questions (triées de la plus récente à la plus ancienne pour ce tag)”
“dev réordonne la liste des questions par votes (triées de la plus votée à la moins votée)”
“dev sélectionne une question pour consulter les réponses”
“dev exprime son désaccord sur une réponse par un vote down”
“dev exprime son accord avec la réponse par un vote up”

En zoomant ainsi on obtient une histoire bien plus complète, et nous avons au passage fait naître la nuance au sein du mot “vote” entre vote down et vote up.

Quand vous démarrez un nouveau projet, je vous encourage vraiment à prendre 1h ou 2h de votre temps pour faire cet exercice. Ça vous sera extrêmement bénéfique !

Nous verrons la semaine prochaine comment faire un atelier de User Story Mapping à partir de ce résultat :)

En attendant, Happy Coding !

[1/4] - Comment bien démarrer un projet : la…

Create your profile

Only paying subscribers can comment on this post

Check your email