Il y a quelques semaines je présentai un sujet intitulé « Ludification du travail » à une trentaine d’étudiants de l’Epita dans le cadre de leur semaine annuelle de conférences technologiques. J’avais le plaisir d’inaugurer cette présentation sur un sujet qui me tient à coeur et qui fait couler de plus en plus d’encre numérique dans la blogosphère agile. Vous trouverez ci-dessous mon support de présentation que j’ai chargé sur SlideShare. 

J’ai fait un rapide ROTI à l’issue de la présentation et obtenu une majorité de 4 et 5, j’ai également récolté quelques 1: on ne peut pas intéresser tout le monde et le caractère obligatoire de cette conférence ne permettait pas d’utiliser la loi des 2 pieds. 

Enfin, si le support n’est pas assez explicite, sachez que j’ai déroulé cette présentation aux Xebians lors de notre XKE du mois de décembre et que la session a été filmée. Vous devriez donc avoir les explications incessamment sous peu. 

Pour faire simple, imaginez que sur un seul écran vous puissiez voir en un clin d’œil l’état de vos builds (succès/instabilité/échec), le nombre de tests unitaires et d’intégration agrémenté de métriques telles le nombre de lignes de code, la couverture de code et le respect des normes de codages.

Mieux qu’un long discours, nous vous proposons une courte vidéo de 3 minutes qui démontre la facilité avec laquelle vous pouvez démarrer facilement avec l’outil.

Si l’outil vous intéresse, il est disponible au téléchargement et le code source est à votre disposition sur github.

Si vous désirez en savoir plus sur le développement de ce projet, nous vous proposons une rétrospective de ces derniers mois, en partant de la genèse du projet jusqu’à son état actuel.

La genèse

Visuwall est un projet imaginé et développé par deux Xebians : Arnaud Lemaire et Julien Smadja. L’idée a germé en janvier 2011 à l’occasion d’une mission axée sur l’amélioration de la testabilité d’un projet Java. Sa première étape fut d’écrire plusieurs dizaines de tests d’acceptance afin de valider le bon fonctionnement d’un webservice REST.

Les tests échouaient souvent et pouvaient durer plusieurs heures suivant l’environnement ciblé. Nous voulions connaître l’état de chaque environnement immédiatement et surtout, rendre l’information visible aux personnes extérieures. Le premier réflexe a bien sûr été de récupérer une unité centrale, un écran et d’installer un plugin Hudson capable d’afficher un « mur » de projets.

Ensuite, nous avons commencé à tenter de l’adapter graphiquement : changer la taille des polices, des blocs, cacher les informations non pertinentes, en afficher d’autres, etc. Un premier fork du plugin a donc été fait sur Github mais le cycle de développement n’était pas optimal : difficulté à tester, redéploiement du plugin, vérifications manuelles, etc.

La customisation du plugin n’étant pas viable, nous décidons de créer notre propre logiciel, adapté à nos besoins et ouvert à plusieurs outils. Visuwall était né… Enfin, ce nom n’est pas d’origine, le nom de code était Jbiniou puis JWall, ProjectWall et enfin, un matin, il fut baptisé officiellement Visuwall, une simple contraction des termes Visual et Wall.

Visuwall sera développé en parallèle de notre projet chez notre client, dans un cadre open source (Apache Software License 2), hébergé sur Github et codé en Java.

Technologiquement parlant : une base de données embarquée HsqlDb, une couche de persistence JPA2/Hibernate 3, une couche service Spring3/Spring MVC et une interface graphique Html/Javascript utilisant jQuery.

Rapidement, le projet est découpé en plusieurs modules, le core, l’interface web et les plugins. Il était très important que Visuwall soit capable d’être étendu par des plugins que nous avions d’abord catégorisés en deux groupes: les plugins des outils de builds (Hudson, Jenkins) et les plugins des outils de qualité (Sonar). Comme l’écriture d’un plugin se doit d’être simple, le design d’une API publique a été amorcé. Il s’agit principalement de remplir au maximum le contrat imposé par le moteur de Visuwall. Par exemple, un plugin doit être capable de fournir la liste des projets, la durée de tel ou tel build, le nombre de tests, etc.

Après plusieurs mois de développement, dans des endroits insolites comme les Bus, Metro, Rer et autres salles d’attente, le projet a été présenté lors du XKE de Juin afin de recueillir les premiers avis de nos collègues Xebians et pourquoi pas, les inciter à installer cette version 0.1 chez leurs clients.

À la suite des premiers retours (bugs et améliorations) nous avons travaillé sur une refonte totale (notamment sur l’API des plugins).

Modularité

Au fur et à mesure du développement, nous nous apercevons que certaines parties de notre code constituent à elles seules des projets à part entière. Nous avons donc déplacé ces projets dans un repository Github séparé. Ainsi, la communauté pourra se servir facilement de ce qui a été commencé pour Visuwall et utilisable dans un autre contexte. C’est notamment le cas des parties clientes de Bamboo, TeamCity, Hudson, Jenkins, Sonar (projet nommé Clients), mais également la partie validation des formulaires d’où naquit une librairie de validation (Client Bean Validation) qui est une implémentation en Javascript de la JSR303 pour la validation coté client des objets du serveur.

Pour améliorer la modularité du projet nous travaillons actuellement sur une transformation des clients en bundle OSGI afin de pouvoir charger et décharger des plugins à la volée pendant que l’application tourne. Cette évolution nous permet à la fois de mieux appréhender le coté modularité de l’OSGI mais également d’apporter une plus grande flexibilité à l’application. À terme, l’ajout du moteur OSGI permettra de faire fonctionner toute l’application avec des modules customisables, remplaçables et extensibles.

L’aventure continue

Notre travail sur Visuwall ne fait que commencer, nous avons encore des anomalies à corriger et des fonctionnalités à implémenter. Nous espérons avoir un maximum de retours de la part de la communauté pour pouvoir proposer un logiciel de qualité et utilisable dans le cadre de tous vos projets.

Visuwall a été présenté à CITCON 2011 devant quelques personnes dont un représentant de JetBrains. Nous allons prochainement prendre contact avec lui pour discuter des différentes améliorations que nous souhaiterions dans l’API REST de Teamcity !

Le concept de la coderetreat est née à la conférence CodeMash en Janvier 2009. L’idée était de créer un événement reproductible d’une journée afin de permettre de s’entraîner sur les fondamentaux du développement logiciel. Depuis maintenant 3 ans, le format de coderetreat a évolué au fil du temps pour aider les développeurs à aiguiser leurs pratiques techniques. Sous le patronage de Corey Haines, le concept se popularise et aujourd’hui il y a quasiment une coderetreat par semaine quelque part dans le monde.

Qu’est ce qu’une coderetreat ?

Lorsque vous assistez à une coderetreat vous allez vous attaquer à une tâche simple, généralement le jeu de la vie de Conway. Ce même exercice sera exécuté de manière répétée à travers plusieurs sessions de 45 minutes. Chaque session est traitée en programmation par paire utilisant la technique de développement dirigée par les tests (TDD). Ce qui, pour bon nombre de participant est déjà un entraînement en tant que tel.
Au fil de la journée les participants sont invités à s’entraîner sur des domaines en particulier : les 4 règles du design simple, SOLID, « TDD as if you meant it », ping-pong pairing entre autre. Il y a généralement 6 sessions dans une journée, chaque session étant entre-coupée d’une rétrospective et d’une courte pause. Un solide déjeuner ponctue la mi-journée. La journée est conclue par une rétrospective globale. Généralement le participant repart d’une journée de coderetreat, au minimum avec tout un tas de petites astuces : nouveau raccourci clavier, nouvelles techniques, fonctions peu usitées d’un IDE ou d’un langage, et globalement avec le sentiment d’avoir pu pratiquer une autre manière de développer.

Le jeu de la vie est un problème relativement simple à comprendre mais qui fournit un champ d’expérimentation particulièrement riche pour l’entraînement de ces pratiques et le design. Finir l’exercice dans une session est généralement ardu car ce n’est pas l’objectif, il est le support de l’apprentissage, pas une fin en soi. Participer à une coderetreat c’est s’entraîner, s’entraîner non pas à résoudre le problème le plus vite possible mais bien s’entraîner afin d’être globalement plus efficace. Nous avons déjà abordé le thème de l’entraînement intentionel sur ce blog.

Une coderetreat n’est pas contrainte à un langage de programmation en particulier, ce type d’événement est l’occasion de découvrir un nouveau langage en le pratiquant concrètement sur un problème que vous avez déjà résolu dans votre langage de prédilection. Il y a rarement meilleure occasion pour découvrir un nouveau langage et bénéficier d’une assistance qui donne un bon coup de fouet à cet apprentissage qui est parfois difficile à débuter.

Le global day of coderetreat

Le 3 décembre a lieu le « global day of coderetreat ». C’est un événement international initié par Corey Haines et organisé par des facilitateurs locaux dont le but est de faire se dérouler un maximum de coderetreats en une journée. Le but de cette journée est non seulement de faire s’aiguiser les capacités des participants mais aussi de sensibiliser notre profession sur ce type d’entrainement spécifique.

L’événement aura lieu sur environ 48 heures, le 3 décembre prochain. Corey Haines commencera en Australie en facilitant une coderetreat à Sydney puis prendra un avion pour rejoindre Hawaï où il facilitera la dernière coderetreat du « jour ». Pendant ce temps, 90 coderetreats auront lieu dans la plupart des fuseaux horaires du monde, ce qui fait environ 2000 participants. Lorsqu’une coderetreat se termine, elle pourra se connecter avec une autre qui démarre ou qui est en pause déjeuner pour échanger du feedback.

Pour la France, Xebia accueille et facilite celle de Paris avec l’assistance de la Paris Software Craftsmanship Community et Arolla. L’évenement est complet. La France est bien représentée avec deux autres coderetreats ce jour là, à Bordeaux et Toulouse.
Avec le rythme actuel nous envisageons de faciliter 3-4 coderetreats par an environ, notez que ce type d’événement a généralement lieu le samedi matin relativement tôt.

Vous pouvez suivre notre blog ou notre twitter pour les annonces des prochaines coderetreats.

Quelques liens pour creuser le sujet :

• Global day of coderetreat.
• How a coderetreat work.
• Deliberate Practice.

Depuis quelques temps j’attendais l’arrivée de cette journée avec impatience. Intrigué par le nom et le pitch, je me demandais ce que j’allais y trouver, c’est-à-dire ce que les autres allaient apporter. Même si je ne doutais pas de l’intérêt de faire le déplacement, je suis toujours un peu prudent sur le simple fait que rassembler une brochette d’experts agiles dans un endroit pendant une journée va forcément ressortir sur du positif.

