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

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

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.

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.

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.

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.