vendredi 21 octobre 2011

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 !

lundi 3 octobre 2011

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 ...