jeudi 30 octobre 2008

Bienvenue à Bruno


Je souhaite la bienvenue à Bruno Orsier, collègue, ami et inspirateur dans la nébuleuse blogosphère ;-) Ses premiers billets sont pour les conférences AgileTour de Grenoble et Valence. Notez aussi ses nombreuses contributions sur developpez.com sur les bonnes pratiques de tests et de POO.

Le But


Coup de cœur pour le livre Le But écrit par Eliyahu Goldratt (père de la théorie de contraintes). Ce livre est un vrai roman qui vise à nous faire comprendre des concepts assez indigestes de prime abord. Concepts qui ont tout à fait leur place dans la boîte à outils de l'Homo Agilis ;-)

L'histoire raconte la périlleuse quête d'un directeur d'usine qui a 6 mois pour sauver son entreprise. En effet, ce directeur d'usine apprend du jour au lendemain que son usine n'est pas rentable alors que tous les indicateurs de processus sont bons, que les rendements de ces machines sont les meilleurs du secteur. Abasourdi, ce dernier mettra un certain temps pour savoir par où commencer... heureusement, il croisera une vieille connaissance à lui, un expert de l'optimisation des processus, gourou mathématicien aussi, qui lui donnera de sérieux tuyaux... à déguster.

vendredi 24 octobre 2008

AgileTour Valence


AgileTour 2008 s’est terminé hier à Valence… Vive AgileTour 2009 !

J’ai beaucoup apprécié cet après-midi passé à Valence. Je m’y suis rendu avec mon collègue et ami Bruno. Le niveau des sessions, la qualité des échanges ainsi que le buffet ont été au rendez-vous. Le tout a été orchestré d'une main de maître par les organisateurs! Chapeau bas!

L’atelier « Artistes et Specifieurs » animé Gery Derbier m’a énormément plu. On y découvre de façon ludique les écueils possibles dans la communication entre client et développeurs, et surtout les moyens pour arranger les choses. Je ne regrette pas d’y être allé !

Le retour d’expérience d’Alexandre Boutin sur l’implémentation de Scrum chez Yahoo ! en Europe, Asie et Canada m’a beaucoup plu ! Il y était question du choc des cultures. On relève au passage qu’Alexandre avait initialement tenté d’implémenter du cycle en V, mais a du retourné sa veste (du bon coté) en choisissant une démarche Agile. Je retiens aussi que la démarche initiale était un processus imposé visant à contrôler, alors que la forme Agile est un framework optionnel facilitant l’adoption de Scrum mais sans le rendre obligatoire : « On peut forcer quelqu’un à suivre un processus, on ne peut le forcer à être Agile... ». Enfin, une raison obligatoire au succès de la démarche est l'engagement du management.

J’ai ensuite assisté à une petite partie du forum ouvert animé par Alexandre, où il était question du rôle des spécialistes dans une approche agile et du sujet brûlant de la contractualisation au forfait.

Enfin, Gery Derbier a présenté la méthode Crystal de Alistair Cockburn décrite dans les livres Agile Software Developpement et Crystal Clear. J’y ai retenu que cette méthode pouvait s’apparenter à un framework où les pratiques concrètes doivent s’adapter en fonction du contexte et de la vie du projet. Ce framework s’appuie sur des points théoriques :

  • Le développement logiciel est un jeu coopératif d’invention et de communication avec deux objectifs antagonistes : livrer un produit et se préparer pour la partie suivante.
  • Le produit délivré par une équipe est à l’image de celle-ci

Crystal s’appuie 3 propriétés principales : livraison fréquente (au moins tous les 6 mois), communication de proximité entre tous les développeurs (moins de 30 sec pour obtenir une info), réflexion tactique pour s’améliorer (une fois minimum tous les 2 mois). Crystal me fait penser à une méta-méthode, relativement "universelle" en fait.

Dans les couloirs, j’ai beaucoup apprécié mes échanges avec Laurent Bossavit, Géry Derbier, Emmanuel Chenu, Emmanuel Hervé, ainsi que bien d’autres que j’oublie… ca fait sacrément plaisir d’échanger, d’apprendre, on se sent moins seul dans le désert ;-)

