Je l’aime à mourir

Ecris le 28 décembre 2007
Dans la catégorie Web surf | Laissez un commentaire

Je prends des cours de guitare depuis quelques semaines et un ami m’a conseillé d’attaquer cette chanson bien adaptée pour les débutants. En cherchant sur le web, je suis tombé sur cette vidéo d’explication très bien faite.

Merci à l’auteur, Ashuan59.

Lettre au Père Noël

Ecris le 22 décembre 2007
Dans la catégorie Articles | Laissez un commentaire

En cette période de fin d’année, l’effervescence ambiante nous rappelle que nous avons tous à une époque fait nos lettres aux Pères Noël, même si avec l’age venant, nous avons peut être perdu l’habitude de prendre le temps de la faire.

Souvenez vous de l’état d’esprit dans lequel vous étiez :

  1. Commencer par savoir ce que l’on veut.
  2. Ecrire la lettre.
  3. La confier aux parents pour qu’ils l’envoient au Père Noël.
  4. Attendre le 25 décembre au matin pour obtenir ce que l’on voulait.

J’apprécie beaucoup cet exercice et il m’arrive souvent de le pratiquer avec les équipes dans lesquelles je travaille, dans une version allégée (nous nous passons des étapes 3 et 4)

La première partie est la plus intéressante. Le fait de retrouver l’état d’esprit neuf que nous avions lorsque nous étions enfant nous aide à oublier les contraintes que la vie d’adulte fait peser sur nos esprits. Nous avons ainsi l’opportunité de retrouver ce que nous voulons réellement, sans craindre les risques réels ou abstraits que nos vœux peuvent engendrer.

De manière étonnante, si nous sommes suffisamment convaincu de ce que nous voulons, il y a de bonne chance que nous l’obtenions.

« What you want is what you get »

Dessine moi un logiciel

Ecris le 11 décembre 2007
Dans la catégorie Articles | Laissez un commentaire

Choisissez un collègue informaticien, n’importe lequel, qu’il porte le titre de développeur, d’architecte, d’urbaniste ou de manager. Demandez-lui de dessiner une application informatique.

Il y a toutes les chances que le dessin qu’il vous fera sera constitué de boites, de flèches, et peut être de cylindres. Tous les livres, toutes les méthodologies d’architectures ou d’urbanisme reprennent ce même type de schéma. Certains en ont mêmes fait une science en tant que telle. Il existe autant de types de boite que d’applications. J’ai résumé pour vous ceux que je croise les plus souvent : base de données, écrans, couche service, framework techniques, socle d’échange, gestion des authentifications, référentiel, gestion des habilitations, mapping objet-relationnel, moteur de workflow, etc… etc…

Dés lors que nous avons fait ce constat, nous ne sommes plus surpris par la manière dont sont construites les applications dans la vaste majorité des cas. L’équipe, ou le manager, choisit une boite et commence à l’implémenter. Il commence par exemple par la base de données. Puis il passe à la suivante. Puis une autre. Jusqu’à ce que toute l’application ait été construite. Ce chemin de construction est parfois résumé dans un diagramme de Gantt.

Cette approche présente l’avantage d’être facile à comprendre, par tout le monde. Elle est facile à expliquer et donne le sentiment d’être facile à suivre, facile à piloter.

Elle présente aussi des inconvénients :

Si vous choisissez de suivre une approche agile pour la construction de votre application, vous aurez le choix de procéder autrement. Vous pourrez bénéficiez d’une caractéristique unique de la “matière” informatique : tout peut changer, tout le temps.

Ralph Johnson nous le rappel dans un article de Martin Fowler :

There is no theoretical reason that anything is hard to change about software.

Plus qu’un jeu d’éléments qui s’emboitent les uns dans les autres, je vois la construction de logiciel comme la création d’un tableau. L’artiste commence par une esquisse. Le sujet est posé et les grandes masses apparaissent. Mais les détails sont encore flous et la finition n’est pas idéale. Puis il rajoute de la peinture, il fait des mélanges pour voir ce que ca donne. Il revient parfois en arrière par endroit, pour mieux garder une harmonie d’ensemble. Petit à petit, le tableau devient de plus en net, plus précis. Jusqu’au moment où c’est terminé.

L’informatique vous offre la liberté de procéder de la même manière pour construire votre logiciel. Vous avez le choix de commencer par l’implémentation de plusieurs boites dés les premières itérations de votre projet. Vous aurez déjà un premier aperçu de votre application. Ce sera un embryon de ce que vous pourrez obtenir plus tard, mais vous pourrez déjà le montrer à vos clients et obtenir leurs feedback. Ils vous diront ce qu’ils aiment dans ce que vous avez déjà réalisé, ce qu’ils souhaitent que vous changiez et ce qui leur manquent. Tenez en compte pour la suite de votre projet.

