Mix-IT 2012 : retours

Introduction

Jeudi 26 avril avait lieu Mix-IT 2012 à Lyon, une conférence visant à mixer agilité, écosystème Java et Innovation IT et j’ai enfin pu y aller : en voici mon retour.

Avant de rentrer dans les détails des sessions que j’ai suivies, un mot sur l’organisation : impeccable ! Très bon accueil, bonne organisation, affichages efficaces, collations irréprochables. Côté programme, une grande diversité et des sessions de qualité : le problème est alors de devoir faire des choix ! Côté point d’amélioration : circulation un peu serrée entre les sessions et écrans un peu bas pour les projections en session, il valait mieux être devant. Mais bon, c'est mineure !

Après les mots d’accueil, nous avons eu une intervention de Martin Gömer (Google France) qui nous a parlé du nouveau Chrome pour Android et a fait sa pub de recrutement ... Pas trop compris ce que ça faisait là ... Mais bravo pour l'écharpe et pour la capture d'écran animée ...

Les tests unitaires sont-ils toujours si rentables ?

Chez un client, les membres de l'équipe, que j'accompagne pendant quelques semaines, m'avaient demandé de leur proposer quelque chose pour aborder la question des tests unitaires et du TDD, dont ils ont entendu parler mais ne pratiquent pas du tout, ce qui ne les empêchent pas de produire en toute qualité, avec un nombre réduit d'anomalies.

Je leur ai naturellement proposé une journée "Tests unitaires et TDD", formule déjà éprouvée chez d'autres clients, avec un programme progressif :

• Présentation théorique (2h) :  coût de correction des bugs, pourquoi tester, tests unitaires, mocks, TDD, bonnes et mauvaises pratiques, conseils et pièges, lien avec l'agilité, intégration continue, etc ...
• Démonstrations sous forme de Kata (1h30) : exemple basique, exemple simple, introduction aux mocks avec Mockito, ...
• Et l'après-midi, mise en pratique pour les participants sous forme de coding-dojo Randori (3h30) : tests simples avec JUnit, puis sujet propice à la mise en oeuvre des mocks, cette session me permettant de guider les participants, les accompagner, d'insister sur les bonnes et mauvaises pratiques, tout en leur offrant un espaces d'expérimentation où ils peuvent toucher du doigt les tests unitaires en approche TDD
• Conclusion, rétrospective, ROTI

Tests et automatisation : pourquoi et comment ? Ou comment j’ai été convaincu pour Selenium

Introduction

Aujourd’hui, j’ai eu la chance de participer à une séance de présentation et d’échanges, inter-services, autour du sujet « tests et automatisation » : vaste sujet !

La séance, proposée et animée par Laurent, était sur la forme de « forum ouvert » (« open space » pour les anglophones), un peu préparé pour guider la séance.

Une introduction, avec quelques généralités sur les tests, a permis d’introduire les termes comme JUnit, Selenium, Jenkins, Sonar, … ainsi que d’aborder très rapidement la question « pourquoi des tests ? » en évoquant : la sérénité, la non-régression, le codage plus rapide, etc …

Ensuite Laurent a proposé et présenté plusieurs sujets, auxquels les participants en ont ajouté quelques uns. Après une séance de vote (type « buy a feature »), une première session avec 2 ateliers en parallèle s’est mise en place :

• Présentation et démonstration Sonar
• Les tests, par quoi commencer ? Selenium et/ou JUnit
  et/ou Jenkins ? 

Connaissant un peu Sonar, je me suis orienté vers le 2e atelier, d’autant plus que les membres de l’équipe que j’accompagne y étaient, et que le sujet est plus d’actualité pour ma mission.

Présentation d'offre en mode agile

Récemment, j'ai répondu à un appel d'offre pour un projet de développement logiciel, en mode agile. J'ai donc fourni un document écrit, assez conséquent. Hier, j'étais convié à Paris chez ce client potentiel, pour présenter oralement mon offre devant une poignée de personnes.

En préparant ma présentation, limitée à 1 petite heure, j'ai listé bon nombres de sujets à aborder, avec la difficulté de synthétiser tout cela pour le peu de temps imparti.

Le client voulant une approche agile pour la gestion et le suivi du projet, je me suis donc naturellement orienté vers l'agilité pour ma présentation, en m'inspirant notamment de l'atelier "Buy A Feature".

J'ai donc commencé par une introduction rapide mais précise, en expliquant que j'avais beaucoup de choses à dire, mais que je voulais être sûr, dans le peu de temps imparti, de répondre aux réelles attentes de l'auditoire, pour un ROI (retour sur investissement) optimum pour tous.

Ensuite, j'ai présenté une diapo avec la dizaine de sujets que je pouvais aborder. Les sujets couvraient tous les aspects du projet, en reprenant en grande partie la trame de mon document initial : qui suis-je, pourquoi ai-je répondu, la solution proposée, l'interface utilisateur, détails techniques, organisation du projet, support et maintenance, etc ...

Comme je m'y attendais, les participants ont d'abord semblé surpris par cette organisation, surtout lorsque je leur ai donné la parole moins de 5' après le début de mon intervention ! La première question d'un des participants a été de savoir s'il n'était pas possible de passer tous les sujets dans la séance. J'ai donc ré-expliqué l'idée d'aborder en priorité les sujets qui les intéressent le plus, et que l'avenir nous dira ce que nous aurons le temps d'aborder ou pas.

Après un petit flottement, pendant lequel je me suis demandé si je n'allais pas renoncer et parcourir linéairement tous les sujets, un participant s'est lancé en choisissant un premier sujet. Puis les choses se sont enchaînées doucement, les participants comprenant certainement un peu mieux le principe, et en voyant peut-être déjà les avantages. Après 20' sur quelques sujets, les dialogues intéressants sont apparus sur base de questions-réponses, au fil des sujets abordés.

Finalement, mon intervention a duré plus longtemps que prévu, le client ayant la maîtrise de la limite horaire. Malgré tout, tous les sujets n'ont pas été abordés. Sont notamment restés des sujets que j'étais persuadé de présenter, comme quoi il est impossible d'anticiper les attentes d'un auditoire, d'un client, d'un utilisateur, le mieux étant vraiment de lui donner la parole !

Comme bon nombre de situations où il faut faire des choix, j'ai senti une certaine frustration des participants pour les sujets non abordés. J'ai un peu pallié à cela en leur laissant le diaporama. Et je préfère qu'ils aient cette frustration en ayant fait leurs choix, plutôt qu'une présentation que j'aurais figé et qu'ils soient frustrés de ne pas avoir entendu certaines informations qu'ils auraient attendues ....

