Michael Borde

Agile Tour 2010 Bordeaux

2010-10-03T12:28:00.007+02:00

L'édition bordelaise de l'Agile Tour aura lieu le jeudi 7 octobre prochain, dans les locaux de l'ENSEIRB-MATMECA. J'ai l'impression que l'édition 2009 vient à peine de s'achever que nous devons une nouvelle fois enfiler nos brassards (bleus cette années :)).

En tant qu'organisateur j'ai bien entendu fais lourdement la promotion de l'évènement mais je profite de ce billet pour faire un petit rappel... ou appel c'est selon.

Chères "ressources", si l'on daigne vous offrir une journée pour assister à l'évènement, j'irai vous chercher moi-même à Lacanau si vous faites l'école buissonnière. Si vous devez sacrifier une journée de congé, faites-le. Il est de votre devoir en tant que professionnel d'assister à l'Agile Tour ce jeudi. Vous ne trouverez pas meilleur investissement pour soigner votre amélioration continue.

Chers managers, offrez une journée de congés à vos "collaborateurs", cela surpassera n'importe quelle formation poubelle dispensée, dans une salle d'hôtel, entre deux pauses viennoiseries. Si toutefois vous n'êtes pas des plus généreux en ces périodes de crise supposée, ne faites pas obstacle à l'Agile Tour. Vous seriez bien irresponsables d'empêcher un employé de s'améliorer à faible coût.

Notez que je n'accepterai aucune excuse à base de "j'ai un tournoi de fléchette prévu depuis 2 ans" ou "je participe au casting d'incroyable talent". Le 7 octobre n'est pas une alternative - c'est la journées où seront les professionnels.

Et si vous n'êtes pas tout à fait convaincus, sachez que Jean-Baptiste Dusseaut et moi-même, présenterons un retour d'expérience sur Arpinum. Cela se passe en salle Feedback de 16h50 à 17h50. Pour plus d'informations, consultez le planning.

Pensez à vous inscrire en cliquant ici. Merci par avance.

A jeudi!

La fin d'une époque

2010-06-25T21:09:00.006+02:00

DDD, XP, du carton et 20c tel aurait pu être le titre de ce billet pour résumer ces dernières années.

C'est avec une grande nostalgie que je lis nos début mais avec un certain amusement que je me remémore des péripéties. Et bien que ces derniers temps ce n'était plus pareil, je suis triste d'annoncer que mon projet s'achève.

J'ai conservé la dernière histoire. Elle n'est ni bien écrite ni intéressante par rapport à tout ce que nous avons accompli. Mais c'est la dernière. Il y a un an j'offrais un même bout de carton à mon binôme...

Cet après-midi j'ai donc fais un peu de nettoyage. Je me suis alors saisi des histoires et j'ai tout jeté. Faites et validées, elles n'ont plus d'utilité.

Ce projet a fait partie de moi ces deux années. Il a rythmé ma vie et mon humeur. Et bien que j'ai souvent été poussé à mes limites je trouve que j'ai beaucoup de chance d'avoir participé à l'aventure.

Merci à vous Gaëtan, Marlène, Alexandre, Charlotte, Fabrice, Florian, Christophe, Jérôme et Xavier, pour votre bon travail. J'admire la patience dont vous avez fais preuve pour me supporter.

Merci à Laurence et Aurélie pour votre réactivité et vos nombreux feedbacks. Merci à ma direction pour m'avoir laissé mener la barque comme je le voulais.

Bilan plus complet il y aura mais définitivement pas ce soir.

Sculpture d'organisation

2010-06-22T00:11:00.008+02:00

Ce soir j'ai assisté à un atelier animé par Colin pour l'association Okiwi. Nous autres participants avons décrit différents systèmes et y avons défini les rôles principaux. La situation optimale était que nous étions nous mêmes acteurs des systèmes évoqués. Et si ces systèmes étaient défaillants ça n'en serait que plus amusant. Beck soit loué ce fut le cas.

Après avoir choisi un système, son acteur, guidé par Colin, a organisé l'espace pour accueillir une mise en situation. L'acteur a ensuite désigné les interprètes des rôles et leur a fait une brève description de leur place dans ce système.

Et... action! Le système démarra, la seule règle étant que tout devait se faire dans un mutisme complet. Pendant une demi-heure (le temps est à confirmer) les participants ont mimé une situation qui était très fidèle à la réalité, selon l'acteur positionné en observateur.

A chaque atelier je me demande quelle peut bien en être la conclusion. Selon la trame initiale nous avons des éléments de réponses :

Une personne qui intervient dans un système se met assez vite à reproduire les dysfonctionnements de ce système.

Alors certes, les comédiens d'un soir ont retranscrit un système défectueux avec beaucoup de pertinence et sans être guidé pendant leur jeu. Mais voir cette mise en situation était-elle bénéfique pour les autres participants que l'acteur - principal concerné?

De nombreuses questions me sont venues en tête mais j'ai besoin de prendre du recul sur cet atelier afin d'avoir un avis plus tranché. Je vais tout de même conclure sur une idée de Colin. Pourrait-on mettre en situation un système, de cette manière, pour y détecter les éventuels dysfonctionnements à priori?

Compte rendu : la Charte de Projet

2010-01-13T08:17:00.007+01:00

Il y a quelques heures s'est déroulée une conférence de Laurent Bossavit sur la Charte de Projet. Vous comprenez bien que je me devais d'assister à une présentation de quelqu'un se définissant comme un Extreme Programmer de la 1ère heure.

L'avant
Les ouvrages sur les approches agiles, que ce soit sur SCRUM pour les frileux ou Extreme Programming pour les plus hardis, nous expliquent comment peut fonctionner le déroulement du projet. Nous sommes donc bien armés lorsqu'il s'agit du "pendant". Mais comment pourrait se dérouler l'avant projet dans un contexte agile?

Le coup d'après
Laurent Bossavit a commencé par comparer notre métier avec le billard et si je ne devais retenir qu'une analogie ce serait la suivante. Au billard, nous ne nous efforçons pas seulement de réaliser un bon coup, nous faisons aussi en sorte de nous positionner pour le suivant. Il en est de même pour nous autres agilistes. Nous ne livrons pas du code de piètre qualité suffisant pour répondre au besoin actuel. Nous préférons produire du code de qualité qui fonctionne et qui permettra aussi de faciliter sa maintenance et son évolution. Laurent Bossavit définit ainsi quelques propriétés d'un projet dit "agile" : nous y prévoyons le coup d'après et nous maintenons une qualité élevée. Il précise aussi qu'il faut bien évaluer le gain d'un tel projet. Commencer un projet qui n'a pas lieu d'être est un échec assuré. Les technologies ou les méthodologies ont un impact minime sur le succès d'un projet par rapport à sa légitimité.

La charte
Comment gérons-nous l'avant projet? Nos vieux réflexes peuvent nous pousser à établir un cahier des charges. Malheureusement ce n'est foncièrement pas agile : un tel document n'est pas exhaustif, ne répond au mieux qu'aux besoins actuels et malgré tout fait office de contrat. Un réflexe plus intéressant est de définir des histoires utilisateurs mais quand bien même nous nous limiterions à un thème ou à la prochaine version majeure, il y aurait pléthore de post-its à gérer.

Durant cette phase, nous avons besoin d'un document léger et capable de définir en quelques mots ce que l'on va faire. Laurent Bossavit insiste sur ce point : nous n'avons pour seul mérite d'avoir atteint des objectifs préalablement définis. Il serait bien facile de constater le résultat d'un projet et de feindre que tout s'est déroulé selon le plan. Mais est-il réellement possible de définir de façon concise mais exhaustive ce que l'on veut réaliser? La réponse est positive car selon l'orateur, le quoi s'exprime en beaucoup moins de mots que le comment. Tout ceci est appuyé par Kennedy lui-même :

[...] avant la fin de cette décennie, un homme posera le pied sur la Lune et retournera sur Terre en toute sécurité. [Kennedy 61]

Le document, dont le format importe peu mais qui se limite à une page maximum, est matérialisé par la Charte de Projet. Celle-ci comporte la mission, les objectifs, le périmètre, les ressources et les décideurs.

Une histoire de réalités
Selon Weinberg, et appuyé par Laurent, un problème n'est qu'une différence entre une réalité perçue et une réalité souhaitée. Nos réflexes nous poussent à avoir une démarche de solution quand nous tentons de traiter un problème. Nous répondons ainsi à la réalité souhaitée alors que si nous avions analysé le problème nous aurions pu agir plus simplement sur le côté perception. Etablir un document comme la charte peut faciliter la réflexion nécessaire en amont d'un projet.

Une technologie parfaite
Laurent Bossavit nous a décrit quelques outils pour mener à bien cette réflexion et je présenterai celui qui m'a le plus marqué : le mythe de la technologie parfaite. Cet outil va nous permettre de faire la différence entre attente et solution. Il n'est pas rare de trouver la mention suivante dans un cahier des charges : "le temps de réponse doit être inférieur à 2s". Il s'agit clairement d'une solution, le besoin réel n'est pas exprimé. Si nous utilisons la technologie parfaite, le temps de réponse est immédiat et donc une telle mention est inutile. Nous devons donc exprimer tout ce qui pourrait se dire en considérant une technologie parfaite.

Le zoo humain
Laurent a aussi précisé qu'il était important de comprendre les écarts entre les réalités perçues et souhaitées. Pour cela il faut être au plus prés des acteurs impliqués dans un projet. L'orateur va même jusqu'à bannir le terme utilisateur qu'il juge trop abstrait. Laurent apporte quelques solutions comme les persona qui permettent de représenter un acteur. Il s'agit d'une fiche comportant un nom, une photo et la description d'une personne factice ou non. Tout ceci est bien moins impersonnel qu'un dessin en forme de bâton sur un cas d'utilisation. Laurent Bossavit va plus loin en nous proposant de passer une journée dans la vie d'un acteur. Cette petite session de "Vis ma vie" permettra ainsi d'appréhender au mieux le contexte dans lequel évolue notre acteur.

Parlons du cash
En amont d'un projet il est aussi nécessaire de définir le modèle économique. Fonctionnons-nous avec un modèle par utilisateur ou financé par la publicité pour ne citer qu'eux. Combien d'argent allons-nous gagner? Combien tout ceci va nous couter, à maintenir comme à exploiter? Au final il faudra du concret : des chiffres. Les managers et l'équipe projet vont ainsi parler le même langage.