mardi 21 octobre 2008

La Troisième Question


Dans Scrum, la troisième question de la mêlée quotidienne (daily scrum) consiste à savoir si l'équipe rencontre des obstacles. En général si on vous pose la question de bon matin « Ca va ? », vous répondez naturellement « Oui » même si vous avez un gros souci dans la tête. Si j'étais consultant, je dirais qu'il s'agit d'un « meta programme » bien connu en PNL ;-)

(euh, je n'ai rien contre les consultants et la PNL)

Dans Scrum, c'est souvent pareil; à la question « Vous avez des problèmes ? » , les équipes répondent « Non, tout va bien » .

Les expériences passées m’ont conduit à penser que la première chose à faire pour un Scrum Master c’est de reformuler la question de façon ouverte afin d’obtenir un maximum d’information. La seconde chose est de s’assurer que l’équipe comprend que cette question ne concerne pas seulement les obstacles destinés au Scrum Master, mais surtout les obstacles internes à l’équipe elle-même ! L’objectif est ici d’éviter le réapprentissage (éviter que des membres tombent dans un piège déjà connu par les autres). Il y a d'autres objectifs derrière cette question, mais ce sera pour une autre fois.

C’est en animant une équipe expérimentée en tant que Scrum Master durant cet été que j’ai eu une sorte d’illumination sur cette fameuse 3ème question. En cogitant les notions Lean de temps de cycle, de gestion de priorité, et je dois dire aussi sous influence de l’excellent livre de E. Goldratt « Le But », que j’ai eu envie de reformuler cette question sous cette forme :

« Quels sont les obstacles que nous rencontrons et qui nous empêchent de finir cette user story que nous avons commencé en premier ? »

(à noter le « nous » dans la question qui permet de dire clairement que le Scrum Master est avec l’équipe ;-)

En effet, si le but est de réduire le temps de cycle (ou de réalisation par l’équipe), la théorie nous dit que l’on travaille plus efficacement si on se concentre sur une seule tâche à la fois. Dans un monde idéal toute l’équipe devrait travailler sur la même User Story. Or, ce n’est pas tout le temps possible dans la vraie vie, mais il n’empêche que la tâche la plus vieille devrait être la plus prioritaire devant les autres. Une sorte de « Hot User Story » marquée en rouge pour que l’équipe puisse se focaliser sur celle-ci en priorité, les tâches relatives à celle-ci devenant automatiquement prioritaires devant toutes les autres.

Dans la pratique, même si cette reformulation parait séduisante, il s’avère qu’elle est insuffisante. Il ne suffit pas à un Scrum Master d’être persuadé d’avoir vu la lumière pour convaincre ses collaborateurs. L’intérêt de la question posée ne vaut que si l’équipe est prête à l’entendre. Or, il arrive parfois qu’une équipe à l’esprit bien trop occupé pour réfléchir à des aspect jugés trop théorique, ou tout simplement en dehors des préoccupations de l'équipe… mais ceci est un autre problème ;-)

Prioriser des demandes d’amélioration d’intégration continue


Je voudrais partager cette pratique que je me suis imposé récemment. Le problème à résoudre était le suivant :

"Comment prioriser les demandes d’amélioration de notre plateforme d’intégration continue ?"

En effet, les équipes y détectent souvent des pistes d’améliorations. Ces améliorations ont pour but de leur permettre de travailler plus efficacement. Comme nos ressources pour modifier nos outils d’intégration continue sont assez limitées, il faut faire des choix, prioriser les demandes et délivrer en fonction des priorités. Un tel backlog existe depuis très longtemps mais il n’y a jamais eu de notion de priorité à l’intérieur. Les demandes étaient traitées selon la règle de « celui qui parle en dernier » ou la règle de « celui qui parle le plus fort ».

A un moment, pour résoudre le problème, je fut tenté de faire voter les équipes pour qu’elles définissent elle-même la valeur des demandes d’amélioration. Un peu comme un planning poker. Ce processus avait pas mal d’inconvénient :

  • disponibilité des équipes pour voter
  • la décision de faire telle ou telle chose repose sur un vote «au feeling» et non sur du «factuel»
  • il se peut que de grosses différences de perception surviennent pendant les votes (des discussions certes intéressantes peuvent se tenir, mais au final le processus peut prendre beaucoup de temps)

Nous n’avons jamais tenté cette méthode.

M’inspirant de l’approche Lean, j’ai essayé de poser chaque demande d’amélioration du point de vue « Muda » (=gaspillage). Par intégration continue, on entend en fait une « ligne de production logicielle » dont le but est de convertir une ou plusieurs modifications de code en un produit terminé. Chaque attente sur cette « chaîne de montage » introduit un délai supplémentaire dans le temps de réalisation. Les demandes d’amélioration peuvent être vues comme des moyens de supprimer ces attentes. Le résultat d’une amélioration est donc un gain de temps de disponibilité de la plateforme afin de traiter de nouvelles modifications de code.

Partant de cela, avec l’aide de membres des équipes, nous avons estimé le gain de temps (=réduction de « Muda ») engendré par chaque demande. En adoptant le point de vue d’une User Story, on exprime la valeur de la demande dans l’unité « Heure.UserStory/Jour ». Par exemple une valeur de 2 signifie un gain de disponibilité de la plateforme de 2 heures par jour pour une User Story en cours de développement. Introduire la notion de « Heures.UserStory » permet de tenir compte du fait que l’amélioration aura un impact sur plusieurs User Stories en parallèle.

Je ne suis pas un expert du product backlog produit mais j'imagine que la même démarche pourrait être utilisée pour quantifier précisemment la valeur d'une fonctionnalité utilisateur : comment cette fonctionnalité pourra faire gagner du temps à l'utilisateur? Comment cette fonctionnalité lui apporte une réelle valeur, chiffrée?

Reste ensuite à estimer la taille de développement de chaque demande. En calculant ensuite le rapport Taille/Valeur on peut alors s’attaquer aux demandes qui auront le meilleur retour sur investissement.

lundi 20 octobre 2008

Paysages virtuels


Récréation. Terragen est un petit bijoux de logiciel que je connais depuis des années. Il permet de créer des "paysages virtuels" comme ce superbe coucher de soleil. Il intègre un modeleur de terrain, des textures de surface (neige), un moteur de ray-tracing tenant compte de centaines paramètres (atmosphère), un rendu pour des nuages 3D, un gestionnaire pour les étendues liquides comme les lacs (ou la mer), etc... très facile à prendre en main... essayez pour voir ;-)

