Je fais mes premiers pas en BDD - le Behavior Driven Development (développement dirigé par les comportements). A ce stade j'ai du mal à voir s'il s'agit d'une simple variante du TDD (développement dirigé par les tests), ou bien s'il s'agit de quelque chose de vraiment différent et novateur. Le BDD semble permettre de faire des tests à plus haut niveau que les tests unitaires, directement au niveau des histoires d'utilisateurs (user story), et produit un rapport d'exécution de test compréhensible par un non informaticien, contrairement aux tests unitaires usuels. Certains trouvent cela très utile pour démontrer à leurs clients qu'ils font bien les tests, et indiquer précisément quels tests ils font, pour d'autres c'est simplement un moyen d'implémenter des spécifications exécutables et avoir une meilleure couverture de code.

Pour se faire une idée plus précise de cette nouvelle technique, rien ne vaut une expérimentation concrète, je vais donc participer demain à une séance de BDD avec mes camarades du Coding Dojo du CARA. Voici comment j'ai préparé mon environnement Visual Studio 2008 pour pouvoir faire du BDD, dans une configuration minimaliste pour démarrer.

» Lire la suite!

AutoHotkey est un logiciel gratuit qui me permet quotidiennement de simplifier certaines tâches répétitives. Par exemple saisir les dates dans notre format normalisé, taper les formules de politesse dans les mails, taper plus vite les expressions courantes lors des traductions, écrire des macros pour répéter un test de logiciel des milliers de fois, insérer des bouts de code pendant la programmation, insérer certains commentaires pour respecter nos normes de codage... Bref, une sorte de couteau suisse. Evidemment il y a des outils spécialisés pour tout ca : dans Office on peut écrire des macros, dans les environnements de programmation aussi, etc. Mais comme j'utilise beaucoup de logiciels, je ne maîtrise pas forcément les particularités de chacun, et un couteau suisse est bien utile dans mon cas.

Dans AutoHotkey on réalise tout cela grâce à des fichiers de script que l'on exécute soit en permanence, soit ponctuellement. Un fichier de script peut également être compilé en un exécutable Windows que l'on peut faire tourner sur n'importe quel PC, même si AutoHotkey n'est pas installé. Bon j'en ai déjà marre d'écrire AutoHotkey sans arrêt, avec les majuscules bien placées, alors je vais automatiser ca ! J'édite le script principal, via la barre d'icônes, cela lance Notepad (il y a des modes AutoHotkey disponibles dans des éditeurs plus avancés), et il me suffit d'insérer la ligne :

::ah::AutoHotkey

pour que maintenant dans n'importe quelle application Windows, le fait de taper ah insère automatiquement AutoHotkey. Quand je travaillais sur la traduction de Scrum et XP depuis les tranchées, j'avais défini des abréviations comme :

» Lire la suite!

L'une des utilisations des cartes mentales (aussi appelées cartes heuristiques) est la prise de notes (au sujet d'un cours, de la lecture d'un livre, sur n'importe quel travail en cours). Tony Buzan, l'inventeur des cartes mentales, critique fortement la prise de notes traditionnelle : il considère que 90% des mots qui sont écrits ne servent à rien (donc 90% de l'effort d'écriture serait du gaspillage, et 90% de la ou les relectures serait aussi du gaspillage !). Dans Une tête bien faite, il va même beaucoup plus loin, et donne des exemples d'élèves assez mal jugés par leurs enseignants, qui ont des prises de notes traditionnelles défectueuses, et qui pourtant font de remarquables cartes mentales. Son idée est que l'on peut très mal juger un enfant quand on lui impose une certaine manière de s'exprimer.

En tout cas ceux qui se mettent à travailler avec des cartes mentales regrettent vivement de ne pas avoir appris ces techniques plus tôt, et pourquoi pas très tôt à l'école. Enseigner les cartes mentales ne demande que peu d'efforts, alors pourquoi s'en priver ? Heureusement certains enseignants travaillent déjà avec des cartes. Voici le témoignage d'un professeur de français :

