27 Oct 2015

Comment instaurer le dialogue pour écrire de bons scénarios fonctionnels

 

Depuis plusieurs mois, nous mettons en place une nouvelle méthodologie de développement au sein de nos projets Agile : le Behavior Driven Development (BDD).

 

La méthode BDD est classifiée dans les spécifications par l’exemple.

Il faut assimiler la méthodologie BDD à une conversation entre les trois acteurs d’un projet :

  • Le métier qui connait le mieux le fonctionnel, les cas d’usage, les règles métier
  • Le testeur qui amène son esprit critique et beaucoup de questions sur les cas passants et non passants de la fonctionnalité
  • Le développeur et son besoin d’exemples afin d’éclaircir les aspects fonctionnels mais aussi techniques auxquels il sera confronté lors de son développement

 

Afin de réduire les allers-retours métier/testeur/développeur sur les ambigüités d’une user story (vocabulaire, cas limites, un simple cas passant, etc.) ou encore l’interprétation de chacun d’une user story durant son cycle de vie, nous avons mis en place l’atelier de review.

Cet atelier permet d’impliquer les trois parties du projet au plus tôt et surtout d’engager la conversation nécessaire et indispensable à l’écriture de bons scénarios fonctionnels.

 

Concrètement, comment se déclenche un atelier de review ?

Nous avons ajouté dans notre kanban l’étape “Atelier de review” juste après l’étape de conception de la user story par le product owner qui représente la vision métier et avant l’étape de l’écriture des scénarios en Gherkin.

Durant le Daily, nous analysons l’état du kanban et décidons si un atelier de review doit être déclenché selon deux critères :

  • Est-ce qu’au moins 2 user story sont en conception finie ?
  • Est-ce que le Product Owner, le testeur et 2 développeurs (voir plus) sont disponibles ?

Si ces deux critères sont réunis, l’atelier de review est déclenché en général juste après le Daily (pour des questions de logistique, une salle est réservée tous les jours de 10h à 10h30 afin de rassembler rapidement et facilement les trois acteurs).

 

Et maintenant, comment se déroule un atelier de review ?

Le testeur et les développeurs contactent le product owner via Lync, la première user story est sélectionnée selon sa business value. La conversation est alors engagée.

Nous parcourons les règles de la user story afin que toutes les parties aient la même interprétation de la fonctionnalité à développer. Des questions sont posées et surtout des exemples concrets sont proposés et demandés.

 

Ceci est théorique, un exemple expliquera mieux le déroulement de cet atelier !

Voici notre User Story : Accéder à l’application Mechanics depuis mon portail mobile

 

En tant qu’agent général ou collaborateur d’agence,

Je veux me connecter à l’application Mechanics automatiquement avec mes identifiants via mon portail mobile Zen après avoir sélectionné une fiche client,

Afin de réaliser un bilan épargne/retraite pour ce client.

 

Règles Métier :

RG01 : Les distributeurs pouvant accéder à l’application Mechanics depuis leur portail mobile sont :

  • Agents généraux et ses collaborateurs depuis Zen

RG02 : Les distributeurs ne pouvant pas accéder à l’application Mechanics depuis leur portail mobile sont :

  • Agent prévoyance et patrimoine (A2P) depuis d’application HolyCities

RG03 : Les clients éligibles à l’application Mechanics sont :

  • Personne physique y compris Indéterminés
  • Double-profils (il s’agit d’un foyer client contenant un fiche client personne morale & une fiche client personne physique)

RG04 : Les clients non éligibles à l’application Mechanics sont :

  • Personne morale

RG05 : Je n’ai pas besoin de ré authentifier pour accéder au site Mechanics.

 

La conversation s’engage autour des différentes règles métiers. Nous posons des questions afin d’obtenir des illustrations réelles sur les règles à mettre en place. Ces illustrations nous permettent d’engager un brouillon de scénarios qui permettront de mieux comprendre la user story et de piloter les développements.

 

1er exemple de scénario pouvant illustrer les règles RG01 et RG03

Vérifier qu’un agent général sur une fiche client éligible peut accéder à Mechanics à partir de son portail mobile

Etant donné que M Solar est un agent général

Et que la fiche de Mme Fields est sélectionnée

Et que Mme Fields est une personne physique

Quand M Solar demande une simulation

Alors l’accès à l’application Mechanics est autorisé

 

2ème exemple de scénario pouvant illustrer la règle RG04

Vérifier qu’un agent général sur une fiche client inéligible ne peut accéder à Mechanics à partir de son portail mobile

Etant donné que M Solar est un agent général

Et que la fiche de SUMMER est sélectionnée

Et que SUMMER est une personne morale

Quand M Solar demande une simulation

Alors l’accès à l’application Mechanics n’est pas autorisé

 

3ème exemple de scénario pouvant illustrer la règle RG02

Vérifier qu’un agent prévoyance & patrimoine ne peut accéder à Mechanics à partir de son portail mobile

Etant donné que M Liquid est un agent prévoyance & patrimoine

Et que la fiche de Mme Soul est sélectionnée

Et que Mme Soul est une personne physique

Quand M Liquid demande une simulation

Alors l’accès à l’application Mechanics n’est pas autorisé

 

Lors de l’atelier de review des questions peuvent se poser comme pour cette US :

Quid du comportement attendu lors de l’accès à l’application sans passer par le Portail Mobile  c’est-à-dire en entrant directement l’url dans le navigateur ? (une redirection, une page d’erreur, …).

La réponse du product owner donne lieu à une nouvelle règle voir à une nouvelle user story de gestion des cas limites de l’application qui sera elle aussi retranscrite en scénarios.

 

Et après ?

L’atelier terminé, la user story peut être tirée en BDD en cours.

Le testeur et un développeur formalisent les exemples évoqués lors de l’atelier de review sous forme de scénarios Gherkin et ajoute les cas non évoqués lors de l’atelier de review afin de contrôler l’ensemble de la user story.

 

Voici ce que donnent les scénarios en Gherkin :

ScenarioGherkin

 

Pour conclure, l’écriture de scénarios en Gherkin prend du temps et il peut être difficile de monopoliser le product owner. Pourtant, il est nécessaire que les trois acteurs aient une conversation pour construire de bons scénarios.

L’atelier de review revient à un atelier de BDD Light. Les questions sont posées en direct et les réponses sont souvent immédiates. Cela installe également de la confiance grâce à une meilleure communication entre les acteurs de l’équipe projet.

Même si à première vue nous pouvons être tenté de penser que cet atelier est une perte de temps, il se révèle être tout l’inverse.

La user story est illustrée avec des exemples et les points bloquants, les oublis, les erreurs, etc. sont détectés au plus tôt du cycle de vie de la user story ce qui évite de la bloquer en cours de développement et permet également de diminuer les bugs.

Cet atelier a également un autre aspect : une fois que nous avons une vision claire du besoin, nous sommes à même de rendre ce besoin le plus INVEST (Independant – Negotiable – Valuable – Estimable – Small – Testable) possible. L’atelier conduit régulièrement à un découpage du besoin pour plus de fluidité et tester au plus tôt.

Share