BodySplash.fr

Aller au contenu | Aller au menu | Aller à la recherche

mardi 25 août 2009

Vélocité

Par Jean-Baptiste le mardi 25 août 2009, 19:24 - Agilité

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 :)

3 commentaires aucun rétrolien

vendredi 31 juillet 2009

La fin de l'agilité

Par Jean-Baptiste le vendredi 31 juillet 2009, 13:01 - Agilité

Voilà un titre de billet bien pessimiste, surtout venant de quelqu'un co-organisant l'agile tour bordeaux, et pratiquant quotidiennement XP.

Laissez moi expliquer un peu mon pessimisme actuel. Commençons par deux exemples concrets : au cours de deux conversations différentes, avec deux clients différents, voilà les retours que l'on peut avoir en abordant le sujet de l'agilité :

  • "L'agilité, oui on connaît, mais on est beaucoup plus pragmatique que ça nous"
  • Ou bien : "L'agilité? oulala non mon bon monsieur, on veut faire les choses simplement nous".

Ces deux réactions sont authentiques, et même si je ne veux pas tirer de deux exemples une généralité, je me pose cependant la question suivante : Comment, alors que l'agilité avait pour but premier de revenir à des choses simples et pragmatiques, comment maintenant a-t-elle l'image de quelque chose de compliquée et éloignée de la réalité?

Mon embryon de réponse n'est pas neuf, mais je vais tout de même essayer de le résumer. Faisons un peu d'histoire voulez-vous? La première méthode agile, alors que le mot agile n'existait pas, était l'eXtreme Programming. Cette méthode avait ça d'assez magique à mes yeux, qu'elle réconciliait le développement avec la planification et la valeur métier. La première de XP Explained est assez explicite :

"Extreme Programming is about social change"

La première idée est donc de réussir à oublier nos anciennes habitudes, désapprendre ce que nous croyions être la bonne approche, et commencer à envisager notre manière de faire d'un oeil plus adulte. Peut être que l'habitude qui a le plus de mal à passer, c'est la sacro sainte séparation entre développeurs et chef de projet/architectes etc etc. Ce besoin compulsif d'être au-dessus des autres, et par la même de les prendre de haut : "oui môôôa tu comprends, je ne fais plus de technique, je suis chef de projet". Pourtant, le manifeste agile est là pour nous rappeler que "les meilleurs architectures, design ou spécifications émergent d'équipes auto-organisées". Le fait que cette phrase soit issue du manifeste, et non pas d'XP, montre qu'elle est normalement universelle : le manifeste est un consensus obtenu entre des professionnels n'entretenant pas nécessairement les mêmes visions.

Au fil des années pourtant, la mode a été de s'éloigner du pragmatisme et de la simplicité qui était le coeur de l'agilité. "On a pris du recul" diront certains, "on a théorisé" etc, etc. et finalement, c'est le bon vieux modèle pyramidale qui est revenu en force. Scrum, en enlevant les pratiques d'ingénierie pour ne garder que le planning a réintroduit cette idée de séparation entre le "management" et le développement. Le rôle de Scrum Master, quoi qu'on en dise, est un rôle de manager dont l'utilité dans une équipe auto-organisée est vraiment discutable. Ensuite, le rapprochement a été fait avec Lean, avec plus ou moins de bonheur. Même s'il y a des choses intéressants à prendre dans Lean, il ne s'agit en aucun cas d'une méthode agile applicable tel quel au monde de l'informatique. Pourtant maintenant c'est très à la mode de ne plus dire qu'on est agile, mais dire qu'on fait du lean. Prenez pour exemple cette vidéo. On y voit en fait, une présentation d'XP, de bout en bout, sans jamais le citer. Alors je ne doute pas que cette équipe fonctionne très bien, mais il n'empêche que cette vidéo est un mensonge : la clef de leur succès provient d'XP, pas du Lean.

Alors pourquoi est-ce que je tiens tant toujours à ramener XP sur le devant de la scène? Car l'agilité perd son sens, et les mauvais retours se multiplient d'équipes qui n'ont pas réussi à mettre en place l'agilité, car on leur a fait croire que ça ne demander pas de changements de techniques, ou une discipline d'ingénierie en acier trempé. Je reviens toujours à la charge, car c'est l'agilité qui va mourrir, du moins dans cette forme là, si autant de gens continuent à la répendre en passant à côté de ses concepts fondamentaux. Oui j'ai rencontré des architectes dans leur tour d'ivoire, des chefs de projet, des sociétés entières, se disant agile, alors que l'équipe de développement n'en avait même pas entendu parler. La diffusion sémantique fait son travail, et il me semble donc indispensable que de loin en loin, certains fassent des piqûres de rappel, pour demander "R U doin it rong?". Je pense que c'est le but premier du Craftsmanship manifesto.