Tous les élèves n’ont pas forcément adhéré à l’utilisation des cartes heuristiques, que je n’ai absolument pas voulu imposer, mais bon nombre d’entre eux y ont trouvé un outil d’une grande utilité pour organiser leurs idées, préparer leurs fiches de révision au baccalauréat et appréhender l’épreuve finale.

» Lire la suite!

Dans Pragmatic Thinking and Learning: Refactor Your Wetware (vivement recommandé par Java In The Alps), l'auteur Andy Hunt décrit plusieurs biais cognitifs qui affectent nos processus de pensée. En gros, ces biais cognitifs sont les "bugs" dans nos manières de penser. Ces bugs ne viennent pas de notre éducation ou de notre formation, ils sont inhérents au "fonctionnement" de notre cerveau, et nous les avons tous à des degrés divers. Bien sûr éducation et formation peuvent y remédier, mais encore faut-il les connaître.

Si vous n'avez pas le livre, vous pouvez en trouver une liste impressionnante de biais cognitifs sur wikipedia pour vous faire une idée. L'étude des biais cognitifs est un sujet passionnant en soi (certains de ces "bugs" permettraient de décider plus rapidement dans des situations d'urgence - très important pour le chasseur de la préhistoire, d'autres sont liés à notre incapacité flagrante à manipuler correctement probabilités et incertitude), mais pourquoi s'y intéresser dans notre contexte d'informaticiens ?

Tout simplement parce que la connaissance des biais cognitifs permettrait aux équipes agiles (et à leurs facilitateurs et coachs) de s'améliorer plus efficacement. La capacité de pouvoir reconnaître un biais cognitif est un outil très précieux. En effet, une fois que vous avez reconnu un biais en action, vous pouvez abandonner les pensées du style "ce gars est un imbécile, il réfléchit n'importe comment, il n'y a rien à en tirer, etc.", et vous pouvez adopter une stratégie d'amélioration adaptée au biais en question.

» Lire la suite!

Si vous souhaitez utiliser de belles icônes pour agrémenter vos cartes mentales, et ainsi voir si cela aide à développer votre capacité de résolution de problèmes comme je l'ai suggéré dans un billet précédent, le site Smashing Magazine propose de nombreux jeux d'icônes gratuits (source : le groupe MindManager Enthousiasts).

Utiliser un jeu d'icônes cohérentes donne un résultat bien plus plaisant qu'avec mon ensemble de cliparts hétéroclites !

Ci-dessous je propose une nouvelle carte réalisée avec quelques icônes deux de ces jeux, l'un développé par VistaIco et l'autre par Sébastien Durel. J'ai retenu uniquement certaines icônes qui peuvent me servir dans mes cartes de résolution de problèmes, et mon choix est bien sûr arbitraire. Vous pouvez être inspirés par d'autre icônes ou d'autres jeux d'icônes. Les cartes mentales n'ont pas forcément vocation à être un support de communication universelle, je les vois surtout comme un excellent support pour réfléchir et mieux mémoriser.

» Lire la suite!

N'avez-vous jamais trouvé étrange que dans les "romans d'affaires", comme le célèbre Le But : Un processus de progrès permanent, le héros qui fait face à un problème insoluble prend souvent sa voiture, et roule plusieurs heures tout en réfléchissant à ses difficultés ? Moi cela m'a toujours surpris. J'ai longtemps mis ca sur le compte d'une particularité culturelle américaine, en lien avec les grands espaces et la prédominance de la voiture comme moyen de transport. Toutefois j'ai changé d'avis récemment en lisant Dessiner grâce au cerveau droit. L'auteur, Betty Edwards, y explique que la conduite sollicite fortement notre cerveau droit, cerveau droit que certains d'entre-nous sous-utiliserions dans la résolution de problèmes. Betty Edwards animait d'ailleurs des séminaires en entreprise pour aider les gens à mieux réfléchir grâce au dessin.

