Le site Arpinum Blog Arpinum Blog Arpinum fr-FR Mon, 20 Oct 2014 19:26:03 +0000 Mon, 20 Oct 2014 19:26:03 +0000 Mix-IT 2014 vu par jb http://www.arpinum.fr/2014/05/12/mix-it-14/ Mon, 12 May 2014 00:00:00 +0000 http://www.arpinum.fr/2014/05/12/mix-it-14 <p>J’avais sauté l’édition 2013 pour de sombres histoires de naissances, mais je n’ai pas raté l’édition 2014, et j’avais en plus l’honneur d’être orateur.</p> <p class="center"> <img class="img-responsive" src="/images/blog/mixit14/logo-mixit.png" /> </p> <h2 id="ce-qui-ma-marqu">Ce qui m’a marqué</h2> <p>C’est devenu un peu classique de féliciter les organisateurs de conférences, mais là, je dois avouer que suis juste, bluffé :</p> <ul> <li>des orateurs excellents, venant des 4 coins du monde</li> <li>un prix très abordable</li> <li>des crèpes à volonté, et maison !</li> <li>repas d’excellentes factures</li> <li>une soirée privée sur un bateau ! Avec un open bar bien provisionné (grâce à Atlassian il paraît)</li> </ul> <p>bref</p> <p class="center"> <img class="img-responsive" src="/images/blog/mixit14/wow.gif" /> </p> <h2 id="les-keynotes">Les keynotes</h2> <p>Les keynotes étaient à mes yeux du niveau de ce qu’on peut attendre d’un TedX : ça fait rêver, c’est bien emballé, et ça vous met des étoiles dans les yeux.</p> <p><a href="http://ploum.net/">Lionel Dricot</a> alias Ploum, nous a parlé de BitCoin, mais surtout de la fin du travail. J’aurais aimé qu’il aborde le sujet du revenu de base, mais de son point de vue, en conférence il ne veut pas donner de solutions, juste des constats. C’est une approche qui se tient. Je vais garder cette citation de lui :</p> <blockquote> <p>La meilleure source d’emploi est l’inefficacité</p> </blockquote> <p>En vrac ensuite, je note que github ont des <a href="http://customspaces.com/office/DhXb6EKlE9/github-office-san-francisco/">bureaux</a> qui déchirent, et que <a href="https://twitter.com/ryu5t">Rieul Techer</a> m’a presque fait regretter de ne pas avoir suivi mon premier amour qu’était la biologie.</p> <h2 id="les-confrences">Les conférences</h2> <p>Il n’y avait rien à jeter dans ce que j’ai vu, ce qui est un peu un exploit je trouve dans une conférence. Bien sûr, certaines ne m’ont pas apporté grand chose, mais seulement car je n’avais pas choisi la bonne salle finalement. Je ne vais pas faire le tour de toutes les conférences, histoire de vous épargner un billet trop long :)</p> <h2 id="how-to-make-better-decisions">How to make better decisions</h2> <p><a href="https://twitter.com/OlavMaassen">Olav Maassen</a> nous a parlé de real options. Même si c’était un peu rapide, j’ai beaucoup aimé cette présentation. Finalement, l’architecture que nous proposons dans le mythe du framework agile sert exactement à ça : garder des options ouvertes, et réduire le coût de récupération en cas d’échec. Je retiens son analogie : si vous faites un plongeon depuis le bord d’une falaise, aurez-vous besoin d’une corde pour remonter ou pas ? Quand avez-vous toujours le choix de ne pas plonger, quand êtes vous engagé à plonger ? Un framework fullstack ressemble beaucoup à mes yeux à un plongeon sans corde pour remonter…</p> <h2 id="how-to-do-kick-ass-software-development">How to do Kick-Ass software development</h2> <p><a href="https://twitter.com/svenpet">Sven Peters</a> nous a parlé des entrailles d’Atlassian. Beaucoup d’énergie dans cette conférence, surtout que quand il parle de kickass, c’est bien de lui qu’on cause :</p> <p class="center"> <img class="img-responsive" src="/images/blog/mixit14/kickass.jpg" /> </p> <p>Ce que je retiens de sa conférence : non l’agilité n’est pas morte, c’est ce qu’Atlassian tente de faire toujours : comment faire mieux aujourd’hui qu’hier.</p> <h2 id="natural-course-of-refactoring">Natural Course of refactoring</h2> <p><a href="https://twitter.com/ms_bnsit_pl">Sieraczkiewicz Mariusz</a> (j’ai du copier/coller son nom pour y arriver), nous a présenté son approche structurée au refactoring de code legacy. J’ai aimé sa distinction entre le refactoring du quotidien et le refactoring stratégique. Ensuite, je suis moins fan de son étape 0 : comprendre le code. Je suis plus en accord avec le principe de refactorings “sans le cerveau”, avec quelques règles de bases, pour faire émerger quelques concepts. Je me suis déjà perdu des jours entiers à tenter de comprendre du code legacy, je préfère donc maintenant un golden master et quelques techniques de base. Le reste de son processus est très bien :</p> <ul> <li>exprimer l’algorithme</li> <li>extraire les responsabilités</li> <li>introduire de la flexibilité</li> <li>faire évoluer l’architecture</li> </ul> <p>Phrase à retenir : si vous avez une méthode privée que vous avez envi de tester, c’est probablement qu’elle pourrait être publique dans une autre classe.</p> <h2 id="fluent-http">Fluent-Http</h2> <p><a href="https://github.com/CodeStory/fluent-http">Fluent-http</a> c’est une nouvel outil en java pour faire du web simplement, produit par David Gageot et Jean-Laurent de Morlhon. Nous l’utilisions déjà à Arpinum pour un petit projet interne, car cet outil ressemblait à nos yeux à la fin d’une longue quête de l’outil le plus simple pour faire du web en java. Le pitch était effectivement de pouvoir booter une application web avec java 8 en 1/2h, et… oui c’est possible sans framework full stack \o/ Il y a une grande source d’inspiration du côté de jekyll, sans pour autant être un générateur statique, avec du support pour less, coffeescript, guice, jackson… Bref, c’est un vrai régale à utiliser, et c’est un outil qui fait très bien une et une seule chose : le web. En même temps, c’est la critique que je peux faire aux frameworks full stack en général : ils tentent de bien faire du web, et souvent c’est le cas, mais oublient de gérer correctement le métier en le réduisant à une simple base de données.</p> <h2 id="des-produits-avec-des-quipes-distribues-">Des produits avec des équipes distribuées ?</h2> <p>Ah un bordelais :) <a href="http://www.twitter.com/alexismonville">Alexis Monville</a> nous a fait un retour passionnant sur comment travailler sur <a href="">Open Stack</a>, projet open source assez connu on va dire, avec un nombre de commiters et de sociétés au board assez impressionnant. Beaucoup de patterns passionants à voir dans cette présentation. Personnellement, je valide encore une fois que je suis assez intéressé par la manière de gérer la “confiance” dans un commit, et donc un développeur :</p> <ul> <li>il faut un nombre de votes suffisant pour qu’une modification soit acceptée</li> <li>les cores commiters, dont la voix compte plus, sont promus par cooptation</li> <li>certains développeurs sont élus par les autres en tant qu’expert d’un sujet, mais ce mandat n’est pas éternel</li> </ul> <p>J’ai eu mon lot de projets où tout le monde avait le droit commiter tout le temps, quelque soit le niveau de confiance ou de qualité de code du développeur, et ce pattern aurait peut être évité les catastrophes que j’ai observé…</p> <h2 id="le-mythe-du-framework-agile">Le mythe du framework agile</h2> <p>On ne présente plus ce classique d’Arpinum :) J’ai eu un très bon accueil, ce qui flatte toujours mon égo, mais plus important, les conversations en off étaient passionnantes. Il faut maintenant que je propose la suite de cette conférence je pense : du live coding sur ces principes, et quand choisir d’utiliser un framework fullstack malgré tout.</p> <h2 id="et-surtout-plein-de-conversations">Et surtout, plein de conversations</h2> <p>J’ai pu parler avec tout un tas de gens que je ne vois que sur Twitter, qui se reconnaîtront, la liste est longue :) J’ai particulièrement aimé les échanges sur le code legacy avec <a href="https://twitter.com/johan_alps">Johan</a> et <a href="https://twitter.com/sanlaville">Rémy</a>. Leurs réflexions et leur travail sur la question est vraiment passionant, ne manquez surtout pas leur conférence à <a href="http://2014.conference-agile.fr/">Agile France</a></p> <h2 id="conclusion">Conclusion</h2> <p>Comme on peut le voir, je reviens avec des nouveaux concepts, des discussions passionantes, et 1kg de crèpe dans le ventre. Donc ne manquez pas l’édition 2015 :)</p> Les phases du programmeur illustrées http://www.arpinum.fr/2014/04/23/un-bel-exemple/ Wed, 23 Apr 2014 00:00:00 +0000 http://www.arpinum.fr/2014/04/23/un-bel-exemple <p>Comme pas mal de monde, je suis tombé sur <a href="http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html">le billet</a> de dhh enterrant le TDD. Petit rappel des faits, c’est le créateur de Ruby On Rails.</p> <p>Je trouve que c’est une très belle illustration de la dissonnance cognitive dont je parlais dans <a href="http://www.arpinum.fr/2014/04/08/les-phases-du-programmeur/">mon billet précédent</a> En fait il décrit les étapes lui même c’est assez magique :</p> <ul> <li>étape 1 : il se sent coupable de ne pas faire de tests, désagréable sensation</li> <li>étape 2 : il essaye vaguement de s’y mettre (quelques semaines, hum, 7 ans après je suis toujours en train d’en découvrir tous les jours sur le sujet)</li> <li>étape 3 : réduction de la dissonnance : TDD ça sert à rien et c’est mort, et ceux qui disent le contraire ne sont que de vilains ayatollah, bouh</li> </ul> <p>Bon je n’ai pas super envie de rentrer dans le démontage en règle de son article, je crois que je me suis déjà bien étendu sur le pourquoi du comment dans le mythe du framework agile<sup id="fnref:1"><a href="#fn:1" class="footnote">1</a></sup></p> <p>Je vais juste vous donner <a href="https://www.youtube.com/watch?v=bNn6M2vqxHE">deux liens</a> parlant de <a href="http://nerds.airbnb.com/testing-at-airbnb/">Rails et de TDD</a>, et clôturer sur ces mots hautement philosophiques de <a href="https://twitter.com/JeromeAvoustin">Jérôme Avoustin</a> qui a bien résumé l’article</p> <blockquote class="twitter-tweet" data-conversation="none" data-cards="hidden" data-partner="tweetdeck"><p><a href="https://twitter.com/oaz">@oaz</a> Je n&#39;arrive pas à enfiler mes slips et mes caleçons. C&#39;est assez ! J&#39;arrête d&#39;en mettre ! &quot;Le caleçon et le slip sont morts&quot;.&#10;OK...</p>&mdash; Jérôme Avoustin (@JeromeAvoustin) <a href="https://twitter.com/JeromeAvoustin/statuses/458977470231089153">April 23, 2014</a></blockquote> <script async="" src="//platform.twitter.com/widgets.js" charset="utf-8"></script> <div class="footnotes"> <ol> <li id="fn:1"> <p><a href="http://www.arpinum.fr/2013/08/23/le-mythe-du-framework-agile/">L’article</a> et <a href="http://www.pinterest.com/arpinumfr/conf%C3%A9rences/">les vidéos sur notre pinterest</a> <a href="#fnref:1" class="reversefootnote">&#8617;</a></p> </li> </ol> </div> Les phases du programmeur http://www.arpinum.fr/2014/04/08/les-phases-du-programmeur/ Tue, 08 Apr 2014 00:00:00 +0000 http://www.arpinum.fr/2014/04/08/les-phases-du-programmeur <h2 id="ou-comment-intresser-un-programmeur--la-programmation-propre">Ou comment intéresser un programmeur à la programmation propre</h2> <p>Je rebondis sur le <a href="http://agilitateur.azeau.com/post/2014/03/27/Comment-convaincre-un-d%C3%A9veloppeur-qu-un-jeu-de-balle-peut-l-aider-dans-son-m%C3%A9tier#rev-pnote-493-3">billet d’Olivier</a>, car il fait parfaitement écho à certaines de mes interrogations de ces derniers mois. Cet article représente mes réflexions du moment, pas une vérité transcendantale et universelle. Je vais m’appuyer sur mes vagues connaissances en plus des biais cognitifs et des motivations, autant dire clairement que je suis à peine un apprenti sorcier dans ces domaines. Allez c’est parti.</p> <p class="center"> <img src="/images/blog/phases/serious.gif" /> </p> <h3 id="le-constat">Le constat</h3> <p>C’est un peu comme s’il existait les développeurs intéressés par les pratiques d’ingénierie d’un côté, et les autres de l’autre côté. «L’agile tour c’est pas pour les développeurs», «TDD c’est pas la vraie vie», voilà des remarques qui me brisent un peu le cœur mais que j’entends très régulièrement. Pourtant, écrire du bon code, ce n’est pas une lubby d’extrêmistes qui aiment bâtir des cathédrales, c’est vital pour un <a href="http://blog.pluralsight.com/7-reasons-clean-code-matters?utm_source=newsletter&amp;utm_medium=email&amp;utm_campaign=blog">certain nombre de raisons</a>.</p> <p>En gros, mes conférences, que je considère comme étant pour développeurs, vu que j’en suis un, sont assez souvent acceptées dans le monde des conférences agiles, mais pour le moment, le succès est mitigé dans les conférences «100%» développeurs : JUGs, Devoxx, etc. D’un côté, on va me dire qu’un agile tour c’est pas pour les développeurs, et d’un autre côté on va me dire que la manière dont je code en fait 7 heures par jour ne marche pas dans «la vraie vie».</p> <h3 id="un-modle-dexplication">Un modèle d’explication</h3> <p>Qui est le développeur de 2014 ? En inspectant ma propre carrière, j’en suis venu à me fabriquer une sorte de petit modèle d’explication. D’explication de quoi ? Et bien essentiellement de ce qui fait qu’en début de carrière, les conférences qui me tiennent à cœur aujourd’hui ne m’intéressaient pas. </p> <h4 id="les-deux-phases-de-la-vie-dun-programmeur">Les deux phases de la vie d’un programmeur</h4> <p>Est-ce que vous vous souvenez de votre première expérience de conduite ? En ce qui me concerne, les débuts étaient assez délicats. Pourquoi ? Car les mécanismes les plus élémentaires de la conduite me demandaient un acte conscient : changer une vitesse, garder ma trajectoire, faire attention à mon environnement, etc. Le souci du coup, c’est que mes réflexes n’étaient pas optimum, car une grande partie de mon attention était accaparée par ces détails. Avec le temps, ces mécanismes sont devenus des automatismes, qui ne me demandaient plus une concentration consciente. C’est ce qui entraine parfois ce fameux effet : « ah je suis arrivé, mais je n’ai aucun souvenir de la route.» Il parait que c’est le mécanisme standard d’apprentissage de notre cerveau : pour libérer du « temps de traitement conscient », notre cerveau va faire descendre en inconscient tout ce qu’il peut. Par exemple, reconnaître un visage ne vous demande pas d’effort (normalement), manipuler votre main ne vous demande pas d’effort, etc. </p> <p>Quand je me rappelle mes débuts en programmation, je trouve que ce modèle s’applique bien : écrire un if me demandait un effort conscient, compiler me demandait un effort conscient, etc. C’est que j’appellerais la phase 1. Elle a duré pas mal de temps chez moi. Du moment où je me suis mis à programmer vers 14 15 ans, à la fin de mes 5 premières années d’expérience (à peu prêt). Du coup, mon cerveau étant intégralement pris par le «il faut que ça fonctionne», il restait peu de place pour le «il faut le faire bien». Ce qui caractérise à mes yeux également cette phase , c’est que si le Jean-Baptiste d’aujourd’hui allait s’adresser au Jean-Baptiste de cette époque, ils ne se comprendraient absolument pas. </p> <p class="center"> <img src="/images/blog/phases/fight.gif" /> </p> <p>Que se passe-t-il en phase 2 ? Etant donné que la technique est à peu près maîtrisée, le cerveau est libéré pour d’autres tâches. En programmation, cela veut dire que notre cerveau est libéré pour réfléchir au pourquoi nous faisons ce que nous faisons : quel est le problème du client ? Quelle est la meilleure manière d’atteindre cet objectif ? En d’autres termes, il devient possible de se poser la question «comment le faire bien ?». </p> <h4 id="de-la-technique--apprendre">De la technique à apprendre</h4> <p>De quoi était fait mon travail pendant cette phase 1 ? De programmation par coincidence. C’est à dire, sans citer cette grande boîte de e-commerce française chez qui j’étais, mon quotidien consistait à écrire des procédures stockées (beaucoup), et l’ASP qui appelait ces procédures, et générer du XML mangé par des XSLT. Je ne sais pas si vous sentez le concept, mais dans une telle approche, on ne se pose pas vraiment la question de coder proprement, du moins pas dans mes termes actuelles. Je me posais la question de commenter ou pas, de comment structurer mes 6000 lignes (sic) de prostock pour que je m’y retrouve, mais si vous me parliez de principes SOLID, de design patterns, d’architecture hexagonale, de TDD, je vous aurais taxé « d’architecte » ou de développeur non pragmatique, il n’y avait juste pas de lien entre mon quotidien et ces pratiques. En revanche, je suis allé aux Tech Days, je voulais qu’on me présente les nouveautés de SQL Server, savoir ce que ça allait changer à mon quotidien </p> <h4 id="une-illusion--perdre">Une illusion à perdre</h4> <p>Le souci dans tout ça, c’est que chaque jour je ne devenais pas meilleur programmeur, je devenais juste plus fort à gérer cette manière de faire. Or, tout système a une vélocité naturelle qu’il est impossible de dépasser, et la vélocité de celui-ci était très limitée.</p> <p>Pourtant à l’époque, je me pensais pas mauvais. J’avais même eu cette grandre phrase lors d’une soirée : «honnêtement je ne vois pas ce qu’il me reste à apprendre». Je pense que trois éléments m’empéchaient de devenir meilleur : </p> <ul> <li>Je voulais avoir une sensation de maîtriser mon travail, une des trois motivations intrinsèques<sup id="fnref:1"><a href="#fn:1" class="footnote">1</a></sup></li> <li>La dissonnance cognitive, rien que ça <sup id="fnref:2"><a href="#fn:2" class="footnote">2</a></sup></li> <li>L’effet Dunning-Kruger <sup id="fnref:3"><a href="#fn:3" class="footnote">3</a></sup></li> </ul> <p>Ok comment j’assemble ces trois éléments ? L’effet Dunning Kruger en gros me dit qu’à l’époque, la quantité de choses que je ne savais pas m’empêchait d’évaluer correctement la qualité de mon travail. Je le jugeais correct exclusivement à la lumière de mes compétences de l’époque, qui étaient trèèèès faibles. (je vous rassure, il me reste encore beaucoup de chemin à parcourir). A côté de ça, mon envie de maîtriser ce que je faisais ne me donnait pas envie d’entendre qu’en fait, je ne savais vraiment rien. Du coup, quand par un biais x ou y j’entendais une remise en question, cela créait cette désagréable dissonance cognitive : je souhaite maîtriser mieux mon travail, mais la piste que l’on me propose a l’air de demander trop de temps et d’efforts, ou bien me met mal à l’aise tant elle a l’air de montrer qu’il me reste un gouffre à franchir. Du coup, comme <a href="http://fr.wikipedia.org/wiki/Dissonance_cognitive#Le_Renard_et_les_Raisins">le renard</a>, j’ai décidé que ces raisins ne valaient pas la peine d’être mangés. Le fameux «TDD ça ne marchera pas dans mon quotidien», ou mon fameux à l’époque «les design patterns ça sert à rien, ici on est pragmatique on fait ce qui marche». </p> <p>Il est tout à fait possible de rester bloquer éternellement dans cette phase de cette manière, à répéter la même année chaque année, à avoir l’impression d’être bon car on a atteint la vélocité maximum de ce système. Il faut réussir à perdre cette illusion : la seule manière d’apprendre, c’est d’accepter que l’on ne sait rien, et de laisser l’égo au vestiaire.</p> <h4 id="cette-tape-est-ncessaire">Cette étape est nécessaire</h4> <p>Je peux paraître très négatif, mais cette étape est malgré tout nécessaire. La programmation demande de maîtriser ou d’apprendre beaucoup de concepts. Comment réfléchir à écrire un bon test, si le simple fait d’écrire un for accapare 90% de notre cerveau ? Comment réfléchir aux principes SOLID alors qu’on ne manipule pas des classes au quotidien, ou qu’on en fait apparaître par hasard ? Comment prendre des risques pour apprendre à faire mieux, si j’ai la pression au quotidien ? Depuis 3 ans que j’enseigne, je peux effectivement vous faire ce retour : tenter d’enseigner TDD à quelqu’un qui commence juste la programmation, ça ne marche absolument pas. Pour démarrer, il faut donc cette phase d’expérimentation, de dialogue simple entre le code et le résultat visuel. Ce n’est pas un hasard si j’ai appris la programmation avec VB, le résultat visuel était là rapidement. Ce n’est pas un hasard si je me suis mis à PHP pendant ma 1ère S : je tapais quelques lignes, je faisais F5 dans le navigateur et pouf magiquement la page avait un nouveau comportement. Ce dialogue code / visuel, cet émerveillement d’avoir l’impression de maîtriser sa machine, c’est vraiment la clef de la création de ma passion.</p> <h4 id="le-dclencheur">Le déclencheur</h4> <p>Il n’y a pas vraiment de magie, ce qui m’a fait quitter cette phase c’est l’accumulation de plusieurs facteurs : </p> <ul> <li>démission de mon poste, poussé par l’envie de découvrir autre chose</li> <li>la rencontre avec quelqu’un déjà plus avancé sur le chemin de l’amélioration continue</li> <li>l’émerveillement lié à la mise en place de TDD</li> <li>la lecture de DDD et eXtreme Programming explained</li> </ul> <p class="center"> <img src="/images/blog/phases/happy.gif" /> </p> <p>A partir de là, mon quotidien n’a plus consisté à assembler des bouts techniques de bric et de broc, mais à tenter de faire bien les choses. Le « ça fonctionne » est devenu le strict miminum de mon travail, et non plus l’objectif. Le «d’abord faite le marcher, puis faite le marcher bien, puis faite le marcher vite» est devenu mon mantra. A partir de là, une conférence me présentant un outil, me présentant un framework, a clairement commencé à m’ennuyer. Je n’ai plus cherché de missions pour apprendre une nouvelle technologie, mais pour avoir la possibilité de faire mieux. Nous avons créé <a href="http://tiron.fr">Tiron</a> dans cet objectif : apprendre à faire mieux, sans contrainte, et c’est maintenant le crédo d’Arpinum. Avant d’être une boîte qui nous fait vivre, Arpinum est avant tout une boîte qui nous fait apprendre. </p> <h3 id="revenons--la-question">Revenons à la question</h3> <p>Donc, nous avons vu mon début d’explication sur pourquoi il est difficile de parler à la majorité des développeurs. Si cette hypothèse détient une partie de vérité (tous les modèles sont faux, certains sont utiles), nous pouvons alors tenter de fabriquer un discours qui leur parle. J’ai le sentiment qu’une majorité des développeurs intéressés par ces conférences sont quelque part coincés entre les deux phases: ils veulent faire mieux, sinon ils ne prendraient pas de leur temps pour venir. Ils sont passionnés également. Mais il est encore difficile de parler de TDD, de refactoring, car leur quotidien, souvent dans des boîtes oldshool, avec architecture imposée, 0 test, etc : ces sujets ne résonnent pas avec les sujets de qualité de code. Ce que m’a montré mes quelques années d’enseignement, c’est qu’un module de 20h avec des 4ème année suffit à « convertir » au moins une certaine fraction des élèves à ces approches. Mais le cours est « forcé », comment attirer de gens libres de leur temps dans un module de 20h parlant de TDD? </p> <h4 id="la-stratgie-gageot">La stratégie Gageot</h4> <p>Je ne sais pas si vous le connaissez, mais <a href="https://twitter.com/dgageot">David Gageot</a> est un développeur à suivre : ses conférences sont excellentes. Ses sessions de live coding sont purement des démonstrations de refactoring, de tests bien fait, etc. Son Github est rempli de pépites de code, bref, il remplit parfaitement mes critères d’un excellent développeur. Pourtant, si vous prenez <a href="http://parleys.com/play/5148922a0364bc17fc56c85a">le titre de cette session</a> vous notez l’absence de mots clefs « agiles » . Cependant, cette présentation consiste à faire le Kata Gilded Rose, en appliquant la technique du Golden master, tout en maîtrisant à la perfection les outils de refactoring de son IDE. Cette session a eu le grand succès qu’elle mérite, je l’ai vu au Bordeaux JUG, et le public était conquis. Ce public qui massivement ne vient pas à un Agile Tour, ne vient pas à une session TDD ou refactoring, est non seulement venu, mais a adoré. La session se serait nommée « démonstration de refactoring de code legacy par la Kata Gilded Rose », aurait-elle eu le même succès ? Est-ce donc ça la technique ? Dissimuler notre contenu derrière des buzz words ? Cloud, Legacy, etc ? Nous avons mené une petite expérience à Arpinum. Grâce à <a href="https://twitter.com/guillaume_agile">Guillaume Saint-Etienne</a>, nous avons monté une formation parlant de l’architecture agile présentée lors de ma session « Le mythe du framework agile »<sup id="fnref:4"><a href="#fn:4" class="footnote">4</a></sup>. Pourtant, cette formation s’appelle officiellement « Développement Web en Java ». Nous avons proposé cette formation dans les milieux très friands de formations techniques : succès. Il y a deux ans, nous avons tenté une formation TDD avec les mêmes personnes : aucune inscription. </p> <h4 id="start-with-why">Start with why</h4> <p>Le pourquoi est toujours massivement important dans la motivation de quelqu’un a participé à une entreprise, une formation, etc. Nous avons vendu le pourquoi de nos conférences seulement sur ce postulat : « le code propre, c’est important ». Ce « pourquoi » parle dans un Agile Tour (et encore), mais pas dans une conférence plus technique j’ai l’impression. Nous devons donc mettre le pourquoi du côté de la technique dans une conférence technique : le cloud, le web, l’architecture, etc. TDD, les principes SOLID, ne peuvent pas être le but de la session, mais le comment. Le mythe du framework agile a eu des échos dans des milieux moins agiles qu’à mon habitude, car mon « pourquoi » j’ai l’impression ne se situait pas sur les pratiques agiles en elles mêmes, mais sur un terrain plus technique : les frameworks. </p> <h2 id="pour-conclure">Pour conclure</h2> <p>Voilà, cette analyse vaut ce qu’elle vaut, mais elle a le mérite au moins de proposer un modèle qui s’applique à ma carrière. Comme je n’ai pas l’impression d’être si particulier que ça, peut-être aidera-t-elle d’autres développeurs. </p> <div class="footnotes"> <ol> <li id="fn:1"> <p>Voir <a href="https://www.goodreads.com/book/show/6452796-drive">Drive</a>, ou cette <a href="https://www.youtube.com/watch?v=u6XAPnuFjJc">vidéo</a> le résumant <a href="#fnref:1" class="reversefootnote">&#8617;</a></p> </li> <li id="fn:2"> <p><a href="http://fr.wikipedia.org/wiki/Dissonance_cognitive#Le_Renard_et_les_Raisins">Dissonnance cognitive</a> <a href="#fnref:2" class="reversefootnote">&#8617;</a></p> </li> <li id="fn:3"> <p><a href="http://fr.wikipedia.org/wiki/Effet_Dunning-Kruger">Effet Dunning-Kruger</a> <a href="#fnref:3" class="reversefootnote">&#8617;</a></p> </li> <li id="fn:4"> <p><a href="http://www.ustream.tv/recorded/40584886">Partie 1</a> et <a href="http://www.ustream.tv/recorded/40585651">partie 2</a> <a href="#fnref:4" class="reversefootnote">&#8617;</a></p> </li> </ol> </div> La Liste http://www.arpinum.fr/2014/01/20/la-liste/ Mon, 20 Jan 2014 00:00:00 +0000 http://www.arpinum.fr/2014/01/20/la-liste <img class="right_pic" src="/images/blog/liste/liste.jpg" alt="la liste d'arpinum"/> <p> Il y a quelques jours, <a href="https://medium.com/tariqs-thoughts/e222faa21947">Tarik Krim</a> a donc créé de grands remous dans la force en publiant <a href="https://medium.com/tariqs-thoughts/e222faa21947">cet article</a> parlant de sa future liste de «la fine fleur de nos talents numériques». </p> <p>Malgré une intention louable de vouloir rappeler à la France que faire de bons produits, bah ça demande de bons développeurs, nous sommes d'accord que cette liste d'accointances semble une bien étrange manière de résoudre ce problème. Je n'ai pas forcément besoin d'en dire beaucoup plus, étant donné qu'<a href="https://twitter.com/avernois">Antoine Vernois</a> a déjà fait un excellent job <a href="https://blog.crafting-labs.fr/?post/2014/01/17/les-100-meilleurs-developpeurs-preferes-des-francais"> sur son blog</a> pour faire le tour du problème. Il y a eu également de nombreuses réactions sur twitter allant dans ce sens, et c'est très bien. </p> <p>Le billet d'Antoine en revanche, m'inspire une réaction plus intéressante je l'espère. Nous ne pouvons être jugé que par nos pairs, et mon critère à moi se situe effectivement du côté de la qualité du code, et surtout du nombre de développeurs que nous avons pu aider dans notre carrière. C'est pourquoi, pour tenter modestement de détourner une liste pas terriblement maligne ni très utile, pourquoi ne ferions-nous pas, nous les développeurs artisans anonymes de France (acronyme à déposer, ça claque DAAF), chacun notre liste des développeurs qui nous ont aidé d'une manière ou d'une autre dans notre voie ? Cette liste se doit d'être non ordonnée, non exhaustive, et ne contenir que des développeurs français. Elle peut ensuite contenir bien sur des personnes avec qui nous avons travaillé, des personnes qui nous ont inspiré, des personnes qui nous ont montré tout ce qu'il ne fallait pas faire, bref, une personne à qui vous voulez faire un gros poutou et dire <a href="http://youtu.be/jrdYgY-UiCM?t=2m27s">«Merci, j't'aime putain»</a>. </p> <p> Alors sans tambour ni trompette, à la manière d'un Guillame et son <a href="http://guillaumevincent.com/2013/11/15/Merci.html"> Merci</a>, voici ma liste non ordonnée (notez que c'est dont un bel exemple d'un &lt;ul&gt;, vive le web sémantique) non exhaustive des développeurs qui m'ont aidé ou qui m'aident toujours, d'une manière ou d'une autre, à être un meilleur développeur chaque jour : </p> <ul> <li>Luc Mazardo</li> <li>Colin Garriga Salaün</li> <li>Jacques-Antoine Masse</li> <li>Cyrille Matraire</li> <li>Charles Couillard</li> <li>Alban Guffroy</li> <li>Bertrand Bougon</li> <li>Emmanuel Gaillot</li> <li>Michael Borde</li> <li>Jonathan Perret</li> <li>Pascal Grange</li> <li>David Gageot</li> <li>Grégoire Devaux</li> <li>Guillaume Lebur</li> <li>Antoine Vernois</li> <li>Rémy Sanlaville</li> <li>Laurent Bossavit</li> <li>Fabien Bézagu</li> <li>Guillaume Vincent</li> <li>Thierry Cros</li> <li>Johan Martinsson</li> <li>Jérôme Avoustin</li> <li>François Baronnet</li> <li>Jean Laurent de Morlhon</li> <li>Thibaud Gavard</li> <li>Sami Jaber</li> <li>Guillaume Saint-Etienne</li> <li>Thierry Vazzoler</li> <li>Millicent Billette</li> <li>Christophe Chaligne</li> <li>Stéphane Blondon</li> <li>Mickael Ruellan</li> <li>Didier Girard</li> <li>David Dumon</li> <li>Pascal Menardais</li> <li>Olivier Azeau (ok joker il est plus développeur :))</li> <li>Olivier Biaus</li> <li>Thomas Marty</li> </ul> <p>Voilà, oui j'ai oublié plein de monde, et alors, c'est le but vu que cette liste n'a aucune valeur!</p> <p>P.S : ne bataillez pas pour l'orthographe de vos noms, j'ai fait ce que j'ai pu :) </p> Pourquoi nous ne faisons plus de l'AGILE http://www.arpinum.fr/2013/10/31/pourquoi-nous-ne-faisons-plus-de-lagile/ Thu, 31 Oct 2013 00:00:00 +0000 http://www.arpinum.fr/2013/10/31/pourquoi-nous-ne-faisons-plus-de-lagile <p class="credits"> Ceci est un article initialement écrit pour le site de l'agile tour bordeaux 2013 </p> <p>Voilà un titre bien accrocheur, surtout pour un sponsor Agile Tour Bordeaux depuis plusieurs années. Alors je vous vois venir : "Oui, encore un titre racoleur pour attirer le chaland et vendre leur sauce !", mais laissez-moi vous expliquer un peu notre histoire. </p> <h3>Au commencement, il y avait <strike>les dinosaures</strike> une SSII et des développeurs voulant bien faire leur travail. </h3> <p> Nous étions quelques développeurs dans un forfait se passant plutôt mal. Dans un refus du statut quo et de laisser le projet mourir, nous constations tout ce qui n'allait pas : <ul> <li>Forfait au périmètre figé, alors que c'était la nième tentative du client de réussir le projet,</li> <li>chef de projet despotique, dont le credo était, je cite, "Vous n'avez pas besoin de réfléchir, je l'ai fait pour vous", </li> <li>choix de priorisation basés sur la technique : "Bah oui, il nous faut les fondations pour faire une maison", </li> <li>choix d'architecture douteux : "Oui je sais que j'ai tort, mais je ne peux pas revenir sur ce que j'ai dit, sinon ça saperait mon autorité", </li> <li>aucune confiance dans l'équipe : "On ne peut pas vous faire confiance à vous, les développeurs".</li> </ul> </p> <img class="img-responsive pull-left" src="/images/blog/revolution.jpg"/> <p> Bref, excédés, nous avons mené une révolution non violente (ou pas), pour changer tout ça, basée sur la responsabilisation de l'équipe pour qu'elle refuse la pression, les intimidations quotidiennes, la non qualité et la faible estime de soi. Tous ces travers étaient entretenus au quotidien pour garder l’équipe sous contrôle. Ce que nous avons découvert alors, c'est qu'une équipe de professionnels, sûre de ses choix, se met à refuser ce <a href="http://www.arpinum.fr/2011/09/28/le-middle-management-cause-de-tous-les-problemes-%25c2%25a0/">management archaïque</a>. Et in fine, la SSII a décidé de se débarrasser de ce chef de projet encombrant. Nous avons réalisé qu'une transition vers l'agilité, la vraie, passe par les développeurs. Vous pouvez redécorer comme vous voulez les murs de votre prison, mais si vous refusez toujours d'étudier le métier de développeur, vous passez à côté de l'agilité. </p> <div class="clearfix"></div> <h3>Mais alors, c'est super ? </h3> <img class="img-responsive pull-right" src="/images/blog/saucisses.jpg"/> <p>Ce qui devient intéressant, c'est la réaction de la SSII face à notre révolution tranquille : "Ah oui c'est super votre truc, l'Agile là. Bon on va vous embaucher un Scrum Master, parce que bon, vous, vous êtes développeurs, vous ne savez pas de quoi vous parlez". La première action de ce nouveau Scrum Master a été d'acheter Jira, et de remplacer nos belles histoires au mur par leurs numéros technique… Ironique, non? </p> <p>La suite de l'histoire est, bien sûr, que toute trace de l'agilité de développement a disparu pour laisser la place à une agilité de bastringue, juste utile pour tenter de vendre toujours les mêmes forfaits. Du respect des développeurs, de la confiance, de la formation continue, il ne restait rien. </p> <p>Au début de l'aventure dans cette SSII, notre tenacité à mettre en place l'agilité nous a valu bien des déboires. Et quand ils ont pris le train de la lucragilité, nous, nous étions toujours mal vu, car nous parlions du métier de développeur, pas seulement de Scrum. </p> <h3>Vers d'autres horizons</h3> <p> Nous sommes donc partis fonder notre propre société, pour éditer notre logiciel dans un premier temps, puis proposer de la formation et de l'accompagnement, armés de l’expérience acquise sur nos produits. Le constat de ces quelques années nous laisse également un léger goût amer dans la bouche. Nous étions persuadés que le simple fait d'intervenir dans le cadre d'une mise en place de l'agilité cautionnerait beaucoup de ces pratiques que nous voulions instaurer. Que nenni. Nous avons accompagné des sociétés voulant de l'agilité pour les managers, mais les développeurs, quelle importance ? Pire, nous avons rencontré des sociétés voulant se servir de nous comme caution pour pouvoir blâmer leurs développeurs, en disant que la boîte avait fait tous les bons choix, mais que si rien ne marchait, c'était bien de la faute de ces fainéants. </p> <p>Quelques morceaux choisis :</p> <ul> <li>"Comment-ça notre architecture n'est pas testable, mais c'est pas ça le souci!",</li> <li>"Comment ça il faut arrêter d'imposer des délais, mais ils vont rien faire si on ne le fait pas !",</li> <li>"Comment ça ce sont les équipes qui doivent prendre les décisions techniques ! C'est inadmissible j'ai un architecte qui nous coûte très cher qui a inventé la meilleure solution!". </li> </ul> <p> Alors oui, je vous rassure, de loin en loin nous avons obtenu de beaux résultats, et avons croisé des coachs qui nous inspirent beaucoup. Cependant, dans ces luttes pour faire considérer le développement comme un métier, nous avons souvent constaté que nous nous battions contre les marchants du temple, prêts à valider toutes les lubies du client pour pouvoir signer un contrat, sans se soucier des équipes qui continuent à souffrir dans des conditions dignes des temps modernes. </p> <p> Mal vus au début du mouvement vers l'agilité, "car ça ne marche pas comme ça un projet", nous le sommes maintenant de nouveau car "non l'agilité ça change rien au développement, formez mon manager plutôt à bien utiliser la vélocité comme outil de coercition". </p> <h3>Et donc</h3> <p> Donc, si l'agilité devient officiellement un outil supplémentaire pour continuer à ignorer le métier de développeur, nous ne disons plus que nous en faisons. Ô oui bien sûr, nous nous considérons agiles jusqu'au bout des ongles, et ça sera toujours, je l'espère, le secret de nos réussites, mais nous ne pouvons tout simplement pas lutter contre la horde de coachs éphémères promettant que non, l'agilité n'a rien à voir avec le développement. Si vous avez compris vous aussi, que le bon produit ne peut pas émerger d'équipes pressurisées et stigmatisées, alors nous pouvons travailler ensemble. Si vous avez compris que développer est un métier, qu'il faut toute une vie pour prétendre le maîtriser, alors nous sommes heureux de parcourir ce chemin avec vous. Si vous avez réalisé que les entreprises qui ont changé le monde ces 10 dernières années ont été créées par des développeurs passionnés, et non par un étudiant d'HEC, alors nous nous entendons. Et finalement, si vous avez compris que l’excellence technique est au service du bon produit, alors nous partageons les mêmes valeurs. </p> <p>En attendant, nous sommes un atelier logiciel, et nous faisons d'excellents produits pour des clients qui ont compris. </p> <p class="center"> <img src="/images/blog/swc.jpg"/> </p> <div class="credits"> <span>Crédits photos :</span> <ul> <li>Saucisse, par <a href="http://www.flickr.com/photos/bitterjug/with/989972343/">Bitterjug</a></li> <li>Revolution, par <a href="http://www.flickr.com/photos/20872388@N06/with/5572306965/">Peej</a></li> <li>Software craftsmanship, par <a href="http://leanmagazine.net/">Leanmagazine</a></li> </ul> </div> <strike>Winter</strike> Agile Tour is coming http://www.arpinum.fr/2013/10/02/agile-tour-is-coming/ Wed, 02 Oct 2013 00:00:00 +0000 http://www.arpinum.fr/2013/10/02/agile-tour-is-coming <img src="/images/blog/agiletour/agiletour.jpg" alt="agile tour" class="right_pic" /> <p> Ça y'est la saison des <a href="http://agiletour.org">agile tour</a> et pas tour est de retour (oui Grenoble n'est pas un agile tour, ne l'oublions pas s'il vous plait, ou <a href="http://www.agilex.fr/">Alexandre</a> va encore devenir tout rouge). L'agile tour, c'est cette parenthèse enchantée de fin d'année ou nous rechargeons nos batteries auprès de la très sympathique communauté du même nom. </p> <h2>Bordeaux</h2> <iframe width="560" height="315" src="//www.youtube.com/embed/SI0PKn4jBMo" frameborder="0" allowfullscreen></iframe> <p><a href="http://agiletourbordeaux.okiwi.org/">L'agile tour Bordeaux</a> et Arpinum, c'est une vieille histoire d'amour qui remonte à avant même notre création, puisque nous étions co-organisateurs de l'étape bordelaise dès 2009. La nouveauté cette année, c'est qu'aucun Arpinumien n'est dans le comité d'organisation. Nous manquions un peu de temps pour lui donner tout l'amour qu'il mérite, mais la nouvelle équipe fera, je suis sûr, un excellent boulot. En attendant, nous restons bien entendu sponsor, et orateurs. <p class="center"> <img src="/images/blog/agiletour/agiletourSponsor.jpg" alt="sponsor" class="center_pic" /> </p> <p>Outre notre mot d'ouverture, vous pourrez venir nous voir si tout va bien aux sessions suivantes (le programme n'a pas encore été officiellement publié au moment où j'écris ces lignes) : </p> <ul class="liste-arpinum"> <li> Le mythe du framework agile <p>C'est une session où je parlerai du piège de sortir des frameworks full stack à tout bout de champ. <a href="http://www.arpinum.fr/2013/08/23/le-mythe-du-framework-agile/">Ce billet</a> est une bonne introduction à ce sujet.</p> </li> <li>Démonstration TDD ou Pratiquer TDD <p>Nous ne savons pas encore laquelle des deux a été choisie (peut être aucune d'ailleurs), mais dans tous les cas, si vous voulez apprendre le TDD, il faut aller voir Michael. Même après 4 ans d'agile tour, nous pensons qu'il est juste toujours indispensable de faire une présentation de cette discipline, qui pour notre part a drastiquement amélioré notre code, et notre plaisir à le produire.</p> </li> </ul> <p class="center"><img src="/images/blog/agiletour/agiletourSpeakingAt.jpg" alt="" id="center_pic" /></p> <h2>Toulouse</h2> <p><a href="http://tour.agiletoulouse.fr/">L'organisation Toulousaine</a> nous a honoré cette année encore en acceptant nos propositions.</a> Vous y retrouverez à nouveau le mythe du framework agile, et Démonstration TDD.</p> <p>Avec ou sans Arpinum de toute manière, Agile Tour Toulouse reste un évènement incontournable, où le simple plaisir de retrouver les agilistes toulousains justifie amplement le déplacement. Si vous cherchez plus de justifications pour votre boss, Olivier s'est fendu <a href="http://agilitateur.azeau.com/post/2013/10/01/10-raisons-de-ne-pas-manquer-l-Agile-Tour-Toulouse-2013"> d'un petit argumentaire.</a></p> </p> <h2>Grenoble</h2> <p>Enfin nous finirons notre tour d'horizon à <a href="http://2013.agile-grenoble.org/">Grenoble</a>. Pour la première fois, nous allons y parler. Oui je vous le donne en mille, du mythe du framework agile et de TDD. </p> <p>Au fils du temps, Agile Grenoble s'est imposé comme un (le ?) plus gros évènement parlant d'agilité en France, nous sommes donc encore une fois très honoré d'y avoir notre mot à dire.</p> <p class="center"><img src="/images/blog/agiletour/winter-is-coming.jpg" alt="" /></p> <h2>Et les autres…</h2> <p>Bien sur, nous aurions aimé avoir le temps (et les moyens :)) de continuer notre tour de France, mais que voulez-vous ma bonne dame, nous ne pouvons pas passer notre vie à jouer du <a href="http://www.youtube.com/watch?v=M5ZM7kzYiXM">Banjo</a> :) .</p> Le mythe du framework agile http://www.arpinum.fr/2013/08/23/le-mythe-du-framework-agile/ Fri, 23 Aug 2013 00:00:00 +0000 http://www.arpinum.fr/2013/08/23/le-mythe-du-framework-agile <p>Je tente cette année de mettre au point une nouvelle conférence, dont le titre encore provisoire serait : le mythe du framework agile. Je vais tenter de vous en donner un avant gout dans ce billet. </p> <p>Le sujet, cela fait plusieurs années qu'il nous trotte dans la tête avec les autres arpinumiens. Notre approche, depuis un certain temps maintenant, consiste à assembler des bibliothèques selon nos besoins plutôt que de suivre les instructions d'un framework, et nous regardons d'un oeil dubitatif les mouvements de foules vers les frameworks "full stack". C'est là normalement que nous nous faisons taxer de fan de JBoss, car c'est vrai que dans le monde, il n'y a que les fans de play d'un côté, ceux de JBoss de l'autre (sarcasme). </p> <p>Si nous parlons d'un gros framework propriétaire maison, comme nous avons pu en croiser beaucoup chez des gros comptes que nous ne citerons pas, il n'y a souvent pas de débat, "bien sur que c'est le mal". Les réactions en formation ou autre sont souvent : <ul class="liste-arpinum"> <li>il est mal foutu, il nous ralentit</li> <li>il nous empêche de faire des tests découplés, il est envahissant</li> <li>il n'a pas tout prévu, donc dans notre cas spécifique on doit faire des hacks de folie pour atteindre nos objectifs. </li> </ul> </p> <p> Pourtant, la promesse faite à la société qui a financé ce désastre, c'est des coûts de développement réduits, puisque tout est fait, la possibilité d'embaucher de mauvais développeurs, car tout le travail compliqué a été fait par les stars qui ont codé le bousin. </p> <p>Ok donc tout le monde est d'accord avec ça. C'est bien. Maintenant, quelles différences existent entre ces gros frameworks, et disons, Play ? Ou Grails ? Ou Rails ? Ou Roo ? Ou Cake ? Ou Django ? (oui j'ose). Les promesses sont les mêmes pourtant, cet espoir de faire plus vite au prix d'un couplage très fort avec l'outil si on n'y prend pas garde. Ne sommes-nous pas en train de faire mieux la mauvaise solution ? (et encore, quand on regarde certains, on peut difficilement parler de "mieux"). </p> <h2>Ou mettre le métier donc ? </h2> <p>Si on regarde un tutoriel bateau sur ce genre de framework, on se retrouve souvent avec un gros hello world faisant du CRUD auto-généré pour vite vite aller mettre des données en base. C'est fantastique, maintenant je voudrais voir une véritable application s'il vous plait, pas un moteur de blog ou une todolist, car bon, moi j'en trouve pas tant que ça des clients qui veulent un nouveau moteur de blog. Moi mes clients, ils ont des problèmes métiers à résoudre, pas des tables à remplir. Et ou donc mettre son métier dans ces frameworks ? Bien souvent, il se retrouve éclaté un peu dans la vue, un peu dans le contrôleur, et un peu dans le «modèle». </p> <p>Premier constat, malgré les termes ambigus, le modèle n'est pas le métier dans ces frameworks, mais juste un accès à la base, et la base n'est pas le métier. </p> <p>Serait-ce donc dans les contrôleurs qu'il faut chercher notre métier ? Non plus, un contrôleur doit juste lire l'entrée de l'utilisateur et le convertir en un signal compréhensible pour le métier. Sinon, la promesse de duplication est bien forte. </p> <h2>Optimiser pour la création, poussif pour la maintenance</h2> <p>L'argument souvent invoqué pour vendre ces frameworks, c'est la rapidité avec laquelle nous allons créer une application. Hop en 2 mn j'ai de jolis formulaires qui vont en base. Non seulement, cette approche est déjà un soucis vis à vis du métier, car je ne veux pas mettre un formulaire en base, mais appliquer un cas d'utilisation, mais en plus, il se cache une vérité plus difficile derrière : une application est beaucoup plus maintenue qu'elle n'est créée. Optimiser pour la création semble donc être un mauvais pari, mieux vaut optimiser pour la maintenabilité. Et comment optimise t'on pour la maintenabilité ? Il n'y a pas de secret : avec du faible couplage, sans duplication, en taclant les concepts métiers au coeur de l'application, et avec des tests unitaires, de préférence apparus via TDD. Si vous pensez que vous n'avez pas le temps, jetez un coup d'oeil à ce petit <a href="https://twitter.com/AntoineCezar/status/365880336380473344/photo/1">schéma</a> : (cc <a href="http://twitter.com/AntoineCezar">@AntoineCezar</a>)</p> <p>J'ai vu beaucoup trop d'applications démarrer au quart de tour, puisqu'il suffisait de remplir les trous laissés par la génération de code, pour ensuite petit à petit s'embourber au fur et à mesure que la duplication de code augmentait. </p> <h2>C'est quoi une architecture agile ? </h2> <p>Le pitch de notre architecture est donc de ne pas se faire utiliser par un framework, mais d'utiliser des bibliothèques pour faire le boulot. </p> <p>En théorie, rien ne s'oppose à bien utiliser ces frameworks correctement, mais j'ai l'impression qu'il existera toujours cette sensation que nous luttons contre le framework. Rails, <a href="http://twitter.com/DHH">DHH</a> le dit lui-même, sert à gérer des applications comme celles de 37signals : c'est à dire très peu de métier, voir pas du tout, qui ne grossira pas, et essentiellement de la présentation de données. Je pense personnellement que c'est très bien, mais que peu d'applications rentrent dans cette définition, tout du moins dans mon contexte de développeurs d'applications métier. Qu'est-ce donc qu'une architecture agile ? Je vais reprendre la <a href="http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf">définition</a> de Martin Fowler : une bonne architecture permet de minimiser le nombre de décisions à prendre, et de les retarder le plus possible.</p> <p>Voici la proposition que nous faisons, qui n'a rien de magique, car elle ne fait qu'être une approche <a href="http://alistair.cockburn.us/Hexagonal+architecture">hexagonale</a> matinée de <a href="http://dddcommunity.org/">DDD</a> avec une once de <a href="http://martinfowler.com/bliki/CQRS.html">CQRS</a> et une partie d'Ivar Jacobson (remis au goût du jour par <a href="http://confreaks.com/videos/759-rubymidwest2011-keynote-architecture-the-lost-years">Uncle Bob</a> </p> <p>Le métier doit être au coeur de nos préoccupations. Donc, nous le mettons au centre, et il ne dépend de personne. Nous le faisons apparaître comme nous ferions le kata du bowling. Pas de notion de base de données, pas de notion de web, tout ceci n'est que détails d'implémentation que nous retardons à plus tard. Bien découper le domaine, ou les domaines plutôt, c'est toute la partie stratégique de DDD, est critique. Pour simplifier ce billet, nous dirons juste que nous n'avons pas nécessairement un seul modèle du domaine. Par exemple, Joda Time peut être considéré comme un sous domaine de la gestion de temps. Nous utilisons également les patterns tactiques de DDD pour organiser le métier (Repository, Entity, Value Object, etc). Pour rappel, le pattern Repository n'est pas un DAO. Un DAO parle d'accéder à la base, un entrepôt est une collection (liste) d'agrégats, donc par exemple pas de méthode Update dessus. Vous vous doutez du coup également que nos objets métiers ne peuvent pas être des Active Records, nous ne sommes pas couplés à la base. </p> <p class="center"> <img src="/images/blog/frameworkagile/metier.png" alt="architecture globale" class="center_pic"/> </p> <p>Pour implémenter la persistance, nous sommes toujours un peu old school, et apprécions le mapping objet/relationnel. Enfin pour être plus précis, le mapping objet/document, nous avons codé <a href="http://mongolink.org/">mongolink</a> pour répondre à nos besoins, car nous trouvons MongoDB bien plus léger et facile d'utilisation qu'un SGBD classique. La mode est de parler d'event sourcing, je vais réserver mon jugement pour le moment. </p> <p class="center"><img src="/images/blog/frameworkagile/persistance.png" alt="architecture globale" class="center_pic"/> </p> <p>Le domaine est maintenant apparu, de préférence en discutant avec un expert du métier. Mais, il existe une infinité de possibilités pour l'utiliser, ce qui est peut être un peu trop. Hors, nos utilisateurs ont des cas d'utilisation bien précis en tête normalement : passer une commande, réserver une place, voir leurs agendas, etc. Ces cas d'utilisations, on pourrait presque imaginer en faire des histoires utilisateurs d'ailleurs. Si nous encapsulons ces cas dans un contrôleur ou une ressource, nous avons un souci. Ils seront couplés à une manière de les appeler, et tout effort de proposer plusieurs manières d'exposer le métier demandera de la duplication. Si nous avons une envie folle de brancher des tests d'acceptation automatiques, ça va être délicat de ne pas dupliquer le travail fait dans les contrôleurs. Donc notre proposition est de représenter explicitement ce cas d'utilisation dans une classe qui lui est propre, au point ou si nous voulons trouver comment une histoire est faite, il nous suffise d'ouvrir cette classe. Nous appelons une classe comme celle ci une commande, et elle est exécutée par un bus de commande. Le bus peut donc être dans le même processus que l'application, ou bien déporté via un mécanisme de messaging quelconque. La commande peut retourner éventuellement le résultat de ce calcul, sous la forme d'un DTO. Le bus de commande encapsule l'exécution dans un contexte : transaction, sécurité, etc. Le métier est libéré de cette contrainte, et nous n'avons plus besoin d'un opensessioninviewfilter. </p> <p class="center"> <img src="/images/blog/frameworkagile/commandes.png" alt="architecture globale" class="center_pic"/> </p> <p>Si nous imaginons brancher une api rest par dessus, ce n'est donc pas bien compliqué de demander à notre couche web de comprendre les entrées des utilisateurs pour en faire des commandes, et retourner le résultat de l'exécution. Si nous voulons avoir un connecteur mail, sms, ou autre, pas de souci, ces connecteurs auront la même responsabilité d'accéder aux commandes. La partie web va également avoir la responsabilité de savoir qui est connecté, pour pouvoir donner cette information à la commande. </p> <p>Pour ne pas brouiller le métier avec des considération de lecture (recherche indexée, affichage agrégé de différentes informations, pagination, tri etc), nous préférons à présent ne plus utiliser le domaine pour ces problématiques. Nous nous sommes rendus compte que bien souvent, nos agrégats sont optimisés pour l'exécution d'une transaction métier, mais s'en sortent mal pour l'affichage. Nous utilisons donc une couche assez fine de recherche, très proche du modèle de stockage, afin de profiter de ce qu'il sait bien faire : l'indexation, le tri, etc. Ces recherches sont également exécutés via un bus, encapsulant les informations de transaction et de sécurité. </p> <p class="center"><img src="/images/blog/frameworkagile/requetes.png" alt="architecture globale" class="center_pic"/> </p> <p>Bien souvent, nous faisons des applications web, avec quelques ponts vers des choses comme caldav ou des mails. Mais donc, nous devons tout de même enfin nous intéresser à ce qui est le coeur de préoccupations de tous ces frameworks full stack. Pour faire du web, au plus simple nous avons juste besoin d'une bibliothèque de routing : pouvoir associer une url à une fonction à invoquer, et une bibliothèque de templating, pour rendre l'html. En java, notre duo favori est restlet/freemarker, même si nous lorgnons vers des remplaçants. On peut ensuite complexifier le tout, en faisant une api REST, et une pure application JS ou autre pour la consommer. Nous aimons cette approche, car elle est tout simplement devenue crédible avec les évolutions techniques, et l'approche hybride ne permet plus d'économiser tant de temps que ça. Nous aimons donc Angular pour simplifier le développement de cette partie, LESS pour rendre nos css intelligibles, bootstrap ou html kickstart pour cacher nos carences de designer, underscore pour avoir un meilleur javascript, bref, vous voyez qu'il est possible de beaucoup décorer l'approche. </p> <p>Voici un schéma résumant de manière très sommaire les grands concepts : </p> <p class="center"><img src="/images/blog/frameworkagile/globale.png" alt="architecture globale" class="center_pic"/> </p> <p>Oui, ce n'est pas si compliqué que ça, et nous avons énormément de portes ouvertes pour l'étendre en fonction des besoins : <ul class="liste-arpinum"> <li>ne pas utiliser la même base pour les requêtes</li> <li>distribuer certaines parties vers d'autres applications</li> <li>avoir plusieurs options de déploiement : le métier sur son propre serveur, la webapp sur une ferme, etc etc</li> </ul> </p> <p>C'est une architecture qui nous permet de commencer par le coeur de l'application, et de retarder des décisions techniques au moment ou elles deviendront réellement nécessaires. Elle nous permet de tacler la complexité du métier au centre, de ne pas introduire de duplications, de découpler nos différents composants, sans pour autant tomber dans le syndrome passe plat d'une architecture en couche. Elle nous permet de faire évoluer le code quand nous tirons une fonctionnalité, et non pas en poussant toutes les décisions initialement. Quoi de plus agile finalement ? </p> <h2>Quelques pensées supplémentaires </h2> <p>Pour étoffer un peu le débat, voici les remarques que nous entendons le plus souvent quand nous abordons ce sujet : </p> <p class="quote">L'avantage d'utiliser Play ou autre, c'est qu'il n'y a pas besoin de savoir beaucoup coder pour atteindre un résultat.</p> <img src="/images/blog/frameworkagile/cat.jpeg" alt="laul" class="left_pic" /> <p>Je pense que le cimetière des entreprises est rempli de boîtes qui ont trouvé ça super intelligent de pouvoir embaucher des gens sachant à peine coder. Si vous empruntez cette voie, vous avez intérêt à générer un sacré paquet de cash pour absorber le coût pharaonique de maintenance que vous êtes en train d'induire. Je le sais, j'ai bossé pour une boîte qui a malheureusement confondu son incompétence avec ce qui a fait son succès. Développer est un métier, vous ne voulez PAS embaucher des amateurs pour vos développements. Vous voulez des professionnels formés, sinon préparez vous <a href="http://www.javaworld.com/javaworld/jw-08-2013/130813-orange-county-tax-system-rewrite-ends-badly.html">à ne rien avoir, malgré le prix d'appel alléchant</a>. </p> <p class="quote">C'est pour les bons cette approche</p> <p>Même type de remarque que pour la précédente. Ce n'est pas pour les bons, c'est pour les développeurs qui se sont formés, et oui je vous accorde que c'est une espère assez rare, tant la tendance est de vouloir surtout devenir chef de projet le plus vite possible. Ce n'est pas pour autant qu'il faut entretenir ce cercle vicieux de médiocrité. Embauchez moins, mais embauchez bien. </p> <p class="quote">Ok elle est chouette ton approche, mais pour une maquette c'est pratique Play</p> <p>Je suis sur que le créateur de Play est content d'avoir passé des heures à fabriquer une technologie pour faire des maquettes. Bon ensuite, vous connaissez les arguments, une maquette finit toujours par être la véritable application, malgré toute nos promesses de tout réécrire de 0 "quand on aurait le temps". Donc ne commencez pas par faire une maquette, commencez par faire le minimum qui fonctionne de votre application. </p> <h2>Conclusion</h2> <p>Il n'existe pas de solution parfaite, nous adaptons ces principes en fonction de ce que nous croisons, ce n'est pas une recette à appliquer telle quelle. Peut être que votre quotidien consiste effectivement à faire des applications CRUD, c'est juste que dans mon expérience, rien n'est vraiment une application CRUD. Bien souvent, il s'agissait juste de faire <a href="http://blog.xebia.fr/2013/08/22/jcrete-2013-frameworks-really/">rentrer son framework plus ou moins de force dans le besoin client</a>, car quand on a qu'un marteau, tout ressemble à un clou. </p> <p>Ce que nous avons appris : <ul class="liste-arpinum"> <li>Un logiciel est plus maintenu qu'il n'est créé</li> <li>MVC n'est pas une architecture</li> <li>Aucune décision prise en avance ne résiste à l'examen de l'implémentation réelle</li> <li>Nous ne voulons pas nous faire utiliser, nous voulons utiliser</li> <li>Retarder les décisions, développer l'architecture en flux tiré, pouvoir retravailler n'importe quel pan de l'application, ce sont les clés d'une architecture agile.</li> <li>Un framework promettant de tout de faire si vous vous pliez à ses contraintes est un mirage : passé l'effet wahoo, sans discipline vous échouerez. </li> <li>En s'éloignant du CRUD basic, et en démarrant par le métier, nous faisons apparaître des ergonomies plus proche des intentions des utilisateurs. Le syndrome du formulaire access nous atteint moins. </li> </ul> </p> Nous l'avons fait! http://www.arpinum.fr/2013/03/08/nous-lavons-fait/ Fri, 08 Mar 2013 00:00:00 +0000 http://www.arpinum.fr/2013/03/08/nous-lavons-fait <img src="/images/blog/yeswecan.jpg" class="right_pic"/> <p>Samedi dernier Charles et moi avons dispensé notre première formation offerte sur TDD à l'espace <a href="http://www.coolworking.fr">Coolworking.</a> Les 10 participants ont tous répondu présents à notre plus grande surprise car certains venaient de Toulouse, Limoges ou Aix en Provence.</p> <p>La journée a commencé avec une présentation formelle de la pratique et comme TDD ne s'écoute pas mais se vit, nous avons pris les claviers avec Charles. Nous avons bien pris le temps de dérouler le cycle de TDD et d'appliquer les 3 règles d'Uncle Bob.</p> <p>Après notre démontration, la salle s'est transformée en dojo randori et nos participants ont mis les mains dans le cambouis.</p> <p>L'après-midi a été découpée en plusieurs sessions de développement durant lesquelles nos participants se sont frottés à différents exercices en binôme.</p> <img src="/images/blog/journeetdd20130302.jpg" class="left_pic"/> <p>La journée a été très enrichissante pour Charles et moi. J'espère que c'est aussi le cas pour les participants. Les retours sont très positifs pour le moment et ça nous encourrage à renouveler l'aventure.</p> Formation TDD offerte le samedi 2 mars http://www.arpinum.fr/2013/02/07/journee-tdd/ Thu, 07 Feb 2013 00:00:00 +0000 http://www.arpinum.fr/2013/02/07/journee-tdd <img src="/images/code-retreat.jpg" class="right_pic"> <p>Charles et moi organisons une formation TDD (Test-Driven Development), de façon bénévole, le samedi 2 mars à Bordeaux, dans l’espace <a href="http://www.coolworking.fr">Coolworking</a>.</p> <p>Pour les non initiés, TDD est une pratique de développement issue de l’écosystème Extreme Programming. Elle repose sur l’idée folle qu’il serait pertinent d’écrire un test avant même d’avoir développé une fonctionnalité. Utilisée au quotidien elle conduit vers une conception simple et offre une bonne couverture de code.</p> <p>TDD nous accompagne dans chacun de nos développements chez Arpinum et bien que nous continuons d’apprendre sur le sujet, nous nous sentons suffisamment matures pour l’enseigner.</p> <p>Cette formation est dédiée <strong>aux parfaits débutants</strong> qui sont suffisamment curieux et courageux pour apprendre une pratique de développement majeure sur leur temps libre. Vous apprendrez, entre autre, à tester unitairement une application, à remanier le code et vous serez sensibilisés à la conception simple.</p> <img src="/images/blog/omgcat.jpg" class="right_pic"> <p>Nous vous offrons cette formation parce que notre propre amélioration passe par la diffusion de nos connaissances.</p> <p>Les places sont limitées à 10 personnes et pour éviter quelques abus nous ferons en sorte d’avoir au maximum 2 personnes d’une même société.</p> <p>Nous ne fournissons pas de machine donc vous devrez apporter un ordinateur portable avec un IDE fonctionnel. Le langage pressenti pour cette formation est Java ; bien que peu moderne il a pour avantage d’être connu de tous.</p> <p>Le formulaire d’inscription est disponible <a href="http://www.arpinum.fr/journee-tdd-du-2-mars-2013/">ici</a>.</p> <p>Nous gérons une petite liste d’attente en cas de désistement et nous vous tiendrons au courant.</p> <p><strong>Mise à jour (08/02/2013) :</strong> La session est complète, toutes les nouvelles inscriptions seront sur la liste d'attente.</p> <p><strong>Mise à jour (10/02/2013) :</strong> Les inscriptions sont fermées.</p> <h2>Détails techniques</h2> <ul class="liste-arpinum"> <li>Lieu : <a href="http://www.coolworking.fr">Coolworking</a>, 19 rue Esprit des lois, 33000 Bordeaux</li> <li>Date : samedi 2 mars 2013</li> <li>Horaires : 9h-12h et 14h-17h</li> <li>Inscription : <a href="http://www.arpinum.fr/journee-tdd-du-2-mars-2013/">ici</a></li> <li>Participants : 10</li> <li>Matériel : Ordinateur portable</li> <li>Langage : Java</li> <li>Plus d’infos : <a href="http://www.arpinum.fr/contact/">Contactez-nous</a></li> </ul> Stoos Connect http://www.arpinum.fr/2013/01/27/stoosconnect/ Sun, 27 Jan 2013 00:00:00 +0000 http://www.arpinum.fr/2013/01/27/stoosconnect <p>Vendredi dernier, se tenait la première conférence du <a href="http://www.stoosnetwork.org/">réseau stoos</a>, le <a href="http://stoosconnect.nl/">Stoos connect</a>. L'évènement était rediffusé chez <a href="http://coolworking.fr">coolworking</a>, et voici en peu de mots ce que je peux en dire.</p> <img src="/images/blog/cropped-stoos_connect12.png" class="center_pic"/> <h3>Stoos quoi ?</h3> <p>Si vous ne connaissez pas l'initiative <a href="http://www.stoosnetwork.org/">Stoos network</a>, je vous invite à la découvrir. Si je vous donne mon résumé personnel, c'est un peu le mouvement agile du management, avec donc, son rendez-vous initiateur dans la montage :) Le but est donc rien de moins que de changer le monde, en changeant la manière dont les organisations conçoivent le travail et produisent de la valeur. Moi, personnellement, ça me va comme pitch. On trouve des gens comme <a href="https://twitter.com/stevedenning">Steve Denning</a> à l'origine de cette idée, et je vous encourage vivement <a href="http://www.forbes.com/sites/stevedenning/2013/01/14/towards-the-tipping-point-in-leadership-management/">cet article</a>. En somme, le but est de porter les valeurs et principes de l'agilité qui nous sont chères, dans des sphères normalement assez fermées.</p> <h3>Donc ça a causé de quoi</h3> <p>Je ne vais pas tenter de lister tous les orateurs, je vais juste énumérer ce qui m'a le plus marqué:</p> <ul class="liste-arpinum"> <li>Le management «scientifique» de Taylor, ne l'a jamais été, car ses postulats ne sont pas étayés, et pire, ont été démontés par 40 ans de recherche sur les motivations humaines.</li> <li>Le management est mort dans les années 70, mais il ne s'en est pas rendu compte. Il a été remplacé par le leadership. En effet, depuis les années 70, de «grosses» boites ont réussi à très grande échelle en se passant de management.</li> <li>Les idées derrière Stoos network et l'agilité sont dans l'air du temps depuis des décennies, mais le management «scientifique» est très résistant. C'est une des dernières technologies du XIXème que nous utilisons encore.</li> <li>Le management n'a pas toujours été là, c'est une «technologie» créé par l'homme.</li> <li>Le management a été créé pour obtenir la conformité. Il ne peut pas être utilisé pour créer l'engagement.</li> <li>On peut fabriquer un système de prime réellement juste, à base de <a href="http://www.noop.nl/2012/11/the-6-rules-for-rewards.html">hugs</a></li> <li><a href="http://www.wikispeed.com/">WikiSpeed</a> n'arrêtera jamais de m'impressionner.</li> <li>Pour que tout cela réussisse, il faut que le «centre» des organisations perde son arrogance.</li> <li>Les commerciaux les plus efficaces sont ceux motivés et poussés à vendre selon un but noble.</li> <li>De biens jolis <a href="http://randommanager.com/">tee-shirts</a></li> <li><a href="http://fr.wikipedia.org/wiki/Slow_Management">Slow management</a></li> <li>Un steward qui déchire <br /> <iframe width="420" height="315" src="http://www.youtube.com/embed/DYA_ivyj3kE" frameborder="0" allowfullscreen></iframe></li> </ul> <h3>Ce que j'ai moins aimé</h3> <ul class="liste-arpinum"> <li><a href="https://twitter.com/DanielPink">Daniel Pink</a> n'a pas pu venir, et nous n'avons eu qu'une vidéo assez conventionnelle de lui.</li> <li>Beaucoup de soucis techniques</li> <li>Toutes mes orateurs préférés ou presque étaient programmés tout à la fin.</li> <li>Nous étions vraiment trop peu nombreux à Bordeaux, alors que d'autres villes faisaient salle comble. Bordeaux pas assez motivé par ces sujets ?</li> </ul> <h3>Le mot de la fin</h3> <p>Steve Denning veut créer un mouvement de mouvements, pour avoir un impact réel sur le monde : Stoos, Agile Alliance, Scrum Alliance, etc… et je pense effectivement que c'est une excellente initiative, surtout qu'il a la voix qui porte le monsieur. Donc j'ai envi de me demander si, sur Bordeaux, des personnes motivées sont prêtes à porter le flambeau :) </p> <p class="quote">Never doubt that a small group of thoughtful, committed citizens can change the world. Indeed, it is the only thing that ever has. Margaret Mead</p> Quelques raisons d'utiliser MongoLink http://www.arpinum.fr/2013/01/23/quelques-raisons-d-utiliser-mongolink/ Wed, 23 Jan 2013 00:00:00 +0000 http://www.arpinum.fr/2013/01/23/quelques-raisons-d-utiliser-mongolink <p>Il y a presque deux ans maintenant je pense, nous avons commencé à nous mettre à utiliser <a href="http://mongodb.org">mongodb</a> dans certains de nos projets. Les raisons sont multiples, mais ce qui nous a particulièrement séduit, c'est :</p> <ul class="liste-arpinum"> <li>une plus grande souplesse dans la manipulation de schéma (si on peut parler de schéma),</li> <li>les documents sont bien plus proches de l'objet que ne l'est un SGBD,</li> <li>l'atomicité se limite au document, et donc en modélisant un agrégat par collection, c'est assez proche d'une philosophie DDD</li> </ul> <p>Ceci étant dit, MongoDB reste une base de données, et nous souhaitons toujours mettre le métier au cœur de nos préoccupations, en appliquant, entre autre, l'ignorance de la persistance. Il y a plusieurs manière bien sur d'obtenir ce résultat, mais l'approche mapper, avec ses défauts, a l'avantage normalement de simplifier la chose. À l'époque, il existait bien sur déjà en java quelques solutions, mais aucune ne respectait tous nos critères, et nous avons donc pris cette décision un peu folle de faire la notre : <a href="http://mongolink.org">MongoLink</a></p> <h2>Pas d'annotation, pas de XML</h2> <p>Ah, voici bien quelque chose qui nous tenait à cœur : ne pas avoir à mélanger des responsabilités dans notre métier en plaçant des annotations de persistance partout, parfois prenant plus de place que le code lui-même. Nous ne voulions pas non plus de XML, ou même de n'importe quel autre type de fichier pour déclarer le mapping, pour limiter les résistances au refactoring. La solution restante était donc de déclarer le mapping en code, via une Fluent Interface. <a href="http://www.fluentnhibernate.org/">Fluent NHibernate</a> a été une grosse source d'inspiration.</p> <p>Voilà donc à quoi peut ressembler un mapping : </p> <div class="highlight"><pre><code class="java"><span class="kd">public</span> <span class="kd">class</span> <span class="nc">FruitMapping</span> <span class="kd">extends</span> <span class="n">AggregateMap</span><span class="o">&lt;</span><span class="n">Fruit</span><span class="o">&gt;</span> <span class="o">{</span> <span class="kd">public</span> <span class="nf">FruitMapping</span><span class="o">()</span> <span class="o">{</span> <span class="kd">super</span><span class="o">(</span><span class="n">Fruit</span><span class="o">.</span><span class="na">class</span><span class="o">);</span> <span class="o">}</span> <span class="nd">@Override</span> <span class="kd">public</span> <span class="kt">void</span> <span class="nf">map</span><span class="o">()</span> <span class="o">{</span> <span class="n">id</span><span class="o">(</span><span class="n">element</span><span class="o">().</span><span class="na">getId</span><span class="o">());</span> <span class="n">property</span><span class="o">(</span><span class="n">element</span><span class="o">().</span><span class="na">getName</span><span class="o">());</span> <span class="n">collection</span><span class="o">(</span><span class="n">element</span><span class="o">().</span><span class="na">getVarieties</span><span class="o">());</span> <span class="n">subclass</span><span class="o">(</span><span class="k">new</span> <span class="n">SubclassMap</span><span class="o">&lt;</span><span class="n">Banana</span><span class="o">&gt;(</span><span class="n">Banana</span><span class="o">.</span><span class="na">class</span><span class="o">)</span> <span class="o">{</span> <span class="nd">@Override</span> <span class="kd">protected</span> <span class="kt">void</span> <span class="nf">map</span><span class="o">()</span> <span class="o">{</span> <span class="n">property</span><span class="o">(</span><span class="n">element</span><span class="o">().</span><span class="na">getSkin</span><span class="o">());</span> <span class="o">}</span> <span class="o">});</span> <span class="o">}</span> <span class="o">}</span> </code></pre></div> <br/><br/> <h2>Support du polymorphisme sur les objets valeurs</h2> <p>Voilà une fonctionnalité dont je rêve depuis des années. Combien de fois avec Hibernate j'ai du transformer un objet valeur en entité pour pouvoir gérer du polymorphisme, et du coup brouiller le métier, et complexifier le mapping ! Non avec mongolink, pas de soucis. Si vous voulez par exemple mapper un State, aucun problème :</p> <div class="highlight"><pre><code class="java"><span class="kd">public</span> <span class="kd">class</span> <span class="nc">StateMapping</span> <span class="kd">extends</span> <span class="n">ComponentMap</span><span class="o">&lt;</span><span class="n">State</span><span class="o">&gt;</span> <span class="o">{</span> <span class="kd">public</span> <span class="nf">StateMapping</span><span class="o">()</span> <span class="o">{</span> <span class="kd">super</span><span class="o">(</span><span class="n">State</span><span class="o">.</span><span class="na">class</span><span class="o">);</span> <span class="o">}</span> <span class="nd">@Override</span> <span class="kd">protected</span> <span class="kt">void</span> <span class="nf">map</span><span class="o">()</span> <span class="o">{</span> <span class="n">subclass</span><span class="o">(</span><span class="k">new</span> <span class="n">SubclassMap</span><span class="o">&lt;</span><span class="n">OpenState</span><span class="o">&gt;(</span><span class="n">OpenState</span><span class="o">.</span><span class="na">class</span><span class="o">)</span> <span class="o">{</span> <span class="nd">@Override</span> <span class="kd">protected</span> <span class="kt">void</span> <span class="nf">map</span><span class="o">()</span> <span class="o">{</span> <span class="o">}</span> <span class="o">});</span> <span class="n">subclass</span><span class="o">(</span><span class="k">new</span> <span class="n">SubclassMap</span><span class="o">&lt;</span><span class="n">CloseState</span><span class="o">&gt;(</span><span class="n">CloseState</span><span class="o">.</span><span class="na">class</span><span class="o">)</span> <span class="o">{</span> <span class="nd">@Override</span> <span class="kd">protected</span> <span class="kt">void</span> <span class="nf">map</span><span class="o">()</span> <span class="o">{</span> <span class="o">}</span> <span class="o">});</span> <span class="n">subclass</span><span class="o">(</span><span class="k">new</span> <span class="n">SubclassMap</span><span class="o">&lt;</span><span class="n">PendingState</span><span class="o">&gt;(</span><span class="n">PendingState</span><span class="o">.</span><span class="na">class</span><span class="o">)</span> <span class="o">{</span> <span class="nd">@Override</span> <span class="kd">protected</span> <span class="kt">void</span> <span class="nf">map</span><span class="o">()</span> <span class="o">{</span> <span class="o">}</span> <span class="o">});</span> <span class="o">}</span> <span class="o">}</span> </code></pre></div> <br/><br/> <h2>Mise à jour automatique en émettant que les operators nécessaires</h2> <p> Qui dit ignorance de la persistance, dit ne pas avoir à explicitement pousser ses mises à jour vers la base de données. Pour supporter cette approche, tous les chargements dans MongoLink sont encapsulés dans une session, qui se chargera toute seule à la fin de déterminer les modifications qui ont été effectuées sur les objets chargés. Si vous avez utilisez Hibernate, rien de bien neuf pour vous, mais là ou ça devient plus délicat quand on parle de MongoDB, c'est qu'il vaut mieux exprimer ses mises à jour à l'aide de seulement les <a href="http://docs.mongodb.org/manual/reference/operators/#update-operators">operators nécessaires</a>. </p> <p>Disons donc que vous avez le code suivant :</p> <div class="highlight"><pre><code class="java"><span class="o">.</span> <span class="o">.</span> <span class="o">.</span> <span class="n">mongoSession</span><span class="o">.</span><span class="na">start</span><span class="o">();</span> <span class="n">MaClasse</span> <span class="n">instance</span> <span class="o">=</span> <span class="n">mongoSession</span><span class="o">.</span><span class="na">get</span><span class="o">(</span><span class="s">&quot;monId&quot;</span><span class="o">,</span> <span class="n">MaClasse</span><span class="o">.</span><span class="na">class</span><span class="o">);</span> <span class="n">instance</span><span class="o">.</span><span class="na">setUneValeur</span><span class="o">(</span><span class="s">&quot;une valeur&quot;</span><span class="o">);</span> <span class="n">mongoSession</span><span class="o">.</span><span class="na">stop</span><span class="o">();</span> </code></pre></div> <br /><br /> <p> La session va seulement émettre cette opération : </p> <div class="highlight"><pre><code class="javascript"><span class="p">{</span> <span class="s2">&quot;$set&quot;</span> <span class="o">:</span> <span class="p">{</span> <span class="s2">&quot;uneValeur&quot;</span> <span class="o">:</span> <span class="s2">&quot;une valeur&quot;</span><span class="p">}</span> <span class="p">}</span> </code></pre></div> <br/><br/> <h2>Les classes de mapping sont cherchées par MongoLink</h2> <p>Une des frustrations que nous avions avec Hibernate, c'était de devoir tenir une liste dans la configuration de tous les fichiers de mapping. De plus, il n'est pas forcément facile à configurer. Nous voulions donc avoir une solution simple pour démarrer mongolink : </p> <div class="highlight"><pre><code class="java"><span class="n">ContextBuilder</span> <span class="n">builder</span> <span class="o">=</span> <span class="k">new</span> <span class="n">ContextBuilder</span><span class="o">(</span><span class="s">&quot;org.mongolink.test.integrationMapping&quot;</span><span class="o">);</span> <span class="n">Settings</span> <span class="n">settings</span> <span class="o">=</span> <span class="n">Settings</span><span class="o">.</span><span class="na">defaultInstance</span><span class="o">();</span> <span class="n">MongoSessionManager</span> <span class="n">sessionManager</span> <span class="o">=</span> <span class="n">MongoSessionManager</span><span class="o">.</span><span class="na">create</span><span class="o">(</span><span class="n">builder</span><span class="o">,</span> <span class="n">settings</span><span class="o">);</span> <span class="o">.</span> <span class="o">.</span> <span class="o">.</span> <span class="n">MongoSession</span> <span class="n">mongoSession</span> <span class="o">=</span> <span class="n">sessionManager</span><span class="o">.</span><span class="na">createSession</span><span class="o">();</span> </code></pre></div> <br/><br/> <h2>Conclusion</h2> <p>Bien, tout ceci était finalement une introduction rapide à la philosophie de MongoLink :</p> <ul class="liste-arpinum"> <li>DDD et ignorance de la persistance</li> <li>Mapping en code</li> <li>Vrai support du polymorphisme des objets valeurs</li> <li>Mises à jour efficaces</li> <li>Simplicité de configuration</li> </ul> <p>Je pourrais ajouter en vrac, le fait qu'il ne retourne pas de proxy, passe toujours par les fields pour les mises à jour pour ne pas nécessiter de setters; possède une api de recherche; fournit des outils pour faciliter les tests; mais il faut garder de la substance pour d'autres articles :)</p> <p>J'espère que cela vous donnera envi de l'essayer, même si je vous l'accorde, il reste du travail pour le rendre plus grand public, et qu'il y aurait bien d'autres choses à dire.</p> Le premier Scrum Wine de l'année 2013 http://www.arpinum.fr/2013/01/17/le-premier-scrum-wine-de-l-annee/ Thu, 17 Jan 2013 00:00:00 +0000 http://www.arpinum.fr/2013/01/17/le-premier-scrum-wine-de-l-annee <p>Nous avons été accueilli hier chez <a href="http://www.coolworking.fr">coolworking</a> pour le premier Scrum Wine de l'année 2013.</p> <p>Après une revue de l'agenda agile (bien chargé) de l'année par <a href="https://twitter.com/PhilAgile">Philippe Launay</a>, nous avons eu le droit à une présentation Kanban en 5 minutes chrono par Olivier Patou, bravo Olivier pour cette belle performance !</p> <img class="right_pic" src="/images/blog/JB-scrumwine.jpg" /> <p>Esprit corporate oblige, j'ai assisté ensuite à la présentation d'extreme programming, par le très bon <a href="https://twitter.com/BodySplash">Jean-Baptiste Dusseaut</a> :). JB a débuté cette présentation en partant des principales pratiques d'xp (TDD, Refactoring, Pair Programming et Design incrémental) et nous a guidé à travers les principes et les valeurs vers la <a href="http://prezi.com/eqmsbhlrxjz6/la-voie-du-programmeur-version-longue/">voie du programmeur</a>. Les nombreuses questions à la fin de la session et le bon ROTI ont montré l'intérêt grandissant pour les pratiques d'extreme programming. Mettre en place les pratiques n'est pas simple, mais le jeu en vaut la chandelle! </p> <p>A mon grand regret, je n'ai pas pu gouter le Pic St Loup ni participer aux toujours très intéressantes discussions avec la communauté agile bordelaise à la fin de l'évènement.</p> <p>Pour finir, je pense que je vais essayer de convaincre mes collègues arpinumiens d'aller à la conférence <a href="http://xp2013.org/">XP 2013</a>, en Autriche cette année.</p> Global Day of Coderetreat, on remet ça ! http://www.arpinum.fr/2012/12/04/global-day-of-code-retreat-on-remet-ca/ Tue, 04 Dec 2012 00:00:00 +0000 http://www.arpinum.fr/2012/12/04/global-day-of-code-retreat-on-remet-ca <p>Le 8 décembre prochain est la journée mondiale du <a href="http://globalday.coderetreat.org/">code retreat</a>. Sponsorisée par l’association <a href="http://okiwi.org/">Okiwi</a>, la deuxième édition à Bordeaux se déroulera chez <a href="http://www.coolworking.fr">coolworking</a>, en plein centre de Bordeaux.</p> <p>Nous aurons le plaisir à nouveau d'animer l'édition bordelaise, avec un petit changement par rapport à l'année dernière : C'est <a href="https://fr.twitter.com/michael_borde">Michael</a> et <a href="https://fr.twitter.com/BodySplash">Jean-Baptiste</a> qui pair-animeront la journée.</p> <img class="right_pic" src="/images/blog/gdcr2012.png" /> <p>Le principe de cette "retraite" est simple et reste le même d'année en année : 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.</p> <p>Cette année l'évènement affiche <a href="http://communaute.okiwi.org/events/global-day-of-coderetreat-2012-bordeaux">complet</a>, j'ai hâte de coder avec mes paires !</p> <p>A samedi !</p> Un 1er Agile Tour Pau http://www.arpinum.fr/2012/10/30/un-1er-agile-tour-pau/ Tue, 30 Oct 2012 00:00:00 +0000 http://www.arpinum.fr/2012/10/30/un-1er-agile-tour-pau <p>Le 24 octobre dernier a eu lieu le tout premier <a href="http://www.pyrenees-agile.org/agile-tour-pau-2012/">Agile Tour Pau</a>. J’étais plutôt impatient de découvrir la formule pyrénéenne en cette veille d’Agile Tour Toulouse et de contribuer activement avec une présentation <a target="_blank" rel="tdd" href="http://referentiel.institut-agile.fr/tdd.html" class="highlighted">TDD</a>.</p> <p>L’évènement a eu lieu dans la très belle école <a href="http://www.eisti.fr/">EISTI</a>. Les locaux sont très modernes, le hall est aussi vaste que magnifique et l’amphithéâtre tout simplement génial. Figurez-vous qu’en tant qu’orateur nous avions droit à un micro serre tête, des micros sans fils pour le public, plusieurs TV avec un retour de la présentation et un grand écran lisible même pour du code.</p> <p>Cette première édition s’est déroulée sur une après-midi et exclusivement dans l’amphithéâtre. Le public était majoritairement composé d’étudiants. C’était une très grosse crainte pour moi de présenter un sujet devant un public qui n’avait pas choisi ma session et qui n’était pas forcément concerné par le métier de développeur.</p> <p>Après un mot d’introduction de <strong>Mélissa Oscoso</strong>, l’organisatrice de cet Agile Tour, et de <strong>Laurence Lamoulie</strong> la directrice du campus, les festivités ont commencé.</p> <h3>Quel chemin vers l’Agilité (Antoine Vernois et Thierry Cros)</h3> <p><img class="right_pic" src="/images/blog/atpau-thierrycros-anthoinevernois.jpg"><br> J’ai eu le plaisir de voir une bonne session d’introduction avec <strong>Quel chemin vers l’Agilité</strong> d’<strong>Antoine Vernois</strong> et <strong>Thierry Cros</strong>. C’était un panel de plusieurs approches agiles avec leurs pratiques mais surtout leurs valeurs respectives. J’aime beaucoup les présentations <a target="_blank" rel="pairing" href="http://referentiel.institut-agile.fr/pairing.html" class="highlighted">en binôme</a> ça les rend bien plus dynamiques et le duo avait beaucoup de choses à nous dire <img src="http://www.arpinum.fr/wp-includes/images/smilies/icon_smile.gif" alt=":)" class="wp-smiley"> </p> <h3>Gestion de portefeuilles de projets Agiles (Fabrice Aimetti)</h3> <p><img class="left_pic" src="/images/blog/atpau-fabriceaimetti.jpg"><br> Ensuite, <strong>Fabrice Aimetti</strong> nous a parlé de <strong>Gestion de portefeuilles de projets Agiles</strong>. En tant que développeur ce genre de sujet me dépasse parfois un peu mais je dois avouer qu’il était très bien amené. Fabrice a toujours le chic pour faire de belles diapos riches en couleur et comme le fond est aussi de qualité, le message global passe très bien. J’ai particulièrement apprécié le démarrage où il fait une piqure de rappel sur les différentes responsabilités autour d’un projet. Ca vous étonnera mais ScrumMaster n’est pas une réponse universelle (dédicace au public).</p> <h3><a target="_blank" rel="tdd" href="http://referentiel.institut-agile.fr/tdd.html" class="highlighted">Test-Driven</a> Development (Votre bien aimé)</h3> <p><img class="right_pic" src="/images/blog/atpau-michaelborde.jpg"><br> Après une courte pause, je suis monté sur l’estrade pour discuter de <strong><a target="_blank" rel="tdd" href="http://referentiel.institut-agile.fr/tdd.html" class="highlighted">Test-Driven</a> Development</strong>. Je n’avais que 45 min mais un maximum de choses à dire. J’avais donc préparé une introduction très brève à <a target="_blank" rel="tdd" href="http://referentiel.institut-agile.fr/tdd.html" class="highlighted">TDD</a> de 5 min tout au plus. <a target="_blank" rel="tdd" href="http://referentiel.institut-agile.fr/tdd.html" class="highlighted">TDD</a> est une pratique qui ne s’écoute pas mais qui se vit, j’ai donc déroulé le Kata du Bowling en Java le reste de ma session. Je me suis beaucoup amusé pendant ce court instant de code. Ce Kata est vraiment intéressant parce qu’il est possible de solliciter le public à chaque test. Un certain <strong>Alexandre Boutin</strong> m’a même suggéré un test qui a démontré un défaut dans mon code.</p> <p>Mes slides sont disponibles <a href="http://fr.slideshare.net/michaelborde/tdd-en-5-minutes" title="TDD en 5 minutes">ici</a> et les sources par <a href="http://github.com/MichaelBorde/Bowling-AgileTourPau2012-Kata-Java">ici</a>.</p> <h3>Coup de pouce Agile chez Total (Alexandre Boutin et Yann Poles)</h3> <p><img class="left_pic" src="/images/blog/atpau-yanpoles-alexandreboutin.jpg"><br> Pour finir, ce même <strong>Alexandre Boutin</strong> et <strong>Yann Poles</strong> nous ont présenté <strong>Coup de pouce Agile chez Total</strong>. J’avais quelques aprioris sur les retours d’expériences liés aux grands groupes mais j’ai été agréablement surpris. Le changement chez Total est conduit comme un véritable produit agile : logo, roadmap, <a target="_blank" rel="heartbeatretro" href="http://referentiel.institut-agile.fr/heartbeatretro.html" class="highlighted">rétrospective</a>s, développement incrémentiel, apprentissage sous forme de jeu, etc.</p> <p>Il y avait une très bon ambiance durant cet Agile Tour et ça semble très prometteur pour la suite. J’ai hâte d’être à l’année prochaine et de voir grandir l’évènement.</p> <p>Un grand merci à <strong>Mélissa Oscoso</strong> et l’<strong>EISTI</strong> pour cette belle journée. Et finalement, merci aux autres orateurs pour avoir diffusé un message des plus pertinent.</p> <p>Les vidéos de l’évènement sont disponibles sur le site de <a href="http://www.pyrenees-agile.org/agile-tour-pau-2012/">l’Agile Tour Pau</a>.</p> Agile Tour Bordeaux 2012 : la meilleure édition http://www.arpinum.fr/2012/10/15/agile-tour-bordeaux-2012-la-meilleure-edition/ Mon, 15 Oct 2012 00:00:00 +0000 http://www.arpinum.fr/2012/10/15/agile-tour-bordeaux-2012-la-meilleure-edition <p>La semaine précédente aura été bien dense pour moi entre les 2 jours d’atelier avec David Evans et l’Agile Tour Bordeaux version 2012.</p> <h2>Testing in Lean and Agile Projects</h2> <p>L’atelier dédié aux tests était très pertinent. Son contenu m’était plus que familier mais j’ai eu le plaisir de côtoyer cet excellent orateur qu’est David Evans. Non seulement il maitrise son sujet mais sait l’enseigner de façon redoutable. Les discussions avec les différents participants étaient aussi très intéressantes. Nous venions de sociétés bien différentes avec un rapport aux tests tout aussi différent.</p> <h2>Une belle journée</h2> <p><img src="/images/blog/charles-at2012-small.jpg" class="right_pic"><br> Mais ce billet concerne définitivement l’Agile Tour Bordeaux 2012. Le titre dévoile quelque peu le message&nbsp;: c’est le meilleur AT qui a vu le jour dans notre ville. Quelle est la recette de ce succès? Un savant mélange des éléments suivants&nbsp;:</p> <ul class="liste-arpinum"> <li>Une équipe motivée et hétérogène&nbsp;: un grand merci à Bastien Gallay, Florian Guérin, Samir Hanna, Jérôme Roux, Mickael Ruellan et Guillaume Vincent. Des vieux routards de l’organisation comme de nouvelles têtes.</li> <li>Un lieu agréable&nbsp;: l’EPITECH s’est réellement impliquée dans la bonne réussite de l’évènement. Un autre merci à la souplesse de l’école et à ses élèves pour leur participation active. Retransmission des conférences dans la cafétéria et sur Dailymotion&nbsp;: que demande le peuple?</li> <li>Des orateurs de qualité : du beau monde comme chaque année mais avec le petit plus produit, David Evans était là.</li> </ul> <h2>Morceaux choisis</h2> <p>Pour la première fois depuis que l’évènement existe sur Bordeaux, j’ai pu me mettre dans la peau d’un participant et voici un bref résumé des sessions qui m’ont le plus&nbsp;intéressé.</p> <h3>What Testers and Developers Can Learn From Each Other (David Evans)</h3> <p><img src="/images/blog/davidevans-at2012-small.jpg" class="right_pic"><br> <strong></strong>L’évènement bordelais s’est vu offrir une session d’ouverture. C’était une première et une véritable réussite. David Evans nous a parlé de test mais surtout des hommes qui se cachent derrière : les développeurs et les testeurs professionnels. Il nous a expliqué à quel point il était crucial et pertinent de réconcilier ces deux espèces.</p> <p>A retenir :</p> <ul class="liste-arpinum"> <li>Ce n’est pas grave d’échouer mais il faut échouer vite,</li> <li>Tester un logiciel n’améliore pas de fait sa qualité,</li> <li>Un logiciel non testé est un logiciel qui ne fonctionne pas,</li> <li>Testeur peut devenir un talent plutôt qu’un nom de métier.</li> </ul> <h3>XP Basics (Fabien Bézagu)</h3> <p><img src="/images/blog/fabien-at2012-small.jpg" class="left_pic"><br> Une session sur Extreme Programming est toujours bonne à prendre dans un Agile Tour. Je n’avais rien vu ni entendu de la toute nouvelle présentation de Fabien, je me devais donc d’y assister. Le but était de donner une vision d’ensemble de l’approche de Kent Beck et ce fut très bien exécuté. Après une introduction extrême, Fabien a énoncé les causes des échecs des projets (dépassement des délais, effet tunnel, défauts, etc.) et a expliqué en quoi XP était une réponse pertinente à chacun de ces points. J’ai bien aimé la forme de cette présentation qui évitait l’effet catalogue de pratique.</p> <p>&nbsp;</p> <p>&nbsp;</p> <h3>La voie du programmeur (Jean-Baptiste Dusseaut)</h3> <p><img src="/images/blog/jb-at2012-small.jpg" class="right_pic"><br> Je suis allé voir une autre session d’un Arpinumien. Encore? Sous peine d’être taxé de corporatisme&nbsp;aiguë&nbsp;je tiens à préciser que c’était la seule session qui parlait exclusivement du métier de développeur. J’avais vu la version <a href="http://vimeo.com/41144268" title="La voie du programmeur">lightning talk </a>au Mix-IT et j’étais curieux de voir si Jean-Baptiste avait suffisamment de matière pour un créneau plus long. Eh bien messieurs, c’est la cas. Sachez qu’il est bel et bien possible de devenir développeur professionnel dans un monde qui privilégie les termes pompeux comme chef de projet, architecte ou expert technique. Le chemin sera long mais il existe! Vous aurez besoin de lire mais aussi de pratiquer&nbsp;énormément&nbsp;et vous seul&nbsp;êtes&nbsp;responsable&nbsp;de votre formation.</p> <h3>Sociocratie: une gouvernance agile (Thierry Cros)</h3> <p><img src="/images/blog/thierrycros-at2012-small.jpg" class="left_pic"><br> La sociocratie est un sujet qui passionne Thierry ces derniers temps et quand il parle d’un sujet qui le passionne, ça finit par vous passionnez vous même. J’avais déjà assisté à une présentation informelle de la sociocratie faite par Thierry au cours de l’Agile Open Sud 2012. Ca m’avait beaucoup intrigué et je me demande toujours si un tel changement social est possible en France. La <a href="http://fr.wikipedia.org/wiki/Sociocratie" title="Sociocratie">sociocratie</a> est un mode de gouvernance qui permet à une organisation de se comporter comme un être vivant, de s’auto-organiser. La thèse de Thierry est que si les approches agiles permettent de s’auto-organiser à l’échelle d’une équipe, la sociocratie pourrait être un moyen tout à fait compatible de s’auto-organiser à l’échelle d’une entreprise (voire plus).</p> <h3>La communication au service du projet (Isabel Monville)</h3> <p><img src="/images/blog/isabelmonville-at2012-small.jpg" class="right_pic"><br> La dernière session de la journée fut pour moi une véritable surprise. Je n’avais jamais assisté à une présentation d’Isabel et j’ai beaucoup apprécié sa contribution à l’Agile Tour. La présentation était dédiée à la communication, une notion qui m’est chère puisqu’elle est la 1ère valeur d’Extreme Programming. Oui, la communication peut et doit être au service du projet. Beck le dit lui même, la plupart des problèmes dans un projet trouve sa source dans un manque de communication. Isabel nous a donc parlé des différents états du moi (Parent, Adulte, Enfant) et de leurs impacts sur la communication, des drivers qui se déclenchent au fond de nous en situation de stress et tellement d’autres choses. Le lendemain j’ai été obligé de m’acheter un livre sur l’analyse transactionnelle, la base de certaines approches de coaching.</p> <h2>La suite?</h2> <p>Qu’il va être difficile d’attendre 1 an avant d’avoir un nouvel Agile Tour dans ma ville. En attendant, je serai à Pau et Toulouse la semaine prochaine. Il se peut aussi que ma gentille société m’autorise à aller me balader vers Grenoble en Novembre.</p> Octobre : le mois agile http://www.arpinum.fr/2012/10/09/octobre-le-mois-agile/ Tue, 09 Oct 2012 00:00:00 +0000 http://www.arpinum.fr/2012/10/09/octobre-le-mois-agile <p>Chers managers, si vous tremblez à l’approche du mois de mai et de tous ses ponts, méfiez-vous désormais du mois d’octobre. Les Agiles Tours convient de plus en de monde. Le bruit court dans toute l’Occitanie que l’évènement bordelais serait complet depuis quelque temps déjà. A la différence des pré-vacanciers de mai, ce seront des personnes curieuses, dans une démarche d’amélioration continue et responsables qui déserteront vos équipes. Jamais une journée de RTT n’aura eu autant de valeur.</p> <p>Chez Arpinum c’est l’hécatombe. Depuis 2009, l’ensemble des développeurs, coachs, commerciaux et cadres dirigeants participe aux Agile Tours. Et bien que tout ça loge dans le break (le bus agile) de Fabien, ce n’est pas moins impressionnant.</p> <p><img width="300" height="225" alt="" src="/images/blog/lolcat-300x225.jpg" title="lolcat" class="size-medium wp-image-796 aligncenter"></p> <p>2009… cette année fut plein de souvenirs pour moi. J’organisais pour la 1ere année l’Agile Tour Bordeaux avec Jean-Baptiste et Charles. Ces deux compères y ont même présenté un Kata TDD. Pour ma part je présentais <strong>Extreme Programming</strong> non pas sans appréhension. Une semaine avant nous étions partis en reconnaissance à Toulouse qui en était à sa 2ème année d’Agile Tour.</p> <p>Pour 2010, Jean-Baptiste et moi remettions le couvert pour l’organisation. D’ailleurs nous avons eu le plaisir de présenter <strong>l’Agilité sans concession</strong> qui résumait bien notre état d’esprit sur le développement de <a href="http://tiron.fr/" title="Tiron">Tiron</a>. Fabien était aussi de la partie avec sa présentation <strong>DDD et XP</strong>, deux piliers de notre savoir faire. Nous avions toujours faim d’agilité et nous sommes donc naturellement allé voir les toulousains.</p> <p>En 2011, … oui vous avez gagné, Jean-Baptiste moi participions à l’organisation. C’était la 1ere fois qu’Arpinum sponsorisait l’évènement. Le programme était époustouflant c’était une très bonne journée mais je ne suis pas objectif. Il fallait d’ailleurs la terminer par la présentation de Fabien intitulée <strong>TDD, je commence demain ! </strong>Fabien est parfois laxiste, j’aurais préféré un <strong>TDD, je zappe le buffet de cloture de l’Agile Tour et je commence tout de suite !</strong> Mais je ne lui en veux pas, il a eu le courage avec Jean-Baptiste de présenter <strong>DDD et XP</strong> à Toulouse.</p> <p>En 2012, Jean-Baptiste et moi avons été convoqué par la Nasa pour diriger une refonte des produits Google sur l’ipad mini. Nous avons ainsi jugé préférable de nous retirer de l’organisation. D’ailleurs, l’équipe actuelle vous prépare un évènement de toute beauté, j’espère que mon patron me laissera y aller. Quoiqu’il en soit, cher public, nous ne vous laissons pas tomber, Arpinum est sponsor Gold (la classe). Notez bien que Jean-Baptiste présentera <strong>La voie du programmeur</strong> et Fabien aura la lourde tâche de faire aussi bien que moi avec <strong>Extreme Programming</strong>. Des rumeurs entièrement fondées disent que je présenterais un Kata TDD à l’Agile Tour Pau pour sa 1ere année. Nous y allons avec Fabien la veille de la session Toulousaine ou nous y rejoindrons nos compères. Finalement ce mois d’octobre sera bel et bien chargé pour Arpinum.</p> <p>A bientôt chers agilistes.</p> TDD, le piège à éviter http://www.arpinum.fr/2012/07/28/tdd-le-piege-a-eviter/ Sat, 28 Jul 2012 00:00:00 +0000 http://www.arpinum.fr/2012/07/28/tdd-le-piege-a-eviter <p>TDD est une pratique de moins en moins controversée, mais qui a toujours du mal, comme toute pratique contre-intuitive, à réellement devenir dominante et maitrisée. Même parmi les personnes qui s’y sont essayées, nous trouvons des réfractaires, et bien souvent, leur argument principal ressemble à ça :</p> <blockquote class="quote"><p>Oui le TDD, on a essayé, mais ça coûte cher. Les tests sont longs à écrire et à maintenir, et finalement ils se cassent au moindre refactoring. Du coup nous : faisons surtout des tests d’intégration, ne testons pas tout, ne faisons pas de refactoring (rayez la mention inutile).</p></blockquote> <p>Quand on observe les tests qui ont été produits, ils sont souvent effectivement compliqués et fragiles. En creusant un peu, et en comparant les situations, nous arrivons pratiquement invariablement à la même conclusion: les personnes qui tiennent ce discours sont passées à côté du secret du TDD; du changement d’état d’esprit qu’il implique, et dont tout le reste découle. C’est ce changement de point de vue, ce passage à un autre paradigme, qui permet de faire apparaître et évoluer le design, comme TDD le promet; qui permet d’obtenir des tests rapides, facile à comprendre, qui sont une aide au refactoring; qui permet de voir des sourires et de la fierté au sein d’une équipe sûr de son travail. Quel est donc ce changement fondamental ?</p> <p style="text-align: center;"><em>Il ne faut pas penser à l’implémentation en écrivant son test</em></p> <p>Voilà, c’est tout simple. Systématiquement, les syndromes évoqués plus haut sont issus d’une volonté de prouver une implémentation plutôt qu’une fonctionnalité. Ce faisant, le test va avoir tendance à couvrir trop de terrains, s’appuyer intensivement sur les mocks, et à ne porter aucunement une intention compréhensible, et donc maintenable. En voulant sauter des étapes, aller directement à l’implémentation que nous imaginons, nous perdons en fait tous les gains de productivité attendus.</p> <p>Vous pouvez savoir si vous souffrez de ce syndrome si :</p> <ul class="liste-arpinum"> <li>vous ne comprenez plus vos tests,</li> <li>vous passez systématiquement plus de 10 minutes à écrire un test</li> <li>vos tests sont longs (en terme de lignes),</li> <li>vos tests sont longs (en terme de temps),</li> <li>vous avez des tests dont le nom est seulement la méthode qu’ils appellent,</li> <li>vous êtes tenté après coup de rendre des méthodes qui étaient privées, publiques,</li> <li>le moindre refactoring fait hurler plusieurs tests (nous rappelons que le refactoring est le fait de changer la structure interne du code sans changer son comportement extérieur)</li> </ul> <p>Pour «attraper le coup», il n’y pas de secret. Il faut s’entrainer, avec des katas, à suivre &nbsp;ces 3 règles :</p> <ul class="liste-arpinum"> <li>Nous n’avons pas le droit d’écrire de code de production pour autre chose que faire passer un test au vert</li> <li>Nous n’écrivons pas plus de code de test que nécessaire pour qu’il soit rouge, et la compilation qui ne passe pas est un test rouge</li> <li>Nous n’écrivons pas plus de code de production que nécessaire pour faire passer un test au vert</li> </ul> <p>Vous pouvez bien sur aussi vous inspirez de démonstrations de praticiens expérimentés, comme ce <a href="https://vimeo.com/16935085">nombre romain en javascript</a>.</p> <p>Une fois que vous aurez «pigé le truc», c’est à ce moment là que le TDD ne vous apparaitra plus comme une contrainte, mais comme une pratique libératrice de votre code, de vos capacités, et de votre plaisir à développer.</p> Agile Tour Bordeaux 2012  http://www.arpinum.fr/2012/06/08/agile-tour-bordeaux-2012/ Fri, 08 Jun 2012 00:00:00 +0000 http://www.arpinum.fr/2012/06/08/agile-tour-bordeaux-2012 <p>Une fois n’est pas coutume, nous sommes cette année à nouveau sponsor Gold de <a href="http://agiletourbordeaux.okiwi.org">l’Agile Tour Bordeaux</a>. Nous sommes aussi toujours impliqués dans l’organisation, quoique officiellement moins que les années précédentes. </p> <img src="/images/blog/at2012_sponsor.jpg"> <p>Pourquoi sponsoriser un tel évènement ?&nbsp;Car notre passion pour les beaux produits, de qualité, créant de la valeur, ne s’est pas tarie avec le temps. Nous sommes toujours intimement persuadés que l’agilité, par ses pratiques et surtout ses valeurs, est à ce jour le meilleur moyen d’atteindre cet objectif. Nous sommes toujours convaincus que les bons produits passent par la réussite et la satisfaction de ceux qui les construisent. Donc, participer, et sponsoriser des évènements tel que l’Agile Tour, mais aussi <a href="http://institut-agile.fr/">l’institut agile</a>, nous semble toujours autant indispensable pour changer le monde, pas après pas. </p> <p>Nous espérons donc vous voir nombreux le 12&nbsp;octobre prochain à <a href="http://www.epitech.eu/ecole-informatique-bordeaux-aquitaine/">EPITCH Bordeaux</a>, et que notre goodies de cette année vous apportera autant de satisfaction que celui de l’année dernière. Pour vous (re)donner envi de venir, voici en bonus le trailer de l’année dernière :</p> <p><iframe width="560" height="315" frameborder="0" allowfullscreen="" src="http://www.youtube.com/embed/0khtz5HAabQ"></iframe></p> MixIT 2012 http://www.arpinum.fr/2012/04/27/mixit-2012/ Fri, 27 Apr 2012 00:00:00 +0000 http://www.arpinum.fr/2012/04/27/mixit-2012 <p>Il faut battre le fer tant qu’il est chaud, et je vais essayer de livrer mon retour sur le Mix-IT. Je n’ai pas réussi à battre <a href="http://agilarium.blogspot.fr/2012/04/retrospective-du-mix-it-2012.html">Fabrice</a>, qui encore une fois a dégainé plus vite que son ombre :)<br> <img src="/images/blog/logo-mixit.png"></p> <p>Mix-IT, c’est une journée de conférence co-organisée par le <a href="http://www.clubagilerhonealpes.org/">Cara</a>, et le <a href="http://www.lyonjug.org/">JUG Lyonnais</a>. 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 :</p> <blockquote><p>«Science sans conscience n’est que ruine de l’âme»</p></blockquote> <p>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.</p> <p>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.</p> <p>La journée a commencé par des croissants bien sur, mais également par deux keynotes.</p> <p>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 :</p> <blockquote><p>«Maman, j’en ai marre d’avoir peur de me tromper»</p></blockquote> <h3>Social Architecture 101</h3> <p>Je suis ensuite aller voir Pieter Hintjens, parler d’architecture sociale. Il est l’instigateur de <a href="http://www.zeromq.org/">zeroMQ</a>, 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 <a href="http://www.danpink.com/drive">Drive</a>, de Daniel Pink, est une lecture bien plus intelligente de cette énergie.</p> <h3>Backbone</h3> <p>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).</p> <p>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.</p> <p>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.</p> <h3>Lightning Talk</h3> <p>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.</p> <p>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).</p> <p>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)</p> <h3>Software Development Workflow at Google</h3> <p>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.<br> 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.</p> <h3>Le DotGame : jouer la performance</h3> <p>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.</p> <h3>Pour conclure</h3> <p>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.<br> 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.</p> <p>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. </p> Agile Open Sud http://www.arpinum.fr/2012/03/18/agile-open-sud/ Sun, 18 Mar 2012 00:00:00 +0000 http://www.arpinum.fr/2012/03/18/agile-open-sud <p>Agile Open Sud, c’était ce week-end à Banyuls, et c’était très sympa. Si vous ne connaissez pas le principe, c’était un espace ouvert se déroulant du vendredi au samedi, pour que les agilistes de tout bord se retrouvent et discutent dans un cadre sympathique. Les principes d’un espace ouvert sont les suivants:</p> <ul class="liste-arpinum"> <li>Les personnes qui sont présentes sont les bonnes</li> <li>Ce qui arrive est la seule chose qui pouvait arriver</li> <li>Ca commence quand ça commence</li> <li>Quand c’est fini, c’est fini.</li> </ul> <p>Pour ma part, j’ai pu participer aux sessions suivantes</p> <ul class="liste-arpinum"> <li>SCOP et structure agile</li> <li>Polyglot data,</li> <li>Un coding dojo</li> <li>Skulls &amp; Roses</li> <li>Agililté et Code Legacy</li> <li>Réflexions pour construire un nouveau jeu agile avec Kodu.</li> </ul> <h3>SCOP et structure agile</h3> <p>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 <a href="http://fr.wikipedia.org/wiki/Sociocratie">sociocratie</a>, sujet que j’ai très envie d’approfondir dans les mois à venir.</p> <h3>Polyglot Data</h3> <p>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.</p> <h3>Coding Dojo</h3> <p>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 :) </p> <h3>Skulls and Roses</h3> <p>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. <a href="http://fr.asmodee.com/ressources/jeux_versions/skull-roses.php">Skulls &amp; Roses</a> est un jeu par le créateur de <a href="http://www.asmodee.com/ressources/jeux_versions/les-loups-garous-de-thiercelieux.php">Loups-Garous</a>, et on y retrouve son amour pour les complots, la fourberie et le bluff. Je le conseil fortement.</p> <h3>Agilité et Code Legacy</h3> <p>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.<br> Techniquement parlant, j’ai (re)découvert la technique du <a href="http://mikadomethod.org/">mikado</a>, 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.</p> <p>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 <a class="highlighted" href="http://referentiel.institut-agile.fr/pairing.html" rel="pairing" target="_blank">pair programming</a> était encore une fois la bonne pratique à mettre en oeuvre pour diffuser de nouvelles manières de faire.</p> <h3>Le jeu du développeur de jeu</h3> <p>Guillaume nous a fait découvrir <a href="http://www.kodugamelab.com/">Kodu</a>, 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 <a class="highlighted" href="http://referentiel.institut-agile.fr/pairing.html" rel="pairing" target="_blank">pair programming</a> 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.</p> <h3>Et aussi</h3> <p>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.</p> <h3>Pour conclure</h3> <p>Il faut avouer que ce fut très agréable, que le format est excellent, et il va falloir refaire ça.<br> 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> <p>P.S : quelques retours ou photos de l’évènements:</p> <p><a href="http://agilarium.blogspot.fr/2012/03/agile-open-sud-2012.html">Fabrice</a><br> <a href="http://www.aubryconseil.com/post/Agile-Open-Sud-c-etait-bien">Claude</a><br> <a href="http://thierrycros.net/?post/2012/03/18/Agile-Open-Sud-2012-%3A-c-est-fait">Thierry</a><br> <a href="http://www.areyouagile.com/2012/03/agile-open-sud-2012-cest-fait-aussi/">Pablo</a><br> <a href="https://plus.google.com/photos/116143551415551277170/albums/5721290570804148241">Des photos</a><br> <a href="https://twitter.com/#!/rvignes/agile-open-sud-2012/members">La liste twitter</a> de (presque) tous les présents<br> <a href="http://ayeba.fr/2012/03/agile-open-sud-2012/">Alexis</a><br> <a href="http://www.rui.fr/event/conf-agile-open-suddone/2012/03/19/">Rui</a></p> Institut Agile http://www.arpinum.fr/2011/12/22/institut-agile/ Thu, 22 Dec 2011 00:00:00 +0000 http://www.arpinum.fr/2011/12/22/institut-agile <img src="/images/blog/institut.png" class="right_pic"> <p>Nous sommes depuis le 1er décembre officiellement partenaire de l’Institut Agile et nous en sommes fiers. :) </p> <p></p> <p>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 <a href="http://institut-agile.fr/">site</a> de l’institut :</p> <blockquote class="quote"><p>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.</p></blockquote> <p>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 <a href="http://referentiel.institut-agile.fr/">travail</a> de Laurent à ce sujet), ainsi que d’impliquer le monde de l’enseignement pour préparer les étudiants à être agile.</p> <p>C’est donc pour toutes ces raisons que nous soutenons l’Institut Agile, et espérons pouvoir l’aider durablement.</p> Agile Grenoble 2011 http://www.arpinum.fr/2011/12/15/agile-grenoble-2011/ Thu, 15 Dec 2011 00:00:00 +0000 http://www.arpinum.fr/2011/12/15/agile-grenoble-2011 <img src="/images/blog/agilegrenoble2011.png" class="right_pic"> <p>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, <a href="http://agile-grenoble.org/">Agile Grenoble</a>.</p> <p>Avec bien peu de sommeil, nous sommes arrivés une demi heure en avance ce qui nous a permis de prendre le café avec <a href="http://twitter.com/#!/claudeaubry">Claude Aubry</a> et <a href="http://twitter.com/#!/thierrycros">Thierry Cros</a> confortablement installés en regardant les gens en rouge s’agiter.</p> <p>La journée a débuté avec une très bonne keynote de <a href="twitter.com/kjscotland">Karl Scotland</a> qui nous a fait une variation de <a href="http://www.startwithwhy.com/">start with why</a>, 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.</p> <p>J’ai assisté ensuite à une session passionnante de <a href="http://twitter.com/#!/jbrains">J. B. Rainsberger</a>, «&nbsp;Les tests intégrés sont une arnaque!&nbsp;». Nous avons eu le plaisir d’assister à la première version totalement en français de cette présentation maintenant très <a href="http://www.infoq.com/presentations/integration-tests-scam">connue</a>.<br> 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.<br> Pendant ce temps là, JB (l’autre, celui d’Arpinum) a assisté à la session de <a href="http://twitter.com/morendil">Laurent Bossavit</a> 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é…</p> <p>Nous nous sommes ensuite rendus à une démonstration du Behaviour-Driven Development «&nbsp;Démonstration / Kata BDD sur un logiciel pilotant un instrument&nbsp;». 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 <a href="”http://en.wikipedia.org/wiki/Behavior_Driven_Development”">BDD</a> 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… </p> <p>Après cette session, nous avons eu le plaisir de voir <a href="http://twitter.com/#!/unclebobmartin">Uncle Bob</a> à travers la diffusion du premier épisode de la série <a href="http://www.cleancoders.com/">Clean Coders</a>. Même en connaissant par coeur le discours du personnage, le montage fait «&nbsp;maison&nbsp;» du premier épisode lui a donné un aspect très plaisant d’un travail fait main, bourré de références de geek.<br> 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 :) ) </p> <p>La pause de midi fût tout aussi agréable, bien que trop courte avec un plateau repas bien garni et d’excellente qualité.</p> <p>L’après midi a repris par une keynote de <a href="http://twitter.com/jurgenappelo">Jurgen Appelo</a> «&nbsp;How to change the world&nbsp;». 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 «&nbsp;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 &amp; control qui a tendance encore à résister dans beaucoup d’équipes dites «&nbsp;agiles&nbsp;». 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.<br> <img src="/images/blog/chasm-e1323947683459.png" class="right_pic"></p> <p>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, <a href="http://twitter.com/morendil">Laurent Bossavit</a> et <a href="http://twitter.com/#!/lmorisseau">Laurent Morisseau</a>, 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 <a class="highlighted" href="http://referentiel.institut-agile.fr/sashimi.html" rel="sashimi" target="_blank">DoD</a> de l’article de <a href="”http://en.wikipedia.org/wiki/Winston_W._Royce”">Royce</a>, mais apparemment il n’en est rien. </p> <p>La deuxième session de l’après midi, Git au quotidien, était une session dans notre «&nbsp;zone de confort&nbsp;» : 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.<br> 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…<br> L’aspect «&nbsp;branches&nbsp;» 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 :) ).</p> <p>Pour la dernière session de la journée, nous avons choisi l’option «&nbsp;canapé&nbsp;» et avons fait l’impasse sur celle-ci, la fatigue aidant.</p> <p>Notre journée s’est terminée par un pot pour fêter avec les autres partenaires notre nouveau statut de membre de l’<a href="http://institut-agile.fr/">institut agile</a>. 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 <a href="”http://wiki.agile-france.org/cgi-bin/wiki.pl?EmmanuelGaillot”">Emmanuel Gaillot</a>. Peut-être à Agile Open France ? </p> <p>Notre seul regret au final dans ce déplacement est de ne pas avoir pu participer à la suite logique de l’évènement, <a href="http://agile-grenoble.org/2011/innovation">Agile Innovation</a>, nos obligations bordelaises nous en ayant empêchées.<br> Nous avons aussi été assez impressionnés tout au long de la journée sur l’organisation infaillible de cet manifestation de 500 personnes.</p> <p>Pour conclure, je pense ne pas trop me tromper en disant «&nbsp;A l’année prochaine Grenoble!&nbsp;».</p> <p>P.S : une mention spéciale également pour <a href="”http://fr.twitter.com/#!/Agilarium”">Fabrice</a>, 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. </p> Code retreat bordelais http://www.arpinum.fr/2011/12/13/code-retreat-bordelais/ Tue, 13 Dec 2011 00:00:00 +0000 http://www.arpinum.fr/2011/12/13/code-retreat-bordelais <img src="/images/blog/gdcr-mini.png" class="right_pic"> <p>Nous avons eu le plaisir d’accueillir le 3 décembre dernier le premier code retreat bordelais. Organisé par l’association <a href="http://www.okiwi.org">Okiwi</a>, 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.</p> <p>Nous nous sommes retrouvés à une quinzaine dans nos locaux pour participer à cette retraite, animée par Jean-Baptiste, coach émérite d’Arpinum :) . </p> <p>Le principe du code retreat est simple :</p> <ul class="liste-arpinum"> <li>on travaille en binôme sur des sessions de 45 minutes se terminant par une rétrospective,</li> <li>on travaille sur un exercice imposé, le jeu de la vie,</li> <li>le code est jeté à la fin de chaque session,</li> <li>le coach choisit de nouvelles règles pour la session suivante.</li> </ul> <p>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.</p> <p>L’exercice proposé lors de ce code retreat, le <a href="”http://fr.wikipedia.org/wiki/Jeu_de_la_vie”">jeu de la vie</a> était propice au travail en pair-programming. Les règles sont simples, mais les choix et les conceptionss qui en découlent sont nombreux.</p> <p>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.</p> <img src="/images/blog/code-retreat-arpinum.jpeg" class="left_pic"> <p>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.</p> <p>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.</p> <p>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… </p> <p>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.</p> <p>On essaie de se refaire ça plus souvent ? :) </p> Agile Tour Bordeaux 2011 http://www.arpinum.fr/2011/11/23/agile-tour-bordeaux-2011/ Wed, 23 Nov 2011 00:00:00 +0000 http://www.arpinum.fr/2011/11/23/agile-tour-bordeaux-2011 <p>L’agile tour Bordeaux, c’était déjà il y a plus d’un mois.<br> Les vidéos sont <a href="http://www.youtube.com/user/agiletourbordeaux">en ligne</a>, je vous laisse ici voir le magnifique trailer concocté par notre <a href="http://web.me.com/munkydinamikblast">reporter de choc</a> : </p> <p><iframe width="560" height="315" frameborder="0" allowfullscreen="" src="http://www.youtube.com/embed/0khtz5HAabQ"></iframe></p> <h2>En tant qu’organisateur</h2> <p>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. </p> <p>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 : </p> <p>- avoir notre propre site,<br> - utiliser notre propre système d’inscription,<br> - utiliser mailchimp,<br> - avoir un open space et un coding dojo toute la journée, et moins de conférences.</p> <p>Je pense pouvoir dire que notre communication et la gestion des inscriptions ont été chaotiques, pour le reste nous sommes assez fiers de nous :) </p> <h2>En tant que sponsor</h2> <p>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é :</p> <p><img width="224" height="300" class="alignnone size-medium wp-image-604" title="photo" alt="" src="http://www.arpinum.fr/wp-content/uploads/2011/09/photo-e1322055835933-224x300.jpg"></p> <p>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…</p> <h2>En tant que participant</h2> <p>J’ai pu assister aux conférences suivantes : </p> <h3>Ni gladiateurs, ni bisounours. Une équipe remarquable au quotidien. Par Christophe Thibaut</h3> <p>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). </p> <h3>Lorsque Scrum ne marche pas. Par Alexandre Boutin</h3> <p>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. </p> <h3>Quarante ans de crise, dix ans d’agilité, et maintenant ? Par Laurent Bossavit </h3> <p>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.</p> <h3>Billes Rouges, animées par Alexis Monville</h3> <p>L’expérience des billes rouges a été mise au point par <a href="http://fr.wikipedia.org/wiki/William_Edwards_Deming">William Deming</a> 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.<br> Alexis a fait filmer tout ça, et voici une petite mise en bouche :<br> <iframe width="560" height="315" frameborder="0" allowfullscreen="" src="http://www.youtube.com/embed/kLcYtZNspn4"></iframe></p> <h2>Bref</h2> <p>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.<br> 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.<br> Je vous dis à l’année prochaine ? </p> Journée mondiale du Code Retreat http://www.arpinum.fr/2011/11/09/journee-mondiale-du-code-retreat/ Wed, 09 Nov 2011 00:00:00 +0000 http://www.arpinum.fr/2011/11/09/journee-mondiale-du-code-retreat <img src="/images/blog/gdcr.png" class="right_pic"> <p>Le 3 décembre est la journée mondiale du <a href="http://coderetreat.com/global_day.html">code retreat</a>, et Bordeaux, grâce à l’association <a href="http://okiwi.org/">Okiwi</a>, aura son évènement!</p> <p>Nous aurons le plaisir d’accueillir et d’animer la première édition bordelaise de cet évènement dans nos locaux.</p> <p>Le principe de cette «&nbsp;retraite&nbsp;» 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.</p> <p>Placée sous le signe du <a href="http://softwarecraftsmanship.org/">Software Craftsmanship</a>, 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.</p> <p>Le nombre de places est assez limité (16), dépêchez-vous de vous <a href="http://coderetreat.ning.com/events/global-day-of-codertreat-bordeaux-france">inscrire</a>!</p> Agile Tour Toulouse, nous y étions http://www.arpinum.fr/2011/11/02/agile-tour-toulouse-nous-y-etions/ Wed, 02 Nov 2011 00:00:00 +0000 http://www.arpinum.fr/2011/11/02/agile-tour-toulouse-nous-y-etions <img src="/images/blog/AT2011.png" class="right_pic"> <p>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.<br> 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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>Je suis aller voir pour commencer la session d’<a href="http://agilitateur.azeau.com/">Olivier Azeau</a> sur les principes <a href="http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod">SOLID</a>. À la manière de <a href="http://www.viddler.com/explore/sigmat/videos/29/">Mock et Stub montent sur scène</a>, 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…</p> <p>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.<br> 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.</p> <p>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.</p> <p>Je suis ensuite aller voir Agile et CMMI, par <a href="http://www.areyouagile.com/">Pablo Pernot</a> et Yassine Zakaria. Pablo avait piqué ma curiosité sur <a href="http://twitter.com/#!/pablopernot">Twitter</a> 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.</p> <p>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.</p> <img src="/images/blog/427705190-e1320231127938.jpg" class="left_pic"> <p>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.<br> 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 :<br> </p><blockquote class="quote"><p>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.</p></blockquote><p></p> <p>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.<br> Nous avons néanmoins des points à améliorer, et nos prochaines versions sous ce format seront meilleures.</p> <p>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 <a href="http://ofps.oreilly.com/titles/9780596518387/">«Apprenticeship patterns»</a> 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.</p> <p>Pour la session de clôture, Toulouse a mis les petits plats dans les grands en faisant venir (paradoxalement)&nbsp;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.</p> <p>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.</p> Le middle management cause de tous les problèmes ?  http://www.arpinum.fr/2011/09/28/le-middle-management-cause-de-tous-les-problemes-%25c2%25a0/ Wed, 28 Sep 2011 00:00:00 +0000 http://www.arpinum.fr/2011/09/28/le-middle-management-cause-de-tous-les-problemes-%c2%a0 <p>Dans le petit monde du coaching agile, il y a un certain consensus qui traîne pour nommer le middle management comme étant la plus grosse contrainte dans le chemin de l’agilité. Encore dernièrement sur tweeter, cette information a circulé (<a href="http://twitter.com/#!/TotherAlistair">cf alistair</a> et <a href="http://twitter.com/#!/jurgenappelo">jurgen</a>).</p> <p style="text-align: center;"><a href="http://www.flickr.com/photos/pahudson/4839265440/" title="Middle Management by p_a_h, on Flickr"><img width="240" height="160" alt="Middle Management" src="http://farm5.static.flickr.com/4090/4839265440_28e945e0e2.jpg" class="aligncenter"></a></p> <p>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.</p> <p><a href="http://www.flickr.com/photos/beginasyouare/6121659469/" title="Crushing Fire by Mike_tn, on Flickr"><img width="240" height="192" alt="Crushing Fire" src="http://farm7.static.flickr.com/6201/6121659469_5fa286278f_m.jpg" style="float: right;"></a>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.</p> <p>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é.</p> <p>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.</p> <p>Comme l’explique très bien <a href="http://cleancoder.posterous.com/">Uncle Bob</a> dans <a href="http://www.amazon.fr/Clean-Coder-Conduct-Professional-Programmers/dp/0137081073/ref=sr_1_1?ie=UTF8&amp;qid=1317214841&amp;sr=8-1">The clean coder</a>, 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.</p> <p>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 » <a href="http://www.humanite.fr/30_01_2011-comment-l%E2%80%99informatique-exige-du-sang-neuf%E2%80%A6-et-pas-cher-463585">bête et méchante</a>, et dans l’émergence d’un certain protectionisme comme en parlait <a href="http://agilitateur.azeau.com/post/2010/11/01/Derri%C3%A8re-l-%C3%A9cran-de-la-r%C3%A9volution-sociale">Olivier Azeau</a>.</p> <p>C’est donc sans grande originalité que je viens de décrire le cercle vicieux de la <a href="http://fr.wikipedia.org/wiki/Th%C3%A9orie_X_et_th%C3%A9orie_Y">théorie X</a>, 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.</p> <p>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 <a href="http://www.okiwi.org">d’Okiwi</a>, 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 <a href="http://shop.oreilly.com/product/9780596518387.do">Apprenticeship patterns</a> tendent vers cette réalité.</p> Le professionnel http://www.arpinum.fr/2011/07/19/le-professionnel/ Tue, 19 Jul 2011 00:00:00 +0000 http://www.arpinum.fr/2011/07/19/le-professionnel <img src="/images/blog/affiche_Professionnel_1981_1-1.jpg" class="right_pic"> <p>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.</p> <p>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.</p> <p>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 :</p> <blockquote class="quote"><p>Le professionnalisme caractérise la qualité du travail de quelqu’un ayant de l’expérience.</p></blockquote> <p>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 ?</p> <p>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.</p> <p>Le bon professionnel gagne donc effectivement de l’argent de son activité, mais optimise en plus chaque denier qui est placé en lui.</p> <p>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 ; &lt;ajouter ici la clause où vous vous reconnaitrez&gt;</p> <p>Pour revenir à notre exemple initial, qu’est ce qui fait de cette personne un développeur amateur, mais un bon game designer ?</p> <p>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.</p> <p>En tant que développeur ceci dit, ce n’est pas la même chanson :</p> <p>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é.</p> <p>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.</p> <p>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.</p> <p>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).</p> <h3>Notes :</h3> <p>Pour plus d’informations sur les caractéristiques et l’éthique d’un développeur professionnel, il existe quelques livres : <a href="http://www.amazon.fr/Clean-Coder-Conduct-Professional-Programmers/dp/0137081073/ref=sr_1_1?s=english-books&amp;ie=UTF8&amp;qid=1311065696&amp;sr=1-1">The clean coder</a>, <a href="http://www.amazon.fr/gp/product/020161622X/ref=s9_simh_gw_p14_d3_i2?pf_rd_m=A1X6FK5RDHNB96&amp;pf_rd_s=center-2&amp;pf_rd_r=08046TMFSXZ52FDS9YTE&amp;pf_rd_t=101&amp;pf_rd_p=463375533&amp;pf_rd_i=405320">the pragmatic programmer</a>, <a href="http://www.amazon.fr/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959/ref=pd_sim_eb_4">the mythical man month</a>, <a href="http://www.amazon.fr/Passionate-Programmer-Creating-Remarkable-Development/dp/1934356344/ref=sr_1_1?s=english-books&amp;ie=UTF8&amp;qid=1311065725&amp;sr=1-1">The passionate programmer</a>.</p> Ne faites pas de l'Agile http://www.arpinum.fr/2011/06/07/ne-faites-pas-de-lagile/ Tue, 07 Jun 2011 00:00:00 +0000 http://www.arpinum.fr/2011/06/07/ne-faites-pas-de-lagile <img src="/images/blog/agilite_s.jpg" class="right_pic"> <p>L’agilité a fêté ses 10 ans il y a quelques mois (enfin, le terme officiel, les méthodes elles, sont plus vieilles).</p> <p>Depuis quelques temps cependant, il est plus à la mode de parler de l’Agile, plutôt que de l’agilité.</p> <p>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 <a href="http://pragprog.com/magazines/2011-02/agile--">article</a>&nbsp;de <a href="http://pragdave.pragprog.com/">Dave Thomas</a> pour exprimer ce qui ne nous convient pas chez Arpinum.</p> <p>On ne peut pas «faire de l’agile», on peut seulement le devenir.</p> <p>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.</p> <p>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.</p> <p>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&nbsp; cérémoniels de Scrum ne va pas faire de vous quelqu’un d’agile, mais juste vous donner l’opportunité de le devenir.</p> <p>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.</p> <p><em>Crédit photos: <a href="http://www.flickr.com/photos/polandeze/390314091/">jump</a>&nbsp;/ polandeze via Flickr CC <a href="http://creativecommons.org/licenses/by/2.0/deed.fr">License By</a></em></p> Bilan sur 5 ans d'eXtreme Programming http://www.arpinum.fr/2011/05/21/bilan-sur-5-ans-dextreme-programming/ Sat, 21 May 2011 00:00:00 +0000 http://www.arpinum.fr/2011/05/21/bilan-sur-5-ans-dextreme-programming <p>En 2006, en arrivant sur une nouvelle mission par la nouvelle SSII venant de m’embaucher, ma carrière allait changer de tournure.</p> <h3>Posons un peu le contexte</h3> <img src="/images/blog/cri_s.jpg" class="left_pic"> <p>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.</p> <p>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.</p> <p>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 <a href="http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670">Code Complete</a> ou <a href="http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612/ref=sr_1_1?s=books&amp;ie=UTF8&amp;qid=1306740574&amp;sr=1-1">Design Patterns</a>, mais toujours pas <a href="http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658/ref=sr_1_1?s=books&amp;ie=UTF8&amp;qid=1306740618&amp;sr=1-1">XP</a>, ni <a href="http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215/ref=sr_1_1?s=books&amp;ie=UTF8&amp;qid=1306740679&amp;sr=1-1">DDD</a>.</p> <p>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 <a href="http://www.amazon.com/Applying-Domain-Driven-Design-Patterns-Examples/dp/0321268202/ref=pd_sim_b_3">Applying DDD de Jimmy Nilson</a>, <a href="http://www.amazon.fr/Pratique-NET-2-0-C/dp/2841773396/ref=sr_1_2?ie=UTF8&amp;s=books&amp;qid=1306741319&amp;sr=8-2">Pratiques de .NET en C# de Patrick Smacchia</a>.</p> <h3>A la découverte d’un nouveau monde<span style="color: #333333; font-weight: 300;" class="Apple-style-span">&nbsp;</span></h3> <img src="/images/blog/lune.jpg" class="right_pic"> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>Le contexte et nos connaissances étant ce qu’elles sont, nous n’avons pas forcément emporté un grand succès. <a href="http://fabien.bezagu.free.fr/index.php?2008/01/23/6-aveu-d-echec">comme l’explique Fabien</a>. Cependant, les premiers mois de ce projet ont été une des meilleurs périodes de ma vie de développeur, jugez plutôt :</p> <ul class="liste-arpinum"> <li>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,</li> <li>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,</li> <li>chaque semaine comprenait son lot d’améliorations.</li> </ul> <p>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.</p> <p>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.</p> <h3>Et donc?</h3> <p>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 :</p> <ul class="liste-arpinum"> <li>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,</li> <li>la simplicité : la peur du mauvais design a disparu, je sais que je vais le faire apparaître par design incrémentiel,</li> <li>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,</li> <li>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.</li> </ul> <p>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 <a class="highlighted" href="http://referentiel.institut-agile.fr/pairing.html" rel="pairing" target="_blank">pair programming</a>. 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.</p> <p>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.</p> <p>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!</p> 1/2 heure pour démarrer un projet http://www.arpinum.fr/2011/05/10/12-heure-pour-demarrer-un-projet/ Tue, 10 May 2011 00:00:00 +0000 http://www.arpinum.fr/2011/05/10/12-heure-pour-demarrer-un-projet <p>Au cours de deux semaines de coaching autour du Domain-Driven Design et de l’eXtreme Programming, j’ai été amené à jouer un atelier assez enrichissant. L’objectif était de démontrer à la fois l’extraction de la connaissance de l’expert métier, et la manière de démarrer le développement en se concentrant uniquement sur ce langage commun.</p> <p>Pour l’occasion, le PMO du projet a endossé le rôle d’expert métier. Son but : tenter de nous décrire son besoin en tant qu’organisateur de courses d’orientation pluridisciplinaires. Il faut avouer, c’était une chance qu’il connaisse si bien ce secteur sans aucun rapport avec notre travail au quotidien. De plus, nous n’avions rien préparé à l’avance, ce qui a donné un exercice « sans filet ». Il ne s’agissait donc pas d’une démonstration académique, mais bien d’une réalité tangible.</p> <p>De mon côté, je devais, avec l’aide du reste de l’équipe, tenter de trouver son problème, négocier les bases d’un langage commun, puis développer la première histoire.</p> <p>Nous avions un peu moins de deux heures pour mener à bien cet exercice.</p> <img src="/images/blog/2661425133_1328692483_m.jpg" class="right_pic"> <p>Pour une équipe assez habituée à la communication avec le métier à travers des spécifications ou des écrans, je pense que le premier impact de cet atelier à été la découverte de cette discussion/négociation avec l’expert pour extraire un langage commun, jamais teinté de technique, d’Excel ou de solutions. Le langage extrait n’exprimait que des concepts riches de sens dans ce contexte : points de sécurité, équipe de sécurité, étapes, participants, performances, course, etc. </p> <p>A la fin de cette discussion, nous avions un lexique, une mindmap capturant notre modèle naissant, et notre première histoire utilisateur. Nous avons pu aborder en plus quelques grands classiques des soucis de communication :</p> <ul class="liste-arpinum"> <li>des solutions étaient exprimées plutôt que des problèmes,</li> <li>beaucoup de synonymes, il a donc fallu décider lesquels choisir et s’y tenir,</li> <li>trop de détails : ils sont très utiles pour comprendre l’ensemble, mais il faut savoir abstraire et décider ce qui est pertinent ou pas dans le modèle en cours de construction.</li> </ul> <p>Le deuxième point très marquant pour l’équipe a été, d’après les retours, l’absence totale de délai entre le moment ou nous avions notre première histoire utilisateur, agrémentée de son test d’acceptation, et le moment où nous avons commencé à développer. Effectivement, l’avantage de ne faire dépendre le cœur de l’application d’aucune considération technique, est que le démarrage du développement est aussi simple que le lancement de son IDE favori et l’écriture du premier test, exactement comme dans les coding dojos que j’animais le matin. Tous les katas que nous avions faits n’ont donc plus été vus comme des exercices d’esprit sans relation avec notre travail au quotidien, mais véritablement comme un entraînement en conditions réelles. Encore une fois, vu que nous n’avions rien préparé avec l’expert, cette demi-heure était du temps réel : voilà tout le temps qu’il faut pour démarrer un projet !</p> <p>Enfin, pendant ce petit développement, nous avons dû régulièrement réinterroger notre expert sur des ambiguïtés que nous avions laissées passer, prouvant par là même qu’un souci dans le code représente un souci dans le métier, pas un souci technique.</p> <p>Cet exercice a récolté les meilleurs ROTI de tout ce que j’ai pu faire en deux semaines, mais je ne le jouerai pourtant pas en premier si je devais être amené à refaire une mission équivalente. J’ai eu le sentiment que l’effet « révélation » de l’exercice n’a pu exister que grâce aux 4 mois de développement précédant mon arrivée, et aux deux semaines de coding dojo/formation/<a class="highlighted" href="http://referentiel.institut-agile.fr/pairing.html" rel="pairing" target="_blank">pair programming</a> qui venaient de s’écouler. Apparemment, l’équipe continue l’exercice dans les désormais traditionnels dojos du matin, et j’ai bien peur qu’elle préfère bientôt développer sur l’exercice plutôt que sur le «&nbsp;vrai&nbsp;» projet :) Après tout, c’est exactement ce qui s’est passé pour nous sur Tiron.</p> <p>J’espère aussi pouvoir compter à nouveau sur l’aide d’un expert jouant aussi bien le jeu la prochaine fois.</p> <p><em>Crédit photos: <a href="http://www.flickr.com/photos/alancleaver/2661425133/">Time</a> / Alan Cleaver via Flickr CC <a href="http://creativecommons.org/licenses/by/2.0/deed.fr">License By</a></em></p> Résumé formations mars 2011 http://www.arpinum.fr/2011/03/23/resume-formations-mars-2011/ Wed, 23 Mar 2011 00:00:00 +0000 http://www.arpinum.fr/2011/03/23/resume-formations-mars-2011 <p>Les intéressés se reconnaîtront, mais voici comme promis quelques liens et ressources pour compléter les sessions de formation de ce mois-ci.</p> <p>Sur le <a href="https://github.com/arpinum">github d’Arpinum</a>, se trouve le code source de l’exercice du video club. La solution est dans la branche solution. Les sources du kata-garros pour le premier groupe sont également à cet endroit, n’hésitez pas à le continuer :) </p> <p>Nous avons abordé beaucoup de sujets pendant ces quelques jours, donc voici quelques liens pour approfondir ces connaissances :</p> <ul class="liste-arpinum"> <li><a href="http://martinfowler.com/articles/mocksArentStubs.html#TheDifferenceBetweenMocksAndStubs">Mocks Aren’t Stubs</a> : l’article de Martin Fowler abordant les différentes doublures de tests, ainsi que les deux écoles du TDD : classicistes vs Mockistes</li> <li><a href="http://www.refactoring.com">Refactoring</a> : le site «&nbsp;officiel&nbsp;» sur le sujet, comprenant entre autre le catalogue des refactorings possible. Bien sûr la lecture <a href="http://www.google.com/books?id=1MsETFPD3I0C">du livre</a> est toujours vivement recommandée.</li> <li>Les principes SOLID de la programmation orientée object : <a href="http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod">cet article</a> d’Uncle Bob est pas mal, sinon il en parle très bien et en détails dans <a href="http://books.google.com/books?id=x4tQAAAAMAAJ&amp;q=practices+principles+patterns&amp;dq=practices+principles+patterns&amp;hl=fr&amp;ei=iNGJTfzyJ46bOsC5-fgN&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=3&amp;ved=0CDYQ6AEwAg">ce livre</a></li> <li>Les odeurs de code : <a href="http://www.codinghorror.com/blog/2006/05/code-smells.html">cet article</a> de Jeff Atwood reprend les différentes odeurs décrites dans le livre sur le refactoring.</li> </ul> <p>Techniquement, outre JUnit et Mockito, nous avons découvert :</p> <ul class="liste-arpinum"> <li>Guava : pour nous simplifier la vie à bien des endroits</li> <li><a href="http://code.google.com/p/hamcrest/">Hamcrest</a> : pour pouvoir écrire de «&nbsp;beaux&nbsp;» assert</li> </ul> <p>Dans nos nombreuses digressions, l’eXtreme Programming a été souvent au coeur de nos débats, donc voici un site assez bien fait présentant plus en détail XP : http://www.extremeprogramming.org. Bien sûr, lire <a href="http://books.google.com/books?id=G8EL4H4vf7UC&amp;printsec=frontcover&amp;dq=extreme+programming+explained&amp;hl=fr&amp;ei=jdaJTfSkBIKEOsf7wKkO&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=1&amp;ved=0CC0Q6AEwAA#v=onepage&amp;q&amp;f=false">le livre</a> est toujours une bonne idée.</p> <p>Nous avons également parlé de la technique du pomodoro, donc voici <a href="http://www.pomodorotechnique.com/">le site officiel</a></p> <p>Si vous cherchez d’autres sujets de kata, <a href="http://codingdojo.org/">codingdojo.org</a> contient quelques sujets. Sinon, google reste une source inépuisable d’informations.</p> <p>Enfin, je rappelle que <a href="http://www.okiwi.org">Okiwi</a> organise toutes les deux semaines un dojo de programmation, pour continuer à s’entraîner sur tout ce que nous avons vu!</p> Les écoles préparent-elles bien les étudiants ? http://www.arpinum.fr/2010/12/07/les-ecoles-preparent-elles-bien-les-etudiants/ Tue, 07 Dec 2010 00:00:00 +0000 http://www.arpinum.fr/2010/12/07/les-ecoles-preparent-elles-bien-les-etudiants <img src="/images/blog/293293358_914e8ccd9b_m.jpg" class="left_pic"> <p>Mon frère suit actuellement des études d’informatique en école d’ingénieur. Son professeur de Java a donné un projet d’année à réaliser. Pour cela, il a distribué un document contenant l’expression des besoins succincte et le déroulement du projet.</p> <p>Mon frère, qui veut réussir ce projet, m’a demandé de l’aide. Comme j’ai aussi été étudiant et que j’ai, comme certainement beaucoup d’autres étudiants, connu de longues nuits blanches une semaine avant de rendre ma copie, je lui apporte des conseils pour se focaliser sur l’important dès le début, avoir un rythme soutenable et voir son avancement. Je suis donc en train de lui expliquer la seule méthode de travail que je connais et qui permet d’atteindre ces objectifs : extreme programming.</p> <p>La fin du projet est prévue pour le mois d’avril 2011.</p> <h3>Un cent mètres avec des boulets aux pieds</h3> <p>Tout pourrait être pour le mieux dans le meilleur des mondes possibles, mais voilà… Dans le document décrivant le déroulement du projet, j’ai vu des contraintes fort déplaisantes.</p> <h4>Fermez la communication !</h4> <h4><span style="font-weight: normal;" class="Apple-style-span"><blockquote class="quote"><p>Fin des questions pour l’appropriation du besoin : le 14 décembre 2010 à 10h30</p></blockquote></span></h4> <p>Un des critères les plus importants d’un projet réussi est l’adéquation entre le besoin et le logiciel réalisé. Pour atteindre cet objectif, une communication constante doit être établie entre le client et l’équipe de développement. Il est aujourd’hui admis, en regard de l’échec des méthodes traditionnelles, qu’il est impossible de prédire dès le début du projet le périmètre de celui-ci. Comment, dans ces conditions, peut-on se permettre de refuser toute forme de communication avant la fin du projet ?</p> <h4>À vos marques, prêt, documentez !</h4> <h4><span style="font-weight: normal;" class="Apple-style-span"><blockquote class="quote"><p>&mdash; Dossier de spécification à rendre le 28 janvier 2011. Première note.</p></blockquote></span></h4> <h4></h4> <h4><span style="font-weight: normal;" class="Apple-style-span"><blockquote class="quote"><p>&mdash; Dossier de conception à rendre le 27 avril 2011. Deuxième note.</p></blockquote></span></h4> <p>Évidemment, quiconque avec un minimum de connaissance dans les méthodes agiles pensera à la deuxième valeur du <a href="http://agilemanifesto.org/iso/fr/">manifeste agile</a> : « Des logiciels opérationnels plus qu’une documentation exhaustive».</p> <p>Nous sommes ostensiblement dans l’approche opposée puisqu’il est dit clairement que les documents qui doivent être fournis seront notés. Il n’est d’ailleurs pas fait mention du code à fournir ni de sa notation dans le reste du document.</p> <h3>Est-ce formateur ?</h3> <p>L’argument avancé par les professeurs pour proposer une approche ne favorisant que très peu l’agilité et la réussite du projet est que <strong>« c’est comme ça en entreprise »</strong>. Je dois bien admettre qu’il y a malheureusement un fond de vérité dans cette affirmation. Ces professeurs estiment donc que le rôle d’une école est de préparer ses étudiants à ce qu’ils vont rencontrer dans les entreprises. Même si pour cela, les étudiants doivent souffrir des méthodes traditionnelles.</p> <h4>Est-ce vraiment ça le rôle des écoles ?</h4> <p>Lors des dernières conférences auxquelles j’ai pu assister, de nombreuses questions portaient sur les problèmes liés au recrutement de jeunes qualifiés aux méthodes agiles. Il est clairement difficile de trouver des jeunes développeurs qui connaissent TDD, la conception incrémentale et l’art de faire le plus simple qui fonctionne.</p> <p>Je mettais cette rareté sur le dos de l’ignorance des méthodes agiles par les professeurs. Hors, visiblement, nous ne sommes pas dans ce cas puisque, toujours selon mon frère, les professeurs prétendent connaître ces méthodes mais <strong>choisissent</strong> de ne pas permettre à leurs étudiants de les utiliser parce que « c’est comme ça en entreprise ».</p> <p>Le monde de l’entreprise a besoin de jeunes professionnels adaptés aux contraintes actuelles et formés aux <strong>meilleures</strong> méthodes qui existent actuellement. Ces jeunes doivent être capable de regarder le fonctionnement des entreprises avec un regard critique et pas avec celui d’un ovin incapable de proposer des changements.</p> <p><em>Crédit photos: <a href="http://www.flickr.com/photos/lionoche/293293358/">On compte plus facilement ses moutons que ses amis..</a> / Lionoche via Flickr CC <a href="http://creativecommons.org/licenses/by-nc-nd/2.0/deed.fr">License By</a></em></p> Idée reçue numéro 2 http://www.arpinum.fr/2010/11/15/idee-recue-numero-2/ Mon, 15 Nov 2010 00:00:00 +0000 http://www.arpinum.fr/2010/11/15/idee-recue-numero-2 <p>Je continue une série de billets consacrés aux idées reçues <a href="http://www.arpinum.fr/2010/09/01/Id%C3%A9e-re%C3%A7ue-num%C3%A9ro-1">débutée ici</a>.</p> <blockquote class="quote"><p>Tu codes mal tu n’as pas mis de commentaire</p></blockquote> <p>Un code fortement commenté n’est pas une propriété d’un bon code, au contraire. C’est souvent le signe d’un manque d’expressivité et de lisibilité du code. La seule documentation perpétuellement à jour est le code lui même.</p> <p>Les commentaires sont mauvais car :</p> <ul class="liste-arpinum"> <li>ils sont voués à être obsolètes,</li> <li>ils brouillent la lecture du code,</li> <li>on perd du temps à les écrire, à les formuler correctement.</li> </ul> <p>C’est seulement quand on échoue à rendre le code explicite que l’on doit s’autoriser à ajouter un commentaire. Et cela doit être rare.</p> <p>Une astuce pour supprimer progressivement les commentaires superflus est d’utiliser le refactoring <a href="http://www.refactoring.com/catalog/extractMethod.html">Extract Method</a>. (Vous noterez au passage la suppression du commentaire dans l’exemple du refactoring).</p> L'agilité sans concession http://www.arpinum.fr/2010/10/13/lagilite-sans-concession/ Wed, 13 Oct 2010 00:00:00 +0000 http://www.arpinum.fr/2010/10/13/lagilite-sans-concession <p>Comme nous le disons la <a href="http://www.arpinum.fr/2010/09/30/Agile-Tour-Bordeaux-2010">semaine dernière</a>, nous étions à l’Agile Tour Bordeaux pour cette édition 2010. A peu prêt 180 personnes ont fait le déplacement, et nous sommes toujours heureux de voir l’engouement qu’engendre les méthodes agiles.</p> <p>Nous espérons avoir ajouté un peu de couleur à cet évènement.</p> <img src="/images/blog/DSC05927_m.jpg"> <p>La session que nous animions avec Michael s’est déroulé selon nos espérances, en se muant en un beau débat qu’il a été difficile de faire tenir dans les temps impartis. Ceci dit, une présentation vivante est pour nous le signe que le sujet intéresse, et que l’exemple que nous sommes en train de bâtir interpelle. Je vais tenter ici de résumer les remarques les plus intéressantes, ou tout simplement celles dont je me rappelle.</p> <p>Une remarque intéressante qui a fusé était que l’agilité en générale, et donc chez Arpinum, ne fonctionne que par la compétence et la motivation des participants au projet. C’est quelque chose qui s’entend assez souvent, que l’agilité est élitiste. Bien sûr, nous ne sommes pas d’accord, et la conclusion qui a été tirée est que le seul pré-requis à une bonne équipe agile est la volonté de s’améliorer. L’agilité vous demande finalement seulement de faire ce que vous savez à un instant t, puis de chercher les moyens de vous améliorer.</p> <img src="/images/blog/DSC05919_s.jpg" class="left_pic"> <p>Une autre question de fond était de savoir comment embaucher des développeurs agiles. Cette question est à double sens : à la fois il faut se demander où trouver les compétences agiles et en même temps, il faut avoir bâti l’environnement qui donne envie à un agiliste de venir chez vous. Les compétences, c’est un sujet assez épineux tant il y a un manque de formation à ce niveau là pour le moment dans les différents cursus proposés. De plus, comme il a été dit, ce n’est pas en 2/3/5 ans d’études que l’on devient un bon développeur agile, mais bien en pratiquant régulièrement et en se confrontant à des problèmes réels. C’est pourquoi en ce moment la communauté agile est assez adepte de notions comme l’apprentissage de maître en maître comme moyen de transmettre le savoir agile. Du coup, la meilleur façon d’embaucher des développeurs agiles est peut être tout simplement d’organiser l’environnement d’apprentissage nécessaire à l’émergence de nouveaux développeurs agiles. Il faut donc plutôt chercher des passionnés, qui sont conscients que leur métier évolue et nécessite donc de gros efforts pour rester à la page et opérationnels, et leur donner une demi-journée par semaine pour aller dans un kata ou ailleurs par exemple.</p> <p>Apparemment, nous avons également surpris par notre capacité à migrer tout un pan de Tiron sans jamais arrêter de livrer de la valeur. Techniquement, il s’agit de notre passage de Spring MVC à Restlet. Sans surprise, cette migration a été possible grâce aux tests unitaires, et en choisissant comme stratégie de migrer petit à petit en développant juste le bout de code qu’il fallait pour faire cohabiter les deux systèmes.</p> Agile Tour Bordeaux 2010 http://www.arpinum.fr/2010/09/17/agile-tour-bordeaux-2010/ Fri, 17 Sep 2010 00:00:00 +0000 http://www.arpinum.fr/2010/09/17/agile-tour-bordeaux-2010 <img src="/images/blog/city_11.jpg" class="right_pic"> <p>Nous aurons le plaisir de faire un retour d’expérience&nbsp; à l’Agile Tour Bordeaux organisé le 7 Octobre 2010.</p> <p>Intitulée «&nbsp;L’agilité sans concession!&nbsp;», cette session présentera comment la pratique stricte de l’agilité a permis la genèse et la réussite d’Arpinum.</p> Idée reçue numéro 1 http://www.arpinum.fr/2010/09/01/idee-recue-numero-1/ Wed, 01 Sep 2010 00:00:00 +0000 http://www.arpinum.fr/2010/09/01/idee-recue-numero-1 <p>Laissez moi entamer ici le premier billet d’une série. Comme le titre l’indique, au cours de nos différentes missions, nous avons eu l’occasion de tomber nez à nez avec certaines idées reçues. Elles sont souvent issues d’une sorte de sagesse collective, de vérités transmises de développeur en développeur depuis des temps immémoriaux. Si parfois elles sont empruntes d’une certaine vérité, il faut bien admettre que dans la grande majorité des cas, c’est tout simplement du grand n’importe quoi.</p> <p>Quelques sites existent déjà pour recenser ce genre de perles, mais nous voulions également adjoindre notre démystification.</p> <p>Allez, ne faisons pas durer le suspens plus longtemps, et laissez moi ouvrir le bal en douceur :<br> </p><blockquote class="quote"><p>Si ce n’est pas cassé, ne répare pas!!</p></blockquote><p></p> <p>Ce vieil adage d’ingénierie, sans doute vrai dans d’autres corps de métier, est un générateur de catastrophe dans le monde de l’informatique. C’est une négation de la conception incrémentale, du refactoring et de l’amélioration continue. Pour garder un logiciel maintenable et de qualité au cours du temps nous DEVONS réparer ce qui n’est pas cassé.</p> Les sirènes de l'agilité http://www.arpinum.fr/2010/08/19/les-sirenes-de-lagilite/ Thu, 19 Aug 2010 00:00:00 +0000 http://www.arpinum.fr/2010/08/19/les-sirenes-de-lagilite <img src="/images/blog/4262542377_4331df962c_m.jpg" class="right_pic"> <p>L’agilité est maintenant très connue. Attirées par toutes ses promesses, de nombreuses sociétés, notamment des SSII, tentent une adoption trop timide, en préférant souvent conserver au maximum leur contexte en place plutôt que de tenter de le modifier pour tirer pleinement partie des promesses de l’agilité.</p> <p>Le cas le plus flagrant est sans doute l’association douteuse du forfait et de l’agilité. Le souci, c’est que la définition même du forfait implique une distance, voire une barrière infranchissable, entre le fournisseur de service et le client. Une équipe sans l’implication du client pourra pousser la qualité au maximum, elle livrera certes une application solide, mais qui passera probablement complètement à côté du besoin. Ce n’est finalement peut-être pas un hasard si le manifeste agile est composé de 25% de notions techniques contre 75% de communication.</p> <p>Fort de cette réflexion, nous nous sommes alors posé l’éternelle question de l’oeuf ou la poule : doit-on d’abord adopter les pratiques techniques et, une fois que nous sommes solides, partir en chasse de clients ouverts; ou bien, comme le préconise Scrum, doit on d’abord adopter son client (c’est beau), et acheter les pratiques techniques pour faire le ménage chez soit afin de satisfaire encore mieux un invité de marque.</p> <p>Il est important de rappeler et de souligner que les méthodes agiles ne sont pas centrées sur le seul fournisseur du logiciel, c’est à dire, pour le réduire à son strict minimum, un manager et une équipe de développement. Ces tentatives managériales envoutées par les promesses séduisantes des sirènes de l’agilité sont malheureusement vouées, nous avons pu le constater trop souvent autour de nous, à l’échec. L’implication du client est primordiale, les développeurs suivront immanquablement si celui-ci prend part activement aux rituels de l’équipe.</p> <p><em>Crédit photos: <a href="http://www.flickr.com/photos/klearchos/4262542377/">The Little Mermaid…</a> / Klearchos Kapoutsis via Flickr CC <a href="http://creativecommons.org/licenses/by/2.0/">License By</a></em></p> Internet Explorer 6 http://www.arpinum.fr/2010/06/01/internet-explorer-6/ Tue, 01 Jun 2010 00:00:00 +0000 http://www.arpinum.fr/2010/06/01/internet-explorer-6 <img src="/images/blog/ripie6.png" class="right_pic"> <p>Comme beaucoup de sociétés vivant sur le Web, nous avons dû nous poser la fatidique question de supporter ou non Internet Explorer 6.</p> <p>Tous les sites de statistiques ne s’accordent pas sur la part restante d’IE 6, mais il est possible de trouver des variations entre 10% et 20%. Ces chiffres sont à mettre en perspective suivant le public, car il faut bien se rendre compte que nombre de sociétés obligent encore leurs employés à utiliser Internet Explorer 6.</p> <p>Alors, pourquoi ce navigateur pose-t-il problème?</p> <h3>Fonctionnalités</h3> <p>Il est sorti il y a tout de même prêt de 10 ans, et forcément, face à un navigateur plus récent, ses fonctionnalités sont bien plus limitées. D’un côté, il s’agit de fonctionnalités pour les utilisateurs, comme la navigation par onglets, l’intégration d’un lecteur de flux RSS, une page de démarrage rapide etc.</p> <p>De l’autre côté, il s’agit également de fonctionnalités pour les développeurs, qui permettent ainsi de proposer de meilleures applications, plus interactives, plus belles et plus faciles à utiliser (pour les curieux, il s’agit essentiellement du support d’HTML 5 et css 3). Du coup, décider de supporter IE6, revient bien souvent à choisir de limiter les fonctionnalités et les interactions pour s’aligner sur le plus faible dénominateur commun.</p> <h3>Rapidité</h3> <p>Encore une fois en raison de son âge, IE6 n’est bien entendu pas au niveau de la concurrence en terme de rapidité de rendu des pages et d’exécution de JavaScript. D’un côté cette lenteur peut avoir un impact assez négatif sur le sentiment de qualité que dégage notre produit, et de l’autre, nous devrions limiter notre usage de JavaScript de peur d’atteindre des records de ralentissement.</p> <h3>Sécurité</h3> <p><strong></strong>La règle première pour avoir un ordinateur sécurisé à l’abris de la plupart des attaques est de mettre à jour régulièrement son système et d’utiliser les dernières versions de ses logiciels. IE 6 comporte encore bien des failles qui sont maintenant connues et facilement exploitables. Sans compter que d’autres continuent à être découvertes.</p> <h3>Qualité</h3> <p>Arpinum a été créé avec une démarche d’amélioration continue, et de recherche de l’excellence. Un navigateur vieux de 10 ans s’accommode difficilement de tels objectifs.</p> <p>Nous avons bien l’intention de proposer à nos utilisateurs les dernières possibilités qu’offrent HTML5, et IE6 se mettrait en travers de notre route dans ce cas.</p> <h3>Normes</h3> <p>Depuis plusieurs années le W3C tente de définir les standards des technologies faisant fonctionner Internet. Le respect de ces&nbsp; normes par tous les navigateurs permet à la fois de fiabiliser son utilisation, mais également de proposer de nouveaux usages plus modernes. En freinant le développement de cette norme, IE6 ralentit également le développement d’Internet dans son ensemble, forçant bon nombre de sociétés à brider leurs produits pour le supporter.</p> <p>Avec tous ces défauts,&nbsp; on pourrait presque dire que les acteurs d’Internet ont tout intérêt à avoir un rôle éducatif, et à pousser en douceur leurs utilisateurs à changer de navigateur. C’est d’ores et déjà le choix qu’a fait Google il y a peu.</p> <p>Pour toutes ces raisons, malgré la présence d’une part de marché encore non négligeable, nous avons décidé de ne pas supporter IE 6 sous Tiron. Bien entendu, nous sommes compatibles avec tous les autres navigateurs du marché, IE 7 et 8 inclus.</p> Fierté http://www.arpinum.fr/2010/04/17/fierte/ Sat, 17 Apr 2010 00:00:00 +0000 http://www.arpinum.fr/2010/04/17/fierte <img src="/images/blog/paon_s.jpg" class="left_pic"> <p>Les valeurs d’Extreme Programming nous ont servi jusqu’à ce jour pour la réalisation de notre projet phare, <a href="http://www.arpinum.fr/tiron">Tiron</a> . Ces valeurs sont la communication, le feedback, le respect, la simplicité et le courage. Nous pouvons également y ajouter l’humanité. Ces valeurs nous animent réellement et modifient profondément notre façon d’aborder notre travail. Avant de travailler avec cette équipe, ces mots étaient souvent vides de sens à mes yeux. Il est difficile, sans avoir vécu une telle expérience, de comprendre à quel point ils ne le sont pas pour nous.</p> <p>Aujourd’hui, il y a une valeur que j’aimerais ajouter à cette liste : <strong>la fierté</strong>. C’est toujours avec beaucoup de fierté que nous montrons notre travail à nos proches et c’est ce sentiment qui a été prépondérant lorsque nous avons ouvert notre service le 13 mars dernier. Tandis que le monde de l’informatique s’est terriblement durci ces dernières années et que les sociétés de service ont cherché à déposséder les développeurs de leur talent créatif en en faisant des ouvriers interchangeables, nous cherchons au contraire à être fiers de ce que nous créons en améliorant sans cesse la qualité de notre produit.</p> <p>Personnellement, je suis particulièrement fier d’appartenir à cette aventure, à cette équipe et, désormais, à cette société. Il est très rare de trouver autant de qualités techniques et humaines que chez mes associés. Chacun, pris séparemment, aurait beaucoup à apporter à de nombreuses équipes parmi lesquelles j’ai travaillé. Charles est le sérieux et la sérénité incarnés, Jean-Baptiste nous apporte sa fougue et son désir de découvertes techniques et Michael a un humour décapant ainsi qu’un regard toujours aiguisé sur les méthodologies. Je n’oublie pas Coraline bien sûr, qui définit notre travail et qui sait faire preuve de patience et de détermination.</p> <p>Pour terminer, je tiens à ajouter que je suis excessivement fier de signer ici le premier billet d’Arpinum et je nous souhaite une longue vie.</p> <p>Soyons fiers de ce que nous avons fait et de ce que nous ferons.</p>