Ce qui devient vraiment dommage dans cette histoire, c'est que nous tenions enfin une vision unifiée de collaboration de tous les acteurs nécessaires à la réussite d'un projet, l'abolition d'un sectarisme corporatiste, mais hélas, nous revoilà à nouveau face à la guéguerre "les techies vs les chefs", et ça, ça me rend vraiment triste. Est-ce qu'il sera jamais possible à grande échelle de dépasser ce réflexe puérile du "mon poste est plus gros que le tien?".

L'agilité va disparaître, mais XP finalement, restera en trame de fond pendant bien longtemps, car en fait, c'est déjà le cas

13 commentaires aucun rétrolien

lundi 13 juillet 2009

Deux petits liens

Par Jean-Baptiste le lundi 13 juillet 2009, 17:13 - General

Les plus attentifs auront remarqué les deux nouveaux logos qui ornent le côté droit de ce blog.

Le premier permet pour ceux que ça intéressent de me suivre sur Twitter, mais je préviens, je ne suis pas sûr de très bien comprendre l'intérêt du bousin, donc je ne "twitte" pas beaucoup.

Le deuxième est plus "drôle". Ca fait un certain temps que je voulais l'ajouter, mais Fabien l'a fait avant moi du coup. Bref, je vous invite donc à rejoindre la compagne anti-if.

aucun commentaire aucun rétrolien

mercredi 24 juin 2009

Structure et frameworks

Par Jean-Baptiste le mercredi 24 juin 2009, 18:06 - Code

Voilà un titre bien obscure. Alors de quoi allons parler aujourd'hui? De la manière la plus simple que je vois actuellement de commencer une application web en java. Il y a quelques semaines effectivement un ami me demandait finalement quoi utiliser pour démarrer un projet de 0 e, avec comme postulat de base que finalement, tout était bien compliqué. Je vais donc décrire ici mes environnements/outils/frameworks favoris qui à mon sens, permettent de s'en sortir dans la grand majorité des cas, et tout en fournissant une base à la fois solide et extensible.

L'environnement

Avant même de commencer à développer, mieux vaut savoir comment nous allons développer. Je pense maintenant qu'il y a une base indispensable à tout projet avant même de penser conception et développement.

Build

Avec quoi construire notre appli? Ca a l'air bête comme question, mais ce n'est en fait pas si simple dans le monde de java, ou tout n'est pas aussi intégré et monolithique que dans le monde .NET.

Par défaut, à peu prêt tout le monde utilisait Ant. Personnellement, je n'en peux plus: xml au kilomètre, dépendances gérées à la main, pas user friendly, bref, une horreur à mes yeux. Si vous lisez de temps en temps ce blog, vous devez vous douter que je vais proposer Maven. Avec maven, il va être possible en 2 lignes de xml d'avoir un projet entièrement compilé, testé, packagé. Les dépendances sont téléchargées depuis un entrepôt central, et il les gère en cascade, donc on ne passe plus des heures à linker ou mettre à jour les libs externes, c'est géré. Si on suit ses conventions, c'est bien simple maven permet de faire oublier une grande partie des tâches techniques de base d'un projet.

Une question qui peut venir et savoir comment organiser son projet dans maven: Multi module ou mono module? l'avantage du multi module est qu'il va garantir une séparation entre les couches, là ou le mono module si on ne fait pas attention peut entraîner un certain mélange. Ceci dit, la complexité du multi module au début ne compense pas ce risque hypothétique, et mieux vaut de toute manière enseigner qu'interdire. Donc, jusqu'à le projet atteigne une complexité trop importante, je préfère la simplicité du mono module tout en faisant attention à ne pas mélanger les couches.

SCM

Même si vous êtes seuls, il vous faut quelque chose pour conserver et versionner votre source, ne serait-ce que par sécurité et pour avoir la possibilité de revenir en arrière. Git a beau être une star montant, je ne le connais pas, et je vais donc me contenter de conseiller subversion: simple, efficace, et non intrusif (pas de lock par défaut sur les fichiers).

