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.

L’agilité a fêté ses 10 ans il y a quelques mois (enfin, le terme officiel, les méthodes elles, sont plus vieilles).

Depuis quelques temps cependant, il est plus à la mode de parler de l’Agile, plutôt que de l’agilité.

Outre le fait que ce n’est pas très français, et que donc ça me fait mal aux oreilles, je vais ici honteusement paraphraser un article de Dave Thomas pour exprimer ce qui ne nous convient pas chez Arpinum.

On ne peut pas «faire de l’agile», on peut seulement le devenir.

L’intention du mouvement était de trouver un adjectif pour qualifier certaines approches et/ou certaines manières de faire. Elles ont alors été qualifiées d’agile, représentant ainsi qu’elles permettaient d’aller vite et bien.

Il n’est pas possible d’acheter un pack d’Agile, et hop, le miracle s’opère. Il est juste possible de le devenir un peu plus chaque jour. En essayant au quotidien d’aller plus vite et plus facilement, on devient de plus en plus agile.

L’essence même de Scrum par exemple tient dans cette volonté de faire mieux chaque jour, donnant de nombreuses opportunités d’analyser nos pratiques. Adopter les  cérémoniels de Scrum ne va pas faire de vous quelqu’un d’agile, mais juste vous donner l’opportunité de le devenir.

Finalement, faire de l’agilité un nom, c’est d’une certaine manière figer les possibilités que nous associons à ce nom. Un nom est un ensemble borné, contenu dans sa définition, un adjectif est ouvert aux possibilités et aux évolutions. Donc s’il vous plaît, ne faites pas de l’Agile, soyez le.

Crédit photos: jump / polandeze via Flickr CC License By

Posons un peu le contexte

J’avais démissionné de la société précédente pour me frotter à de nouveaux projets et de nouvelles personnes, dans l’espoir d’améliorer mes compétences et mon plaisir à travailler, tout simplement.

Jusque là, j’avais toujours tiré une certaine fierté de mes développements, et ils récoltaient leurs lots d’appréciations auprès de mes paires, mais systématiquement j’avais cette peur au ventre. La peur d’avoir laissé passer un bug, la peur de ne pas avoir trouvé le meilleur design possible, la peur de ne pas tenir les délais… De plus, ce code était technique, et je ne concevais pas autrement mon travail qu’en traduisant des demandes fonctionnelles en design technique.

J’avais entendu parler d’XP, mais comme beaucoup de monde, je n’en savais pas grand chose si ce n’est qu’on devait programmer par paire. Je sentais d’une certaine manière que j’étais dans la mauvaise direction, et c’est pourquoi je me suis mis à lire, beaucoup. Des livres comme Code Complete ou Design Patterns, mais toujours pas XP, ni DDD.

Donc c’est dans ce contexte que je démarrais cette nouvelle mission, avec toujours la même peur au ventre. Et là, dans un bureau digne des messages à caractère informatif, on me présente mon nouveau collègue, lui aussi prestataire : Fabien Bézagu. Sur son bureau trônent Applying DDD de Jimmy Nilson, Pratiques de .NET en C# de Patrick Smacchia.

A la découverte d’un nouveau monde 

De fils en aiguille, nous voici donc en train d’expérimenter : des patterns, des idées, de l’orientée objet, et surtout de plus en plus de DDD. Puis un jour, il arrive avec cette idée folle : commencer son développement par les tests.

Comme beaucoup de monde, je suis réticent au début, mais je m’y mets de plus en plus, poussé par l’autre énergumène.

Comme apparemment, notre travail est apprécié, on nous confie un nouveau projet. Là bien sûr, nous sortons DDD vaillamment, et nous tentons de nous améliorer. Nous sommes bien sûr très teintés XP, mais sans encore avoir fait le grand saut. Puis un matin, excédés sans doute de ne pas avoir toutes nos réponses, nous faisons enfin l’investissement d’acheter nos copies de XP explained.

