Si vous travaillez en Agile vous avez sûrement déjà entendu parlé du BDD. Le sujet est d’ailleurs assez fréquent sur ce blog. J’ai en effet écrit plusieurs articles à son propos. Les derniers étant liés à la maturité du BDD et à des dérives que j’ai souvent observées.
Le sujet d’aujourd’hui n’est pas tant sur le BDD tel qu’il est en théorie mais plutôt sur le « comment » implémenter avec succès ce dernier.
Les limites du BDD « by the book »
Sur le papier, pour faire du BDD il faut être dans une équipe « Agile » qui respecte la construction des US avec une norme INVEST, qui travaille avec des Definition of Done et Ready bien suivies, qui travaille sur un produit (ou partie d’un produit) où l’on développe des fonctionnalités qui modifient son comportement… Mais aussi une équipe soudée qui a un vrai esprit d’équipe et une envie de s’améliorer.
Cela fait beaucoup de choses… Et d’ailleurs ces équipes, si elles n’ont pas encore adaptées le BDD ont généralement mis en place des pratiques assez proches ou qui couvrent déjà en partie les apports du BDD.
Première limite: intérêt limité du déploiement du BDD dans les équipes qui répondent aux prérequis
Je ne vais pas y aller par 4 chemins, l’équipe idéale pour implémenter le BDD n’a pas vraiment besoin de l’implémenter!
Les équipes qui ont le plus besoin du BDD (et de ses apports) sont les équipes qui n’ont pas l’ensemble de ce qui parait être les prérequis pour mettre en place le BDD.
Seconde limite: les équipes qui répondent aux prérequis sont rares
Une autre limite au BDD « by the book » est cette contrainte d’être dans une équipe qui travaille dans un environnement « vraiment » agile.
Sur le papier on se dit que la grande majorité des équipes travaillent sur un produit (ou partie d’un produit) en particulier qu’elle fait évoluer. Dans les faits ce n’est pas le cas.
Dans les grandes organisations on peut trouver beaucoup d’équipes qui travaillent avec des contraintes poussant à intégrer (au forceps) de l’agile dans un contexte cycle en V, des équipes en charge de plusieurs produits, des équipes avec un métier qui n’a pas forcément encore compris l’agile (et demande tout en une fois pour une date précise), des équipes en charges de demandes d’évolutions sur des progiciels externes…
Si l’on suit le BDD « By the book » alors ces équipes ne peuvent pas faire du BDD… Alors que le BDD a beaucoup à leur apporter!
Réussir l’implémentation du BDD
Les bénéfices attendus
Que veut concrètement dire « réussir l’implémentation du BDD » ? Les réponses sont particulièrement nombreuses. Plus que savoir si une équipe a une pratique du BDD qui suit la théorie, je pense pense qu’il faut mesurer la réussite de l’implémentation du BDD par l’atteinte d’objectifs concrets.
Le BDD, comme toute pratique (ou outil) existe pour répondre à des problématiques. En fonction du contexte (et donc de l’équipe) on peut attendre des bénéfices différents du BDD. Les plus fréquents sont:
- une accélération des livraisons avec moins d’aller-retours pour corriger des bugs
- une meilleure qualité des livraisons avec un produit plus proche de l’attendu
- une meilleure communication dans l’équipe
- une réduction des coûts de production
- une meilleure compréhension du produit et de ses fonctionnalités
- Homogénéiser les pratiques et le niveau de qualité entre les équipes en Agile à l’échelle…
Avant de savoir comment évaluer l’implémentation du BDD il est important de bien identifier les bénéfices attendus du BDD pour l’équipe.
Préparer l’implémentation du BDD
Lorsque l’identification des apports attendus du BDD est faite il est faut convaincre les membres de l’équipe que le BDD peut les aider à améliorer la qualité de leur travail et leur qualité de vie au travail (je croise trop souvent des personnes en souffrance à cause de leur travail et qui cherchent des réponses) est également un élément clé. « Forcer » l’implémentation d’une pratique est un élément qui est trop souvent contre-productive.
L’implémentation du BDD
L’équipe fera généralement face à des difficultés lors de l’implémentation du BDD.
Dans certains cas cela se résout par la répétition mais dans d’autres on peut s’apercevoir que la théorie ne répond pas au besoin. Dans ce cas il faut trouver collectivement comment remplacer les pratiques qui sont problématiques tout en s’assurant que les bénéfices attendus sont préservés. Dans les cas où les bénéfices de la pratique en question ne sont pas attendus par l’équipe (car hors contexte ou déjà couvert par d’autres pratiques de l’équipe) il est évidemment possible de ne pas les remplacer.
Le suivi de l’implémentation du BDD doit se faire, non pas par rapport à une proximité avec la théorie mais par rapport à une proximité à l’attendu.
Avoir cette posture permet d’apporter de vrais gains aux équipes et assurer une implémentation pérenne de la pratique dans un grand nombre de contextes et d’équipes qui, sur le papier, n’auraient pas pu faire du BDD « by the book ».
Au final, on peut se dire que ce qui est pratiqué par l’équipe n’est pas du BDD au sens où on l’entend généralement mais est-ce vraiment le plus important ?
Conclusion
Réussir à implémenter le BDD n’est pas réussir à implémenter un BDD théorique dans une équipe agile théorique. Réussir l’implémentation du BDD dans une équipe c’est avant tout réussir à apporter les bénéfices du BDD dont l’équipe a besoin… Et que l’équipe s’approprie cette pratique pour continuer à l’utiliser et la faire évoluer avec leurs besoins.
Je tiens néanmoins à rappeler que l’adaptation de la théorie c’est bien mais que pour réussir concrètement à adapter cette dernière au besoin il est nécessaire de bien connaitre cette théorie et la maitriser suffisamment pour savoir quels ajustements apporter pour ne pas perdre l’essence des pratiques (dans le cas du BDD une communication assurant une compréhension partagée entre les différents acteurs) et avec les bénéfices attendus par ces dernières.
Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !
N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
