Accueil > Actualités, Méthodes Agiles > As VISEO, We went to CukeUp!, So we can improve our BDD

As VISEO, We went to CukeUp!, So we can improve our BDD

IMG_1191-0.JPG

BDD par Dan North

Cette année a eu lieu la 5ème édition du CukeUp! organisée par Skills Matters dans la charmante ville de Londres. Cette session a été l’occasion de voir des présentations autour du mouvement BDD et de participer à des ateliers mettant en pratique des problématiques de gestion de projet et de développement.

Les conférences et ateliers se sont déroulés sur 2 jours. Skills Matter s’est chargé de nous fournir en colories afin d’irriguer nos cerveaux avides de savoir.

 

À travers cet article je vais tenter de retranscrire ce que CukeUp! m’a apporté. Je vais ainsi vous partager ma vision sur comment le BDD peut améliorer un projet et sa gestion. Je reviendrai dans un second temps sur les limites de cette méthode et enfin, je conclurai de la même manière que les organisateurs : WTF is BDD ?

Comment le BDD peut rendre un projet meilleur ?

 

Retours d’expérience

IMG_1147-0.JPGCe qui revient souvent lorsqu’on aborde le BDD est la nécessité de comprendre les besoins d’un projet. Jo Wickremasinghe nous a raconté son retour d’expérience du temps où elle travaillait en tant que Product Owner à la BBC (en 2009).
Son équipe rencontrait des difficultés pour produire leurs projets dans des délais raisonnables en maintenant une qualité convenable. À ce moment là, TDD et Scrum étaient en place.
Pour cette raison, un coach Agile est intervenu afin d’améliorer l’équipe. Ce qui est ressorti de ce coaching est la mise en place du BDD pour améliorer la compréhension des besoins d’une part, et d’autre part pour établir des standards de communication entre les différents acteurs (PO, Scrum master, développeurs, testeurs).
Pour ce faire, la première étape a été de revoir la manière dont les User Stories sont écrites : ils ont rendus les stories les plus petites possible afin d’identifier les besoins primaires, clairs et non ambiguës. Des exemples concrets étaient ensuite mis en place à l’aide de l’approche BDD (écrits en Gherkin). Ces exemples ont amené une illustration claire des User Stories, permettant ainsi d’améliorer la qualité des produits.
Une des conséquences directes a été la capacité à délivrer plus régulièrement ce qui était produit par l’équipe; une autre conséquence, a été la réduction du nombre de bugs du fait de la diversité des tests grâce aux exemples (scénarios).
Un dernier point, moins attendu, a été une meilleure entente au sein de l’équipe entre tous les acteurs : le fait d’avoir travaillé la communication (point essentiel pour que le BDD fonctionne) a entrainé une consolidation naturelle au sein de l’équipe et les conflits se sont résorbés d’eux même.

BDD Tips and Tricks

IMG_1175-0.JPG

Carlos Ble et Borja Navarro

Mettre en place le BDD semble donc être une bonne pratique. Carlos Ble et Borja Navarro ont partagé avec nous leurs trucs et astuces pour rendre le BDD encore plus utile. Leurs conseils viennent directement de leur retour d’expérience et permettent d’éviter des erreurs souvent commises.

Le BDD met en avant la nécessité de comprendre les besoins, les fonctionnalités. Carlos et Borja conseillent d’illustrer les fonctionnalités par des exemples. Les exemples amènent des cas concrets qui permettent de mieux comprendre le besoin.
Un autre conseil a été d’utiliser des Personaes. Le fait d’utiliser des personnages répond à une autre « règle » du BDD qui est de garder l’utilisateur au centre du besoin. Il est donc recommandé de créer des acteurs qui seront utilisés dans les scénarios qui illustrent les fonctionnalités.
Afin de créer ces exemples, l’utilisation du Gherkin peut être utile afin de placer le contexte, l’action et le résultat attendu. Cela permet également de garder les exemples simples (Given… When… Then).
Attention néanmoins à ne pas illustrer par des exemples trop simples (perte de temps) ou à créer des exemples qui se réfèrent à un état technique : le TDD couvrant déjà cet aspect. Le but du BDD est de se concentrer sur les fonctionnalités et non sur le moyen d’y arriver.

3 exemples où le BDD aurait sauvé le projet

