J’hésitais un peu à y aller, craignant que les présentations soient plus de l’introduction à Scrum. Puis je me suis décidé pour voir Eric Mignot de chez Pyxis, voir le Touilleur (aka Nicolas Martignole) faire sa première et pour revoir Guilaume Bodet qui avait fait une très bonne présentation au Scrum User Group en mars. Bien m’en a pris, car la soirée était très instructive !

Première présentation

La première présentation, sous la forme d’un dialogue, a été une introduction à Scrum. Le Touilleur en a profité pour ressortir sa métaphore de la machine à laver.

Je ne ferais pas un topo complet de cette présentation qui a principalement reposé les bases de Scrum et du manifeste agile, mais j’ai cependant bien aimé certaines idées avancées par Eric Mignot.

Notamment : apprendre Scrum c’est désapprendre autres choses (avec en cible de mire les processus lourds et parfois incohérents imposés par certaines méthodes).

L’idée véhiculée tout au long de cette présentation est que les méthodes agiles ne doivent pas être vues comme une méthodes à appliquer aveuglement « out of the box ». Les méthodes agiles sont là pour nous faire réfléchir sur ce que l’on fait, et pour nous redonner le goût de faire du dev. Pour cela, elles proposent un ensemble d’outils, mais elles ne doivent pas être vues comme une méthode à part entière.

Le but ce n’est pas de faire du scrum, mais de s’améliorer. Ainsi, pourquoi pas introduire petit à petit le daily Scrum ou bien la démonstration post itération tous les mois ?

Je vous ai refait au propre le schéma d’Eric qui synthétise assez bien Scrum ci-dessous :

Info intéressante, Eric estime que la vélocité sur un projet se stabilise au alentour du 5^ème ou 6^ème sprint.

Deuxième présentation

La deuxième présentation, proposée par Guillaume Bodet a été encore une fois extrêmement enrichissante. Guillaume nous proposait de confronter la réalité de l’introduction de Scrum sur les équipes en place.

Premier problème, comment trouver un Product Owner ? Pour cela, et contrairement à ce que la littérature propose on se rend compte fréquemment :

• que le product owner n’est pas forcément seul
• qu’il n’est pas forcément responsable de tout
• qu’il n’est pas forcément un visionnaire

On n’a pas tous un Steve Jobs dans nos entreprises. Le rôle de du product owner est avant tout un rôle logique.

Deuxième problème comment on démarre un projet agile et comment on constitue un Backlog de produit.

Pour démarrer un projet il faut au mininum :

• la taille estimée du projet
• le ROI
• la liste des principaux risques
• la composition de l’équipe

Le tout pouvant tenir dans un document d’une dizaine de pages max.

A partir de ceci on obtient le go du projet et on peut partir sur un Sprint 0 avec une équipe réduite. A l’issu de ce Sprint le Product Owner, aidé par l’équipe, aura créé un premier backlog de produit.

Le burdown chart a ensuite été évoqué. La notion intéressante est de mettre en avant deux courbes, une qui montre les stories implémentées à partir de l’estimation initiale, l’autre pour montrer l’ajout de story (ou le retrait) ou la réévaluation des tâches. C’est plus motivant et vendeur de voir un burdown qui globalement est en baisse.

Guillaume nous livre la difficulté rencontrée de vendre le burdown aux comités de direction, habitués au diagramme de Gantt et aux jalons clairs. Il convient selon lui de maintenir à jour 5 niveau de planification :

• daily (quotidienne en heures)
• itération (toutes les 2 semaines)
• releases (trimestriel)
• product roadmap (semestriel)
• product vision (annuel)

La scalabilité de Scrum a ensuite été mise en avant au travers de plusieurs retours d’expérience. Le but est d’avoir ses équipes de Scrum avec chacun un ScrumMaster. Puis les ScrumMaster se retrouvent tous les 2/3 jours avec un « Meta ScrumMaster » qui est le ScrumMaster des ScrumMasters. Le principe s’applique en théorie sur n’importe qu’elle profondeur (j’ai déjà vu ça dans des présentation de Yahoo).