IDE

Certains puristes vont certainement dire qu'un éditeur de texte suffit pour développer, mais à mon avis, on est loin d'une productivité optimale. Voilà à mes yeux ce que doit ABSOLUMENT faire un IDE:

  • intégrer les test unitaires : pouvoir les lancer facilement, et naviguer rapidement dans le code incriminé par un test rouge,
  • refactoring : c'est à mon sens l'outil ultime de productivité et de qualité. Sans aides au refacto il est trop facile, par manque de courage ou de temps, de ne pas faire des changements pour clarifier le code. Pourquoi renommer une classe si ça nous prend 10mn de faire le tour de l'appli pour trouver ceux qui l'utilise? Pourquoi extraire une super classe et centraliser du comportement si c'est un long travail fastidieux de copier/coller? Voilà pourquoi je pense qu'il est juste indispensable qu'un IDE intègre un certain nombre de refactorings assistés
  • auto-complétion, coloration, indentation: c'est la base, mais il est bon de le rappeler
  • navigation rapide dans le code: il doit être possible d'ouvrir rapidement des types ou des fichiers, mais aussi depuis une classe par exemple d'aller directement dans le code d'un objet qu'elle inclue.

Il y aurait être d'autres choses à ajouter, mais c'est déjà pas mal. Les trois IDE les plus connus du monde java (Eclipse, NetBeans, Intellij Idea) assurent tous ces fonctionnalités en plus d'une intégration à Maven indispensable dans notre cas. Je ne vais pas rentrer dans des débats religieux sur lequel est le mieux, mais personnellement j'utilise Eclipse.

Intégration continue

Je pense que l'intégration continue doit être en place dans le premier jour du projet, il ne faut pas attendre de commencer à avoir des soucis pour la mettre en place. Le minimum est bien sur de compiler l'application et de faire tourner les tests.

Il existe maintenant pas mal de solutions gratuites, mais je dois avouer ma nette préférence pour Hudson, grâce à son esprit "on déploie et ça marche". C'est très simple à mettre en place, il marche très bien avec Maven, et il peut être étendu à souhait avec pas mal de plugins. Que demander de plus?

Les technos

Bien, nous avons la base pour commencer à développer, c'est bien, mais ça ne nous dit pas quels frameworks utiliser pour bâtir notre application web. Au risque de spoiler un petit peu, je vous annonce tout de suite que je ne vais pas conseiller JEE, même en version "simple" en n'utilisant que servlet/jsp.

Restlet

Voici un framework qui mériterait un billet à part entière, mais je vais essayer de faire un résumé. Le but de restlet est de servir de base pour produire et consommer des ressources conformément à l'approche Rest. Ce qui est bien avec ça, c'est que l'on peut commencer très simplement, en faisant une application "à l'ancienne" avec des pages html entièrement générées côté serveur, puis commencer à si on veut à faire plus du RIA, avec GWT, Flex, Dojo, peu importe, les ressources restent les mêmes, on négocie juste une représentation différente.

Comme je le disais, Restlet est très simple à mettre en place, pas besoin de conteneur de Servlet ou autre, il peut démarrer son propre serveur web en une seule ligne de code. Les ressources et la configuration se fait également entièrement dans le code, avec quelques recours très discret aux annotations. Bref, Restlet est une base idéale pour toute application web: il est multi-paradigme, peut grossir en même temps que votre application sans vous forcer une grande complexité dès le début, bref, je suis fan. Ah vous de choisir au début si vous voulez faire une application à l'ancienne, du GWT, du flex etc etc, Restlet supporte tout le monde de toute manière. Suivant ce que vous avez décidé, vous pouvez ensuite par exemple utiliser Freemarker ou Velocity pour générer la représentation html de vos ressource selon une approche MVC bien connue.

Hibernate