Laissez-moi mes ressources!
Laurent a insisté sur le fait qu'il fallait obtenir un accord sur les ressources. Il n'y a rien de plus démotivant qu'après s'être engagé dans un projet, un élément extérieur vienne perturber les fondations de cet engagement en modifiant les ressources. Vous as-ton déjà supprimé ou ajouté des développeurs en plein milieu d'une itération? Je lève la main en ce moment... Les ressources comprennent aussi l'accès aux décideurs, l'environnement de travail ainsi que les formations. J'ai cité le mot : décideurs. Ils ont une importance capitale. Il est important de connaitre ceux qui vont valider votre travail ou qui peuvent décider de continuer comme d'arrêter le projet.

Il y aurait beaucoup à dire sur le sujet et je vous mettrai un lien vers la vidéo dès sa parution. J'ai fortement apprécié l'intervention de Laurent Bossavit : son discours était des plus intéressant et son élocution exemplaire. Un grand merci au JUG de Bordeaux ainsi qu'à Okiwi pour avoir organisé tout ceci. Mention spéciale pour la taverne et son jarret frites... mais je n'en dis pas plus...

Vidéos Agile Tour Bordeaux 2009

2009-11-13T19:32:00.005+01:00

Jb me devance et nous informe que les vidéos de l'Agile Tour Bordeaux sont disponibles ici.

Je vous conseille de regarder la session TDD animée par mes confrères Jean-Baptiste et Charles. Ils exécutent sans faille le Kata du Bowling. Et Dieu sait à quel point je suis encore plus exigent avec mes proches.

N'hésitez pas à consulter le retour d'expérience de SC2X que nous a fait Rachel Dubois ainsi que Mickael Gasrel. Un retour assez mitigé sur l'adoption d'une approche Agile.

Pour finir, je vous suggère de vous passer en boucle la présentation d'Extreme Programming. Sa qualité n'a d'égal que la taille de mon ego. Je ne fais absolument pas de prosélytisme, le fait que je sois l'acteur de cette session n'est qu'une incidence.

Un grand merci aux cameramen, time boxers ainsi qu'aux monteurs pour leur excellent travail.

Bon visionnage quant à vous!

Gojira à Bergerac

2009-11-08T18:37:00.004+01:00

Au milieu de toute cette actualité agile, je fais une brève parenthèse musicale.

Ce week-end j'étais dans la petite bourgade de Bergerac. Mais pourquoi se perdre là-bas, me demanderez-vous? Je ne vois que deux raisons valables, siroter un cocktail au Sherwood ou assister au concert de Gojira. Comme je n'ai pas pour habitude de faire des concessions je me suis adonné à ces deux activités!

J'ai donc plongé, le temps d'une soirée, en immersion parmi tous ces métaleux amateurs de gros son. Il y avait la faune habituelle : du vieux rocker avec son T-shirt de Motorhead, en passant par le gothique à la tenue dantesque, jusqu'à l'émo en quête d'identité. Je ne manquerais pas non plus de citer ce magnifique punk en treillis qui s'est approché de la scène en hurlant un magistral : "Envoie le bois enculé!!!!". Je remercie cet homme qui a crée sans le vouloir un running gag dont on s'est gargarisé toute la soirée.

En première partie figurait, Eths, un groupe Marseillais, que je ne connaissais pas et j'avoue avoir été agréablement surpris. Pendant quelques morceaux, Candice a littéralement contrôlé la foule avec son déhanché de diablesse, le tout appuyé par un éclairage des plus opportuns.

Puis est arrivé Gojira. Bien que je n'aime pas particulièrement ce groupe j'ai dû reconnaitre que leur concert était tout simplement excellent. La salle était bien remplie pour un concert de métal situé à Bergerac. Le son était gros, une partie de la foule pogotait, l'autre tentait de danser sur le rythme improbable des Landais. Au milieu de tout ça, je me suis souvenu à quel point j'aimais le métal.

Envoie le bois!

Le repos de l'agiliste - suite et fin

2009-11-02T20:38:00.003+01:00

Les souvenirs de cette journée commencent à s'estomper mais je vais synthétiser les moment clé. Ce que je retiens c'est qu'il y avait du monde et que l'espace était très réduit. J'ai beaucoup papillonné d'un groupe de personnes à l'autre afin d'extorquer quelques feedbacks et de conseiller mes amis sur les sessions à suivre. Les gens étaient très satisfaits bien que frustrés, parfois, de ne pas pouvoir assister à des sessions comme TDD.

Remue-méninge
Après la présentation XP j'ai rejoins l'atelier de Pascal Grange sans avoir aucune idée de l'ovni qu'il allait piloter. J'avais entendu le mot amélioration dans un vague brouhaha et la pièce m'avait paru assez douillette pour que j'y fasse un somme d'une petite heure. Par malchance l'atelier a commencé par une séance de speed networking. Nous sommes sortis dans le hall afin de faire connaissance avec une autre personne pendant 3 minutes. C'était très important nous informait l'animateur et nous nous exécutâmes donc avec beaucoup d'application.

De retour dans la salle, le jeu débuta. Les participants ont reçu un lot de feuilles contenant deux images qu'ils devaient retourner, une à une, au début de chaque phase du jeu. L'objectif était simple : trouver les différences le tout sous le joug d'un chronomètre des plus stressant. Il est bon de noter que les images étaient de complexité très différentes. A la fin de la 1ère phase, les agilistes devaient rationaliser leur méthode de détection et l'appliquer pendant la seconde phase. Autour du jeu, un manager notait les différents scores et après la seconde phase il ordonna à l'assemblée de suivre la méthode du détecteur ayant obtenu le chiffre le plus élevé. Les joueurs s'exécutèrent non sans à priori concernant la méthode.

A la fin du jeu, les participants s'insurgeaient, pourquoi le manager faisait-il appliquer une approche basée sur les résultats bruts d'une seule personne dans un contexte très spécifique? Ceci a fonctionné sur un dessin basique et certaines personnes avaient bien du mal à l'appliquer sur une photo. Par ailleurs les indicateurs étaient-ils fiables? Après tout on ne connaissait pas le nombre total de différences sur l'image du grand gagnant.

Et pouf... la session s'acheva sur une simple question : comment réagirions-nous si une telle méthode était imposée dans notre organisation? Dans la foulée nous avons quitté la salle. Point de conclusion pré-mâchée, nous devions nous forger la notre. Notez que plus tard dans la journée, Pascal m'a détaillé un peu plus sa thèse, avec la meilleure volonté du monde je n'aurai pas atteint sa conclusion. Imaginez un puzzle dans lequel il n'y aurait aucun contour - ce n'est pas évident de commencer. Tout ceci fera l'objet d'un futur billet. Il m'a aussi avoué que le speed networking était une escroquerie, qu'il n'avait servi qu'à réveiller l'auditoire.

Ouch...

XP Scrum, salade tomate oignon
J'y étais mes chers amis! J'y étais! En fin de journée j'ai assisté à la conférence incroyable de Jean-Pierre Vickoff! Je suis bien incapable de résumer ce que j'ai vécu pendant cette heure. C'était une rencontre du 5ème ou 6ème type, à ce niveau - il faut que je consulte l'ASE. Je suis sorti de l'amphithéâtre un peu béa et il a fallu qu'on me mette une grande gifle pour que je recouvre mes esprits.

Je retiens tout de même l'une des meilleures entrées en matière et un flot de parole inégalé. Il y avait aussi des blagues très déplacées mais pas moins savoureuses sur les faits divers chez FT et des diapos hors du commun. Quand je dis diapo c'est un bien petit mot pour décrire ce qu'il nous a projeté. Je pense que les termes "berceau de la vie" ou "Canis Majoris" correspondraient mieux. C'était du lourd mes amis! Suivant les conseils de Guillaume Saint Etienne, notre orateur nous a concocté une diapo comportant l'ensemble des pratiques Scrum+XP sur la droite, la super roue PUMA@Vickoff au centre (et ça tourne et ça tourne), le Da Vinci Code vers la gauche et la constellation des Gémeaux englobant le tout. Du lourd!

La forme était très particulière mais plaisante, j'en garde un bon souvenir. Sur le fond je reste un peu mitigé mais je note beaucoup de bon sens dans son texte. Je retournerai volontiers assister à une conférence de ce grand homme qu'est Jean-Pierre Vickoff.

Conclusion
Cet Agile Tour me laisse un excellent souvenir. J'ai eu de bons retours sur les sessions et l'organisation. Il y avait du monde, des boissons chaudes comme fraiches, des viennoiseries et des petits fours. Que demande le peuple? Un grand merci à vous public. Un merci tout aussi grand à Colin et sa patience légendaire, Frédéric et ses conseils avisés, Samir et sa bonne humeur, Julie et son activisme, Charles parce que c'est Charles, Mickaël et ses talents audiovisuels et finalement JB parce qu'il faut bien quelqu'un pour finir les pizzas.

Le repos de l'agiliste

2009-11-01T21:14:00.005+01:00

Fiou! L'Agile Tour Bordeaux est terminé, l'agiliste que je suis va pouvoir se reposer. Finis les lundis soir consacrés à boire de la bière et manger des pizzas autour d'un backlog qui ne se vide jamais. Terminés les week-ends passés à réviser la série XP entre deux vidéos d'oncle Bob.

Vous me manquerez chers organisateurs! Bien heureusement notre consanguinité est telle que je suis amené à croiser la moitié de l'organisation plusieurs fois par semaines... mais chut!

Le jeudi saint
Jeudi 29 octobre 2009. Il est 6h45 et le réveil sonne. Je soulève une paupière "X", puis une deuxième "P". Mon Dieu! C'est le jour J! Et là tout s'enchaine, petit déj, le chat, la douche, ma sacoche avec le portable et un kit de survie : une compote. J'arrive sur les lieux à 8h05, avec un léger retard, fâcheux défaut dont je ne me déferai jamais. Au LaBRI tout le monde s'agite, les salles se réorganisent, se flèchent et s'équipent, les badges s'étalent et les brassard se mettent. Tout le gratin est là : les organisateurs, les étudiants et père Bézagu en renfort.

Le temps passe vite, il y a de plus en plus de monde. Je salue quelques amis et échange des mots dont je n'ai plus aucun souvenir. Mon esprit est ailleurs, en communion avec Beck il me semble. Mais que se cache t-il derrière la slide 93? Comment pourrais-je bien justifier le travail en binôme? Ouf! C'est l'heure de la plénière d'ouverture, ça va me changer les idées. Il y a beaucoup de monde, cet évènement n'est donc pas un pétard mouillé. Je suis rassuré, j'ai bien fait de demander autant de goodies et de militer pour une présentation ma société.

