XP Day France 2009 – journée 1

J’ai participé cette année à XP Day France 2009. Organisé par Sandrine Olivencia, Yannick Ameur, Sébastien Douche et Thibaut Bouchette pendant presqu’un an, avec le support et l’aide de l’association Agile France, cet événement est l’occasion de réunir 250 personnes pendant 2 jours sur le thème de l’Agilité. Tout d’abord côté organisation, un grand bravo. Le cadre était un espace de conférence en plein bois de Vincennes, avec des repas au top, environ 3h par jour de temps libre pour discuter entre chaque conférence, bref l’occasion de lier connaissance, de partager son expérience et d’assister à de nombreuses conférences.

Le nom XP Day tout d’abord, sera peut-être Agile Day l’an prochain. Car à part XP, nous avons parlé Scrum, Kanban, Lean (qui se défend d’être Agile si j’ai bien compris…) ainsi que valeurs humaines, hédonismes, jeux d’entreprises, etc. C’est donc le sujet de l’Agile en général qui était traité pendant ces 2 jours.

Première session : « Soigner sa schizophrénie, projet MOA/MOE voyage autour des exigences fonctionnelles exécutables »
Objectif de cette session: présenter des outils pour rendre moins flou la discussion entre la MOA et la MOE. Dresser un état de l’art dans le domaine des tests fonctionnels.
Herve Lourdin d’OCTO Technologies, Rémy Sanlanville d’Orange Business, Emmanuel Hugonnet de SilverPeas axent la présentation sur la définition de l’environnement entre le métier d’une part et la réalisation d’autre part. MOA pour le métier, les idées et le contexte. Pour la MOE, notre vision est plutot axée sur la réalisation, l’architecture, la définition du done se fait avec les tests unitaires. Comment rejoindre ces 2 hémisphères et améliorer la communciation ?

La clé est tout d’abord la communication. Pour cela, chacun doit s’attacher à définir la notion du « TERMINE » car c’est le contrat et l’engagement qui permettent la réalisation du développement. Emmanuel appuie la démonstration par un graphique montrant que presque 43% des fonctionnalités d’un logiciel ne sont pas utilisées. Nous sommes face à un réel problème. La communication entre le métier et la réalisation s’est axée aujourd’hui sur un contrat, les fameuses spécifications. Or un contrat ne doit pas être là pour remplacer une communication forcément nécessaire.

Le développement par l’acceptation des tests (Acceptance Test Driven Development) est une technique qui permet de faire émerger un discours, un langage commun compris des développeurs et du métier. La création d’un mini DSL, l’écriture par le formalisme « Given… When… Then… » permet par exemple de se centrer sur la réalisation et l’écriture des tests d’acceptation.
Faire de l’ATDD est donc un moyen de bien faire ce que je dois faire, les TDD étant un moyen de bien faire les choses.

Quelques outils cités : JBehave, Fitness Framework ou encore Rspec. Présentation très sympa, j’ai pris ensuite plaisir à écouter Eric, Hervé, Rémy et Emmanuel durant le cocktail échanger leurs points de vues sur les outils, sur le métier du testeur, la perception des équipes d’assurance qualité dans l’entreprise, la phrase d’une dame présente qui lâche mollement une énormité comme « dans Lean les tests unitaires sont du gachi », bref je me suis bien amusé et j’ai compris la démarche, l’intérêt de travailler par la définition de l’acceptance, plutôt que sur la définition du contrat initial.
Voici mon ROTI (Return On Time Invested)

Qualité de la présentation : 4/5
Ce que j’ai appris : 4/5

