Mix-IT, c’est une journée de conférence co-organisée par le Cara, et le JUG Lyonnais. Du coup, cela donne un mélange que j’adore tout particulièrement : des conférences très techniques d’un côté, et des conférences plus «philosophiques» de l’autre. Comme le disait Rabelais :

«Science sans conscience n’est que ruine de l’âme»

Nous y sommes allés à deux Arpinumien, @michael_borde et moi-même, et je ne désespère pas de le convaincre d’écrire également sa vision de l’évènement.

Cela va sans dire, l’organisation était top, la journée a été très fluide grâce à eux, avec du café toujours à disposition. Le wifi a fonctionné parfaitement, ce qui est un exploit dans ce genre de rassemblement.

La journée a commencé par des croissants bien sur, mais également par deux keynotes.

Bon, celle de google était assez dispensable, mais Claire Blondel (@claireblondel) a été excellente. Le thème du droit à l’erreur est cher aux agilistes, et il était parfaitement défendu et illustré. Je retiens cette phrase de la fille de l’oratrice :

«Maman, j’en ai marre d’avoir peur de me tromper»

Social Architecture 101

Je suis ensuite aller voir Pieter Hintjens, parler d’architecture sociale. Il est l’instigateur de zeroMQ, et il nous a parlé de ses patterns pour monter des architectures sociales qui fonctionnent. J’ai accroché a pas mal de ses idées, pour certaines déjà connues, mais d’autres étaient un peu plus… choquantes. Son opposition à réunir les équipes dans un même bureau, essayer de traiter tout le monde comme des volontaires, quitte à devoir les virer pour ça sont autant d’idées assez… provocatrices. Bien sur il y a un fond intéressant à creuser. Wikipedia, les projets open source (comme le sien), montrent que la distance et la diversité des idées, sans cohésion de groupe, font émerger des constructions très impressionnantes. Sur le volontariat ceci dit, je pense que Drive, de Daniel Pink, est une lecture bien plus intelligente de cette énergie.

Backbone

Ensuite, je suis allez satisfaire ma soif de geek en allant regarder du live coding autour de backbone.js. La session était animée par Bodil stokke (@bodiltv), qui portait le pantalon le plus geek que je n’ai jamais vu (space invader).

Bon, c’était maîtrisé, Backbone est assez sexy, d’autant plus avec du WebSocket pour rendre tout ça encore plus dynamique (c’était un client twitter). Le soucis à mes yeux (et à ceux de Jérôme Avoustin @JeromeAvoustin), c’était l’absence complète de tests unitaires. On pourra surement penser qu’en une heure, c’est difficile d’introduire des tests, mais, même en une heure, nous avons perdu du temps sur des bugs introduits.

Enfin, je ne garde tout de même Backbone dans un coin de la tête, avec Sammy.js, car il y a du potentiel là dessous.

Lightning Talk

Après un très bon sandwich fournit par l’organisation, il était temps pour moi d’aller ouvrir le bal des lightning talks, car «La voie du programmeur» a remporté le plus d’approbations. J’en étais très fier, mais j’avais du coup surtout beaucoup de pression, surtout quand j’ai appris que nous étions retransmis en live sur Internet Je pense m’en être bien sorti si j’en crois les différentes personnes (que je remercie) qui sont venues ensuite me donner leur avis. Alexis a filmé ça, donc en attendant les vidéos officielles, je vais sans doute la déposer sur un coin du web.

Les autres LT étaient tout aussi passionnants, si ce n’est plus. Mon seul bémol, c’est le LT sur les propriétés dynamiques, ou il m’a semblé que l’orateur résolvait un problème (la difficulté de mise en production, des couches inutiles), par un autre problème (rendre tout configurable, et faire disparaître le métier).

Je retiens personnellement, encore une fois le bon message sur le droit à l’erreur mis en avant par Jérôme Avoustin (@JeromeAvoustin), la remise au goût du jour de la compagnie X et Y, par Alexis (@alexismonville), et le concept de Developper Experience, de Pamela Fox (@pamelafox)

Software Development Workflow at Google

Salle comble et plus pour Petra Cross (@petracross), et la gestion de projet chez Google. Rien de révolutionnaire ici, Google n’a pas réinventé la roue. Ce qui reste bien sur exceptionnel, c’est d’avoir un exemple d’une société d’une telle taille utilisant tous les principes qui nous sont chers, agilité en premier. Car oui, c’est officiel, Google est bien agile. Il ne le revendique tout simplement pas car ils n’ont pas envi, à juste titre, de devoir s’expliquer sur les connotations de ce mot.
Il y a eu bien sur un débat sur le fait de considérer les daily standup comme un antipattern à éviter. Je suis d’accord que l’intérêt d’un standup, quand l’équipe est bien rodée, que l’espace de travail est réelleent informatif, devient finalement limité. Ensuite, j’ai peur que ce genre de phrases «ah mais google ils en font pas» servent de mauvaise excuse à des équipes qui en auraient désespérément besoin.