Cette idée d'un rôle asymétrique des deux hémisphères du cerveau ne semble pas avoir de réalité neurologique (voir par exemple Cerveau droit, cerveau gauche : le mythe).  Il n'empêche que je me retrouve dans la description du mode "cerveau gauche" (verbal/analytique/séquentiel), et je me suis aperçu qu'il m'était utile de faire travailler délibérément un mode "cerveau droit" (visuel/perceptif/simultané). C'est particulièrement vrai en résolution de problèmes informatiques, comme le développement de nouveaux algorithmes ou l'investigation de problèmes mystérieux.

Dans ce billet je décris une technique moins dangereuse que la méthode américaine basée sur la voiture, à savoir l'utilisation de cartes mentales.

» Lire la suite!

Aujourd'hui j'ai animé un quatrième dojo agile (en interne, contrairement aux dojos du CARA où je participe comme secrétaire ou animateur occasionnel ou simple participant). Dans les dojos internes ma préoccupation principale est toujours de trouver des activités qui puissent intéresser nos utilisateurs embarqués dans les équipes Scrum. Ces  utilisateurs ne savent pas programmer, et je ne peux donc pas me baser sur des activités de programmation pure. Par exemple je ne peux pas utiliser les innombrables vidéos qui comportent plein de code, ce qui réduit beaucoup mes choix. De plus je dois essayer de varier les activités, afin de maintenir l'intérêt des participants. Alors aujourd'hui le programme que j'avais concocté était 1) vidéo "Agile Testing" 2) Exercice d'auto-organisation d'équipe 3) suite du challenge de programmation (le simulateur de fourmis) déjà mentionné dans les billets précédents.

» Lire la suite!

Dans ce billet j'examine comment nous pourrions développer notre capacité à générer de la connaissance afin d'améliorer notre pratique de Scrum (voir billet précédent sur la conception de produits Lean).

Pour commencer, je pense qu'il faut distinguer connaissances publiables (par exemple sur le Web) et connaissances confidentielles (relatives au coeur de métier de votre entreprise). Vous pouvez être tentés de considérer que tout ce que vous faites dans votre entreprise est strictement confidentiel. Je n'en suis pas certain. Justement la pratique des méthodes agiles nous encourage à être beaucoup plus ouverts qu'auparavant, et à chercher à collaborer avec l'extérieur de l'entreprise. Il me semble donc qu'il faut être très sélectif sur ce qui doit rester confidentiel.

