dimanche 18 août 2013

BDD : Behavior Driven Development

Définition

Le "Behavior Driven Development" (BDD) est une méthode de développement logiciel, créée par Dan North en 2003, qui encourage la communication directe entre les personnes du besoin et l'équipe en charge d'y répondre. Le but est de créer ensemble un produit qui répond exactement aux attentes du client. Le maître mot : la compréhension des acteurs.



On peut définir plus précisément les acteurs de la manière suivante :
  • Les personnes du besoin : ils sont le client, les représentant du client ou les experts métiers dans une entreprise. Ils connaissent parfaitement le besoin qui pousse la création du produit.
  • L'équipe : elle est l'ensemble des personnes qui tenterons de répondre aux besoins établis grâce à des outils techniques.

Étrangement (ou pas), ces deux acteurs ne se fréquentent pas vraiment au quotidien. Sans exagération, aucune :
  • Les uns pensent des autres que ce sont des geeks renfermés et inintéressants de part leur propension à utiliser en permanence un vocabulaire technique incompréhensible. 
  • Les autres se défendent en prétendant que ces premiers sont des farfelus, des gens qui ne savent jamais ce qu'ils veulent et que tout est toujours mieux dans leur tête que sur le papier.
Et pourtant dans la vraie vie, ces acteurs sont amenés à collaborer !


La communication : essence du BDD

Avec ces divergences, il est souvent compliqué de se comprendre :

Le BDD est un méthode qui implique les deux partis dans un processus de communication efficace. Ils sont tous les deux mis à contribution et chacun doit sortir de sa zone de confort :
  • Les personnes du besoin doivent formaliser leurs besoins, leurs idées, non plus sur un document Word de 500 pages, mais selon des scénarios dans un langage structuré.
  • L'équipe doit s'impliquer dans le besoin, comprendre le contexte, les termes métiers importants. Elle ne reste plus dans son monde de technique de Design Patterns, de Sockets, de Dll, de Batch... 
Les questions posées aux personnes du besoins ou même à un membre de l'équipe ne doivent plus ressembler à :
"La Factory de Patient doit-elle pouvoir utiliser l'index de téléphone en paramètre ?
mais plutôt à :
"Les coordonnées téléphoniques sont-elles obligatoires pour enregistrer un patient ?".


Expliquer grâce à des scénarios

Afin que les personnes du besoin et l'équipe de développement puissent se comprendre, il est indispensable d'utiliser des exemples, des scénarios. Ils doivent être normalisés comme par exemple avec la syntaxe Cucumber, composée des mots clés suivants :
  • Given : Etant donné un état
  • When : Lorsqu'une action est effectuée
  • Then : Une conséquence est constatée
Ce langage permet de faire le pont entre le monde du métier et le monde du développement. Il permet d'écrire des scénarios et génère des tests unitaires automatisés que l'équipe doit implémenter.
On peut y décrire :
  • Un comportement graphique : 
Scenario: Activation du bouton de validation du formulaire de patient
Given Le formulaire de création de patient ouvert
     And Le bouton "Valider" est inactif
When Je saisie le nom
     And Je saisi le prénom
     And Je saisi l'âge
Then Le bouton "Valider" devient actif
  • Un comportement purement métier :
Scenario: Ajout d'articles dans un panier d'achat
Given Un panier vide
When J'ajoute un article de 8 euros dans le panier
     And J'ajoute un article de 10 euros dans le panier
Then Le montant du panier est automatiquement calculé
     And Le montant du panier vaut 18 euros

Les scénarios peuvent être "variabilisés" avec des exemples. Cela permet de générer un grand nombre de cas d'utilisation avec la même structure de scénario.

Scenario Outline: Authentification sur un portail
Given Un compte de login "admin" et de mot de passe "admin159" valide
When J'ouvre le formulaire d'authentification
     And Je saisis l'identifiant "<login>"
     And Je saisi le mot de passe "<password>"
     And Je valide le formulaire
Then Le message d'erreur "<message>" s'affiche
Examples:
| login  | password | message                                        |
| admin  | admin    | L'identifiant ou le mot de passe est invalide. |
| admin2 | admin159 | L'identifiant ou le mot de passe est invalide. |
| admin2 | admin2   | L'identifiant ou le mot de passe est invalide. |
| admin  | admin159 |                                                |


La syntaxe utilisée (ici avec le framework Specflow) donne une vision très claire de la fonctionnalité attendue. Mais pour palier les problèmes de compréhension, il est nécessaire que les scénarios soient écrits avec rigueur et selon un formalisme que l'équipe et le client doivent avoir établis de manière claire. Une nomenclature récapitulant l'ensemble des règles est indispensable.


