Compte rendu de l'XP Day Suisse (Genève) 2009

| Pierre Caboche | Jean-Philippe Vigniel |

Le 30 mars 2009 s'est tenue à Genève la conférence XP-Day sur l'eXtreme Programming et les méthodes agiles. Developpez.com y était. En voici le compte-rendu.

Commentez

- Titre : Compte rendu de l'XP Day Suisse (Genève) 2009

- Auteurs : Pierre Caboche, Jean-Philippe Vigniel

- Parution : 20 avril 2009

- Mise à jour : 30 avril 2020

- Licence :

Sommaire

- Présentation

- Sessions théoriques

- Découvrir eXtreme Programming

- Les cinq premiers pas pour devenir agile

- TDD et Erlang

- Retours d'expérience

- XP à dimension industrielle

- Mettre en symbiose des outils XP et des outils « traditionnels »

- Transatel : Mise en œuvre des pratiques agiles sur la maintenance évolutive d'une application Legacy

- Retour d'expérience sur le Pair Programming

- Pratiques d'ingénierie incrémentale

- Session philosophique

- Programmation hédoniste

- Remerciements

- Liens

Présentation

La conférence XP-Day porte sur l'eXtreme Programming et les méthodes agiles. Il existe plusieurs éditions des XP-Day : en France, Belgique, Suisse, etc.