Une question se pose alors : existe-t-il des cas ou le BDD aurait pu permettre a un projet de ne pas échouer ?
Megan Folsom a présenté 3 projets qui, d’après elle, auraient eu une issue différente si le BDD avait été appliqué :
  • Jeff Bezos et son firephone
  • Sergey Brin et les Google glasses
  • Obama et le site web d’ObamaCare
Ces 3 projets, qui ont été des échecs, partagent un schéma commun. Tout d’abord une mauvaise identification du client, puis une mauvaise identification du besoin initial et enfin, une mauvaise solution. Si nous devions écrire les User Stories des 3 projets nous aurions quelque chose proche de :
As Jeff Bezos
I want a phone that list the thing I want to buy
So I can spend all my money on amazon.com
As google team
We want to record every thing I do with my glasses
So I can say It’s cool
As the President of the United States of America
I want the website to be released at this date no matter what
So I can keep my credibility
Au vu de ces 3 stories, certains projets n’auraient sûrement pas vu le jour (firephone, google glass) et d’autres auraient eu une autre approche (site web de l’ObamaCare).
La conclusion principale qu’apportent ces exemples est le manque de communication et de discernement par les équipes de réalisation vis-a-vis du demandeur. Les projets ont été réalisés pour les demandeurs et non pour les clients/utilisateurs du projet.
Le BDD aurait pu éviter ces problèmes à travers l’écriture de stories claires, mettant en scène des Personaes pour illustrer l’utilisation souhaitée.
Le besoin est concentré sur ce que souhaite le décideur et non sur ce qu’aurait voulu les utilisateurs.

Le BDD suffit-il à la réussite d’un projet ?

Produire des programmes plus rapidement

IMG_1144.JPGComprendre les besoins est important mais cela suffit-il à la réussite d’un projet ? L’un des workshop portait sur la capacité à produire des programmes plus rapidement.
La première question qui nous a été posée a été : le code est-il un point essentiel ou au contraire le point faible d’un programme ? Comment estimons-nous / évaluons-nous le code par rapport aux autres aspects d’un programme ? Pour Dan North, le code est le point faible. Au mieux, il est un simple véhicule permettant d’arriver à un état final qu’est le produit fini.
Dan nous a donné sa vision sur le sujet : le code peut amener des problèmes et il est simple de changer de technologie pour obtenir un produit similaire (voire identique). Ce qui est important est ce qui a un impact sur le Business (idées, budget, etc).
Afin de produire un programme rapidement il est nécessaire d’avoir une phase d’analyse.
Cette phase doit être bornée, c’est-à-dire qu’il ne faut pas tomber dans un espace temps parallèle propre à une analyse infinie, qui devient contre productive, mais au contraire rester concentré sur le but final : obtenir un produit qui a de la valeur. L’analyse est une phase coûteuse qui n’apporte de valeur qu’une fois terminée. Il est donc essentiel de réduire le temps afin de conserver un équilibre entre les différentes phases du projet.

Agile, you keep using that word

Dan a animé une autre session pendant laquelle il a partagé son opinion sur l’agilité. Premièrement, d’après lui, notre vision sur l’agilité n’est pas correcte :
I do not think it means what you think it means

Cette citation du film The Princess Bride résume sa pensée. Le manifeste Agile date de 2001 or en 2015 les besoins et les moyens ont changé : nous voulons des livraison plus rapides, qui peuvent scaler et qui sont durables dans le temps.

I tried Agile/BDD/Scrum and it didn't work...
... in my context

Dan défend que les pratiques dépendent du contexte. Le manifeste Agile impose des pratiques indépendamment de l’environnement or il est important d’identifier tous les contextes (technologie, architecture, business, capacité de l’équipe, etc.) afin de déterminer les pratiques. On peut alors les mettre en place et adapter ce que préconise l’agilité pour améliorer le déroulement des projets et la qualité des livraisons.

Une fois cette analyse complète, il faudra estimer le coût nécessaire à la réalisation du produit. Cette étape, bien que nécessaire pour le business, n’est pas évidente. En effet, « l’art » de l’estimation n’est pas une compétence fiable. Les investisseurs souhaitent savoir combien le projet va leur coûter afin d’estimer leur ROI mais il est difficile voire impossible d’être précis dans cet exercice.

#NoEstimates does not mean « No estimates »

