Comment réussir aux ateliers de spécifications BDD?

Aujourd'hui, nous avons essayé d'introduire BDD dans notre processus de développement logiciel en organisant un atelier de spécification.

Pour cet atelier, nous avions 2 développeurs, 1 testeur et 1 analyste commercial. L'atelier a duré 1h30 et à la fin de celui-ci, nous avons réussi à trouver quelques scénarios BDD pour notre nouvelle fonctionnalité. Nous avons essayé de nous concentrer sur la recherche des scénarios que nous pourrions manquer et des plus difficiles.

À la fin de l'atelier, certaines personnes n'étaient pas satisfaites de l'atelier.

Un développeur a estimé qu'il avait perdu son temps car il avait l'habitude de donner les scénarios directement à l'analyste commercial et de les examiner avec elle. L'analyste commerciale n'était pas sûre de la couverture de nos scénarios (avait le sentiment que nous aurions pu passer à côté d'autres choses importantes), mais plus important encore, estimait que cet atelier était également une perte de temps car elle aurait pu comprendre tous ces scénarios par elle-même. et dans un laps de temps plus court .

Cet atelier expérimental a duré 1h30, et à la fin de celui-ci, nous ne nous sentions pas assez confiants sur ce que nous avons fait ... bien sûr, nous aurions pu y consacrer plus de temps mais honnêtement, la plupart des gens sont épuisés après 1h30 de brainstorming pour aller chercher des affaires règles du cerveau BA.

Ma question est donc de savoir comment ce genre d'atelier peut réellement fonctionner. Dans la théorie, étant donné que vous avez une nouvelle fonctionnalité à développer, vous placez l'arbre `` amigos '' (dev / tester / ba) dans la même pièce afin qu'ils puissent collaborer ensemble pour écrire les différentes exigences pour la nouvelle fonctionnalité à l'aide d'exemples. Je peux voir tous les avantages de cela. Surtout en termes de partage des connaissances et de produit commun / objectif final / vision réalisée.

Notre conclusion de cette expérience était qu'il est en fait plus rentable d' avoir d'abord un BA pour travailler seul sur les exemples et ensuite seulement d'avoir les scénarios à réviser / retravailler par les 3 `` amigos ''. En ayant le BA pour travailler seul, nous sommes en fait plus confiants que nous allons moins manquer quelque chose + nous pouvons toujours revoir les scénarios par la suite pour revérifier. Nous ne pensons pas qu'une simple session de brainstorming / découverte délibérée soit réellement suffisante pour couvrir sérieusement toutes les exigences d'une nouvelle fonctionnalité. L'analyste d'affaires est en fait la meilleure personne pour ce genre de choses. La meilleure chose que nous puissions faire est de revoir ce qu'elle a écrit et de voir si nous avons une compréhension commune (ce qui pourrait alors conduire à réécrire certains de ses scénarios ou en ajouter de nouveaux qu'elle aurait pu manquer).

Alors, comment pouvez-vous faire en sorte que cela fonctionne efficacement dans la pratique ?

Si vous pouvez dériver les scénarios de la description, vous avez terminé.

Un anti-modèle que je vois souvent dans BDD est que les gens ressentent le besoin de parler et d'écrire chaque scénario en détail.

Certains scénarios sont si bien compris qu'il suffit de les dériver d'une brève description. Par exemple, si je dis: «J'aimerais la fonction de connexion cette semaine», vous savez à quoi cela devrait ressembler. Vous savez qu'il existe des scénarios pour le bon mot de passe, le mauvais mot de passe, le mauvais nom d'utilisateur. Nous n'avons pas vraiment besoin d'en parler ou de les capturer en détail.

De même, je pourrais dire: «Voici le formulaire d'enregistrement des utilisateurs. Nous devons être en mesure de créer de nouveaux utilisateurs, de les laisser modifier leurs détails et de se supprimer, sauf que la suppression ne doit pas réellement supprimer, elle doit simplement les marquer comme supprimés afin qu'ils puissent récupérer leurs comptes s'ils le souhaitent. "

Et vous pouvez demander: "La récupération de compte fait-elle partie de cette fonctionnalité?"

"Ils peuvent être deux fonctionnalités si vous le souhaitez."

"D'accord, nous avons donc des scénarios pour créer, lire, mettre à jour, supprimer; cela devrait être assez facile. Parlons de la récupération de compte; cela semble plus intéressant."

En général, si la description du comportement est suffisante pour que l'équipe de développement dérive les scénarios, vous n'avez pas besoin d'en parler. Vous pouvez le faire en cas de doute, mais vous pouvez simplement saisir les scénarios dont vous devez vous souvenir, si vous en capturez un.

Si vous ne l'avez jamais fait auparavant ou si vous n'êtes pas sûr, discutez des scénarios.

