272 lines
12 KiB
Markdown
272 lines
12 KiB
Markdown
|
# 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 !
|