Catégorie: Développement agile

Dans le 18e coding dojo du Club Agile Rhône Alpes, ce 5 janvier dernier, j'avais pris un exemple réel issu de nos plans de tests, et basé sur les courbes de calibration, un concept très utilisé en chimie (et donc dans nos applications). Demain, dans la 20ème session, nous poursuivrons sur cet exemple. Comme pas mal de jours ont passé, ce billet est destiné à nous rafraîchir la mémoire sur la question, à moi le premier !

» Lire la suite!

Pour démarrer la discussion sur la rédaction de spécifications exécutables l'autre soir au CARA, j'avais pris l'exemple de la réalisation d'un logiciel de comptage de calories. L'exemple n'est pas gratuit : je trouve que la plupart des logiciels de ce genre ont une interface utilisateur très influencée par l'implémentation avec une base de données, et pas très influencée par les besoins utilisateurs. Pardonnez l'expression, mais ce genre de logiciel "pue la base de données", alors que la base de donnée n'a que peu de valeur pour l'utilisateur - c'est juste un choix d'implémentation bien pratique pour les développeurs.

Par conséquent, il me semble que travailler sur un tel logiciel est intéressant pour apprendre le BDD, car justement nous aimerions éviter de "polluer" les scénarios par des concepts purement techniques comme des questions de base de données. Le challenge est donc de parvenir à exprimer les scénarios avec des mots d'utilisateur et pas du jargon informatique.

Dans ce billet je vais détailler mon point de départ et illustrer les premières leçons que j'ai tirées des discussions. Bien sûr cela reste un exemple "jouet" mais je parviendrai peut-être à en faire une application complète dans quelque temps.

Je suis également passé à la rédaction de scénarios en français, ce qui est possible en Cucumber (tapez la commande cucumber -i18n fr pour avoir les équivalences).

Mon point de départ était la fonctionnalité suivante :

» Lire la suite!

La réunion du CARA sur la rédaction de spécifications exécutables grâce au BDD (Behavior Driven Development) a été très intense. Merci aux nombreux participants pour cette soirée stimulante et aux camarades du CARA pour l'organisation ! J'ai le sentiment que tout le monde a pu gagner une compréhension plus concrète du BDD, et a pu appréhender l'aspect collaboratif de la rédaction de scénarios.

Les discussions ont certainement dérivé de l'objectif initial qui était d'explorer différentes manière d'écrire des spécifications exécutables, mais elles n'en ont pas moins été très intéressantes. Il y a eu trop d'échanges pour tout retracer dans un seul billet, donc ici je vais me concentrer sur l'un des aspects : pourquoi s'intéresser au BDD ?

» Lire la suite!

Pour illustrer un cas (extrême) de la flexibilité du format Given/When/Then que je mentionnais précédemment, voici un exemple GreenPepper (à partir de la version 2.6 GreenPepper supporte l'écriture de scénarios à la Cucumber - merci Emmanuel pour l'information).

GreenPepper est tellement flexible que les mots-clés Given/When/Then ne sont même pas obligatoires. Ainsi on peut écrire des scénarios comme celui-ci :

» Lire la suite!

Le dojo du 5 janvier à Grenoble concernait l'exploration de l'articulation entre TDD et BDD, sur la base d'un exemple que j'avais proposé. L'exemple s'appuie sur la problématique de la calibration des instruments scientifiques, problématique que nous devons souvent traiter dans nos logiciels. L'exemple est donc tout à fait concret et réaliste, implique des calculs assez rapides à programmer (comme la régression linéaire) qu'il serait néanmoins judicieux de traiter en TDD. De plus il comporte des spécifications trompeusement simples (source de diverses incompréhensions entre développeurs et utilisateurs) que le BDD pourrait certainement traiter. Le BDD devrait d'ailleurs permettre d'élaborer un modèle métier satisfaisant. C'est pourquoi cet exemple me paraît bien approprié et j'espère que nous le poursuivrons dans de futures séances.

Durant le dojo il y a eu des questions sur la manière dont j'avais rédigé les spécifications en Cucumber, ce qui est normal car le format Given/When/Then offre beaucoup de flexibilité. Rien ne vous force à utiliser When par exemple, ou à limiter les tests à des sections Then. En ce qui me concerne, j'ai l'habitude quand je code de faire les calculs au moment où l'on demande les résultats (ce qui est possible quand il y a peu de données, et évite de gérer des questions de cohérence données/résultats). Donc je n'éprouve pas trop le besoin de mentionner un déclenchement avec un When par exemple. Mais c'est probablement un cas où mon style et mes habitudes de programmation influencent directement sur la rédaction des spécifications exécutables, ce qui n'est guère souhaitable - dans le BDD nous souhaitons justement éviter de polluer les spécifications par des concepts très liés à l'implémentation, pour rester focalisés sur le modèle métier.

» Lire la suite!

