Archives pour juin, 2009

Voici le compte-rendu de ma deuxième journée.

La matinée

La keynote « La Longue Défaite : un retour sur l’histoire des méthodes de gestion de projet informatique » de Godefroy Beauvallet a donc ouvert le bal de la deuxième journée des XPDays France 2009.
Cette keynote nous a donc retracé, en 3/4 d’heure, l’histoire de la gestion des projets informatiques.
En 1994, on estimait que sur les projets informatiques, nous avions :

• 31% de projets annulés
• 53% des projets qui coûtaient au mieux deux fois plus cher que prévu initialement
• 9% des projets finissant dans les temps et dans le budget (chiffre pour les grandes compagnies)
• 16% des projets finissant dans les temps et dans le budget (chiffre pour les petites compagnies)

Si la même estimation pour l’année 2002 montre une certaine amélioration, cela n’est pas forcément dû à de meilleurs développements, mais plutôt au fait que nombre de projets sont de petits projets, donc moins susceptibles d’échouer…
Alors pourquoi une telle situation ?
C’est donc en étudiant l’histoire de la gestion des projets informatiques que nous pouvons trouver quelques réponses…
Godefroy nous a donc beaucoup parlé des modèles en cascade, de waterfall, de modèle en spirale, en insistant bien sûr sur les défauts de ces techniques.

Il nous a également conté l’histoire passionnante du projet Polaris dont le développement (capital, en temps de Guerre Froide) s’était basé sur le PERT (Program Evaluation Review Technique).
Le PERT a été ainsi créé en 1956 à la demande de la marine américaine afin de planifier la durée de son programme de missiles balistiques nucléaires miniaturisés Polaris.
Alors que le délai initial de ce programme – qui a fait intervenir 9000 sous-traitants et 250 fournisseurs – était de 7 ans, l’application de la technique du PERT a permis de réduire ce délai à 4 ans.
Mais en réalité, la technique du PERT n’était que peu utilisée dans les faits, mais il servait essentiellement de sécurité pour les décideurs, pour montrer que tout allait bien…

Une keynote vraiment intéressante au final, bien que peut-être un peu courte, car il y avait tant à dire !

J’ai ensuite réalisé ma présentation sur Sonar au cours des Lightning Talks, ensemble de sessions rapides dédiées aux outils.
Si je suis plutôt content de ma prestation, je regrette toutefois le peu de temps dont j’ai disposé pour aller véritablement au fond des choses, en particulier sur l’aspect plus théorique comme le suivi de la qualité du code source.
D’un autre côté, il faut dire qu’une autre présentation « qualité du code source et l’intégration continue » devait aborder ces sujets…
Les Lightning Talks se sont ensuite poursuivi avec les présentations sur les outils agiles dans le monde .Net, puis sur GreenPepper.

J’ai donc ensuite été voir la « Qualité du code source et l’intégration continue » par Erwan Alliaume et Nicolas Le Coz de Xebia.
A vrai dire, je n’ai pas beaucoup appris lors de cette session, mais il faut dire aussi que ces sujets sont loin de m’être étrangers
Le contenu était toutefois intéressant, et présentait plutôt bien l’état actuel de la réflexion sur la qualité du code, ainsi que son suivi au cours du développement d’un projet.
A noter une (courte) démonstration de l’outil Sonar a été faite à la fin de la session, ce qui tend à prouver l’importance que prend cet outil aujourd’hui !

J’ai passé ma deuxième moitié de la matinée à chercher la réponse à la question « Scrum est-il dangereux ?« , animée par Guillaume Tardif et Eric Lefevre-Ardant.

Il ne s’agissait pas d’une présentation, mais d’une sorte de forum, de débat ouvert.
Première étape : prendre le pouls de l’assemblée. Qui pense que Scrum est dangereux ? Qui pense que Scrum est une bonne chose ?
Nous devions être entre une cinquantaine de participants, et mon estimation est qu’environ 60% d’entre eux avait un avis plutôt positif sur Scrum, le reste un avis plutôt (voire très) négatif, à quelques exceptions près dont Emmanuel Gaillot d’Octo pour qui Scrum reste un mot (ce en quoi, il n’a pas tort ) …

Eric a divisé la session en deux parties, où chacun était libre de donner son avis, son point de vue sur Scrum.
Considérant la grande qualité des personnes présentes dans l’assemblée, je dois dire que le débat a été très passionné, et je pense même que les 90 minutes de la session n’étaient pas suffisantes !

