Cet article est la suite d’une série intitulée « Il était une fois un projet IT en Kanban« , débutée en 2013, décrivant  les différentes étapes de l’accompagnement d’un grand groupe vers une transformation Agile à grande échelle, basé sur Kanban.

Les épisodes précédents :

• Il était un fois un projet IT en Kanban (Episode 1 : Du Story Mapping au Kanban) ;
• Il était un fois un projet IT en Kanban (Episode 2 – Part I : Indicateurs Graphiques) ;
• Il était un fois un projet IT en Kanban (Episode 2 – Part II : Mesurer la performance du système avec les KPI);
• Il était une fois un projet IT en Kanban (Episode 3 : Tenez vos promesses avec la prédictibilité).

Ce quatrième épisode décrit les étapes et éléments mis en place dans l’amélioration de la qualité des Stories.

L’efficience d’un Système Kanban, réside dans sa capacité à identifier et supprimer les obstacles.

L’un de ces obstacles et sans conteste la qualité des User Stories, pouvant perturber la chaine de production de valeur, ainsi que la capacité à être prédictible. Cela fait également porter un risque important sur la capacité d’une équipe projet à tenir ses promesses, notamment lorsqu’un nombre important d’anomalies est identifié en phase de qualification.
L’objectif est d’améliorer la qualité des User Stories traitées, mais comment faire ? Voici une approche que nous avons mise en place sur nos projet :

• Intégrer des Règles Métier dans la description de la Story ;
• Décrire les tests à réaliser, permettant de valider les règles métier, au format BDD (Behaviour Driven Development) ;
• Faire intervenir, très en amont, l’équipe en charge de la qualification des Stories ;
• Mettre en place des séances de Pair-testing sur la validation des Stories.

Si la description d’une User Story et le BDD n’ont plus de secrets pour vous, je vous recommande d’aller directement au paragraphe « Intégration des Régles Métier et du BDD dans mon Système Kanban ».

Les Règles Métiers

La description d’une User Story reste un exercice assez simple (normalement), avec un gabarit utilisable dans la plupart des cas :

En tant que (qui)
Je veux (quoi)
Afin de (pourquoi)

Exemple :
En tant que client
Je veux m’authentifier à l’application
Afin d’accéder à la page d’accueil

Néanmoins, bien que cette Story raconte une histoire compréhensible par tous, elle ne peut être réalisée (développée) en tant que telle. Celle-ci doit s’accompagner de l’ensemble des descriptions permettant de définir quelles sont les attentes de chacun des acteurs. Ces descriptions sont représentées par ce que nous avons décidé de nommer communément les Règles Métiers.

Chaque Règle va être décrite sous la forme de « Bullet Point ». Exemple :

• La saisie d’un identifiant est obligatoire
• L’identifiant est de type adresse email
• La saisie d’un mot de passe est obligatoire
• La longueur du mot de passe minimum est de 6 caractères
• Le mot de passe est de type alphanumérique
• Le couple identifiant/Mot de passe doit correspondre à un compte existant
• Le compte doit être actif.

A ce stade, les Règles Métier apportent un bon niveau de compréhension du besoin exprimé par la Story, mais celle-ci ne peut toujours pas être réalisée de façon sereine. En effet, quels sont les messages d’anomalies à afficher dans le cas où l’identifiant n’est pas saisi ou que le compte n’est pas actif ?

C’est là qu’interviennent les BDD.

Le Behaviour Driven Development (BDD)

Le BDD, pour Behaviour Driven Development ou Développement piloté par les comportements, est un langage métier qui permet de décrire des comportements sous forme de tests auto-suffisants. Celui-ci va permettre à l’expert métier, au Product Owner et aux développeurs de se comprendre, grâce à l’utilisation d’un vocabulaire commun accessible à tous.

Le gabarit communément utilisé sur les BDD est le suivant :

Étant donné (description du contexte)
Lorsque (l’action)
Alors (le résultat)

Exemple :
Étant donné un Utilisateur Anonyme sur la page de connexion du site

ET que j’ai saisi l’identifiant « roger@xebia.fr »

Et que j’ai saisi le mot de passe « toto1234* »

Lorsque je valide en cliquant sur le bouton « valider »

Alors il est redirigé vers la page d’accueil du site

Et l’identifiant est affiché en haut à gauche

Une User Storiy peut contenir plusieurs BDD, dont le premier est le BDD nominal, celui correspondant le plus souvent au cas passant, mais il s’agit surtout de celui apportant la plus grande valeur ajoutée à l’utilisateur.

Autres éléments d’une User Story

Bien que représentant l’essentiel de la « documentation », les Régles Métiers et les BDD ne sont pas les seuls éléments pouvant apporter une information travaillant à la qualité d’une User Story. Contrairement à ce qu’on peut voir parfois, l’Agilité ne recommande pas l’absence de documentation, mais le juste niveau nécessaire à la bonne compréhension du besoin.