Extrémisme
La session s'achève, il est 10h. Ma présentation commence dans 20 minutes, je suis plus que large. Je me saisie d'une compote et flâne quelque peu dans le hall. Je ne sais plus qui je croise mais cet obscure personnage m'informe que la salle simplicité est déjà pleine. WTF! Compote en main je me dirige vers le champ de bataille pour apprécier la situation par moi-même. C'était donc vrai... Je finis ma compote et pose tranquillement la cuillère sur la table. Je n'ose pas regarder l'auditoire. Bon je regarde mais très rapidement... oulalala, mes amis sont tous là et positionnés vers la droite. En face de moi et au fond de la salle se trouve père Bézagu. Un rang devant et en plein dans mon champ de vision est assise la délégation de ma société. Ça n'arrange pas mes affaires, je ne saurai pas qui regarder pendant la présentation. Ah si j'ai trouvé, près de moi se trouvent deux femmes, la charmante Rachel Dubois et quelqu'un à qui je n'ai pas eu le plaisir d'être présenté.

Une minute s'écoule, Colin s'approche et me demande s'il ne serait pas judicieux de commencer, même en avance. J'aurais bien du mal à retranscrire, ici, toute la courtoisie dont il fait toujours preuve. Bien.

Tout le monde est près? Bonjour à tous, je suis Michael Borde et je vais vous présenter Extreme Programming.

Je parle, je bouge, j'explique, je me moque, je fais la morale et finalement je tourne la 104ème diapo : les questions! C'est passé tellement vite!

Je suis assez satisfait de ma présentation. J'ai fais deux erreurs d'enchainement de slide dont une que j'ai masqué assez vite dans un écran de fumée. Je n'ai pas fait d'accrochage majeur si ce n'est un bref passage où je dis que personne n'implémente intégralement Extreme Programming. Le "personne" était un peu extrême d'autant plus que j'avais clairement dis que le développement de Tiron embrassait pleinement XP. J'ai donc rajouté un "sauf moi" et tout de suite après, dans ma tête : "mais quel connard de prétentieux je suis!". Oui, il est facile de déraper en public, mais on ne m'en a pas tenu rigueur.

La séance de questions fut très intéressante et j'avoue avoir été mis en défaut par la 1ère. Une personne m'a demandé s'il fallait doubler toutes les compétences à cause du travail en binôme. En creusant un peu, il me demanda comment faire cohabiter un graphiste avec un développeur. Je n'ai jamais travaillé avec une telle personne, je ne pense pas en avoir côtoyé une d'ailleurs. Face à mon ignorance j'ai appliqué le principe de précaution et j'ai déclaré que cette association était peut-être une exception. Immédiatement après Rachel Dubois à contrebalancé mes propos en faisant part d'un retour d'expérience sur le sujet et validant ainsi l'association développeur/graphiste. Je ne me suis pas attardé sur le sujet et quoiqu'il en soit il aurait été difficile de lutter contre ce retour d'expérience. Dans les jours à venir, j'écrirai un billet sur ce type de binômage pour nuancer tout ceci.

Ensuite j'ai eu une question des plus classiques mais pas moins légitime : en début de projet qu'est-ce qui motive le choix de telle ou telle approche? Pourquoi Scrum, pourquoi XP? Y'a t'il une méthode plus adaptée selon un contexte? Je n'ai pas sombré dans la guerre de clocher Scrum/XP, j'ai simplement répondu qu'il n'y avait pas de silver bullet, qu'on utilisait ce qu'on connaissait ou ce qui était en vigueur, au niveau agilité, dans son organisation.

Il y eu bien d'autres questions mais vous pourrez observer ça dans la vidéos qui sera disponible dans quelques temps. Je publierai mes slides par la même occasion.

L'après XP fut beaucoup plus zen et sera décrit dans un prochain billet :)

Agile Tour Bordeaux : J-1

2009-10-28T08:48:00.004+01:00

Demain aura lieu une étape de l'Agile Tour 2009 à Talence près de Bordeaux. Pour les retardataires, toutes les informations sont disponibles sur le site.

Je remercie d'avance les participants. Ces personnes qui croient en l'Agilité, qui lui donnent une chance et qui désirent se retrouver jeudi pour partager des valeurs communes. Merci à vous, chers professionnels, de consacrer une modeste journée à votre amélioration continue.

Agilistes, je vous retrouverai avec plaisir lors de ma présentation d'Extreme Programming, à 10h20 dans la salle simplicité.

A demain.

Agile Tour Toulouse

2009-10-22T22:10:00.007+02:00

Chers amis, ce matin une délégation spéciale de l'organisation bordelaise partait pour la ville rose afin d'espionner ses confrères de l'Agile Tour Toulouse.

Nous avons donc pris la route vers 6h15 par un temps plutôt frais et modérément sec. Les étoiles... non je m'égare... Deux heures et demie plus tard nous étions coincés sur la rocade de Toulouse - le café pris à la station service nous a été très préjudiciable au niveau timing. A l'aide de trois iPhones nous avons réussi à trouver l'IUT ; le havre de l'agile tour. Une fois garés sur une place plus ou moins légale nous sommes entrés dans le hall et avons récupéré nos badges ainsi que les fameux sacs de goodies. Nous avons manqué le discours d'ouverture et la première session venait tout juste de commencer. C'est donc avec un peu de précipitation que nous primes un café, mangeâmes des viennoiseries, fîment un cluedo, et fonçâmes dans le grand amphithéâtre. Après tout ce passé simple inutile de vous dire que nous étions repus.

La première session animée par Jean-Marie Damas nous présentait les promesses de l'agilité et les difficultés sous-jacentes. C'était assez général mais convenait parfaitement pour un public large.

Ensuite j'ai assisté à mon coup de cœur de la journée avec l'agilité sous contraintes. Dans cette session David Brocard nous expliquait les difficultés pour adopter une démarche agile dans une organisation aux mœurs traditionnelles. En somme, comment placer un projet agile par rapport aux autres, quels sont les changements au niveaux des rôles ainsi que des outils. Ce n'était que du bon sens mais faisait office d'excellente piqure de rappel (ou d'appel).

Une pause et quelques viennoiseries consommées je suis retourné dans le grand amphithéâtre où Guillaume Saint Etienne mixait agilité et SSII sous fond d'images originales et diapositives très dynamiques. L'ensemble m'a bien plu, l'orateur était bon et le discours cohérent. Le passage sur le Green-IT et le fait qu'une amélioration de la qualité pouvait s'inscrire dans une démarche écologique était peut-être de trop.

Après un consensus général (hihi), la fine équipe décida de manger au restaurant universitaire. C'était à deux pas de l'IUT et nous a permis de ne pas perdre de temps. Le site de l'agile tour était vraiment bien placé. Après un repas équilibré composé d'une salade de tomates et fêta, d'une crêpe au jambon ainsi que des frites et finalement une crème brulée nous sommes retournés dans hall en vue d'une session pour digérer.

J'ai assisté à la présentation de Claude Aubry sur les estimations, indicateurs et métriques agiles. C'était globalement intéressant et j'ai remarqué quelques diagrammes à bonnes valeurs informatives. A expérimenter donc...

Ensuite j'ai subi une session sur l'estimation autour d'un projet agile. La première partie traitait du planning poker et j'ai bien aimé voir l'orateur estimer des citrouilles pour préparer Halloween. J'ai eu beaucoup plus de mal avec la seconde partie sur la méthode Use Case Point que j'avais déjà vu à l'œuvre. Je m'attendais à autre chose qu'une présentation sur une méthode permettant de chiffrer (le mot est dit) des Réponses à Appel d'Offre. Je suis bien placé pour savoir que les RAO sont une réalité dans les SSII mais je ne comptais pas voir ressurgir un concept aussi biaisé lors de l'Agile Tour. Ce n'était définitivement pas Feng Shui.

Pour rouvrir mes chakras je me suis vengé sur les petits fours pendant la pause. Un jus d'orange plus tard je retournais dans l'amphi pour assister à la dernière session. Il s'agissait d'un retour sur expérience de l'enseignement de l'agilité par Jean-Michel Inglebert. Le professeur nous expliquait que les étudiants, dès les premières années, étaient confrontés à certaines pratiques d'ingénierie sans même savoir qu'elles étaient de natures agiles. Au fur à mesure de la formation, les élèves acquéraient une sorte de culture agile. Toutefois ces étudiants étaient trop jeunes pour comprendre certaines problématiques soulevées par les approches modernes comme le changement systématique des besoins ou encore les principes sous-jacents à TDD. Je suis assez d'accord avec la réflexion qu'à menée l'auteur. J'ai juste trouvé que c'était bien un plaisir sadique aux professeurs de forcer les élèves à faire des tests unitaires web en perl... :)

Après la session de clôture nous avons eu droit à une petite surprise de la part de nos organisateurs : un bel apéro nous attendait dans le hall. Ce fut donc par pure politesse que nous prîmes cacahuètes et muscat. A 19h nous avons quitté les lieux, la tête encore pleine d'agilité.

J'ai beaucoup apprécié cette journée que ce soit au niveau organisation comme au niveau du contenu des sessions. J'espère que l'évènement bordelais se passera dans d'aussi bonnes conditions. Quoiqu'il en soit, dans J-7 nous serons fixés!

Extreme Packaging

2009-10-18T20:38:00.011+02:00

L'enjeu

Vendredi soir les organisateurs de l'Agile Tour Bordeaux se réunissaient pour une session extraordinaire : il fallait remplir les sacs offerts aux participants de tous les goodies que nous avions reçus. Les 200 sacs se sont vus recevoir diverses plaquettes des sponsors, stylos, bonbons et autres plannings des sessions.

Avant de s'atteler à la tâche, les 6 agilistes que nous étions définirent le modus operandi de la première itération. Nous avions besoin de rigueur pour constituer des sacs de qualité ; imaginez un instant si une poche contenait une double ration de bonbons!

Itération 1 : la chaîne

Hormis Colin qui était sceptique nous étions d'accord pour tester l'idée de la chaîne.

Voici un schéma de notre processus :

Cliquez pour plus de lisibilité.

Tout commençait par Charles qui devait sortir un sac du carton pour me le donner. J'avais pour seule mission d'y placer un autocollant ainsi qu'une plaquette. Je le posais à côté de Colin qui le prenait pour y mettre une plaquette ainsi qu'une boite de bonbons. Colin posait le sac prés de JB qui le remplissait d'une plaquette ainsi que d'un planning. Ensuite JB le donnait à Mickaël qui le grossissait d'un stylo (il se peut que j'ai oublié un goodies). Pour finir, Julie prenait le sac et le plaçait dans un carton en prenant soin d'accrocher les anses intelligemment pour faciliter leur extraction.
Charles joua le rôle du tracker et énonça les terribles "plus que 195", "plus que 190"... La chaîne était désespérément lente nous n'allions pas tenir les délais. Nous avions des contraintes, je devais rentrer tôt et nous avions tous très faim :) Nous avons donc mis fin prématurément à l'itération pour tenter d'améliorer le processus.