2) Le Planning Game(détails)
Premier atelier pratique pour moi. Dans une salle de 40 personnes, l’objectif était pour François Wauquier de SFEIR de présenter la cérémonie du Planning Game, de nous faire réaliser un exercice de plannification avec un jeu de rôle, afin de nous faire prendre conscience de l’importance de cette cérémonie (XP ou Scrum). Le public présent dans mon groupe était constitué de gens de la MOA, peu au fait de ces techniques. Après la présentation détaillée de la séance de Planning, nous voilà découper en plusieurs groupes. Objectif pour notre équipe : jouer le rôle d’une agence de voyage qui doit organiser une colonie de vacances. L’un des acteurs joue le rôle du client. Au bout de quelques minutes je me rends compte que personne ne maîtrise franchement le sujet. Quelqu’un tente l’explication d’une User Story, un autre essaye de comprendre à quoi servent ces cartes (Planning Poker). Avec l’aide de Jean-Laurent de Morlhon de Vidal, nous voilà finalement entrain d’expliquer rapidement le jeu du planning poker. A cet instant précis je me dis que j’aurai dû partir. Mais finalement, la magie va opérer (j’en rajoute un peu là). Je pense à cet instant que je perds mon temps. Puis surgissent les questions des 6-8 personnes présentes. Tout d’un coup nous voilà entrain de trouver les mots pour expliquer le fonctionnement du jeu, pourquoi nous utilisons une unité arbitraire, etc. François vient dans notre groupe et recadre très professionnellement l’activité, tout en nous laissant faire notre propre expérimentation. Bref finalement j’ai appris de cette session à expliquer simplement le Planning Poker et les unités de plannification, à des personnes du métier. Intéressant et enrichissant.

Qualité de la présentation : 3/5
Ce que j’ai appris : 2/5

Pause déjeuner
Rupture dans la journée, le moment du repas est l’occasion de lier connaissance. XP Day a une très bonne idée : organiser un repas assis à des tables rondes de 12 personnes. C’est donc le moyen de discuter librement sur la matinée. Je reconnais 2 têtes connues : David Gageot de Tech4Quant et Jean-Laurent de Morlhon de Vidal, tous les deux anciens collaborateurs de Valtech. Quelques instants après m’être assis, je me rends compte que je suis à une table de Valtech, actuels ou anciens salariés. C’est l’occasion de discuter, de faire connaissance avec Xavier Warzee de Microsoft, membre du bureau du French SUG comme moi. Là je vous sens sceptique, vous vous dîtes c’est quoi cette page People ? Ah mais mon bon monsieur sur le Touilleur Express on a aussi nos pages People afin de raconter un peu qui fait quoi, cela fait vendre plus de numéros ! Bref bon repas.

3) Travailler entre Adultes(détail)
Retour et envie d’aller écouter Raphaël Derbier. Tant pis je loupe le show de Régis Médina, mais je suis venu chercher des réponses à mes questions. Raphaël nous propose de nous faire prendre conscience de notre propre comportement dans l’entreprise. Une comparaison ludique entre notre monde d’adulte et le monde des enfants va nous permettre de nous rendre compte de notre propre comportement. Tout d’abord l’idée que l’entreprise est notre mère nourricière : « Ah mais moi je vais pas acheter un livre, c’est à l’entreprise de me l’acheter » ou encore « Moi je veux une formation pour être manager » et aussi le très pratique « On a pas le droit de le faire alors je le fais pas ».
Bref voici ce que je note sur mes feuilles : un enfant n’hésite pas à demander du feedback : « Papa, il est beau mon dessin ? » sans la peur d’être jugé. Un enfant utilise le jeu pour apprendre. Raphaël explique que si des équipes d’architecture prennent le temps avec un jeu de représenter le SI, cela permet de mettre en avant les problèmes techniques très rapidement, sans perdre 3 mois pour se rendre compte que 2 équipes ne se parlent pas… J’évoque le jeu LEGO Serious Game qui est licencié officiellement et vendu pour gérer le conflit et améliorer la communication dans les équipes. D’ailleurs le lendemain j’aurai une discussion avec Isabelle de Pyxis sur l’utilisation des Legos pour faire un Burndown Chart. Elle ne connaissait pas cette idée.
Raphaël explique tout d’abord qu’être adulte s’est « Prendre soin de soi ». Et un enfant est par définition un être qui n’est pas capable de prendre soin de lui, au sens autonomie. Etre adulte c’est donc faire un pas vers l’autonomie. Par des jeux de 5mn il nous force à échanger avec nos voisins. « Quelle est la dernière occasion où tu as pris soin de toi ? ». Intéressant, car cela fait émerger aussi le besoin fondamental d’être en groupe. Il parle d’intelligence collective, de l’importance d’être acteur et d’être présent.
Au niveau des règles il explique aussi que les enfants utilisent les règles comme socle de départ mais s’autorisent la transgression ou la tricherie, dans le but de s’adapter à l’environnement. Si votre question commence par « Est-ce que je peux… » alors la réponse sera oui. Cela nous fait gagner du temps, s’autoriser à ne pas suivre la règle s’est faire travailler son système limbique en utilisant la palette de nos émotions : la peur, le plaisir, la colère, etc.
Difficile de vous résumer l’excellente présentation de Raphaël, qui m’a éclairé sur quelques points, et qui m’a donné de nouveaux outils pour former des équipes à la méthode Scrum. Je constaterai le lendemain à la session « Scrum est-il dangereux » que certains d’entre nous sont de grands enfants, mais je réserve cela pour demain.

