Est-ce que le Behavior Driven Developpment est indispensable ? Pas forcément si on réduit son champ d’action au seul langage Gherkin pour tester et automatiser !
Dans le cas où une équipe n’est pas encore rodée au vrai BDD et qu’ils n’ont pas encore l’habitude de se challenger et de travailler vraiment ensemble, il faut, comme pour l’immobilier, prendre en compte 3 critères important :
🎯Collaborer,
🎯Collaborer,
🎯Collaborer
Et donc utiliser tous les moyens à votre disposition comme un atelier 3 amigos ou de l’Example Mapping !
Les origines de l’example mapping
L’example mapping a été développé par Matt Wynne en 2015, expert en BDD, dans le but d’améliorer la collaboration entre les membres de l’équipe et de garantir que les exigences métier sont claires et sans ambiguïté pour créer de la valeur. Il a constaté que de nombreux projets de développement échouaient en raison d’une mauvaise communication entre les différentes parties prenantes, conduisant à des fonctionnalités mal définies ou mal comprises.
Dans le monde du développement logiciel, la compréhension des besoins métier est essentielle pour créer des produits de qualité. Cependant, il est souvent difficile d’avoir une vision claire et partagée entre les membres de l’équipe. C’est là qu’intervient l’example mapping, un qui favorise la collaboration, la compréhension commune et sert de base solide dans la phase de découverte et de compréhension approfondie des besoins métier.
Les bénéfices de l’example mapping
L’example mapping présente de nombreux avantages pour les équipes de développement, notamment :
- Collaboration renforcée : L’example mapping favorise l’implication de toutes les parties prenantes, en encourageant la conversation et la collaboration. Les membres de l’équipe, souvent appelés les « 3 amigos » (développeur, testeur, et représentant métier), travaillent ensemble pour affiner les besoins métier et challenger les idées.
- Compréhension commune : En utilisant des exemples concrets pour illustrer les règles métier, l’example mapping permet à toute l’équipe de partager une compréhension commune des exigences. Cela réduit les risques d’interprétation erronée et les malentendus.
- Identification précoce des lacunes : Lors de la création des exemples, il est possible de détecter rapidement les cas manquants ou les règles mal définies. Cela permet de combler les lacunes dès le début du processus, ce qui conduit à des spécifications plus complètes et précises.
Comment mettre en place l’example mapping dans mon équipe ?
L’example mapping se déroule généralement en suivant ces étapes :
- Noter la User Story (US) : Commencez par écrire la User Story sur un post-it. Cela sert de point de départ pour la discussion et la création de la carte des exemples.
- Ajouter les critères d’acceptation et les règles connues : Ensuite, identifiez les critères d’acceptation et les règles métier connues liées à la User Story. Écrivez-les également sur des post-it distincts et placez-les à côté de la User Story.
- Ajouter les exemples : Pour chaque règle métier, ajoutez différents exemples concrets qui illustrent cette règle. Utilisez des post-it supplémentaires pour chaque exemple. Cela permet de visualiser les différentes situations auxquelles la fonctionnalité doit répondre.
- Noter les questions : Tout au long de la discussion, des questions peuvent survenir. Notez-les sur des post-it séparés et placez-les à côté des éléments concernés. Ces questions seront traitées ultérieurement pour éviter de sortir de la salle de réunion et maintenir la concentration.
Pour maximiser les bénéfices de l’example mapping, voici quelques bonnes pratiques à suivre :
- Garder le focus : Limitez chaque session d’example mapping à environ 30 minutes. Cela aide à maintenir l’attention de l’équipe et à favoriser une discussion productive.
- Un meeting par User Story : Consacrez un meeting spécifique à chaque User Story afin de maintenir le niveau de détail et de focaliser l’attention sur une fonctionnalité à la fois.
- Encourager la participation active : Impliquez tous les membres de l’équipe dans la discussion et encouragez-les à partager leurs idées et préoccupations. Chaque voix compte pour une compréhension approfondie des besoins métier.
- Encourager les itérations : L’example mapping est un processus itératif. N’hésitez pas à revenir sur les exemples et les règles pour les affiner et les améliorer au fur et à mesure que la compréhension progresse.
Les erreurs à éviter
Les erreurs à éviter lors de la mise en place de l’example mapping sont les suivantes :
- Trop de règles de gestion pour une seule User Story:
Lorsque vous constatez qu’une User Story contient un nombre excessif de règles de gestion, il est essentiel de la découper en d’autres US plus spécifiques. Cela permet de maintenir la clarté et la précision des exigences, et facilite la compréhension de chaque fonctionnalité individuellement.
- Trop d'exemples pour une seule règle :
Si vous vous retrouvez avec une multitude d’exemples pour une seule règle, cela peut indiquer que la règle elle-même est peu précise ou trop complexe. Prenez du recul et réévaluez la formulation de la règle afin de la rendre plus concise et compréhensible. Cela facilitera la création de cas concrets et évitera les confusions inutiles.
- Multiplication des questions sans maturité suffisante de la User Story :
Si vous vous trouvez confronté à un flux constant de questions sans fin lors de l’atelier d’example mapping, cela peut être le signe que la User Story n’est pas suffisamment mature. Assurez-vous de bien définir et clarifier les besoins avant d’entamer la session d’example mapping. Une User Story claire et complète réduit le nombre de questions imprévues et facilite le processus de mapping.
- Ne pas impliquer toutes les parties prenantes :
Pour maximiser les avantages de l’example mapping, il est essentiel d’impliquer toutes les parties prenantes pertinentes, y compris les représentants métier, les développeurs et les testeurs. Leur contribution et leur point de vue enrichiront la carte des exemples.
- Rentre trop dans les détails d’implémentation et technique :
Il est crucial d’éviter de se focaliser sur les aspects techniques tels que le code, l’architecture ou l’interaction avec l’interface utilisateur lors des sessions d’example mapping. Au contraire, il faut saisir cette opportunité pour approfondir la compréhension des besoins métier. Il est essentiel de favoriser des discussions de qualité, en trouvant un équilibre entre la durée des sessions et la profondeur des échanges. En limitant les sessions à 30 minutes, l’équipe peut maintenir sa concentration et favoriser des discussions productives.
- Rédiger les critères d’acceptation en Gherkin pendant cette session
Il est possible que cela entraîne un ralentissement du processus et détourne l’attention de la collaboration et de la compréhension mutuelle. Il est recommandé de se limiter à écrire les exemples bruts dans un premier temps, sans se préoccuper des critères d’acceptation en Gherkin. Cette approche favorise la créativité et la génération d’idées avant de se plonger dans les détails par la suite.
L’example mapping est donc un atelier précieux pour favoriser la collaboration et la compréhension commune dans le cadre du Behavior Driven Development (BDD).
En évitant les erreurs courantes telles que la surcharge d’exemples, l’omission de discussions approfondies et la négligence des parties prenantes, les équipes de développement peuvent tirer pleinement parti de cette approche et améliorer la qualité de leurs produits logiciels. À titre d’exemple, regardez comment j’ai loupé mon Example Mapping.
Les bonnes pratiques telles que limiter la durée des sessions d’Example Mapping, encourager la participation active de tous les membres de l’équipe et favoriser l’itération pour affiner les exemples et les règles au fur et à mesure de la compréhension.
Alors, rassemblez vos « 3 amigos » et commencez dès maintenant à mettre en pratique l’example mapping pour des résultats plus performants dans votre processus de développement logiciel !