Le DotGame : jouer la performance

Enfin, car ensuite les horaires d’avion nous contraignaient à partir, je suis allé faire le jeu proposé par Oana Juncu (@ojuncu), illustrant les bienfaits du Kanban dans la gestion d’une pizzeria Beaucoup de fun, et effectivement une net amélioration dans la 3ème itération avec l’introduction du Kanban. C’était juste vraiment dommage de ne pas avoir eu le temps de debrieffer plus en profondeur.

Pour conclure

Je suis bien sur très déçu de ne pas avoir pu rester jusqu’à la fin, et de pas pu aller faire l’after au Moma.
Mais en tout cas, j’ai vu un évènement d’une très grande qualité, animée par des passionnés, avec un contenu excellent et bien équilibré. Oui il faut maintenant compter le MixIT comme un des grands évènements de notre profession en France chaque année.

J’ai comme d’habitude beaucoup aimé pouvoir croiser les habitués de ce genre d’évènements, plus pas mal de nouvelles têtes.

• Les personnes qui sont présentes sont les bonnes
• Ce qui arrive est la seule chose qui pouvait arriver
• Ca commence quand ça commence
• Quand c’est fini, c’est fini.

Pour ma part, j’ai pu participer aux sessions suivantes

• SCOP et structure agile
• Polyglot data,
• Un coding dojo
• Skulls & Roses
• Agililté et Code Legacy
• Réflexions pour construire un nouveau jeu agile avec Kodu.

SCOP et structure agile

J’étais curieux d’entendre les retours de ce parmi les participants utilisant ce type de structure. Beaucoup de démystification donc sur le fonctionnement d’une SCOP, et j’ai découvert la sociocratie, sujet que j’ai très envie d’approfondir dans les mois à venir.

Polyglot Data

Nous avons surtout parlé pendant cette session de la nécessité pour les équipes de cesser de penser “données données données”, pour avoir une réflexion plus profonde autour de, par exemple, DDD, et ensuite s’autoriser bien plus de libertés dans les mécanismes de persistances. Je note la volonté des présents aussi d’abolir une bonne fois pour toute Merise (oui il existe encore des endroits perdus ou cela se pratique), et les DBA tortionnaires.

Coding Dojo

Après le repas du soir, nous avons tenté d’improviser un dojo, histoire de se faire plaisir entre développeurs, et faire découvrir ce format à ce qui ne connaissaient pas. Hélas, l’heure tardive, la fatigue, et le choix d’un langage que nous ne connaissions pas beaucoup nous a ralenti dans nos ardeurs. On fera mieux la prochaine fois

Skulls and Roses

Pablo a proposé une petite partie de ce jeu qu’il avait acheté pour l’occasion, histoire de voir si nous pouvions en tirer des conclusions agiles. Il faut bien avouer que nous avons eu quelques peines à faire des ponds vers notre domaine de prédilection, mais on s’est tellement marré que ça valait le coup. Skulls & Roses est un jeu par le créateur de Loups-Garous, et on y retrouve son amour pour les complots, la fourberie et le bluff. Je le conseil fortement.

Agilité et Code Legacy

C’est effectivement toujours une bonne question. Est-il possible de faire entrer facilement de l’agilité dans une base de code datée et sans test, et pire, avec toujours une équipe legacy continuant à introduire plus de dette.
Techniquement parlant, j’ai (re)découvert la technique du mikado, qui a l’air vraiment efficace pour reprendre du code legacy sans passer des semaines avec des tests rouges. Bien sur, nous avons rappelé qu’introduire des tests reste la base de tout. Jérôme nous a impressionné sur son courage dans sa mission actuelle.

Sinon, comme le disait Cyrille Martraire, le soucis réside bien dans les équipes legacy plus que dans leur code. Nous avons eu le sentiment que le pair programming était encore une fois la bonne pratique à mettre en oeuvre pour diffuser de nouvelles manières de faire.

Le jeu du développeur de jeu

Guillaume nous a fait découvrir Kodu, un langage graphique destiné aux enfants pour développer des jeux-vidéos. Nous avons planché sur sont idée de faire un jeu agile pour les non développeurs pour leur faire découvrir certains concepts clés, comme les tests, le pair programming ou le design émergent. Il y a beaucoup de potentiel je pense avec Kodu pour développer tout une gamme de nouveaux jeux agiles, ou de revisiter les classiques.

Et aussi

A table ou dans les voitures, nous avons pu parler d’Agile Tour Occitanie, de système de vote, de certification, de motivation, de langages de programmation, de frameworks de développement rapide, d’IDE, bref, aussi beaucoup de découvertes de ce côté là aussi.

Pour conclure

Il faut avouer que ce fut très agréable, que le format est excellent, et il va falloir refaire ça.
Je retiens comme tout le monde comme améliorations d’allonger la durée, et d’être plus discipliné sur les horaires. Je retiens également de m’améliorer moi-même, et de moins parler.