Les autres éléments pouvant constituer une User Story sont :

• Les Wireframe ou Mockup (Mariage entre US et Wireframes)
• Des prérequis
• jeu de données
• etc.

Intégration des Règles Métiers et du BDD dans mon Système Kanban

Le Product Owner aux manettes

Après la phase de Story Mapping, ayant permis d’identifier les premières Stories à traiter, le travail de description peut débuter. Cette activité est prise en charge par le Product Owner, garant de la retranscription du besoin métier et de la gestion du Produit. Celui-ci va décrire les Règles Métier attachées à une User Story. Pour cela il peut bien entendu se faire assister par toute personne pouvant lui apporter des éléments de réponse et une bonne compréhension du besoin (Business Analyst, Utilisateur final …). Sur notre projet, le Product Owner avait une autre activité à réaliser … Décrire le BDD nominal.

L’équipe de tests, le co-pilote

Sur les projets dits « classiques », l’équipe en charge de la Qualification et de la Recette du produit intervient généralement en fin de phase projet. Le risque devient alors important sur la détection d’un nombre élevé d’anomalies.

Sur notre projet, nous avons souhaité une meilleure collaboration en faisant intervenir le plus tôt possible les acteurs en charge de la qualification. Pour cela, dès que le Product Owner a finalisé les règles métiers et le cas de test nominal, la user story est « tirée » par un membre de l’équipe de qualification qui aura en charge les deux activités suivantes :

• Valider le niveau de compréhension de la story, au travers des règles métiers et du BDD nominal ;
• Rédiger l’ensemble des BDD permettant de valider l’adéquation des développements qui seront réalisés avec le besoin.

À ce stade, l’objectif est d’arriver à une user story contenant l’ensemble des informations permettant à l’équipe de développement d’effectuer son analyse.

Nous ne limitons pas le nombre de BDD à écrire sur une Story. Tous les BDD devant être déroulés pour valider le besoin exprimé doivent être décrits. Ce volume de test fera partie des éléments à analyser pour déterminer l’effort à fournir par l’équipe de développement, dans la réalisation d’une Story. De plus, le BDD ne doit pas remplacer la conversation du Product Owner avec l’équipe. Le piège à éviter est l’illusion du détail que peut donner un BDD et qui peut avoir pour conséquence que l’équipe se passe de communication directe. Le niveau de maîtrise du produit par l’équipe est généralement un indicateur s’il faut générer plus ou moins de BDD.

T’es pas INVEST, tu rentres pas

Étape suivante de notre workflow, l’analyse de la story par l’équipe en charge de sa réalisation.

L’équipe de développement va donc procéder à l’analyse de la story, dont l’objectif sera de définir si celle-ci répond aux critères INVEST :

• I : Une Story dépendante d’une ou plusieurs autres Stories ne sera pas testable et ne pourra pas être validée tant que les autres n’auront pas été faites, ce qui fait porter un risque sur la capacité de l’équipe à pouvoir réaliser rapidement un incrément démontrable au Métier ;
• N : Une Story doit pouvoir être négociable afin de garantir à l’équipe la capacité de livrer au métier les fonctionnalités répondant le plus à ses attentes et permettant également de respecter le TTM ;
• V : Une Story n’ayant pas de valeur business pour le métier n’apporte aucune plus-value au produit ;
• E : L’estimation d’une Story est importante, car elle permet à l’équipe d’identifier l’effort à fournir et de garantir une granularité cohérente entre les US, aidant à une meilleure mesure de la prédictibilité ;
• S : Une Story trop grosse en effort et en taille met en risque sa réalisation dans un délai court et sa compréhension par l’équipe délivery et Tests ;
• T : Une Story ne possédant pas l’ensemble des cas de tests à passer pour la valider ne pourra être développée et validée en garantissant être en adéquation avec le besoin exprimé par le Métier.

Cette analyse n’est pas réalisée lors d’une réunion de Sprint Planning, mais selon le principe de la gestion en flux continu et en tenant compte des limites basses et hautes mises en place. Sur notre projet, une étape INVEST a été positionnée, juste après l’étape d’écriture des BDD. La limite appliquée sur cette étape a été de 5 stories maximum. Cela signifie que dès que 5 stories sont « fini » dans l’étape précédente, une partie de l’équipe de développement « tire » ces stories et prend entre 30 et 45 min pour effectuer les travaux suivants :

• Valider le niveau de compréhension des règles métiers ;
• Valider le niveau de compréhension des BDD et leur complétude par rapport aux règles métiers ;
• Analyser l’impact potentiel sur l’architecture du produit et la nécessité ou non de créer une ou plusieurs story techniques ;
• Estimer l’effort à fournir sur la réalisation de la story (en taille de t-shirt : XS S M L XL)
• Valider que la story est indépendante.