Conclusion. Je suis vraiment content de ce choix de présentation qui était pourtant un peu risqué. Mon objectif a été atteint, et cette nouvelle expérience "agile" était vraiment enrichissante ! Merci aux participants qui ont joué le jeu ...

Objectif Cloud avec l'AlpesJUG

Hier soir, j'ai réussi à m'organiser pour assister à une des soirées organisées par l'AlpesJUG. Les invités Nicolas De Loof et Paul Sandoz étaient venus nous parler .... cloud, c'était à ne pas manquer !


Après quelques rappels sur le cloud, les solutions IaaS, PaaS et SaaS (voir par exemple sur Wikipédia si ces termes ne vous disent rien), Nicolas nous a plus précisément parlé des solutions proposées par CloudBees, notamment :

• Run@Cloud qui offre un service de type PaaS, permettant d'exécuter une application WEB dans un serveur d'application
• Dev@Cloud qui offre un service plutôt SaaS, permettant d'héberger ses sources (Git, ...) et de construire ses projets (ordonnanceur Jenkins)

En 2^ième partie, Paul a présenté les projets CloudBees pour 2012, avec notamment plusieurs évolutions autour de Jenkins et des liens entre cloud public et cloud privé. La volonté de CloudBees pour 2012 est de "faire tomber les barrières" pour démystifier le cloud et y amener les acteurs ....

En fait, je connaissais CloudBees puisque j'ai une application hébergée chez eux depuis 2 ans, enfin avec un démarrage chez Stax Networks qui a été racheté par CloudBees. En effet, en 2010, j'ai développé une application qui devait être accessible par plusieurs utilisateurs via internet. J'ai naturellement cherché un hébergé à la hauteur de mes moyens financiers pour ce projet : aucun ! L'application étant développée avec Play! framework (mince, toujours pas écrit mon article ...), j'ai cherché du côté de la communauté, et Stax m'avait été indiqué sur le forum de Play!.

Pour moi, il n'y avait pas d'alternative. D'ailleurs, je garde et propose cette approche dans bon nombre de situations. L'application mentionnée précédemment est à usage privé, mais devrait s'ouvrir à d'autres groupes d'utilisateurs, et la solution restera "cloud" ! Récemment, pour un nouveau projet, j'ai encore proposé une solution de type SaaS, avec création d'espaces privés pour chaque utilisateur, les avantages d'une telle solution sont tellement nombreux que je n'y vois pas beaucoup d'autres alternatives.

Ce qui me frappe c'est à quel point "le cloud" semble faire peur ou semble mystérieux ... Et pourtant, les solutions de type SaaS sont de plus en plus nombreuses et répandues, mais sans forcément afficher l'étiquette "cloud" : c'est le cas pour GMail, ce blog, les réseaux sociaux, etc ... Finalement, petit à petit et sans s'en rendre compte, tout le monde profite du cloud !

Bon, bien sûr, il y a différents niveaux d'approches. Mon application mentionnée plus haut est en quelques sortes simplement hébergée sur internet, comme une appli PHP chez Free il y a 10 ans (15 ? ah bon, déjà ...), elle n'est pas "scalable" pour que les traitements et les données puissent être répartis sur plusieurs instances de serveurs à la volée, mais c'est bel et bien une première étape vers le cloud, non ?

Pour revenir à CloudBees, je n'ai pas encore utilisé Dev@Cloud, mais j'ai évidemment regardé et suivi cette offre, en attendant une opportunité pour tester.

Mais c'est sûr, le cloud va prendre de plus en plus de place dans notre monde de développement logiciel, il va falloir s'y adapter, revoir nos habitudes, s'ouvrir l'esprit, et certains prestataires comme CloudBees font beaucoup pour nous faciliter la transition !

Merci aux intervenants, à l'AlpesJUG pour cette bonne soirée, et aux chauffeurs de voiture pour les covoiturages !

Agile Grenoble 2011 : retours et réactions

Ce 24 novembre, j'ai pu assister à Agile Grenoble 2011. En voici quelques retours et réactions.

Session plénière

Bon, le classique d'un début de conférence, "le mot des organisateurs" et petit intervention d'un sponsor, pas grand chose à en dire ... Ah si ! Frédéric DUFAU-JOEL (et son collègue) nous parle(nt) de la mutation agile au sein du groupe SAMSE, de ci, de ça, et dans le lot :

"Les chefs de projets formés au rôle de Product Owner". 

Hein ? Comment ? Whaouuuuuu. C'est ce que je disais dans ce billet, je pense que souvent les chefs de projets font plutôt mieux des Product Ower que des ScrumMaster, s'ils connaissent bien le métier. La journée commençait bien !

"Les test intégrés sont une arnaque" par J. B. Rainsberger

J'avais plus ou moins choisi cette séance depuis quelques jours. Mais la veille, avec une trentaine de chanceux, nous avons passé une super journée à coder avec Jo, lors du "Legacy Code Retreat" organisé par le CARA. Du coup, j'ai foncé à cette session !

Joe est cool, sympa et barbu, mais sans en avoir l'air, il a un recul et une maturité passionnants sur le développement, le code, les tests, et le tout plein d'humour !

Joe a commencé par expliquer ce qu'il entend par "tests intégrés" à ne pas confondre avec les tests d'intégration. Ces derniers permettent de tester le lien entre notre code et un autre système ou une librairie extérieure. Les "tests intégrés" portent sur un sous-ensemble du système, un groupe de composants qui inter-agissent entre eux, mais pas sur tout le système. Rappel : les tests unitaires, plus "bas niveau", portent sur un seul composant. Mais pourquoi ces tests intégrés existent ?

Nous connaissons tous la situation suivante : les tests unitaires sont OK à 100% mais il y a des bugs. Ces derniers viennent des interactions entre objets, d'où l'idée du développeur de créer des tests pour couvrir ces interactions, ce sont les "tests intégrés".

Les tests unitaires apportent une "pression positive" sur la conception en me signalant les problèmes par des feedbacks immédiats. Ce qui n'est pas le cas des tests intégrés. Ces derniers entrainent une conception "sloppy" ("négligée"), entrainant des interactions compliquées, donc plus difficile à tester et donc amenant le développeur à créer moins de tests unitaires. Le début de la gangraine et ... de l'arnaque ! Alors que le développeur pensait bien faire ...

Le cercle est vicieux, plus de tests intégrés entrainent ... plus de tests intégrés (car moins de tests unitaires), le "virus" s'auto-réplique menant au "system heat death", la "mort du système par surchauffe" : le coût de maintien augemente exponentiellement et devient trop important.