Nous avons donc commencé par penser que Scrum est dangereux car :

• il donne une certaine méfiance aux personnes extérieures au projet
• il donne du mal pour collaborer avec des équipes non Scrum
• il marginalise
• il peut s’apparenter à une dérive dogmatique
• il ne fait pas sérieux, avec son jargon
• il révèle les incompétences
• il provoque des départs dans l’équipe
• il remet en cause l’organisation
• il radicalise les équipes
• il supprime le chef de projet
• il rend plus difficile la valorisation des collaborateurs
• il peut (se) décridibiliser en cas d’échec
• il existe des certifications, incitant à penser qu’il y a des gens qui savent mieux que d’autres
• il représente une solution de facilité
• il n’implique pas assez le Product Owner
• il est viral
• il est simpliste
• il peut casser le reste de l’agilité
• il est trop formel
• il est incompatible avec la Recherche & Développement
• il est difficile à faire

Malgré ce déluge de critiques, on s’est dit aussi que Scrum est une bonne chose car :

• il accroît la communication
• il accroît l’implication de l’équipe dans le projet
• il fait émerger les problèmes
• il est compréhensible par les non-développeurs (contrairement à XP)
• il offre une grande visibilité de l’avancement du travail
• il détruit le waterfall
• il fait de la publicité pour l’agilité
• il ouvre la porte à XP
• il permet de lisser l’effort
• il permet d’échouer plus vite !
• il amène à la réflexion
• il donne un codage plus efficace
• il donne une plus grande motivation, plus de plaisir
• il offre une certaine liberté
• il n’est pas une méthodologie
• il offre une impression de fluidité, de rythme
• il est honnête
• il donne un meilleur contrôle du client, grâce au rôle du Product Owner et de son rôle de prioritisation
• il se focalise sur le produit
• il y a beaucoup de documentation, de retours d’expérience

Voilà pour la liste des aspects positifs ou négatifs sur Scrum.
Un compte-rendu plus élaboré sur cette session est donné par Nicolas sur son blog du Touilleur Express.
Il a également eu la bonne idée d’enregistrer la session, disponible en Podcast.
Eric a également fait une rétrospective – en anglais – de cette session, visible ici.

A noter que cette session a été fortement inspirée de Is Scrum evil? de Jeffrey Fredrick, et que le choix de la traduction d’Evil par dangereux était sujet à controverse (mais a-t-on une meilleure traduction ?)…

Eric a conclu très furtivement en disant que la meilleure méthode agile était la ARxTA, ou Artisanal Retro-Futurism crossed with Team-Scale Anarcho-Syndicalism… Tout un programme !

L’après-midi

J’ai commencé mon après-midi avec une « Introduction à TDD pour les managers« , d’Eric Lefevre-Ardant et Stéphane Labati.
Si je suis assez au fait de la méthode TDD (Test Driven Development ou encore Développement Piloté par les Tests), j’étais assez curieux de voir comment elle allait être présentée à un public de non techniciens.
Cela peut toujours être intéressant de trouver des nouvelles idées pour convaincre les grands chefs et les managers de l’utilité d’une telle pratique…
Ici, point d’Eclipse, de Netbeans ou autre IntelliJ. Le seul outil utilisé est Excel ! Eh oui, faire du TDD avec Excel, c’est possible.
L’application a développer reste relativement simple – quoique – puisqu’il s’agit d’un « traducteur » de chiffres arabes en chiffres romains.
Sans être très technique, j’ai trouvé cette mise en pratique plutôt sympathique, montrant efficacement l’intérêt de la méthode TDD.

Viennent ensuite deux présentations proposées par mon ami Rémy Sanlaville, dont la première, « Coding-dojo : un retour d’expérience« , expose un retour d’expérience sur les Coding Dojo.

Mais avant toute chose, qu’est-ce qu’un coding-dojo ?
Le constat de départ est que trop de développeurs utilisent uniquement leur travail (et leurs réalisations professionnelles) comme terrain d’entraînement pour parfaire leurs techniques.
Le principe d’un dojo de code est de proposer un espace sûr pour que les développeurs puissent expérimenter, tester et apprendre en dehors du cadre d’un projet.
Un coding dojo est donc l’endroit idéal pour apprendre un nouveau langage (le Ruby par exemple) ou encore une technique particulière (le TDD).