P.S : quelques retours ou photos de l’évènements:

Fabrice
Claude
Thierry
Pablo
Des photos
La liste twitter de (presque) tous les présents
Alexis
Rui

Nous sommes depuis le 1er décembre officiellement partenaire de l’Institut Agile et nous en sommes fiers.

Derrière ce partenariat, nous avons voulu soutenir le travail de Laurent Bossavit au travers les missions de l’Institut Agile. Plutôt que de reformuler ces missions, je vais les reprendre du site de l’institut :

Les missions de l’Institut comprennent la recherche et la formalisation de connaissances sur les approches agiles et le développement de l’activité économique liée à ce domaine.

Convaincus par les apports et les bienfaits de l’agilité, il nous semble essentiel d’avoir à disposition des études et des informations fiables à ce sujet, une définition claire et précise des pratiques agiles (voir le travail de Laurent à ce sujet), ainsi que d’impliquer le monde de l’enseignement pour préparer les étudiants à être agile.

C’est donc pour toutes ces raisons que nous soutenons l’Institut Agile, et espérons pouvoir l’aider durablement.

Jean-Baptiste et moi-même avons eu le plaisir de faire le déplacement vers Grenoble, pour participer à ce qui est maintenant le plus grand événement parlant d’agilité en France, Agile Grenoble.

Avec bien peu de sommeil, nous sommes arrivés une demi heure en avance ce qui nous a permis de prendre le café avec Claude Aubry et Thierry Cros confortablement installés en regardant les gens en rouge s’agiter.

La journée a débuté avec une très bonne keynote de Karl Scotland qui nous a fait une variation de start with why, agrémenté de ses propres exemples. Cette keynote très agréable demandait quand même un bon niveau d’anglais. J’avoue avoir fait l’impasse sur quelques phrases.

J’ai assisté ensuite à une session passionnante de J. B. Rainsberger, « Les tests intégrés sont une arnaque! ». Nous avons eu le plaisir d’assister à la première version totalement en français de cette présentation maintenant très connue.
La démonstration de Jbrains, totalement faite au paperboard, m’a conforté dans l’idée de ce que je me faisais de ces tests intégrés, une vraie plaie, et surtout dans les techniques à employer pour éviter que ce virus s’autoréplique.
Pendant ce temps là, JB (l’autre, celui d’Arpinum) a assisté à la session de Laurent Bossavit sur les biais cognitifs, et en a fait un retour extrêmement positif, mais je ne me lancerais pas dans la description d’une session à laquelle je n’ai pas assisté…

Nous nous sommes ensuite rendus à une démonstration du Behaviour-Driven Development « Démonstration / Kata BDD sur un logiciel pilotant un instrument ». Je pense que le terme BDD a été dévoyé lors de cette session, mais il était quand même marrant de voir la machine bouger à partir de tests specflow . Le BDD est effectivement au mieux de sa forme quand il sert à faire apparaître et à manipuler un langage métier omniprésent, et les démonstrateurs ici manipulaient des checkbox et des boutons…

Après cette session, nous avons eu le plaisir de voir Uncle Bob à travers la diffusion du premier épisode de la série Clean Coders. Même en connaissant par coeur le discours du personnage, le montage fait « maison » du premier épisode lui a donné un aspect très plaisant d’un travail fait main, bourré de références de geek.
Depuis quelques mois, nous nous demandions si nous devions investir dans cette série, je pense que nous nous sommes décidés suite à cette diffusion (vu que nous n’avons pas gagné l’un des lots proposés à la fin, la série complète )

La pause de midi fût tout aussi agréable, bien que trop courte avec un plateau repas bien garni et d’excellente qualité.

L’après midi a repris par une keynote de Jurgen Appelo « How to change the world ». Après avoir mis en avant ses 15 années d’échec personnel, Jurgen nous a invité à danser avec nos managers. L’état d’esprit du management « 3.0″ qu’il a distillé tout au long de cette keynote était rafraîchissant mais à notre grand regret encore trop éloigné de la réalité et du command & control qui a tendance encore à résister dans beaucoup d’équipes dites « agiles ». La stratégie qu’il propose en tout cas pour «changer le monde» a fait écho à certaines de nos expériences, surtout son insistance à nous rappeler que malgré tout le travail que peut accomplir un coach, après son départ les «trainards» feront tout ce qu’ils peuvent pour revenir en arrière.

Nous avons fait l’impasse sur les premières sessions de l’après midi et avons privilégié les échanges informels. Parmi ces échanges, nous avons eu une discussion avec deux Laurent, Laurent Bossavit et Laurent Morisseau, surtout autour de la nécessité de s’appuyer sur des sources et des études fiables et de la capacité de certaines sources douteuses à devenir fiable par diffusion sémantique. Même si la tentation est grande de vouloir utiliser des exemples percutants dans nos présentations pour évangéliser les foules, l’honnêteté intellectuel doit nous pousser à ne pas engendrer de nouveaux mythes. Par exemple, on a souvent véhiculé que le cycle en cascade devait sa popularité par la mauvaise lecture du DoD de l’article de Royce, mais apparemment il n’en est rien.