Le choc est rude pour moi : toutes les réponses que je cherchais depuis des années, ou ce que je savais intuitivement sans oser me l’avouer, est écrit noir sur blanc, avec une clarté et une simplicité désarmante. Bien sûr, le projet social d’XP devient alors mon cheval de bataille.

Le contexte et nos connaissances étant ce qu’elles sont, nous n’avons pas forcément emporté un grand succès. comme l’explique Fabien. Cependant, les premiers mois de ce projet ont été une des meilleurs périodes de ma vie de développeur, jugez plutôt :

• tous les matins, j’étais heureux d’aller au travail. Je savais ce que j’avais à faire, j’étais fier de ce que je produisais, le métier était enrichissant et mes collègues passionnants,
• tous les soirs, je sortais empli de la certitude que je n’aurais rien pu faire de plus pour faire avancer le projet. Le travail énergique étant correctement mis en place, je sortais sans ce sentiment désagréable de travail inachevé, ou de gaspillage de temps passé sur des soucis d’environnements,
• chaque semaine comprenait son lot d’améliorations.

Quand le projet a finalement eu des soucis pour différentes raisons, ces pratiques nous ont permis de rester droit dans nos bottes, en sachant que nous avions fais notre maximum. Cette confiance fait toute la différence quand le client tente de vous mettre la pression, en vous faisant croire que vous n’en faites pas assez.

La suite bien sûr, c’est que XP est devenu le cœur de nos préoccupations, toujours dans l’objectif de pratiquer le DDD et répondre ainsi au mieux aux problèmes de nos clients. Nous avons donc porté ce message dans nos autres missions, et nous avons fini par lancer Tiron et Arpinum.

Et donc?

Si je fais donc le bilan de ces 5 années d’apprentissage, et sans vouloir faire trop sectaire, XP m’a apporté les points suivants :

• la qualité : en avançant grâce au TDD, en extrayant la connaissance en suivant le DDD, et en la gravant dans le code et dans FitNesse, la qualité de nos développements a grandement augmenté, réduisant ainsi les coûts, et augmentant la confiance de nos clients,
• la simplicité : la peur du mauvais design a disparu, je sais que je vais le faire apparaître par design incrémentiel,
• la confiance : grâce à la qualité et la simplicité, j’ai gagné en confiance, je sais que je fais mon maximum pour réduire les gaspillages et livrer un produit de qualité dans les temps,
• le calme : de cette confiance naît le calme : la plupart du temps, je ne sens plus la pression du temps. Comme l’explique Uncle Bob, de même qu’un chirurgien opérant à cœur ouvert, je ne regarde plus la montre, stressé par le délai, mais je me concentre sur la tâche à accomplir, confiant sur le fait que seules mes pratiques me permettront de respecter les délais.

XP n’est bien sûr pas magique. Il ne nous a pas transformé en bons commerciaux, la pluri-disciplinarité a ses limites. Le caractère de chacun est également une composante pas toujours facile à gérer en pair programming. De plus, le plus simple qui fonctionne, après plusieurs années de développement, devient nécessairement compliqué. XP gère bien mieux ce souci que d’autres approches, mais le problème persiste.

D’un point de vue plus large, en adoptant les valeurs d’XP, je me suis rendu compte que ma propre satisfaction passait par la satisfaction d’un tout. Le fameux principe de bénéfice mutuel. C’est pourquoi j’ai quitté le monde des SSII, même si j’en garde un bon souvenir, car opposer mes intérêts à ceux des clients, opposer mes intérêts à ceux des commerciaux, opposer mes intérêts à d’autres développeurs, n’était clairement plus pour moi un moyen de fonctionner qui me convenait.

Je ne peux au final, comme nous le faisons en formation ou coaching, que conseiller de s’accrocher à ceux et celles qui débutent cette route. Le jeu en vaut tellement la chandelle!