lundi 6 février 2012

Qu'y a-t'il dans une histoire (une Story) ?

Le Behaviour-driven development (BDD ou développement dirigé par le comportement) est une méthodologie « extérieur-intérieur ». Il démarre à l' extérieur en identifiant les produits métiers puis pénètre dans les fonctionnalités (« features ») pour déterminer qui réalise ces produits. Chaque fonctionnalité est capturée dans une « story » qui définit la portée de cette fonctionnalité en même temps que les critères d'acceptation. Cet article est une introduction à l'approche BDD qui définit et identifie les histoires et leurs critères d'acceptation.

Ce qui suit est la traduction de l'article de Dan North : http://dannorth.net/whats-in-a-stor..., publiée ici avec son aimable autorisation.

Les termes fréquemment usités dans le domaine seront également signalés en anglais.

Introduction

La livraison de code consiste à écrire du code qui produit des résultats métiers. Cela semble évident, mais souvent des facteurs politiques ou environnementaux nous conduisent à l'oublier. Parfois, la livraison de code peut sembler ne consister qu'à réaliser des rapports optimistes permettant de s'assurer de la bonne humeur des responsables projet ou juste à simplement maintenir les gens occupés pour garantir de conserver les effectifs existant, mais c'est un autre sujet.

En général, les attendus métiers sont trop génériques pour pouvoir être utilisés directement pour écrire du code (où commencer à coder quand l'attendu est « économiser 5% de mes frais de fonctionnement »?), aussi nous avons besoin de définir des exigences à un niveau intermédiaire afin de pourvoir faire le travail.

Le Behaviour-driven development (BDD) prend le parti que vous transformez simplement et efficacement une idée d'exigence en code implémenté, testé et prêt pour la production tant que les exigences sont suffisamment spécifiques pour que tout le monde comprenne de quoi il retourne. Pour ce faire, nous avons besoin d'un moyen de décrire les exigences de telle sorte que tout le monde – les fonctionnels, les analystes, les développeurs et les testeurs – ait une compréhension commune de la portée du travail. A partir de là, ils peuvent se mettre d'accord sur une définition commune de « terminé » (« done ») et nous échappons aux pièges mentaux du découragement (« gumption traps ») du « ce n'est pas ce que j'avais demandé » et « j'ai oublié de vous dire quelque chose ».

Ceci, alors, est le rôle de l'histoire (« Story »). Elle doit être une description d'une exigence et du bénéfice métier associé assortie d'un ensemble de critères grâce auxquels on pourra s'accorder sur le fait que l'exigence est satisfaite, donc que le travail spécifié est terminé (« done »). Ceci constitue une définition plus rigoureuse que celle que l'on trouve dans d'autres méthodologies où elle est diversement décrite comme « la promesse d'un dialogue » ou « la description d'une fonctionnalité ». (Une histoire BDD peut aussi facilement décrire une exigence non fonctionnelle du moment que le travail peut être cadré, estimé et validé par tous).

Lire la suite...