Quand nous avons mis en place Scrum en 2005, notre but était de développer plus rapidement et plus facilement de nouveaux produits, entre autres objectifs. Au fil du temps nous avons découvert que même si Scrum fonctionne parfaitement bien, nous n'avons pas réellement développé plus rapidement. L'hyper-productivité mentionnée par certains ne nous a jamais rendu visite ! Néanmoins je reste convaincu qu'il y a encore beaucoup de possibilités de mieux développer les nouveaux produits, et surtout de gagner du temps. Je ne suis pas obsédé par une "productivité" bien difficile à mesurer, mais par contre je déteste les gaspillages de temps : débogages interminables, faire/défaire/refaire une histoire utilisateur mal comprise, séjours chez les clients pour résoudre des problèmes mystérieux. la liste est bien longue.

Une clé pour un développement plus facile de nouveaux produits est probablement d'accompagner la pratique de Scrum par le développement d'une nouvelle culture d'entreprise favorisant l'amélioration continue.

» Lire la suite!

Une conséquence inattendue mais bénéfique de notre démarche de caddying est que nous avons maintenant un blog interne utilisable par tous les employés du site. Il utilise le moteur Pebble qui a été assez simple à mettre en place (de l'ordre d'une journée de travail). L'idée est venue d'un de nos caddies qui souhaitait pouvoir publier sur son activité de caddy (et permettre à ses joueurs de publier leurs propres billets, par exemple pour des retours d'expérience). En tant que "Meta-caddy", j'ai encouragé cette initiative qui va bien dans la direction que j'imaginais il y a quelques mois (voir ce billet sur la mise en place du caddying) :

- les caddies seront encouragés à publier des retours d'expérience sur leur action, ou encore sur leur domaine de prédilection... L'idée étant que leur action devrait servir à générer de la connaissance (thème que j'explorais dans ce précédent billet).

En effet notre démarche de caddying doit contribuer à notre démarche actuelle de nous doter de nouveaux outils et moyens de favoriser l'amélioration continue et l'apprentissage.

» Lire la suite!

Pour conclure mon exploration des moyens de pratiquer le BDD en .NET, il me restait à examiner Cuke4Nuke, l'équivalent de Cuke4Duke de Java. C'est chose faite, et ce billet montre comment installer tout ce qu'il faut pour arriver à faire tourner l'exemple du jeu du pendu qui m'a servi dans les billets précédents.

» Lire la suite!

Je poursuis mon exploration des différentes possiblités de faire du Behavior Driven Development sur plate-forme .NET. Après avoir examiné l'approche NBehave, je vais voir comment utiliser plus directement Cucumber (une des principales références en BDD, avec une communauté très active). Cucumber étant programmé en Ruby, on peut donc utiliser IronRuby, l'implémentation de Ruby pour .NET. Dans ce billet je décris l'installation de IronRuby, celle de Cucumber sous IronRuby, et je montrerai l'exécution de mon exemple prédécent dans ce nouvel environnement. Faire tourner Cucumber sous IronRuby a été un peu laborieux pour moi, donc j'essaierai très prochainement une autre approche, celle de Cuke4Nuke - Cucumber for .NET qui promet d'être plus directe.

» Lire la suite!

Un lecteur m'ayant indiqué qu'une nouvelle version de NBehave (0.4.5) était disponible depuis une semaine, j'ai repris l'exemple du jeu du pendu pour voir comment on écrivait maintenant les tests et le code de "pontage" (la façon dont j'ai procédé jusqu'à présent étant obsolète). L'expérience est assez satisfaisante, on procède comme avec Cucumber. J'ai donc écrit mes scenarios (purement textuels) puis écrit une classe C# pour faire le pont avec le code de "production", ma classe Game. Ici j'ai réutilisé la classe résultant de mes essais précédents pour aller vite, il aurait été préférable de se laisser guider par les tests pour découvrir petit à petit cette classe - c'est ce que vous conseille si vous voulez tenter l'expérience. Ci-dessous je présente les scénarios, puis la classe de pontage.

» Lire la suite!

Nos quatre ans de pratiques de méthodes agiles nous conduisent maintenant à chercher à créer des conditions plus favorables au développement des compétences et des connaissances. Pour cela depuis peu nous mettons en place un programme de caddying (voir Mise en place du caddying et Le meta-caddy).  Après quelques semaines de vie de ce programme, j'ai pu relever plusieurs aspects très encourageants : apparition de thèmes décidés par les joueurs, proposition de nouveaux services comme Gettting Things Done, support clair du management, mise en place d'un moteur de blog interne...

» Lire la suite!

En préparant le programme de caddying dont j'ai parlé dans un billet précédent, nous avons fait un brainstorming avec une dizaine de personnes (chefs d'équipe, ScrumMasters, directeur, assurance qualité) pour définir la fonction du responsable du programme. Nous avons d'ailleurs vite pris l'habitude d'appeler ce rôle "meta-caddy", les informaticiens aimant bien mettre partout le préfixe meta. Ce brainstorming a permis d'identifier 6 types de responsabilités pour le meta-caddy :

» Lire la suite!