Les trois registres


Aujourd’hui, un petit peu de communication… il parait que c’est la raison #1 de presque tous nos échecs, que ce soit dans le travail ou à la maison ;-)

J’ai suivi une formation sur la communication en début d’année. Je dois avouer qu’elle m’a beaucoup apporté. Je suis très loin de maîtriser les outils que la formatrice nous a enseignés, mais il n’en reste pas moins que certains principes appris ne me quittent plus.

Voyons l’un de ces outils : quand on s’exprime, nous le faisons selon 3 registres différents :
  • le registre factuel : on exprime les faits tel qu’ils se sont produits, sans interprétation ni arrière-pensée, le plus objectivement possible
  • le registre des émotions : on exprime ses propres émotions (joie, tristesse, peur, colère etc..) sous la forme « Je ressens ceci… »
  • le registre des opinions : on exprime une interprétation, une métaphore, une conception de la réalité, c’est le cas d’un jugement, d’une appréciation de valeur.

Certains de ces registres sont des facteurs clefs pour une bonne communication. Mais ce n’est pas le cas de tous ces registres.

Le registre factuel peut être utilisé pour poser un problème, décrire une situation. Il est utile pour décrire une vision qui doit être partagée avec autrui. La puissance du factuel, c’est qu’il permet un consensus dans tous les cas. C’est souvent un registre utilisé en introduction, pour « poser le problème ».