La deuxième session de l’après midi, Git au quotidien, était une session dans notre « zone de confort » : Git on connait, on n’allait pas trop se faire de noeuds au cerveau avec cette présentation. Les orateurs ont su présenter l’essentiel de Git de manière claire et surtout avec des exemples très simples, en se focalisant sur quelques commandes, représentant 80 ou 90% de l’utilisation classique d’un gestionnaire de code source.
La présentation de l’utilisation de Git en équipe distribuée a été une découverte pour moi, j’utilise effectivement Git, mais dans mon équipe colocalisée…
L’aspect « branches » de Git a été je pense volontairement omis, ce qui a permis aux orateurs de se concentrer sur l’essentiel (oui, les branches, ça peut être pratique mais ce n’est pas obligatoire, et ça ne doit pas vivre plus de quelques jours ).

Pour la dernière session de la journée, nous avons choisi l’option « canapé » et avons fait l’impasse sur celle-ci, la fatigue aidant.

Notre journée s’est terminée par un pot pour fêter avec les autres partenaires notre nouveau statut de membre de l’institut agile. Hélas les horaires de train nous ont forcé à écourter cette joyeuse réunion qui commençait à être passionnante. J’espère que nous aurons l’occasion de reprendre la conversation que nous avions avec Emmanuel Gaillot. Peut-être à Agile Open France ?

Notre seul regret au final dans ce déplacement est de ne pas avoir pu participer à la suite logique de l’évènement, Agile Innovation, nos obligations bordelaises nous en ayant empêchées.
Nous avons aussi été assez impressionnés tout au long de la journée sur l’organisation infaillible de cet manifestation de 500 personnes.

Pour conclure, je pense ne pas trop me tromper en disant « A l’année prochaine Grenoble! ».

P.S : une mention spéciale également pour Fabrice, seul autre bordelais ayant fait le déplacement, avec qui nous avons eu des échanges passionnants pendant les longs trajets. Le poudlard express n’était pas si express que ça.

Nous avons eu le plaisir d’accueillir le 3 décembre dernier le premier code retreat bordelais. Organisé par l’association Okiwi, cet évènement a fait partie de la journée mondiale du code retreat qui a réuni à travers le monde plus de 2000 développeurs.

Nous nous sommes retrouvés à une quinzaine dans nos locaux pour participer à cette retraite, animée par Jean-Baptiste, coach émérite d’Arpinum .

Le principe du code retreat est simple :

• on travaille en binôme sur des sessions de 45 minutes se terminant par une rétrospective,
• on travaille sur un exercice imposé, le jeu de la vie,
• le code est jeté à la fin de chaque session,
• le coach choisit de nouvelles règles pour la session suivante.

J’ai eu la chance de passer cette journée à coder, en tant que participant et à m’efforcer, avec ma paire de respecter les quatre règles d’une conception simple : Les tests passent, Don’t Repeat Yourself, le code doit véhiculer l’intention du développeur et minimiser le nombre d’éléments.

L’exercice proposé lors de ce code retreat, le jeu de la vie était propice au travail en pair-programming. Les règles sont simples, mais les choix et les conceptionss qui en découlent sont nombreux.

Plus que l’exercice de code en lui même, le plus important était la démarche entreprise pour arriver au but. D’ailleurs la fameuse règle du “au bout de 45 minutes, on jette le code” a beaucoup aidé à cela : adieu le joli code qu’on a produit ces dernières 45 minutes, on recommence de rien, mais on va le faire mieux qu’avant.

Les règles imposées par le coach au fil de l’eau ont permis de pimenter la chose : aucun if, pas de types primitifs, on reprend le code d’une autre paire… J’avoue que la règle du “pas de types primitifs” m’a un peu fait faire des noeuds au cerveau, mais la solution trouvée, en groovy, était assez élégantes.

Pour moi, cette journée a surtout été intéressante sur un point : les échanges avec mes paires. J’ai eu l’occasion de travailler avec 6 personnes différentes, avec à chaque fois une approche différente du problème. J’ai beaucoup appris de ces échanges.

La diffusion en live des code retreats de Toulouse, Paris et Montréal était assez anecdotique, mais il était intéressant de voir que nous n’étions pas les seuls à trimer…

Pour conclure, même si cette journée nous a demandé un investissement conséquent en temps (sisi), je suis entièrement satisfait de cet évènement où nous avons pu réduire l’écart entre la manière dont nous codons et la manière dont nous aimerions coder.

On essaie de se refaire ça plus souvent ?

En tant qu’organisateur

Nous avons accueilli 280 personnes de plein d’horizons différents : étudiants, boss, managers, développeurs… C’est donc une belle croissance. Chaque année, cela nous prend beaucoup de temps d’organiser cet évènement. Depuis Mars nous nous voyions une fois par mois, puis une fois par semaine à partir de juin.