Ensuite, Joe est rentré plus dans le détail et la technique, parlant des mocks, d'interface entre client et serveur, introduisant les notions de "expectations" (pour vérifier les interactions) et "stubs" (pour simuler les réponses) selon le sens testé pour l'interaction entre le client et l'interface, puis l'idée de "design by contract". Les problèmes d'intégrations sont alors dûs à des désaccord sur le contrat.

Il faut donc une cohérence entre les tests de collaboration de part et d'autre de l'interface, chaque test d'un côté doit avoir son pendant de l'autre. Aux "expectations" doivent correspondre des "actions", et aux "stubs" doivent correspondre des "expected result" : on parle alors de "tests de contrats".

Joe a fini rapidement avec un exemple de tests sur l'ArrayList et la LinkedList dérivant toutes les 2 de List, avec le souci de supprimer les duplications en remontant le code similaire dans la classe parente abstraite "ListTest", aboutissant à une couverture de cas maximale.

Cette présentation était vraiment super intéressante, surtout qu'il me faut maintenant explorer en détails toutes les notions présentées rapidement ci-dessus. A noter que Joe a fait une présentation sur "tableau papier" sans aucune note : chapeau et merci !

@xnopre 28/11/2011 : Oups, tellement évident mais tellement sympa : j'ai oublié de remercier Joe pour son effort de présentation en Français, comme la veille pour le Legacy Code Retreat, effort appréciable et discours impeccable ! Merci !

"Démonstration / Kata BDD sur un logiciel pilotant un instrument" par Matthieu Gironnet et Johanny Bergeron

L'objectif de cette session était de présenter le développement piloté par les tests d'acceptances exécutables sous forme de démo, avec un vrai système qui bouge.

Je dois admettre que les orateurs ne semblaient pas super à l'aise, mais c'est difficile et il faut bien commencer, bravo à eux.

La session était intéressante mais certains points en ont baissé la pertinence. Le permier point est un manque de précision sur les parties de système simulées ou non. Les orateurs ont expliqué ne pas utiliser le vrai logiciel complet mais un faux ("fake"). Hors, dans les démos, l'instrument bougeait. Ca a dû apporter de la confusion à pas mal de monde, d'ailleurs en fin de séance, quelqu'un a posé la question. Mon expérience des tests fonctionnels exécutables en environnement industriel, proche de celui-là, avec le développement de pilote, m'a permis d'extrapoler et de comprendre : ils utilisaient bien un "faux" système mais qui chargeait le "vrai" driver qu'ils ont développé et voulaient tester.

Le second point portait sur la présence du code de production. Le temps de session étant court, les orateurs ont mis le focus sur l'écriture des tests par le Product Owner (copié-collé un peu trop rapide empêchant de lire ces tests et donc de bien suivre) et le développement nécessaire côté fixture pour exploiter ces tests. Du coup, une fois ce dernier code écrit, les tests sont tout de suite passés au vert puisque le code de production était là : nouvelle confusion certainement ...

Sachant que ce mode de présentation "en live" est risqué et donc audacieux, c'est tout de même tout à l'honneur des orateurs d'avoir osé cette sesssion technique sommes toutes réussie !

Slam par UnDeuxGround

Après la pause déjeuner (mieux organisée et réussie que l'an dernier), les compères slameurs nous ont fait des mélanges d'actualités (Le Monde du jour même) et d'agilité (idées piochées ici et là dans les sessions). Sympa, de bonne qualité et distrayant !

"Maîtriser le legacy avec Mikado" par Johan Martinsson et Miguel Moquillon

Les intervenants ont attaqué par un sketch en enchaînant 4 "daily stand-up meetings" pour mettre en évidence des situations concrètes que nous avons tous vécues :

• "Analysis-Paralysis" : le développeur est bloqué, mais c'est pas grave, ça va pas durer !
• "Multiplication des modifications" : plein de modifications partout, apparition d'instabilités
• "Tunnel noir" : la découverte des problèmes au fur et à mesure, pas de visibilité, "encore 2 problèmes à régler mais c'est pas les mêmes que les 2 d'hier"
• "Grand merge" : la fusion est douloureuse

Les orateurs ont ensuite enchaîné par la refonte de code en direct, en utilisant une nouvelle méthode : Mikado. Une pause au bout de quelques minutes pour nous expliquer la méthode que nous étions en train de voir "en vrai", en expliquant le principe qui consiste à noter son objectif et de quelles tâches il dépend. Ces tâches peuvent parfois être traitée, ou sinon, en nécessiter d'autres que l'ont identifie sur le tas. Il est alors impératif de revenir en arrière, dans la dernière situation stable, avec de s'attaquer à ces nouvelles tâches "feuille", et ainsi de suite ... On construit alors le graphe Mikado.

Reprise du codage, que l'on comprend alors mieux, puis une nouvelle pause pour faire l'analogie avec le "vrai" jeu Mikado : on a alors sous les yeux, d'un côté un vrai jeu Mikado (les "baguettes") sur une table, vidéo-projeté sur l'écran de droite, et le graphe Mikado sur l'écran de gauche, et l'analogie saute aux yeux. D'un côté le mikado noir qu'il faut attraper, dessous, en voyant bien ce qu'il faut enlever d'abord. D'un autre, l'objectif final (ajouter une fonctionnalité) avec toutes les tâches qu'il faut traiter d'abord (pour l'instant ....).

Par rapport aux 4 situations présentées dans le sketch initial, les réponses de la méthode Mikado sont :

1. Une analyse en local du problème, avec la découverte petit à petit des problèmes grâce au fait d'envisager des solutions simplistes
2. Des modifications avec un stabilité permanente
3. Une phase exploratoire permettant une meilleure visibilité de la situation découverte au fur et à mesure
4. La possibilité de commits et merges fréquents pour une intégration progressive

Dans le total prolongement du "Legacy Code Retreat" de la veille, cette session m'a permis de bien comprendre l'intérêt évident de l'approche proposée par la méthode Mikado. En plus, la présentation était vivante, pleine d'humour, bien rythmée entre l'alternance de "direct" et d'explications, et surtout : du vrai code ! Yeah les artisans ! ;-) (à suvire dans un prochain article sur "Innovation Grenoble" ...)

Bravo et merci !

"Git au quotidien" par Guillaume Gardais et Laurent Tardif

Je connais Git que j'ai un peu utilisé, voir mon enthousiasme dans ce REX. Néanmoins, persuadé de l'intérêt et de l'avenir de Git, j'ai choisi cette session pour vérifier ce point de vue et éventuellement en apprendre un peu plus. Je n'ai pas été déçu !

Bien sûr, Git est l'avenir. Même si la session ne le fait pas ressortir, l'outils est présenté de façon attrayante (pleins de possibilités) mais peut-être effrayante (trop de possibilités). En effet, cette grande liberté nécessite la mise en place de règles pour l'utiliser de façon commune dans une même équipe.

Et pas déçu, car j'ai appris des choses, même si les commandes présentées étaient basiques. Les explications des orateurs sur les possibilités de repo local et de repo public par développeur, les possibilités d'échange 1 à 1 entre 2 développeurs, et, très intéressant, les possibilités de build automatique par le serveur d'intégration continue de mon propre code dès que je le rend public : super intéressant ! J'ai donc mieux compris ces concepts de bases que j'avais rapidement passés lors de ma mise en oeuvre de Git.

Là aussi, bravo et merci !

"Symphonie pour PHP industrialisé en agilité majeure" par Jonathan Bonzy, Marc Nazarian et Bernard Huguet

Depuis quelques temps, notamment suite à une mission en PHP, en tant que développeur Java (essentiellement), je me questionne sur l'avenir de ce langage. Surtout que bon nombre de structures mondiales l'ont choisi pour des applications utilisées par des millions d'utilisateurs dans le monde (pas besoin de donner d'exemples !). En plus, depuis la version 5, le langage s'est orienté vers l'objet, et l'outillage ne cesse de s'étoffer ces derniers mois (ou années ?), notamment pour les tests unitaires et autres outils pour du code propre et de qualité. C'est donc sans hésiter que j'ai choisi cette session parlant en plus d'industrialisation.