Itération 2 : présenter les sacs

Ce qui nous ralentissait était le fait que nous posions le sac à chaque fois. Le sac étant souple il fallait quelques secondes pour le démêler et l'ouvrir. Colin et Charles décidèrent que nous devions présenter le sac à l'agiliste qui suivait dans la chaîne pour qu'il y place ses goodies. Cette personne devait ensuite attraper le sac par les anses et faire de même avec son voisin. Cette technique était bonne, nous avons gagné en productivité. Mais ne ne pouvions pas nous satisfaire d'une seule optimisation il fallait encore s'améliorer.

Itération 3 : l'abandon de la chaîne

Notre tracker nous fis remarquer, pendant le bilan de mi-itération, que les sacs changeaient trop souvent de mains. C'est ainsi que nous avons adopté l'idée initiale de Colin : ce dernier tiendrait le sac ouvert et tout le monde devrait y jeter ses goodies. Nous nous exécutâmes et grâce à cette optimisation notre vélocité atteignit des sommets. Par ailleurs un élément extérieur nous ajouta une pression supplémentaire : le four préchauffait et il faudrait s'interrompre pour y positionner les crêpes au fromage.

Itération 4 : la qualité d'abord

Julie, consommatrice finale du sac détecta une baisse flagrante de qualité. Dans notre précipitation les goodies ainsi jetés au fond du sac prenaient plus de place que nécessaire. Nous avions des contraintes de volumétrie, il fallait pouvoir entreposer ces 200 sacs dans 3 ou 4 cartons! Julie nous conseilla de bien placer les goodies sous forme de feuille pour éviter les plis et prendre le minimum de place. Une touche finale fut donc apportée à notre processus. Nous prenions la plaquette la plus grande et nous y placions toutes les autres dessus, Colin avait pour mission de mettre tout ce petit monde dans le sac. Les goodies de formes cylindriques pouvaient ensuite y être jetés.

Bilan

Nous sommes partis du processus le plus simple qui pouvait fonctionner : celui de la chaîne. Cette chaîne sollicitait l'ensemble des intervenants, semblait naturelle et surtout évitait que nous nous gênions dans un espace réduit. Après tout ça fonctionne dans d'autres situations comme un déménagement ou des travaux. La proximité que nous avions nous a permis d'abandonner la chaîne pour une solution comportant moins de mouvements inutiles. A chaque itération nous avons appris de nos erreurs et nous avons amélioré par petits incréments notre processus.

Le bilan final est qu'après cette soirée, nous avons atteint un tel niveau dans l'industrialisation de notre packaging que nous songeons à construire un business model autour de tout ça.

Extreme Presenting

2009-10-04T10:58:00.004+02:00

Le 29 octobre je présente Extreme Programming à l'Agile Tour organisée pour la première année à Bordeaux. Je reviendrai sur l'évènement dans un prochain billet ou dans une prochaine vie... celle-ci me semblant déjà bien remplie :)

Je désire vous faire partager le making-of de cette présentation avec une photo de piètre qualité. Jugez par vous même :

En tant qu'Extreme Programmer je suis les conseils de Beck et j'apporte un soin tout particulier à mon environnement de travail. Ainsi je dispose d'un Typematrix et d'une souris Microsoft Habu reposant sur le célèbre Func 1030. Mon bureau propose des vivres à portée de main, en témoigne la banane, la barre de céréales ainsi que le café.

Oui bon j'admets, ce matin ma machine de guerre a rendu l'âme probablement à cause d'une tentative d'installation de MacOS infructueuse il y a quelques mois. Je n'ai pas trouvé de cause plus probable, le matériel informatique est fiable de nature et ma partition Windows XP n'a connu que 3 configurations radicalement différentes ces dernières années.

Alors depuis ce matin je travaille sur une table Ikéa avec une chaise aussi inconfortable qu'un strapontin dans un TGV. Comble de tout j'ai dû céder mon 22" pour l'écran 9" d'un EeePC...

Je ne me plains pas, j'aime travailler dans des conditions extrêmes, ça me rappelle le Vietnam (ou Battlefield Vietnam, j'en ai fais un des deux).

Changement de cap

2009-08-17T22:27:00.007+02:00

Mes amis, il m'arrive une micro-tragédie et elle risque d'être longue à conter à cause de mon TypeMatrix.

Jadis j'étais aux commandes du célèbre Poséidon, ce magnifique paquebot parti en mer il y a presque un an déjà. Le voyage fut des plus long et épuisant mais après une traversée semée d'embuches nous sommes arrivés non loin "d'un" bon port.

Un à un j'ai dû me séparer de mes matelots. Certains départs furent plus difficiles que d'autres mais en ma qualité de pirate je me devais d'en témoigner une parfaite indifférence. Une indifférence couplée à une sincère courtoisie tout de même.

Après deux semaines de débauche passées à dépenser une généreuse partie de ma solde en rhum, femmes et jeux divers sur Tortuga j'ai repris mon service. Il était temps au navire de rejoindre son port d'ancrage. J'ai donc saisi la barre pour un dernier voyage sur une mer désespérément calme mais reposante.

J'ai balayé le pont du regard. Le constat était aussi prévisible que percutant : j'étais seul. Seul sur mon nouvellement rebaptisé vaisseau fantôme. Ainsi, à dix heures je n'ai entendu aucun sachet de biscuit s'ouvrir, n'ai reçu aucune invitation à partager un thé brulant. Pas l'ombre d'une blague de mauvais gout n'a été échappée et de ce fait aucun rire forcé non plus. Il en fut de même pour le, désormais sans saveur, gouter.

Je me remémorais ces matinées encore embrumée du travail de la veille où nous tentions avec mon second de déchiffrer la carte. Les indications y étaient floues, la mer jouait avec notre patience et l'équipage pouvait embrasser la mutinerie à tout moment. Et bien que parfois nous avons laissé exploser notre colère (chose que je regrette quand dirigée contre nous), nous méritons amplement le prix "Valium" de la maitrise de soi et du bon sang froid.

Il est si facile d'adopter de simples habitudes que même une coupure brutale comme des vacances ne saurait atténuer. Ces flibustiers que je savais mercenaires d'une traversée me manqueront. Mais comme on dit dans la piraterie : à chaque voyage son équipage!

TDD au Bordeaux JUG : le bilan

2009-05-15T18:40:00.008+02:00

Il y a deux jours père Bézagu est tombé sur une news annonçant une présentation de Test Driven Development au Bordeaux JUG organisé à l'Enseirb. TDD est une pratique que j'utilise au quotidien et que je trouve primordiale. Je ne pouvais pas manquer cette réunion. Ainsi je m'y suis rendu avec deux collègues Agilistes convaincus. En parlant de ça je m'aperçois que JB a déjà pondu un billet.

L'orateur était un chef de projet qui a découvert TDD il y a quelques mois parce que c'était une exigence de son client. Ce dernier désirait un grand taux de couverture et imposait la pratique. Bon évidemment il y a mieux pour découvrir un concept aussi fondamental que d'y être contraint. Mais passons. Cet individu a eu le courage de diffuser sa trouvaille et c'est le principal.

La présentation était un retour d'expérience sur TDD mais avec le plan utilisé le bilan a véhiculé un sentiment assez négatif sur la pratique. J'ai notamment crié objection quand j'ai entendu des énormités comme :
- "les tests entrainent un surcout"
- "il faut avoir un client vachement mature pour accepter de payer pour des tests"
- "on est payé pour réaliser et les bugs sont du ressort de la maintenance"
- "parfois le client ne s'aperçoit même pas des bugs"

Alors en effet il est plus couteux sur du très court terme de faire un test unitaire mais sur le moyen et long terme, le gain de qualité indéniable se traduira nécessairement en gain de productivité. TDD permet d'écrire du code propre qui fonctionne. Il est faux de penser qu'il n'y a que pendant la maintenance qu'on traite les bugs. Combien de temps passez-vous à utiliser le débugger si vous ne testez pas de façon unitaire et automatique? Avez-vous des sueurs froides quand vous remanier un bout de code? Nous non.

Ensuite, le client ne paye pas les tests mais du code qui fonctionne. C'est une escroquerie de vendre une réalisation bancale avec l'espoir qu'il passe la validation/recette. Avec ce genre de pensées minables le développement ne sera jamais considéré à sa juste valeur.

Mais de toute façon, est-ce bien important de répondre à des trolls de cette espèce? Le client est habitué à avoir une application qui ne fonctionne pas et qui ne répond qu'au quart de ses besoins vieux de dix ans. Pourquoi faire mieux?

Alors certes, l'ami extrémiste à ma droite et moi même nous sommes un peu enflammés hier soir mais nous avons vite été coupés dans notre élan et finalement personne n'a pu réagir à la présentation. Aucun débat, aucune question, il fallait enchainer vers la suivante traitant d'un sujet bien moins important*. Tout ceci fut un échec et je suis maintenant très satisfait que le nom de Kent Beck ou du livre TDD ne soient pas cités lors de cette supercherie.

* il est à noter que l'intervenant suivant a fait une présentation très pertinente et que ça a sauvé la soirée.

Binôme et proximité

2009-05-11T22:29:00.005+02:00

