Concombre et User story

Le Concombre Masqué

Agilité est une boite à outils de pratiques dédiée aux individus, aux les logiciels fonctionnels, à la collaboration client et à la réponse au changement. Oui, ce sont les valeurs du  Manifeste Agile. Non, ce n'est pas une méthode.

L'Agilité concerne aussi bien des cycles de développements que des phases d'analyse métier.

Dans son blog, Jurgen Appelo essaye de créer une liste des pratiques Agiles. On peut ne pas être d'accord avec son contenu mais elle a au moins l'avantage d'exister.

Parmi toutes ces pratiques il y en a deux qui peuvent être combinées efficacement pour gérer l'analyse métier au sein d'une organisation Agile : les User stories et le Behaviour Driven Development.

C'est là où le Concombre Masqué passe à l'attaque !!!!

User Stories

Les user story sont de courtes phrases décrivant un besoin métier (fonctionnel) du point de vue et responsable de produit. C'est une manière simple et aisément compréhensible de véhiculer l'information du product owner vers l'équipe

Mike Cohn, l'un des créateurs du Manifeste Agile, propose d'écrire les user story comme suit :

En tant que  <un rôle>, je veux <un but> pour <une raison>

Le rôle  et le but sont obligatoires. La raison est optionnelle si elle est évidente.

Afin de créer des user story efficaces, il est préférable de respecter le principe INVEST. Une user story devrait :

• être Indépendante - Independent
• être Négociable - Negotiable 
• apporter une valeur ajoutée - Valuable 
• être estimable - Estimable 
• être petite - Small 
• comporter des tests d'acceptation - Tests 

La création des tests est obligatoire. Les tests d'acceptation doivent être écrits pour pouvoir considéré une user story comme acceptable.

Pourquoi ne pas utiliser une cornichon, ou gherkin en anglais, pour écrire ces tests ? 

C'est exactement ce que nous allons faire grace au behaviour driven development (BDD). 

C'est là que le Concombre Masqué devient cool !!!

Behaviour Driven Development - La syntaxe Gherkin

Le BDD est une technique de développement mise au point par Dan North. Mais nous ne sommes ici intéressez que par la manière de faire du recueil de besoins avec le BDD : la syntaxe "cornichon" de son vrai nom Gherkin syntax.

Pourquoi Gherkin ? Parce que c'est un savant jeu de mots anglais autour de Cucumber, l'outil d'écriture de tests pour Ruby.

It is a Business Readable, Domain Specific Language that lets you describe software’s behaviour without detailing how that behaviour is implemented.

Gherkin serves two purposes – documentation and automated tests."

citations de Github

On pourrait traduire ça par

"C'est un langage compréhensible orienté besoins métier, qui décrit le comportement d'une application sans se préoccuper des détails de l'implémentation"

Pour décrire un besoin avec la syntaxe gherkin, utilisez le modèle suivent :

• Etant donné un contexte 
• Et un complément d'information au contexte (optionnel)
• Lorsqu'une action spécifique est exécutée
• Alors un résultat attendu
• Et un complément au résultat attendu (optionnel) 

Utilisez ce modèle pour décrire les principales tests d'acceptation d'une user story

Un exemple

D'abord la user story

"En tant  que manager je veux afficher toutes les contrats de garanties autorisés pour mes clients"

Dans ce cas; les cas d'acceptations concernés les cas de succès et d'échec du comportement

Un contrat de garantie existe

• Etant donné un manager 
• Et il possède au moins un contrat de garantie valide parmi ses clients  
• Lorsque la page des Garanties est chargée 
• Alors la liste des garanties affiche toutes les garanties retrouvées 
• Et la somme des Prix des garanties est affichés sous la colonne Valeur 

Aucun contrat de garanties n'existe

• Etant donné un manager 
• Et il ne possède aucun contrat de garantie valide parmi ses clients  
• Lorsque la page des Garanties est chargée 
• Alors la liste des garanties affiche vide
• Et un message affiche "Aucune données trouvé pour cette requête"

Conclusion

L'emploi des user stories écrites avec tests d'acceptation formatés suivent la syntaxe gherkin, couplés à une discussion avec l'équipe permettra certainement au product owner et aux analystes de s'affranchir de lourde documentations difficiles à lire et a maintenir (évidemment dans un contexte Agile).

Rappelez-vous que l'un des points les plus importants des pratiques Agiles est la Communication avec un grand C. Donc mettre en place des techniques ou des pratiques permettant d’améliorer cette communication entre toutes les parties prenantes permettra d'économiser du temps et d'améliorer la qualité des fonctionnalités développées.

Pour en savoir plus :

• Le anifeste Agile (fr) : http://agilemanifesto.org/iso/fr
• Le blog de Mike Cohn (en) : http://blog.mountaingoatsoftware.com
• Le blog de Jurgen Appelo (en) : http://www.noop.nl 
• “User stories applied” par Mike Cohn, éditions Addison-Wesley Professional