Vous saurez tout sur le BDD

Thomas Clavier

C’est l’histoire de 3 Amis

Le truc qui part en prod c’est ce que le dev à compris.

Pourquoi ?

Se comprendre
Réduire le gâchis
Guider le développement du produit

Se comprendre

Est-on certain d’avoir compris la même chose ?

Réduire le gâchis

Rework = incompréhension du dev et/ou interprétation du dev
Influence du business sur le code

Guider le développement

Architecture émergente
Adaptation au marché
Cohésion avec la qualité

Le BDD tous les jours

Processus itératif en 3 étapes.

Étapes

Atelier de découverte

Ce que le logiciel pourrait faire.

Le BDD permet d’avoir la bonne conversation au bon moment afin de maximiser la valeur du code que vous allez produire.

Des conversations constructives

Nous utilisons des conversations structurées, appelées ateliers de découverte, qui se concentrent sur des exemples réels du système du point de vue des utilisateurs. Ces conversations permettent à notre équipe de mieux comprendre les besoins des utilisateurs, les règles qui régissent le fonctionnement du système et l’étendue de ce qui doit être fait.

Elles peuvent également révéler des lacunes dans notre compréhension, où nous avons besoin de plus d’informations avant de savoir ce qu’il faut faire.

L’examen d’une session de découverte révèle souvent des fonctionnalités de faible priorité qui peuvent être écartées de la portée d’une histoire d’utilisateur, ce qui aide l’équipe à travailler par petites étapes, améliorant ainsi leur flux.

Si vous êtes nouveau dans le BDD, la découverte est le bon endroit pour commencer. Les deux autres pratiques ne vous apporteront pas beaucoup de joie tant que vous n’aurez pas maîtrisé la découverte.

Exemples mapping

Entrainement

Formulation

Ce que le logiciel devrait faire.

Dès que nous avons identifié au moins un exemple précieux lors de nos séances de découverte, nous pouvons maintenant formuler chaque exemple sous forme de documentation structurée. Cela nous donne un moyen rapide de confirmer que nous avons vraiment une compréhension commune de ce qu’il faut construire.

Contrairement à la documentation traditionnelle, nous utilisons un support qui peut être lu à la fois par les humains et les ordinateurs, de sorte que :

Nous pouvons obtenir un retour d’information de toute l’équipe sur notre vision commune de ce que nous construisons.
Nous pourrons automatiser ces exemples pour guider notre développement de la mise en œuvre.

En écrivant cette spécification exécutable de manière collaborative, nous établissons un langage partagé pour parler du système. Cela nous aide à utiliser la terminologie du domaine des problèmes jusqu’au code.

Automatisation

Ce que le logiciel fait réellement.

Maintenant que nous avons notre spécification exécutable, nous pouvons l’utiliser pour guider notre développement de la mise en œuvre.

Prenons un exemple à la fois, nous l’automatisons en le connectant au système à titre de test. Le test échoue parce que nous n’avons pas encore implémenté le comportement qu’il décrit. Nous développons maintenant le code d’implémentation, en utilisant des exemples de niveau inférieur du comportement des composants internes du système pour nous guider si nécessaire.

Les exemples automatisés fonctionnent comme des rails de guidage, ce qui nous aide à maintenir notre travail de développement sur la bonne voie.

Lorsque nous devrons revenir et maintenir le système plus tard, les exemples automatisés nous aideront à comprendre ce que le système fait actuellement, et à apporter des modifications en toute sécurité sans rien casser involontairement.

Ce retour d’information rapide et reproductible réduit la charge des tests de régression manuels, libérant ainsi les gens pour effectuer des travaux plus intéressants, comme les tests exploratoires.

Outils

Personas
Exemples
Ubiquitous language
Gherkin

Personas

Lever une ambiguité et se projetter dans des usages différents
Fluidifier la conversation du business vers les développeurs et les utilisateurs
Élaborer la stratégie produit pour le business

Exemples

Règle sans exemple

Comment faire un nœud de chaise ?
Dessinez une étoile à 12 points

Étoile à 12 points

Exemple sans règle

KO	OK
thieGh6E	Di2ceik5D
azerTy007	aY0wae1oo
kexuCacee	somuuS4ge

Exemple sans règle

KO	OK	Règle
thieGh6E	Di2ceik5D	9 charactères
azerTy007	aY0wae1oo	pas dans le dico
kexuCacee	somuuS4ge	des chiffres et des lettres

Language Commun co-construit

Ubiquitous Language

Dans les exemples

Changer les critères de segmentation sur la famille lave linge
Changer les attributs du noeud de nomenclature de niveau 6

Dans les exemples

Des mots polysémiques.

Dans le domaine des vegétaux la tomate est un fruit
Dans le domaine de la cuisine, la tomate est un légume
Dans le domaine de l’école, la tomate est un jeu
Dans le domaine du spectacle, la tomate est un feedback

Dans le code

Imaginez un distributeur avec :

une nomenclature de référencement
une nomenclature de vente

Gherkin

Scenario = un exemple

Feature = une fonctionnalité

Français

Automatisable

UX / UI

1955

2015

Durée de vie des tests

Quand je m’identifi.
Quand je rentre mon login, mon mot de passe et que je clic sur valider.

3 étapes (Découvrir, Formaliser, Automatiser)
Des outils (Exemples, Personas, Exemple Mapping, Ubiquitous language, Gherkin)
Pour (se comprende, réduire le gachi, guider le développement)

Partagez vos expériences

	@thomasclavier @thomas@libre-entreprise.com
	https://ajiro.fr/talks/conference-bdd/