Agile Innovation était une journée entièrement dédiée aux échanges open-space et qui faisait suite à la conférence Agile Grenoble la veille, avec un programme plus classique. L’ambition des organisateurs étaient d’offrir un espace d’échange permettant aux praticiens aguerris d’aller au delà d’un programme de présentation qui, comme il se veut accessible à tous, peu sembler parfois un peu simple pour les agilistes expérimentés.
Alexandre Boutin était notre maître de cérémonie pour la journée. Armé de sa cloche de montagne, dont nous allions entendre le son rythmer cette journée, il nous a rassemblé après un petit déjeuner pour l’ouverture de cet open-space. Les règles d’un open space sont simples et l’objectif de cette ouverture est d’établir l’agenda de la journée.

La construction de l’agenda s’est faite sur le même principe que les open-space de la conférence ALE2011: chacun présente une proposition de sujet au groupe et la colle directement sur un créneau disponible, premier arrivé, premier servi. Je trouve cette technique assez efficace car il n’y a pas, comme j’ai pu le voir à des conférences comme CITCON par exemple, de votes pour faire émerger les sujets les plus populaires puis une construction collaborative de l’agenda. Cela évite de perdre un temps précieux pour arriver à un consensus qui généralement ne satisfait pas vraiment, autant partir tout de suite avec l’idée qu’il faudra faire des choix douloureux et ne pas s’embêter à une planification collaborative. La seule contrainte que je vois pour que cela fonctionne est d’avoir suffisamment de créneaux disponibles, dans le temps et l’espace, pour atteindre un écart suffisamment grand entre le nombre de propositions planifiées et le nombre de propositions abandonnées. A ce titre, Alexandre nous a fait une belle démonstration d’agilité en réduisant à la volée la durée des créneaux de 20 mn et en augmentant le nombre d’espaces de discussion pour maximiser les propositions. Bien joué.
3 sujets m’intéressaient fortement pour le premier créneau: Transformation Agile, advanced Story Mapping, et coaching agile. Je n’avais aucune envie d’en rater un et j’ai donc décidé de ne pas choisir! A force de pratiquer les open space, j’ai fortement développé mon application de la loi des 2 pieds ce qui permet d’une part de suivre plusieurs sessions en parallèle, mais aussi de ne pas regretter une session si elle se révélait être sans intérêt pour moi (dans ce cas je repars dans la première le coeur léger). Ca marche particulièrement bien si les facilitateurs des sessions font un bon travail de synthèse au fil de l’eau: lorsqu’on arrive dans l’espace de discussion on peut saisir rapidement ce qui s’est dit tout en écoutant la discussion en cours. Ensuite, il suffit à la fin du créneau de retourner voir la synthèse finale de chaque discussion pour lire les éléments manqués. Avec un peu d’exercice ça marche bien.

La session transformation Agile était animée par Petra Skappa et Greg Hutchings. Ils ont présenté différentes approches imagées de transformation (dont on sentait que certaines n’étaient pas conseillées): La goutte d’eau agile dans l’océan, les pousses agiles, le responsable agile et ses ambassadeurs distribués, le focus tournant (bottom up, top down, inside out, lateral).

La session stroy map était animée par Mac Adams. Il a présenté différentes approches de la technique et les participants ont partagé leur technique et les bénéfices.

La session Coaching Agile facilitée par Jean-François Jagodzinski, attrapée en toute fin, a généré beaucoup d’information. Elle était particulièrement intéressante dans la mesure où l’objectif était de prendre le point du vue des coachés et pas celui du coach. C’était un peu l’arroseur arrosé, là où le coach agit souvent comme un miroir de l’équipe, ce sont ici les coachés qui renvoyaient au coach leur image. C’était très instructif dans l’optique d’améliorer son action de coach agile. La discussion a même largement débordé sur le créneau suivant. Je m’en suis extrait avec difficulté pour rejoindre la session d’Alexandre Boutin sur les jeux sans matériel, une session qui a eu beaucoup de succès. J’ai particulièrement aimé le jeu des triangles (ou des systèmes complexes) plein d’enseignements sur l’auto-organisation.

Sur le troisième créneau j’animais une session sur le sujet « Agile Distribué ». Mon objectif était de rassembler les retours d’expériences et les opinions des praticiens ayant évolués dans des contextes distribués. Deux principales organisations se dégagent: des équipes pluri-disciplinaires co-localisées par site mais qui travaillent sur un même backlog, et une équipe pluridisciplinaire distribuée sur plusieurs sites. Au fil des discussions, la session a pris une tournure plutôt étonnante, là où nous voyons souvent le deuxième modèle comme une contrainte qui nous est imposée et qu’il faut éviter, quelques participants ont proposé que le modèle distribué est peut-être une cible en soi car elle porte des contraintes vertueuses: elle force la discipline individuelle, elle met en évidence des dysfonctionnements qui passent inaperçus en mode co-localisé, et elle apporte une richesse culturelle bien supérieure qui favorise la qualité du produit.

L’après-midi démarrait pour moi par une session sur la contractualisation agile. L’occasion de mentionner le contrat agile que Xebia a sorti en license Creative Commons et d’en expliquer les principes. Jean-François Jagodzinski a également beaucoup partagé ses expériences et l’état de ses réflexions. J’ai aimé sa métaphore du bio: quand on achète un poulet bio, on achète aussi le processus de fabrication du poulet, pas seulement le poulet. C’est un peu pareil pour le contrat Agile, l’idée est d’acheter un processus de fabrication et pas seulement le produit final.

J’ai continué l’après-midi avec un session facilitée par Jacques Couvreur, dont le but était de rassembler tous les ingrédients pour faire LA conférence agile en 2012, celle que les gens s’arracheront. Son critère de succès: les inscriptions sont complètes en 5 minutes même si le site de réservation ouvre à 6h du matin.

Enfin pour conclure avec les sessions de la journée, j’ai participé à une discussion sur Extreme Programming et BI, facilitée par Cedric Bourgeois. Avec les quelques participants présents, nous en sommes arrivés à la conclusion qu’en l’état le BI ne se prête pas bien à des pratiques comme le TDD, c’était prévisible. C’est avant tout une question d’intégration. Il reste néanmoins possible de faire des tests d’intégration automatisés et de les exécuter le plus souvent possible, plutôt que d’attendre la fin du cycle de fabrication de rapports BI.

La journée s’est terminée par un tour de salle où chacun a pu exprimer ce qu’il retenait de le journée. Les retours ont été dithyrambiques, Alexandre en a fait une synthèse sur son blog.

Formation Scrum Product Owner certifiante animée par Arlen Bankston les 12 et 13 décembre 2011.

Cette formation inclue les petits déjeuners, pauses cafés, déjeuners (restaurant La Cavalina), supports de cours, pokers cards, une copie de l’ouvrage « Scrum en action » de Guillaume bodet, l’abonnement à la Scrum Alliance et la certification Scrum Product Owner bien entendu.

Si cette formation vous intéresse ou que vous souhaitez de plus amples informations, n’hésitez pas à nous contacter au 01 53 89 99 99 ou par courriel (info@xebia-training.fr).

Xebia est ainsi fière, de mettre à votre disposition son contrat agile open source,  sur le site contrat-agile.org !

Ce contrat résultant d’une réflexion collégiale et de l’agrégation des différentes expériences de cabinets de conseil agiles, et d’un cabinet d’avocat spécialisé, propose aux donneurs d’ordres et aux prestataires, un cadre contractuel adéquat dans la mise en place de leurs projets informatiques.   

Soucieux de ne pas contredire la réalité du terrain et fort de notre propre expérience, nous nous sommes attachés à intégrer fidèlement les problématiques des directions achats, dans le respect total des valeurs agiles.

Visibilité budgétaire, engagement forfaitaire, évolution du périmètre fonctionnel, engagement et disponibilité de le MOA, priorisation par la valeur métier, sont autant de points d’achoppement, pour ne citer qu’eux, qu’il nous a fallu traiter pour aboutir à un contrat équilibré et pragmatique en tenant compte des contraintes de chacune des parties.

Attachée au partage de connaissances, Xebia a souhaité le rendre accessible à l’ensemble des acteurs de la communauté agile, sous Licence Creative Commons,  et vous invite donc à nous faire part de toutes vos suggestions à cette adresse : contact@contrat-agile.org.

Nous espérons par notre action, contribuer à la progression de la communauté dans ce domaine si exploratoire et complexe qu’est celui de la contractualisation agile.

Pour la troisième année consécutive Xebia sera présente à l’EPITA, jeudi 10 novembre, dans le cadre de la semaine annuelle de conférences technologiques, organisée chaque année dans les locaux de l’école.

Cette manifestation est toujours une occasion incontournable pour les étudiants de découvrir nos métiers et de rencontrer des professionnels de l’informatique. C’est Gilles Mantel, Chief Evangelist chez Xebia et fort de 10 ans d’expérience dans la gestion de projets agiles, qui ira cette année à la rencontre des étudiants. Il abordera un sujet très tendance, celui de la ludification du travail.

Partant du constat que les Serious Games prennent une place de plus en plus importante dans notre quotidien professionnel, notamment dans les organisations agiles, Gilles illustrera au moyen de cas concrets les apports de ce nouveau mode de travail. Il traitera aussi des éventuelles limites à y apporter.

En 3 semaines, 99 inscrits sur Meetup ! On peut déjà suivre l’activité sur Twitter. A cette première session, beaucoup de développeurs Java, quelques rubyistes et bientôt plus de développeurs .Net, car cette communauté s’adresse bien sûr à tous les langages.

Au programme, une proposition de la vision pour cette communauté puis une présentation renversante d’un invité surprise venu de Londres.

Bienvenue au PSCC

Cyrille Martaire l’organisateur de cette première session pense qu’il existe un fossé entre les user groups techniques (Java, Ruby, Scala, …) et les user groups moins techniques (Scrum, Lean, …). Où sont les groupes autour du TDD, du Clean Code, de la feature injection, du refactoring, des legacy challenges, etc. ? Il est vrai qu’il existe des groupes tels que les Duchess qui amènent cet esprit de communauté ou encore des événements comme les codes retreats et coding dojos qui mettent l’accent sur la technique plutôt que sur la technologie.

Cependant, pour Cyrille l’idée est de rassembler une communauté — donc sans pouvoir central — où chacun pourrait intervenir à tout niveau, pour expérimenter, pratiquer, mentorer, échanger et réfléchir à l’importance et à la diffusion de nos pratiques dans l’industrie. Lors de ces sessions, il n’y aurait pas de réponses toutes faites mais plutôt des solutions à penser ensemble. Les sessions pourraient s’organiser par exemple autour de round table discussions, de hands-on, de guest talks ou lightning talks et couvriraient des sujets aussi divers que notre future carrière en tant que codeurs ou tout simplement comment découpler son code.