Comme une bonne équipe agile, nous étions auto-organisés et pluridisciplinaires. Nous avons expérimenté cette année à plusieurs niveaux, avec plus ou moins de succès :

- avoir notre propre site,
- utiliser notre propre système d’inscription,
- utiliser mailchimp,
- avoir un open space et un coding dojo toute la journée, et moins de conférences.

Je pense pouvoir dire que notre communication et la gestion des inscriptions ont été chaotiques, pour le reste nous sommes assez fiers de nous

En tant que sponsor

Pour la première fois cette année, Arpinum était sponsor, et nous avons réfléchi longtemps aux goodies que nous voulions mettre dans les sacs. Après plusieurs votes, notre choix s’est porté sur quelque chose de… décalé :

J’ai eu l’honneur de présenter Arpinum à la session plénière, et je dois avouer qu’étrangement, j’ai eu le trac. Les origines de notre nom ont donc été révélées…

En tant que participant

J’ai pu assister aux conférences suivantes :

Ni gladiateurs, ni bisounours. Une équipe remarquable au quotidien. Par Christophe Thibaut

Probablement ma session préférée de la journée. La deuxième partie manquait peut être du rythme et de la pêche de la première partie sur les anti-patterns d’équipe, mais l’ensemble était d’une limpidité remarquable, et m’a donné envie de vraiment pratiquer sérieusement les Core Protocols (Amazon, si tu m’entends, nous attendons toujours l’expédition de notre livre).

Lorsque Scrum ne marche pas. Par Alexandre Boutin

Alexandre étant un des plus fervents ambassadeur des jeux agiles, il nous a fait utiliser le jeu «Buy a Feature» pour acheter ses différents retours d’expérience sur ses échecs à la mise en place de Scrum. Le jeu en lui même a déjà donné beaucoup d’animation, et ensuite ses anecdotes étaient palpitantes et timeboxées au cordeau. J’ai donc encore passé un excellent moment.

Quarante ans de crise, dix ans d’agilité, et maintenant ? Par Laurent Bossavit

Je suis avec beaucoup d’attention le travail de Laurent depuis la fondation de l’Institut Agile. Cette conférence était donc un peu la synthèse d’un de ses sujets : l’histoire de notre profession. Je trouve la démarche de ce travail d’historien très bonne, tant il est vrai qu’il est difficile de faire la part entre mythe et réalité sur certain pans de notre histoire. Pas mal de mes élèves étaient présents en plus, et ça leur a permis de vraiment mettre en perspective cette «vérité» de l’ingénierie logiciel qui leur est assénée à l’école. Pour les «professionnels» présents, ça a été également une bonne opportunité de réviser ses classiques, et pour d’autres de se rendre compte que nous avons des classiques. Bref, encore un bon moment.

Billes Rouges, animées par Alexis Monville

L’expérience des billes rouges a été mise au point par William Deming pour démontrer les maladies mortelles que les entreprises peuvent attraper. L’atelier en lui-même était déjà passionnant à regarder (je n’ai pas été acteur), mais le débat qui s’en est suivi valait tout l’or du monde. Les principes de Deming sont toujours, voir plus qu’à l’époque, incroyablement d’actualité, et la démystification de ce qu’est un «bon» management faisait vraiment plaisir à entendre.
Alexis a fait filmer tout ça, et voici une petite mise en bouche :

Bref

Bref, même s’il est possible de dire que je ne suis pas vraiment impartial, j’ai adoré cette journée. C’est normal me direz-vous, en tant qu’organisateur, nous concoctons le programme qui nous fait le plus envie, mais pour une fois en 3 ans, j’ai pu assister à beaucoup de choses.
Je réitère mes remerciements à mes comparses organisateurs, à l’ENSEIRB-MATMECA qui nous accueille gracieusement, aux sponsors sans qui nous ne pourrions pas faire venir nos orateurs de loin, et bien sur à Brice pour son excellent boulot sur les vidéos.
Je vous dis à l’année prochaine ?

Le 3 décembre est la journée mondiale du code retreat, et Bordeaux, grâce à l’association Okiwi, aura son évènement!

Nous aurons le plaisir d’accueillir et d’animer la première édition bordelaise de cet évènement dans nos locaux.

Le principe de cette « retraite » est simple : nous codons en binôme sur des sessions de 45 minutes sur un seul et unique problème pour la journée. Après chaque session, l’ensemble du code produit est supprimé, nous animons une rétrospective, et de nouvelles règles sont mises en place.

Placée sous le signe du Software Craftsmanship, cette journée nous permettra d’essayer de réduire l’écart entre la manière dont nous codons et la manière dont nous aimerions coder.

Le nombre de places est assez limité (16), dépêchez-vous de vous inscrire!

Nous voici soulagés, les Agiles Tours Toulouse et Bordeaux sont passés, et la pression en tant qu’orateur et organisateur est tombée.
Les Agiles Tours, c’est toujours un excellent moment pour retrouver de vielles connaissances, et partager nos visions dans la joie et la bonne humeur. Bref, le 19 octobre, très tôt, le bus Arpinum est parti vers Toulouse.