Concentrez-vous sur les domaines inhabituels, en particulier s'il existe des fonctionnalités que vous n'avez jamais faites auparavant. Ce sont des endroits fantastiques pour avoir des conversations et noter tous les exemples surprenants qui se présentent. J'ai généralement deux questions que je pose, basées sur le modèle BDD:

Étant donné un contexte
Lorsqu'un événement se produit,
alors un résultat doit se produire.

• Y a-t-il un autre contexte qui, pour le même événement, produit un résultat différent?
• Y a-t-il un autre résultat qui est également important?

Si tout le monde à la table semble s'ennuyer, la fonctionnalité à laquelle vous parlez est probablement bien comprise. Il suffit souvent de dire: "Cela devrait fonctionner comme X , mais avec Y à la place." C'est ce que Dan North appelle le modèle Ginger Cake ; c'est comme la recette du gâteau au chocolat, mais avec du gingembre au lieu du chocolat.

Même si la partie prenante commerciale est capable de dériver les scénarios lui-même, il est vraiment important que l'équipe de développement puisse lui parler, reprendre et internaliser sa langue. Ce langage est ensuite intégré dans le code, ce qui leur permet d'avoir de meilleures conversations à l'avenir et d'aider les nouveaux arrivants au projet à comprendre ce qui se passe. Si les développeurs ne parlent pas la langue, ils ne l' utiliseront pas.

Si l'intervenant commercial ou l'analyste ne veut vraiment pas passer le temps à capturer des choses dans la session, je préfère que les développeurs rédigent les scénarios en collaboration avec les testeurs, puis lui demandent de le revoir. Cela est plus susceptible de révéler des malentendus que l'inverse.

Parfois, BDD ne fonctionne pas.

Une autre possibilité est que vous trouviez un scénario dont la partie prenante n'est pas sûre. "Oh, je n'y avais pas pensé! Je ne suis pas sûr." Plutôt que d'essayer de clouer l'entreprise et de la punir avec certitude, il peut être utile d'abandonner BDD à ce stade et d'essayer quelque chose de simple pour obtenir des commentaires et donner à l'entreprise quelque chose sur lequel ils peuvent itérer. Gardez-le facile à changer et écrivez les scénarios une fois que vous comprenez mieux ce qui se passe.

Le BDD bien fait peut vraiment aider à découvrir des lieux d'incertitude. Étant donné que chaque projet qui vaut la peine d'être fait a un aspect nouveau et n'a jamais été fait auparavant, il y a une incertitude quelque part. Si vous vous concentrez sur l'utilisation des scénarios pour aider à découvrir délibérément l'ignorance , vous apprendrez plus vite, et l'apprentissage est généralement une grande partie du temps consacré à un projet.

De plus, j'ai constaté que plus les équipes de développement collaborent de cette manière, plus l'entreprise est prête à leur faire confiance dans l'incertitude, et plus l'innovation commence à se produire. Les entreprises innovantes, de par leur nature même, ont beaucoup d'incertitude dans leurs projets.

J'ai écrit un article de blog il y a quelque temps sur Cynefin , ce qui m'aide vraiment à comprendre où les conversations seront les plus efficaces. Si vous le lisez et comprenez les quatre domaines, voici les règles que j'utilise:

• Les choses simples et compliquées (connues) sont souvent bien comprises et vous n'avez pas besoin de parler en détail des scénarios.

• Les choses très complexes (inconnues) ne sont pas du tout comprises. Vous pouvez le découvrir en discutant des scénarios. Le manque de certitude signifie que BDD ne fonctionnera pas ici, alors parcourez quelque chose de facile à changer et obtenez des commentaires rapides à la place. Toute pratique qui conserve vos options, comme les tests AB, est également excellente dans cet espace.

• BDD fonctionne brillamment dans l'espace intermédiaire (connaissable) comme mécanisme de transmission des connaissances et pour découvrir les deux autres espaces. Ce n'est pas un marteau et tout n'est pas un clou. En fait, si vous pouvez concentrer le temps passé à avoir des conversations sur quoi que ce soit, il ne s'agit pas des exemples que vous pouvez trouver; il s'agit de trouver les exemples que vous ne pouvez pas .

La durée de la réunion n'est pas votre problème. Il est normal que ces réunions durent longtemps. MAIS tout le monde devrait en sortir confiant. Qu'ils ne l'ont pas fait, c'est votre problème.

Je proposerais une brève réunion pour discuter d'une exigence. Planifiez une deuxième réunion quelques jours plus tard, afin que tout le monde sache qu'ils doivent être prêts d'ici là.

Ensuite, le BA et le testeur devraient chacun proposer leurs scénarios, car ils regardent tous deux les logiciels de manière très différente. Demandez-leur de les écrire sur des cartes et de les coller sur un tableau quelque part, au moins un jour avant la deuxième réunion, laissez chacun regarder à travers son propre temps et y réfléchir. Jetez tous les doublons, montrez tous les scénarios qui n'ont pas été pris en compte.