Le travail en binôme exige une grande proximité entre les développeurs. Il y a un excellent chapitre là dessus dans XP Explained où Beck évoque les problématiques liées à cette proximité. Nous retrouvons, entre autre, un exemple de binôme mixte dont l'individu masculin est légèrement collant. Je vous conseille de regarder par curiosité la photo, relativement anxiogène, qui illustre la situation : ça vaut son pesant de dosette Nespresso. Il évoque aussi le besoin de chaque personne d'avoir un espace personnel car il est toujours important de disposer son petit bazar sur un poste de travail bien à soi. D'ailleurs en ce moment je suis forcé d'accueillir le bazar que mon binôme a ramené avec lui mais il me corrompt de manière habile avec des barres de céréales...

Bon lisez ce bouquin que diable. Je peux vous montrer la porte, jouer avec la poignée tout au plus, mais c'est à vous de la franchir!

Je ne m'étendrai pas davantage sur la mixité du binôme ou les maniaqueries personnelles mais sur un sujet bien plus sérieux. Une personne de mon équipe dégage une odeur nauséabonde... et oui... Même si rien ne le laisse présager ça pourrait être un problème de santé mais j'espère pour cette personne qu'il s'agit plus d'un manque d'hygiène.

Jusqu'à présent je n'avais jamais rencontré ce genre de situation. J'ai bien lutté contre un parfum qui rentrait en conflit avec le mien, une combinaison café/clope ou encore une attaque de phéromones involontaire d'une de mes protégées mais tout ceci restait supportable.

Comment travailler de façon aussi fusionnelle qu'en paire avec ce genre de personne? Je dois avouer que j'en suis incapable et ça nuit à mon confrère. Je vais commettre le péché d'orgueil mais ne pas travailler avec moi sur le projet actuel c'est se priver de beaucoup de choses. Notez que la foudre s'abattra 5 ou 6 fois sur moi à cause de cette dernière phrase.

Alors qu'ai-je fais? Ai-je isolé mon mouton noir sous peine de ne pas le faire évoluer? Non, il me reste la notice d'utilisation de la conscience que j'ai jetée il y a quelques mois. J'impose tout simplement cette personne aux autres et ils ne peuvent que subir - subir sa seule présence. Comme un manque d'hygiène n'est pas souhaitable avec nos méthodes de travail et puisque je manque d'une certaine légitimité, j'ai discuté de ce problème avec mon chef de projet. Lourde tâche pour lui que celle d'annoncer à un jeune développeur qu'il doit prendre une douche le matin...

Travail en binôme

2009-05-10T00:35:00.011+02:00

Parmi tous les concepts proposés par XP celui que j'affectionne le plus après TDD est le travail en binôme. Je resterai bref sur les bienfaits d'une telle pratique mais je ne manquerai pas de rappeler que cela permet, entre autre, de partager les connaissances, obtenir une revue de code permanente et exiger le meilleur de chaque participant.

J'ai rencontré toute sorte de binôme et je vous fais partager les 3 rôles évidents que j'ai retenu :

- le mentor : ce binôme est une mine d'or pour peu que vous voulez progresser. Il a assez de connaissance pour vous noyer mais dispose d'assez de pédagogie pour vous faire évoluer. Le bénéfice mutuel est bien présent car d'une part le mentor aime sa position de mentor et d'autre part, enseigner est une excellente façon de perfectionner son art. Mélanger deux mentors est parfois contre productif : s'ils se lancent dans des débats "métaphysiques" sans fin les développements restent figés.

- l'élève : un binôme avec lequel il va être très amusant de travailler. En général c'est lui qui prend le clavier et votre rôle à vous consiste à le laisser tomber dans tous les panneaux. Avec l'élève il faudra rester très zen, en général il tape moins vite (ça inclut les raccourcis clavier), le code est moins bon et, à cause de sa condition, fait moins de blagues douteuses. Il y a du bénéfice mutuel car l'élève bien souvent vous fera douter par ses questions de plus en plus précises et sera très exigent envers vous. Vous l'avez compris, l'élève s'épanouit pleinement avec le mentor mais quant est-il avec un autre élève? Je répondrai en proposant une expérience simple. Disposez les élèves sur un poste de développement neutre et placez le clavier à équidistance d'eux. Maintenant il ne vous reste plus qu'à compter le nombre de formules de politesse qu'ils vont inventer pour éviter d'être celui qui code.

- le Doppelganger : ce binôme est votre exact miroir. Il a des connaissances équivalentes et code avec les mêmes convictions ou philosophie que vous. Votre duo est très véloce et vous mettrez de véritables claques aux histoires que vous prendrez. Travailler avec le double est un véritable bonheur. Vous vous connaissez tellement que vous vous amuserez à faire ressortir les défauts de l'autre. Avec un peu de recul vous vous apercevrez aussi que vous avez acquis certaines habitudes et que la séparation, bien que nécessaire, va être délicate. Mais la scission est l'occasion pour votre couple d'évoluer différemment et c'est lors des retrouvailles et de la resynchronisation du savoir que le bénéfice mutuel prendra tout son sens. Le seul point réellement négatif est que travailler avec son image est bien plus épuisant qu'avec un autre type de binôme.

Oh je n'ai fais que citer des évidences et j'ai usé d'un soupçon de mauvaise foi mais ce billet est une excellente introduction pour le prochain qui s'annonce bien moins réjouissant.

Une histoire de bateaux

2009-04-21T23:09:00.004+02:00

Ce midi je suis allé nager avec un ami récemment promu chef de projet. Nos seuls échanges, ces derniers temps, se sont résumés à quelques piques sur la santé de nos "fardeaux" respectifs. Hormis ce genre de courtoisies d'usage nous n'avons pas eu l'occasion de discuter mais depuis peu j'ai remarqué un certain changement dans son attitude. La plaisanterie, aussi cynique soit-elle, s'efface peu à peu au profit d'un savant mélange de colère et de lassitude.

En ce moment, mon ami tient la barre du Titanic et son principal soucis, mis à part l'absence de Kate Winslet, est qu'il donne toute son énergie pour éviter le premier iceberg menaçant. J'ai peur qu'à ce rythme il ne lui reste même plus assez de force pour écoper.

Mon Poséidon est certes moins luxueux mais il a le mérite de flotter à l'envers.

L'Agilité au féminin

2009-03-17T21:49:00.004+01:00