Le registre des émotions est très utile aussi car il permet de donner du feedback sur votre état à autrui. Nos émotions exprimées permettent à l’autre de comprendre nos réactions, et si ce dernier peut les comprendre, il pourra aussi s’adapter pour améliorer les choses. Le registre de l’émotion est aussi très utile car il est « incontestable » : si vous ressentez de la colère, vous dites « Je suis en colère », personne ne pourra le contester. Par contre si vous criez « Tu n’es qu’un abruti ! », on pourra deviner que vous êtes en colère mais le dialogue risque de tourner au conflit ! Ce registre permet t’interpeller son collaborateur sur les conséquences de ses actes, plutôt que sur ses actes seuls. On passe d’un discours « Tu… » à un discours « Je… ».

Le registre des opinions doit être utilisé avec beaucoup de précaution. Notre interprétation des choses, nos valeurs, nos principes sont notre richesse intérieure. Ce sont des référentiels uniques d’un individu à l’autre. Mais de l'opinion au jugement il n’y a qu’un pas. Souvent, justement en cas d’émotions, il est très facile d’emprunter des raccourcis et de coller des « étiquettes » aux individus. Exprimer des opinions négatives c'est est un vrai désastre en communication. On parle des fois du « Tu qui tue ». Par exemple, un collaborateur s’est comporté d’une façon qui vous a mis en colère, vous lui dites « Tu aurais pu faire attention ! Tu n’es pas très doué !». Si vous dites « Je pensais que tu devais faire ceci : tu viens de faire cela : je suis plutôt déçu par ce que tu viens de faire, pourrait-on en discuter ? », il s’agit d’une démarche factuelle avec un feedback sur son émotion, c’est plus constructif et ça évite de « rabaisser » inutilement son collaborateur.

Les registres des faits et des émotions nous aident en fait à travailler notre écoute : au lieu de « juger » , on essaye avant tout d’apprendre à mieux connaître son collaborateur. Il en résulte que la relation avec autrui s'améliore, et le travail en équipe s’en trouve lui aussi grandement amélioré. Pour le plus grand bien de tous.

lundi 13 octobre 2008

Core Protocols

La première fois que j’ai entendu ce terme c’était à Paris aux XP-Days, en mai dernier, en déjeunant avec Olivier Albiez. J’ai ensuite lu la traduction française de Gery Derbier des Core Protocols, tirés du livre des époux McCarthy (Software for your Head). A ce jour, je suis persuadé que les Core Protocols sont des outils très puissants pour aider un groupe à devenir une vraie équipe. Ces outils sont le fruit d’observations et d’améliorations à partir de vraies expériences en équipe (bootcamp). Cela explique pourquoi les Core Protocols évoluent avec le temps.

En introduction, les auteurs soulignent que pour constituer une équipe performante, il faut la conjugaison des trois facteurs suivants

  • la présence des membres de l’équipe (savoir qui est dans l’équipe)
  • une décision (objectif) qui a l’adhésion totale de l’équipe
  • l’alignement de chaque membre de l’équipe avec l’objectif commun

On constate que les thèmes abordés ici vont de l’intelligence du groupe au développement interpersonnel. Les époux McCarthy nous donnent des outils pour travailler sur ces trois axes. Par exemple, l’outil « Décider » est un outil qui permet à une équipe de décider à l’unanimité. Un autre outil « Contrôle d’intention » permet d’éclaircir les actions d’un membre de l’équipe qui ne serait pas bien comprises par un autre membre.

Toutefois, j’ai l’impression que ce genre de techniques ne passent pas bien dans notre pays. Nous baignons peut-être dans une culture qui n’incite pas les gens à parler profondément, et pire, qui fait se sentir les gens fautifs si ils révèlent leurs émotions en groupe. Nous sommes extrêmement focalisés sur les domaines de l’action, des tâches, des processus et tellement peu sur ceux de la communication.