Ne jetez rien avec quoi vous n'êtes pas d'accord, mais marquez-le comme litigieux. Si une conversation très brève avec la personne qui l'a écrit vous aidera, faites-le, mais surtout enregistrez-le.

ALORS ayez votre réunion de planification / conception. Ayez un ordre du jour solide pour cette réunion (commencez par le tas de cartes, mettez les plus litigieuses en haut) et ne lui permettez pas de dévier. Assurez-vous de sortir de cette réunion avec tous les points de discorde résolus.

Assurez-vous toujours que tout le monde dans une réunion est préparé pour le sujet de cette réunion!

N'utilisez jamais une réunion pour "réfléchir" à quelque chose ensemble. Cela fait perdre du temps à tout le monde.

Recette générale pour des réunions efficaces:

• demander à quelqu'un de préparer les éléments à discuter
• exiger que tous les participants les aient étudiés (et pas seulement les lire)
• recueillir les commentaires au préalable et exiger que tous les participants les aient étudiés (pas seulement lus)
• tenir la réunion pour prendre des décisions

À propos des plaintes ...

Commençons par ceux-ci:

Un développeur a estimé qu'il avait perdu son temps car il avait l'habitude de donner les scénarios directement à l'analyste commercial et de les examiner avec elle.

C'est ce qu'il faisait dans l'atelier. Cela me semble donc être une mauvaise excuse de mauvaise humeur. Je soupçonne que ce développeur n'aime tout simplement pas (ou les deux) l'examen minutieux de l'atelier et ses contraintes de planification.

L'analyste commercial n'était pas confiant avec notre couverture de scénario (avait le sentiment que nous aurions pu manquer d'autres choses importantes)

En quoi est-ce différent que lorsqu'elle le fait de son côté et le fait examiner par un développeur, à part le fait que plus de gens l'ont regardé? Je soupçonne que ce n'est que le résultat d'un atelier qui est peut-être un peu chaotique. Vous aurez l'assurance d'avoir suffisamment de tests en les mettant en œuvre et en les intégrant. Vous ne pouvez jamais être sûr d'avoir trouvé tous les bogues, et en ce qui concerne la couverture, la meilleure façon serait de les schématiser dans vos user stories.

mais plus important encore, a estimé que cet atelier était aussi une perte de temps car elle aurait pu comprendre tous ces scénarios par elle-même et dans un délai plus court.

Oui, et tout seul, dans son jardin clos et sans partage de connaissances. Alors qu'en faisant cela, les futurs ateliers pourraient être plus productifs car tous les participants ont acquis un peu de connaissances sur la façon d'aborder ces choses.

Peut-être que la réunion a été lente cette fois, cela ne veut pas dire que ce sera toujours le cas. Et en tant que personnel externe, j'aurais, avec une formation pour bien faire les choses, plus de confiance que la couverture était meilleure dans un atelier avec 3 participants avec des mentalités différentes qu'avec un seul dictateur.

De plus, si un développeur avait déjà besoin de revoir ces scénarios avec elle, je suis sûr que le va-et-vient est beaucoup plus rapide et efficace dans l'atelier que d'utiliser le "Je fais mes trucs seuls et je donne des trucs à vous, vous l'examinez seul et revenez vers moi et recommençons ".

Suggestions

• Soyez positif et insistez sur le fait que si le processus est bon, vous vous améliorerez.

• Essayez de rationaliser l'atelier et de le garder sur la bonne voie.

• Peut-être donner de la place à l'analyse du «loup solitaire», en commençant l'atelier avec chacun qui conçoit quelques scénarios par lui-même (encore mieux, avant l'atelier), puis en les triant et en les fusionnant.

Et si vous ne pensez pas que faire ce remue-méninges est nécessaire, très bien: demandez au BA de travailler seul, mais faites ensuite l' examen en tant qu'atelier, au moins. Les globes oculaires plus le mieux, pour citer Eric S. Raymond 's Linus Law :

Given enough eyeballs, all bugs are shallow.

Vous avez déjà de très bonnes réponses ici, donc je vais me concentrer sur un petit aspect qui a jusqu'à présent été ignoré. Le rôle de chacun des trois Amigo devrait être en mesure de s’acquitter de la session. Ils offrent chacun une valeur différente, ils comprennent chacun un ensemble différent de contraintes.

En général, le BA devrait être en mesure d'apporter le principal chemin heureux à la session, il devrait également être en mesure de fournir les principaux scénarios de défaillance d'un point de vue commercial. L'expertise de test doit être capable d'identifier les cas limites et les scénarios supplémentaires nécessaires pour prouver que le système fonctionne en toutes circonstances. Le travail du développeur n'est pas vraiment d'ajouter des scénarios, bien qu'ils le fassent souvent en cas de défaillance technique, leur travail lui aussi garantit de bien comprendre les exigences afin de transmettre les implications et de mettre en œuvre l'exigence avec le minimum de communication supplémentaire.