Ici encore, les 3 orateurs ont opté pour la mise en scène théatrale permettant d'avoir une séance vivante tout en faisant passer des messages importants sur base de comparaisons. Nous avions donc devant nous un Product Owner, avec un nouveau projet, sollicitant 2 développeurs ayant des approches très différentes mais faisant, bien sûr, au final, les bons choix ! A savoir :

• PHP pour le Web et la charge, 
• NetBeans comme IDE, 
• Symfony pour le framework et éviter de réinventer la roue, 
• PHPUnit + Behat + Selenium pour les tests à tous les niveaux, 
• Maven pour l'industrialisation, 
• et Jenkins pour l'intégration continue. 

Le tout est proposé dans un Boilerplate disponible sur internet pour permettre à chacun d'être rapidement opérationnel dans un environnement de qualité. Bravo les gars, je vais m'empresser de télécharger tout ça !

A noter au passage une remarque intéressante et très importante : les tests fonctionnels sont plus lents et plus difficiles à maintenir. Donc ne pas en abuser, bien respecter la pyramide des tests. A une époque où l'on parle de plus en plus de BDD, attention à l'effet de mode, il est bon de rappeler les limites. +1 !

La seconde partie de séance a continué par des revues de sprint toujours sous forme théatrale, permettant aux 3 compères de mettre en avant des points intéressants :

• un début de projet pas vraiment productif ("Hello world") mais permettant de mettre en place les outils pour une production de qualité, et le montrer au PO en lui expliquant
• une avancée itérative, progressive, avec une forte collaboration entre le PO et l'équipe, et bien sûr, une forte productivité en toute qualité (présence de tests, etc ...)
• la méfiance et la nécessité de ne pas s'emballer pour, par exemple, la reprise d'un projet existant, en commençant par vérifier le comportement de l'application par un dialogue fort avec le PO et la mise en place de tests, avant de commencer le moindre codage

J'ai vraiment jugé cette session de manière très positive, autant sur le fond que sur la forme qui permet de faire passer des messages importants. La mise à disposition d'un "pack" près à l'emploi est également une chouette initiative que je vais rapidement tester et évaluer, et qui ne peut que contribuer à promouvoir les valeurs de l'agilité, notamment autour de la qualité et des bonnes pratiques (même si ça ne fait pas tout).

Et là encore, bravo et merci !

Le diaporama était déjà en ligne ici, et le boilerplate est disponible sur github : cool et merci !

Conclusion

Finalement, je m'aperçois que j'ai surtout suivi le trac "technique", comme quoi ça me passionne, et je pense qu'il est important de ne pas mettre la technique de côté dans ce genre de manifestations. L'agilité ne peut pas se mettre en place dans une structure si la technique et les bonnes pratiques des développeurs ne suivent pas. Or, ce point est trop souvent négligé dans les migrations vers l'agilité, et c'est dommage, surtout si c'est pour aboutir à une réussite partielle voir un échec ...

Concernant le programme, je pense qu'il manque un trac pour les novices, pour présenter les idées et concepts de base de l'agilité, de Scrum, de l'ingénierie agile, etc ... C'est sûr, le niveau à Grenoble est élevé, tant côté orateurs que participants. Néanmois, le public est varié, et pour continuer à élargir la promotion de l'agilité, il me semble important d'en donner l'accès à tous, y compris les curieux qui n'y connaissent rien. A méditer ...

Et bien sûr, bravo et merci au CARA et à l'équipe pour l'organisation impeccable !

A suivre ici prochainement si tout va bien : d'autres retours sur cette semaine pleine d'agilité, notamment Grenoble Innovation ...

Coder proprement : évitez le bruit !

La publication de cet article m'a été motivée par l'article de François Wauquier Refactoring: Supprimmer le bruit qui a tout de suite fait résonner chez moi des concepts que je voulais partager ici depuis longtemps, et dont en voici quelques uns, en rebondissant sur certains thèmes abordés par François.

D'ailleurs, François mentionne essentiellement le code de test, mais pour moi, les règles sont les mêmes que le code soit de test ou de production !

Javadoc et commentaires

Pour moi, la meilleure JavaDoc est le code lui-même. Idem pour les commentaires. En plus, tout cela ne sera que rarement maintenu avec l'évolution du code, mieux vaut de loin un code explicite, avec des nommages (variables et méthodes) clairs, précis et parlants, quitte à être un peu long ... Un roman avec des phrases ...

J'aime bien le principe de Robert C. Martin dans son livre Coder Proprement (que je recommande !) pour qui le recours au commentaire est le signe d'un échec pour trouver de bons nommages.

Pour la JavaDoc, je différencie néanmoins le cas d'une librairie publique, ou du moins utilisées par d'autres équipes (par exemple), exposant une véritable API, où la JavaDoc peut avoir de la valeur ajoutée, mais à condition d'être complète, à jour, compréhensible, etc ... un vrai boulot !

Getter et setter

Je suis arrivé à la pratique suivante : si mon objet est un "objet de données" ne servant qu'au sein de mon package, aucune hésitation, pas de getter/setter et les attributs en portée "package" (donc sans préciser la portée). Par contre, s'il s'agit d'une API, là j'hésite un peu plus, surtout si mes objets doivent être immutables, dans ce cas, attributs privés fournis dans le construteur et accessible uniquement par les getter : 

public class User {

 private final String name;

 private final String phone;