Puis ajoutez, affinez, complétez votre application. D’itération en itération, votre vision deviendra plus précise et convergera vers le meilleur compromis possible compte tenu du temps impartis, du budget et ce qui apporte le plus de valeur à vos clients. La construction d’application peut être autre chose qu’un assemblage de briques d’un jeu d’enfant. Elle peut aussi être la création d’une image de plus en plus nette, que vous pourrez recadrer, retravailler tout au long de votre projet.

Ouverture des inscriptions aux Rencontres Agiles 2007

Ecris le 26 novembre 2007
Dans la catégorie Evénements, Annonces | Laissez un commentaire

Les inscriptions pour les Rencontres Agiles 2007 sont officiellement ouvertes. Nous avons une salle de 200 places que nous remplirons dans l’ordre d’arrivée des inscriptions.

Ne perdez pas de temps, inscrivez vous maintenant, c’est gratuit !

43 folders

Ecris le 22 novembre 2007
Dans la catégorie Articles | Laissez un commentaire

J’ai découvert la méthode Getting Things Done de David Allen grâce à la session qu’avait animée Bernard Vander Beken durant les XP Days Benelux 2006. Depuis un an, j’ai essayé plusieurs systèmes de gestion de mon 43 folder sans parvenir à trouver la solution qui me convienne.

J’ai commencé par chercher un système « in real life ». Un caisson à dossiers suspendus me paraissait trop encombrant et j’ai opté pour un classeur avec 43 onglets. Les documents sont bien classés mais cela est trop compliqué à gérer. Le simple fait de sortir le classeur me parait déjà une contrainte qui fait que je ne l’utilise pas. De plus, le classeur n’est pas transportable et je ne peux pas y accéder dés que je suis en dehors de mon bureau.

J’ai également testé des solutions électroniques. J’ai utilisé pendant plusieurs mois le wiki personnel ConnectedText. Ce petit logiciel est un vrai bijou qui dispose entre autre d’une API pour intégrer des scripts en Python. Un contributeur a développé un script pour GTD qui marche à merveille. Néanmoins, je restais frustré par la limite du logiciel. Il ne permet de gérer que des données au sein du wiki, avec éventuellement des liens web ou vers des fichiers. J’ai également tenté la gestion sous forme de dossiers dans Microsoft Outlook. Cela fonctionnait bien pour moi, mais là encore, j’étais limité aux documents gérés par Outlook, c’est-à-dire essentiellement des mails.

Ce n’est que récemment que j’ai eu l’idée de revenir à une solution d’une simplicité absolue : des dossiers stockés directement sur mon disque dur.

J’ai créé un répertoire 43folders contenant les 43 dossiers dont j’ai besoin. Dans chacun de ces dossiers, je stocke… tout !

Le résultat est redoutable d’efficacité. C’est ultra simple à mettre en œuvre, cela permet de gérer tous les types d’informations stockables sur un ordinateur, quelque soit leur source. Il est ultra simple de déplacer un élément d’un folder à un autre. J’ai des raccourcis sur mon bureau qui me permettent à tout moment d’aller directement sur mon 43folders et d’explorer les actions de la journée en cours.

Par exemple, j’ai ici pour la journée du 21 un article de blog sur 43folder à écrire, deux mails à traiter et un rappel pour rappeler quelqu’un représenté sous la forme d’un simple fichier texte dont le nom sert de marqueur TODO.

Il ne reste plus qu’à trouver l’assiduité nécessaires pour consulter ces folders et passer de l’intention à l’action ;-)

La technique du Pomodoro

Ecris le 19 novembre 2007
Dans la catégorie Articles | 2 commentaires

Matteo Vaccari et Frederico Gobbo ont présenté aux XP Days Benelux une session sur la technique du Pomodoro. Je n’ai pas assisté à cette session et j’ai demandé à des personnes qui avaient participé de me décrire ce qu’elles avaient retenu.

Cette technique consiste à découper le temps en tranches de 20 minutes. On utilise un minuteur de cuisine en forme de tomate (pomodoro en italien) pour mesurer ces périodes. Lorsqu’on se lance dans un pomodoro, on coupe toutes les distractions qui peuvent nous interrompre dans le pomodoro : téléphone, mail, IM, etc… L’objectif est de terminer le pomodoro sans avoir changé de contexte pour par exemple répondre à une question d’un collègue. A la fin d’un pomodoro, on arrête ce que l’on était en train de faire, et on se force à changer de contexte, en prenant une courte pause café, en lisant ses mails ou toute autre activité de ce genre.

Pour des taches qui dépassent les 20 minutes, il est conseillé de compter les pomodoro accomplis pour mesurer une vélocité et améliorer sa capacité à estimer le temps nécessaire pour terminer un travail.