BDD vs TDD

De manière générale, BDD et TDD sont souvent utilisés ensemble au sein des projets. Le BDD se situe plus au niveau macroscopique, au niveau du comportement de l'application, alors que le TDD se situe souvent plus au niveau de chaque classe. Le TDD favorise le vrai design de classe et stimule le refactor.
Un cycle BDD est composé de plusieurs cycles TDD :


Le cercle extérieur représente un scénario BDD alors que le cercle intérieur représente un test en TDD. Pour qu'un scénario soit implémenter, il faut une succession de tests plus unitaires en TDD sur la classe de bas niveau.


Exemple complet en C# avec SpecFlow

Pour un exemple complet de l'utilisation des scénarios via la méthodologie BDD, se rendre à ce lien.


Les avantages du BDD

Du point de vue de l'équipe, les avantages du BDD sont de deux niveaux:
  • Avantages techniques
    • permet de générer des tests unitaires pour piloter le développement
    • permet de structurer un design de classes piloté par le métier
    • permet d'obtenir des spécifications claires, concises et vivantes : elles évoluent en fonction des besoins et restent toujours en accord avec le code
    • permet d'obtenir un "cahier de recette" automatisé : plus besoin d'un n ème intermédiaire, appelé aussi "Testeur", pour jouer et rejouer les scénarios. Les scénarios en BDD entrent dans l'intégration continue et les tests automatisés.
  • Avantages humains
    • permet d'adopter naturellement le langage du besoin, le domaine
    • permet de comprendre, d'être compris par le client et de proposer des idées pertinentes avec son besoin.

Un point très intéressant du BDD : un problème technique reflète presque toujours un manque ou une incohérence fonctionnelle. J'ai pu le constater personnellement à maintes reprises : lorsqu'en tant qu'équipier nous sommes confrontés à une anomalie, à un problème technique ou un problème de conception, c'est presque automatiquement : 
  • soit une erreur de compréhension du métier par l'équipier
  • soit une mauvaise écriture des scénarios associés par la personne du besoin

Du point de vue des personnes du métier, les avantages du BDD sont :
  • permet de guider l'écriture du besoin : la syntaxe étant très contraignante, elle aide à cerner précisément le besoin et banni le superflu.
  • aide à prioriser le besoin
  • permet de mieux se faire comprendre : il n'y a pas de "garantie" mais un besoin écrit avec un langage intermédiaire établis de manière claire entre les partis, a de meilleurs chances d'être compris par un équipier qu'un mail de 400 lignes ou une document Word écrit de bonne volonté.


Les inconvénients du BDD

Malgré tous ces avantages, la méthodologie BDD possède néanmoins quelques inconvénients :
  • Très forte implication des personnes du besoin. En effet, ils ont la responsabilité d'écrire les différents scénarios à implémenter.
  • L'écriture des scénarios force à réfléchir. Et oui, cela peut être vu comme un inconvénient surtout par les personnes ayant la vision métier mais répétant sans cesse : 
"Ne me pose pas la question, c'est écrit dans le document 15, paragraphe 501, ligne 135 !"
Ecrire les scénarios, même complexe, c'est se replonger dans le besoin et être pragmatique sur ce que l'on souhaite modéliser. Un exercice intellectuel qui est loin d'être facile, même pour les personnes ayant la meilleure vision des besoins.
  • L'implication de l'équipe. En effet, l'équipe doit s'impliquer dans le processus et jouer le jeu. Les scénarios doivent être implémentés et bien ! Chaque membre de l'équipe est responsable des fonctionnalités implémentées, et bien plus quand elles sont visibles sous forme de tests automatisées de couleur verte !


Les erreurs les plus courantes

Voici quelques exemples des erreurs les plus courantes lors de l'utilisation de la méthodologie BDD :
  • L'équipe écrit ou modifie les scénarios sans l'accord des personnes du besoin. La méthodologie du BDD consiste à être au plus proche du besoin. Si l'équipe modifie les scénarios, on risque de s'éloigner du besoin originel voir même de créer des fonctionnalités qui ne font pas partie du besoin.
  • Les scénarios ne sont pas implémentables. Ce problème vient d'un mauvais compromis entre les deux partis. Les contraintes d'implémentions doivent être mises au claire lors de la formulation de la nomenclature d'écriture.
    Exemple de formulation très difficile à implémenter :
