BodySplash.fr

J'essaye de rattraper le retard pour faire un rapide retour sur un atelier animé par Colin Garriga-Salaün, membre très actif et bien connu des bordelais d'Okiwi ^[1]. Donc oui j'ai beaucoup de retard, car on parle tout de même d'un atelier du 4 janvier, et rapide non pas car je n'ai pas aimé, mais car il est difficile d'en parler sans spoiler son contenu.

Du coup, le but de ce bilet va plutôt être de tenter de vous convaincre d'aller le voir quand Colin va le refaire ^[2].

En ce qui concerne le déroulement, la soirée s'est divisée en 4 parties :

• Présentations de différents modèles de changement
• Jeu de l'oie modifié ^[3]
• Debriefing libre et commun
• Bières

La présentation d'ouverture était peut être un peu dispensable, mais le jeu et sutout les réactions après coup valaient vraiment le détour. Je ne peux pas en dire trop, mais j'ai appris des choses sur des notions que j'aborde rarement comme le conditionnement culturel ou la force de l'habitude (entre autre). En plus, j'ai mangé des carambars.

source photo

Je ne sais pas pourquoi ces derniers temps, j'entend pas mal de retours comme quoi le refactoring serait ralenti par les tests unitaires. L'explication derrière cette affirmation douteuse est qu'il faut bien souvent modifier les tests en même temps que le code de production.

J'ai tendance à croire que cette idée bizarre est née d'une des deux écoles de TDD. Ces deux approches ont été bien décrites par Martin Fowler dans son article sur les mocks et les stubs.

Je vais me permettre de le paraphraser ici :

• L'approche classique essaye d'utiliser le plus possible de vrais objets, et un "double" s'il est difficile ou gênant d'utiliser l'implémentation réelle (par exemple, l'envoie d'un mail)
• L'approche par Mock va utiliser dans tous les cas des doubles de test pour tout objet ayant un comportement intéressant.

Pour qualifier ces deux méthodes, Mister Fabien parle de tests Boîte Noire et de tests Boîte Blanche.

Appliquer systématiquement une approche par mock implique une chose : on teste plus la chorégraphie de notre objet que ses résultats. Nous allons vérifier que tel méthode de tel mock a été appelé avec tel paramètre, et que si nous retournons tel valeur, alors notre objet va se comporter de telle manière. Ce faisant, nous liions inexorablement notre test avec l'implémentation sous-jacente, rendant par la même plus douloureux le refactoring, car il nous faudra effectivement changer les tests en même temps que le code de production. L'écriture des tests peut être fastidieux en plus, vu la quantité d'éléments à doubler (constat fait par exemple lors du JUG Bordelais sur le sujet

Dans une approche classique, comme nous testons la plupart du temps le comportement extérieur, nous nous moquons éperdument de l'implémentation, pour vu que le résultat soit bon, et nous passons également moins de temps à écrire nos doubles.

Je ne fais que répéter ce que vous savez sans doute déjà, mais demain, c'est le grand jour. Après plusieurs mois de préparation, voici que l'Agile Tour passe demain par le Labri.

Si tout se passe bien et que vous êtes inscrits, vous avez du recevoir les derniers détails par mail, sinon, nous commençons à accueillir tout le monde à partir de 9h (avec un petit déjeuner et du café pour faire bonne figure).

A 14H, nous aurons la joie avec Charles Couillard de faire une présentation/démonstration de TDD, qui espérons le sera instructive.

Je n'ai pas grand chose à ajouter, si ce n'est de dire que demain est l'aboutissement d'une belle course de fond que j'ai apprécié faire avec les autres organisateurs.

Le sujet est assez connu, mais il se trouve que lors d'un des derniers bilans, nous nous sommes tout simplement posés la question de savoir comment nous mesurions réellement notre vélocité, et en fait cette question n'est pas si simple.

Pour simplifier le débat, je vais partir du principe que nous chiffrons les histoires en jour/pair, sinon ça complique un peu trop la donne.