De plus les connaissances confidentielles seront consultées par un groupe très restreint (un petit sous-ensemble de l'entreprise), et maintenues par un groupe encore plus réduit. Elles courent donc un fort risque d'obsolescence. Par contre les connaissances publiées seront consultées par bien plus de personnes, et seront plus vivantes, car elles pourront être maintenues, commentées voire critiquées ou réfutées par plus de gens. D'autre part vos connaissances publiées pourront être indexées par  les moteurs de recherche, et deviendront ainsi facilement accessibles pour... vos collègues ! Ainsi, en choisissant d'aider la communauté, nous nous aidons nous mêmes !

» Lire la suite!

Ce livre de Michael N. Kennedy a été publié en 2003, et a pour sous-titre "Why Toyota's System is Four Times More Productive and How you Can Implement It".

Je ne cherche pas à faire une critique du livre. Pour cela les commentaires sur amazon permettent de se faire une bonne idée. Je détaille simplement certains points qui m'ont frappé, par rapport à mon but de mieux comprendre les implications (notamment organisationnelles) d'une mise en place de Scrum.

Note : ce livre est écrit comme une nouvelle. Mais ne vous attendez pas à une intrigue romantique. C'est plutôt dans le style The Five Dysfunctions of a Team: A Leadership Fable, de Patrick Lencioni, à savoir une description assez vivante des réunions et discussions entre les membres d'une équipe de management. J'aime bien ce style qui permet de rentrer plus facilement dans un nouveau sujet, mais cela peut rendre l'assimilation des idées un peu plus difficile, et peut demander ensuite de compléter avec d'autres livres écrits de manière plus traditionnelle.

» Lire la suite!

Une bonne pratique qui est apparue très rapidement dans nos dojos de programmation est de bien nommer les tests. En effet, comme les dojos successifs sont séparés de plusieurs semaines, à chaque fois on redécouvre le code, et quand les tests sont mal nommés, nous sommes obligés de les relire entièrement pour les comprendre. En fait l'un des avantages des dojos est de simuler sur une courte période ce qui se passe dans la vie réelle : quand vous revenez sur votre code plusieurs mois ou années plus tard, vous avez parfois l'impression qu'il a été écrit par quelqu'un d'autre, non ?

Par conséquent les participants des dojos sont tous d'accord sur le fait qu'il faut bien nommer les tests. Rien de très surprenant, me direz-vous, c'est une bonne pratique bien connue. Par exemple dans Clean Code, le livre de l'oncle Bob dont j'ai parlé dans un billet précédent, il y a plusieurs points qui parlent du nommage correct. Le deuxième chapitre, écrit par Tim Ottinger, est même entièrement consacré à la question du nommage. Plus loin dans le livre, le chapitre "Tests propres" mentionne notamment :

» Lire la suite!

Discussion intéressante ce 11 février lors du troisième dojo du Club Agile Rhône Alpes : nous nous apprêtions à introduire des commentaires dans notre code de test quand un participant a fait remarquer qu'il préférerait voir ces mêmes informations sur la trace de sortie, afin de rendre les résultats de tests unitaires plus lisibles. Plusieurs solutions ont été discutées, et nous avons retenu la plus simple, à savoir inclure l'information en question directement dans le nom de la méthode de test.

Cela m'a fait prendre conscience à quel point un commentaire représente une information "morte" par rapport au code, "vivant" car exécuté. Et cela m'a remis en mémoire un chapitre du livre Clean Code: A Handbook of Agile Software Craftsmanship par Robert C. Martin (et d'autres auteurs comme Michael Feathers qui a écrit le chapitre "Error Handling"). En effet ce nouveau manuel de référence consacre pas moins de 21 pages à la question des commentaires dans le code (presqu'autant qu'au TDD !).

Comment bien commenter son code est un sujet assez sensible, sur lequel les développeurs et leurs managers sont enclins à s'enflammer facilement ! Personnellement je converge petit à petit vers l'opinion qu'il faut éviter les commentaires autant que possible, et Robert C. Martin explique cela très bien, aussi je traduis ci-dessous quelques extraits :

» Lire la suite!

Je viens de voir cette annonce de la dernière nouvelle de Clarke Ching, Rocks into Gold. Clarke Ching, souvenez-vous, j'ai parlé de lui à l'occasion de mon premier dojo agile où j'avais animé son exercice sur le task-switching, afin de sensibiliser les participants au coût élevé de cette façon de travailler.

J'aime assez ces auteurs qui présentent des sujets sérieux sous forme de romans. En fait c'est essentiellement Goldratt qui me vient à l'esprit, avec Le but : un processus de progrès permanent, Réussir n'est pas une question de chance, Critical Chain pour ceux que je connais, mais récemment j'ai découvert aussi The Gold Mine: A Novel of Lean Turnaround, par Freddy et Michel Balle (auteurs français, mais hélas leur livre n'existe qu'en anglais).

Rocks into Gold est une courte nouvelle, que vous pouvez acheter pour un prix modique, mais que vous pouvez aussi lire en ligne gratuitement, sous la forme de 238 (!) courts transparents (en anglais). La lecture prend de 20 à 40 minutes.

Si vous comptez la lire vous-même, ne lisez pas la suite de ce billet pour l'instant !

» Lire la suite!