L'édition destinée à la Suisse romande s'est déroulée le 30 mars 2009 à Genève, dans le Geneva Business Center. Cette édition était entièrement francophone (contrairement à d'autres éditions des XP-Day).

Organisation

La conférence est composée de 12 sessions, qui se déroulent en parallèle sur 2 salles.

La difficulté des sessions est indiquée par un système de ceintures, comme au judo:

- ceinture blanche : débutant ;

- ceinture jaune : intermédiaire ;

- ceinture noire : avancé.

La salle 1 accueillait les sessions notées « ceinture blanche », tandis que la salle 2 accueillait les sessions d'un niveau plus avancé.

Nous étions 2 pour couvrir la plupart des sessions.

Prix

L'inscription coûte entre 80.- et 100.- CHF, suivant la date d'inscription (80.- CHF si inscrit 6 semaines à l'avance, 100.- CHF ensuite).

Geneva Business Center

Geneva Business Center
Avenue des Morgines, 12
1215 Petit Lancy
Suisse

Accès

L'accès au Geneva Business Center par les transports en commun est très simple, car il se situe sur la ligne de bus numéro 23, arrêt « Bossons ».

En revanche, l'accès en voiture n'est pas des plus aisés. La circulation dans Genève est extrêmement difficile, et trouver une place de parking l'est encore plus. Par ailleurs, le parking indiqué comme gratuit sur le site du XP-Day ne l'était malheureusement pas.

Les goodies

À son arrivée, le visiteur se voit remettre un superbe sac en toile de jute griffé « XP day, pour un développement durable ».

On apprécie le parallèle qui est fait entre « développement durable », respect de l'environnement, utilisation de matériaux renouvelables et « développement logiciel » durable et renouvelable.

Les sessions

Pour ce compte-rendu, nous avons décidé de présenter les sessions non pas dans l'ordre chronologique, mais en les regroupant par thèmes :

- sessions théoriques ;

- retours d'expériences ;

- session philosophique.

Sessions théoriques

Ces sessions ont pour but soit de faire découvrir les méthodes agiles en général, soit de faire découvrir des aspects très particuliers des méthodes agiles.

Découvrir eXtreme Programming

Cette séance constitue une très bonne présentation d'XP. Destinée principalement aux développeurs n'ayant pas ou peu d'expérience d'XP, cette séance fut accessible, claire et très bien illustrée par de nombreux points et des métaphores.

En tout début de séance, l'intervenant Didier Besset nous explique que le but d'XP est de maîtriser les coûts, en particulier les coûts liés aux changements. En effet, plus des changements doivent survenir tard dans le développement, plus ces changements coûtent cher ; la courbe du coût étant exponentielle :

Pour maîtriser les coûts liés aux changements, XP propose :

- le développement itératif ;

- une planification adaptable et non rigide ;

- une architecture évolutive et non contraignante ;

- la multiplication des tests.

Puis il nous explique certains fondamentaux d'XP.

XP c'est :

- faire preuve de bon sens ;

- faire les choses simplement ;

- privilégier la communication ;

- intéragir de près avec le client ;

- faire tout cela à 100 %.

Un principe fondamental, c'est de respecter la place du client et des développeurs ainsi que les connaissances de chacun. Ainsi on suppose que :

- le client connaît son métier ;

- les développeurs connaissent leurs outils ;

- le client définit les priorités ;

- les développeurs définissent les détails.

Ainsi le client doit / les développeurs ne doivent pas / le client a le dernier mot pour :

- décider du workflow ;

- définir les champs, menus, boutons ;

- choisir une charte graphique.

Les développeurs doivent / le client ne doit pas / les développeurs ont le dernier mot pour :

- décider d'une architecture ;

- choisir les outils (langage, BDD) ;

- définir le modèle.

Le client définit les priorités. Si une date de livraison semble en danger, risquant d'être dépassée, les développeurs doivent signaler le problème au client qui décidera des fonctionnalités à retirer afin de conserver la date de livraison.

Après une bonne livraison, c'est le client qui décide de la mise en service.

Après ces explications sur le rôle de XP, la place du client et des développeurs, Didier Besset explique en détail quelques grands principes de XP:

Test Driven Design

Les tests unitaires sont écrits par les développeurs. Il faut écrire les tests unitaires avant de coder. Il faut tester tout ce qui peut « foirer » ainsi que le comportement aux valeurs limites.

Les tests d'acceptation sont écrits par le client. Ils permettent de vérifier le respect du cahier des charges (et de savoir quoi tester). Ils sont un bon départ pour la documentation.

Intégration Continue

Chaque changement est immédiatement inclus dans un système déployé. Le déploiement fait partie du développement.

Un système utilisable existe en permanence :

- les développeurs peuvent essayer le système ;

- le client aussi.

Livraison fréquente

- elle est la conséquence directe de l'intégration continue ;

- le client a le système en main le plus tôt possible ;

- le client peut réagir ;

- le choc des nouvelles fonctionnalités est atténué.

Simplicité

Écrire du code lisible :

- les autres doivent pouvoir le lire ;

- vous aussi, après plusieurs mois.

Les intentions doivent être claires :

- utiliser des standards ;

- éviter les abréviations ;

- éviter les commentaires.

Le dernier point (éviter les commentaires) peut paraître bizarre, mais pour l'intervenant, le code doit se suffire à lui-même. S'il y a des commentaires, c'est que le code n'est pas lisible. J'aurais tendance à dire que les commentaires doivent exprimer ce que le code ne dit pas (fonctionnement général, invariant, propriétés de certaines variables…), mais Didier Besset n'est pas d'accord sur ce point.

En conclusion, Didier Besset commente cette citation de Peter Merel: « Make it run, make it run well, make it run fast. In that order. »:

- « Make it run » : passer les tests ;

- « Make it run well » : refactoriser, rendre le code lisible ;

- « Make it run fast » : optimiser.

Et surtout : ne rien dupliquer !

Télécharger les slides de la présentation

Les cinq premiers pas pour devenir agile

La séance est présentée par Portia Tung et Pascal Van Cauvenberghe.

Le duo fonctionne bien et présente sous forme ludique les petits outils/jeux permettant de qualifier/améliorer son agilité. L'objectif de la présentation va au-delà des 5 premiers pas pour devenir agile et explore plutôt comment amener une équipe à détecter des problèmes via l'utilisation de jeux.

La partie la plus intéressante vient d'un jeu illustrant la théorie des contraintes. Ce jeu montre comment une personne surchargée peut bloquer très vite une équipe.

Bien sûr, ce jeu est construit pour mettre en évidence ce qu'il veut montrer. L'équipe doit colorier un ensemble de dessins, un des membres se retrouve avec trop de travail pendant que le reste de l'équipe regarde. L'effet 'physique' est saisissant.

Comme tous les jeux très simples, il construit une situation caricaturale. L'important est donc le discours qu'il y a autour. Évidemment tout le monde se doute bien que si une personne se charge de tout, d'autres attendent. Ce qui est plus subtil c'est de se dire que si une personne est surchargée et stressée dans l'équipe, la soulager permet non seulement de lui faciliter la vie, mais a de bonnes chances d'améliorer le processus global.

Une personne de l'assistance demande si le concept ne doit pas être poussé jusqu'au bout en 'laissant partir' un leader technique qui prend trop de place dans l'équipe et laisser l'équipe se réorganiser d'elle-même. La conclusion de l'assistance est partagée entre le concept d'équipe homogène et d'équipe 'moyenne'.

Lors d'une pause, j'ai l'occasion de discuter plus en avant avec Pascal. Il m'explique comment il utilise ces jeux pour faire prendre conscience aux équipes des points d'amélioration possibles. Ainsi un des points clefs de son travail de consultant consiste à faire se rencontrer tous les intervenants d'un processus. La tentation pour chaque équipe étant d'optimiser sa partie et non la chaîne globale. Les jeux prennent alors beaucoup d'intérêt pour aller au-delà des frottements inévitables entre services.

Télécharger les slides de la présentation

Télécharger les résultats de la rétrospective

TDD et Erlang

Erlang est un langage de programmation conçu à l'origine par Ericsson avant d'être rendu public. Erlang est à la fois un langage de programmation fonctionnelle et un langage de programmation concurrente.

Cette session, présentée par Dominic Williams et Nicolas Charpentier, a permis de montrer l'application de la TDD à chacun de ces paradigmes de programmation.

Dominic Williams a d'abord montré en quoi la programmation fonctionnelle diffère beaucoup de la programmation procédurale ou orientée-objet, y compris en ce qui concerne les tests. En programmation orientée-objet, par exemple, avant de pouvoir tester il est nécessaire d'initialiser les objets et d'effectuer une série d'opérations afin d'amener les objets dans l'état que l'on cherche à tester. En programmation fonctionnelle, l'écriture des tests est souvent plus simple, plus lisible (une qualité primordiale en TDD) et semble finalement plus naturelle.

Pour illustrer cela, Dominic Williams a comparé des tests unitaires portant sur des listes : d'abord dans un langage orienté-objet, puis en Erlang. Les tests unitaires en Erlang se sont montrés plus concis (une ligne) et plus lisibles, car l'initialisation des listes était beaucoup plus simple.

Les démonstrations des tests en Erlang ont été faites en direct, sous Emacs, à la mode « ping-pong » (Dominic écrit les tests, Nicolas modifie le programme en conséquence) :

En haut à gauche : les tests.
En haut à droite : le programme à tester.
En bas : le résultat de la compilation/test.

Une autre démonstration intéressante a permis de montrer comment tester des fonctions d'ordre supérieur.

En programmation fonctionnelle, l'abstraction s'obtient par l'utilisation de fonctions d'ordre supérieur (c'est-à-dire des fonctions acceptant d'autres fonctions comme paramètre). En Programmation orientée-objet, l'abstraction se fait par héritage, ce qui pose certains problèmes : un même comportement doit être testé dans les sous-classes, parfois il est même nécessaire de définir des sous-classes dans le seul but de tester le comportement de la super-classe.

Toutes ces démonstrations ont permis de montrer que l'écriture de tests unitaires était simple de par la concision et l'expressivité du langage. Mieux encore : l'approche TDD permet de bien coder en programmation fonctionnelle. Par exemple, la TDD permet de tout de suite tester (et donc d'implémenter) les cas d'arrêt d'une fonction récursive, ce qui tend à réduire le risque de récursion infinie.

Le deuxième point important de cette présentation concernait la TDD en programmation concurrente et l'intérêt d'Erlang dans ce domaine.

De plus en plus d'applications introduisent des problématiques liées à la concurrence : threads, parallélisation, applications distribuées, ressources partagées…). Il est possible de faire de la programmation concurrente dans de nombreux langages (par exemple en introduisant des threads), le problème est que l'ordre d'exécution est alors non déterministe et il devient extrêmement difficile d'écrire des tests pour des programmes concurrents.

En Erlang, la notion de programmation concurrente se fait par l'introduction d'« acteurs » indépendants qui communiquent entre eux par l'échange de messages (Erlang gère même les cas de « timeout »). L'exécution devient alors parfaitement déterministe, le programme est simple, facile à comprendre, et il devient facile d'écrire des tests.

Cette présentation fut extrêmement intéressante. Elle a permis de montrer l'intérêt de la TDD en programmation fonctionnelle ainsi que les avantages de Erlang pour résoudre les problèmes de programmation concurrente et faciliter les tests pour ce type de programmes. Cette présentation a également permis de montrer que la programmation fonctionnelle pouvait être utilisée dans certains projets industriels.

Pour bien comprendre cette session, il est utile d'avoir quelques connaissances des bases de la programmation fonctionnelle, pas forcément en Erlang (pour ma part je ne connaissais pas du tout Erlang, j'étais plus habitué à Ocaml).