-   Given Un utilisateur qui n'est pas 'administrateur'
-   Given Pour tous les mots de passe non valides
-   When Je ne clique pas ...
-   Then "Tout" va bien
...
  • Les scénarios ne sont pas implémentés correctement. La plupart du temps, les scénarios sont assez clairs pour être implémentés par l'équipe sans difficulté en terme de compréhension. Cependant, certains peuvent être très compliqués. Un scénario mal implémenté correspond souvent à un scénario qu'un équipier n'a pas compris. Il faut favoriser les communications entre les acteurs, même pendant l'implémentation de scénarios. Si un scénario est compliqué, il faut pouvoir entamer la discussion avec les membres de l'équipe ou la personne du besoin en charge de les écrire. Seul l'échange peut éclaircir rapidement l'incompréhension.


Conclusion

Le BDD est un méthode de développement très intéressante qui met au centre la communication entre les personnes du besoin et l'équipe de développement. Chaque parti doit sortir de sa zone de confort pour travailler avec un langage structuré intermédiaire. Couplés avec une méthode Agile, les scénarios en tant que critères d'acceptation de UserStories, permettent à l'équipe d'être complètement immergée dans les vraies problématiques du client et ainsi d'être en mesure de proposer des solutions qui correspondent exactement à ses attentes. Le client quant à lui, voit (avec émerveillement) l'avancement de son produit, sprint par sprint et n'est pas surpris de son bon fonctionnement.

Etant développeur, et appliquant le BDD quotidiennement dans mon entreprise, j'ai pu réaliser l'importance d'être impliqué dans le besoin du client. Le langage structuré permet d'être en contact directement avec ce qu'il souhaite sans aucune erreur de compréhension possible. Couplé avec du TDD pour le design du code, on obtient un logiciel répondant exactement au besoin du client et de très bonne qualité (robustesse et non régression).

Dans une époque ou l'équipe de développement devient le centre des attentions notamment grâce aux méthodes Agiles, j'encourage énormément les développeurs à s'intéresser à ce type de méthode. Il est vrai que certains contextes, les personnes du besoin ne sont pas toujours disponibles ou ne veulent pas s'impliquer davantage dans l'écriture des scénarios. Mais dans ce cas, la vraie question serait :
"Pourquoi les personnes qui ont la meilleure vision des besoins ne veulent-elle pas s'investir dans un processus qui garantit les fonctionnalités et la qualité du produit final ?" =)

5 commentaires:

  1. Salut Pierre ! Dans ta dernière phrase, tu penses à quelqu'un ? :-)

    Gabriel (RABHI)

    RépondreSupprimer
  2. Salut Gabriel ! Je ne pense à personne en particulier, je fais juste un constat ;) Les BDD restent difficiles à écrire directement par une personne du besoin mais ce n'est pas une raison pour ne pas s'impliquer dans ce processus !

    RépondreSupprimer
  3. Comme tu sais que je suis un casse couille, la définition que tu donnes à "Ubiquitous language" n'est pas tout à fait exact. "Les deux partis doivent échanger grâce à un langage structuré appelé aussi "Ubiquitous language". " En fait non, l'Ubiquitous language en lui même c'est simplement le vocabulaire partagé par le métier et la technique. La notion de structure des scenario est propre au BDD. L'Ubiquitous language en lui même n'est pas structuré, et est une notion indépendante du BDD (très présente dans le DDD aussi par exemple)

    RépondreSupprimer
    Réponses
    1. Ce que j'entend dans cette phrase, c'est que le BDD peut s'apparenter comme une sorte d'ubiquitous language ou langage commun entre les personnes du métier et les développeurs. Il est un maillon entre ces deux mondes, demandant à chacun un effort pour écrire ou lire ces scénarios.
      C'est différent de l'ubiquitous language du DDD qui représente des termes métiers précis, un vocabulaire partagé comme tu dis, que le développeur doit apprendre à maîtriser afin de s'approcher au mieux du besoin, un partage du savoir indispensable.
      La phrase porte à confusion, je vais la réviser.
      Merci de ton retour

      Supprimer
    2. C'est pour ça que ça porte à confusion, car quand on parle d'ubiquitous language, ça a bien précisément le même sens en BDD et en DDD. Du coup dire que " le BDD peut s'apparenter comme une sorte d'ubiquitous language ou langage commun entre les personnes du métier et les développeurs", c'est perturbant.

      Pour pratiquer efficacement le BDD, il faut un d'ubiquitous language. Par ailleurs le BDD permet de structurer les scénarios qu'on exprime à l'aide de cette d'ubiquitous language. :)

      Supprimer