ROTI
Qualité de la présentation : 4,5/5
Ce que j’ai appris : 4/5

4) Push Pull réaliser sans itérations (détail)
Yan Picard de Muller nous propose d’expérimenter en petits groupes du Kanban. Lorsque le mode purement itératif ne répond pas à la demande, il y a d’autres alternatives dont j’ai déjà parlé sur le blog le Touilleur Express. La production pilotée par la consommation est un principe passionnant qui nous vient de Lean. Yan organise chaque groupe comme une Agence Web en charge de la réalisation d’un site Internet. Il explique le fonctionnement et nous propose d’expérimenter tout de suite le fonctionnement. J’ai senti qu’il connaissait son sujet, j’ai eu du mal à comprendre par contre ensuite comment nous devions faire pour réaliser le jeu. J’ai repensé à mon enfance, lorsqu’un cousin vous expliquait la règle du Monopoly, et qu’au départ vous aviez du mal à comprendre. Bref nous voilà dans la situation où comme des enfants, nous n’arrivons pas à tout saisir. Finalement, après quelques essais le jeu se met en place sans trop de soucis. Nous déroulons quelques cycles, avec des lancés de dés comme 1D6+4 qui nous permettent de jouer un rôle. Je dois jouer le rôle de l’architecte de l’information, marrant. L’exercice a été difficile car nous étions trop nombreux. A retester en petit groupe je pense, car sinon côté organisation c’était très bien. Je dis cela car lorsque vous verrez le ROTI, je ne souhaite pas blesser Yan, je veux donner mon sentiment très personnel tout en m’autorisant à dire « je n’ai pas trouvé cela top POUR MOI » uniquement sans porter un jugement de valeur

ROTI
Qualité de la présentation : 2,5/5
Ce que j’ai appris : 2/5

5) La parabole du trafic urbain : l’Agilité expliquée autrement(détail)
Tout d’abord si vous lisez le blog souvent, vous savez que je suis un grand fan des paraboles, métaphores et autres images, qui me permettent d’expliquer des concepts avec des mots simples. François Bachmann est Suisse, Coach Agile, et un gars très sympa avec qui j’ai diné ensuite lors du grand diner XP Day. François voici tout d’abord l’article sur la machine à laver du Touilleur Express, histoire que j’ai rejoué lors de la présentation de Scrum au Paris JUG avec Eric « Bob » Mignot.
François nous propose de nous présenter quelques images simples afin d’établir un parallèle entre les méthodes Agiles et le trafic urbain. Son objectif est de nous donner quelques phrases, quelques repères pour expliquer à nos clients et à nos managers les grands principes de l’Agilité.
Tout d’abord observons les différents trafics. Sur une photo nous voyons une rue de New Dehli encombrée de piétons, de voitures, une anarchie apparente pour nous avec notre oeil d’européen. Ensuite en allemagne, à un péage, le flux de voiture qui se divise pour passer la barrière de péage. Au japon, où des indicateurs sur la route donnent les temps de parcours. Bref en quelques slides nous voyons où il veut nous emmener.
Il y a tout d’abord différents types de trafic :
– Habituel
– A valeur ajoutée
– Urgence