Ah voilà un choix plus discutable n'est-ce pas quand on cherche à définir les frameworks les plus simples pour démarrer n'est-ce pas? Le plus simple pourrait-on me dire, serait de directement se connecter à la base, et de faire nos requêtes. Le soucis avec cette approche, c'est que jamais elle ne sera capable de gérer correctement une grande complexité. On se retrouvera nécessairement avec du code mort, de la duplication et une très faible réutilisabilité du code. Ceci dit, il doit y avoir plus simple qu'Hibernate non pour accéder à nos données? Sûrement, mais là je vais devoir avouer que je suis complètement perverti par DDD, et je ne conçois pas de ne pas d'abord penser objet, tester, puis seulement ensuite de faire apparaître la base. Seul un mapper O/R par metadata mapping permet d'utiliser cette approche à 100% , et hibernate est la meilleure solution open source gratuite que je connaisse pour atteindre ce but. Ah mes yeux, et pour une fois, l'effort d'écrire et maintenir tout ce XML me semble complètement être compensé par la valeur: pouvoir écrire un modèle du domaine testable et indépendant de toute considération technique. Le point discutable est sans doute, dans le cadre d'une application juste CRUD, est-ce que ça vaut le coup de sortir l'artillerie lourde? Ma réponse habituelle est que je n'ai jamais connu en 7 ans d'applications qui faisaient simplement du CRUD, donc j'ai le sentiment que ce n'est pas la règle mais le cas particulier. De plus, comment savoir à l'avance que l'application ne fera QUE du CRUD quand on la commence?

Quelques remarques

Il y a bien entendu des critiques à émettre sur le choix des technologies de base, notamment sur la productivité. Il y a peu voir pas du tout de travail prémaché dans ce que j'ai proposé, pas de composants déjà utilisables rapidement, ou de scripts pour générer rapidement les "échafaudages", sans doute parce que je ne suis fan d'aucunes des technologies proposant ces options, car trop de choix me déplaisent dedans (Ruby on Rails et Grails sont très contraignants sur pas mal de points, tant ils font de choix pour nous, Wicket, JSF and co sont orientés composants et modèle par page et ne tirent pas partie à mon avis des avantages du web; Spring MVC est déjà plus sympa, surtout en version 3, mais c'est déjà beaucoup plus lourd que Restlet...)

aucun commentaire aucun rétrolien

jeudi 18 juin 2009

Ruby

Par Jean-Baptiste le jeudi 18 juin 2009, 15:12 - Code

Voilà quelques temps que je m'intéresse à la nouvelle star montante des langages de programmation : Ruby.

Etant donné que je ne suis pas du tout encore un expert sur le sujet, je ne vais pas m'éterniser, mais laissez moi partager quelques remarques avec vous. La communauté Ruby se vante, souvent à juste titre, d'utiliser un langage très expressif, piloté par les bonnes pratiques de développement. Cependant, je n'ai pu m'empêcher de noter quelques éléments qui, je trouve, contredisent cette affirmation.

Le premier constat vient tout simplement des méthodes de conversion, les classiques toString, toInt etc etc que nous pourrions trouver dans d'autres langages. Plutôt que d'utiliser des noms complets, en ruby nous allons trouver des to_s, to_a, to_i. Pour un langage qui se veut expressif, je trouve ça excessivement choquant d'utiliser des acronymes pas nécessairement évident.

Deuxième constat, saviez vous qu'il existe une différence entre les méthodes eql? et equal? L'un compare sur le type et valeur, et l'autre sur la référence. Différencier ces deux comportements juste par une convention de nommage très bancale me semble juste aberrant. Un débutant ne peut juste pas faire la différence, et même les plus expérimentés peuvent facilement se laisser tromper. Ruby se vante également d'être entièrement orienté objet, contrairement par exemple à Java ou C# qui font tout deux la différence entre des types primitifs et les types références. Cependant, les libs globalement fournies avec Ruby sont tout simplement noyautées de méthodes statiques. Pourquoi se venter d'être Full OO si c'est pour s'appuyer aussi lourdement sur une approche procédurale?

Enfin, dernière remarque, Ruby ne supporte pas la surcharge de méthode: le nom d'une méthode doit être unique dans une classe. Du coup, si on veut utiliser la surcharge, qui est tout de même très pratique, on doit accepter en fait un nombre variant de paramètres, et à nous de tester tous les cas d'appels que l'on veut gérer. La complexité cyclomatique générée par cette approche est juste énorme. La liste pourrait s'allonger encore, tant finalement le langage est l'interpréteur sont bourrés de "petits trucs" qui sont juste impossible à deviner et peuvent briser votre programme si vous ne les connaissez pas. Par exemple, j'utilisez un "gets" pour lire une entrée en mode console, et quand je me suis à passer un paramètre à la commande, ça ne fonctionnait plus. Le côté souvent "magique" de certaines parties de ruby brisent à mon sens le principe de moindre surprise, et le gets en est un bon exemple.

J'essaye de faire la part des choses bien entendu, et je n'ai essayé ici de citer ici que ce qui me semble être de vrais soucis, et non pas des habitudes provenant d'autres langages. Un langage qui vaut la peine d'être appris doit changer note manière de penser, et Ruby m'a effectivement apporté beaucoup, et je l'apprécie. Ceci dit, après un tel buzz, je ne peux pas m'empêcher d'être déçu par ces détails qui sont mines de rien, pas si insignifiants que ça.

un commentaire aucun rétrolien

mercredi 27 mai 2009

groupe de discussion autour de ddd

Par Jean-Baptiste le mercredi 27 mai 2009, 11:46 - General

Voilà quelques mois déjà que j'annonçais l'ouverture officielle de DDDFrance. Par manque de temps, il faut avouer que nous n'avons pas fait grand chose depuis pour remplir le site ou pour attirer une communauté dessus. Après quelques réflexions cette semaine, Fabien a proposé la création d'un groupe de discussion. Effectivement, le wiki, apte à intégrer le changement, ne semble pas pour le moment être le meilleur moyen de structurer des conversations. De plus, il faut avouer que c'est un peu intimidant de modifier "en live" en site web pour poser sa question.

Du coup, je vous présente le groupe de discussion google autour de ddd en français. L'idée est d'avoir des conversations, espérons le, de qualité, dont nous pourrons ensuite tirer une synthèse à mettre sur le wiki.

A vos inscriptions!

aucun commentaire aucun rétrolien

vendredi 15 mai 2009

Retour sur Bordeaux JUG TDD

Par Jean-Baptiste le vendredi 15 mai 2009, 15:14 - Agilité

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.

4 commentaires aucun rétrolien

lundi 11 mai 2009

Agile tour

Par Jean-Baptiste le lundi 11 mai 2009, 16:17 - Agilité

Ceux qui sont particulièrement à l'affût ont peut être noté via le groupe de discussion XP France, ou bien par le blog de fabien, que l'Agile tour cette année passera par Bordeaux. Il se trouve que je participe également à son organisation, donc même tarif ici que sur le blog de fabien: posez des questions, faite passer vos attentes/vos remarques, bref si vous avez des choses à dire, dite le :)