Si nous prenons Planning XP, nous pouvons lire que la vélocité est le temps passé sur des histoires terminées, alors que Scrum ou d'autres d'ailleurs préconisent plus d'additionner les points des histoires terminées. Voilà deux approches assez radicalement opposées: l'une ne prend pas du tout en compte les estimations passées, alors que l'autre ne s'appuie que dessus. Les deux approches demandent de toute manière que nous tendions à être précis dans nos estimations afin de respecter le contrat de l'itération, cependant, je préfère avoir une vélocité stable aux inconvénients d'une vélocité en montagne russe. En effet, il y a fort à parier que le temps passé sur des histoires terminées va rester globalement stable. Bien sûr, il va il y avoir quelques aléas en fonction de la justesse de nos estimations ou des chaos rencontrés sur la route, mais globalement la vélocité, une fois lancée, va rester sensiblement la même. Dans une approche par addition des estimations, la stabilité de la vélocité dépend énormément de la justesse de notre jugement, et on va se retrouver (et apparemment c'est le cas chez pas mal de monde), avec une vélocité en yoyo, avec un écart type vraiment important.

La stabilité permet de faciliter le travail du product owner, qui globalement sait toujours à quoi s'attendre pour planifier les itérations futurs. De plus pour le sentiment de l'équipe, elle n'a pas l'impression une semaine de ne rien produire, et l'autre de tout défoncer: il existe du cout une sensation d'un effort constant mais soutenable plutôt que de courses folles ou de marches de grands-pères.

Certains outils comme Pivotal Tracker pour contourner le problème propose maintenant la moyenne des 3 dernières itérations comme vélocité (en additionnant les points donc). Même si ça répond en partie à mon problème, je dois avouer que mesurer le temps effectivement passé sur les histoires est très intéressant, dans le sens ou cela permet d'identifier des gaspillages potentiels. Dès la première itération par exemple, on va sans doute voir apparaître qu'on a réussi seulement à travailler 2 heures par jour, alors qu'avec une technique en point, il va falloir attendre bien plus longtemps pour le problème devienne évident. Alors on pourrait me dire que ce n'est pas incompatible, on pourrait mesurer le temps passé réellement ET mesurer notre vélocité en point, mais, rappelons-nous qu'il faut savoir rester simple, et peut être ne pas multiplier les mesures/analyses/conversion etc etc. Quoique, peut être que comme ça le Scrum Master aura enfin du travail

Que d'acronymes dans ce titre. Hier soir, je suis donc allé pour la première fois à une réunion du JUG Bordelais car et d'une, je ne connaissais pas avant, et de deux, le sujet était TDD, et si vous me suivez un peu vous devez savoir que j'y accorde une certaine importance.

Pour mettre les choses au clair, le TDD est pour moi un point critique pour l'avenir de notre profession (oui carrément). Comme aime à le répéter l'oncle Bob, nous devons devenir des professionnels, et cela passe essentiellement par écrire du code propre. Hors comment écrire du code propre? Et bien pour le moment je n'ai pas trouvé mieux, et apparemment je ne suis pas le seul, que d'écrire les tests avant de coder.

Donc voilà le cadre posé, qui va me permettre maintenant de décrire ma déception. C'était un retour d'expérience sur un forfait mené normalement par les tests. Déjà, premier signe d'alarme, l'équipe s'est mise à tdd contrainte et forcée, car c'était une exigence du client. Deuxième point noir, personne dans l'équipe ne connaissait l'approche, du coup bien entendu, ils ont eut d'énormes difficultés à s'y mettre sans quelqu'un d'expérimenté pour montrer l'approche. Suite à cette présentation du contexte, on enchaine donc par une présentation un poil trop succincte de ce qu'est TDD. Ouf on a eu droit au moins un cycle test, code, refactor, mais le refactoring est à mon avis trop passé à la trappe. Disons plutôt qu'il était considéré comme acquis pour le public ou l'orateur, ce qui à mon avis n'était pas du tout le cas. Le plus gros défaut finalement et que cette introduction n'a montré tdd que comme une pratique de qualité, et pas d'architecture. Pire encore, cette présentation a été faite dans l'esprit que la qualité s'oppose à la productivité, ce qui est une des pires idées reçues de notre métier. La productivité passe par la qualité, inévitablement; j'y reviendrai plus loin.

Ensuite, s'en est suivi une partie bien trop longue à mon avis sur les problèmes que l'équipe avait rencontrés, et leurs solutions. Je pense que pour quelqu'un ne connaissant pas le sujet, toute cette partie a eu plutôt tendance à convaincre que tester, c'est long, cher et compliqué.

On finit ensuite par une métrique qui m'a obligée à réagir, encore une fois sur la productivité, à base de "regardez, l'application fait 3000 lignes, mais on a du faire 12000 de lignes de tests . Bouh la productivité de merde". Ok, alors premier point, je crois que l'on s'est bien rendu compte que productivité et nombre de ligne de code n'avait juste rien à voir. Piloter son code par les tests permet d'écrire du code plus concis et mieux structurer, et par la même moins gros qu'un code écrit sans les tests. Donc ces fameuses ligne de code que prennent les tests qui sont soit disant le mal absolu (on est pas payé à tester voyons), combien de lignes de code de production ont-elle économisées? Et à votre avis, entre un code qui fait juste ce qui est attendu, et un code qui en fait trop car il est parti dans les peut-être, lequel a le plus de chance de contenir des bugs? De plus, si on suit le cycle tdd: code de test qui suffit à être au rouge, code minimum pour faire passer, refacto; combien de temps passe-t-on dans le debugger? Oui ces grandes sessions de debugging, où l'environnement met plusieurs minutes à démarrer, où on pose des points d'arrêt à l'aveugle, où on rate son passage donc on doit recommencer; oui elles disparaissent pratiquement intégralement quand on mène correctement le développement par les tests. Pas un mot là dessus hier soir (enfin si, là j'ai pas pu m'empêcher de dire quelque chose). Autre gain de temps par tdd: on reste concentré. Plus de temps perdu car on papillonne sur trop de tâches en même temps: on reste concentré sur le test en cours, ce qui peut le faire passer au rouge ou au vert, et rien d'autre. Le fameux "turnaround" est ainsi réduit. Bien entendu, le gain final évident est qu'il est excessivement plus facile de découvrir et corriger les bugs quand on a produit l'application avec les tests qu'autrement.

Ah ce stade là, je tiens à féliciter la brillante intervention d'un des auditeurs, qui a tout de même sorti que comme les bugs, c'est de la maintenance, et que nous notre travail, c'est le développement, alors on en a rien à foutre de produire une application de qualité. Dixit le bonhomme, le client ne testant pas tout, il va accepter la livraison, nous donner le chèque, et ça nous suffit. Cette attitude à un nom: c'est de l'escroquerie, comme vendre une voiture d'occasion avec des freins prêts à céder. On a fait la vente, mais on a des chances de tuer le client. Cette vision est à mes yeux incroyablement limitée et pourrait presque s'apparenter à l'économie de la Camorra: un profit à très court terme sans considération pour les externalités négatives. Non seulement, le client ne reviendra sans doute pas, (je le sais, j'en récupère des déçus en ce moment), mais en plus, on donne une image de garagiste aux informaticiens. Vous avez déjà eu ce sentiment, en allant faire réparer votre voiture que vous allez vous faire truander? Et bien c'est exactement ce qu'est en train de devenir notre profession avec des attitudes pareils. Je crois que Michael a d'ailleurs bien répondu hier soir à cette remarque Je pourrai ajouter que je ne crois pas de toute manière en cette opposition développement/maintenance, et que la maintenant débute dès le premier commit, mais ce serait un peu hors sujet.

Une question également est passée à laquelle je n'ai pas eu le temps de répondre, c'était l'éternel "le client doit être mature pour accepter les tests". Ah ça je répond, que nous n'avons pas à vendre les tests. Nous n'avons pas à vendre au client que nous allons utiliser de l'intégration continue ou du refactoring. Nous n'avons pas à lui demander s'il préfère qu'on laisse un swicth à la place d'un polymorphisme, s'il préfère qu'on utilise eclipse ou netbeans Ce que je veux dire, ce que nous n'avons pas à lui vendre notre manière de travailler pour qui l'accepte. Il faut arrêter un peu de se plaindre tout le temps car on a pas l'autorisation de faire les choses comme on le voudrait. En tant que professionnels, nous sommes seuls en charge de notre manière de travailler. Nous sommes grands et responsables, et devons assumer pleinement le fait que nous avons un métier. La manière dont on l'accomplit techniquement regarde peu le client du moment que nous maximisons son investissement.

Pour conclure, j'ai tendance à penser que toute initiative pour faire découvrir TDD est bonne à prendre, mais la présentation d'hier soir animée par quelqu'un de très peu expérimenté dans l'approche, et qui apparemment du coup n'était pas du tout convaincu, à fait plus de mal que de bien à mon avis. J'ai conscience bien entendu que je ne prend pas de gants dans ce billet, et si je choque certaines personnes je m'en excuse, mais les commentaires sont ouverts, et puis si des gens du JUG me lisent, pourquoi ne pas organiser un contre débat?

P.S: toutes ces questions sont finalement des classiques, et Fabien avait déjà produit un billet sur le sujet il y a quelques temps pour répondre aux mêmes interrogations.

Je vais ici simplement relayer l'info, si vous ne l'avez pas eu, que le French SUG organise un sondage sur les méthodes agiles en france.

Bon personnellement, je le trouve sur certains points perfectible, mais ne crachons pas dans la soupe, et essayons pour une fois d'avoir des stats intéressantes sur l'utilisation de l'agilité en France. Je n'ai pas spécialement envi de gagner une Wii, mais si vous pouvez me mettre en parain, ne vous en privez pas

Je me permet ici de commenter cet article de Christian Fauré

J'aime cet article car il résume avec des concepts forts un problème que nous sommes nombreux à constater. Ceci dit, je ne suis pas sûr de croire en sa vision de "L'open source solution au mal". D'ailleurs Didier Girard non plus n'accroche pas complètement.

De mon propre petit côté, ce que j'ai pu observer dans le monde de java c'est l'adoption aveugle de solution comme Jboss "parce que c'est la norme". Dans ce choix, il n'y a eu aucun esprit critique, aucune réflexion par rapport au contexte, juste un "tout le monde l'utilise donc nous aussi". Bilan des courses, à avoir choisi un outil sans le connaître, et sans savoir ses possibilités, je me suis déjà retrouvé à devoir reprendre du code qui ne s'appuyait en aucun cas sur les possibilités du framework, et le rendait par là même relativement illisible et truffé de bugs très difficiles à traquer (surtout au niveau de la gestion des transactions et des threads).

L'enfer est pavé de bonnes intentions, mais des solutions comme Jboss ou même Spring participent activement à mon avis à la prolétarisation.

Fondamentalement, c'est l'esprit critique qui fait défaut. Certaines initiatives opensource sont effectivement issus de gens critiques rejetant une solution existante et proposant donc la leur (Je pense encore une fois à Spring, mais aussi à Castle Windsor, NHibernate et bien d'autres). Mais comment insuffler cet esprit à TOUS les développeurs? La plupart d'entre nous travaillons dans un contexte à 0 responsabilité où les choix sont fait par un chef par forcément éclairé. Dans un environnement qui ne favorise pas l'initiative, l'intérêt d'avoir un esprit critique acéré est finalement très limité (c'est presque un handicape en fait). Ca me fait d'ailleurs penser à la théorie X et la théorie Y.

A mon humble avis, l'agilité (vous vous demandiez sans doute quand j'allais y venir :)) permet justement de développer cet esprit critique. La recherche du plus simple qui fonctionne, le design incrémental, la volonté de s'améliorer en permanence sont à mon sens autant de valeurs et de pratiques qui peuvent réduire la prolétarisation. L'abolition aussi de la séparation architecte/développeur me paraît crucial pour obtenir des développeurs critiques. Mon credo serait sans doute "responsabilisez les gens, et alors ils deviendront critiques", et ça tombe bien car l'agilité redistribue les responsabilités.

Il y a quelque temps déjà, j'avais écrit un billet concercnant Scrum Vs XP. Peut-être l'avez vous lu, peut-être pas, mais l'essence de ce que je disais alors entre autre, était que je me méfiais de Scrum car il passait sous silence toutes les techniques d'ingénierie en se concentrant sur la gestion de projet. C'était un danger pour moi, car il me semblait, et me semble toujours, qu'il est impossible de réussir un projet agile sans les pratiques d'ingénierie qui vont bien. Comment travailler en itération si à chaque passage on ne fait que grossir la dette technique n'est-ce pas?

Je vous reparle de tout ça car il se trouve que Martin Fowler en parle aujourd'hui . Alors oui je vous link ça car vous vous en doutez, je suis fier d'avoir obtenu les mêmes concluions que Fowler Ceci dit, je vous le fait passer également car j'aime bien montrer que je ne parlais pas dans le vent, et que le phénomène que j'avais anticipé existe réellement. Fowler est plus dans le consensus que moi, et ne démonte pas Scrum. Mais personnellement, je maintiens ce que je disais: pourquoi choisir Scrum quand XP est complet et n'induit pas le risque d'oublier ou le planning ou l'ingénierie?