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.
- 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.
mardi 21 octobre 2008
La Troisième Question
Dans Scrum, c'est souvent pareil; à la question « Vous avez des problèmes ? » , les équipes répondent « Non, tout va bien » .
Prioriser des demandes d’amélioration 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 ».
- 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.
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?
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 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.
(*) 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
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.
- 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!
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.