Il y a eu un grand changement de décor pour cette année et ce centre de conférence faisait vraiment grandiloquent, et le petit déjeuner a fait bien plaisir après toutes ces heures de route.

Comme tout le monde, j’ai assisté à la Keynote d’Alexandre Boutin sur les jeux agiles et j’ai gagné une tablette de Toblerone ! Alexandre a vraiment été à l’aise dans cet exercice et sa session était donc une très belle démonstration de l’intérêt des jeux agiles.

La bonne idée de Toulouse cette année concernant les sponsors, était de ne faire monter sur scène que trois d’entre eux. Face au même soucis de « défilé commercial », à Bordeaux nous avons choisi de favoriser les petites boites ou les éditeurs de logiciel. C’est intéressant de voir, face au même problème, comment les différents Agile tours réagissent.

Je suis aller voir pour commencer la session d’Olivier Azeau sur les principes SOLID. À la manière de Mock et Stub montent sur scène, certains membres du public ont dû jouer les rôles de composants, de développeurs et de chefs. Personnellement, je me suis vraiment bien amusé pendant cette session. Ensuite, les principes SOLID ne sont vraiment pas simples à démontrer. Malgré une preuve par A + B à la fin que des composants à responsabilité unique s’appuyant sur l’inversion de contrôle ne nécessitait plus du tout de changement de code pour être réutilisés, certaines personnes dans la salle ont tout de même exprimé qu’ils préféraient manipuler un composant monolithique contenant un gros paquet de if. Développer est un métier…

Je suis ensuite allé voir « Histoire d’une transformation agile », par Laurent Carbonnaux et Lionel Molas. Pas grand chose à redire sur le contenu : c’est propre, et les deux compères ont réussi à faire prendre la mayonnaise agile dans un contexte pas évident.
J’ai beaucoup aimé les échanges post-session : malgré la réussite dans la gestion agile d’un projet d’une telle envergure (70 personnes, 9 équipes, code legacy, techno embarqué…), aucun d’entre nous n’avait vraiment envie de rejoindre le projet si l’occasion nous en était donnée. Comme quoi, nous cherchons tous une grande dose de plaisir dans notre travail.

Nous nous sommes ensuite rués sur le buffet, qui ma foi était fort bon. Pour obtenir un 10/10, quelques places assises supplémentaires auraient été nécessaires.

Je suis ensuite aller voir Agile et CMMI, par Pablo Pernot et Yassine Zakaria. Pablo avait piqué ma curiosité sur Twitter et, malgré toutes mes réticences, je voulais entendre ce qu’il avait à dire. C’était en fait assez intéressant. Les slides Astérix y sont sans doute pour beaucoup Nous sommes obligés d’être d’accord avec leur affirmation qu’il serait dommage de ne pas se « surveiller » mutuellement sous prétexte de débats de fanatiques. Cependant, je n’ai pas vu une seule fois dans cette présentation un élément de CMMI dont j’avais besoin pour mes projets ou qui ne soit pas couvert par une pratique agile. De plus, Yassine ne s’est pas caché sur le fait que les « CMMIstes » préfèrent se réunir en début de projet pour construire la méthode parfaite plutôt que de partir avec le minimum qui fonctionne et améliorer en route. De plus, la vision CMMI donnait vraiment encore cette impression que l’équipe et les développeurs n’étaient pas censés avoir leur mot à dire sur leur manière de travailler.

Leur conclusion a été : « nous pouvons nous inspirer mutuellement, mais mélanger les deux engendre un effet Frankeinstein. L’un doit prévaloir sur l’autre ». Dans tous les cas, cette session proposait de sortir des idées reçues et on ne peut qu’apprécier ce genre d’initiatives.

Ensuite j’ai co-animé notre session sur DDD et XP. Nous l’avons faite de nombreuses fois dans des contextes très différents, mais nous avons pris le risque de la changer radicalement pour cette occasion ! Plutôt que de suivre des diapos et un partage de parole, nous avons tenté de nous prendre la parole quand nous en avions envie, tout en suivant la trame de fond, pour ajouter beaucoup de dynamisme à cette présentation sinon trop théorique.
Nous avons eu autant de personnes qui ont adoré que de personnes qui ont détesté, ce qui, quelque part, nous fait plaisir car nous avons suscité des émotions ! Une personne a eu la gentillesse de nous envoyer un mail pour nous dire pourquoi il n’avait pas aimé et je vais copier sa conclusion :

Le ressenti que j’ai eu (j’imagine à tord mais ce n’est qu’un ressenti), c’est d’un petit groupe un peu élitiste qui s’adresse à des personnes aussi élitistes et pour les autres, ils n’ont qu’à s’accrocher, on s’en fout.

