14 KiB
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 (hébergé, payant) ou 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