Invité surprise

Ensuite nous avons assisté à une présentation sur le software craftsmanship de très haute qualité et pleine de vécu. Venu tout droit de Londres, le co-fondateur de la communauté londonienne du software craftsmanship, Sandro Mancuso, a touché et inspiré son audience.

Au quotidien, Sandro est consultant dans le système bancaire de la City, où depuis longtemps d’ailleurs les développeurs agiles pratiquant le TDD sont très recherchés. Le rôle de Sandro est de pair-programmer avec les développeurs de son plateau et ainsi de diffuser les pratiques et donc les bons réflexes du craftsman. Un rêve apparemment pour lui de pouvoir coder et de partager entre développeurs toute la journée. 

La transformation agile

Sandro nous rappelle que la transformation agile a commencé il y a maintenant 10 ans et que nous avons passé la plupart de ces 10 années à nous concentrer sur les personnes, leurs interactions, le team building, l’écosystème et que cela a pris le dessus sur les pratiques techniques.

Aujourd’hui malgré cette transformation agile nous avons toujours des bogues, des problèmes d’intégration et des urgences en production. C’est ce que Sandro appelle l’agile hangover. Il rappelle non seulement que les processus sont importants, mais que le produit lui même est finalement central. L’exemple de Toyota vient à l’esprit : des processus leans et bien rodés, mais voudriez-vous rouler dans une Toyota qui sortirait de la chaîne pleine de défauts?

Notre notion du temps

La plupart du temps semble-t-il, nous sommes sous pression et nous voulons pourtant avancer et finaliser nos développements. Que choisissons-nous alors ? Nous prenons des raccourcis. Nous avons, dit-il, une notion du temps erronée. Nous dépensons beaucoup d’énergie dans des cycles de déploiements d’artifacts contenant du code déjà bogué ou en essayant d’expliquer du code hérité lorsque nous savons qu’une pratique comme le TDD permet d’approcher le code légué, offre une boucle de feedback extrêmement rapide et réduit de façon drastique le nombre de bogues en production.

Souvent, nous oublions que des pratiques comme le test, le refactoring et le cleaning font partie intégrante de notre programmation quotidienne et que lorsque nous nous efforçons dans nos sprints à créer en parallèle de notre user story des tâches ou sous-tâches dédiées aux unit testing, refactoring, cleaning, code reviewing, en réalité nous ne faisons — en plus de dépenser de l’énergie inutilement dans Jira — que donner l’opportunité à notre product owner de les écarter, dé-prioriser, de les oublier ou pire de pouvoir les supprimer.

Pratiquer et convaincre

Nous sommes les seuls responsables en tant que codeurs pour garder notre système propre et testable. Et pour cela les moyens existent déjà. Ne serait-ce que les pratiques de l’extreme programming. Lors de cette séance, Sandro nous montre que ces pratiques sont indépendantes du contexte et donc implémentables dans 99% des situations. Il est possible alors de produire du code propre, testable et découplé. Le pair programming par exemple vous donne un retour instantané sur votre nommage (classes, méthodes, variables) et votre design (découplage, granularité, responsabilité, complexité).

Sandro insiste sur le fait que si l’on veut convaincre avec le craftsmanship, il ne faut pas débattre autour des pratiques mais plutôt montrer ce qu’elles apportent. Si votre manager ne comprend pas l’intérêt du collective code ownership ne lui expliquez pas comment cela fonctionne mais plutôt ce que cela va lui apporter. Il en va de même pour l’intégration continue.

Sandro a aussi beaucoup parlé de nos carrières et de l’importance de la pratique. Il dit faire 20 heures de pratique par semaine mais avoue que cela fait beaucoup et que tout le monde n’a pas la chance de pouvoir pratiquer autant. Chez notre employeur, il nous propose de voir tout code legacy non pas comme un poids mais comme un challenge. Un puzzle gigantesque à résoudre. Dans ce gigantesque puzzle, explique t-il, essayons de dégager d’abord les 4 coins, d’assembler par couleurs, de détecter des patterns, et de résoudre les problèmes petit à petit.

Finalement le craft c’est quoi

Le craftsmanship, c’est donc nous : développeurs, programmeurs, codeurs. Nous ne sommes pas de simples employés mais des professionnels exerçant un métier que beaucoup devraient nous envier. C’est aussi cette alliance productive que nous devons avoir avec nos clients et entreprises. Et c’est aussi une responsabilité, surtout dans la transmission du savoir et la préparation des générations futures.

Le software craftsmanship n’est pas une église et n’essaie pas de convertir mais plutôt de montrer par l’exemple. Ce n’est pas du beautiful code en veux-tu en voilà mais plutôt une façon continuelle d’ajouter de la valeur au produit.

Comme le résume Sandro : « Software craftsmanship is all about putting responsibility, professionalism, pragmatism and pride back into software development. » 

Bien sûr, ajoute Sandro, le craft n’est pas suffisant pour assurer le succès d’un produit, mais le manquement du craft pourrait bien être la principale cause de son échec. Et n’oublions pas que l’agilité et le software craftsmanship se complètent : les processus agiles nécessiteront toujours une excellence technique et une attitude professionnelle. 

Alors merci encore à Sandro et à Cyrille et souhaitons beaucoup de participations et une longue vie au PSCC.

J’ai commencé la journée par la session Obeya Kanban de Laurent Morisseau. L’obeya c’est le lieu de travail d’une équipe dans le jargon Lean, et donc c’est un terme japonais. Si vous vous intéressez un peu au sujet vous savez qu’on aime bien parler japonnais dans le Lean, non pas parce que ça fait plus intelligent mais parce que ça vient de Toyota (cela dit ça fait aussi plus intelligent lors de vos dîners en société).

Laurent nous présente dans sa session le contenu et la disposition des informations visuelles autour d’une équipe qui fonctionne en Kanban. Laurent nous détaille progressivement les différents éléments de ces supports visuels et, ce faisant, revient sur certains points de l’approche Kanban pour les expliquer. On s’aperçoit au final que toute l’approche se matérialise d’une manière ou d’une autre sur les murs de son Obeya, dans l’une des zones suivantes: la cible, le planning, la tendance, le planning micro, les indicateurs de performances, le suivi des problèmes. Laurent ne se restreint pas qu’à Kanban puisqu’il nous donne également des parallèles avec SCRUM et ce que pourraient être ces différents éléments visuels: la cible est la vision, la tendance est le suivi de la vélocité, le planning est le burndown produit, le micro planning est le tableau d’itération, etc. Au final, derrière le simple titre, la présentation était riche d’informations et couvrait un spectre beaucoup plus large. La partie sur la gestion de la performance était notamment assez musclée. Elle me parle dans la mesure où j’ai un bagage d’ingénieur qualité, mais je suis plus sceptique quant à la généralisation d’une approche de la performance aussi systématique. Malgré ce bémol, la présentation était pleine de conseils utiles. Je retiens particulièrement la conclusion suivante: le management visuel doit être simple et créer un flux d’apprentissage pour l’équipe. Laurent nous indique deux critères de validation d’un bon management visuel: tout peut être dessiné à main levé et les problèmes doivent être visibles.

Sur le deuxième créneau j’animais ma session désormais bien rodée sur le ROI de l’automatisation des tests. J’ai profité de l’occasion pour en faire un remaniement cosmétique important et la rendre plus visuelle.  Je remercie au passage la personne qui m’a prêté son PC car j’ai rencontré des soucis de compatibilité entre mon Mac et le projecteur de l’amphithéâtre.

Pour la dernière présentation de la matinée j’ai choisi la session de Fabrice Aimetti sur la gestion de portefeuille agile. Là-aussi, derrière ce titre assez court se cachait une avalanche d’information et de références. Outre la gestion de portefeuille, Fabrice a parlé de formalisation des user stories, de présence du Product Owner, de planification agile, d’atelier d’innovation, de story map. Ce que j’aime c’est que Fabrice prend un soin tout particulier à citer et afficher ostensiblement ses références. On y trouve d’ailleurs la présence de notre collègue Hollandais Serge Beaumont pour sa définition d’une user story « prête ». J’ai surtout retenu de la présentation de Fabrice une succession de petites expressions croustillantes picorées ça et là ou de sa propre création:

• une vision sans action est une utopie, une action sans vision est un cauchemar
• le cahier des charges est surtout un cahier décharge
• un manager est quelqu’un qui utilise les hommes pour accomplir un travail, un leader est quelqu’un qui utilise le travail pour accomplir les hommes
• Faites développer à des équipes agiles des produits qui méritent de l’être
• Un atelier est une réunion dans laquelle le livrable est fait en séance

J’ai commencé l’après-midi avec l’atelier Problem Solving de Regis Medina. Le principe était de travailler sur la bonne définition d’un problème et pas tellement de chercher à le résoudre en séance. Régis nous a distillé une démarche pour aboutir à un plan d’action. Nous avons appliqué cette démarche par groupe de 3 sur nos propres situations, chacun proposant un problème aux autres pour collaborer sur sa définition. Regis nous a fait successivement travailler sur:

• l’identification du problème
• la formalisation de ses impacts
• la recherche de la situation standard qui n’a pas été suivi
• et les actions à prendre pour observer concrètement les causes du problème.

Il est intéressant de constater que l’on part souvent sur de faux problèmes ou des problèmes mal formulés car découlant de notre interprétation personnelle d’une situation. La formalisation d’un problème est objective et doit se traduire en un écart chiffré entre une situation donnée et le point de vue d’un client. Cet écart est l’expression même du problème. Je retiens aussi la mise en application très concrète de la technique des 5 pourquoi: on va voir 5 fois ce qui se passe (on utilise ses pieds), ce n’est pas un questionnement rhétorique!

Dernière présentation de la journée avec la roue de Demming des projets agiles vue par Thierry Montulé. Et là attention, il fallait attacher sa ceinture, remonter sa tablette, éteindre son téléphone, et surtout brancher son cerveau.

La présentation est partie dans les strates atmosphériques des principes agiles. Lorsque Thierry vous lache sur le ton de la discussion des phrases comme « le respect est une posture d’humilité assertive », vous avez intérêt à ne pas prendre de notes ou twitter ces morceaux choisis au risque de se laisser décrocher rapidement. Au détours de cette présentation à la fois dense et simplement structurée, Thierry présente les valeurs du pragmatisme avec la métaphore d’une voiture: la communication est le volant, le respect est l’embrayage, le feedback est le tableau de bord, la cooperation est l’accélérateur. Il transforme ensuite le triangle de fer des projets classiques en une pyramide mettant en perspective la méthode, les hommes, la structure, et le client. Thierry termine enfin avec sa roue de Demming qui superpose les valeurs du pragmatisme avec celles des processus empiriques, le système PDCA et ses axes d’amélioration. Simple et pourtant inexplicable sans la présentation qui va avec.

