Quels arguments puis-je utiliser pour «vendre» le concept BDD à une équipe réticente à l'adopter?

Je suis un peu un ardent défenseur de la méthodologie de développement conduit par le comportement (alias BDD). J'applique BDD depuis quelques années maintenant, et j'ai adopté StoryQ comme cadre de choix lors du développement d'applications DotNet. Même si je fais des tests unitaires depuis de nombreuses années et que je suis passé auparavant à une approche de test d'abord, j'ai constaté que j'obtiens beaucoup plus de valeur en utilisant un cadre BDD, car mes tests capturent l'intention des exigences de manière relativement l'anglais clair dans mon code, et parce que mes tests peuvent exécuter plusieurs assertions sans terminer le test à mi-chemin - ce qui signifie que je peux voir quelles assertions spécifiques passent / échouent en un coup d'œil sans déboguer pour le prouver.

Cela a vraiment été la pointe de l'iceberg pour moi, car j'ai également remarqué que je suis en mesure de déboguer le code de test et de mise en œuvre de manière plus ciblée, avec pour résultat que ma productivité a considérablement augmenté et que je peux plus déterminer facilement où un échec se produit si un problème survient pour se rendre à la génération d'intégration en raison de la sortie qui fait son chemin dans les journaux de génération. De plus, l'API StoryQ a une belle syntaxe fluide qui est facile à apprendre et qui peut être appliquée d'un nombre extraordinaire de façons, ne nécessitant aucune dépendance externe pour l'utiliser.

Donc, avec tous ces avantages, vous penseriez qu'il est facile de présenter le concept au reste de l'équipe. Malheureusement, les autres membres de l'équipe hésitent même à regarder StoryQ pour l'évaluer correctement (sans parler de l'idée d'appliquer BDD), et se sont convaincus mutuellement d'essayer de supprimer un certain nombre d'éléments StoryQ de notre propre cadre de test de base, même bien qu'ils aient initialement pris en charge l'utilisation de StoryQ, et même si le code qu'ils souhaitent supprimer n'affecte aucune autre partie de notre système de test. Cela finirait par augmenter considérablement ma charge de travail dans l'ensemble et va vraiment à contre-courant, car je suis convaincu par l'expérience pratique que c'est une meilleure façon de travailler en testant d'abord dans notre environnement de travail particulier, et ne peut que conduire à une plus grande améliorations de la qualité de nos logiciels, étant donné que je ' ai trouvé plus facile de s'en tenir au test en utilisant d'abord BDD. Pour clarifier davantage, la majorité des tests unitaires que nous avons tendance à être assez fragiles et difficiles à maintenir, un résidu d'années de tests mal appliqués où une réticence à s'en tenir à un processus piloté par les tests a vu les développeurs se replier sur leurs vieilles habitudes et faire tous leurs tests à la fin du projet (ces mêmes personnes se disent Agiles!).

La question se résume donc vraiment à ce qui suit:

1. Quels arguments puis-je utiliser pour vraiment faire comprendre qu'il serait préférable pour cette équipe d'utiliser StoryQ, ou tout au moins d'adopter la méthodologie BDD?
2. Pouvez-vous me signaler des preuves anecdotiques que je peux utiliser pour étayer mon argument en faveur de l'adoption du BDD comme méthode de choix standard?
3. Quels contre-arguments pouvez-vous penser qui pourraient suggérer que mon souhait d'encourager l'équipe à adopter le BDD pourrait être une erreur? Oui, je suis heureux d'avoir tort, à condition que l'argument soit valable.

REMARQUE : je ne préconise pas que nous réécrivions nos tests dans leur intégralité, mais plutôt de simplement commencer à travailler d'une manière différente pour tous les futurs travaux de test, et de préférence de la manière dont nous engageons nos clients.

Et pour ceux d'entre vous qui souhaitent en savoir plus sur BDD, les liens suivants peuvent être utiles:

• http://dannorth.net/introducing-bdd/
• http://en.wikipedia.org/wiki/Behaviour_driven_development
• http://behaviour-driven.org/Introduction