 public User(String name, String phone) {
  this.name = name;
  this.phone = phone;
 }

 public String getName() {
  return name;
 }

 public String getPhone() {
  return phone;
 }
}

A noter tout de même que les getter/setter peuvent faciliter le débogage, ainsi que le refactoring (i.e. un getter qui n'en est finalement pas un ...). Donc, à voir selon les situations ...

Découpage des tests

Pour moi, la règle simple est la suivante : bien respecter le découpage d'un test en 3 phases, présentées sous forme de blocs séparés par une ligne vide :

1. préparation
2. test (et un seul)
3. vérifications (une ou plusieurs assertions)

Si nécessaire, une phase additionnelle de nettoyage peut être envisagée. Ne pas oublier que chaque test doit être indépendant, les tests doivent pouvoir être déroulé seul ou dans n'importe quel ordre.

J'ajouterai que si la phase de préparation est un peu longue, ne pas hésiter à la reporter (tout ou partie) dans des méthodes pour augmenter sa simplicité et donc sa lisibilité.

Constructeur vide et "super()"

Je ne les mets jamais, mais effectivement, il faut bien se poser la question lorsqu'on ajoute un constructeur avec des paramètres : ne faut-il pas un constructeur vide également (piège) ?

De même, je supprime les "super()" en début de constructeur, totalement inutile et alimentant le "bruit" !

Messages d'assertions

Tiens, c'est marrant, jusqu'à très récemment, dans mes formations ou interventions, je préconisais l'ajout systématique d'un message dans les assertions, pour bien expliquer la situation. Mais lors de mes 2 dernières interventions, j'ai remis cela en question.

En effet, je me suis rendu compte de la difficulté pour les développeurs pour comprendre le rôle de ce message (quand est-il affiché et à quoi sert-il ?) et trouver le bon texte (risque de message inversé ou innaproprié). Et lorsque le principe est compris, les messages peuvent vite se retrouver très longs, nuisant ainsi complètement à la lisibilité du test. Sans compter, les duplications de tests où le message n'est pas mis à jour.

J'en arrive finalement à changer d'avis et opter pour l'absence de messages, mais avec des nommages clairs et explicites (ici encore !), éventuellement par l'usage de méthodes personnalisées permettant de regrouper plusieurs assertions :

    assertThatObjectContainsTheThreeFirstNumbers(generatedObject);

Variable locales et nommages

J'adhère à l'approche de Robert C. Martin qui démontre que l'utilisation des variables locales est dangereuse et qu'il faut donc limiter leur usage. Donc, on les supprime, sauf si la ligne générée devient vraiment trop longue ou si la présence d'une variable locale intermédiaire peut aider à la lisibilité et la compréhension du code.

Dans ce cas, le nommage est très important, éviter les noms courts, voir très court à une ou quelques lettres. Et comme le dit François Wauquier, "Le meilleur nommage pour une variable est le nom de sa classe". En plus, Eclipse le fait automatiquement avec la commande "Refactor / Extract Local Variable" (ALT + SHIFT + L).

Conclusions

Le refactoring est indispensable et doit être quotidien dans le travail d'un développeur. Il est incontournable pour faire évoluer un code existant, notamment pour lui ajouter de nouvelles fonctionnalités. Le risque varie selon le type de refactoring effectué (renommages, extraction en méthodes, reprise d'algorithme, ...) et les modifications évoquées par François Wauquier et reprises en partie ici sont à faible risque.

J'aime beaucoup l'analogie trouvé par François avec le bruit, j'aurais aimé la trouver moi-même, je reprendrais l'idée, bravo et merci !

Et comme François propose de Supprimer le bruit, je pousse un peu plus loin en proposant, en plus, sur du nouveau code, d' Eviter le bruit ! ;-)

Forfait, marché public et agilité : petit REX

J'ai récemment clôturé une petite affaire, au forfait pour un organisme public, donc un marché public. Le projet a été proposé et mené dans une approche agile dont voici un petit retour d'expérience.

Contexte

• Evolutions et corrections sur une application WEB interne existante
• Liste des points à traiter fournie dans le cahier des charges mais manque de clarté et de précision
• Affaire traitée en moins de 2 mois par une personne (moi)
• Seulement 3 intervenants : 2 interlocuteurs côté client (dont 1 que je connaissais déjà) et moi-même

Idée de départ

Adepte des approches agiles, il me semble désormais difficile, voir impossible, de mener une affaire en mode "classique" :

• Etablir et signer un cahier des charges fixe
• Se mettre d'accord sur un délai et un tarif (et donc un contenu)
• Développer "hors site" pendant plusieurs semaines (ou moi)
• Le jour J, livrer ce qui a été réalisé, prendre acte des problèmes et mécontentements, les gérer au mieux, et se faire payer !

J'ai donc souhaité proposer une approche plus agile, en m'inspirant de Scrum, et de mes expériences en agilité, en me donnant quelques objectifs précis :

• Satisfaire les utilisateurs finaux et donc mon client
• Permettre les changements par le client en lui donnant le contrôle de la priorisation
• Fonctionner en cycle court pour avoir du feedback régulier

Vocabulaire

Les 2 interlocuteurs pour ce projet ne sont pas du tout expert en informatique, logiciel, développement, etc ... De plus, le projet était court en durée. J'ai donc opté pour une adaptation du vocabulaire par rapport à Scrum :

• "Histoires" (Stories) : j'ai plutôt parlé de "fonctionnalités" tout simplement
• "Carnet de produit" (Product backlog) : j'ai introduit la notion de "Référentiel des fonctionnalités" pour le document que j'ai créé en début de projet, avec la liste des points à traiter, que j'ai complètement ré-exprimés, et que j'ai maintenu à jour tout au long des développements, fournissant ainsi en fin de projet un état des lieux des points traités ou non
• "Itérations" (Sprints) : j'ai gardé le terme d' "itérations" qui reste intuitif et a été très bien adopté par tout le monde
• "Vélocité" (Velocity) : j'ai plutôt évoqué la "capacité de production" journalière permettant d'estimer un "volume de production" par itération
• "Réunion de planification" (Sprint planning) et "Revue d'itération" (Sprint review) : j'ai regroupé ces 2 cérémonies en une seule baptisée simplement "Réunion d'itération"

J'ai laissé de côté le rôle de ScrumMaster pas vraiment utile dans ce contexte. Le terme de "Responsable de produit" (Product Owner) a été évoqué dans la présentation initiale de l'approche, mais sans être utilisé par la suite.

Approche proposée et organisation

