337 lines
14 KiB
Markdown
337 lines
14 KiB
Markdown
# 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
|