Sur le projet ProRail au Pays-bas, 25 personnes étaient réparties en 4 équipes. La V1 a été livré au bout de 8 mois puis les releases s’en sont suivis tous les 3 mois.

Enfin, Guillaume a fini la présentation en parlant d’architecture.

Il met un léger bémol au principe d’architecture émergente. Selon lui, l’architecture doit quand même être réfléchi au début du projet, on sait globalement qu’elles vont être les besoins et on doit prévoir ce dont on aura besoin au minimum. Selon lui, les erreurs d’architecture peuvent être très lourdes à corriger (si c’est possible) si l’architecture est fondamentalement fausse.

Il a fini par présenter la notion d’architecte agile (que l’on trouve présenté sur le blog de Xebia) 

L’architecte agile est cet architecte qui propose des règles flexibles plutôt que dogmatique.

D’après Scott Ambler (IBM) :

• piloter l’architecture par les besoins
• essayer de modéliser à plusieurs
• préférer la collaboration plutôt que la documentation (à quoi servent des best practices de centaines de pages si personnes ne les lit ni ne les comprend).
• faire simple (KISS)
• s’attaquer aux grandes problématiques tôt, régler les détails au moment voulu
• rester flexible
• publier les modèles d’architecture/métaphores.

Pour conclure, la soirée a été encore très intéressante. Merci aux présentateurs et au ParisJug pour ces présentations de qualité.

Un résumé très complet et avec photos est disponible également ici.

La première présentation de Guillaume Laforge sur Groovy était très intéressante et axée sur le point de vue d’un développeur Java. L’argument majeur que je retiens est que tout code java est lui même du code Groovy (mais pas l’inverse naturellement!). La prise en main est donc très bonne car on écrit du code java au début que l’on groovyse au fur et à mesure que l’on maîtrise les tricks du langage. Je vous épargne les détails ici car Xebia en fait un compte rendu très complet ici. Le seul aspect au final qui me laisse encore perplexe dans Groovy est le faible pouvoir de détection d’erreurs à la compilation. Guillaume Laforge estime que l’aide des IDE (notamment IntelliJ) combiné à un set minimaliste de test unitaire résout le problème, à voir…
La présentation finit par une présentation des DSL (Domain Specific Langage), je ne suis pas persuadé que n’importe quel utilisateurs puissent les utiliser, mais c’est en effet un vrai moyen de se rapprocher de son client et d’essayer de parler la même langue.

La deuxième présentation était une introduction à Grails faites de manière assez ludique. Le point de vue mis en avant (et c’est l’un des atout majeur de Groovy/Grails) était vraiment la productivité. Avec aussi une partie sur le fait que Grails produisent bien une applis standard J2EE (un War). Il est en effet bluffant de voir en 10 minutes tout ce que l’on est capable de produire. Entre une syntaxe très simplifiée (merci Groovy), un boulôt de génération massive pour la BDD et l’IHM (merci Rails) et le fait de pouvoir s’abstenir de redémarrer le serveur d’application, il est clair que la productivité est au rendez-vous. De plus, d’après les retours d’expériences il semblerait que Grails tiennent globalement bien la montée en charge.
A l’issu de cette présentation, j’ai appris que la communauté Groovy était en train de sortir un équivalent de Grails pour Swing, en cherchant un peu je viens de découvrir Griffon. A tester!

Dernier petit bonus de la soirée, j’ai gagné le livre « Filthy rich client » ce qui vraiment cool, merci au ParisJug!

Pour ceux qui n’auraient pas pu participer à la soirée, vous n’avez pas tout perdu car 2 présentations équivalentes sont disponibles, ce sont globalement les mêmes, celles du ParisJug étant justes un poil mise à jour et rallongées.

Présentation de Groovy sur parleys

Présentation de Grails : T18 – Innover sans contraintes, intégrer sans ruptures (s’inscrire gratuitement sur le site de l’université du SI).