_{Pour ceux intéressés par plus de détails, nous sommes une petite équipe de 4 travaillant sur environ 5 grands projets. L '"essai pilote" pour le BDD a duré environ 2 mois au départ, suivi d'une autre période d'environ 4 mois. L'équipe a accepté que je continue de travailler de cette façon et devait faire ses propres essais. Je fais du BDD depuis environ 2 ans maintenant depuis la fin du procès, tandis que les autres sont devenus très bons pour esquiver le problème. Plutôt que de forcer une "confrontation" sur la question, je cherche des moyens de persuader doucement l'équipe de sortir de son derrière collectif et de prendre le temps de faire sa part.}

Quels arguments puis-je utiliser pour vraiment faire comprendre qu'il serait préférable d'utiliser StoryQ, ou à tout le moins d'appliquer la méthodologie BDD?

"Le client le veut."

IMO vous voulez vendre BDD à vos clients / experts de domaine au moins autant qu'à l'équipe de développement.

BDD est un processus collaboratif extérieur-intérieur où plusieurs parties prenantes sont impliquées. Les avantages de BDD ne sont pas seulement pour les développeurs de déduire automatiquement leur code de test des tests d'acceptation, ils résident également dans la coopération créative qui a lieu entre les techniciens et les hommes d'affaires pour produire des spécifications précieuses et bien définies du comportement prévu du système.

Donner aux clients / analystes commerciaux un accès à une interface où ils peuvent exécuter chaque spécification exécutable, contrôler leur statut et voir la progression de leur mise en œuvre est également très apprécié.

Il y a une présentation de Dan North sur la façon dont vous pouvez vendre des BDD à l'entreprise: http://skillsmatter.com/podcast/java-jee/how-to-sell-bdd-to-the-business

1. Dans une équipe réticente à adopter le BDD, il n'y a probablement aucun «argument» que vous pouvez utiliser pour «convertir» vos collègues en adoption à grande échelle.
    
   Je pense que le mieux que vous puissiez faire est de les convaincre de faire un essai ("test de fumée", "essai à sec", "projet pilote") - surtout si vous dites clairement que vous abandonnerez l'idée si les résultats des tests sont négatifs.
2. Votre approche pour trouver des preuves anecdotiques correspond parfaitement à l'idée de convaincre l'équipe de l'essayer. Pour cela, je rechercherais simplement sur le Web quelque chose comme "Success story Driven Development Driven" et choisir ce qui me semble plus facile à utiliser.
3. Il y a quelques contre-arguments auxquels je peux penser qui pourraient suggérer que votre souhait de convertir les efforts de l'équipe en BDD pourrait être une erreur.
    
   Aucun de ceux-ci n'est particulièrement constructif, en particulier du point de vue d'un «défenseur du changement», mais malheureusement, vous devrez probablement faire face exactement à cette rhétorique ( BTDTGTTS ):
    
   • vous ne pouvez pas garantir que la productivité globale de l'équipe s'améliorera
   • vous ne pouvez pas garantir que les efforts investis dans l'adoption du BDD donneront un retour sur investissement substantiel
   • l'équipe se débrouillait suffisamment bien sans BDD, le risque de changer l'approche actuelle n'est pas justifié
   • Google (ou Microsoft ou IBM - indiquez simplement le nom du fournisseur de logiciels "respectable") se passe très bien sans BDD, ce qui "prouve" que BDD n'est pas nécessaire
   • les approches non BDD n'ont pas eu une chance équitable dans les tests comparatifs
   • BDD peut être généralement OK mais pour ceci et ce module / projet, il n'est pas applicable

D'après mon expérience, le moyen le moins douloureux de traiter les contre-arguments comme ceux énumérés ci-dessus était d'effectuer un test contrôlé limité pour un changement proposé.

Le statut de "test limité" invalide essentiellement trois des quatre arguments ci-dessus, à l'exception de celui concernant le "fournisseur respectable", qui pourrait être contré en fournissant des preuves anecdotiques de la réussite (des preuves anecdotiques ne fonctionneront probablement pas pour un "changement radical", mais pour essais limités c'est assez bon).

Si le changement est en effet utile et que le test est correctement organisé, vous remarquerez un changement positif dans l'attitude de l'équipe et de la direction, ce qui rend la transition vers un changement à grande échelle en douceur et sans douleur.

Un autre avantage du test limité est qu'il vous permet de clarifier et d'ajuster les détails du processus cible sans causer trop de problèmes et avec un risque moindre de «dommages à la réputation» de l'idée. Chaque fois que j'ai participé à de tels tests , j'ai été agréablement surpris de découvrir à quel point il était facile de passer à une adoption à grande échelle, les détails les plus importants étant définis et clarifiés lors du test.

Il est peut-être temps de recruter des cadres. Si vous avez essayé et vu des résultats solides, mais que l'équipe rechigne, la direction devra peut-être s'impliquer.

Cela est particulièrement vrai s'ils nuisent aux membres de l'équipe les plus productifs de l'entreprise. Soyez prêt à réagir. Vous pouvez commencer par approcher la direction et chercher à ce que l'équipe cesse de vous sous-estimer en retirant vos cas de test.