Après un départ un peu compliqué de Paris pour Genève, j’ai réussi à rejoindre dimanche soir la Suisse, avec Sébastien Douche. Nous avons été accueilli par Thomas Verin, Xavier Bourguignon et Maxime Nowak. Soft-Shake se déroule dans un centre de conférence adossé au stade de football de Genève. Après un diner typiquement Suisse (encore merci au Geneva JUG), nous avons terminé les derniers détails de nos présentations respectives. Sébastien présentait les DVCS et Git. Quant à moi je faisais la Keynote d’ouverture et une présentation sur Play! Framework.

Lundi matin, la journée débute avec un mot de Jacques Couvreur, l’un des organisateurs. Au total il y avait environ 130 personnes, speakers compris. Un peu moins que les 200 personnes escomptées, succès mitigé de l’aveu même de Jacques. Les grèves en France ont empêché pas mal de monde de venir malheureusement.

La journée est organisée autour de 4 salles, avec un track iPhone, un track Agilité, un track Java et un track Incubateur. Le mélange prend bien, les communautés Java, iPhone et Agiles se sont mélangées, c’était vraiment sympa.

Je vous posterai ma présentation d’ouverture, sur le thème de la passion et du métier de développeur. J’ai raconté un peu mon expérience et quelques idées sur les moyens pour dynamiser une équipe. Quelques moyens aussi pour que chacun se fasse plaisir à son boulot.

J’ai assisté ensuite à un retour sur expérience sur Scrum. Le déroulement de la mise en place de la méthode, les choses qui se sont bien passées, les difficultés rencontrées, bref un retour intéressant. Ce fut ensuite pour moi la présentation de Play! Framework. J’adore présenter ce framework. C’était la deuxième fois en 15 jours après la co-présentation avec Guillaume Bort au ParisJUG. Après une présentation de 40 minutes, j’ai montré comment coder une application de TodoList. Je me suis appuyé sur Git afin de créer des tags dans ma démo, pour pouvoir avancer dans l’implémentation sans avoir à coder, et donc ennuyer l’audience. Le code est déjà sur GitHuB sur http://github.com/nicmarti/PlayDoo. Vous pouvez télécharger le projet PlayDoo via le lien http://github.com/nicmarti/PlayDoo/archives/master. Attention le projet utilise la version 1.1-RC2 de Play! Framework. Cette version est disponible sur le site de Play!. Enfin utilisez Java 6 afin que tout fonctionne sans soucis. Je vous proposerai un tutorial détaillé un peu plus tard.

J’ai eu l’occasion de discuter une heure avec Régis Médina avant le déjeuner. J’avais assisté à sa présentation lors de l’Agile France 2010 sur le Lean. Passionné et expérimenté, il m’explique la démarche Lean et les valeurs portées par celle-ci. L’observation constante de ce que nous faisons nous permet de détecter les points où nous pouvons nous améliorer. Il ne faut pas vivre la recherche d’amélioration comme un stress ou un moyen de pression. Au contraire, en passant par exemple le temps de compilation de votre projet de 15mn à 4mn, vous gagnez du temps pour faire autre chose. C’est autant de stress en moins pour se laisser du temps pour réfléchir et coder. Le Lean s’accompagne d’un changement de valeur au niveau de l’organisation. Plus particulièrement du management des hommes. Régis parlera lors de sa présentation de PDCA, de différents moyens pour qu’un projet soit développé en s’améliorant constamment. Ce fut un échange passionnant, merci à Régis pour cette heure passée ensemble.

Le déjeuner m’a permis de rencontrer quelqu’un qui a rejoint eXo Platform récemment, Henri Gomez. Il me parle de l’article le plus lu sur le Touilleur Express. Je mesure à chaque fois l’impact de ce billet écrit en juillet 2009. Cet article, et vous êtes nombreux à l’avoir lu, a marqué pas mal de monde.

L’après-midi reprend avec une Keynote éclairée de Régis Médina sur le Lean. Le cycle en V est mort et enterré, quoique cette approche traditionnelle soit encore largement utilisée. Le matin même je parlais d’une étude qui a porté sur 1298 projets aux USA. Il n’y a que 33% des projets qui affirment utiliser des pratiques Agiles. Attention, je ne parle pas de méthodes Agiles mais bien de pratiques de génie logiciel. Sur ces 33%, à peine 11% des projets sont en Scrum. Nous sommes donc bien loin de la perception parfois faussée du déploiement de l’Agilité en entreprise.

