Pourquoi le caddying

Le caddying est une nouvelle étape dans notre mise en place de méthodes de développement agiles (SCRUM principalement), et c'est une tentative de privilégier "les individus et leurs interactions plutôt que les processus et les outils" (cf. le manifeste agile). Notre besoin était de trouver un moyen simple d'alimenter une dynamique d'amélioration continue. Au début nous nous sommes beaucoup appuyés sur une démarche très orientée processus. Toutefois il me semble que sans une réelle dynamique d'amélioration continue, une pratique "orientée processus" de SCRUM comporte un fort risque de délivrer régulièrement et de manière prédictible des produits médiocres. La qualité des produits et la performance des équipes ne viennent pas automatiquement ni magiquement en suivant plus ou moins à la lettre un processus. Au mieux, la qualité augmente un peu parce que vous accordez plus d'attention aux tests, tandis que certains gaspillages sont supprimés étant donné que SCRUM est naturellement lean, mais vous atteignez vite un plateau.

L'idée du caddying est venue de discussions sur ces thèmes avec François Beauregard qui nous avait expliqué ce concept de caddying mis en place dans Pyxis. Nous avons ensuite adapté la démarche à notre contexte, essentiellement en donnant un axe assez technique au caddying pour l'instant.

Notre caddying a certains points communs avec le mentorat, terme qui selon Wikipedia "désigne une relation interpersonnelle de soutien, d'échanges et d'apprentissage, dans laquelle une personne d'expérience, le mentor, investit sa sagesse acquise et son expertise afin de favoriser le développement d'une autre personne, le mentoré, qui a des compétences à acquérir et des objectifs professionnels à atteindre". Mais il nous paraît plus sain d'éviter des termes chargés de sens vagues ou d'a priori comme coach ou mentor, qui requièrent de laborieuses clarifications (voir Managing vs. Coaching vs. Mentoring).

Aussi nous parlons simplement de caddy et de joueur (en référence à ces deux "rôles" dans le golf). Attention, le caddy n'est pas un simple porteur de clubs, c'est un joueur expérimenté qui connaît bien le parcours, et qui est indispensable même aux meilleurs joueurs mondiaux.

Ce billet décrit concrètement comment se passe le caddying dans notre contexte (édition de logiciels scientifiques), en présentant les thèmes sur lesquels nous travaillons, la mise en place concrète, les avantages et inconvénients identifiés après un peu plus de six mois de pratique.

» Lire la suite!

Ce lundi 29 mars j'ai eu le plaisir d'assister à la deuxième édition de la conférence XP Day Suisse, qui se tenait à Genève, tout comme l'année dernière (voir le compte-rendu de Pierre Caboche). Cette conférence bénéficie du soutien de plusieurs sponsors, dont developpez.com (merci pour l'invitation gratuite dont j'ai profité), et d'une équipe d'organisateurs dynamiques et passionnés. J'ai d'ailleurs trouvé excellente toute l'organisation, que ce soit le choix du lieu, le "time-boxing" des diverses séances, les buffets, les zones de temps réservées aux échanges informels et au réseautage, le vote immédiat en fin de séances par gommettes de couleurs, le bon sac en toile de jute durable avec comme "goodies" juste le jeu de cartes de l'alchimiste agile. Félicitations donc aux organisateurs qui nous ont permis de passer une excellente journée.

» Lire la suite!

J'aime bien lire des billets qui contiennent des informations factuelles sur de vrais projets, car cela permet de se situer par rapport à d'autres équipes et entreprises. Récemment j'ai vu notamment le billet Démarches de tests fonctionnels, de Christian Blavier, qui citait des chiffres intéressants (dans les commentaires du billet) :

Voici quelques métriques que je viens de réunir dans différents contextes :
- secteur media, sur un projet avec 3 développeurs qui dure depuis 9 mois on a plus de 100 scénarios de test GreenPepper
- secteur media, plusieurs équipes de 3 développeurs, ils ajoutaient en moyenne 5 tests fitnesse par itération de 2 semaines, soit plus d'une centaine de tests par an
- encore media, équipe de 7 développeurs avec 2 MOA à plein temps et qui font des tests GP depuis 18 mois : 8743 assertions (dans 122 pages) soit 153 assertions en moyenne par itération d'une semaine
- secteur assurance, une équipe de 2 développeurs + 1 MOA sur 6 mois pour tester une plateforme de services (20 web services) : 200 pages de tests Fitnesse et 5000 assertions. Un retour d'exp complet est disponible ici : http://usi2008.universite-du-si.com/WebcastArchi.aspx (session A10)
- secteur open source , octopus microfinance et son harnais de test GP disponible ici : http://wiki.octopusnetwork.org/display/OPUS/Home

Dans ces mêmes commentaires, Louis Pellerin ajoutait :

De mon expérience avec GreenPepper pour le produit Talia que nous développons (un produit sans réelle interface utilisateur), nous avions une proportion d'environ 80 spécifications exécutables (GreenPepper) pour plus de 200 tests unitaires et intégrés (mstest).

Il y a aussi le billet Pendant ce temps-là, à Boulogne., d'Emmanuel Gaillot, qui donne les chiffres suivants :

L'équipe compte actuellement 6 programmeurs (dont le responsable produit), 2 graphistes, 3 modérateurs et une poignée de stake-holders. Tout ce monde travaille dans un ancien atelier réhabilité à Boulogne, dans une même pièce. L'application web est développée en TDD (à l'exception des vues). Elle est actuellement couverte par 951 assertions, réparties sur 563 tests automatisés qui s'exécutent en 35 secondes environ.

En 4 mois de boulot, nous avons consommé 150 pages de flipchart, 15 marqueurs, 100 fiches cartonnées, 2000 post-its de couleurs et tailles variées, 10 stylos feutre, 5 stylos bic, 2 bloc-notes, 50 feuilles A4, un playmobil et 300 viennoiseries.

Si vous connaissez d'autres billets ou articles du même style je suis preneur.

En attendant voici quelques informations du même type sur l'un de nos projets : 38 sprints de développement (durée 3 semaines), une équipe de développement de (en moyenne) 4 développeurs et 1 chimiste testeur/représentant des utilisateurs (plus 1 ScrumMaster, et 1 Product Owner).

» Lire la suite!

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!