3 commentaires aucun rétrolien

vendredi 8 mai 2009

Enquête sur les méthodes agiles

Par Jean-Baptiste le vendredi 8 mai 2009, 15:02 - Agilité

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 :)

aucun commentaire aucun rétrolien

lundi 4 mai 2009

Osons nous montrer au grand jour

Par Jean-Baptiste le lundi 4 mai 2009, 18:20 - Agilité

Car il n'y a plus de hontre à être Développeur :) Ainsi, j'assume et j'estampille.

exp

P.S: J'ai découvert ce joli petit logo très dans l'esprit XP par Denis Dolfus, et on doit un merci à Emmanuel Chenu

aucun commentaire aucun rétrolien

dimanche 26 avril 2009

Livres

Par Jean-Baptiste le dimanche 26 avril 2009, 22:08 - General

Comme ça va faire plusieurs fois que l'on me demande conseil sur quelques livres informatiques, je me suis dit que ce serait pas mal de faire une page ici résumant les quelques livres que je considère comme limite indispensable et/ou très instructif. Je dois avouer qu'il y a deux livres dans cette liste que je ne possède pas moi-même, mais bon il me semblait intéressant de les mettre tout de même.

Je les ai catégorisé pour essayer de faciliter le choix, mais cette séparation n'est bien sûr pas parfaite. J'essaierai aussi si je trouve le temps d'écrire un petit commentaire pour chacun.

Tout se passe donc sur cette page

un commentaire aucun rétrolien

jeudi 9 avril 2009

A pu HADOPI

Par Jean-Baptiste le jeudi 9 avril 2009, 16:52 - General

aucun commentaire aucun rétrolien

lundi 6 avril 2009

Scrum, c'est xp sans le côté geek

Par Jean-Baptiste le lundi 6 avril 2009, 20:07 - Agilité

Je vais simplement ici vous conseiller de regarder la vidéo qui suit, (et merci à Fabien pour le lien). Le titre est provocateur, mais finalement assez vrai. Bref, je vous laisse en compagnie d'un des papas de l'agilité. Cliquez ici, si si.

