Dans cette vidéo vous verrez au travers du BDD pourquoi il est important pour l’équipe métier de challenger les propos avec l’équipe technique.
Dans cette logique, vous apprendrez comment gagner en finesse pendant l’étape de définition des User Stories.
Également, le DDD vous prouvera l’utilité de définir un langage commun compréhensible pour tous, afin que les différentes équipes cernent les User Stories définies précédemment de la même manière.
Enfin, le TDD vous montrera comment gagner du temps en écrivant du code propre par l’intermédiaire de tests préalables.
Behavior Driven Development ou BDD pour un langage compris de tous
D’après Michaël, le Behavior Driven Development (BDD) est une approche de découverte par l’exemple ! Cette approche vise notamment à éviter tout quiproquo entre les différents acteurs impliqués au sein d’un projet.
L’idée sous-jacente à cette approche est d’illustrer les Acceptance Criteria (règles de gestion) à travers des exemples simples, concrets et ultra-précis.
Cette première étape permet tout simplement de définir les tenants et aboutissants d’un projet de manière très simpliste. Ainsi, les besoins fonctionnels sont plus facilement apprivoisés et ça permet d’éviter toutes confusions en amont du projet.
Le résultat c’est un langage commun parlé par tous les acteurs, qu’ils fassent partis de l’équipe métier ou bien technique.
Domain Driven Design ( DDD) la deuxième étape, pour illustrer
Le Domain Driven Design quant à lui est une approche complète et approfondie de design. Un des objectifs de cette approche de développement logiciel est de faire en sorte que le code source manifeste fortement le langage commun, définit auparavant lors de l’étape BDD, mais aussi qu’il émerge des concepts de domain modeling spécifiques et adaptés au domaine.
Michael parle également de deux outils à disposition dans cette approche:
- Le context-mapping : qui est un schéma de la structure, des grands ensembles et de tous ses acteurs dans le but de visualiser les flux d’échanges Upstream/Downstream
- Ainsi que du Bounded-context : il s’agit de définir un langage commun à tous afin de vulgariser le jargon de chaque parties pour dresser une seule et unique interprétation possible.
Test Driven Development (TDD) : multiplier les tests pour coder sans bugs
La dernière partie du meet-up aborde le Test Driven Development. En bref, cette discipline de programmation TDD repose sur un précepte de clean-coding. Elle vise ainsi à écrire chaque test avant d’écrire le code source d’un programme. ca a pour effet d’accélérer drastiquement les développements tout en assurant de forts bénéfices tels que :
- la concentration sur la vision cliente d’un cas d’utilisation du logiciel
- l’absence de code mort
- un code fortement malléable sans risque
- une living documentation
- ainsi que plein d’autres aspects étonnants mis en avant par Michaël dans la vidéo
Si vous voulez en savoir plus sur ces méthodes, nous vous invitons à consulter les articles de Michaël Azerhad.
Cet article vous a plu ? N’hésitez pas à suivre notre actualité sur notre blog.