Toute la difficulté pour les orateurs fut de présenter, en 60 minutes seulement, les différents concepts liés à la programmation fonctionnelle devant un public peu habitué à ce genre de programmation (comme en témoignent les questions posées lors de la séance), et cela avant même de rentrer dans le cœur du sujet : les tests.

Afin que la session reste accessible au plus grand nombre, les exemples choisis restent simples (l'exemple sur les listes est un cas d'école). De fait, les habitués de la programmation impérative s'interrogent sur l'intérêt de la programmation fonctionnelle alors que les habitués de la programmation fonctionnelle (en minorité dans la salle) auraient été friands de cas moins triviaux (ce qui aurait rendu, de fait, la session beaucoup moins accessible).

Télécharger les slides de la présentation

Retours d'expérience

Voici les sessions concernant les retours d'expériences sur XP et les méthodes agiles.

Ces sessions sont intéressantes, car elles montrent les applications des méthodes agiles sur des projets réels (parfois d'envergure) et font le point sur les erreurs à éviter.

XP à dimension industrielle

Une présentation intéressante dans laquelle les intervenants (Pierre-Emmanuel Dautreppe et Norman Deschauwer) font le bilan de l'utilisation de XP sur un gros projet.

Le contexte du projet est le suivant :

Thales Belgique a été mandaté par une grande banque sociale belge. Le projet était initialement d'un an puis a été renouvelé d'année en année pour finalement s'étendre sur 6 ans. Au départ, le projet regroupait 3 à 4 personnes pour atteindre 15 personnes finalement.

Pour ce projet, c'est l'entreprise client qui a imposé l'utilisation de XP, ce qui fut un gros avantage pour l'équipe en charge du développement. En effet, dans la plupart des projets faisant intervenir XP, l'initiative d'utiliser XP revient souvent à l'équipe informatique qui doit alors convaincre le client du bien-fondé de XP.

En revanche, l'équipe informatique n'avait pas l'habitude d'utiliser XP et n'avait pas de bonnes pratiques à la base. Ce projet fut donc l'occasion de reparcourir l'ensemble des pratiques qu'offre XP, ainsi que ses valeurs :

- communication ;

- simplicité ;

- réactivité ;

- feedback ;

- courage (être prêt à repartir de zéro) ;

- respect (team first).

Il fut donc décidé d'introduire les pratiques de XP au fur et à mesure, ce qui fut une erreur, d'après les intervenants. Selon eux, il eût mieux valu introduire l'ensemble des pratiques dès le départ.

Intégration continue

L'intégration continue a été mise en place dès le début du projet.

Un serveur dédié compile et lance des tests et envoie des mails lorsque quelque chose ne fonctionne pas. Cela permet d'évaluer rapidement les risques et de communiquer les résultats des tests.

Planning game

Une technique arrivée trop tard dans l'entreprise.

Cette technique permet aux développeurs d'avoir une vision plus globale du projet. Elle permet aux analystes de présenter le besoin fonctionnel du client, sous forme de « user stories ». Ainsi il devient plus facile de définir ce qu'est une tâche.

Communication

Échanger le savoir

Tout le savoir de l'entreprise est centralisé au sein du service informatique.

L'une des dérives possibles est alors de se sentir meilleur que l'utilisateur et de vouloir dicter son comportement.

Utiliser des métaphores

Les métaphores facilitent la communication. De plus, elles permettent de trouver un langage commun entre les informaticiens et le client. Ainsi les données métiers se retrouvent au niveau du code.

Pour le développement, on parle fonctionnalités plutôt que tâche. Travailler sur une tâche est sans intérêt, travailler sur une fonctionnalité l'est beaucoup plus.

TDD

Une grosse erreur fut de mélanger tests unitaires et tests de recettes. Une autre erreur fut d'écrire du code qui n'était pas couvert par des tests.

Le gros problème, c'est que l'on n'apprend pas à faire des tests à l'école. Écrire un bon test est un exercice compliqué et il est nécessaire de :

- sensibiliser les développeurs à l'écriture de tests ;

- écrire les tests avant de coder ;

- écrire des tests lisibles plusieurs mois, voire plusieurs années plus tard.

Livraison rapide

Intérêt :

- meilleur R.O.I. ;

- un feedback rapide ;

- plus grande réactivité.

Les itérations durent deux semaines, une livraison a lieu tous les deux mois.

Conception simple

La conception doit être simple, mais simple ne veut pas dire simpliste.

Refactoring

Le refactoring consiste à prendre du recul et à regarder l'application dans son ensemble, puis à passer un grand coup de balai dans l'implémentation.

Le rôle de l'Architecte Agile est de mettre le doigt sur les zones à risque (en terme de performance, de design…) et de procéder à la revue de code.

Avantage : Il connaît l'intégralité du code
Inconvénient : Le fait d'avoir un Architecte Agile peut déresponsabiliser l'équipe

Télécharger les slides de la présentation

Mettre en symbiose des outils XP et des outils « traditionnels »

Par Pierre-Emmanuel Dautreppe et Norman Deschauwer.

Il s'agit d'un retour d'expérience sur l'utilisation des outils (informatique ou de management) par Thales.

Le cadre du projet examiné est un forfait pour lequel le client a demandé un développement Agile et du développement en binôme. Sachant que ni le client ni l'équipe n'avaient d'expérience préalable d'une quelconque méthode Agile, c'est l'adaptation des équipes et des outils que propose cette présentation.

La présentation est bien menée et le binôme (un grand classique de cet XP day que la présentation en binôme) fonctionne bien. Les doutes, le recul par rapport à la méthode, les problèmes rencontrés sont bien mis en avant avec le message 'ce n'est pas magique'.

Les intervenants ont présenté leur projet découpé en quatre phases :

- Genèse ;

- Recadrage ;

- Crise ;

- Maturité.

Pour résumer les points marquants de cette expérience sont les suivants :

Après pas mal d'ajustement, la doc a été limitée au maximum, un wiki sert de référentiel pour la 'vraie' doc : convention, doc utilisateur, etc.

Le stand-up meeting a été long à se mettre en place, actuellement ils séparent les points à vocation technique et ceux à vocation fonctionnelle.

Le suivi des tâches et des consommations se fait dans JIRA à des fins de facturation.

L'estimation a été longtemps un problème, ils ont expérimenté plusieurs façons de faire avant de trouver l'optimum. Actuellement, ils utilisent la méthode suivante :

Sur un mur divisé en durée (de quelques heures à quelques jours), l'équipe doit positionner toutes les tâches envisagées pour l'itération courante. Dans une première étape, chaque membre de l'équipe prend une partie des tâches et les pose à l'endroit qu'il estime réaliste. Ensuite la discussion s'engage sur la pertinence de ces choix. La réunion peut être longue, mais toute l'équipe participe et l'estimation est acceptée d'un commun accord.

À propos de l'estimation, la gestion par point plutôt que par unité de temps a été un problème, du coup ils sont revenus à une estimation par unité de temps.

Détail amusant (si j'ai bien suivi), le point sert à présenter l'estimation au client évitant ainsi d'empiéter sur le discours commercial.

Dernier détail sur le sujet, ils estiment avoir un rendement de 4h30 de codage effectif par jour.

Le ROTI (Return on Time Investment) qui consiste à faire évaluer une réunion par les participants a été utilisé à outrance avant de revenir en arrière et de l'utiliser avec parcimonie. L'analyse étant que toutes les réunions n'ont pas besoin d'être optimisées en permanence.

Journée extrême : une journée (par itération, je crois) où les binômes tournent très souvent. Elle permet de favoriser la communication et le partage de compétence.

Le DOJO (qui consiste à faire tourner un binôme sur une machine sous le regard du reste de l'équipe). Bon outil, mais potentiellement mal pris. Les problèmes de susceptibilité peuvent être délicats à gérer.

Kanban (la méthode de Toyota permettant de gérer les flux dans les process de prod) : dans leur cas c'est l'ajout d'états (à spécifier, spécifié, à coder, etc.) à leur tableau de tâches qui a amélioré l'organisation.

Cette liste n'est pas exhaustive, bien d'autres points ont été abordés durant cette session fort intéressante.

Télécharger les slides de la présentation

Transatel : Mise en œuvre des pratiques agiles sur la maintenance évolutive d'une application Legacy

Présentée par Eric Dejambe et Gabriel Le Van, cette session très intéressante est là aussi un retour d'expérience portant sur l'intégration de méthodes Agiles dans une petite équipe travaillant sur un legacy (en Java tout de même).

La présentation de l'état initial du projet présente son lot de dette technique, d'équipe démotivée, de mise en production de version hautement boguées etc. L'estimation du temps passé montrait que l'équipe passait 80 % de son temps sur la correction de défauts et malgré tout continuait à accepter des évolutions fonctionnelles. Bien sûr, le mode 'héroïque' du développement se heurtait très vite au mécontentement des utilisateurs, ce qui est assez désagréable à vivre.

Évidemment, le message attendu est que d'un coup de baguette magique agile l'application devienne géniale et l'équipe super motivée. La réalité est bien sûr plus complexe et c'est tout l'intérêt de l'expérience présentée ici.

Le premier élément est de savoir s'il faut tout réécrire ou faire évoluer l'application. Les intervenants présentent une analogie bien amenée, celle du jardin. La friche pour la situation actuelle, Versailles pour une potentielle réécriture complète, et un jardin retravaillé pour l'évolution pas à pas.

Le choix mis en avant est bien sûr l'évolution pas à pas. J'apprends au passage que l'anti pattern consistant à vouloir tout refaire a joliment été appelé par la société Octo « l'étoile noire » : ce pattern consiste à essayer de construire l'arme absolue nonobstant le fait qu'elle a une fâcheuse tendance à exploser avant d'être opérationnelle.

La partie la plus intéressante, une fois ce choix justifié, est l'ordre et la manière d'introduire peu à peu de la solidité dans l'application et les processus. L'idée centrale est de rembourser la dette technique peu à peu au grès des corrections de bugs. L'approche retenue pour introduire les éléments d'agilité est aussi celle des petits pas.

Si je suis convaincu que l'approche technique par petit pas est le bon choix, je me demande si l'introduction des concepts SCRUM au fil de l'eau est la meilleure option. Maintenant il faut voir que Gabriel Le Van venait d'être engagé et ce qu'il explique c'est que ce n'est pas forcement facile de tout bouleverser en arrivant de l'extérieur, je veux bien le croire. L'acceptation par l'équipe reste la clef de la réussite du projet

Les premières décisions sont essentiellement techniques, puis peu à peu les décisions organisationnelles sont introduites.

Voici (en gros) l'ordre d'introduction des changements :

- « Mavenisation » du projet ;

- Mise en place d'intégration continue via Hudson, avec une remarque intéressante sur l'effet marketing de l'outil ;

- Mise en place des tests sur les parties modifiées ;

- Incitation des développeurs à travailler sur d'autres parties de l'application, et travail en binôme ;

- Révision des relations avec l'architecte fonctionnel, passage d'un document de référence à des rencontres de visu ;

- Introduction des structures de temps (time boxing) et des itérations ;

- Stand up meeting.

En termes de délai, il aura fallu un mois et demi pour revenir sur une application avec une qualité correcte et commencer à détacher du temps pour de potentielles évolutions. Étant donné que la société avait prévu de ne rien faire de nouveau pendant quasiment l'année c'est un très bon résultat.

Après six mois, l'équipe s'est remotivée (malgré des départs) et a retrouvé la confiance de ses commanditaires. De nouvelles évolutions sont embarquées et le travail de consolidation continue.

La suite de l'histoire, c'est normalement l'extension des pratiques aux autres équipes de développement de l'entreprise, et pour l'équipe en place l'introduction des tests fonctionnels.

Finalement, cette présentation était très complète et plutôt bien menée. L'intérêt principal était de voir le chemin qui a permis à une personne extérieure (mais embauchée) de transformer peu à peu l'équipe et l'application pour revenir à un état maîtrisé.

Le mot de la fin, c'est la petite remarque sur le fait qu'ils n'ont pas réussi à prouver formellement au management les gains qu'apportait la méthode. Je suppose que, vus de l'extérieur, les concepts mis en place ne font que faire revenir les développements à un état normal où les éléments demandés fonctionnent correctement. C'est un peu dur pour nous, mais ça veut dire qu'il reste de la pédagogie à faire.

Retour d'expérience sur le Pair Programming

Cette session est présentée par Jérôme Layat d'Hortis S.A., Java Senior, coach en méthodes agiles, cofondateur d'Agile-Swiss.

Jérôme revient sur son expérience en matière de Pair Programming. La session est divisée en 2 parties, correspondant à deux projets :

- projet chez un courtier en ligne ;

- programme de contrôle aérien.

Jérôme parle des difficultés rencontrées par rapport au Pair Programming.

La première des difficultés consiste à faire accepter l'idée du Pair Programming au sein d'un service informatique. Ensuite viennent les difficultés à travailler en binômes. Cette session fourmille d'exemples et d'anecdotes :

- sur les tensions qui peuvent apparaître au sein d'un binôme ;

- sur le problème des binômes qui veulent travailler en musique, un casque sur les oreilles (impossible en pair programming) ;

- sur la difficulté d'appliquer le Pair Programming lorsque l'équipe est en nombre impair.

Jérôme montre comment ces difficultés ont été surmontées et comment, finalement, ses autres collègues (qui n'appliquaient pas le Pair Programming) avaient envie de s'y mettre, car les binômes de Pair Programmeurs avaient l'air de bien s'entendre, de prendre plaisir à leur travail, tout en étant extrêmement productifs.

Il apparaît alors un schéma intéressant pour l'adoption du pair programming : les collègues se trouvant immédiatement à côté de Pair Programmeurs auront souvent envie de les copier. Le Pair Progrmming se propage alors comme un virus.

Corollaire : pour faire adopter plus rapidement le Pair Programming au sein d'un service, mieux vaut placer les Pair Programmeurs au centre de la pièce.

Cette présentation était très intéressante et très vivante, notamment grâce aux nombreuses anecdotes richement et savamment illustrées.

Consulter les slides de la présentation

Pratiques d'ingénierie incrémentale

Pas grand-chose à dire à propos de cette session.

Au niveau de la présentation, c'est pour le moins sobre : un écran blanc avec une pousse de bambou et les informations d'usages (titre, nom de l'intervenant…) et c'est tout ! Une seule page !

Une présentation pareille, ça n'a pas dû prendre trop de temps à préparer…

En effet, sous un titre pompeux et trompeur il s'agit en fait d'une session de questions-réponses totalement improvisée. C'est l'auberge espagnole : on n'y trouve que ce qu'on y amène !

L'exercice est assez périlleux en soi, mais pour ne rien arranger l'intervenant ne va pas au bout des choses et esquive certaines questions.

La session était annoncée comme étant « tous publics ». D'une part, je vois mal comment un débutant pourrait ne pas s'ennuyer devant cette présentation, ne sachant pas de quoi il est question. D'autre part je doute que les plus expérimentés puissent se satisfaire de réponses aussi évasives.

Bref, une présentation aussi décousue que décevante.

Télécharger les slides de la présentation

Session philosophique

Une présentation très originale se distingue clairement des autres de par le fait qu'elle présente la programmation non pas d'un point de vue technique, mais d'un point de vue philosophique.

Programmation hédoniste

Une session très intéressante dans laquelle Dominic Williams met en parallèle les méthodes agiles et certaines notions philosophiques :

- le jardin d'Épicure ;

- le plaisir ;

- le matérialisme ;

- Dieu.

Dominic Williams, alias Neo

Le jardin d'Épicure

Épicure est le père de l'Épicurisme, une école philosophique fondée à Athènes en 306 av. J.-C. et établie dans un jardin ouvert à tous : aux hommes comme aux femmes, quel que soit leur niveau social.

Dans cette présentation, XP et les méthodes agiles sont assimilés au jardin d'Épicure, car accessibles à tous, matérialistes, et régis par des règles simples.

À l'inverse du jardin d'Épicure, l'Académie de Platon se voulait beaucoup plus élitiste et régie par des règles strictes. Seules 2 femmes y étaient présentes. Rapidement, le jardin d'Épicure a éclipsé l'Académie de Platon.

Le plaisir

Le but de l'Épicurisme est la recherche du bonheur, du plaisir constant. Il ne s'agit cependant pas du plaisir charnel, mais de l'absence de troubles et de déplaisir.

Cette recherche d'absence de déplaisir est très présente dans XP et les méthodes agiles : par la mise en place de tests, le développeur essaye de s'affranchir du déplaisir lié à la correction de bugs.

Paradoxalement, la recherche du plaisir est un tabou dans le monde du travail.

Le matérialisme

Pour Démocrite, la connaissance par les sens est obscure, seule la connaissance dérivée de la raison est véritable et légitime.

Pour Platon, nos sens sont trompeurs et il existe une réalité supérieure. Ceci est illustré dans l'allégorie de la caverne :

On enferme des prisonniers dans une caverne d'où ils ne peuvent percevoir que des ombres. Leur perception de la réalité est alors faussée. Si on relâche un prisonnier (ou s'il s'échappe), il pourra voir le monde tel qu'il est. Ne pouvant supporter la lumière, il désirera retourner dans la caverne. De là se pose un problème : lorsqu'il retournera dans la caverne et racontera à ses semblables ce qui lui est arrivé, les prisonniers refuseront de le croire et pourraient vouloir tuer ce calomniateur.

Une représentation moderne de l'allégorie de la caverne se retrouve dans le film Matrix avec l'opposition entre monde réel et monde virtuel, pilule bleue et pilule rouge, Neo voulant libérer les prisonniers de la matrice alors que ceux-ci feront tout pour défendre le système.

Il en va de même pour les méthodes agiles : pour de nombreux analystes, les diagrammes UML représentent une réalité plus forte que le code. Un modèle peut être « parfait », mais le code qu'il génère est « sale ».

Pour le développeur agile, c'est l'inverse: la réalité, c'est le code, pas le modèle.

Dieu

Dieu représente l'autorité, le créateur, l'Architecte de l'Univers.

Une représentation moderne se trouve à nouveau dans la trilogie Matrix lorsque Neo rencontre l'Architecte (l'architecte logiciel, créateur de la matrice, du monde virtuel connu des habitants de la matrice, Dieu).

Dans le domaine du logiciel, l'Architecte représente l'autorité suprême et est mis sur un piédestal.

XP tend à rejeter l'Architecte. « Dieu est mort », disait Nietzsche, l'autorité n'est plus et par conséquent il faut être plus autonome. C'est ce que proposent les méthodes agiles : être plus autonome, plus responsable, s'élever et apporter plus de créativité aux projets informatiques.

Remerciements

Nous tenons à remercier l'ensemble des organisateurs de cette édition XP-day Genève 2009, qui ont donné énormément de leur temps et de leur énergie afin que cet événement soit rendu possible.

Ces efforts se sont révélés payants, les présentations étant en général de très bonne qualité et en français.

Liens

- Le site XP-day Suisse

- Le programme avec les slides en téléchargement

- Le forum d'entraide dédié aux Méthodes Agiles

- Les meilleurs cours sur les Méthodes Agiles, sur Developpez.com

- Agile Alliance : la référence de la communauté agile internationale

N'hésitez pas à réagir sur ce reportage : Commentez