eric.lemerdy

Aller au contenu | Aller au menu | Aller à la recherche

mercredi 13 mai 2009

Présentation du Lean Software Developement

Je vais parler aux XP Day !

XP Day bag 1 (c'est le sac de l'année dernière)
1 2 3
  1. Ne pas négliger la théorie
  2. S'entraîner en s'écoutant pour se corriger
  3. Prendre des forces (5 fruits et légumes par jour, c'est un objectif dur à atteindre !)
La théorie permet d'être à l'aise avec les fondements de ce que l'on vit sur nos projets.
En s'écoutant, on apprend à se placer du côté de l'auditoire. Je cherche à me poser les questions en tant que public de la présentation : quels sont mes attentes et serais-je déçu si j'y assistais ? Mais la voix n'est pas le vecteur primordial pour faire passer l'information. L'attitude, le ton, la présence comptent aussi beaucoup.
Il est aussi important d'avoir une idée claire des messages que l'on souhaite faire passer. Ensuite, le mieux est de trouver une histoire à raconter pour faire passer le tout de façon agréable. Ce qui me plaît dans une présentation, ce sont les accroches, et lorsque les exemples résonnent dans mon expérience actuelle et passée. J'utilise donc des cartes pour répéter sur lesquelles j'inscris le message important du slide et les accroches et les transitions dans une autre couleur.
Tentons de faire tout ça pour le 26 mai !

jeudi 12 février 2009

Productivité: faire son Hansei

"Je trouve que je passe trop de temps au travail."

Cette phrase exprime un ressenti sur une situation dangereuse.
Que faire pour améliorer cet état ? Et en premier lieu quel est cet état ?!?
Le bon sens cartésien veut que l'on ne puisse mesurer une amélioration que de ce que l'on peut préalablement quantifier.
Partant de ce constat, j'ai décidé de tenter une petite expérience cette semaine: mesurer mon temps de travail.

Ne disposant pas d'un outil aussi interactif que Talia (Pyxis en parle), je me suis monté un google document tableur pour reporter mon activité: Effective working time
(Les valeurs sont en décimales d'heures)
Tous les jours, je remplis le nombre d'heures de travail

  • total de la journée (hors pause déjeuner)
  • de 'dev' on peut traduire par travail productif (slides, docs, etc.)
  • de 'support', les questions des utilisateurs, le support aux autres développeurs
  • de 'other', web surfing, checkage de mail clientèle, pro et perso, lecture de docs et... autre quoi
Le reste est calculé tout seul par différence. C'est ce qui n'est pas comptabilisé (pause toilettes (!), oubli du chrono, etc.).

Le chrono, justement, pièce maîtresse dans mon expérimentation. Je suis infidèle à la philosophie agile ou lean du 'physical communication'. Et non, je n'ai pas trois chronos qui trônent sur mon bureau. A la place, c'est un 'google gadget' sur mon bureau virtuel qui compte le temps qui passe. C'est le bien-nommé : Task List and Timer Timer task_and_timer.png

Bilan après une semaine:

  • L'interface du timer n'est pas très jolie. Encore un développeur qui essaye de faire une interface... Pourquoi diable a-t-il voulu créer sa propre scrollbar ? En regardant comment est fait un google gadget, j'ai compris mais au moins, il aurait pu prendre un style d'ascenseur plus joli.
  • A l'usage, c'est assez lourd de déclencher les chronos au changement d'activité. Un déclenchement à la voix serait sympa, ou alors une IA qui infère l'activité en fonction des logiciels en action sur le poste... C'est possible mais pas dispo. sur google gadget...
  • Ce qui n'apparaît pas justement est le nombre de "changements de contexte" qui est une cause classique de perte de productivité.
  • La tentation de l'isolation est donc importante pour augmenter facilement la productivité
  • L'irrégularité de la journée de travail dénote un emploi du temps assez torturé cette semaine...
  • Prise de conscience sur la répartition réelle des activités quotidiennes
  • Le côté motivant : voir la courbe de l'activité productive qui monte est assez stimulant.
  • Qu'est-ce-qui est fait pendant la journée de travail qui pourrait être éliminé sans conséquences ?

Je pense prolonger encore un peu le monitoring pour tirer d'autres leçons de ces données puis recommencer le mois prochain. Je n'ai pas encore terminé mon "Hansei" (auto-critique, réflexion).
En tous cas, j'encourage quiconque souffrant du temps qui passe trop vite de mener à son tour ce genre d'expérience adapté à son contexte. En effet, le lean nous apprend qu'il n'y a pas de métrique magique qui va illuminer tout seul les gains de productivité à faire. Par la suite, pourquoi ne pas partager les retours en "Hansei Kai" (réunion d'auto-critique) ?
(Ces termes japonnais sont issus de la pensée lean [ppt])

mercredi 28 mai 2008

Travaillez-vous mieux sous pression ?

La pression exercée sur une équipe permet parfois de la stimuler ou de garder un bon niveau de motivation. Mais quand cette pression devient trop grande, la contre-productivité augmente... Voici un graphique issu de la pensée "lean" qui m'est apparu très clair lorsque Bent Jensen nous l'a exposé il y a quelques semaines.
agile_team_pressurepressure.png(src)
Ce que je remarque surtout, ce sont les gaspillages engendrés par des délais de livraison trop long. La pression en début de phase est insuffisante, on risque de pas assez bien utiliser un temps pourtant précieux. Avec des livraisons plus rapprochées, on conserve une pression quasi constante proche d'un niveau toujours acceptable.
Je pense qu'avec des arguments simples mais percutants comme celui-ci, on peut débattre sans choquer avec son équipe trop habituée au rythme "industriel à la française".