3 commentaires aucun rétrolien

mercredi 1 avril 2009

Le nombre de if comme signe de qualité

Par Jean-Baptiste le mercredi 1 avril 2009, 15:47 - Code

Voilà quelques temps déjà, en parlant du projet, un des membres de l'équipe ne venant pas vraiment du monde objet avait fait la remarque que ce qui l'étonnait le plus dans notre code, c'était le très faible nombre de if. Remarque intéressante, mais que j'oublie un peu et voilà qu'hier, j'entends la remarque de la part de quelqu'un d'autre, et concernant un autre projet. Cet après-midi, j'ouvre un projet que je suis censé faire évoluer, et je tombe sur bien peu de classes, mais avec beaucoup de méthodes un peu trop grosses et surtout bourrées de if. Non content d'induire une certaine difficulté à la relecture, la plupart de ces if en fait étaient la pour palier l'absence de concept. C'est à dire qu'ils servent essentiellement à tester la valeur de string et faire un traitement adéquat. Je ne sais pas à quoi cela vous fait penser, mais très personnellement ça m'a amené à l'esprit le refactoring d'école : "un switch est un polymorphisme manqué". Et c'est vrai qu'en essayant de faire apparaître de nouvelles classes avec les bonnes responsabilités, les if ont fondu, le design est devenu plus évolutif et "ouvert à l'extension", et le code beaucoup plus facile à relire.

Du coup, pour revenir au titre de billet, c'est presque à se demander si le nombre de if ne serait pas une métrique intéressante à mettre en oeuvre pour donner un indicateur de plus sur la qualité d'un projet. Le chiffre est bien sûr à mettre en perspective en fonction de la taille du projet, mais je pense qu'un faible nombre de if du coup aurait tendance à démontrer un design pensé en terme de responsabilités plutôt qu'en séquentiel.

2 commentaires aucun rétrolien

mardi 24 mars 2009

La qualité, ça compte

Par Jean-Baptiste le mardi 24 mars 2009, 12:23 - Code

Si vous lisez régulièrement ce blog, vous devez sans doute savoir que je développe depuis quelques mois maintenant dans un environnement full JEE5. J'ai eu l'opportunité tout d'abord de démarrer un projet de 0, puis de reprendre pas mal d'applications existantes.

Mon premier réflexe en commençant la nouvelle application, à part écrire un test, a été d'appliquer au moins les quelques patterns d'organisation de DDD, à savoir aggregate, entity et value object. J'ai pris tellement l'habitude de structurer mon domaine de cette manière que j'aurai d'ailleurs bien du mal à faire autrement. Bref, comme d'habitude ça a fonctionné et j'ai obtenu un modèle du domaine "taclant" correctement la complexité sans devenir illisible.

J'ai du ensuite reprendre d'anciennes applications également sous JEE donc, et je dois avouer que c'était la première fois que je m'essyais à cet exercice. Oui j'avais déjà travaillé sur des "brown fields", mais ils avaient tous en commun de s'appuyer intensivement sur la base et pas sur du "code". Du coup, ce que j'ai découvert en fait m'a "ouvert" les yeux encore plus sur l'intérêt des patterns décrit dans DDD. Car finalement, ce que j'ai eu à reprendre est globalement du code qui essayait d'utiliser les concepts EJB3, mais sans auncune structuration. Donc on se retrouve avec des DAO dans tous les sens, même pour récupérer des entités dépendantes d'une racine; on trouve carrément des références vers des ID plutôt que vers les entités réelles, des références croisées dans tous les sens, bref, je me suis retrouvé face à ce que tout que les concepts d'aggregate/entity/value objet essayent d'empêcher, tous ces problèmes qui font croire à pas mal de gens que l'objet, c'est imbitable.

Bilan de cette histoire:

  • et d'une, il y a toujours des choses à prendre dans DDD,
  • de deux, avant d'entrer dans des systèmes aussi complexes que peuvent être les différents serveurs JEE, et se vanter de faire des supers architectures , il faudrait se concentrer sur qui compte réellement : le code. Je ne veux pas faire une généralité de cette règle, mais je ne compte pas le nombre de tutoriaux/messages de forum/newsgroup etc etc ou j'ai pu constater ce phénomène de "branlette sur l'architecture" alors que le code montré en exemple était tout simplement dégueulasse.

L'architecture n'est pas un paliatif à du code de piètre qualité.

