L’objectif du product Owner est de maximiser la valeur du produit tout en respectant le budget et le délai. Il sert d’interface entre l’équipe technique et le métier. Pour favoriser la collaboration et optimiser la communication entre l’ensemble des acteurs projet, il peut s’appuyer sur la technique Behavior Driven Development (BDD).
BDD
Le BDD consiste à décrire le comportement attendu par le produit sous forme de scénarios avec un langage compréhensible par tout le monde.
Cette technique permet de rationaliser les développements en réduisant les écarts de communication et en permettant une collaboration continue.
Dan North décrit le BDD ainsi : “Using examples at multiple levels to create shared understanding and surface certainty to deliver software that matters.”
Le BDD est basé sur la collaboration, pour que cette technique fonctionne, il est essentiel que les scénarios soient identifiés avec la participation de plusieurs profils : développeurs, testeurs, Product Owner, utilisateurs finaux…
L’idée est de s’aligner sur la même vision et d’identifier l’ensemble des comportements en se basant sur des exemples concrets avant le début des développements.
Différence entre BDD, ATDD et TDD
L’ATDD (Acceptance Test Driven Developement) consiste à préciser le besoin par la définition des critères d’acceptation, on va identifier les tests fonctionnels avant de commencer le développement.
La méthode TDD est une méthode de développement logiciel dans laquelle l’écriture des tests dirige l’écriture du code source. C’est une technique qui garantit la bonne implémentation technique mais non la couverture du besoin fonctionnel. On peut avoir un code valide techniquement mais qui ne répond pas au besoin fonctionnel.
Le BDD se situe entre l’ATDD et le TDD.
L’ATDD identifie le besoin fonctionnel de façon macro, le BDD vient enrichir ce besoin par la spécification du comportement applicatif et guider le développement d’une fonctionnalité et le TDD arive à la fin il prend le relai en guidant l’implémentation technique des besoins.
Avantages
- Une communication forte entre les membres de l’équipe projet : les scénarios sont réalisés de façon collective en utilisant un langage de communication commun
- Une documentation vivante : le langage Gherkin peut être directement exécutable et testable via des outils comme Cucumber ou Specflow
- Un développement guidé par le comportement attendu : ce qui permet d’assurer la qualité fonctionnelle des livrables
- Une cohérence technico-fonctionnelle : les scénarios rédigés par les développeurs sont guidés par la technique et ne porte pas assez la vision des utilisateurs, lors de la rédaction des scénarios le PO peut ne pas identifier les restrictions techniques…
- Un gain du temps lors de la préparation de la démonstration : le déroulement d’une démonstration peut se baser sur les scénarios identifiés de façon collective
Inconvénients
- Disponibilité du client
- Vendre cette pratique aux “chefs” car l’identification de l’ensemble des scénarios peut être coûteuse
Source : BDD - Dan North
