12 KiB
Comprenez (enfin!) ce que votre client vous demande
Votre client ne parle pas la même langue que vous. Comment comprendre ce qu'il vous demande dans ce cas ? Certains vous répondront : "utilisez UML". D'autres vous diront qu'il faut demander à votre client de s'exprimer sous forme de "si...alors". J'imagine que cela doit être possible dans certain cas. Mais dans la majorité des situations, exiger de vos clients qu'ils apprennent l'UML, ou leur demander de formaliser leur pensée sous forme de logique booléenne, est un contre-sens ! Ils n'y arriveront pas efficacement : ce n'est pas leur métier, et probablement pas leur mode de pensée.
C'est pour cela qu'il existe ce que l'on appelle le "Développement piloté par le Comportement" ("Behavior Driven Development", ou "BDD" en anglais). Ce qui se cache derrière ce terme barbare est en réalité très simple : il s'agit d'une démarche pour faciliter la communication entre fonctionnels et techniques, démarche soutenue par l'utilisation d'une langue et d'une grammaire commune.
Cette grammaire commune (appelée "Gherkin") est simple, facile à apprendre, et compréhensible tout autant par un informaticien que par votre voisin, votre conjoint(e)..., et par là-même par votre client.
Utiliser cette grammaire vous offrira un certain nombre d'avantages :
- vous éviterez les quiproquos
- les spécifications vous serviront de documentation
- il sera plus facile d'identifier et de gérer les changements fonctionnels de dernière minute
- vous saurez à tout moment ce qu'il vous reste à faire
Attention, le Développement piloté par le comportement a un pré-requis majeur et non négociable : le client doit s'investir. Il faudra que le client (ou son représentant fonctionnel) soit disponible pour répondre à chacune de vos questions, en permanence. Si personne autour de vous n'est prêt à s'investir pour exprimer le besoin clairement, oubliez l'idée de pratiquer le Développement piloté par le comportement : vous n'aurez pas les moyens d'y parvenir.
Gherkin est une grammaire accessible à tous pour structurer l'expression de besoin
Le besoin doit être exprimé par des Fonctionnalités
Concrètement, comment démarrer ? La première tâche revient à votre client. C'est lui qui va devoir recenser la liste des Fonctionnalités qu'il souhaite voir dans son application.
Pour cela, il va devoir identifier chaque fonctionnalité par un titre simple, court, explicite et unique :
[gherkin]
# Le client va distinguer les fonctionnalités en leur donnant un titre
Fonctionnalité: Avoir accès à la liste des animaux de compagnie
Fonctionnalité: Choisir un animal de compagnie
Fonctionnalité: Acheter un animal de compagnie
Fonctionnalité: ...
Il est impératif qu'à cette étape les titres des fonctionnalités soient clairs et explicites.
Ensuite, il va lui suffire de contextualiser un peu cette fonctionnalité. Par exemple, il devra indiquer qui est le bénéficiaire de cette fonctionnalité :
[gherkin]
En tant que vendeur
En tant que acheteur
En tant que propriétaire de la boutique
En tant que ...
Vous aurez donc désormais connaissance de l'acteur bénéficiaire de la fonctionnalité. Il reste encore à identifier le service offert par la fonctionnalité. C'est cela que vous aurez, finalement, à programmer :
[gherkin]
Je veux acheter un animal de compagnie
Je veux connaître la liste des animaux de compagnie de mon magasin
Je veux connaître la liste des vendeurs
Je veux ...
Pour lever toute ambiguïté, il est important pour vous de comprendre quel est le bénéfice de la fonctionnalité que vous aller développer : à quoi sert-elle vraiment ?
Après tout, c'est indispensable de comprendre et de connaître le pourquoi de votre métier. Lorsque vous travaillez, le fruit de votre travail est vraiment utile ; et il est toujours gratifiant de voir que l'on a rendu service à quelqu'un. C'est pour cela qu'il est important que le client exprime le bénéfice obtenu par la fonctionnalité :
[gherkin]
De telle sorte que je puisse repartir avec un nouveau compagnon
De telle sorte que je sache s'il me faut renouveler le stock
De telle sorte que je puisse organiser les congés de chacun
De telle sorte que ...
Chaque fonctionnalité peut donc être exprimée en quatre lignes, très simples et compréhensibles par tous :
[gherkin]
Fonctionnalité : Connaître la liste des animaux de compagnie disponibles
En tant que vendeur
Je veux connaître la liste des animaux de compagnie disponibles à la vente
De telle sorte que je sache s'il me faut renouveler le stock
Pratique non ? Cette manière d'exprimer les fonctionnalités (dénommée "Gherkin"), est simple, mais surtout est compréhensible par tous. C'est le rôle de votre client (ou fonctionnel) de recenser l'ensemble des fonctionnalités du projet de cette manière. Mais, vous vous en doutez, cela ne suffit pas. Il va falloir maintenant comprendre en détail chaque fonctionnalité ; c'est un travail que vous ferez en commun
Gherkin permet de décrire des fonctionnalités
Vous êtes un journaliste : interviewez !
Chaque Fonctionnalité peut donc être traduite en quatre petites phrases. Mais dans la majorité des cas cela ne suffira pas : il reste des ambiguïtés, ce n'est pas très précis...
C'est là que vous entrez en scène. A partir du moment où les fonctionnalités sont décrites dans leurs grandes lignes, vous allez devoir les détailler. Oui, vous-même ! Comment ? Tout simplement en prenant quelques instants la casquette d'un journaliste : interviewez votre fonctionnel !
Attention, je vous parle d'une vraie interview. Prenez le temps, pour chaque Fonctionnalité, de poser un maximum de questions pertinentes : "et qu'est-ce qui se passe quand ... ?" ; ou encore "je ne comprend pas le bénéfice tiré de cette fonctionnalité pour l'utilisateur."
Posez, donc, toutes ces questions. Et surtout planifiez systématiquement un moment, avant chaque itération, où votre fonctionnel et l'ensemble des équipes techniques (oui, toutes les personnes qui sont concernées), vont se réunir pour cette interview.
J'insiste : il ne s'agit pas d'une réunion facultative : comment ferait-on sans cela pour être sûr d'avoir bien compris la demande du client ? Le temps passé n'est pas perdu, loin de là : c'est du temps de gagné sur la future maintenance, les futures recettes et les futurs va-et-vient entre le client et les équipes techniques.
L'objectif de ces interviews est de comprendre exactement, sans aucune ambiguïté possible, ce qui vous est demandé fonctionnellement. Pour cela, il faudra découper les prochaines Fonctionnalités que vous aurez à développer en "Scénarios".
Chaque Fonctionnalité peut être découpée en Scénarios
Chaque Fonctionnalité peut être décrite en quatre points :
- un titre
- un rôle
- un service rendu
- un bénéfice métier
Mais cela ne suffira probablement pas. Il reste des questions en suspens. C'est le rôle des Scénarios de lever ces incertitudes. Ce sera d'autant plus vrai qu'ils seront rédigés en commun avec le fonctionnel et les équipes techniques.
Chaque Fonctionnalité peut contenir un ou plusieurs Scénarios, et chaque Scénario doit pouvoir se distinguer facilement des autres par un titre :
[gherkin]
Fonctionnalité : acheter un animal de compagnie
(...)
Scénario: acheter un animal de compagnie disponible à la vente
Scénario: tenter d'acheter un animal de compagnie qui est trop jeune
Scénario: tenter d'acheter un animal de compagnie qui est réservé
...
Votre travail de développeur va consister à rendre ces Scénarios effectifs dans l'application. En identifiant les Scénarios réalisés et ceux qui ne le sont pas vous saurez donc exactement ce qu'il vous reste à faire.
Vous vous en doutez : un simple titre ne suffit pas ; il va falloir compléter chaque Scénario. Posez par exemple cette question : "dans quel cadre ce scénario se situe t-il ?". Cela vous permettra de connaître le Contexte de votre Scénario:
[gherkin]
Scénario : ...
Etant donné que tel contexte existe
Etant donné que je souhaite acheter un chien
Etant donné qu'il n'y a plus un seul animal disponible
Etant donné ...
Une application consiste généralement à réagir à des événements. Précisez-donc quels sont ces événements :
[gherkin]
Scénario : ...
(...)
Quand j'essaye d'acheter un chien
Quand je regarde quels sont les animaux disponibles
Quand ...
Dès lors, il ne vous reste plus qu'à préciser le Résultat attendu lorsque cet événement survient :
[gherkin]
Scénario : ...
(...)
Alors je peux repartir avec un petit chien
Alors je dois être informé que le chien est trop jeune pour être
vendu
Alors ...
Cette syntaxe, simple, que l'on nomme Gherkin, va suffire dans la majorité des cas pour que le fonctionnel puisse exprimer son besoin et surtout pour que vous puissiez comprendre sans ambiguïté ce qui vous est demandé.
Voici un exemple de Fonctionnalité :
[gherkin]
Fonctionnalité : acheter un chiot
En tant que client du magasin
Je veux pouvoir acheter un chiot
De telle sorte que je puisse avoir un animal de compagnie
Scénario : acheter un chiot disponible à la vente
Etant donné qu'un chiot est disponible en stock
Quand j'achète un chiot
Alors on me donne un chiot
Scénario: acheter un chiot sevré
Etant donné qu'un chiot est trop jeune pour être vendu
Quand j'essaye d'acheter ce chiot
Alors je suis informé qu'il est trop jeune pour être vendu
Pratique non ?
## Demandez (exigez) des exemples précis
Rappelez-vous que l'objectif du Développement piloté par le comportement est de lever toutes les ambiguïtés. Pourtant, dans le scénario suivant, il reste des questions :
[gherkin]
Scénario: acheter un chiot sevré
Etant donné qu'un chiot est trop jeune pour être vendu
Quand j'essaye d'acheter ce chiot
Alors je suis informé qu'il est trop jeune pour être vendu
Ces questions sont nombreuses :
- à partir de quel âge un chiot peut-il être vendu ?
- quel est l'âge du chiot que l'on essaye d'acheter ?
- comment suis-je informé ? par quelle phrase ?
Autant de questions auxquelles, si vous ne les posez pas maintenant, vous serez obligé de répondre vous-même, avec tous les risques que cela comporte, notamment celui de devoir recommencer votre développement !
Heureusement, il est tout à fait possible, avec Gherkin, de préciser des valeurs à utiliser. Il suffit de les encadrer dans des guillemets :
[gherkin]
Scénario : acheter un chiot sevré
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 chien est trop jeune !"
Pas mal d'ambiguïtés sont levées non ? Et ça ne prend pas beaucoup plus de temps à écrire. Maintenant, il peut arriver qu'un seul exemple ne suffise pas ; il en faudrait plusieurs. Pas de problèmes, Gherkin vous permet d'utiliser des exemples facilement ; il suffit de les passer sous forme de tableaux. Les variables sont alors à encadrer par les symboles "<" (plus petit que) et ">" (plus grand que).
[gherkin]
Plan du Scénario : acheter un chiot sevré
Etant donné qu'un chiot ne peut être vendu avant qu'il n'ait "2 mois"
Et que "<nom-du-chien>" a actuellement "<age-du-chien>"
Quand j'essaye d'acheter "<nom-du-chien>"
Alors on doit me dire "<nom-du-chien> est trop jeune !"
Exemples :
| nom-du-chien | age-du-chien |
| médor | 1 mois |
| rex | 1 mois et 3 jours |
| rantanplan | 15 jours |
Remarquez qu'il ne s'agit plus dans ce cas d'un "Scénario" mais d'un "Plan du Scénario".
Vous voici donc avec un besoin simple, découpé et exprimé clairement. A vous de jouer !