Le projet a commencé par la ré-expression des points à traiter pour donnant naissance au "Référentiel des fonctionnalités", sur base des éléments initialement fournis, et grâce à des échanges avec les 2 interlocuteurs pour leur faire exprimer les besoins (et non les solutions comme c'était le cas dans le cahier des charges fourni).

J'ai ensuite estimé chaque fonctionnalité en "points", de 1 à quelques dizaines. Les fonctionnalités ambiguës ont été estimées avec des fourchettes de points, et séparées des autres pour être précisées avant d'être implémentées. Un repère de 6 points par jour a été utilisé.

A chaque début d'itération, le RDV de la prochaine "Réunion d'itération" était fixé permettant d'en déduire le nombre de jours possibles de production (selon le calendrier et mes disponibilités), et donc le volume estimé de production selon la "capacité de production". Exemple pour l'itération 1 : 6 jours à 6 points = 36 points. Le client pouvait alors "faire son marché" et choisir lui-même les fonctionnalités à implémenter dans la prochaine itération.

Les échanges en cours d'itération ont été nombreux, surtout par mails, pour demander des précisions ou des validations mineures, et tenir informé le client des éventuels changements de planning (1 jour de production en moins par exemple).

En fin d'itération avait lieu la "Réunion d'itération" découpée ainsi :

• Point sur l'itération écoulée, bilan du temps passé, des fonctionnalités traitées ou non, évaluation de la nouvelle "capacité de production"
• Démonstration sur mon portable de chaque fonctionnalité traitée
• Si la satisfaction est au RDV, et si c'était prévu, mise en production
• Préparation de l'itération suivante

Une mise en production a été prévue et réalisée en fin d'itération 2, et bien sûr, en fin de projet.

Observations et constats

Adoption de la méthode : malgré des réticences en début de projet, la méthode proposée a été très vite adoptée, avec une satisfaction manifestée dès la fin de l'itération 1.

Référentiel des fonctionnalités : ce document a vraiment été la colonne vertébrale du projet, servant de référence permanente pour tous, mais nécessitant un investissement pour sa mise à jour quotidienne. Son intégration parmi les livrables à chaque itération, et donc en fin de projet, a permis de fournir au client un véritable état des lieux des développements, et notamment en fin de projet, une vision claire de ce qui a été réalisé, et surtout de ce qui ne l'a pas été, par exemple pour prévoir une prochaine intervention sur l'application.

Vélocité : pour la première itération, la capacité de production avait été estimée à 6 points par jour. Malgré 1 jour de production en moins, tout ce qui avait été prévu a été traité, amenant à constater une capacité de production supérieure à 7. Cette capacité a donc été portée à 7 pour l'itération suivante et est restée à cette valeur pour le restant du projet.

Priorisation : le système de "marché à points" proposé a tout de suite été compris et bien pris en main. Les interlocuteurs connaissait bien le sujet, les objectifs du projet et les points à traiter. Ils n'ont jamais eu de difficultés à choisir les fonctionnalités à traiter selon la capacité disponible.

Suivi et feedbacks : ce point a été parmi les plus forts du projet, puisque les échanges réguliers ont permis d'établir une véritable collaboration avec le client, qui avait une vision claire et transparente de l'avancement, et sentait au jour le jour sa capacité à aller ensemble vers un résultat de qualité permettant de satisfaire les utilisateurs.

Proof of concept : un exemple caractéristique de l'intérêt du feedback :
Pour plusieurs fonctionnalités, j'ai proposé une solution de pages à comportement dynamique (afficher certains champs selon des choix effectué par l'utilisateur). Pour permettre au client d'appréhender la solution proposée avant de l'appliquer à plusieurs endroits, elle a été implémentée sur un cas lors de la première itération. Le client a ainsi pu la visualiser et la valider pour qu'elle soit implémentée sur le reste de l'application.

Droit au changement : le client ayant bien adopté le système de priorisation à sa charge sur base du système de points, il a tout naturellement intégré la possibilité de changements, évidemment en respectant les volumes de charges. Ainsi, bon nombre de changements ont eu lieu au cours de chaque itération, avec des changements sur certaines fonctionnalités, sur leur priorisation, mais également la prise en compte de nouvelles fonctionnalités ou extensions de tâches réalisées.

Encore plus fort ... : lors de la préparation de la quatrième et dernière itération, une discussion a eu lieu autour de fonctionnalités de recherches au sein de l'application existante. Le client a exprimé son insatisfaction récurrente et ancienne par rapport à ces fonctionnalités, et le souhait d'un unique moteur de recherches croisées. J'ai fait quelques remarques et propositions de fonctionnement et d'ergonomie. Le client m'a demandé une estimation (en points bien sûr) qui s'est avérée assez importante, quasiment égale à la capacité de production pour la dernière itération à venir. Après réflexion, le client a décidé d'abandonner tout ce qui restait au cahier des charges pour favoriser la mise en place de ce nouveau module, qui n'avait pas du tout été prévu dans le projet ! Donc un changement complet du reste du projet aux 3/4 de son déroulement ! Et le résultat ne l'a pas déçu, sans aucun regret pour les fonctionnalités écartées, qui ne sont finalement que partie remise pour un prochain projet ;-) .....

A améliorer

Le premier point est dû à ma découverte des appels d'offres pour marchés publics, pour lesquels le montant est fixé (politiquement), alors que j'avais imaginé plus d'échanges et mises au point avant le lancement du projet (évaluation des besoins, explications sur la méthode, ajustement du volume, ...).

Le second point qui m'a piégé est d'avoir mal anticipé la fin du projet pour lequel il aurait été bon de prévoir un volume d'intervention après la dernière itération pour finaliser les développements selon les remarques et observations exprimées lors du bilan de la dernière itération.

Enfin, le "Référentiel des fonctionnalités" devrait idéalement être tenu de façon collaborative, donc un format type Wiki sur un serveur accessible de tous pourrait être intéressant. Mais dans le contexte de ce projet, l'implication du client ne serait pas allée jusque là, et la mise à disposition d'un fichier PDF en fin de projet a été apprécié.

Conclusion

Pour moi, elle est simple : une réussite totale (ou presque) du traitement en mode agile pour ce projet.

Bien sûr, il faut pondérer ce résultat en prenant en compte le contexte "favorable" de ce projet : tout petit projet, liste assez précise des besoins, interlocuteurs connus et collaboratifs, etc ...

Néanmoins, cette expérience reste intéressante et me semble transposable à plus grande échelle, vivement une prochaine opportunité ...

Et vous ? Que vous inspire ce retour d'expérience ? Quelles sont vos expériences en la matière ? ...

Agile Tour Marseille 2011 (retour)

Le 13 octobre dernier, j'ai assisté et participé à l'Agile Tour Marseille 2011, en voici un petit retour, selon quelques prises de notes que j'ai pu faire.

Un document agile se promène un fil - Jean-François Jagodzinski