Au lancement du projet j'ai commandé du matériel de bureau pour constituer notre espace de travail informatif. Lorsque j'ai tout reçu j'ai vite déchanté ; c'était une très mauvaise idée de prendre des cartons blancs alors que le tableau derrière était tout aussi blanc... Oui, on retrouve encore une fois les limites des méthodes en cascade... (je m'en sors bien). Un après midi, mes collègues du sexe féminin ont profité de mon absence pour parfaire le mur des tâches.

A mon retour voici ce que j'ai découvert :

Le cycle de vie d'une tâche commence à gauche et se termine à droite. Naturellement mes collègues ont choisi de passer du rouge au vert, parce que "le vert c'est cool"©. Ingénieux.

Il y a quelques temps nous avons changé de plateau et j'ai du laisser mon tableau sur place. Il a donc fallu que je déménage mon mur des tâches. J'ai pris un tableau tout neuf et non encore fixé, j'ai tracé quelques traits et j'ai positionné les tâches à leur phase. J'ai pris le tableau et je l'ai porté jusqu'à notre nouveau plateau. Pendant ces vingts secondes, imaginez bien que je détenais entre mes mains l'intégralité de notre gestion de projet (blague).

Je ne me suis pas encore absenté et mon mur manque cruellement de déco. Je vous laisse seuls juges :

Notez que que nous avons été contraints d'ajouter une petite extension à notre mur, le résultat global est juste... laid. Ayez pitié du mur les filles!

Cristallisation de l'âme

2009-03-10T23:16:00.009+01:00

En ce moment mon âme tend à se cristalliser.

Que je m'impose une certaine rigueur est positif, par contre il est assez discutable que je sois aussi exigent avec les autres. Chaque jour j'ai l'impression de bafouer, un peu plus, le principe d'humanité pour respecter mes autres valeurs et principes.

Je pense m'être, à tort, auto-assigné un sacerdoce : veiller coûte que coûte à la santé du projet. Mais... il faudrait que je cesse d'être con, ça n'a jamais été mon rôle. Pourquoi devrais-je lutter avec des bases aussi fragiles? Mais surtout, de quel droit pourrais-je demander à l'équipe de pallier tous les manquements ou erreurs commises? Que le prochain qui me cite les mots "conscience" ou "professionnalisme" meurt écrasé par un millier de spécifications!

Alors je vais abandonner et commencer à baisser mes exigences...

et...

dans une lente agonie...

le dernier rempart de l'Agilité dans mon projet...

écrira avec son propre sang...

sur mon mur des tâches...

le plus majestueux des...

...ou pas!

Non, je ne lâcherai rien. Le rôle du connard me sied si bien, après tout...

Tumultes Agiles

2009-02-19T21:53:00.008+01:00

1er act

Nous travaillons actuellement sur un groupe de tâches dont le métier est des plus complexe. Comme nous n'avons pas trouvé de solution évidente pour répondre au besoin j'ai conseillé à un binôme d'appliquer TDD à la lettre. Ainsi, ils ont commencé par écrire un cas métier dans un test unitaire et ont développé le minimum requis pour repeindre NUnit en vert.

Le binôme a continué ainsi pendant quelques jours. Le rythme était simple : découverte d'un cas sur papier, résolution orale, test unitaire, résolution informatique. Comme la tâche était très importante je suivais de près la progression de mes petits protégés. Un soir j'ai confié à un autre développeur qu'il devait y avoir une faille dans notre façon de procéder, nous en étions à une quinzaine de cas, il devenait de plus en plus difficile de consolider la solution et bien d'autres situations métier allaient se présenter.

Le lendemain, j'ai profité de l'absence d'un membre du binôme pour participer pleinement à la tâche. Quand j'ai aperçu les 1500 lignes de tests unitaires j'avoue avoir regretté de m'être levé ce matin là. J'ai encore plus perdu la foi quand j'ai compris que tout ceci ne pouvait que croitre! La taille du domaine était inversement proportionnelle à celle des tests mais le code était brouillon et quelque chose sonnait faux. Tout ceci était bien trop technique et manquait cruellement de sens métier. Finalement nous avons ajouté une notion fonctionnelle qui a débloquée temporairement la situation. Cette petite généralisation nous a épargné de nombreux cas de tests mais je restais sur un sentiment d'insatisfaction.

Le bilan de la tâche était tout de même assez positif, nous pensions avoir fait le tour des situations possibles et nous étions dans les temps.

2ème act

La semaine dernière nous avons achevé une tâche similaire à celle décrite plus haut. Elle était au moins aussi compliquée mais comme les développeurs étaient bien montés en compétence sur le sujet, et il y a eu moins de frictions. Lundi matin, un développeur est venu me voir pour m'informer que nous n'avions pas géré un cas métier. J'ai pris un papier et j'ai dégainé mon stylo bic 4 couleurs que je ne sors que pour les situations critiques. En effet, notre solution était incomplète et le plus inquiétant est que d'une part, nous avions suivi les spécifications à la lettre et d'autre part, nous n'étions pas capables de résoudre le problème sur papier. J'ai immédiatement saisi le téléphone pour joindre mon client et trouver une solution avec lui. Malheureusement la situation que nous avions découverte n'était pas du tout couverte par les spécifications. S'en est suivi de nombreux échanges de mails, dessins scannés, dessins informatisés, coups de téléphone, durant 3 jours sans jamais avoir de solution claire.

A cause de cette sur-communication et de l'absence de résultat la tension est montée d'un cran au 3ème jour. Mon client a de nombreuses pressions de son côté et en ce qui nous concerne, nous travaillons au forfait et notre hiérarchie tient, avec minutie, la comptabilité du projet.

Que fallait-il faire? S'en tenir aux spécifications et avoir une solution bancale du concept le plus important de l'application? Je ne tirerais aucune satisfaction de mon travail dans ces conditions. Figer les développements et attendre de nouvelles spécifications? Impossible, l'application doit être mise en production à une période précise et le timing est serré.

J'ai stoppé les développements mais uniquement sur le concept qui nous posait problème sachant que plus le temps passait, moins il restait de tâches. Et un développeur qui n'a plus de tâche à se mettre sous la dent c'est comme offrir une rose au resto, ça coute cher et ça ne sert à rien... Comment ça le principe d'humanité en prend un coup?

Mon binôme et moi avons pris le risque de refaire une analyse sur le lot en cours sans même savoir où ça nous menait. Bien heureusement, nous avons trouvé une solution pour débloquer, une nouvelle fois, la situation. Il s'agissait, pour résumer, d'un concept métier assez implicite mais permettant de simplifier de nombreuses choses. Le plus intéressant est que cette solution est le fruit du travail des deux parties : le client et le prestataire. Nous avions quelques divergences d'opinion sur le sujet mais en croisant nos idées nous sommes arrivés à un résultat satisfaisant.

Quel soulagement!

Test after : la sentence

2009-02-16T20:48:00.004+01:00

Sur une tâche un peu difficile un développeur a sollicité mon aide. Après une courte réflexion, j'ai pris d'assaut le tableau blanc et je l'ai recouvert de diagrammes, portions de code et autres symboles cabalistiques. Tout s'imbriquait miraculeusement, j'étais fier et j'ai laissé le développeur digérer tout ça.

Ce matin ma collègue m'interpelle et m'informe d'une chose assez sérieuse. Voici un bref résumé de notre dialogue :
ML : "La solution ne fonctionne pas."
MB : "Ah?!"
ML : "Juste avant d'écrire le premier test je me suis aperçu que [...]"

Et en effet ma solution ne répondait absolument pas au besoin! Heureusement le Test First est là pour détecter au plus tôt ce genre de problème...

... sauf que pour cette tâche le développeur a choisi de faire du Test After et l'ensemble de la fonctionnalité était développé. Quand j'ai compris à quel point il était simple d'éviter cette erreur un hurlement a surgi dans mon for intérieur. Immédiatement j'ai compris ce que ressentait Bruce Banner dans ses moments là et je me suis mis à penser à des choses agréables pour rester le plus zen possible : un open bar, NUnit tout vert, une certaine personne dans mon entourage...

Quelle est la morale de l'histoire? Le Test First aurait permi de trouver l'erreur plus tôt dans le développement de la tâche, certainement pas au début mais bien avant de la "terminer". Je passe ma journée à répèter certaines phrases comme "On a déja pris le café?", "Put... c'est rouge", "Tu fais tes tests d'abord". Le message passe bien dans l'ensemble mais on s'aperçoit que le moindre écart, la plus petite entorse au réglement nous rappelle à l'ordre. Demain je tenterai de refaire un point sur Test Driven Development pour qu'au moins cette erreur serve d'exemple et nous permette de progresser.

Edit : Renommage TDD (merci père Bezagu)

En guerre virtuelle

2008-12-21T14:09:00.007+01:00

Ce pauvre blog semble moribond tant je ne l'ai pas alimenté ces derniers temps.

En ce moment je suis en guerre virtuelle. Chaque matin je me lève, je prends un petit déjeuner sommaire en lisant deux pages du Fowler, je me prépare et me rend au front. Arrivé sur les lieux, je salue mes lieutenants et attends le reste des troupes. Une fois au complet nous nous dirigeons vers un bivouac que le premier arrivé a improvisé. Café, viennoiserie et nicotine (pour certains) ingérés, nous nous lançons à l'assaut. Les journées sont longues, parfois nous ne voyons même pas notre ennemi mais nous progressons en formation serrée. Le soir je rentre au camp de base et je suis physiquement hors service. Par contre mon esprit gamberge, je réfléchis souvent aux problèmes en cours et à la stratégie à adopter le lendemain. C'est certes peu reposant mais ça me permet d'avoir une infime longueur d'avance sur les événements. Vous savez maintenant pourquoi je n'ai pas eu le courage de donner des nouvelles du front ces derniers mois.

Dans un prochain message vous en apprendrez plus sur nos alliés, notre ennemi et la campagne en cours.

Autour d'un verre

2008-10-21T22:17:00.009+02:00

Samedi soir je suis allé boire un verre avec JR et quelques collègues à lui. Inévitablement la conversation a tourné autour du travail. Nous sommes prestataires et avons des missions bien différentes, il est donc toujours intéressant de discuter des projets en cours et de nos conditions de travail. Il vaut mieux s'adonner à cet exercice en début de soirée tant la tâche devient ardue après quelques verres...

Je ne sais plus comment Extreme Programming est arrivé sur le tapis - en fait j'ai lancé le débat, je le confesse - mais nous avons abordé quelques pratiques comme le pair programming ou TDD. Figurez-vous qu'à ma plus grande surprise, JR s'est mis spontanément à présenter certaines pratiques et à défendre des principes XP! Ce vieux renard s'était documenté et avait compris, de façon plus précise, le bien fondé de l'Agilité. Certes il n'avait pas eu le temps de lire une partie de la série XP. Ses arguments étaient parfois brouillons comparés à la théorie mais comme il confrontait tout ce petit monde avec son expérience personnelle il était tout à fait convaincant. En ce moment même et tout comme moi, il mettait en place quelques pratiques Agiles sur son projet. JR aurait aimé avoir un coach pour le guider dans son application d'XP. Il est vrai que ça doit être un très bon accélérateur et que j'aimerais faire la connaissance d'une telle personne. Quoiqu'il en soit, le projet de JR est plutôt propice à l'introduction d'une nouvelle méthodologie ; il n'y a pas beaucoup d'enjeu et mon ami possède une autonomie confortable.

La communauté s'agrandit!

Petit bilan

2008-10-17T22:39:00.014+02:00

Depuis une semaine je bosse au forfait sur l'application que je maintenais dans ma dernière mission. Autant vous dire que c'est un réel défi car l'équipe ne connait pas le métier et n'est pas au point au niveau technologies utilisées (ASP .NET, C# et NHibernate). Quoiqu'il en soit, l'expérience en sera d'autant plus enrichissante.

Avant de commencer j'avais fais quelques recommandations. Je désirais avoir plusieurs tableaux blancs, un paperboard qui ne devait pas être une alternative au tableaux, des bureaux agencés de telle sorte que l'on puisse bosser en binôme et que l'on soit en mesure de se voir sans tourner la tête à plus de 90°. En somme je n'ai fais que reprendre les idées d'XP Applied. Figurez-vous que j'avais quelques a priori le jour de mon arrivée ; je ne m'attendais pas à ce qu'on ait pris mes demandes au sérieux. Mais j'ai découvert avec surprise un espace de travail très satisfaisant. Il n'y avait qu'un tableau mais le deuxième allait arriver vite, un paperboard était présent mais ne contenait plus de feuille, tant mieux, son panneau fait office de tableau dont je me sers pour noter l'état du projet. Les bureaux quant à eux sont positionnés de façon optimale.

J'avais longuement réfléchi au démarrage du projet. Je pensais commencer par leur parler de pratiques XP que j'allais mettre en place avec leur consentement. Mon but était de les sensibiliser aux méthodes Agiles et partager ma vision de la conduite de projet. Au dernier moment j'ai changé d'idée et j'ai commencé par leur faire un tour d'horizon de l'application et de l'architecture en couche utilisée. Grave erreur... Lorsque j'ai abordé MVP j'ai eu honte d'avoir été aussi peu clair. Je montrais trop de concepts à la fois, je n'appuyais pas assez mes dires par des diagrammes et j'étais trop hésitant. J'ai vite embrayé sur le modèle et je pense m'en être mieux tiré. Je n'avais pas le temps de parler d'XP, j'ai juste évoqué l'intégration continue et TDD. L'intégration continue automatisée leur a beaucoup plu. Il est vrai que je tiens pour acquis le processus de build mais c'est tout même relativement puissant. Cruise Control récupère les sources au moindre changement dans SVN, les compile, exécute les tests et ne déploie qu'en cas de succès. Je pense étendre le processus en lançant une fusée en mousse pilotée via USB en cas de succès et en allumant un gyrophare rouge USB le cas échéant. Si je n'ai pas le budget pour acheter ce genre de matériel, je me servirai de l'alarme principale du bâtiment. Test Driven Development leur a semblé peu naturel au premier abord et je les comprends, d'autant plus qu'un de mes développeurs est habitué à faire de la conception en up-front. Je ne les ai pas sentis réticents à cette pratique et c'est le principal : essayer TDD c'est l'adopter.

Nous n'avons pas encore de serveur d'intégration digne de ce nom. J'ai réquisitionné un poste de développeur non utilisé et j'ai tout installé dessus. Pour les pauvres diables qui en douteraient, un Pentium D avec 1 Go de ram n'est pas suffisant pour héberger un Oracle Express, un serveur SVN, un serveur d'intégration continue et l'application web du projet... Pour information, l'initialisation des données via client lourd a pris 4h30 alors que ça prend moins d'une heure sur mon ultra portable...

En milieu de semaine, l'environnement technique était mis en place et nous avons commencé à coder. Il n'était pas possible de scinder le travail alors que j'étais le seul à avoir les connaissances. J'ai donc choisi de prendre deux développeurs avec moi pour compléter la première tâche et j'ai donné des pistes aux autres membres de l'équipe pour qu'ils s'auto-forment sur les technologies. Nous avons respecté TDD à la lettre pour bien qu'ils intègrent cette nouvelle façon de travailler et le résultat fut très positif. Après un long remaniement de code (j'avançais lentement pour ne pas les perdre) nous nous sommes aperçu que le simple fait de rajouter deux classes d'une dizaine de lignes tout au plus répondait en grande partie aux exigences de la nouvelle fonctionnalité. Comme nous étions sous pression (contexte forfait...) j'ai trouvé que c'était le moment opportun de leur faire croire que tout ce que nous avions fais ces trois derniers jours n'était pas viable, que nous étions partis dans la mauvaise direction et qu'il fallait tout reprendre. C'est une pratique XP. Quand il y a plusieurs solutions et qu'on ne sait pas identifier la meilleure, plutôt que de tergiverser, on les tente les unes après les autres. Dans notre perpétuelle quête d'amélioration, il se peut qu'on échoue. Évidemment ce n'était pas le cas et j'ai vite vendu la mèche pour éviter un tollé général :)

Je suis très satisfait de cette première semaine de travail. Les développeurs ont du potentiel et j'ai hâte qu'ils montent en compétence sur les technologies et le modèle. C'est une trop lourde responsabilité d'être le seul à détenir une solution, s'il s'avère qu'un jour je fasse un mauvais choix, que je sois dans l'erreur, j'espère de tout cœur qu'un développeur aura assez de courage pour me contredire.

Discussion avec un DBA

2008-10-15T22:45:00.010+02:00

J'ai toujours pensé que dans la vie, il fallait s'entourer d'un bon mécano, d'un ophtalmo et d'un DBA.

J'ai bossé sur différentes applications et toutes nécessitaient une base de données. Mais, je le confesse, je n'ai jamais pris le temps de les optimiser. J'ai certes passé beaucoup de temps avec des collègues à améliorer le mapping NHibernate, comprendre le mécanisme de paresse ainsi que le cache de différents niveaux mais je ne me suis jamais attaqué à la base en elle même.

La base de données n'est qu'un outil parmi tant d'autres mais plus la volumétrie de l'application est grande plus les lacunes en optimisation se font sentir. Malheureusement l'optimisation d'une base est un exercice que je trouve très technique et peu facile d'accès. C'est un domaine interessant et fort utile mais je préfère consacrer mon temps libre à me documenter sur d'autres sujets.

Aujourd'hui j'ai fais la connaissance d'un DBA Oracle et telle une groupie je l'ai harcelé de questions. Il n'a pas su me dire qui était le plus fort de l'hippopotame ou de l'éléphant mais dans l'ensemble il a été clair et précis. Je lui ai notamment demandé pourquoi on séparait les tablespaces d'indexes et de données. Tout ça est lié aux problèmes d'accès concurrentiels. Il serait dommage de ne pas pouvoir accéder en lecture à un index pendant qu'on modifier des données.

J'ai aussi demandé si ça impactait les performances d'avoir une clé primaire autre qu'un entier. En effet, une entité a parfois une identité naturelle sous forme de chaîne de caractère par exemple (le login d'un utilisateur, entre autre). La réponse est non pour ma volumétrie. D'une façon générale un DBA répond à une question par une autre question : "Quelle est ta volumétrie?". C'est très efficace sur un site de rencontre quand on n'a que le portrait haut de la demoiselle pour seule référence :
- "Tu veux qu'on prenne un café ensemble?"
- "Quelle est ta volumétrie?"