Pour laisser mon cerveau se remettre, j’ai terminé ma journée avec des ateliers ludiques organisés par l’équipe d’Agile Nantes. J’ai notamment aimé l’utilisation des origamis pour comparer différentes méthodes des collaboration. Ce qui est intéressant c’est que ce support est déclinable en grand nombre et qu’on peut recommencer le même exercice avec différents pliages pour éviter l’effet d’apprentissage et se concentrer sur les techniques de collaboration. Je pense que cela conviendrait tout à fait pour servir de support à un coach retreat.

Une riche journée donc, et toujours le plaisir d’échanger avec des meneurs du mouvement agile: salutations à Oana, Fabrice, et Laurent. Le plaisir également de croiser Eric un ancien collègue d’une précédente vie professionelle où l’on essayait d’inventer l’offshore à la française. Eric, rejoins le mouvement agile

Au-delà du caractère spectaculaire de cet exemple, il est intéressant de noter que l’origine du dysfonctionnement réside dans un module développé pour une version antérieure de la fusée et devenu obsolète. Ce vestige de code, maintenu dans l’application sans être nécessaire pour son fonctionnement, est l’une des formes de ce que Ward Cunningham désigne sous le terme de dette technique.

A travers ce document, nous découvrirons en quoi la dette technique ralentit la productivité des équipes et nuit aux projets. Nous mettrons en évidence ses mécanismes sous jacents et les leviers d’actions dont nous disposons. Enfin, nous montrerons comment elle se gère au quotidien, par l’instauration de bonnes pratiques de développement et la mise en place d’outils, pour enfin aborder quelques stratégies complémentaires, mais essentielles pour venir à bout de la dette technique.

Télécharger le Livre blanc « Maîtrisez votre dette technique ».

Lundi et mardi prochain, les 3 et 4 octobre, se tiendra la seconde édition de la conférence SoftShake à Genève.
Cette conférence forte de 5 tracks en parallèles sur 2 jours, avec 50 speakers et pas loin de 60 sessions, cherche à fournir un cocktail d’expériences informatiques. C’est une conférence ouverte abordant des thèmes variés embrassant tout les thèmes de notre discipline. Les 5 tracks sont Java, Mobilité, Agile, Microsoft et Incubateur.

J’aurais le plaisir de jouer ma session: « Software Craftsmanship: en pratique » et vous trouverez d’autres sessions particulièrement alléchantes, auxquelles j’espère pouvoir participer, que j’ai piochées dans le programme :

• Clojure Values
• Devops et déploiement continu
• Hands-on Node.js
• DataCaching and DataGrid
• Kata In the Hat
• Marre des Frameworks ! Oui aux bons outils.
• MVC Development in the browser

J’espère pouvoir échanger avec vous sur place à Genève.

J’ai le plaisir d’avoir été sélectionné pour animer ma session traitant du retour sur investissement de l’automatisation des tests. Sous la houlette de Laurent Morisseau et d’une équipe d’organisateurs investis, cette étape s’annonce déjà comme une belle réussite, en espérant ne pas leur porter malchance avec cette prédiction enthousiaste. Le programme concocté pour l’occasion présente un bon équilibre entre sessions pour débutants et sujets avancés, présentations magistrales et ateliers. Le programme fait aussi la part belle aux principes de Kanban pour l’informatique.

De mon côté j’ai pour l’instant porté mon choix sur les sessions suivantes :

• Dessine moi une Obeya Kanban par Laurent Morisseau.
• Agile Portfolio par Fabrice Aimetti.
• Atelier résolution de problème par Regis Medina.
• Le projet agile – la roue de Demming des SI par Thierry Montule.

Les inscriptions sont toujours ouvertes et la participation aux frais reste très abordable.

Jour 2

Le deuxième jour a débuté avec une keynote de Bjarte Bogsnes portant sur le concept « Beyond Budgeting ». Bjarte est responsable de la gestion de la performance chez Statoil, ce n’est donc pas un conférencier technique ou agile. Il présentait ici les pratiques budgétaires appliquées dans cette multinationale Scandinave. Les concepts « Beyond Budgeting » cherchent à changer radicalement la façon dont sont gérés les budgets d’entreprises pour s’adapter à un environnement en perpétuel changement. Ces pratiques se basent sur la responsabilité des employés, et le suivi continu de l’alignement des dépenses avec les objectifs mais aussi les prévisions de l’entreprise. La nuance à saisir entre objectifs et prévisions est la suivante: un objectif est ce que l’on souhaite voir arriver, une prévision est ce que l’on pense qu’il va arriver. Un exemple de pratique dont nous parle Bjarte est d’utiliser la transparence totale plutôt que la constitution d’un budget pour les déplacements. Le discours de Bjarte sonne comme du pain béni pour l’audience présente à la conférence, parmi laquelle on trouve de nombreux coachs agiles. Ce qu’il faut souligner c’est que ces pratiques budgétaires supportent parfaitement une approche agile des projets informatiques mais qu’à aucun moment Bjarte n’utilise le jargon agile de SCRUM, XP, ou Lean. La terminologie utilisée par Bjarte est purement financière et comptable, son discours obtiendra certainement beaucoup plus de crédit chez les managers que celui des agilistes. Bjarte est l’auteur du livre Implementing Beyong Budgeting, et participe  à un groupe de travail sur le sujet, la Table Ronde Beyond Budgeting.

La journée a continué avec les présentations de 30 minutes en parallèle. Sur le premier créneau j’ai choisi d’assister à un Alien Talk, c’est à dire une présentation qui ne porte pas sur l’informatique mais qui alimente notre réflexion sur l’ingénierie logicielle. Cette présentation traitait de la construction d’un véhicule 100MPG, 100 Miles Per Galon, dans le cadre du concours XPRIZE-Automotive. Thorsten Kalnin nous a expliqué comment l’équipe WIKISPEED a construit son prototype en l’espace de 3 mois avec une équipe distribuée géographiquement et en utilisant des pratiques issues de l’ingénierie logicielle et de l’agilité: TDD, intégration continue, conception orienté objet, itérations, rétrospectives. Voilà une présentation extrêmement intéressante à l’heure ou l’informatique cherche à s’inspirer de plus en plus de l’industrie automobile; elle nous prouve que l’inverse a également du sens et que les pratiques agiles ne sont pas une fantaisie de programmeurs barbus et ventripotents mais de solides pratiques d’ingénierie qui favorisent le succès des produits développés. Ces simples faits parlent d’eux-même: le véhicule de WIKISPEED a terminé finaliste de l’épreuve et a passé les 5 étoiles au crash test.

J’animais ensuite ma présentation sur le deuxième créneau de la journée. J’ai passé la soirée de la veille à bien répéter, d’une part parce que je la faisais pour la première fois en anglais après Agile France 2011 et Scrum Day 2011, et d’autre part pour s’adapter au créneau de 30 min. Vous retrouverez le support sur SlideShare. Les retours ont été à nouveau positifs. Il était d’ailleurs simple de se faire une idée de l’opinion de l’audience: à la fin de chaque présentation les participants étaient invités à donner leur appréciation en positionnant un post-it sur la porte de la salle, graduée pour l’occasion d’une échelle verticale de 1 (décevant) à 5 (très bon). Cette notation visuelle appelée « feedback door » permettait de saisir en un coup d’oeil le sentiment de l’audience.

A peine le temps de souffler, j’ai couru attraper la présentation de Claudio Perrone sur la résolution de problème A3, une technique issue du Lean Management. Ce sujet est plutôt récurrent dans les conférences agiles et j’y allais avec l’intention de me rafraîchir les idées sur cette technique que je n’ai pas encore eu l’occasion de mettre en pratique. La présentation de Claudio m’a positivement étonné par son pragmatisme mais aussi sa capacité à focaliser l’audience avec des slides imagés marquants les esprits. Il faut souligner que Claudio dessine lui-même les images de ses slides. Je vous conseille vivement de consulter sa présentation qui parle quasiment d’elle même. J’ai appris beaucoup plus sur le A3 que tout ce à quoi j’avais assisté précédemment.

Sur le dernier créneau de la matinée j’ai assité à la présentation de Jurgen Appelo, très sobrement nommée Comment changer le monde. Jurgen est un peu le père spirituel du réseau ALE et de la conférence ALE2011, c’est sous son impulsion début Février que s’est formé le réseau. J’allais à cette présentation en trouvant le sujet un peu ambitieux, limite prétentieux, et j’en suis sorti avec l’intime conviction que changer, peut-être pas le monde, mais son environnement repose sur des principes simples à appréhender. La présentation m’a particulièrement captivé par l’alternance entre modèles théoriques et exemples pratiques de mise en oeuvre. Jurgen était également très humble dans son discours en confessant s’être trompé pendant 15 ans dans sa façon de vouloir changer les choses et de n’obtenir des résultats que depuis 2 ans, après avoir changé son approche personnelle. Jurgen profitait de la conférence pour lancer son nouveau livre Management 3.0 qui présente en détail son approche du changement.

Le bilan de cette matinée fut donc très positif. Je l’ai vécu comme le point d’orgue de la conférence. L’après-midi démarrait à nouveau avec une série de Lightning talks. Parmi ceux ayant marqué l’audience et provoqué des applaudissements fournis :

• Une spectaculaire métaphore entre la transition vers l’agilité et la consommation d’un hamburger. Présenté comme ça on ne voit pas bien le rapport, et pourtant le présentateur a mis en avant tous les ingrédients nécessaires à la transition: implication cross-fonctionnelle, rythme soutenu, actions à tous les étages. Simplement brillant, les slides sont ici.
• Une présentation sur l’importance du rôle de facilitateur dans les rétrospectives, garant de l’engagement individuel et de la qualité des échanges.
• Un lightning talk provocateur dénonçant les coachs agiles et la dissolution des valeurs originales de l’agilité.
• Une proposition digne d’intérêt: célébrer les échecs tout autant que les victoires. Le speaker nous propose d’inviter nos collègues à partager un « Failure Cake » chaque fois que nous échouons quelque part, car d’une part il est difficile d’en vouloir à quelqu’un qui vous offre un gâteau et d’autre part les échecs nous font apprendre beaucoup plus que les victoires. Le failure cake est l’occasion de déclencher une rétrospective informelle de ce qui n’a pas marché.