J'ai choisi cette session pour avoir l'approche de JF sur la documentation en contexte agile.

JF commence par dresser l'approche "classique" où la documentation est au centre du système, entre "Information", "Process" et "Travail". Intéressant de noter qu'il peut se passer des mois de "travail", permettant de produire de la documentation mais ... aucun produit : bonjour le ROI !

J'ai bien aimé la vision en cascade du cycle de vie d'une documentation de type spécification : collecte du besoin, analyse, conception, puis réalisation. JF plaque sur ce schéma le fait que, dans la réalité, les individus vont osciller entre ces différents états. Par exemple, dans la phase de collecte ou d'analyse, il est fréquent de faire un aller-retour vers l'état plus technique (réalisation par exemple) pour vérifier la faisabilité. De même, dans les phases de conception ou réalisation, il n'est pas rare de revenir vers l'état de collecte pour approfondir le besoin. Ajoutons à cela que chacun oscille différemment, et c'est l'anarchie, l'incompréhension, le déphasage, .... l'échec.

D'où l'idée en agilité de favoriser les échanges entre individus pour exploiter positivement ces oscillations ...

J'ai noté en vrac :

• Le travail peut être du plaisir (j'aime !)
• Il faut éviter le filtrage de l'information, d'où l'idée en contexte agile que l'équipe soit en contact direct avec la source pour faire son propre tri de l'information utile
• La documentation doit avoir de la valeur métier, doit prendre moins de temps et moins d'espace
• Favoriser l'accès et l'utilisabilité de la documentation, ainsi qu'une saisie rapide et facile, et une gestion minimum (exemple : Wiki bien sûr !)

JF est ensuite passé à une représentation intéressante de la documentation en contexte agile, avec tous les éléments la constituant : la vision, le product backlog, les conditions de satisfaction, les contenus d'itération, les spécifications exécutables, les tickets, etc ... L'idée suivante m'a beaucoup plu : il est possible à partir de ces éléments de reconstituer intégralement une documentation "classique" (planning, specs, PAQ, etc ...). Et oui, on a tout mais sous une forme différente !

Un membre de l'auditoire a posé des questions sur le planning, en expliquant qu'en méthode classique, grâce à son planning, il sait qu'il aura telle fonctionnalité au mois de mars. Pour moi, c'est un leur, tout comme un contrat au forfait en mode classique : un leur je vous dis ! Mais j'y reviendrai dans un prochain article ... Mais pour moi, un planning est prévisionnel mais jamais prédictif ....

Session intéressante, une approche différente et transversale de tous les éléments de l'agilité et de Scrum, au travers de la documentation.

"Marshmallow challenge" - Pablo Pernot

L'intitulé de la session de Pablo ne laissait pas entrevoir ce jeu, je ne sais pas pourquoi : "Planification et itération : itérations, redéfinition, équipe hétérogène". Mais bon, peu avant les sessions, j'ai su qu'il s'agissait d'un "Marshmallow challenge". J'ai donc choisi cette session car je n'ai jamais assisté à des jeux à objectifs pédagogiques pour l'agilité (à part le "Scrum Tower Game" que j'ai mis au point pour ma journée d'introduction "Agilité et Scrum").

Je n'ai pas été déçu. Pablo a la pêche ! Et c'est tant mieux, ça se prête bien au contexte.

Je ne reviens pas sur le jeu pour lequel on peut trouver plein d'informations sur le site http://marshmallowchallenge.com/. Ce qui est intéressant c'est qu'il a été joué par des milliers de personnes, et donc qu'il existe des statistiques très intéressantes dont Pablo nous a donné un aperçu : les enfants réussissent mieux que la moyenne, les équipes hétérogènes en profils réussissent également mieux, etc ...

Tout comme pour ma session (voir ci-dessous), je pense que l'intérêt dans une telle conférence mais pas tant l'intérêt pédagogique du jeu, mais plus sa découverte pour le mettre en pratique. Pablo m'a semblé surpris, voir déçu peut-être, des conclusions qui pouvaient être tirées de cette session. Mais pour moi, le contexte n'est pas comparable à celui d'une entreprise où un coach intervient, le public présent est très différent avec des attentes tout autres.

J'ai donné un ROTI de 5 à Pablo car je n'ai vraiment pas perdu mon temps, j'ai pu voir une façon de mettre en place et animer cet atelier, ça m'a donné envie de creuser ce jeu pour peut-être l'utiliser dans mes propres interventions.

Coding-dojo ou l'apprentissage du TDD - Xavier Nopre

Franchement, je ne me sentais pas les épaules pour être "orateur" dans une conférence. Mais finalement, grâce à la convergence de différents éléments, je me suis lancé, j'ai proposé une session "Coding-dojo et TDD" qui a été retenue.

C'est une animation que j'ai fait plusieurs fois en entreprise, mais là, le contexte était différent : les gens ne se connaissent pas, ils ne sont pas censés tous participer, ils ont probablement des niveaux très différents (plus qu'au sein d'une même entreprise).

Ce qui me faisait donc presque le plus soucis était la façon de faire passer les personnes au clavier. En entreprise, je mets tous les noms sur des papiers dans un chapeau et on tire au sort. Là, j'ai laissé faire, et ça a bien fonctionné, il ne m'a manqué personne durant la session.

Public varié ? Oh que oui ! Entre ceux qui ne connaissent pas le TDD et celui qui ne fait que ça depuis 7 ans ! Mais également sur les capacités de développement, d'improvisation, de frappe, d'expression, etc ... Sans compter qu'en passant devant les autres, on perd pas mal de ses moyens. Mais tout cela était très riche.

Il y avait également la question du choix des sujets. Le sujet doit être simple et très abordable pour les participants pour garder le focus sur l'objectif pédagogique (par exemple, le TDD) et éviter de perdre du temps dans des recherches algorithmiques ou autres. J'avais pensé que le public serait hétérogène mais d'un niveau minimum, surtout s'il venait à cette session, et ça a été le cas, apparemment, les sujets n'ont pas posé de problèmes, nous avons pu mettre l'accent sur le TDD.

Un autre point que j'ai pu vérifier (après l'avoir vérifié la veille en entreprise) : le coding-dojo est accessible à tous, quelque que soit le langage, quelque soit le profil. Pour le langage, certains sont passés au clavier en ne connaissant que le C et ils ont codé en Java sans problèmes apparemment, avec l'aide de l'assistance, nous sommes bien dans un travail collectif. Mais ceci s'est également vérifié pour les profils, certains n'étaient visiblement pas ou plus trop "technique" (comme par exemple un chargé de recrutement), et eux aussi ont pu s'essayer sans problème à prendre leur tour de rôle au clavier.

