Avec un peu de retard, voici mon ressenti sur la conférence XP Day France, version 2009.

Pour ma troisième fois, je participe à la conférence XP Days.
Cette année, le choix du lieu des organisateurs a été plutôt bien acceuilli, puisque le Châlet de la Porte Jaune, à quelques encablures de Paris, proposait un décor très agréable, en particulier pour le premier jour qui fut très ensoleillé.
Un bémol toutefois sur la disposition des salles, ainsi que sur l'absence de climatisation qui a rendu les présentations de l'après-midi un peu difficiles...
Le programme était très chargé sur ces deux journées.
En effet, pas moins de 6 sessions étaient proposées en parallèle, ce qui nous amenait parfois à des choix difficiles.
La matinée
J'ai donc commencé par une session avec un nom un peu barbare, à savoir "Un projet extrêmement ambitieux et flou, utilisant les technologies les plus récentes, distribuées sur plusieurs continents".
Cette présentation, proposée essentiellement par Isabelle Therrien de Pyxis ainsi que ses collaborateurs de BeTomorrow et Orange services, nous a décrit la vie au quotidien d'un projet dont le développement se déroule sur trois sites (Paris, Bordeaux et Montréal).
L'aspect primordial au sein de ce type de projet est la communication. Sans bonne communication, et donc sans confiance, un projet ne peut avancer correctement. Il était donc essentiel de lever les obstacles liés à la distribution géographique (et horaire) de l'équipe.
L'un des tournants dans ce projet a été la mise en place de rencontres réelles entre les équipes, ce qu'ils ont baptisé les semaines bordelaises.
Cela a permis de créer de véritables liens entre les membres de l'équipe, et donc d'accroitre leurs confiances réciproques.
Les leçons que l'équipe a pu tirer de cette expérience sont les suivantes :
- Le choix des outils de communications est essentiel.
- Il faut faire attention à trop d'optimisme !
- Il est important de donner une grande visibilité sur ce qui est terminé pour la production.
- Il est nécessaire de créer de petites équipes.
- La propreté du code doit être valorisée!
- Il est préférable diviser les équipes selon une architecture modulaire.
- Il faut y aller, ne pas avoir peur de faire des erreurs...
- Il faut attendre d'être prêt avant d'implanter des changements.
- Etre attentifs et créatifs !
Bref, un retour d'expérience plutôt intéressant, qui montre que les contraintes de ce genre de projet ne sont pas insurmontables !
J'ai ensuite assisté à la présentation, par Arnaud Bailly de "Ceintures et bretelles : Tests pour une application web java".
L'idée est de tester une interface web constituée d'un formulaire relativement simple.
Au début, on part de tests réalisés en Scala, exécutés par Maven2. Si les tests fonctionnent correctement, leur temps d'exécution n'est pas très bon. Comptons une bonne demi-minute pour exécuter 3 tests !
Autre problème, ces tests ne sont pas très lisibles et sont trop liés à la structure du code HTML. Ainsi, en changeant le formattage d'un lien, le test ne passait plus, car ce dernier ne retrouvait plus le lien dans l'arbre DOM (la requête XPath devant être modifiée pour que le test réussisse de nouveau).
Arnaud a donc montré différentes évolutions du code des tests, afin de les rendre plus faciles à lire et à écrire, et à les rendre indépendants de la couche de présentation.
Ainsi, nous avons pu voir en oeuvre différents frameworks pour tester les interfaces graphiques, différents concepts (le pattern Page object par exemple) pour améliorer l'écriture et la conception des tests.
Nous sommes également passé par la virtualisation de l'environnement (via HtmlUnit) dans le but que le navigateur (ici Firefox) ne soit plus directement utilisé pour lors de l'exécution des tests.
Au final, si l'on a réussi à rendre les tests beaucoup plus efficaces et beaucoup moins liés au code HTML, il n'en reste pas moins que les avancées furent minimes pour ce qui est du temps d'exécution.
C'est donc à ce moment qu'Arnaud nous a présenté la dernière version de ses tests, qui s'exécutent cette fois-ci directement au niveau client, donc sans avoir besoin du serveur.
Le gain temporel est devenu tout de suite évident, bien que j'ai trouvé que l'on perdait beaucoup des améliorations réalisées précédemment au niveau de la lisibilité du code des tests, puisque ceux-ci sont désormais écrits en Javascript, avec jQuery pour être précis (en utilisant la librairie de tests jQUnit).
Bref, si la présentation contenait des concepts intéressants, j'ai trouvé que le temps imparti - 30 minutes - était bien trop court pour les explorer complètement. D'où mon impression d'être resté sur ma faim...
Pour terminer la matinée, je me suis rendu à la présentation de Virgile Delécolle Chef, la recette.
Virgile nous a parlé de l'agilité non pas en nous parlant technique (TDD, XP, ou ce genre de chose), ni même de méthodologie (exit Scrum...) mais en nous rappelant les évolutions des tâches de management telles que la planification, le suivi ou encore le reporting.
Il en est également venu à aborder des sujets un peu moins communs, liés aux aspects humains. Ainsi, il a parlé du recrutement, ou encore des entretiens annuels, de l'animation des équipes.
La matinée se terminant, nous avons pu profiter d'un excellent repas. A nouveau, bravo pour l'organisation !
L'après-midi
Ma première session de l'après-midi était consacrée au "rôle du Product Owner et conception produit" de Sébastien Sacard.
Sébastien, passé du coté du rôle du Product Owner, désirait nous faire partager ses retours d'expérience sur les relation entre le responsable business, les responsables du design graphique, ou encore l'équipe de développement.
Les slides de cette présentation sont visibles ici.
J'ai également assisté à "TDD : avec ou sans mocks" de mes collègues de Valtech Anthony Dahanne, Yannick Ameur et Stéphane Malbequi.
Grâce une mise en scène assez agréable - malgré quelques petits ratés techniques - nous avons pu voir comment introduire les mocks dans la démarche des tests au sein d'une application.
Yannick joue le développeur, nouvellement arrivé dans l'équipe, et qui ne sait pas correctement mettre en place des tests unitaires. Grâce à l'aide de ses deux collègues, il va découvrir comment réaliser de bons tests unitaires, puis mettre un pied dans le monde du TDD (Test Driven Development).
Par la suite, les choses se compliquant quelque peu, l'équipe va faire appel aux mocks, en utilisant la librairie EasyMock (qui est moins bien que Mockito - ce message étant sponsorisé par David Gageot ).
Une présentation technique, sans trop de jargon pour autant, qui était assez agréable à suivre.
Peut-être que la mise en scène aurait gagné à être un petit plus "punchy"...
Ma seconde partie d'après-midi a commencé par "Mon Javascript est aussi agile", toujours d'Arnaud Bailly.
Sur cette présentation, les avis divergent. Certains l'ont trouvé géniale, d'autres n'ont pas accroché du tout.
Personnellement, je me situerais un peu au milieu.
Arnaud nous a donc parlé énormément de Javascript - on s'en doutait - mais également de TDD et de DSL (Domain Specific Language), afin de nous montrer que l'on peut effectivement écrire plus proprement du code Javascript.
Ainsi, on a pu voir comment écrire un test de validation de formulaire à la façon "old school", puis en utilisant jQuery et enfin, en DSL. Voici un exemple de chacune de ces façons :
Javascript:
function validform(){ | |
var form = document.getElementById('testform'); | |
var nbYearDl = parseInt(document.getElementById('nbYearDL').value(),10); | |
var age = parseInt(document.getElementById('age').value(),10); | |
var nom = document.getElementById('name'); | |
if(!nom.match(/[A-Z-]*/|>) | |
|| age < 18 | |
|| (age - nbYearDL) < 18) | |
return false; | |
}; | |
| |
document.getElementById('testform').onsubmit = "javascript: validform();"; |
Javascript:
$(function() { | |
$('#testform') | |
.submit(function() { | |
var nbYearDl = $("#nbYearDL",this); | |
var age = $("#age",this); | |
var nom = $('#name',this); | |
if(!nom.match(/[A-Z-]*/|>) | |
|| age < 18 | |
|| (age - nbYearDL) < 18) | |
return false; | |
}); | |
}); |
Javascript:
var rules = function(form) { | |
with(form) { | |
age.must(beANumber().and(range().from(18))); | |
name.must(match("^[A-Z-]+$")); | |
nbYearDL.must(beANumber().and(range().from(0).to(function() { | |
return age.value - 18; }))); | |
} | |
} |
Bien que le contenu soit intéressant, j'avoue être parti pour deux raisons.
La première est que j'ai fini par être un peu perdu, cela allait un peu vite (et pourtant, j'"aime" bien le Javascript).
La seconde, c'est que j'étais vraiment curieux d'aller voir la session sur "la parabole du trafic urbain, l'agilité expliquée autrement".
Comme j'adore les embouteillages, j'ai donc finalement ma journée sur "La parabole du trafic urbain - l'Agilité expliquée autrement" de François Bachmann de Sprint iT.
François nous a montré de nombreux exemples de problèmes liés à la circulation automobile (bouchons, signalisation, etc.) et a essayé d'en faire un parallèle avec le monde de l'informatique en général, et de l'agilité en particulier.
François a ainsi comparer les voies de circulation aux ressources humaines du projet, les signalisations aux méthodes de gestion et les véhicules aux livrables.
On a ainsi pu observer que cet ensemble a un impact important sur la vitesse moyenne de circulation, et donc, selon cette analogie, sur le débit de production.
Savions-nous par exemple que la vitesse moyenne d'un automobiliste dans une grande ville, comme Tokyo ou encore Paris n'est que de 15 km/h, soit l'équivalent d'un déplacement à cheval !
François a donc mis en avant les avantages offertes par les méthodes agiles sur ce type de problème, comme l'importance de la communication ou la réactivité.
En continuant son parallèle avec la circulation, il a pris l'exemple du giratoire, qui sans être parfait, incarne certaines valeurs de l'agilité :
- La communication, par l'observation des autres.
- La simplicité, car il n'y a qu'un seul sens de circulation.
- Aucun flux n'est priviligié par rapport à un autre.
- La responsabilité et le respect des conducteurs.
(en ce qui me concerne, j'ai toujours pensé que dans beaucoup de cas, un sens giratoire était préférable à un carrefour traditionnel).
En conclusion, une présentation attrayante, expliquant tout à fait simplement les principes de base de l'agilité.
Une bonne session pour terminer agréablement cette première journée bien chargée !
A suivre...