L’après-midi a continué avec les sessions open-space, dont vous trouverez certains comptes-rendus sur google spreadsheet. J’ai beaucoup utilisé la loi des deux pieds car finalement peu de sessions ont réellement mobilisé l’énergie des participants et débouché sur des résultats concrets. J’ai donc cherché à éviter au maximum les sessions du type « discussions de salon de thé » ou encore « slides de ma présentation qui n’a pas été retenue au programme ». Je constate à quel point la qualité de l’animateur est importante pour la réussite d’une session open-space. Certaines sessions ont été réellement inspirantes et appellent à l’action, je retiens en particulier la session sur les story maps brillamment animée par Eelco (encore lui), et d’autres réellement ennuyeuses et stériles. Je reviendrais sur ce point lors d’un prochain billet.

La journée s’est terminée par l’organisation d’un repas basé sur le principe de « diner avec un inconnu ». Les organisateurs avaient réservé des tables dans une quinzaine de restaurants de Berlin et, depuis la veille, les participants choisissaient le lieu où ils souhaitaient diner en prenant soin d’éviter de s’inscrire par groupes de connaissances. L’objectif était bien sûr de favoriser encore les échanges et développer son réseau personnel. De l’avis général le concept a fonctionné à merveille, avis que je partage également. Le « networking » est un aspect important d’une conférence mais il est souvent rendu compliqué par l’enchaînement des sessions. Le diner avec des inconnus était un moyen simple de réserver un créneau dédié au networking dans une ambiance propice aux discussions. Pour les plus courageux, la soirée s’est prolongée au bar de l’hôtel où les discussions à bâtons rompus sur les différences culturelles étaient de mise.

Jour 3

Ce dernier jour de la conférence m’a semblé plutôt en retrait par rapport aux deux premiers. Je ne sais pas si cela était du au possible essoufflement des participants après 2 jours de réflexions ininterrompues, au moindre intérêt des présentations sur le créneau matinal, ou encore à l’altération du format des lightning talks qui n’étaient plus libres mais devaient tourner autour du thème « Comment prolonger la structuration du réseau Européen après la conférence ». Dans tous les cas je ne retire pas grand chose de ce troisième jour, excepté la rétrospective massive à 200 personnes.

Mes sessions de la matinée:

• Transformation agile à grande échelle chez Nokia-Siemens: un retour d’expérience plutôt décevant, principalement car il ne tenait pas sur le créneau de 30′, le meilleur était sûrement après ces trente premières minutes de généralités et de satisfecit pour la société de conseil qui a menée la transformation.
• Dépasser les résistances à l’auto-organisation: quelques morceaux intéressants mais beaucoup de généralités et un manque d’exemples concrets, les slides sont ici.
• Open-space « Comment démarrer avec Beyond Budgeting »: les discussions ont plutôt tourné autour de « comment amener les managers à ALE2012, ou toute autre conférence agile ».

La rétrospective était animée par Ken Power. Il a divisé l’assistance en petits groupes de 8 personnes et nous a fait utiliser successivement la technique du « starfish » et la technique du « speed boat ». La première est basée sur la génération de 5 types de souhaits par rapport à un événement donné: « moins de « , « plus de », « arrêter », « essayer », « continuer ». Ces souhaits sont rassemblés sur un espace divisé en 5 parties en forme d’étoile de mer, voir la photo. La deuxième est issue des Innovation Games de Luke Hohman. Elle consiste à s’imaginer un bateau de course ralenti par des ancres, le bateau étant l’événement ou le produit critiqué, et les ancres illustrant les points qui semblent ralentir la performance du produit ou la réussite d’un événement. L’alternance entre ces 2 techniques a permis de générer rapidement un grand nombre de commentaires.

J’ai quitté la conférence avant la keynote finale pour attraper mon avion. Si vous voulez aller plus en détail dans les sujets et le déroulement de la conférence, les organisateurs rassemblent tous les articles de blogs, photos, et matériels générés pendant la conférence sur une page dédiée.

Le format de ALE2011 se veut « unconference », c’est à dire l’opposé d’une conférence avec présentations magistrales et participants passifs. Une « unconference » est basée sur l’immersion et l’engagement au travers de sessions ouvertes dont les sujets sont proposés par les participants. Le programme de ALE2011 a été conçu pour alterner différents types d’échanges:

• Le matin est consacré à des présentations magistrales mais sur un format très court de 30 mn, il y a une douzaine de sujets par matinée avec une keynote d’introduction. J’ai le plaisir de présenter un sujet le 2è jour.
• Le début de l’après-midi commence avec une série de lightning talks de 3 mn chacun, c’est un format très dynamique qui permet de décrire de nouvelles idées ou d’affirmer une opinion sans avoir à la justifier. Les particpants ont tous proposé un sujet en amont de la conférence et auront l’occasion de le présenter aux autres sur l’une des 3 journées.
• Enfin le reste de l’après-midi est consacré aux échanges en format Open-Space Technology: des groupes d’échanges se forment sur la base d’un agenda créé spontanément et avec totale liberté d’aller et venir entre les groupes. Cette liberté de mouvement encourage des comportement de butineurs et polinisateurs.

Cette première journée a commencé avec une keynote de Rachel Davies dont vous trouverez un compte-rendu en anglais sur le blog de Markus Gartner. Vous trouverez également une interview video de Rachel ici.

Sur le premier créneau j’ai choisi la session des organisateurs qui présentaient la façon dont ils ont travaillé pour mettre sur pied la conférence en un temps record sans jamais se recontrer physiquement. J’y assistait pour avoir un retour d’expérience d’un projet distribué avec des objectifs ambitieux. Je retiens plusieurs idées intéressantes:

• Une idée de départ plus délirante que réellement sérieuse: faire une conférence en Europe avec les propositions de sujets refusées à Agile2011 (on vous en parlait dans la dernière RDP), il faut croire que les déçues étaient nombreux car l’enthousiasme généré a transformé cette idée en une réalité.
• Une organisation Lean et Agile sans point de contrôle, les organisateurs ont ainsi mis en place des « sofas » plutôt que des « chairs » pour prendre en charge les différents aspects de l’organisation. Un sofa est une équipe auto-organisée sans responsable.
• Une série d’outils favorisant le travail distribué: Skype et Googledocs pour le travail à distance, LinkedIn pour l’activation du réseau, et Twitter pour recueillir immédiatement le feedback des participants potentiels.

J’ai ensuite assisté à une présentation très dynamique de Angel Medinilla, coach espagnol, sur l’inutilité des estimations. Un sujet polémique qui obtient de plus en plus de résonance dans le monde agile. La présentation avait le mérite de s’appuyer sur des mises en pratique d’une approche aussi radicale. J’y ai retrouvé certaines techniques que j’utilise moi-même pour la planification mais sans aller jusqu’à supprimer les estimations. La présentation est en ligne. Pour résumer l’esprit en une phrase: commencez par faire juste ce qu’il faut d’estimation, puis réduisez progressivement le temps que vous y passez, pour finalement les supprimer totalement. Angel a également fait un parallèle intéressant avec Kanban qui n’est pas basé sur les estimations mais sur des niveaux d’engagements de service en fonction du nombre d’éléments à développer.

Pour finir la matinée j’ai choisi la présentation de Vaidas Adomauskas traitant de la gestion d’un produit lorsque plusieurs équipes travaillent dessus. Vaidas a fait un retour d’expérience sans faux semblants sur l’organisation d’équipes par composant technique et le choix du Product Owner. J’ai aimé l’approche pragmatique qui consistait à choisir le PO parmi l’équipe de développement au démarrage du fonctionnement en agile, ce qui ferait hurler les puristes, puis à progressivement former le métier pour qu’ils s’approprient le rôle. La présentation est en ligne. J’ai discuté plus longuement avec Vaidas en fin de journée sur ses techniques de planification des user stories impactant plusieurs équipes. Son approche est limpide: lorsqu’une story impacte plusieurs équipes, le scrum master de chaque équipe, ou un membre désigné, se réunissent en amont du sprint planning pour que le Product Owner présente la story et la valeur associée. Ensuite les équipes s’organisent entre elles pour découper et se répartir le travail, le Product Owner ne décide pas quelle équipe va faire quoi. L’intégration est faite en cours d’itération et chaque équipe teste la user story dans sa totalité et pas seulement le bout qui lui est alloué. Auto-organisation, pilotage par la valeur, intégration continue, partage de la vision, tout y est! C’est simple comme bonjour et pourtant cette difficulté de gérer les backlog d’équipes collaborant sur un même produit revient régulièrement.

Pour information, les sessions sont toutes filmées et nous pourrons les visionner dans quelques temps.

Après les lightning talks en début d’après midi, nous avons démarré les propositions de sujet pour les discussions open space. J’ai proposé un sujet sur les déclinaisons européennes de l’agilité: les facteurs culturels induisent-ils des différences dans les obstacles rencontrés? Malheureusement le créneau prévu a coïncidé avec l’ouverture du buffet final et la discussion a tourné court par absence de participants (bière 1, Gilles 0). Un peu plus tôt, avant la ruée vers le buffet donc, les discussions auxquelles j’ai participé ne m’ont rien apporté de très nouveau:

• Déploiement continu: principalement une présentation des principes mais rien de concret.
• Visualiser le code legacy: quelques bonnes idées de métriques comme compter le nombre de changements éffectués sur le code pour identifier les parties les plus fragiles.
• L’entreprise agile, session facilitée par notre collègue Néerlandais Eelco: j’ai attrapé cette discussion en cours de route et elle tournait alors au débat philosophique, dommage le début avait l’air intéressant. Vous pouvez visionner une interview d’Eelco sur ce sujet d’Entreprise Agile.
• Histoires et solutions des obstacles à l’agilité: là aussi j’ai rejoins en cours de route, quelques échanges intéressants, même si cela tourne parfois en débat du type « ma transformation agile est plus grosse que la tienne ».
• Retrospective des conférences Bathtube, un format de conférences virtuelles en soirée: les actions d’amélioration portent sur l’infrastructure et la responsabilité tournante de l’organisation

N’hésitez pas à suivre le hashtag #ALE2011 sur Twitter, nous sommes plusieurs à relayer les morceaux choisis des différentes présentations et discussions.

Comme l’explique Daniel Pink dans son excellent livre La vérité sur ce qui nous motive, ce qui fait que nous sommes impliqués dans notre entreprise, dans notre travail, ne dépend pas principalement de récompenses financières.

D’après lui, les trois véritables facteurs qui ont un réel impact sur la motivation sont :

