En tant que Product Manager, la bonne compréhension des User Stories par l'ensemble des parties prenantes constitue l'un de vos enjeux majeurs. Le BDD peut vous y aider.
La User Story représente l'artefact phare du Product Manager. Rédigée, priorisée, détaillée, estimée, développée, testée, validée, elle parcourt un cycle de vie complet avant d'être mise de côté une fois l'objectif qu'elle matérialisait atteint. Le Product Manager est en charge de toute la phase de "préparation" de la User Story. Vous pouvez jeter un oeil à la vidéo d'Antoine au sujet des pratiques à adopter pour bien écrire ses user stories.
Afin de donner corps à votre User Story, Romain vous recommande d'incorporer des Mock-ups. Pratique que j'ai toujours appliquée pour mes User Stories jusqu'à récemment... jusqu’à ce que je devienne Product Manager d'une API ! Les Mock-ups ne m'étant plus d'aucune aide, une nouvelle forme d'enrichissement des stories m'a sauvé la vie : le BDD et puis précisément le langage Gherkin.
BDD et Gherkin en quelques mots
Le BDD (Behavior Driven Development) est une méthodologie agile proposée par Dan North pour aller au delà du TDD (Test Driven Development). Cette méthodologie a pour objectif d'améliorer la compréhension et la collaboration du Product Manager, des développeurs, des testeurs et de toute autre partie prenante pertinente en décrivant le comportement attendu de la fonctionnalité grâce à un langage commun : le Gherkin.
Ce langage basé sur une syntaxe standardisée permet de faciliter la lecture des US et d’uniformiser les critères d’acceptance. L’objectif n’étant pas de paraphraser les règles métier, mais bien de donner des exemples précis. Pour chaque User Story, vous pouvez ainsi rédiger un ou plusieurs tests en Gherkin en suivant la structure suivante :
GIVEN (étant donné que) : le contexte initial à l’exécution du test.
WHEN (quand) : événement ou action à réaliser.
THEN (alors) : résultat attendu.
Template d'une User Story
Ces critères d'acceptance illustrent donc par l'exemple ce que vous attendez de votre logiciel une fois la User Story développée et peuvent être appuyés par des Mock-ups. L'équipe de développement se basera sur ces critères d'acceptance pour écrire le code lié à l'User Story, ils seront également repris par le testeur pour valider la story et pouvoir la passer en done.
L'atelier "Three Amigos" et la rédaction des scénarios
Parmi les bonnes pratiques du BDD, les ateliers de travail "Three Amigos" peuvent être très bénéfiques. L'important n'est pas le nombre de participants mais la pluridisciplinarité des profils autour de la table. Idéalement, un Product Manager, un testeur, un développeur mais aussi un exploitant ou encore un commercial (tout dépend du contexte de votre produit) participent à cet atelier et écrivent ensemble les scénarios suite à la présentation de la story par le Product Manager.
Ces sessions permettent d'aligner la vision et de s'assurer de la bonne compréhension des items par tous. Elles permettent également de creuser les User Stories et de bien prévoir l'ensemble des comportements attendus (donc l'ensemble des critères d'acceptance). Assez coûteuses en temps, elles sont importantes en début de projet lorsque le produit commence à être développé. Avec l'habitude, l'équipe finit par naturellement parler le même langage et le Product Manager (ou le testeur) peut écrire les scénarios seul.