À ce niveau de notre workflow, le processus mis en place permet de garantir un niveau important de qualité des stories. Autre élément d’amélioration de nos stories et de notre processus kanban, plafonner l’effort à fournir sur une story. Sur ce projet, une décision initiale a été de ne pas traiter les stories dont l’effort est supérieur à la taille L. Par la suite le plafond a été redescendu à la taille M. Cela a permis d’affiner le niveau de granularité de nos stories et de leur cycle time moyen, donc une meilleure prédictibilité. Les stories ne répondant pas aux critères décrits précédemment sont taguées comme « bloquée ». À charge ensuite pour le Product Owner ou pour les membres de l’équipe de qualification de procéder à leur correction. Les stories validées peuvent rentrer dans l’étape d’ingénierie.

Un Pair-testing et puis s’en va

L’un des préceptes de l’agilité est de montrer un produit qui fonctionne, quelle que soit la méthode utilisée. Les étapes précédentes ont permis de fournir, à l’équipe de développement, des stories INVEST et d’une granularité suffisamment fine pour être réalisée le plus rapidement possible. Les développements sont réalisés au travers des BDD. Mais comment garantir que ces BDD ont été correctement retranscrits dans le code et qu’une story est vraiment Done ? Pour répondre à cette interrogation, nous avons mis en place une pratique que nous avons nommée le Pair-testing. Son fonctionnement est très simple. Lorsqu’un certain nombre de stories, en fonction de la limite fixée, sont prêtes, un membre de l’équipe de qualification lance une phase de pair-testing (généralement décidé lors du daily meeting). Sur une story, le qualifieur et un développeur, autre que celui l’ayant réalisée, s’installent à un poste de travail. Le développeur effectue l’ensemble des tests représentés par les BDD. Les résultats obtenus sont validés par le qualifieur, dans la positive. Lorsqu’une anomalie ou incohérence est détectée, le développeur procède aux corrections nécessaires, voire fait intervenir le développeur d’origine si besoin. Les tests et les corrections sont effectués tant que tous les cas de tests ne sont pas validés par le qualifieur. La story est Done, lorsque le qualifieur valide l’ensemble des tests déroulés par le développeur. Cette activité permet de garantir l’adéquation de la story réalisée avec les BDD définis et le besoin exprimé par le métier. Cette activité ne permet pas, bien entendu, de valider la story au niveau unitaire et éventuellement de détecter des régressions. La validation de la cohérence d’ensemble sera effectuée au niveau des Minimal Marketable Feature, au fur et à mesure que celles-ci seront réalisées.

N.B. : Dans le cas ou votre équipe n’a pas dans ses membres une personne spécialisée sur les activités de qualification, l’activité de pair-testing est prise en charge par le Product Owner, garant de l’adéquation de la fonctionnalité réalisé avec le besoin métier exprimé.

Conclusion

Les règles métiers donnent une vision statique, le BDD apporte une vision dynamique qui manque souvent pour la compréhension d’une story. Il permet également d’éviter des compréhensions différentes en utilisant un format de description déterministe et intelligible par tous les acteurs d’un projet.

Le retour d’expérience de la mise en place de ce processus, sur notre projet, a été une amélioration importante de la qualité des stories et plus généralement des développements réalisés. L’autre élément intéressant, mis en avant par l’équipe de développement lors du bilan, a été un accueil très positif du pair-testing, qui a réduit les perturbations sur le travail des développeurs (dans la correction des anomalies) et une meilleure communication avec l’équipe de qualification.

Le workflow mis en place a également été un élément positif pour l’équipe de qualification qui a, très en amont, pu préparer ses campagnes de tests et construire au fur et à mesure ses scénarios de tests et améliorer sa connaissance du produit. Bien entendu, ce mode de fonctionnement n’est pas applicable qu’à un mode kanban et peut très bien être mis en place sur un projet en mode Scrum, l’important restant de garantir le plus tôt possible un niveau de qualité maximal des stories.

Take Away (aller plus loin)

Le retour d’expérience, présenté dans cet article, est une première étape dans l’amélioration de la qualité des user stories.

Un Système Kanban repose sur une amélioration continue des processus et pratiques mis en oeuvre. Dans cette optique d’amélioration continue, la prochaine étape doit être une automatisation de vos tests, sur la base des BDD identifiés sur chaque story.

Cette pratique, associée à la mise en place d’une plateforme d’intégration continue vous apportera une efficience plus importante de votre flux d’activité, au travers d’une amélioration de la qualité de vos stories, d’une gestion automatisée des tests de non régression et d’une augmentation de votre flux de livraison en production.

 

Note de l’auteur : J’ai à l’origine créé cet article sur le blog Xebia ou vous pouvez le retrouver.