• L’autonomie
  

  Notre « paramétrage par défaut », c’est l’autonomie et l’indépendance. Malheureusement, les circonstances -entre autres des notions périmées de management- concourent souvent à changer ce paramétrage et à faire baisser notre motivation intrinsèque. Pour favoriser la motivation intrinsèque et les bonnes performances qu’elle permet de réaliser, la première condition est l’autonomie. Les entreprises qui permettent à leurs salariés d’être autonomes, parfois de façon radicale, sont plus performantes que leurs concurrents.

• La maîtrise
  

  La maîtrise obéit à trois règles particulières :

  • C’est un état d’esprit : elle requiert la capacité d’envisager ses propres possibilités comme étant non pas finies mais infiniment améliorables.
  • La maîtrise suppose des efforts, des difficultés et une pratique délibérée.
  • La maîtrise est impossible à atteindre entièrement, si bien qu’elle comporte à la fois un coté frustrant et un côté attirant.

   

• La finalité
  

  Il est dans la nature humaine de rechercher la finalité, c’est-à-dire de trouver un sens à ce que l’on fait, un but qui dépasse notre propre condition. Or les entreprises ont longtemps considéré la finalité comme accessoire, comme un élément souhaitable tant qu’il n’interfère pas avec les choses importantes. Cette situation est en train de changer, en partie grâce au vieillissement des baby-boomers qui se retrouvent confrontés à leur condition de mortel. Dans les organisations, ce nouveau « motif de finalité » s’exprime de trois manières : sous forme d’objectifs de finalité dans lesquels le profit est un moyen, sous forme d’un discours qui met l’accent sur autre chose que l’intérêt personnel, et sous forme de mesures pour permettre aux salariés de trouver par eux-mêmes du sens à ce qu’ils font.

Inspiré par la lecture de ce livre, je vous propose d’adapter l’activité classique de rétrospective, XP Radar, au thème de la motivation.

Déroulement de l’activité

L’activité va permettre à chaque membre de l’équipe de déterminer son positionnement sur chacun des trois points, vus ci-dessus, et ainsi de trouver des axes d’actions pour améliorer la motivation de l’équipe.

Chaque membre de l’équipe répond à chacune de ces questions en attribuant de 0 à 10 points par question (10 étant une réponse optimale) :

Autonomie

Maîtrise

Finalité

Cette liste n’est en aucun cas exhaustive et devra être adaptée au contexte.

Résultat

A partir des moyennes de chaque membre, on peut ainsi tracer un radar pour chaque personne, puis un radar global pour l’équipe. Voilà ce que l’on peut obtenir :

Ce radar permet ainsi de facilement identifier les axes sur lesquels l’équipe va essayer d’intervenir pour accroitre la motivation et par conséquence sa productivité. Il est aussi intéressant de regarder individuellement les résultats afin de trouver des raisons de blocages plus individuelles.
Le plus important, comme dans toute rétrospective, est de déterminer un ensemble d’actions suite à l’analyse des résultats. En fonction des axes faibles identifiés, l’équipe sera amenée à définir une ou plusieurs idées d’amélioration. On pourrait ainsi définir :

• Organiser des formations interne à l’équipe autour d’un sujet.
• Passer une journée avec les utilisateurs pour mieux comprendre leur métier.
• Travailler le sens des user-story avec le Product Owner.
• Laisser plus de liberté à chaque membre dans le choix de ses tâches.
• Ne plus cloisonner les tâches en fonction des compétences spécifiques à chacun.
• Faire remonter au management les besoins d’autonomie de l’équipe.
• etc.

A noter, cette exercice sera plus efficace s’il est réalisé en compagnie de personnes du management afin de partager les différents points de vue, de discuter et de les sensibiliser directement.

Aller plus loin

Que l’on ne se méprenne pas, l’argent est, bien entendu, une condition nécessaire à la réalisation de notre travail. Nous ne travaillons pas par pure générosité, et insuffisamment rémunéré (en comparaison des salaires à l’intérieur et à l’extérieur de l’entreprise), nous sommes en général très vite démotivés.

Cependant, d’après les études, pour tous les travaux nécessitant de la réflexion, de la créativité, la carotte financière peut être négative plus que stimulante. En effet, elle aura tendance à tuer la créativité car elle pollue l’esprit de celui auquel elle est destinée. De plus, elle aura aussi pour effet de limiter cette créativité car elle arrive généralement avec un cadre correspondant aux critères de satisfaction du généreux donateur de la carotte.

Afin de creuser le sujet de la motivation, je vous conseille la lecture du livre de Daniel Pink, ou sinon le visionnage de la très bonne conférence donnée à TED.

André Comte-Sponville a également donné une conférence passionnante à l’université du SI intitulé : Sens du Travail, bonheur et motivation. Je vous encourage vivement à la regarder.

A la fin de la formation, les stagiaires maîtriseront les thèmes suivants :

• Le Lean, le système « Pull » et Kanban
• La cartographie du réseau de valeur
• Le « Work in progress » (WIP)
• L’implémentation de différentes classes de service
• La négociation des accords de niveau de service (Service level agreement) avec le client
• Mettre en place culture d’amélioration continue (Kaizen)
• Mettre en pratique les théories d’ingénierie industrielle au développement logiciel
• Indentification et maitriser les goulets d’étranglement
• Comprendre les coûts de transaction et coordination dans le processus Kanban
• Définir la cadence de livraison d’un système Kanban
• Utiliser les métriques et le reporting pour une amélioration continue

Pour ceux qui ne le connaissent pas, David est l’un des fondateurs de la mouvance agile à travers son implication dans le développement du processus « Feature Driven Development ». Sa démarche repose en parti sur une synergie du modèle CMMI avec les méthodes Lean et agile. David est l’auteur de « Agile Management for software engineering- Applying the theory of constraint for business results » ainsi que « KANBAN, Successful Evolutionary Change For Your Technology Business ».

Si cette formation vous intéresse, n’hésitez pas à contacter notre équipe commerciale au 01.53.89.99.99 ou en visitant notre site xebia-training.fr.

• Date : 23 Juin 14h00.
• Lieu : Hôtel Scribe, 1 rue Scribe, Paris 9ème.
• Consulter le programme et s’inscrire.

Distance entre client et prestataire, différences culturelles, barrière de la langue, manque de visibilité et de contrôle, turn over élevé, compromis sur la qualité sont autant de freins à l’adoption du modèle Offshore pour les DSI françaises.

Ce séminaire tentera d’expliquer comment le modèle d’ingénierie agile distribué, fruit d’une longue expérience, proposé par Xebia et reconnu par la communauté agile internationale peut supprimer ces obstacles et résoudre l’équation coût / qualité / adéquation aux besoins métiers.

Après une présentation de ce modèle par Anurag Shrivastava et Luc Legardeur, respectivement Directeur Général de Xebia India et Président de Xebia France, deux entreprises témoignent : Plastic Omnium et la Société Générale CIB.

Programme

• Café d’accueil.
• Introduction par Luc Legardeur.
• Craintes, espérances et réalités du modèle Offshore par Anurag Shivastava (en anglais).
• Témoignage de Plastic Omnium par Patrick Anfossi (Responsable des Systèmes d’Information).
• Pause
• Le modèle ScrumShore de la Société Générale CIB par Laurent Sarrazin (Head of IT Offshoring Solutions).
• Questions & Réponses

Dans l’attente d’avoir le plaisir d’éventuellement vous y rencontrer.

Robert Martin est venu distiller une session de formation Clean Code les 20 et 21 avril derniers dans les locaux de Xebia Training.

Simon Caplette a fait un retour de cette session sur le blog de Xebia. Une autre session de formation est prévue en novembre.

Nous avons profité de sa venue pour lui poser quelques questions sur les thèmes qu’il aborde.

Avec près de 35 ans d’expérience, Robert Martin est une des figures emblématiques du monde du développement logiciel agile. Il est l’auteur de plusieurs ouvrages et articles sur le « Software Craftsmanship » ou comment développer un logiciel dans les règles de l’art. Il est notamment l’auteur de : «Clean Code: A Handbook of Agile Software Craftsmanship». Il maintient un blog dans lequel il aborde le thème du Clean Code.

Cette année, 5 Xebians vous feront partager leurs expériences et leurs pratiques :

• Jean-laurent De morlhon : Software Craftsmanship: en pratique.
• Gilles Mantel : Automatisation des tests : le mythe du ROI.
• Katia Aresti et Xavier Renaudin (Valtech) : 10 ans après… Ma première expérience agile.
• Nicolas Jozwiak : Au secours, pourquoi ma vélocité n’augmente-t-elle pas ?.
• Nathaniel Richand : Pratiques avancées de tests.

Retrouvez le programme complet et Inscrivez vous !

Pendant 2 jours, se sont succédés conseils pratiques, prises de conscience (« aha… »), analogies originales, discussions sur l’industrie à l’heure du repas, randori TDD, kata, coding dojo, décortication minutieuse de classes, effacement de nombreuses lignes de code inutiles et ses fameuses diversions scientifiques (de la mitochondrie au réchauffement du soleil). Tout ça saupoudré d’une expérience de 40 ans dans l’industrie logiciel aux Etats-Unis.

Instants choisis.

Clean code

Dans l’optique d’un code propre, Uncle Bob a rappelé que la première mission d’un programmeur est de communiquer à travers son code. Nous avons passé aussi du temps à décortiquer, de façon plus poussée que dans son livre Clean Code, des classes (notamment org.jfree.date.SerialDate). Nous avons cherché toute trace de duplication ou de répétition d’information (code, commentaires, javadoc, licences, …) et les avons supprimés. Et quand on cherche on trouve !

Ensuite, il y a eu débat ouvert sur le rôle des codings standards dans une équipe de développement. Pour Robert Martin, le document qui rassemble les standards d’écriture du code c’est le code lui même. Ainsi un nouveau développeur sur le projet étudie le code pour savoir comment l’écrire. Un simple fichier de configuration IDE suffit pour les problèmes de formatting. De la même façon, M. Martin explique qu’il n’utilise pas forcément Checkstyle ou alors avec une configuration vraiment minimale, car le fait de forcer la propreté du code n’encourage pas à entretenir de bonnes pratiques. Appliquer bêtement les règles juste parce que l’outil remonte des violations, sans parcimonie, n’est pas une bonne solution.

Refactoring

Une question qui revient trés souvent a ensuite était soulevée : que faire dans le cas ou l’on se retrouve devant du code legacy spaghetti ? On a hérité du produit et l’on doit le faire évoluer.