Rémy nous propose donc de faire un retour d’expérience consécutif à l’organisation de plusieurs coding dojo sur la région grenobloise, en insistant en particulier sur les problèmes rencontrés :

• Les problèmes liés à l’organisation : il faut du temps, répondre aux problèmes de logistique et de matériel…
• Les problèmes liés au bon déroulement de la séance. Ne pas oublier l’objectif premier, qui est celui d’apprendre, pas forcément de terminer les exercices proposés. D’où l’importance d’un bon facilitateur, qui saura diriger la session convenablement.

Bref, les coding dojo, ça marche, c’est gratifiant, mais ce n’est pas de tout repos à organiser !
Toujours est-il que CARA – Club Agile Rhône Alpes – organise son 11e coding dojo cette semaine ! Preuve du succès de ce type d’événement…

Cela me donne d’ailleurs une idée : ne pourrait-on pas organiser des coding dojo au sein de sa propre entreprise ?

Edit : Rémy, car c’est un gars bien, a mis ses slides à disposition, ici !

La deuxième session animée par Rémy Sanlaville que j’ai pu suivre traitait « De l’atelier à l’usine logicielle : enjeux et retour d’expérience d’Orange Labs« .
Grâce à son expérience au sein d’Orange Labs, Rémy nous a proposé un tour d’horizon très complet sur les solution d’usine logicielle qu’il a pu déployer.
La première étape consistait à nous expliquer l’intérêt d’une telle usine logicielle, puis à comprendre les différentes problématiques liés aux builds.
Un point important est de pouvoir assurer la reproductibilité du build dans l’espace (quelque soit l’environnement) et le temps (quelque soit la date du build).
En effet, différents facteurs impactent directement un build :

• Les fichiers source (code source, fichiers de ressources…) qui évoluent sans cesse
• La plateforme d’exécution, avec son OS, ses outils, ses librairies…
• Les ressources externes (repositories Maven2, ressources Web Services, etc.)
• Les facteurs humains, mais qui sont volontairement omis, car nous sommes dans une démarche d’automatisation des builds.

Bien entendu, Rémy a abordé la question de l’Intégration Continue, en expliquant entre autre l’importance d’une détection précoce des bugs…

Coût de correction et découverte des bugs au cours du cycle de développement

Un chapitre a été par la suite consacré à la question de la traçabilité, grâce à des outils de gestion de bugs (Jira par exemple).
Cela m’a fait comprendre qu’il est nécessaire de renforcer les liens entre l’outil d’Intégration Continue et celui de Tracking, le premier pouvant par exemple injecter des bugs dans le second en cas d’échec d’une compilation…

Bien évidemment, la surveillance de la qualité logicielle est un aspect important dans une usine logicielle, et Rémy a mis en avant l’intérêt qui a été porté à l’outil Sonar (eh oui, encore lui !).

En ressortent au final les aspects positifs d’une telle démarche :

• L’industrialisation réussie d’outils d’ingénierie logicielle
• La recommandation au niveau du groupe France Télécom
• La mise en place de bonnes pratiques
• Les projets sont demandeurs de telles solutions, et souhaitent aller encore plus loin
• L’ingénierie logicielle se renforce dans la culture d’entreprise

mais également les difficultés rencontrées :

• Beaucoup de travaux à mener en parallèle
• Certains sujets (les métriques en particulier) sont difficiles à conceptualiser
• Industrialiser un outil demande du temps et des compétences
• Prise en compte des nombreuses contraintes liées à la taille d’un groupe tel que France Télécom

Les slides de Rémy sont disponibles ici.

Bilan

Les XPDays sont à nouveau un joli succès.
Mon principal problème a été le planning très chargé, 6 sessions en parallèle sur ces deux jours, ce qui imposait de faire parfois des choix difficiles !
D’après le questionnaire fourni, il n’est pas à exclure que la conférence se déroule sur 3 jours dès l’année prochaine…
A ce propos, XP Days France prendra le nom de Agile Paris dès l’année prochaine. Un nom certes plus en adéquation avec son contenu, mais qui ne me séduit pas forcément…

Une dernière fois, encore merci aux organisateurs pour leur fantastique travail !

De nombreux consultants ont réagi suite à leur présence aux XP Days.
Vous pouvez les retrouver sur le blog de Valtech, ici, ici ou encore ici…

Start Slide Show with PicLens Lite

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:

Javascript:

Javascript:

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…

Start Slide Show with PicLens Lite