# Le mot de la fin


## Parlons la même langue

Nous avons discuté des idées, des concepts... Il est temps d'établir
notre Langue Commune.



**Produit**

:   Concept dont l'application sera à terme la réalisation. Ce concept vise
à rendre possible la Vision.

**Vision**

:   Guide et oriente votre projet. Son but est de changer ce qui, dans la
vie de vos utilisateurs, peut les gêner, leur manquer ou les
insatisfaire.

**Bénéfice fonctionnel**

:   Confort métier tiré par les utilisateurs de votre Produit. 


**Langue Commune**

:   Langage clair pour l'ensemble des acteurs d'un projet. Ce langage est
défini en commun.

**Cartographie du Produit**

:   Représentation visuelle simple du Comportement de votre Produit. Cette
représentation peut concerner l'ensemble ou une partie de votre Produit.

**Fonctionnalité**

:   Besoin métier spécifique. Elle est représentée par un texte court qui
communique ce besoin métier au reste de l'équipe. Elle concerne le
service rendu à un utilisateur, et décrit le bénéfice fonctionnel qui
en est tiré.

**Scénario**

:   Illustration des situations dans lesquelles se manifeste une
Fonctionnalité. Elle est représentée par une situation initiale, un
événement et un résultat attendu.

**Exemple**

:   Illustre un Scénario de manière concrète. Il enlève toute ambiguïté
possible sur une étape d'un scénario ou sur le scénario lui-même.

**Livrable**

:   Application concrète livrée au client. Il délivre le Comportement
raconté par les Fonctionnalités et les Scénarios. Il est possible de
fournir un livrable régulièrement au cours de la vie du Projet.

**Recette**

:   Opération qui contrôle que le Livrable correspond au Produit, en se
basant sur les Fonctionnalités et les Scénarios. Peut être automatisée
avec des outils spécialisés.

## Cartographie du Développement piloté par le Comportement

![ Cartographie du Développement piloté par le Comportement ](cartographie.png)


## Les 10 commandements pour vous mettre au Développement piloté par le Comportement


1) **Votre Vision est le seul guide du projet**

:   Chaque fonctionnalité, chaque ressource consacrée au projet, tout doit
    servir cette Vision. Elle est le point de repère et la motivation de
    chacun des acteurs de votre Produit. 

2) **Créez une Langue Commune**.

:   Un développeur ne parle pas la même langue que vous. Créez un
    référentiel et un vocabulaire commun ensemble, et utilisez la syntaxe
    proposée par le Développement piloté par le Comportement, claire pour la
    majorité des gens.

3) **Concevez vos scénarios ensemble**.

:   C'est le seul moyen de retirer toutes les ambiguïtés qui peuvent exister
    entre vous, votre produit et vos équipes. Ne laissez personne rédiger un
    scénario tout seul.

4) **Vos scénarios ne concernent pas l'interface graphique**

:   Faites abstraction du support matériel de votre Produit : site web,
    application mobile... Ce qui compte vraiment c'est le comportement de
    votre Produit.

5) **L'automatisation des recettes fonctionnelles n'est qu'un bonus**

:   Automatiser des recettes fonctionnelles n'a de sens uniquement si au préalable
    vous avez réussi à faire comprendre votre besoin. Sans dialogue ni
    échanges, les tests automatisés testeront que l'application fait bien
    quelque chose, mais pas forcément ce que vous attendez.

6) **L'automatisation des tests techniques est primordiale**

:   Laissez le temps aux équipes techniques et poussez-les à écrire des
    tests automatisés de code source (test unitaire). C'est le seul moyen
    pour eux de réaliser vos demandes légitimes de changements sans faire
    exploser vos coûts.

7) **KISS : Keep It Simple and Stupid**

:   Gardez vos scénarios simples et explicites, et n'employez pas dix mots
    quand cinq suffisent. Si votre scénario est long, c'est probablement
    qu'il recouvre un domaine fonctionnel trop large : découpez-le.

8) **Soyez conscient que vos scénarios changeront**

:   En confrontant régulièrement votre Produit aux avis des utilisateurs,
    une grande partie de vos scénarios va changer, voire disparaître.
    Acceptez-le, et faites en sorte que les équipes techniques l'acceptent
    en les faisant participer à ce processus de changement.

9) **Utilisez des exemples**

:   Vous ne rédigez pas des tests d'acceptation, mais établissez une
    communication pour décrire votre besoin. Illustrez votre besoin par des
    exemples, pourquoi pas avec humour, pour effacer toute ambiguïté.  

10) **Le Développement piloté par le Comportement n'est pas une recette miracle**

:   La recette miracle n'existe pas. Mais c'est au moins un bonne démarche,
    éprouvée, pour vous faire comprendre et faciliter la communication entre
    fonctionnels et techniques. Elle aidera chacun des acteurs de votre
    projet à comprendre son rôle et ce que vous attendez de lui ; il ne
    reste plus à chacun qu'à être un bon acteur.