Alors nous ne sommes pas élitistes, mais il est vrai que le sujet nous semble pointu. En une heure de temps, nous ne pouvions pas couvrir les bases d’XP, nous sommes donc allé au coeur de notre sujet, en espérant en perdre le moins possible. Il ne faut pas prendre le fait de ne pas comprendre ce que disent les orateurs comme de l’élitisme de leur part, mais peut être seulement comme le fait que l’informatique est un sujet très vaste et qu’il est normal de temps en temps d’être largué pendant une conférence. Je suis assez content quand ça m’arrive, car c’est une fantastique opportunité d’apprendre.
Nous avons néanmoins des points à améliorer, et nos prochaines versions sous ce format seront meilleures.

J’ai terminé la journée par Olivier Azeau, encore : « Quand je serai grand, je serai artisant logiciel ». L’idée était de discuter autour du livre «Apprenticeship patterns» et de la notion d’artisanat. C’était vraiment trop court pour faire le tour des patterns et les discussions ont été du coup un peu limitées. C’est dommage car c’est un vaste sujet qui mérite l’attention de tout le monde. Je note le parallèle avec Stradivari car j’ai trouvé intéressant le fait qu’il n’ait jamais réussi à transmettre son savoir, malgré ses nombreux disciples.

Pour la session de clôture, Toulouse a mis les petits plats dans les grands en faisant venir (paradoxalement) Patrice Lagisquet, entraîneur du BO (dernier club du Top 14 comme il le dit si bien ) Les nombreux parallèles qu’il est possible de faire entre agilité et rugby ont été abordés, et il est assez jouissif de voir que ce que certains considèrent comme impossible va de soit chez d’autres. Au niveau du coaching, des dynamiques de groupe, de la motivation, nous devons vraiment arrêter de réinventer la roue et écouter pieusement ceux qui font ça depuis des années.

Bref, ce fut une journée bien remplie pendant laquelle je ne me suis vraiment pas ennuyé, même si je n’ai pas eu de grands moments « aha ». Je dois devenir un peu blasé peut être. J’adresse un grand merci à l’équipe de l’Agile Tour Toulouse pour leur accueil, et la qualité de cette journée.

J’étais, jusqu’à peu de temps, assez d’accord avec cette assertion. Dans mes expériences de salariat passées, à chaque fois que j’avais tenté d’entreprendre une démarche agile, systématiquement, nous sommes entrés en guerre contre le middle management. Je ne prétends pas en connaître les raisons. De manière complètement naïve, je penserais à un mécanisme de défense : défendre son job, défendre ses intérêts, etc. On pourrait aussi parler de peur : la peur de faire confiance, la peur de changer, la peur d’être le seul responsable en cas d’échec. Bref, je vous laisse aller creuser l’avis de Jurgen et Alistair.

Ceci dit, les derniers tweets cette semaine m’ont amené à me reposer la question. Le middle management est-il réellement la plus grosse contrainte ? Le fait est que dans les contextes dont je parle, nous avons obtenu des résultats. Sans éliminer ce frein, nous avons pu, la plupart du temps, le réduire considérablement. Comment avons nous obtenu ce miracle ? En ne poussant pas seuls la démarche, mais en étant appuyés par l’équipe entière. Sans ce mouvement de masse de la « base », honnêtement, nous aurions épuisé nos forces, coincés entre deux piliers inamovibles.

Comment l’équipe s’est-elle retournée contre son middle management ? Par l’éducation j’ai envie de dire. Par la découverte que le « command and control » et la pression n’étaient pas des faits établis, et qu’ils pouvaient être compensés par plus de professionnalisme. En pratiquant le TDD, le refactoring, en estimant elle-même les histoires, tout ceci étant souvent fait dans le dos du middle management, l’équipe petit à petit a pris conscience de l’absurdité d’un commandement en pyramide, et mis le doigt sur les gaspillages du projet. Dans le cas le plus extrême auquel j’ai pu assister, le middle management en place a carrément été viré.

Morale de l’histoire ? Certes, le middle management est une énorme résistance, mais le faire changer n’est pas possible sans résoudre une première contrainte : le manque d’éducation des développeurs. Dis autrement : les mécanismes de contrôle ne sont peut être là que pour compenser le manque de professionnalisme des développeurs que nous sommes.

Comme l’explique très bien Uncle Bob dans The clean coder, un professionnel est capable de dire non. En ayant conscience d’avoir un vrai travail, pas juste une étape en attendant d’être chef de projet; en ayant des disciplines de production de code, comme le TDD et le refactoring, nous gagnons la connaissance et la confiance suffisante pour dire « non » face à des demandes ou des situations aberrantes. En devenant professionnel, ce même management n’a plus besoin de craindre que nous ne fassions rien, que nous livrions trop tard ou que nous les truandions sur les coûts réels. Du coup, en devenant transparents, la nécessité apparente du « command and control » devient inutile.