Une remarque de Régis Médina sur les pratiques Agilites : elles n’adressent pas forcément la source d’un problème. Les pratiques Agiles visent à changer la manière dont on fait les choses. L’approche Lean vient en plus pour nous proposer de s’améliorer et de changer les raisons pour lesquelles nous faisons certaines choses. Par ailleurs, si l’Agilité est un ensemble de pratiques que chacun peut mettre en place, la philosophie de Lean est de revoir l’organisation du monde de l’entreprise, afin d’améliorer la productivité.

Lorsque l’on parle d’amélioration de la productivité, une partie de l’audience (surtout les Français) peut penser à tord que cela va mettre de la pression sur le salarié… Je pense qu’il est important de ne pas tomber dans le panneau. L’objectif de Lean est d’améliorer la productivité afin que nous puissions nous concentrer sur ce qui a de la valeur, plutôt que de perdre du temps (le fameux Muda de Lean) sur des tâches sans réelles valeurs ajoutées. J’ai discuté sur la vision parfois industrielle de Lean et de son application dans le domaine logiciel avec Régis. Fabriquer une voiture à la chaîne n’a rien à voir avec fabriquer un logiciel. Nous sommes d’accord pour dire qu’une application bête de Lean (comme toutes méthodes) avec une vision industrielle ne peut pas fonctionner sur du développement logiciel. Il s’agit bien de prendre le contrat de valeur (ce que je veux améliorer) et de l’appliquer sur le développement logiciel (ce que je veux faire). Comme vous le voyez, le sujet était très intéressant.

J’ai poursuivi l’après-midi avec des présentations autour de Java. J’ai bien aimé la présentation de JBehave de Xavier Bourguignon et la présentation de David Gageot sur l’amélioration des tests unitaires. J’ai un peu somnolé au début de la présentation de Penceo Webdesign sur l’ergonomie. Les slides avec pleins de texte que l’on lit au lieu d’écouter le speaker… c’est pas très ergonomique. Cependant la deuxième partie de la présentation était vraiment plus intéressante. Bon je sais, là dit comme cela vous êtes bien avancé… mais j’ai pas le courage d’écrire un long billet là-dessus.

Conclusion
Pour conclure, Soft-Shake a un bon potentiel pour s’insérer dans le créneau conférence francophone, tout en offrant plus de sujets qu’uniquement Java. Bravo pour le mélange des communautés, cela fonctionne.

Sur ce, je vous donne rendez-vous l’année prochaine.

2 réflexions sur « Retour sur Soft-Shake 2010 »

  1. Hugh,

    Merci pour se billet très intéressant. J’ai tout de même une petite remarque sur la partie décrivant la différence entre Agile et Lean.

    L’agile, pour moi, n’est pas (au choix et non exhaustif): discuter à deux devant un clavier, raconter ses aventures debout devant un tableau multicolore, dessiner des pentes, parcourir un excel listant des envies ou un accélérateur de croissance pour les sociétés produisant des post-it.

    Plus sérieusement l’agile n’est pas « un ensemble de pratiques que chacun peut mettre en place » mais un mode de fonctionnement à l’aide duquel on cherche des solutions aux problèmes rencontrés. Le plus important n’est pas les artefacts prônés par les diverses méthodes mais la mise en place du contexte et des réflexes propices à l’amélioration du travail des équipes (qualité, délais, implication, plaisir, …). Tout cela commence par les équipes mais ne s’y arrête pas et, si fait correctement fait, rayonne dans le reste de l’entreprise (il est rare que les difficultés ne soient qu’interne à une équipe).

    En fait j’adore l’approche Agile (vécue au quotidien) et j’aime tout tout autant le Lean (on y va…). L’opposition entre les deux me semble cependant plutôt artificielle. On peut très bien mettre en place un programme d’amélioration d’un service en « appliquant » le Lean sans mesurer la satisfaction du client et là, quand même, on se dit que le problème n’est pas lié au cadre méthodologique utilisé. L’important ce sont les principes et, ensuite, de choisir les bonnes implémentations ;o)

    Phil

Les commentaires sont fermés.