6 commentaires aucun rétrolien

vendredi 20 mars 2009

Bonne rigolade

Par Jean-Baptiste le vendredi 20 mars 2009, 11:22 - Agilité

Je sors de la lecture de cet article, et je dois avouer qu'il y a quelques passages qui m'ont bien fait rire. Le sujet est délicat, vu l'opposition souvent constatée entre CMMI et l'agilité, mais commencer un article tentant de venter la fusion des deux par il ne reste qu’un levier d’actions permettant de maximiser l’utilisation des ressources humaines et technologiques : Les procédures et les méthodes c'est tout de même bien se rater. Petite piqure de rappel, dans le manifeste agile, on trouve Individuals and interactions over processes and tools . Le reste de l'article est à mon goût un peu trop de la même veine, parlant énormément de processus, et rarement d'interactions.

Ensuite, sur le fond, je je vais gentiment botter en touche pour le moment, en plaidant l'ignorance :) La seule expérience (qui a dit confrontation?) que j'ai eu avec le CMMI était à mon avis bien trop caricaturale pour que je puisse en faire un cas générique. Tout ce que je peux dire, c'est répéter que si effectivement le CMMI favorise les processus et les méthodes comme le laisse entendre cet article, alors à mon avis il y a une certaine incompatibilité d'humeur.

7 commentaires aucun rétrolien

lundi 16 mars 2009

La prolétarisation dans les sociétés informatiques

Par Jean-Baptiste le lundi 16 mars 2009, 10:48 - Agilité

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.

3 commentaires aucun rétrolien

lundi 9 mars 2009

HADOPI

Par Jean-Baptiste le lundi 9 mars 2009, 09:18 - General

HADOPI - Le Net en France : black-out

un commentaire aucun rétrolien

mercredi 25 février 2009

Perf4j

Par Jean-Baptiste le mercredi 25 février 2009, 09:19 - Code

Bon aujourd'hui, je ne vais pas vous infliger un grand discours philosophique. Je voulais juste partager ma petite découverte de la semaine: perf4j, dont la philosophie se résume à cette phrase:

Perf4J is to System.currentTimeMillis() as log4j is to System.out.println()

L'idée est donc qu'il doit être aussi facile d'introduire du code de profiling que du code de logging. Donc à la manière que Logger.getLogger, nous allons récupérer un StopWatch dont l'implémentation dépend de votre framework de logging favoris. L'idée est de générer des traces de performances enregistrées par votre système de log habituel. Du coup le système est entièrement configurable au même endroit que le logging. Si jamais vous trouvez ce code trop envahissant, nativement il est possible d'utiliser aspectJ ou SpringAOP pour le tisser à votre place.

Perf4j est ensuite livré avec un outil en ligne de commande capable d'analyer ces traces, et de proposer des aggregats et des graphes. En poussant la configuration un peu plus loin, on peut même du coup avoir des informations de performances en temps réel via jmx/servlet/etc etc.

Perf4j a mon sens ne remplace pas complètement un bon vieux profiler quand il s'agit d'identifier les problèmes de performance d'une application, mais son extrême simplicité et sa capacité à fournir des statistiques sur le code même en production m'ont assez plu.

J'avais un petit besoin de profiling, et j'ai été heureux de trouver un outil simple pour ça.

2 commentaires aucun rétrolien

vendredi 13 février 2009

Domain Driven Design France aka DDDFrance

Par Jean-Baptiste le vendredi 13 février 2009, 11:38 - General

Ça va faire presque un an que Fabien et moi avions commencé à parler de ce projet suite aux différents échanges qui ont suivi la présentation de DDD de Sami Jaber pendant le Symposium DNG.

Avec beaucoup de retard, la participation d'autres amis et un contenu bien en deçà de ce que nous avions prévu, j'ai la joie de vous annoncer l'ouverture officielle de DDDFrance.org.

Oui le site n'est pas réellement fini, et il lui manque à mon avis le contenu minimum. Nous avons sans doute à la fois manqué de temps et d'énergie, mais ce billet sur le blog de Xebia nous a convaincu qu'il ne fallait plus tarder.

Je vous laisse découvrir le site. Je dirai juste que ce n'est pas pour rien que c'est un wiki, et que la force future et hypothétique de ce site sera sa communauté. Ou pas.

12 commentaires aucun rétrolien

- page 2 de 6 -