Re-dou-table

Une autre question était s'il est préjudiciable de ne définir que des varchar2(4000) alors qu'on connait les longueurs maximales mais qu'on préfère les vérifier, à un seul endroit, dans la couche métier ou présentation. Tout dépend du type d'opérations effectuées sur les données. Si on ajoute et supprime souvent les données il peut y avoir des problèmes de fragmentation. Bien sûr il y a des opérations de maintenance pour défragmenter mais peut être que ça pose problème si la base doit être accessible en permanence (je pense aux applications de production tournant H24). Dans mon projet courant, les données ne sont que très rarement supprimées, donc me voila rassuré.

Évidemment, Google serait capable de répondre à tout ça mais rien ne vaut une bonne discussion avec une personne très technique.

J'en reviens au constat évident qu'avait fait FB autour d'un sandwich : un DBA devrait bosser, ponctuellement, en étroite collaboration avec l'équipe de développement. C'est très Agile de mixer les compétences mais dans les faits, je n'ai jamais bossé avec de DBA...

Cette fois je pars!

2008-10-10T18:25:00.003+02:00

Qu'il m'est difficile de quitter cette grande entreprise dans laquelle j'allais bosser avec joie tous les matins! Le bilan est tellement positif que je n'en reviens pas. J'estime avoir été très chanceux dans ma première mission. Mes petites déceptions et frustrations sont bien peu de choses par rapport à tout ce que j'ai appris.

J'ai une petite pensée pour FB et JBD qui ont fait de moi un meilleur développeur. Une autre pour LS qui même si tout n'était pas rose à tout fait pour m'intégrer et me soutenir. Une pensée spéciale pour JR et sa sympathie, son volontarisme et surtout ses hauts oranges fluos. Et une pensée finale pour ADH et ses anecdotes invraisemblables, ses remarques cinglantes et son visage souriant. Je ne citerai pas Godzi qui a eu le malheur de mourir écrasé par un tiroir sur roulette. Si l'inconscient n'avait pas croisé mon chemin il aurait eu la joie de mourir de faim...

De nouvelles aventures m'attendent!

Idéalisme contre Fatalisme

2008-10-09T19:51:00.009+02:00

Quand je travaillais avec FB et JBD nos discussions en dehors des heures de travail (pauses cafés comprises) concernaient bien souvent l'art, la politique, la littérature Égyptienne et... non en fait on parlait surtout d'informatique. On discutait aussi bien de technique que de méthodologie et parfois on illustrait nos propos avec le projet en cours. Autant vous dire qu'on avait beau avoir un sandwish dans la main, on continuait de bosser!

Quand ils sont partis ces discussions m'ont beaucoup manqué. Par ailleurs mes connaissances sur XP et DDD se consolidaient et j'avais envie d'en faire partager mon entourage pour trouver des échos ou participer à un bon débat. J'ai fais la connaissance de JR, un développeur plus expérimenté que moi. Il n'était pas du tout opposé à l'Agilité mais avait beaucoup de doutes quant à son application. Sa principale crainte était de commencer un nouveau projet sans tous les documents bien rassurants que l'on trouve avant la phase de programmation dans le Cycle en V. Je pense que cette crainte est infondée. Le jeu du planning d'XP permet de créer, chiffrer et prioriser des histoires utilisateurs correspondant à des fonctionnalités. Dans la théorie chaque histoire doit être accompagnée de son test d'acceptation. Lors du planning de l'itération, les histoires sont découpées en tâches et estimées à nouveau. Tout ce petit monde n'est ni plus ni moins que le pendant des spécifications. Il est faux de dire que le développeur "démarre à poil sur un projet", pour reprendre l'expression de JR.

J'ai aussi rencontré ADH une jeune chef de projet avec qui nous déjeunions JR et moi. C'est une personne intelligente et très attachante mais possédant un caractère bien trempé. Durant nos discussions, autour du projet, je discutais d'Agilité ou DDD ouvertement et lui expliquais à quel point je souffrais, en temps que développeur, de ne pas participer à l'extraction du domaine et à l'élaboration de la solution. Je ne l'ai jamais soupçonnée de partager mes opinions mais pour des raisons peu avouables je n'ai pas défendu ma vision de la conduite de projet avec autant de véhémence qu'à l'habituée.

Je voyais bien que certains principes la gênaient et autour d'un café j'ai décidé de lui demander ce qu'elle pensait de ma vision des choses. Bien que la discussion démarrait autour de DDD elle dérapa assez vite vers Extreme Programming. Selon elle le développement par itération avec renégociation du périmètre permanent n'était pas viable. Un des arguments était que les utilisateurs n'auraient pas le temps de se former à une application évoluant trop souvent. Certes XP prévilégie les itérations courtes (1-3 semaines) avec acceptation à la clé mais les livraisons de versions se font moins souvent (1 fois par trimestre). Je ne pense pas qu'une livraison majeure tous les 3 mois soit trop rapide. De plus, pourquoi la somme des formations après chaque livraison serait beaucoup plus longue qu'une seule formation globale? Apprendre fonctionnalité majeure par fonctionnalité majeure est plus pertinent que de tout ingérer en une seule bouchée.

Un autre argument, et celui-là je l'entend souvent, était qu'à redéfinir en permanence le périmètre, l'application serait en perpétuel développement et partirait dans tous les sens. Bien entendu XP préconise l'élaboration d'un planning de versions. En somme, un planning à grande échelle qui définit les tendances des évolutions. Ainsi le client peut faire valider un tel plan à son supérieur qu'il peut approuver ou non s'il détecte des incohérences.

Le développement par itération est un rythme à adopter par l'ensemble des acteurs du projet, l'utilisateur ne fait pas exception. Quel est le risque à définir en up-front les besoins et à les figer? Roy Miller et Ken Auer nous répondent dans XP Applied : non seulement il est impossible d'être exhaustif dans cet exercice mais en livrant après 1 année de développement, on répond au mieux aux besoins vieux d'1 an. En combinant ces deux faits, quelles sont nos chances de répondre aux besoins actuels?

Selon elle, il y avait trop de barrières à l'Agilité. Les chefs de projet subissent trop de pression de la part des clients. Les utilisateurs ne savent pas exprimer leurs besoins et ne désirent pas consacrer du temps à l'apprentissage de l'application. Le problème c'est qu'en étant aussi fataliste les choses ne changeront pas.

Nous sommes tombés en désaccord sur bien d'autres points et j'ai même été gratifié d'idéaliste. Je suis déçu de n'avoir détecté aucune Agilité dans ses opinions. Je suis encore plus déçu de ne pas avoir pu continuer la discussion. Tout cela serait plus simple si ce n'était pas une personne que j'estime beaucoup.

Frustrations

2008-10-08T21:48:00.006+02:00

