SAND-framework/data/doc-prince-book-generation/doc/tome1/Contents/func-un-peu-de-recul.md

# Un peu de recul sur le Développement piloté par le Comportement


## Votre fonctionnalité se spécifie elle-même

Vous savez désormais décrire votre besoin dans une Langue et une
grammaire compréhensible par tous les acteurs de votre projet.

Vous avez peut-être déjà rencontré cette difficulté : au fur-et-à-mesure
de la vie d’un projet, la documentation, fruit d’un travail difficile et
chronophage, se détache généralement de la réalité.

Cette difficulté a en réalité une origine simple : lorsque l’on ajoute
une nouvelle fonctionnalité, mettre à jour la documentation prend
parfois plus de  temps que la réalisation même de la fonctionnalité.

Maintenant, examinez ceci : avec le Développement piloté par le
Comportement, c’est-à-dire grâce à la Langue Commune, grâce une
grammaire spécifique, la documentation fonctionnelle est écrite en même
temps que les spécifications. Et oui! Vos Fonctionnalités sont aussi de
la documentation.

Il est assez facile d’imaginer, par exemple, prendre l’ensemble de vos
fichiers de Fonctionnalités et les transformer en un fichier .pdf, ou
encore d’en faire un manuel en ligne. C'est ce que font, par exemple, 
[Relish](https://www.relishapp.com) (hébergé, payant) ou 
[Pickles](https://github.com/picklesdoc/pickles) (gratuit, à installer soi-même).

Bien plus, aucun changement fonctionnel de code source ne peut être
réalisé sans que l’un de vos fichiers de Fonctionnalités  n’ait été
modifié. C’est le principe même du Développement piloté par le
Comportement : vous ne pouvez pas avoir de delta entre votre expression
de besoin et ce que vos développeurs vous livreront.

Par conséquent, vous l’aurez compris, vous avez ainsi un énorme avantage
:  **les Fonctionnalités que vous avez constituées  reflètent en
permanence l’état réel de votre Produit**. 


Si ce n'est pas le cas, c'est :

+ que vous avez modifié votre Fonctionnalité sans en rédiger les Scénarios directement avec l'équipe technique. Votre erreur sera d'avoir rompu le dialogue avec vos équipes,
+ ou que les équipes n'auront pas encore réalisé votre demande de changement. Il faudra dans ce cas prioriser ce changement parmi l'ensemble de fonctionnalités qu'ils ont à développer.

> Spécification = Documentation = toujours à jour

## Servez-vous de vos fonctionnalités pour prioriser

Pensez à ceci : vous pouvez, si vous le souhaitez, associer un état à
chacun de vos fonctionnalités et scénarios. Par exemple :

+ En attente
+ En cours de développement
+ Réalisé


Vous verrez qu'il existe des outils pour vous aider dans cette tâche.
Grâce à ces indicateurs, vous disposez de la possibilité de visualiser à
chaque instant l'état de votre produit.


Si, donc, vous connaissez la phase de développement de chacun de ces
scénarios et fonctionnalités, pourquoi ne pas vous servir de cette
information pour changer leur priorité ? 


Vous le savez, votre Produit a besoin d'être confronté rapidement au
feedback de vos utilisateurs. Profitez en pour faire en sorte de vous
faire livrer régulièrement des versions simplifiées de votre projet ;
regardez ce qui plaît à vos utilisateurs... C'est justement ce qui plaît
qu'il va falloir développer en priorité dans votre projet, tout le reste
peut être remis à plus tard.


Vous l'aurez compris : ce découpage en fonctionnalités, puis en
scénarios, va vous permettre de prioriser intelligemment votre projet.
Bien plus, cela va vous pousser à abandonner certains points pour en
introduire de nouveaux, plus pertinents pour vos utilisateurs finaux ;
et puisque cela fait partie de votre Produit même, ce changement
fonctionnel sera à la fois rapide et peu coûteux !


> Vous avez un aperçu en temps réel de l'état de votre Produit


## Mesurez le chemin parcouru, pas l'énergie dépensée

C'est souvent la même chose : on surveille le temps passé, les tâches
réalisées... Mais on a tous le même problème : passer beaucoup de temps
ne veut pas dire obtenir un résultat. **Pourquoi mesurer ce temps passé
si vous n'avez pas le résultat attendu** **?** Ce qui compte, ce sont 
uniquement les fonctionnalités.


Les outils classiques vous proposent de découper chaque besoin en tâche,
puis chaque tâche en temps. Or une tâche n'a aucun sens fonctionnel !
Vraiment ! C'est comme si vous demandiez à un chauffeur routier combien
de litres d'essence il a consommé ;  certes, c'est important d'un point de
vue financier, mais ce qui compte c'est quand même de savoir s'il a pu
livrer tous ses clients, vous ne croyez pas ?


Dans un projet informatique c'est pareil : focalisez-vous sur les
fonctionnalités développées. Après tout, c'est ce qui compte vraiment...
Uniquement !


Bien entendu, peut-être que les équipes techniques, elles, travailleront
en tâches, mais :

+ rien ne les y oblige.
+ ça ne vous concerne pas, seules les fonctionnalités vous intéressent


**On n'a jamais vu un client obtenir un bénéfice métier parce qu'une
équipe a accompli une tâche**. Non, le bénéfice ne s'obtient qu'en
fournissant un service, autrement dit une fonctionnalité.


> Le client final n'est pas content parce qu'une tâche est accomplie ;
il est content parce qu'une fonctionnalité lui est offerte et qu'elle
répond a son besoin

## Une bonne fonctionnalité sert la Vision Produit

Prenez le réflexe : demandez-vous systématiquement si votre
fonctionnalité sert votre Vision. Si ce n'est pas le cas ... Et bien
oubliez la !


A contrario, ne vous limitez pas à un cadre. Après tout, ce qui compte vraiment ce
n'est pas la somme de fonctionnalités, c'est de réussir à satisfaire
votre Vision.


Prenez GMail, de Google, par exemple. Chaque fonctionnalité est
sélectionnée pour répondre à cette vision simple : "permettre à chacun
de communiquer facilement avec ses proches". Peu importe le cadre ; du
moment qu'une fonctionnalité sert cette vision, elle est bonne.


Sans Vision, GMail ne serait qu'une application, c'est à dire un simple
webmail. Mais c'est  justement pour cela que GMail c'est :

+ un webmail
+ un service de communication instantané (GTalk) 
+ une application mobile
+ un tchat vidéo (hangout)
+ un rappel des anniversaires de vos amis
+ un carnet de contacts
+ ...


Tous ces services desservent la même vision. C'est ce qui fait que GMail
plaît autant. Et c'est cette vision qui assure la cohérence de
l'ensemble : **il vous faudra parfois refuser certaines
fonctionnalités**, même si à court terme elles semblent rentables. 


Si elles ne répondent pas à la même vision, ces fonctionnalités vont
rendre votre produit incohérent et illogique. Pourquoi dépenser de
l'argent pour rendre votre Produit illogique ? **Tout le monde aime les
choses simples, claires et cohérentes** ; pire : si vous enlevez cette
clarté, vos développeurs eux-mêmes risquent de ne plus comprendre ce que
vous voulez !


Si vous tenez absolument à ajouter une fonctionnalité qui sert une autre
vision, créez un autre projet, avec d'autres équipes, mais ne la
greffez pas artificiellement à celui-ci.


> Respecter scrupuleusement une Vision assure la cohérence et la clarté
du Produit



## Oubliez l'interface graphique

Fatigué ? Pourquoi ne pas faire un petit jeu ? Vous connaissez Google
Calendar ? mais si, vous savez, le calendrier de Google, très pratique,
que vous retrouvez sur calendar.google.com...


A votre avis :


|   Google Calendar serait-il toujours le même produit :    |                   |
| --------------------------------------------------------- | ----------------- |
| Si le site web n'affichait plus la date du jour ?         | ☐ oui ☐ non   |
| Sans page web pour y accéder ?                            | ☐ oui ☐ non   |
| S'il n'affichait pas de calendrier mensuel                | ☐ oui ☐ non   |
| S'il ne vous permettait pas d'ajouter un rendez-vous en cliquant sur le bouton "nouveau rendez-vous" ?| ☐ oui ☐ non   |
| Si Internet n’existait pas ?                              | ☐ oui ☐ non   |


Au risque de surprendre, la réponse est partout la même : "oui" ! Oui,
même si Internet n'existait pas !


Après tout, qui nous dit que le web que nous connaissons ne va pas
disparaître ? Google Calendar pourrait très bien n'exister que sur
téléphone mobile. Mieux, sans électronique. Après tout, si Google avait
existé au début du XXème siècle, il lui aurait fallu trouver un autre
moyen pour délivrer ses services.


Considérez en effet cette Vision de Google Calendar : "permettre à
chacun de connaître facilement  les événements à venir qui le
concernent". Pas besoin de page web, d'application mobile... Un simple
courrier postal pour ajouter un événement, puis quelqu'un qui vient frapper à
notre porte à chaque fois qu'un événement va arriver... C'est suffisant, non ?


Certes, commercialement ce n'est pas l'idéal, mais même si Google
Calendar changeait pour désormais envoyer quelqu'un frapper chez nous à
chaque événement, le Produit serait inchangé ; seul le support matériel
serait modifié. Autrement dit : **le support n'a aucune importance
lorsque vous décrivez votre Produit !**


Quand vous décrivez votre produit, écrivez vos fonctionnalités de sorte
à ce qu'elles soient valables, même sur internet, même sur application
mobile, et même par courrier postal. C'est la seule façon de pérenniser
votre projet. Si vous avez un site web, vos Fonctionnalités et Scénarios
ne doivent pas changer d'un pouce lorsque vous décrivez votre
application mobile.


> Focalisez-vous sur le Comportement de votre Produit, et laissez
l'interface graphique aux ergonomes et aux graphistes.


## Le scénario n'est pas un critère d'acceptation

Considérez ce scénario, mis en évidence par Liz Keogh:

    [gherkin]
    Scénario : pouvoir acheter un animal domestique adulte
        Etant donné qu'un chiot est trop petit pour être vendu
        Quand j'essaye de l'acheter
        Alors je suis informé qu'il ne peut être vendu car trop jeune

Bien. Bien ? Non, pas vraiment... Vous n'avez pas décrit votre besoin,
vous venez en réalité de fournir un Critère d'acceptation générique à
vos développeurs. Leur réaction face à ce scénario ne peut être que
"d'accord, mais à quel âge par exemple le chiot ne peut pas être vendu
?".


Tant qu'il reste des questions en suspend, quelque chose ne va pas.
N'oubliez pas que **vous décrivez vos Fonctionnalités et vos Scénarios, non
pas d'abord pour valider un travail fourni, mais avant tout pour être
sûr que tout le monde a bien compris votre besoin** et pour éviter les
allers et retours inutiles.


Chaque scénario doit contenir ses propres exemples. Notre scénario
pourrait être changé en :

    [gherkin]
    Scénario : pouvoir acheter un animal domestique adulte
        Etant donné qu'un chiot ne peut être vendu avant qu'il n'ait "2 mois"
        Et que "Médor le chien" a actuellement "1 mois"
        Quand j'essaye d'acheter "Médor le chien"
        Alors on doit me dire "Médor le chient est trop jeune. Veuillez revenir dans 1 mois"

C’est un peu plus explicite non ? Et il reste moins de questions. De
cette manière vous limitez les aller-et-venues inutiles et exprimez
votre besoin clairement.


> Si on vous demande: "Pouvez-vous me donner un exemple où cette
situation arrive?", vous n'avez pas rédigé un Scénario mais un Critère
d'acceptation. Effacez le.


## Les principales causes d'échec du BDD

Je vais être franc : cette voie de communication, le Développement
Piloté par le Comportement, n'est pas une recette miracle et peut
échouer.


Vous pouvez, comme pour tout, y perdre de l'argent si vous échouez à
appliquer ce principe fondamental : **ce qui compte c'est de réussir à
ce que chacun comprenne clairement votre besoin vis-à-vis de votre
Vision**.


Je pense que la première cause d'échec vient de la **difficulté à
identifier clairement les fonctionnalités d'un Produit**. On a tous en
tête des idées géniales, le site web qui va tuer Facebook et eBay ; le
vrai souci est de savoir comment, dans la pratique, ce site web va rendre 
service aux utilisateurs, et quelles sont les fonctionnalités qu'on va lui
offrir.


La seconde difficulté réside dans notre propension à avoir besoin d'un
support visuel pour réfléchir à quelque chose. **Il n'est pas simple de
ne se focaliser uniquement sur le Comportement d'un Produit, sans se
soucier de son apparence**, de son interface graphique. Ce sera d'autant
plus vrai si vous avez un profil technique ou si vous êtes très
familiarisé avec les nouvelles technologies. 


Pour résoudre cette difficulté, tentez systématiquement de vous
représenter votre produit sur différents supports : un ordinateur, un
téléphone, mais aussi par courrier ou par pigeon voyageur ! Bref, faites
abstraction totale du support matériel.


Ne vous focalisez pas sur le cheminement qui permet à votre application
ou site web de délivrer un service. Partez en sens inverse depuis
l'utilisateur : quel comportement peut-il avoir avec mon Produit ?
Comment mon Produit peut-il l'aider ?


Enfin, et c'est le plus important : **vous aurez besoin de vous faire
conseiller, surtout si ce n'est pas votre premier projet informatique**.
Il est quasiment impossible de réussir du premier coup à se défaire des
habitudes antérieures.


Il existe aujourd'hui de nombreuses sociétés de conseil en Agilité qui
sauront vous conseiller, surtout dans la démarche de dialogue qu'il vous
faudra engager avec vos équipes. L'investissement risque fort d'en
valoir la peine... Si vous n'en avez pas les moyens vous pouvez (très
sérieusement) effectuer en parallèle ce dialogue auprès de personnes
totalement novices dans le domaine fonctionnel abordé et peu familières
des nouvelles technologies : vos parents, grand-parents, enfants ou vos
amis ermites.


> Il n'existe pas de recette miracle. Faites abstraction de tout
support, oubliez vos habitudes et demandez de l'aide