Au final, les retours sont très positifs, ça fait plaisir. Surtout que c'était réciproque, j'ai moi aussi eu grand plaisir à expliquer et montrer ce qu'est un coding-dojo, et en guise d'exemple, le TDD et la vision que j'en ai. Donc, un grand merci à Karine pour sa stimulation et ses bons conseils, aux participants à ma session qui ont bien joué le jeu, à toute l'équipe d'organisation pour ce bon moment, ainsi que le repas entre orateurs. Bravo !

Coding-dojo ou l'apprentissage du TDD

Introduction

Dans le cadre de mes interventions en entreprise, j'ai eu il y a quelques temps une demande pour « pousser » une équipe de développements vers le TDD. M'a réponse a été de proposer une solution en 3 étapes sur une journée entière.

Cette journée s'est déroulée le lendemain d'une journée de formation, ou plutôt comme je préfère dire, d'information « Agilité et Scrum ». Les participants à la journée « TDD » avaient donc connaissance des valeurs et principes de bases de l'agilité et de Scrum, véritable pré-requis pour aller droit au but du TDD.

Étape 1 : théorie

La première partie de la journée est une présentation théorique sur base d'un diaporama.

On commence en abordant le sujet des tests : tests unitaires, tests d'intégration, tests fonctionnels, automatisation des tests, etc ... Pour faire du TDD, il faut évidemment être d'abord convaincu de l'intérêt d'avoir des tests, et qu'il est plus facile de les écrire avant plutôt que après le code de production, le système étant alors forcément « testable ». On revient notamment sur le coût de correction des bugs qui sera d'autant moins élevé que le bug est décelé tôt (cf Scott Ambler).

On évoque ensuite les outils : les frameworks de tests (JUnit pour Java, PHPUnit pour PHP, Hunit pour Haskell, etc …) et les frameworks de mocks (Mockito, Easymock, JMock, PowerMock, etc …). C'est l'occasion d'expliquer l'intérêt des mocks quasiment indispensables si on fait une architecture bien découpée, à couplage lâche et injection de dépendances.

On ne peut parler de tests sans poser les règles de base, ainsi que les bonnes pratiques : 1 test pour 1 cas, des tests structurés, rapides, évolutifs et propres, du refactoring avant toute chose, etc …

Vient ensuite la présentation du TDD proprement dit : pourquoi du TDD, principes, cycle (rouge-vert-bleu), les variantes, les difficultés, les erreurs à ne pas commettre, les conseils, etc …

La partie théorique se termine par la présentation du coding-dojo : c'est quoi ? Pour qui ? Le Kata et le Randori, organisations et logistique, conseils, etc ...

Étape 2 : démonstration

Pour illustrer le propos, comme on dit, la matinée se termine par une démonstration. Je me met au clavier avec mon environnement de développement, et en partant de sources vides, je montre comment se déroule le TDD.

La démonstration se déroule sur plusieurs exemples de difficultés progressives pour montrer les bases du TDD : un exemple basique, la mise en œuvre sur un exemple plus complet mais toujours simple, et enfin, l'utilisation de mocks sur une exemple bâti sur plusieurs classes, donc des tests sur une classe ayant besoin de collaborateurs.

J'ai constaté des intérêts multiples à cette phase de démonstrations : la possibilité pour les développeurs de concrétiser les explications précédentes, la preuve par la pratique de la faisabilité, un gain de crédibilité et de légitimité en mettant les mains dans le cambouis.

Étape 3 : coding-dojo

L'étape suivante, qui se déroule sur au moins 3h l'après-midi, est la plus ludique et souvent la plus attendue. C'est le moment du « conding-dojo », que j'appelle également « séance de développement en groupe ».

Ma mise en pratique est assez proche des principes que je ne rappelle pas ici, et qui sont facile à trouver sur internet. Par expérience, et après avoir testé différentes durées, je fais des « tours » de 6'. Par contre, je n'hésite pas à mettre le chrono en pause si une discussion prend place pour ne pas pénaliser et frustrer le pilote en place.

Côté sujets, je propose des choses extrêmement basiques, selon les niveaux de l'équipe présente, l'important étant de bien mettre le focus sur le TDD, et non sur une problématique algorithmique ou autre. Ça n'est pas l'objectif d'un dojo « TDD », mais ça pourrait l'être pour un autre dojo. En effet, le coding-dojo est assimilable à une séance de formation, par la pratique, extrêmement instructive. L'objectif d'un dojo doit être unique et clair, et les sujets doivent être en accord avec cet objectif : découverte d'un langage, d'une techno, étude collective de solutions algorithmiques, etc …

Pour bien démarrer la séance, je n'hésite pas allouer le temps nécessaire à l'équipe présente pour échanger sur le sujet pour définir une approche collective. Selon le niveau d'expertise des participants, je les conseille et les guides vers des approches d'architectures « agiles », tout en les laissant maîtres de leurs choix pour qu'ils restent à l'aise pour la mise en pratique ...

En ce qui me concerne, je n'interviens pas en tant que pilote pour permettre un maximum de passage pour les participants. Je joue donc les rôles d'animateur (tours de rôles, timing, …), et de Product Owner (pour les questions sur le sujet et les éventuels choix à faire, en apportant des réponses rapides et claires). Je n'hésite pas non plus à guider les intervenants en suggérant des solutions ou des pratiques, sans s'écarter de l'objectif principal du dojo : mettre en œuvre le TDD.

Mais tout cela ne suffit pas ...

Et oui, ça n'est pas en quelques heures de théorie, démonstrations et mise en pratique qu'on devient maitre du TDD. C'est pour cela que je conclue la journée en donnant quelques conseils aux développeurs : n'attaquer pas forcément dès demain matin, attendez une bonne opportunité, un bout de code qui vous semble favorable au TDD, que vous sentez bien. Mais ça n'ira pas tout seul ...

Alors je propose aux développeurs d'essayer le TDD, de noter les difficultés, les opportunités, etc ... et que nous nous revoyions de temps en temps, régulièrement, pour aborder individuellement ou collectivement ces opportunités, les essais réalisés, les succès, les échecs, etc ...

Pour moi, cette approche globale est la meilleure solution pour accompagner une équipe vers la pratique du TDD, ou du moins vers une approche plus « agile ».

Et vous ?

Quelles sont vos expériences en matière d'apprentissage du TDD, de coding-dojo, etc .... merci pour vos retours et commentaires !

Pour ceux qui peuvent ...

... je serais à l'Agile Tour à Marseille le 13 octobre 2011 pour animer un atelier participatif de 2h sur ce sujet, l'occasion de mieux se rendre compte de quoi il s'agit, et d'échanger sur le sujet !

A bientôt ...