J’ai testé cette technique et je la trouve très efficace pour augmenter ma concentration et m’aider à entrer dans un état de flow sur mon travail. Je trouve la durée de 20 minutes bien calibrée pour accomplir un résultat significatif en restant dans un rythme soutenable. Par ailleurs, le fait d’avoir le pomodoro qui tourne sur ma table aide les personnes autour de moi à savoir que je souhaite ne pas être interrompu dans mon travail, et cela diminue d’autant les sources de déconcentration.

Un article complet sur cette technique est disponible ici.

Les slides de la session de Matteo et Frederico sont .

XP Days Benelux 2007

Ecris le 19 novembre 2007
Dans la catégorie Evénements | Laissez un commentaire

J’aime les conférences agiles de la communauté agile Benelux, autant les Agile Open que les XP Days.

Je n’ai jamais été déçu par le niveau des sessions, et je reviens chaque année la tête pleine de nouvelle idées à mettre en œuvre à tire personnel, ou bien avec mes clients que j’aide à s’améliorer dans leur pratique de l’agilité.

Cette année, pour les XP Days Benelux, deux sessions orientées sur le code ont été pour moi exceptionnelles :

1) Un Dojo animé par Dave Nicolette et Rod Coffin.

Le Dojo inventé en France par Emanuel Gaillot et Laurent Bossavit est devenu un grand classique des conférences agiles. Pour ces XP Days, ce sont Dave et Rod qui s’y sont collé et nous ont proposé un randori à la fois très structuré et très riche.

Ils ont commencé par rappeler le cycle de développement de TDD, puis ils ont distribués aux participants deux feuilles présentant une liste de stories élémentaires à implémenter en groupe. Nous avons ensuite consacré l’essentiel de la séance à coder en Java avec Eclipse. Le dernier tiers de la session a été consacré à une discussion en format fishbowl.

Cette session m’a apporté les idées suivantes que je compte bien mettre en pratique le plus tôt possible :

2) Une analyse des tests animée par Steeve Freeman et Nat Pryce.

Steve Freeman

Steve et Nat ont eu l’idée géniale de concevoir cette session pour nous donner l’opportunité de comprendre les tests écris en TDD pour eux-mêmes, de manière indépendante du code pour lequel ils ont été conçus. Les participants sont amenés à essayer de reconstruire le code à partir uniquement des tests, sans aucune autre forme de spécification.

La session amène un éclairage tout particulier aux tests, au design objet, et à la manière dont ils peuvent être conçus pour rendre le code plus lisible, plus efficace et plus maintenable.

C’est un exercice excessivement efficace pour améliorer le design du code. Cela me donne une envie irrésistible de reproduire le même exercice avec des tests que j’aurais produis moi-même, ou bien avec ceux des projets auxquels je participe.

Faites l’exercice vous-même : choisissez une application autour de vous, dont le code a été écris en TDD. Prenez les tests, sans le code, et essayez de reconstruire le code. Commentez ce que vous avez découvert avec ceux qui ont écrit le code original.

(Photos par Lasse Koskela)

Revival

Ecris le 18 novembre 2007
Dans la catégorie Annonces | Laissez un commentaire

J’ai laissé mon blog en veille depuis plus d’un an déjà et il est tend de reprendre les activités éditoriales. Je me suis beaucoup exprimé en langue anglaise et je vais désormais d’avantage poster en Français.

L’actualité des semaines à venir concerne deux conférences auxquelles j’apporte ma contribution : la Smalltalk Party édition 2007 et les Rencontres de l’Agile 2007.

Je posterai ici, entre autres, les informations concernant ces deux évènements.

Keep your RSS reader tuned !

XP Days France 2006

Ecris le 20 mars 2006
Dans la catégorie Evénements | Un commentaire

La conférence sur l’agilité en France, c’est cette semaine !

Les premiers XP Days de France se tiendront les 23 et 24 mars : il ne vous reste pas beaucoup de temps pour vous inscrire, d’autant plus que je crois savoir que la conférence aura lieu à guichet fermé.Pour ma part, j’animerai une session sur la construction incrémentale. J’espère avoir l’occasion de vous y croiser ;-).

Plus d’information ici : http://www.xpday.fr/

TDD as a piece of cake

Ecris le 17 mars 2006
Dans la catégorie Web surf | Laissez un commentaire

TDD is a hard thing to understand when you never practiced it. You have to practice it yourself to feel the real power of this little green bar on your project, and more importantly, on your mind. Taking the difficulty upfront, Emmanuel Gaillot did a very nice job of explaining TDD to his baker.

If you are new to XP and want to understand this strange practice of writing test before code, please go and read it !

keep looking »