Pour en savoir plus, je vous invite à lire la version française(*) pour vous faire votre propre opinion. Pour information, Géry Derbier animera des sessions à l’Agile Tour 2008 de Valence le 23 octobre prochain !

(*) Il s'agit d'une version assez ancienne. Si vous voulez une version plus récente, merci de me contacter.

dimanche 12 octobre 2008

Scrum et XP depuis les tranchées


Si vous ne connaissez pas le livre "Scrum and XP from the Trenches" de Henrik Kniberg, vous avez deux options:
  • soit vous vous précipitez sur InfoQ pour le télécharger et vous le lisez en anglais
  • soit vous attendez quelques semaines et vous l'aurez en français dans le texte
Nous sommes quelques uns (Guillaume Mathias, Bruno Orsier et Christophe Bunn) à travailler sur sa traduction et j'espère que nous toucherons bientôt au but. Ce joyaux est une mine d'or pour la communauté agile! Des tonnes de conseils pragmatiques, du gros bon sens, bref c'est du très lourd. Il vaut amplement les quelques nuits passées à sa traduction et les relectures. Promis, on va faire le maximum pour vous le donner le plus vite possible... surtout qu'en ce moment, je crois que je suis le "bottleneck" de l'équipe avec le dernier chapitre dans ma "todo list" ;-)

jeudi 2 octobre 2008

Agilité dans les Arbres


Bon, voici la vraie histoire à propos de l’accrobranche, celle qui souleva la risée de mes collègues l’année passée : comment je me suis cassé la cheville sur un parcours d’accrobranche.

L’histoire commence quelques mois avant l’accident, époque où je suis allé faire de l’accrobranche plusieurs fois dans un parc (disons le parc A) avec ma fille. Notez que ma femme n’était pas présente.

Le jour de l’accident, nous sommes allé en famille (femme, enfants, cousins, etc… ) dans un autre parc (disons le parc B). Comme dans chaque parc d’accrobranche, il est obligatoire d’être briefé au démarrage sur les consignes de sécurité par un responsable du site. Sûr de moi, ayant déjà pratiqué, je demande si je peux déroger à la règle et si ma femme pourra me passer son baudrier pour que je puisse profiter moi-aussi des sensations. La responsable accepte, précisant que c’est une mesure vraiment exceptionnelle.

Juste avant la fermeture du parc, il se met à pleuvoir et il est temps de rentrer. Je n’avais pas encore profité du parc et ma femme propose que j’aille me faire plaisir avec la grande tyrolienne de 200 mètre de long qui descend le long d’un pré. J’hésite car l’envie n’est pas au rendez-vous mais elle insiste. J’enfile donc le baudrier et me jette sur la tyrolienne…

A mi-parcours du câble, je devine que rien ne pourra me freiner et je vais probablement m’écraser sur la plateforme d’accueil 100 mètres plus loin… au même moment je devine que j’ai du raté quelque chose, que les tyroliennes du parc B sont différentes de celles du parc A… je n'arrive pas à comprendre pourquoi rien ne me freine… je me souviens, dans le parc A, les câbles sont assez lâches pour que les gens soient ralentis et arrivent en douceur sur les plateformes… Eurêka ! Je réalise qu’ici, dans le parc B, on ne peut pas se lancer à fond, il faut probablement maitriser sa vitesse à l’aide de ses mains en serrant le câble… d’ailleurs j’avais bien lu le panneau « Attention, maitriser votre vitesse ! » à l’entrée de la tyrolienne... mais j’ignorai que ça voulait dire, « svp, ne dépassez pas les 3 km/heure ! »… j’étais loin d’imaginer que les règles étaient si différentes d’un parc à un autre… L’arbre qui se rapproche de moi à vive allure vient confirmer mes craintes et je fini la course avec un grand « crac » dans la cheville gauche, au moment où mes pieds heurtent le gros matelas qui entoure l’arbre. Comme j'arrive à me mettre debout, que je suis encore vivant, j'arrive à me rassurer, ça aurait pu être bien pire ;-)

