352 lines
13 KiB
Markdown
352 lines
13 KiB
Markdown
# Exprimez votre besoin
|
||
|
||
|
||
## Tous la même grammaire
|
||
|
||
Les spécifications classiques, on l'a vu, échouent souvent : elles
|
||
acceptent mal le changement, sont souvent lourdes et ne concernent pas
|
||
toujours que le besoin métier.
|
||
|
||
|
||
Pour remédier à cela, il est possible d'utiliser une autre approche,
|
||
celle préconisée par le Développement Piloté par le Comportement.
|
||
|
||
|
||
"Quel terme barbare !" me direz-vous. C'est vrai. Mais, en fait, rien de
|
||
technique ou de geek derrière ce terme. C'est simplement une démarche
|
||
qui consiste à communiquer avec vos développeurs d'une autre manière, de
|
||
sorte qu'il vous comprennent.
|
||
|
||
|
||
C'est cette démarche que je vous propose de découvrir à partir de
|
||
maintenant.
|
||
|
||
|
||
Cette approche a au moins trois avantages :
|
||
|
||
+ L'écrit sert à la fois à spécifier et à échanger avec les équipes
|
||
+ Le changement est mieux géré
|
||
+ Vous savez à tout instant ce qui est fait et ce qu'il reste à faire
|
||
|
||
|
||
Pour au moins un inconvénient :
|
||
|
||
+ L'investissement et la disponibilité du Propriétaire du Produit doivent
|
||
être importants
|
||
|
||
|
||
Cette approche se base sur la rédaction des spécifications sous un
|
||
formalisme différent, dénommé généralement Gherkin. Ce formalisme n'est
|
||
pas obligatoire, mais il a été prouvé à plusieurs reprises qu'il est
|
||
pratique et répond bien aux problématiques que vous rencontrerez
|
||
probablement.
|
||
|
||
|
||
Si vous souhaitez faire du Développement Piloté par le Comportement
|
||
(Behaviour Driven Development en anglais, ou BDD), chaque acteur de
|
||
votre projet doit apprendre à lire et à comprendre ce formalisme. Pas de
|
||
panique, le coût d'apprentissage est quasi nul ; c'est justement l'un
|
||
des nombreux atouts de Gherkin.
|
||
|
||
|
||
## Décrivez vos Fonctionnalités métiers
|
||
|
||
Vous avez votre Vision du Produit, il est temps d'expliquer ce que vous
|
||
attendez aux développeurs.
|
||
|
||
|
||
Rien de plus simple : commencez par identifier les aspects fonctionnels
|
||
que vous souhaitez qu'ils développent, et ce en les décrivant avec une
|
||
courte phrase. Juste une phrase, courte, pas plus. Cette phrase sera le
|
||
titre de votre fonctionnalité.
|
||
|
||
|
||
**Chaque fonctionnalité doit pouvoir se distinguer des autres par son
|
||
titre**. Prenez les fonctionnalités suivantes :
|
||
|
||
[gherkin]
|
||
# Distinguez vos fonctionnalités en leur donnant un titre :
|
||
Fonctionnalité : Retirer de l’argent au distributeur
|
||
Fonctionnalité : Consulter le solde de son compte au distributeur
|
||
|
||
Il est facile de les distinguer et de les comprendre non ?
|
||
|
||
|
||
Identifier clairement ces fonctionnalités est important : cela vous
|
||
permettra de les prioriser plus facilement.
|
||
|
||
|
||
Bon, vous allez me dire qu'une petite phrase de rien du tout ça laisse la
|
||
place à beaucoup d'ambiguïtés ; et vous aurez bien raison !
|
||
|
||
|
||
Vous le savez, un Produit n'est rien sans un utilisateur pour
|
||
l'utiliser. **Précisez donc qui est l'utilisateur de votre
|
||
fonctionnalité** :
|
||
|
||
[gherkin]
|
||
# Précisez qui est l’acteur bénéficiaire de votre fonctionnalité :
|
||
En tant que rôle
|
||
En tant que administrateur du site
|
||
En tant que conseiller clientèle
|
||
En tant que ...
|
||
|
||
Voilà une bonne chose de faite ! **Identifiez maintenant le Service
|
||
rendu par votre fonctionnalité**. Je conseille toujours de voir le
|
||
service comme ni plus ni moins que ce que votre commercial entend lorsqu'il
|
||
dit "c'est génial, en tant que ... vous pouvez faire ça !". Par exemple
|
||
:
|
||
|
||
[gherkin]
|
||
# Identifiez le service délivré par votre fonctionnalité à l’utilisateur :
|
||
Je peux un service rendu
|
||
Je peux retirer de l’argent au distributeur
|
||
Je peux connaître la quantité d’argent qu’il me reste sur mon compte
|
||
Je peux ...
|
||
|
||
On commence déjà à y voir plus clair. **Il ne reste plus qu'à préciser
|
||
le bénéfice métier** de votre fonctionnalité. Car oui, une
|
||
fonctionnalité sans bénéfice pour l'utilisateur ne sert à rien. Si vous
|
||
ne voyez pas de bénéfice pour votre fonctionnalité, c'est sans doute qu'elle ne
|
||
mérite pas d'être développée. Décrivez ce bénéfice ainsi :
|
||
|
||
[gherkin]
|
||
# Décrivez le bénéfice fonctionnel obtenu par votre fonctionnalité :
|
||
De telle sorte que bénéfice attendu
|
||
De telle sorte que je puisse obtenir de l’argent même quand la banque est fermée
|
||
De telle sorte que ...
|
||
|
||
Ce qui fait que **toute fonctionnalité peut être décrite, de manière
|
||
explicite, en quatre courtes lignes** :
|
||
|
||
[gherkin]
|
||
Fonctionnalité : Retirer de l’argent au distributeur
|
||
En tant que client de la banque
|
||
Je peux retirer de l’argent au distributeur
|
||
De telle sorte que je puisse obtenir de l’argent même quand la banque est fermée
|
||
|
||
N'importe quel membre de votre équipe comprendra ce qu'est cette
|
||
fonctionnalité. Faites attention à n'employer que le vocabulaire de votre
|
||
Langue Commune pour éviter toute ambiguïté.
|
||
|
||
|
||
## Des scénarios pour vos fonctionnalités
|
||
|
||
Un titre, un rôle, le service rendu et le bénéfice métier c'est déjà pas
|
||
mal. Mais en général ça ne va pas suffire : vous pouvez avoir envie
|
||
d'illustrer vos fonctionnalités.
|
||
|
||
|
||
C'est le rôle des scénarios. **Chaque fonctionnalité peut contenir un
|
||
ensemble de scénarios. Ces scénarios doivent tous être clairs, uniques
|
||
et explicites**. Ils représentent le comportement concret que vous
|
||
attendez pour votre fonctionnalité. Par exemple :
|
||
|
||
[gherkin]
|
||
# Un Scénario est une situation concrète de votre Fonctionnalité :
|
||
Fonctionnalité : Retirer de l’argent au distributeur
|
||
|
||
Scénario : Retirer de l’argent avec une carte valide
|
||
Scénario : Retirer de l’argent avec une carte expirée
|
||
Scénario : Retirer de l’argent sur un distributeur qui ne contient
|
||
plus d’argent
|
||
Scénario : ...
|
||
|
||
La réalisation (ou non) dans votre application de ces scénarios détermine l'avancée de votre
|
||
fonctionnalité.
|
||
|
||
|
||
Il est possible que ces scénarios évoluent : certains seront réalisés
|
||
tôt, d'autres seront réalisés plus tard ou seront modifiés... Dans tous
|
||
les cas, **jeter un oeil à l'avancée de ces scénarios vous permettra de
|
||
maîtriser l'avancée de votre fonctionnalité**.
|
||
|
||
|
||
Vous vous en doutez, il peut arriver qu'une simple phrase ne suffise pas
|
||
à décrire avec précision un scénario. Il sera alors temps d'y introduire
|
||
un contexte, un événement déclencheur ou un résultat attendu.
|
||
|
||
|
||
Le contexte du scénario est introduit par l'expression "étant donné". Il situe les
|
||
conditions d'existence de votre scénario :
|
||
|
||
[gherkin]
|
||
# Un Scénario s’inscrit dans un contexte, une situation initiale :
|
||
Scénario : ...
|
||
Etant donné que tel contexte existe
|
||
Etant donné que que je n’ai plus d’argent sur mon compte
|
||
Etant donné que ma carte est expirée
|
||
Etant donné que ...
|
||
|
||
Toute interaction de l'utilisateur avec votre produit peut se traduire
|
||
sous forme d'événement. Un événement est le déclencheur de votre
|
||
scénario, qui vient juste après que le contexte initial soit situé :
|
||
|
||
[gherkin]
|
||
# Un Scénario se démarque par un événement :
|
||
Scénario : ...
|
||
...
|
||
Quand tel événement déclencheur survient
|
||
Quand je demande à retirer de l’argent
|
||
Quand je demande le solde de mon compte
|
||
Quand ...
|
||
|
||
Si chaque action a une conséquence, il en va de même pour les événements :
|
||
chaque événement attend un résultat, exprimé par l'expression "alors" :
|
||
|
||
[gherkin]
|
||
# Chaque Scénario aboutit à un résultat :
|
||
Scénario : ...
|
||
...
|
||
Alors tel résultat est attendu
|
||
Alors je reçois 20 euros
|
||
Alors ma carte est aspirée
|
||
Alors ...
|
||
|
||
Toute cette syntaxe, qui permet de rendre vos fonctionnalités
|
||
explicites, sera comprise par vos développeurs. Et en plus elle n'est
|
||
pas très compliquée, si ?
|
||
|
||
|
||
Au final, voici une fonctionnalité plus complète :
|
||
|
||
[gherkin]
|
||
# Toute personne qui connaître votre Langue Commune comprend
|
||
# votre fonctionnalité :
|
||
|
||
Fonctionnalité : Retirer de l’argent au distributeur
|
||
En tant que client de la banque
|
||
Je peux retirer de l’argent au distributeur
|
||
De telle sorte que je puisse obtenir de l’argent
|
||
même quand la banque est fermée
|
||
|
||
Scénario : Retirer de l’argent avec une carte valide et un
|
||
compte approvisionné
|
||
Etant donné que je détiens un compte bancaire soldé de 100 euros
|
||
Et que ma carte expire l’an prochain
|
||
Quand je demande à retirer 20 euros
|
||
Alors je reçois 20 euros
|
||
Et ma carte m’est restituée
|
||
|
||
Scénario : Retirer de l’argent avec une carte expirée
|
||
Etant donné que ma carte est expirée
|
||
Quand je demande à retirer 20 euros
|
||
Alors ma carte est aspirée
|
||
|
||
|
||
## Illustrez le tout avec des exemples
|
||
|
||
Ce formalisme est utile. Il n'est en aucun cas obligatoire bien entendu,
|
||
mais il a démontré son efficacité, et a l'énorme avantage d'être **clair
|
||
tout autant pour les fonctionnels que pour les développeurs.**
|
||
|
||
|
||
Maintenant, ce formalisme peut manquer de concret. Qu'à cela ne tienne,
|
||
vous pouvez y ajouter vos exemples. Car on est bien d'accords, **rien de
|
||
mieux que des exemples**. Prenons celui-ci :
|
||
|
||
[gherkin]
|
||
# Votre fonctionnalité peut contenir un exemple :
|
||
|
||
Scénario : Retirer de l’argent avec un compte approvisionné
|
||
Etant donné que ma carte expire l’an prochain
|
||
Quand je demande à retirer "20" euros
|
||
Alors je reçois "20" euros
|
||
|
||
Bon, c'est simple, mais limité, car cela nous oblige à recopier le
|
||
scénario autant de fois que nous avons d'exemples. Heureusement, notre
|
||
grammaire est riche, et vous pouvez utiliser la syntaxe suivante (votre
|
||
scénario devient alors un Plan du scénario) :
|
||
|
||
[gherkin]
|
||
# Votre fonctionnalité peut contenir plusieurs exemples facilement :
|
||
|
||
Plan du Scénario : Retirer de l’argent avec un compte approvisionné
|
||
Etant donné que ma carte expire l’an prochain
|
||
Quand je demande à retirer "<montant-demandé>" euros
|
||
Alors je reçois "<montant-reçu>" euros
|
||
|
||
Exemples :
|
||
| montant-demandé | montant-reçu |
|
||
| 20 | 20 |
|
||
| 1000 | 1000 |
|
||
| 50 | 50 |
|
||
|
||
Pratique non ? Les symboles < et \> indiquent une valeur d'exemple, à
|
||
rechercher dans le tableau juste en dessous.
|
||
|
||
Le tableau est dessiné grâce au caractère "pipe". Si vous ne savez pas le situer
|
||
sur votre clavier, il suffit de taper `Alt Gr" + 6`, ou `Alt + Maj + L` si vous
|
||
utilisez un Mac. Rassurez-vous, comme vous le verrez par la suite, il existe des
|
||
outils graphiques pour vous faciliter la vie.
|
||
|
||
## Travaillez en équipe
|
||
|
||
Vous êtes maître de votre Produit, et c'est vous qui décidez de vos
|
||
Fonctionnalités. Par contre, n'oubliez pas que **le dialogue et
|
||
l'échange sont primordiaux pour éviter les ambiguïtés dans votre
|
||
projet**.
|
||
|
||
|
||
Lorsque vous allez rédiger vos scénarios, voici ce qui risque de se
|
||
passer :
|
||
|
||
+ Vous allez devoir les expliquer à votre équipe technique lorsque vous les leur fournirez
|
||
+ Vous n'allez peut-être pas penser à tout, et vos équipes devront vous solliciter très (trop) régulièrement pour des aspects que vous aurez oubliés
|
||
+ Certains de vos scénarios ne seront pas clairs ou n'emploieront pas le vocabulaire de la Langue Commune (on a toujours tendance à se trouver soi-même très clair ; ce n'est pas toujours vrai...)
|
||
+ L'équipe risque de ne pas se sentir suffisamment impliquée
|
||
|
||
|
||
Ces écueils ne sont bien sûr pas systématiques, mais le risque est là.
|
||
Pourquoi prendre ce risque alors que la solution est simple ?
|
||
|
||
|
||
Il suffit en effet de faire participer toutes les équipes lors de la
|
||
rédaction des scénarios. Attention, il ne s'agit pas de laisser
|
||
n'importe qui faire n'importe quoi... Non, **c'est à vous d'expliquer
|
||
votre besoin**, dans la Langue Commune, et **ensuite vous allez ensemble
|
||
le traduire en scénarios**, de telle sorte que tous comprennent
|
||
clairement ce que vous attendez d'eux.
|
||
|
||
|
||
Pour résumer, écoutez les remarques de vos équipes lors de la rédaction
|
||
des scénarios. Idéalement, vous devriez entendre des "oui mais qu'est-ce
|
||
qui se passe si..." et "je ne comprend ce que devient...". Si c'est le
|
||
cas, le pari est réussi !
|
||
|
||
|
||
Dans tous les cas, gardez vos scénarios clairs et concis. Personne n'a
|
||
envie de lire des scénarios de 20 ou 30 lignes...
|
||
|
||
|
||
> "Ecrivez vos scénarios avec l'équipe technique ; le temps passé sera
|
||
compensé par le gain de compréhension et l'inutilité d'avoir à faire des
|
||
va-et-vient incessants au cours du développement"
|
||
|
||
|
||
## Des assistants visuels
|
||
|
||
Vous aviez déjà le vocabulaire (la Langue Commune), vous voici désormais
|
||
avec la grammaire nécessaire pour exprimer votre besoin. Mais on est
|
||
tous les mêmes : personne n'aime pas la grammaire !
|
||
|
||
|
||
Après tout, si votre véritable objectif est de vous focaliser sur
|
||
l'expression de votre besoin, sur la description du comportement de
|
||
votre Produit, à quoi bon se concentrer sur la manière de l'exprimer ?
|
||
|
||
|
||
Pour vous simplifier la vie il existe un certain nombre d'outils qui
|
||
vont vous assister dans la rédaction de vos Fonctionnalités. Ils vont
|
||
vous permettre de rédiger vos features selon une approche plus agréable,
|
||
tandis même qu'ils vont présenter à vos développeurs votre besoin sous
|
||
forme de fichiers clairs qu'ils pourront directement exploiter.
|
||
|
||
|
||
|
||
Il existe plusieurs outils, qui ont tous leurs avantages. On peut penser
|
||
par exemple à BehatViewer, ou à BehatWizard... N'hésitez pas à demander
|
||
vos équipes techniques de vous installer ces outils.
|
||
|
||
|