Dans la salle quelques suggestions : « On pourrait tout refaire ? ». Et Uncle Bob de répondre « Non. Pourquoi ferrait-on mieux cette fois-ci ? ». Un autre lance : « On pourrait faire des sprints de refactoring ? ». Un autre « non » retentissant de la part de Bob. Il explique alors qu’il faut accepter le fait que l’on se retrouve face à une montagne de mauvais code et qu’il faut le nettoyer. Il ne faut pas que le refactoring soit sur l’agenda du sprint, il faut que ce soit un travail de continuous cleaning et de continuous refactoring. Cela implique que chaque développeur en connaisse les pratiques.

Uncle Bob résume par : « The only way to go fast is to clean at the same time! ». Il a donné pour cela une bonne analogie : celle du Sushi chef. Une fois que le Sushi chef vous présente son sushi fraichement assemblé de main de maître, observez son espace de travail. La planche à découper est immaculée et le chef est prêt à recommencer un autre sushi.

Toujours sur les pratiques du refactoring et donc de la détection de code smells, on a eu droit à une trés belle démonstration du côté diabolique du switch statement. On sait tous que le switch statement est fragile et qu’il est facile d’y introduire des bogues. Uncle bob nous indique également qu’il entraîne des couplages dans les déploiements d’artefacts en empêchant le polymorphisme. Tout un programme et peut être le sujet d’un prochain article d’ailleurs, d’autant que lors de cette démonstration nous avons parcouru l’histoire des types de langage (Structuré, Fonctionelle et Orienté Objet) et que les ramifications des raisons sont structurelles.

Test Driven Development

M. Martin a avancé un bel argument pour le TDD. Imaginez une salle remplie de développeurs pratiquant tous le TDD. Choisissez un développeur au hasard. Faites tourner son code. Tous ses tests passent. C’est à dire que dans cette salle tout code à n’importe quel moment (à un intervalle de temps minimal prés) fonctionne selon les specifications. Puissant le concept, non ?

Robert Martin a illustré l’importance de la couverture des tests avec son produit Fitnesse qu’il développe avec une petite équipe. Fitnesse a une couverture de test de 96%. Impressionnant. Pour toute évolution du produit il explique : « I ship it when it is green! ». Comprenez donc que Fitnesse est mise à disposition de la communauté avec les nouvelles fonctionnalités simplement lorsque les test passent. Et Robert ajoute qu’il ne fait même pas tourner l’application, seulement les tests !

Ensuite sur la question d’écriture d’une méthode de test, il est toujours bon de rappeler la règle des 3 A(s) :

• Arrange (préparation des objets et mocks pour le test)
• Act (appel de la méthode à tester)
• Assert (lignes d’assertions)

Le nombre d’assertions dans la méthode n’est pas important mais un test doit tester une fonctionnalité et une seule. Les assertions doivent donc rester dans un groupement logique.

Aussi il a presenté une façon d’écrire la méthode de test qui est assez concise. En voici un exemple:

public void givenVipUser_returnAccessRights()

Dans le cadre du TDD, nous avons abordé la notion de principe de priorité de transformation. Il s’agit d’une technique qui aide à trouver la bonne transformation à faire à son code pour qu’il passe un nouveau cas de test. Vous retrouverez l’essentiel de la description de cette technique dans ce billet de blog : the transformation priority premise. L’avenir pourrait être une série de raccourci-clavier nous suggérant les transformations à faire dans notre code…

Pragmatisme

Son côté pragmatique est ressorti lorsqu’il explique que Fitnesse n’utilise pas de base relationnelle car il n’en a jamais eu besoin. Au départ, pendant la phase de développement initiale, la persistence se faisait en mémoire, puis l’équipe est passée à de la persistence sur le système de fichiers. D’après Bob, un seul client a étendu Fitnesse pour utiliser une base MySql – grâce aux mécanismes d’extensions de Fitnesse. La raison de cette extension est que la DSI de ce client ne permettait pas de persistence sur le système de fichiers !

Une pratique qui lui tenait particulièrement à coeur, et qu’il nous a démontré sur un projet assez simple de legacy, est qu’avant de toucher ou même de regarder le code de production, il faut nettoyer et améliorer les tests existants si il y en a. C’est seulement ensuite, une fois que les tests sont de haute qualité, que le code peut être étudier et modifier.

Sur la question du defensive programming (assertions dans le code de production, null checking, etc), Robert Martin explique qu’il comprend cette procédure pour les APIs publiques. Cependant, faire du defensive programming dans votre propre système d’entreprise n’a pas forcément de sens. Robert observe qu’à chaque fois qu’il a vu du code en style defensing programming en entreprise, c’est que l’équipe n’écrivait pas de tests unitaires.

Conclusion

Il serait difficile de résumer tout ce qu’il s’est passé en 2 jours d’atelier. Heureusement, le craftsmanship et les pratiques associées sont accessibles à tous à travers les rencontres, le web et les livres. Cependant, il est toujours appréciable d’observer la pédagogie, la verve et l’argumentation souvent implacable de quelqu’un dont la façon de coder à radicalement changé après une courte session de TDD avec Kent Beck.

Ceci est une fiction. Toute ressemblance avec des personnes existant ou ayant existé serait totalement fortuite.

Palais de justice de Paris, lundi 21 mars.

Une fois n’est pas coutume, des développeurs sont assis sur le banc des accusés! Ils sont inculpés de faire perdre des millions d’euros à nos chères compagnies du CAC40 en écrivant du code voué à crouler sous son propre poids.

Mr Tedd, praticien du Test Driven Development, est aujourd’hui jugé ainsi que quelques uns de ses collègues : Mr Whatever, Mr Guru, Mrs Clickaway et Mr Testafter.

Prévoyant et confiant, il sera défendu par son avocat : Maître Darrow. Ils ont convenu ensemble de la stratégie à adopter: il faudra pointer du doigt les mauvaises habitudes souvent utilisées et mettre en avant les bonnes pratiques qu’il a appliqué tout au long des projets qui lui ont été confiés.

L’audience est ouverte

Le Président, Mr Beck, ouvre la séance en rappelant les chefs d’accusations aux jurés:

• Le code applicatif contient trop de bugs
• Le code applicatif n’est pas testé
• Le code applicatif est pour la plupart du temps incompréhensible et reste trop volumineux pour le nombre de fonctionnalités
• La modification et l’amélioration du code applicatif existant est trop risqué à entreprendre

La parole est à la défense. Maître Darrow, soucieux de capter l’attention de son audience, rappelle le contexte:

Nous sommes en 2011. Dans les missions dans lesquelles mon client, Mr Tedd, intervient, écrire du code représente 80% de son temps. Ce code capture des règles métiers plus ou moins complexes et qui évoluent dans le temps. Visuellement son travail se traduit souvent par ce qu’on appelle un front end sur lequel un utilisateur tel que vous et moi pouvons interagir. Un bon exemple serait un site de réservation de billets de train au niveau Européen. Vous voyez donc, Messieurs et Mesdames les jurés que l’enjeu est de taille, l’erreur coûte chère et qu’elle n’est donc pas acceptable.

Aujourd’hui, je vais vous démontrer que mon client, Mr Tedd, adopte les pratiques adéquates pour rendre son code fiable, évolutif et pérenne.

Laissez-moi d’abord vous présenter quelques types classiques de développeurs. Si je n’enlève rien aux connaissances techniques et aux talents d’ingénieurs de ces personnes, je leur reprocherais cependant une attitude trop laxiste quant à la fiabilité et la pérennité du code qu’ils soumettent mais aussi une négligence au regard des méthodes qui permettraient d’améliorer considérablement la qualité globale des projets auxquels ils participent.

Permettez-moi de commencer par le cas de Mr Whatever.

Mr Whatever

Tous les regards se tournent vers ce grand gaillard assis au bout du banc des accusés.

Mr Whatever, si vous me permettez de vous citer, vous m’avez dit :

« Moi je fais juste confiance à mon code. Il compile c’est donc qu’il fonctionne. »

Je pense que Mr Whatever n’est jamais resté assez longtemps dans les entreprises pour lesquelles il travaillait pour savoir que son code en production posait plus de problèmes qu’il n’en résolvait. Je rappelle pour les profanes dans l’assistance, que la production est la plateforme exposée au grand public donc aux vrais utilisateurs. C’est dans cet environnement que la charge sur le système se révèle soutenue et que, potentiellement, tous les chemins possibles dans le code écrit sont réalisés en concurrence !

Le problème de Mr Whatever est qu’il ne sait réellement si son code fonctionne que lors de la phase de tests intensifs. Pour lui, tester c’est la tâche de ce que l’on appelle l’équipe de QA, tiré de l’anglais Quality Assurance, et qui s’assure de la qualité du logiciel fournit. Si son code ne fonctionne pas, ils le lui indiqueront et il corrigera. On voit bien que sa responsabilité de fournir du code qui fonctionne lui échappe.

L’avocat se tourne vers l’audience et continue :

Nous ne nous attarderons pas plus sur le cas de Mr Whatever, il appartient à une génération un peu dépassée par les événements.

Cette dernière phrase entraine de légers gloussements dans l’assistance.

Mr Guru

Maître Darrow, après avoir jeté un rapide coup d’œil aux papiers étalés sur son bureau, se tourne vers la personne assise aux côtés de Mr Whatever.

Passons au cas de Mr Guru. Cas intéressant puisqu’il représente l’archétype de l’informaticien auquel on accorde toute sa confiance !

Ses connaissances et son expérience en font un expert dans l’écriture du code. Cependant, il ne teste jamais ce qu’il écrit. Il n’introspecte pas. Perte de temps pour lui ! Il a écrit assez de plateformes pour savoir comment écrire la vôtre. Très bien. Nous aurons alors un code de qualité. Cette affirmation est correcte si votre équipe n’est formée que de Mr Guru ! Situation atypique s’il en est, et bon courage pour les batailles d’ego. Mais bon … passons.

L’avocat lève le bras pointant l’index vers le plafond et lance :

Si notre postulat de départ est que les entreprises ne travaillent qu’avec des profils tels que celui de Mr Guru, voici les problèmes que cela entrainerait :

Maître Darrow marque un silence pour permettre aux jurés de bien se concentrer sur ce qui va suivre.

Le premier problème serait une pénurie rapide de Mr Guru sur le marché. Toutes les entreprises ne pourraient pas en recruter et seraient dans l’incapacité de produire des applications de qualité. Un peu fantasque je vous l’accorde, mais totalement valide avec le postulat de départ.

Le deuxième problème impacterait le budget de l’entreprise. Un Mr Guru cela coûte cher ! Combien seriez-vous prêt à dépenser pour une armée de Mr Guru ?