Tout cela a été le résultat de 3 causes conjuguées :

  • ma femme n’avait jamais été dans le parc A, sinon elle m’aurait mis en garde sur la différence de système des deux parcs
  • il y a une différence entre les 2 parcs : dans le parc A, on peut se lancer, mais pas dans le B (En 2008, une loi oblige tous les parcs à avoir des dispositifs de sécurité pour éviter ce genre d’accident)
  • je n’ai pas suivi les règles du parc, c'est mal! Je n’ai pas assisté au briefing du départ... promis je ne le ferai plus!

Il s’en ait suivi un plâtre, puis une petite complication qui dure encore, et surtout des blagues internes sur mon agilité dans les arbres ;-)

Une petite pensée tout de même pour mon cousin, resté suspendu au bout d’une corde, à plusieurs mettre du sol, pendant des dizaines de minutes, pendant que tous les responsables du parc étaient occupé à me faire évacuer vers le CHU ;-)

Team Building

J’aime beaucoup cette réponse à la question « Comment fait-on du Team Building ? » relevée sur StackOverflow. Il s’agit du témoignage d’un manager d’équipes de développeurs. La transformation d’un «groupe d’individu » vers une « vrai équipe » repose sur certaines pratiques dont il donne une liste des plus importantes selon lui :

  • Vous vous occupez de PERSONNES, pas de machines ni d’esclaves.
  • C’est votre responsabilité de transformer ce groupe en équipe.
  • Au commencement vous devriez donner les premières étapes (Voir The Pragmatic Programmer, Chapter 1, Section 3: "Stone Soup and Boiled Frogs", => être un catalyseur du changement)
  • Vous ETES un exemple à suivre pour eux.
  • Le respect des membres est un « MUST HAVE », et ça commence par vous. Vous devez respecter chaque personne dans l’équipe, et vous assurez que tous les membres se respectent mutuellement.
  • Tous les membres d’une équipe font des erreurs (vous y compris).
  • Si vous faites une erreur, vous DEVEZ la reconnaître en public avec vos équipes, et dire comment vous allez la réparer.
  • Si vous voulez blâmer une personne, faites-le en privé. Si vous avez quelqu’un à féliciter, FAITES-LE publiquement au sein de l’entreprise avec les autres membres d’équipe.
  • Quand vous parlez à votre chef, rappelez-vous que le travail a été fait par vous ET par votre équipe. Vous ne devez pas en assumer seul tout le mérite.
  • N’embêtez pas votre équipe avec les problèmes du projet. Vous devez toujours les protéger des problèmes extérieurs. C’est votre responsabilité.
  • Si vous devez blâmer l’équipe, faites-le avec respect ! Peut-être que l’équipe a échoué à cause de vous, vous devez analyser la situation avec soin (peut-être avec eux).
  • Vous n’êtes pas leur mère.
  • Après un dur travail à forte pression pour fournir quelque chose, donner une pause aux membres de l’équipe les plus affectés.
  • Et le plus important de mon point de vue : essayer de très bien connaître chaque membre de l’équipe : leur personnalité, problèmes, peurs, passe-temps, etc.. Cela aide à prendre vos décisions. Exemple : un membre de l’équipe qui a un ou 2 enfants se "gère" de façon différente de celui qui est célibataire vivant dans un petit appartement.
  • Cela prend du temps pour construire une équipe, ne vous attendez pas à en avoir une en quelques semaines.

mercredi 1 octobre 2008

Stackoverflow

Les deux très célèbres bloggeurs Jeff Atwood et Joel Spolsky ont donné naissance il y a peu à un site collaboratif d’entraide pour développeurs appelé Stackoverflow. Basé sur des questions/réponses, il est 100% gratuit. Il est doté d’un système de votations, de badges et de réputation, ce qui permet de trouver efficacement l’information pertinente. Je l’ai testé sur une question sans réponse après qqs heures de recherche sur la toile et j’ai eu une réponse assez intéressante en 10 minutes. A noter que ce concept « question/réponse » est très proche de celui de Yahoo Answers.