Quand je parle de dire « non », je n’invite pas à la revendication facile de « eux versus nous », mais vraiment à un « non » calme et posé d’une personne éduquée qui, en fonction des données, sait dire « non » quand elle sait qu’elle va dans le mur ; et qui, en contre-partie, propose des solutions créatives. Sinon, nous tombons dans la « lutte des classes » bête et méchante, et dans l’émergence d’un certain protectionisme comme en parlait Olivier Azeau.

C’est donc sans grande originalité que je viens de décrire le cercle vicieux de la théorie X, et je reste convaincu qu’il peut se briser non pas que en ayant le soutien d’un top management éduqué, sorte de despote éclairé des temps modernes, mais bien par l’éducation et la professionnalisation de nous autres, développeurs.

C’est pourquoi, chez Arpinum, nous enseignons en 4eme et 5eme année de cycle d’ingénieur, c’est pourquoi nous co-organisons l’agile tour, nous participons au dojo d’Okiwi, nous tenons ce blog et faisons des vidéos. Nous ne sommes pas les seuls bien sûr à diffuser ces idées et plus nous serons nombreux, plus le glas des sociétés dilbertesques sonnera. Je pense également que finalement, le mouvement du Craftmanship, et les idées véhiculées dans Apprenticeship patterns tendent vers cette réalité.

Il y a quelque temps, lors d’une soirée entre développeurs autour d’une bonne bouteille de vin, est revenu l’éternel débat sur le professionnalisme.

Le débat est parti du constat qu’un des fondateurs d’une société de jeux vidéo que je ne citerai pas, était capable de sortir des perles de jeu, mais personne dans son équipe n’était capable de reprendre son code. Les arpinumiens présents ont alors émis l’hypothèse que cela faisait de lui un bon « game designer », mais un mauvais développeur : un non professionnel.

Si on définit un professionnel par sa seule aptitude à gagner de l’argent grâce à son activité, alors le seul moyen de juger est la quantité d’argent amassée. Ceci dit, j’aime la version Wikipédia du professionnalisme :

Le professionnalisme caractérise la qualité du travail de quelqu’un ayant de l’expérience.

Il est possible d’avoir l’impression que ces deux définitions ne se comprennent pas. L’une parle d’argent, l’autre de qualité. Mais finalement est-ce le cas ?

Le professionnel, contrairement à l’amateur, doit savoir maximiser le retour sur investissement. Un développeur professionnel sait donc que la qualité d’hier est la productivité d’aujourd’hui. Il doit donc à priori toujours produire le code de qualité correspondant aux besoins à un instant T : pas de sur-conception, c’est du gaspillage, mais pas de code illisible et couplé, il sera plus difficile à modifier.

Le bon professionnel gagne donc effectivement de l’argent de son activité, mais optimise en plus chaque denier qui est placé en lui.

Cette optimisation peut alors passer parfois par dire « Non » . Non, nous n’arrêterons pas de faire des tests ; non, cette fonctionnalité n’est pas réalisable dans le temps impartis, mais nous allons trouver un compromis ; <ajouter ici la clause où vous vous reconnaitrez>

Pour revenir à notre exemple initial, qu’est ce qui fait de cette personne un développeur amateur, mais un bon game designer ?

Nous avons conclu que, en tant que game designer, il maximise le ROI de sa société en découvrant des mécaniques de jeu innovantes et amusantes, qui vont donc trouver un public. Il ne suit pas un plan préétabli, mais joue avec des hypothèses, et si elles s’avèrent mauvaises, n’hésite pas à les jeter. Il connaît son marché et le temps à y consacrer : pour un jeu casual, il ne faut pas chercher les mécaniques d’un Eve Online, ni les mêmes temps de développement. Pour résumer, il cherche de manière itérative et incrémentale son nouveau game design, dans une limite de temps correspondant aux bénéfices attendus.

En tant que développeur ceci dit, ce n’est pas la même chanson :

en ne testant pas le plus tôt possible, il augmente le temps de tests de recette et son code illisible augmente le coût de correction. S’il tombe malade, personne ne peut reprendre son code, et il immobilise la société.

En ne produisant pas du bon code, il ne peut pas être utilisé dans d’autres projets, ou servir de source d’inspiration pour d’autres. La connaissance n’est pas transmise.

La société en question se porte pourtant merveilleusement bien. Est-ce que ça veut dire que tout ce beau débat sur le professionnalisme ne sert à rien ? En développant essentiellement des jeux courts sur lesquels ils ne reviennent pas, le souci de qualité est amoindri. Je verrai dans ce cas le manque de professionnalisme comme un coût des opportunités perdues.

Dans un contexte différent cependant, comme un éditeur de logiciel, une équipe travaillant sur le même produit pendant des années sans être rigoureux sur la qualité peut tout simplement couler la société. Le cimetière des entreprises en est rempli (ce n’est bien sûr pas la seule raison possible, la qualité est une condition nécessaire, pas suffisante).

Notes :

Pour plus d’informations sur les caractéristiques et l’éthique d’un développeur professionnel, il existe quelques livres : The clean coder, the pragmatic programmer, the mythical man month, The passionate programmer.