Sur un panneau de mon box j'ai affiché les principes, pratiques et valeurs d'XP. Il y a quelques temps, comme je savais que j'allais travailler dans de nouvelles conditions, je me suis amusé à rêver d'Agilité. J'ai lu les pratiques une par une en cochant celles que je pourrais appliquer. Certaines seraient faciles à faire adopter comme l'intégration continue, le refactoring, et d'autres plus difficiles comme le binômage ou le rythme soutenable. J'étais très satisfait après ce petit bilan de m'apercevoir qu'il n'y avait que peu de pratiques impossibles à appliquer : le client sur site et le jeu du planning. J'étais fier, j'allais avoir une conduite de projet Agile à 95%!

Mais quel con je suis parfois! J'aurais beau adhérer aux principes et valeurs d'XP s'il me manque des pratiques aussi primordiales que les deux précédentes jamais je ne pourrai observer les gains réels de la méthode de Beck.

L'Agilité n'est pas aussi futile qu'un test de personnalité qu'on trouve sur facebook. Qu'est-ce que j'imaginais après avoir coché mes pratiques? Qu'un génie apparaisse et me dise : "Tu es Agile! Tu embrasses le changement, c'est une philosophie qui t'honore. Les gens Agiles sont...". Non. Ma prochaine conduite de projet sera à tendance Agile mais ne sera pas Agile. Je suis frustré de ne pas pouvoir entrer dans XP par la grande porte.

L'échec est bien là

2008-10-07T19:04:00.018+02:00

Il y a plus d'un an, FB et JBD commençait un nouveau projet .NET pour la grosse entreprise dans laquelle j'allais arriver peu de mois après. Auparavant, FB avait appliqué quelques patterns de DDD dans un petit projet et fort cette expérience, il avait décidé avec JBD de remettre le couvert. Le métier était plutôt complexe donc DDD prenait vraiment tout son sens.

Comme ils n'avaient pas accès aux utilisateurs, ils ont tenté de faire une extraction du domaine avec le MOA et la chef de projet. Bien vite, une ébauche de langage omniprésent vit le jour.

Plus tard, j'ai intégré l'équipe et j'ai travaillé avec grand plaisir aux côtés des deux compères. Le projet se portait mal, les utilisateurs n'étaient pas satisfaits de l'application et de nouveaux besoins ont vu le jour. Il y avait de nombreuses pressions autour du projet mais pour ma part ça ne m'affectais pas le moins du monde. Je travaillais avec des personnes intéressantes, j'apprenais beaucoup de choses, aussi bien techniques que méthodologiques. Je me délectais de l'architecture mise en place avec MVP ainsi que les différents patterns de DDD. J'aimais certaines pratiques Agiles mises en place comme TDD (Test Driven Development), le travail en binôme et l'intégration continue par exemple.

Un jour je tombe avec stupeur sur un message du blog de FB. Celui-ci déclarait avoir échoué dans son application de DDD. Les raisons évoquées étaient simples, les développeurs n'avaient aucun accès aux utilisateurs, le domaines qu'ils avaient tenté d'extraire n'était qu'un pari et ne s'avérait pas concluant. Aussi présent qu'était le langage entre nous, la chef de projet et le MOA, il n'atteignait jamais les utilisateurs.

A cette époque je n'étais capable de croire à l'échec. Je n'avais tout simplement pas l'expérience nécessaire et je n'étais pas assez impliqué dans le projet. Mon but était d'apprendre des choses pas de mener le projet à bien (bim erreur!). Certes il était clair qu'on pouvait faire de deuil d'une quelconque conduite de projet Agile mais il y avait encore de l'espoir, selon moi, pour DDD. Je pense que j'avais besoin de me raccrocher à un petit succès sinon à quoi bon s'imposer autant de rigueur dans le développement?

Par la suite, le projet s'est mis en pause, FB et JBD ont quitté l'entreprise et je suis resté pour maintenir l'application. J'ai continué quelques temps en portant mes oeillères. Dès que ma chef de projet changeait certains termes métier, je m'efforçais d'appliquer les modifications dans le code. Certains changements étaient plus lourds que d'autres et parfois ça me prenais plusieurs heures. J'ai fais beaucoup de refactoring, j'ai réorganisé l'ensemble de l'application pour gagner en cohérence et en intention. J'étais fier, le code était beau et testé, les bugs se faisaient de plus en plus rares.

Aujourd'hui, parmi une liste de tâches, je constate qu'il faut renommer un libellé dans une page. Ce libellé correspond à un concept central dans l'application. Pendant un an les développeurs ont employé ce terme avec la chef de projet et le MOA. Il était simple, explicite et fortement ancré dans le langage. Ce n'était pas la première fois qu'un concept changeait de désignation, quand on creuse le métier il s'avère qu'on fasse une découverte et qu'un terme plus explicite voit le jour. J'ai demandé plus d'explications et j'ai découvert avec beaucoup de peine que la majeure partie du modèle créé ainsi que le langage utilisé ne sortait pas du bureau dans lequel je travaillais.

Il est maintenant clair que j'ai fais une erreur en tentant de conserver un modèle du domaine moribond. Que pouvais-je espérer sans jamais avoir rencontré un utilisateur? Comment pouvais-je savoir que le langage omniprésent n'était que local? Pourquoi n'ai-je pas pas pris au sérieux les cris d'alarme de mes confrères?

Lundi une nouvelle équipe de développeurs reprend le projet. Je devrais commencer par leur expliquer que le modèle qu'ils découvriront, aussi beau soit-il, ne trouvera pas son reflet dans la centaine de spécifications qu'ils recevront...

Il y a plusieurs morales à cette histoire. La plus simple est que tout comme un bug, plus un échec est découvert tard, plus les conséquences sont lourdes. Ensuite, on ne peut pas blâmer ses collègues de ne pas partager ses principes et valeurs mais on peut se blâmer soit même de tenter, coûte que coûte, de nager à contre courant.

Un peu d'histoire

2008-10-06T23:19:00.000+02:00

A la suite de mon stage de fin d'étude, fraichement embauché dans une SSII Bordelaise, j'ai entamé ma première mission de développeur pour une grosse entreprise. Je devais reprendre une application développée par un certain FB et les technologies principales étaient les suivantes :

ASP .NET et C# 2.0

NHibernate

Framework perso MVP (Model View Presenter)

De plus, FB avait implémenté quelques concepts qu'il avait découvert dans Domain Driven Design d'Eric Evans.

Le défit était de taille, il s'agissait de ma première expérience professionnelle, de plus je n'avais fais que du J2EE (et EJB 2) pendant mon stage de fin d'étude et n'avais aucune idée de ce que représentait DDD.

Par chance, FB répond toujours présent quand il s'agit d'enseigner quelque chose. Il fait preuve de beaucoup de patience et sait trouver les mots justes pour véhiculer les pratiques qu'il juge bonnes. J'ai aussi rencontré JBD, un autre développeur .NET expérimenté, qui partage de nombreux principes avec FB.

Durant mon stage de fin d'étude j'ai participé à l'ensemble des phases du Cycle en V. Comme je ne connaissais que cette méthodologie et qu'elle me semblait très carrée, murement réfléchie et bien sécurisante je pensais qu'il n'y avait pas d'alternative sérieuse. Pourtant, un des cours de la spécialité Génie Logiciel, à la faculté, était consacré à Extreme Programming. Selon moi, XP y était très mal enseigné, les valeurs n'étaient pas assez mises en exergue et les pratiques pas assez développées. Comment aurais-je pu trouver le Cycle en V plus crédible qu'une méthode Agile dans le cas contraire?

J'ai tenté de suivre les bonnes pratiques Java pendant mon stage et j'ai donc expérimenté le SOA. Tout comme avec le Cycle en V, je ne connaissais pas d'alternative. Le SOA me donnait un sentiment de sécurité (encore!) car les services contrôlent l'ensemble des accès au métier.

Autant vous dire que je me suis senti tout petit lors de mes premiers repas avec les confrères FB et JBD tant ils ont détruit, un par un, les faibles arguments que j'avais en faveur de mes principes. Tout ce qu'ils me disaient avait du sens mais je n'étais pas encore assez expérimenté pour comprendre à quel point j'étais dans l'erreur jusqu'à présent.

Comme je suis une personne de nature orgueilleuse, je me suis mis à lire un ensemble de livres pour accéder à leur niveau. J'ai commencé par Pratique de C# 2 et .NET 2 de Patrick Smacchia pour maitriser un peu mieux le langage que j'utilisais. Ce bouquin très technique m'a permis de comprendre certains comportements de .NET que je jugeais ésotériques. J'ai ensuite attaqué Domain Driven Design et je dois dire que ce fut difficile. Bien qu'à l'aise en Anglais, les tournures employées dans ce livre et la profondeur des concepts expliqués m'ont contraint d'avancer à pas de loup. Ensuite, il était temps de me réconcilier avec XP, j'ai donc pris d'assaut la série en lisant XP Explained de Kent Beck et XP Applied de Ken Auer et Roy Miller. J'avais une bonne vision de l'Extreme Programming et je pensais pouvoir appliquer la majeure partie des pratiques. Pour ce qui est des valeurs, j'y avais adhéré les yeux fermés. Mais j'avais encore beaucoup d'intérrogations au niveau du planning ; je n'avais aucune idée de comment effectuer un bon planning game et des concepts comme la vélocité étaient encore flous. J'ai donc lu Planning Extreme Programming de Kent Beck et Martin Fowler.

Je suis maintenant capable de comprendre une bonne partie de la philosophie DDD et je peux, désormais, me sentir Agile en toute légitimité. Le déclic a été un peu long à mon gout mais j'ai finalement embrassé le changement!

Un nouveau blog parfaitement inutile

2008-10-06T22:55:00.002+02:00

J'ai passé plusieurs années à me moquer de tous ces gens qui étalent leur vie sur la toile. Je trouvais ça parfaitement inutile de partager avec des inconnus ses états d'âmes et encore plus de lire ceux des autres.

C'est donc à des fins purement expérimentales que j'ouvre ce blog dans le but de comprendre ce que pousse les gens à...

...

en fait j'ouvre ce blog parce que j'ai envie de vous faire part de mes états d'âmes. Comment ça je retourne ma veste? De toute façon personne ne me lira, donc je ne partagerai mes pensées qu'avec moi même. M'étant parfaitement connu, je ne rentre pas dans la catégorie décrite en début de message!