Le dernier souci, et non des moindres, serait de s’assurer qu’on ne recrute que des Mr Guru. S’il y a un responsable des ressources humaines dans la salle, il m’accordera que la tâche se révélera ardue. Par ailleurs, je note aussi qu’il arrive à Mr Guru d’être fatigué ou d’être ennuyé, Guru ou pas, il reste humain. De ce fait, il est toujours possible qu’un expert introduise des erreurs dans votre code de production sans le vouloir.

De plus une question se pose. Faut-il bannir les développeurs juniors de votre équipe de développement ? Avons-nous peur qu’ils insèrent des erreurs dans le code ? Un bon manager vous dira que cela serait une faute. Une équipe doit être hétérogène en caractère. Pourquoi se couper du dynamisme des développeurs juniors, de la facilité avec laquelle ils manient les dernières technologies et de leur passion encore verte pour la programmation ?

Après une longue pause, l’avocat fixe chaque membre du jury tour à tour, et conclut :

Nous voyons bien qu’en réalité une équipe est constituée de profils différents et hétérogènes en compétence. Il nous faut donc une pratique commune de développement qui nous assure que Mr Guru et son collègue, plus junior, écrivent leur code d’une manière uniforme et testée sans porter atteinte à leur créativité.

Dans la salle, quelques personnes opinèrent du chef. Sûrement des développeurs!

Mrs Clickaway

L’avocat se rapproche de quelques pas du jury tout en désignant de la main la jeune femme assise au milieu du banc des accusés.

Maintenant le cas touchant de Mrs Clickaway. Mrs Clickaway est bien intentionnée. Elle veut savoir si son code fonctionne. Pour cela elle adopte un cycle rapide d’écriture de code, et de déploiement de son application dans son environnement local. Pour tester, elle clique et re-clique jusqu’à ce qui lui semble avoir parcouru tous les recoins des fonctionnalités qu’elle a implémentées. Pourtant, Mrs Clickaway utilise très mal son temps de développement. Pour les plus techniciens d’entre vous, je dirais qu’elle oscille entre stacktrace, long démarrage de serveur et debuging en tous genres !

En effet, alors qu’elle aurait l’opportunité d’écrire son code tout en l’introspectant, grâce aux trés bonnes librairies logicielles mises à disposition aujourd’hui, elle choisit de tester en mode boite noire. Pour les profanes dans la salle, le mode boîte noire est une série de tests qui se fait à un haut niveau de l’application sans se préoccuper réellement de la structure et du fonctionnement interne.

Je reproche donc à Mrs Clickaway de ne pas se concentrer sur son coeur de métier qui est la production d’un code propre et fiable. Pour être franc, je pense que Mrs Clickaway n’est jamais sûre de ce qu’elle écrit et qu’elle veut se donner bonne conscience avant de livrer son code à l’exploitation.

Je vous le dis, ne pas choisir l’introspection, c’est ne pas choisir de réfléchir sur ce que l’on produit et c’est ne pas choisir l’amélioration de son propre code. Mesdames et Messieurs les jurés, vous m’accorderez que c’est un peu surprenant et relève d’un comportement irresponsable pour un développeur.

Sur le banc des accusés Mrs Clickaway semble anéantie et confuse par cette série d’accusations.

Mr Testafter

Passons maintenant à mon cas favori. Mr Testafter.

Mr Testafter est sur la voie de la rédemption, seulement il a pris à gauche alors qu’il fallait prendre à droite ! Que je vous explique. Mr Testafter a bien compris qu’il fallait tester son code. Cependant, il écrit les tests après avoir écrit ce fameux code de production. Normal vous me direz. Eh bien non ! Cela pose plusieurs problèmes:

Comme tous les développeurs, Mr Testafter passe beaucoup de temps à écrire son code. Quand il en a enfin fini, c’est un soupir de soulagement avec une pause café bien méritée. Enfin jusqu’à ce qu’il réalise qu’il n’a écrit aucun test ! Pour ne rien arranger, il a déjà indiqué fièrement à son manager que son travail était fini. Qu’à cela ne tienne, il va ajouter rapidement les tests, parce qu’après tout, il n’a pas que ça à faire.

C’est à ce moment qu’il doit faire un effort non négligeable: se remémorer les spécifications, imaginer des cas d’utilisations pour finalement… relire son code afin de savoir quoi tester !

L’avocat lance un regard vers Mr Testafter sur le banc des accusés. Ce dernier fixe le plafond.

Idéalement, s’il veut que ses tests soient utiles, c’est-à-dire compréhensibles par un autre développeur, clairs, découpés en spécifications et couvrant toutes les fonctionnalités, il doit reprendre sa réflexion à zéro.

Cependant, Mr Testafter à ce moment précis est pressé. Il n’adoptera pas une démarche d’écriture « fonctionnalité par fonctionnalité ». Plus grave, il ne pensera pas aux effets de bord, car puisque son code est déjà écrit, il est censé fonctionner ! Summum du contre-sens, pour les praticiens du TDD dans la salle, Mr Testafter ne passe pas par la phase d’un test qui échoue. En réalité, Mr Testafter ne voit aucun test échouer ! Bizarre pour quelqu’un qui veut savoir si son code fonctionne.

Une fois les tests ajoutés, laissez-moi vous décrire le résultat, cela se vérifie presque à chaque fois. Il y a toujours plus de code généré qu’il n’en faut et le code contient de la duplication. Mr Testafter n’est pas dans une optique de code minimal pourtant si importante dans les énormes bases de code d’aujourd’hui. Les tests sont désordonnés, ne sont pas organisés en terme de fonctionnalités et contiennent eux aussi de la duplication.

Invariablement aussi, une fois les tests ajoutés, le code restera tel qu’il a été écrit à l’origine. Pas d’optimisation, de minimalisation ou de recherche d’expressivité du code. Le plus grave cependant est d’obtenir ce que l’on appelle un effet gruyère sur la classe testée: des bouts de code resteront non testés. Pour ceux qui me suivraient encore dans l’assistance, je ne vous conseille pas de refactorer du gruyère !

Sur cette dernière phrase, l’audience se partage entre face crédules et sourires.

Mr Tedd – Vers un code agile

Il est l’heure maintenant pour Mr Darrow de défendre son client. Il tient à expliquer aux jurées les principes fondamentaux sur lesquelles repose la méthode que son client Mr Tedd utilise. Il enchaine alors :

A travers les différents profils que je vous ai présenté, nous avons pu voir les insuffisances de certaines techniques de développement.

Laissez-moi donc maintenant vous résumer la manière d’écrire du code applicatif la plus à même à répondre à la problématique de tolérance au changement du monde du logiciel. C’est celle que pratique mon client. C’est le Test Driven Development. Cette méthodologie se résume avec la phrase suivante :

Tout code de production a été écrit pour faire passer un test qui au départ échouait.

Ce postulat pour certains peut sembler abstrait, cependant il se met en pratique tous les jours avec succès. Laissez-moi maintenant énumérer les corollaires directs de ce postulat.

Dans la salle on aurait pu entendre une mouche voler. L’avocat commence à énoncer :

Tout code de production est donc testé. Il n’y a pas plus de code que de fonctionnalités voulues et votre base de code est donc minimale. Toute fonctionnalité étant couverte par un test, vous savez instantanément lorsqu’un test échoue qu’une fonctionnalité n’est plus respectée et vous pouvez prendre aussitôt les mesures appropriées.

Ce code, proprement testé, vous pouvez le simplifier, l’améliorer et le nettoyer sans risque. C’est ce que l’on appelle le refactoring. Votre code devient par conséquent malléable, flexible et donc agile. C’est le moyen d’éviter que votre code ne s’effondre sous son propre poids !

L’avocat continue :

Mesdames et Messieurs les jurés, je vous le demande : Pour ceux qui connaissent le monde du logiciel, quel est le mot le plus important dans l’agilité?

Au vu des visages dubitatifs du public, et de cette femme âgée assise au premier rang qui avait commencé à tricoter, Maître Darrow comprit qu’il aurait à apporter lui-même la réponse.

Le Feedback ! Voilà le concept le plus important à mettre en place. Le Test Driven Development vous permet de mettre en place la plus petite boucle de feedback du monde agile. Instantanément vous savez si votre code répond à vos exigences.

Alors que Mr Darrow est au beau milieu de la défense de son client, le président Mr Beck, avec un geste d’impatience de la main, déclare :

Merci Mr Darrow. Cependant, avant que vous poursuiviez, l’avocat de la partie civile souhaite interroger maintenant votre client Mr Tedd. Et exceptionnellement, je ly’autorise.

Mr Darrow ne peut qu’abdiquer et Mr Tedd se dirige alors vers la barre pour être interrogé. C’est alors qu’un petit homme au front suintant, très agité, s’avance au centre. C’est Mr Pascal, l’avocat de la partie civile. Le contre interrogatoire peut commencer.

La suite du procès dans un prochain article.

Pour ceux qui ne le connaissent pas, Robert Martin est une figure emblématique du monde du développement logiciel agile. Il a rédigé plusieurs ouvrages sur le « Software Craftsmanship ». Co-signataire du Manifeste Agile, il est l’auteur entre autres de : « Clean Code: A Handbook of Agile Software Craftsmanship ».

Si cette formation vous intéresse ou si vous souhaitez de plus amples informations, n’hésitez pas à consulter le programme de la formation sur le site xebia-training.fr ou à nous contacter au 01 53 89 99 99.

La semaine prochaine se tiendra la conférence Mix-IT (prononcez « mixité ») à Lyon. 25 speakers animeront la journée dans 5 salles en parallèle. Le but est de fournir des sujets variés et complémentaires, autour de 5 thèmes :

• Techy : Java et son écosystème
• Agility : L’agilité pour débutants et passionnés
• Trendy : Tendances novatrices et avant-gardistes
• Mixy : Le meilleur de l’agilité et des technologies Java
• Gamy : Jeux agiles et coding dojos

Cet évènement est organisé par le Lyon JUG et le Club Agile Rhône-Alpes.

En vrac, on y parlera de : Play!, Product Owner, Clojure, Coaching agile, Apache Mahout, BDD, Grails, DevOps, Spock, HTML5, Code retreat et bien d’autres sujets.

Vous pouvez découvrir le programme complet à cette adresse.

Xebia participe à cet évènement en animant 2 slots :

• Grails from scratch to Prod, par Aurélien Maury (@aurelienmaury)
• Intelligence collective avec Apache Mahout, par Michaël Figuière (@mfiguiere)

Les places sont comptées (200 spectateurs) donc dépêchez-vous de vous inscrire !

Il reste quelques places disponibles sur le site du scrumday, dépêchez-vous si vous n’êtes pas encore inscrit.