Le mouvement #NoEstimates a cherché à réduire le besoin des estimations. Mais #NoEstimates ne veut pas dire « pas d’estimation » mais fait réfléchir aux moyens de ne pas faire des estimations inutiles, ou des estimations basées sur de mauvaises choses.
Les réflexions principales se voulaient autour du cycle Planifier -> Réaliser -> Tester -> Vérifier. Ce cycle se répète inlassablement dans les projets sans permettre une amélioration. Quelle solution permettrait de sortir de ce cycle en améliorant les produits réalisés ? Une des pistes est de redéfinir ce qui est nécessaire dans les estimations.
Une réflexion intéressante nous a été donnée par Seb Rose :
Prediction is very difficult, especially about the future.
Cette citation illustre parfaitement pourquoi il est difficile d’estimer précisément un projet. Une solution proposée est d’utiliser une échelle de temps avec un borne inférieure et une borne supérieure.
Afin de satisfaire les exigences de chaque partie le RAROC (Risk Adjusted Return On Capital) peut être une solution.
En effet, cette méthode permet de donner le temps minimum (cas idéal si le projet se déroule sans encombre) et le temps maximal nécessaire à la réalisation. Le temps maximal peut être défini comme un nombre peu flatteur pour votre égo s’il venait à être atteint (« vous avez réellement mis 3 jours pour écrire ce Hello World ?! Mais quel genre de développeur êtes-vous ? »).
Les avantages de cette méthode peuvent se résumer ainsi :
  • les investisseurs peuvent déterminer si le coût maximal permet un ROI dans les délais voulus
  • l’équipe de réalisation possède une marge de manœuvre pour gérer les imprévus.
  • Le chiffrage n’est pas gravé dans le marbre et peut évoluer (dans un sens comme dans l’autre) en fonction du contexte qui se crée autour du projet
Avec cette méthode de chiffrage, certains projets peuvent démarrer et produire des applications rapidement (approche Agile et Continuous Delivery). Ces applications suivront un schéma d’évolution continue afin de permettre un retour sur investissement avant même la fin du projet.
Nous avons donc vu que le BDD seul ne garantit pas la réussite d’un projet. Il y a tout un contexte autour et des méthodes qui sont nécessaires. Le BDD vient compléter ces points afin d’amener une nouvelle dimension pour créer des produits qui ont de la valeur.

WTF is BDD?

Pouvons-nous donner une définition ?

IMG_1188-0.JPG
Bien qu’il existe une définition, pouvons-nous dire ce qu’est le BDD ?
Voici quelques certitudes que nous pouvons avancer :
  • le BDD permet de garder le focus sur ce qui impacte le business
  • il permet également de comprendre les besoins et de les découper en exemples simples
Malgré ces éclaircissements pouvons-nous définir de façon précise ce mouvement, cette méthode ?
A la manière d’un talk-show américain, différents acteurs des présentations et workshop des deux jours se sont réunis pour tenter de donner une définition.

Conclusion

(Ma) conclusion : il n’existe pas de définition claire et c’est une bonne chose. Le BDD est un mouvement qui s’adapte aux contextes et s’améliore en fonction des problématiques rencontrées. A titre d’exemple, c’est ainsi qu’est né le Gherkin (Given/When/Then créé par Chris Matts) et qui a été repris par Cucumber pour apporter une solution technique au BDD.
Chacun peut amener son savoir faire pour compléter des fondations solides qui se reposent sur :
  • une nécessité de comprendre les besoins
  • mettre la communication au centre de tous les acteurs
  • observer un objectif commun : créer de la valeur à moindre de coût (et avec moins de bugs).
Voilà qui vient conclure la synthèse de ce CukeUp! 2015 qui a été riche en enseignements et que j’ai essayé de vous retranscrire à travers cet article.
Les workshops auxquels  nous pouvions assister enrichissent grandement les théories énoncées.
Deux mois après ces conférences j’ai pu appliquer certaines pratiques dans le cadre de mes missions. Les astuces sur le BDD m’ont permis de mieux écrire les Gherkin et j’ai pu amener toute l’équipe à participer à cette rédaction. De manière générale, la compréhension des besoins s’est amélioré et un gain dans la qualité des livrables a pu être observé. Il reste encore du chemin à faire mais ce que j’ai pu vous retranscrire dans cet article s’est avéré utile pour mes projets.
Given "Shoun" was at CukeUp! 2015
And The fact he enjoyed the journeys
When He shares what he learned and what he thinks about it
Then He expects it is useful to you
And He expects many likes
Categories: Actualités, Méthodes Agiles Tags: ,
  1. Pas encore de commentaire
  1. Pas encore de trackbacks