Le trafic habituel est constitué par les gens qui vont travailler par exemple. Le risque est faible, nous acceptons du retard et ce processus s’optimise en travaillant sur la disponibilité. Vient ensuite le trafic à valeur ajoutée : par exemple un bus ou un taxi dans sa voie de circulation. C’est la fiabilité qui est alors important, il ne faut pas perdre des clients en cours de route. Alors on met en place des routes spécialisées. Vient enfin les urgences, les pompiers par exemple. Sur l’autoroute, une voie de secours permet de faire passer devant les autres ces véhicules car là le risque vital est là, c’est la vitesse moyenne qu’il faut optimiser.
Personnellement durant son explication je visualise mon SI chez mon client actuel plutôt que les méthodes Agiles.

François nous fait ensuite prendre conscience des méthodes de gestion du trafic. On utilise traditionnellement le mode « Command and Control ». Un feu rouge permet d’arrêter le flux de voitures. Dans les méthodes classiques de développement, la spécification figée est un feu rouge/feu vert qui permet de réguler le flux. Sur un aéroport, une tour de contrôle retire le contrôle aux avions et se charge d’aiguiller les avions, car la sécurité prime avant tout. Intéressant non ? Certains projets ont peut-être besoin d’une tour de contrôle centralisée, d’autres non. C’est ce que je déduis à cet instant de la présentation.

Ce feu rouge justement. Comment se règle les temps d’allumage ? Par statistiques ? par observation des flux ? On est en plein dans la théorie des fluides. Le débit se calcule avec le diamètre du tuyau, mais aussi sa longueur… Intéressant. Je te fais remarquer cher lecteur que je suis en plein pédalage d’idées avec une métaphore à la seconde…

Que se passe-t-il en cas d’accident ? Sur autoroute, une voie de secours permet de s’arrêter en sécurité et de quitter le véhicule en panne, sans pénaliser le trafic derrière nous. Encore une fois j’ai un peu de mal à voir le rapprochement avec Agile. Je pense que dans Scrum, cela s’apparente à la gestion d’un obstacle, identifié pendant le standup meeting du matin. On parque le problème afin de l’adresser sans arrêter la circulation pour autant. Oui il a raison… ça marche et j’ai trouvé tout seul !

François parle encore du feu rouge et des intersections. Il nous dit : regardez ce qu’est qu’un rond-point (un giratoire). C’est un système auto-organisé qui fait appel au courage du conducteur : « je dois prendre la bonne décision ». Le giratoire est un système qui résoud l’encombrement avec des règles simples. C’est le passage d’un mode Command-Control vers un mode autorégulé… plus Agile !
La communication (le clignotant), la gestion de l’engagement (j’y vais à fond ou pas), l’absence de préselection des flux (priorité à ceux qui sont entrain de tourner) le respect de l’autre, la transparence… Oui tout y est ou presque.

Cette séance sera l’occasion d’ajouter à mon panier de connaissance la parabole du trafic routier. Cependant j’ai plus de faciliter à rapprocher cela de mes besoins en architecture, que sur les méthodes Agile. Je préfère l’analogie avec le monde du Sport pour expliquer Scrum rapidement. Mais la présentation était très intéressante

ROTI
Qualité de la présentation : 4,5/5
Ce que j’ai appris : 3,5/5

Cocktail et diner, le moment Off
J’avais décidé de rester diner, ce qui m’a donné l’occasion de présenter Scrum à Cédric Vidal de ProxiAD avec justement l’aide de François Bachmann de Sprint IT. Les moments forts d’XP Day sont donc les conférences mais aussi les moments off qui permettent de discuter avec chacun. On retrouve les habitués des soirées Java et des BarCamps, mais j’ai noté une bonne représentation des personnes du métier, de la MOA.
Je me demande si un effet bénéfique de Scrum n’est pas d’apporter aux gens du métier des réponses plus pragmatiques qu’une autre méthode. Est-ce que regarder le produit et le placer au centre n’est pas plus simple pour eux que de parler de techniques d’ingénierie logicielle ? Qui a discuté avec des personnes de la MOA durant les XP Day ?

Vous saurez tout en revenant lire plus tard la suite…

Articles similaires:

XP Day France 2009 – jour 2 XP Day France 2009 – jour 2, Dans la peau du Challenger et Business Value Game Devoxx 2009 : résumé de la première journée de Conférence Devoxx 2009 résumé de la journée de Jeudi