Developer's notebook

L'institut Lean organise régulièrement des séminaires autour du Lean. Certains sont gratuites, comme la 14e du Lean en France le 16 décembre, d'autres payantes durent toute la journée, comme le 7 décembre avec Michael Ballé. Je vous conseille vivement d'y assister si vous en avez l'occasion !

Ce billet évoque quelques éléments de la sixième séance du séminaire "Lean et Système d'information" :

• "Mise en flux continu des incidents informatiques" par Catherine Chabiron, Lean Office and IT Governance, Faurecia ;
• "Le Lean dans la maintenance du système d'information" par Régis Médina, Operae Partners

Originellement développé par Vera Peeters and Rik Tytgat, ShUnit a été le premier outil de tests unitaires en shell.

Il permet de valider que vos scripts shell effectuent bien ce que vous en attendez. Intégrez vos tests shunit à votre usine de développement et vous serez assurés qu'ils resteront valides de façon permanente, qu'ils ne souffriront d'aucune régression sans vous en alerter.

Je vous propose de me suivre sur les traces d'un framework un peu plus xUnit like : ShUnit2 de Kate Ward.

J'ai trop longtemps mis à jour des métriques à la main pour en avoir une image positive. Ces derniers temps, je me suis pourtant surprise à en apprécier quelques unes. Je vais vous raconter comment certaines ont réussi à trouver (un peu) grâce à mes yeux, en particulier le burn down chart. Mais avant d'y venir, faisons un tour d'horizon sur quelques défauts des métriques.

Les métriques mentent

La métrique peut être tout à fait pertinente au départ, et dans les faits refleter quelque chose de complètement faux. Nous considérons par exemple qu'une MEP réussie n'a pas de rollback et n'a pas eu d'incidents pendant son déroulement.

Après avoir raté l'atelier de Portia "Apprenez les techniques de coaching avec le magicien d'Oz" à l'Agile France, je m'étais dit que c'était trop bête d'attendre les passages des fairytalers en France pour découvrir leurs jeux. J'avais vraiment beaucoup aimé le jeu de Blanche Neige. Non  […]

"Si une réunion ne vous apporte plus de valeur et que vous n'y apportez rien non plus, vous devriez avoir la possibilité de simplement sortir, avec un signe convenu par exemple." (Entendu aux XPDays 2009).

Comme beaucoup, j'ai participé à des réunions "inutiles" où je faisais acte de présence. C'est moins fréquent en environnement agile, avec le ROTI (un note de 1 à 5 de la réunion) qui permet de donner un indice sur la valeur apportée. Autant dans le principe, une réunion peut être utile, sur place sa valeur peut dégringoler : les conversations peuvent tourner en rond, le sujet a dévié et ne concerne plus que quelques personnes (les chefs), etc.

J'ai déjeuné chez ma grand-mère dernièrement, et ma mère avait préparé sa spécialité. Miam en perspective?

Hélas non. C'était trop salé par endroit, des morceaux étaient trop durs et les nouilles trop molles. Tout en mangeant un petit plus lentement que d'habitude, je me demandais pourquoi : est-ce que j'étais devenue plus exigeante ? Est-ce que parce que ma mère préparait ce plat souvent, il était devenu inévitable que je tombe de temps en temps sur un échec ? Est-ce qu'elle l'avait baclé car elle était pressée? Est ce que le pot de sel s'est renversé ? Bizarrement, ce jour là, je ne me suis pas resservie.

Quelques jours plus tard, j'ai appris qu'au moment de la préparation, ma grand-mère était derrière elle à lui donner des instructions, pour corriger son plat. Ca l'avait complètement perturbé. Le mélange des deux façons de faire, où ma mère a plus "obéi" aux ordres plutôt qu'écouter son instinct habituel avait été à l'origine de ce plat extra-terrestre.

Cette année, le programme d'Agile France affichait le nombre de places maximum par session. Vingt-cinq places pour l'atelier d'Esther Derby, auteur éminent de Agile Retrospectives et Behind Closed Doors et membre fondateur de la Scrum Alliance, c'est peu. Je me suis donc précipitée à l'atelier "Lifting the veil : how visible and invisible structures drive organisational behavior". Je ne l'ai pas regretté.

... déjà en ligne ! Si vous faites partie des 20 personnes qui ont du quitter la salle faute de place, vous pouvez vous consoler avec le billet qu'Esther Derby a mis en ligne, avec une photo de l'atelier. Vous verrez que vous pouvez changer les choses avec une approche systémique. Je ferai un retour  […]

It all began when I wanted to have feedbacks on agile tools. By "agile tool", I mean more backlog management than continuous integration. Forums are full of information but they are messy, so I created a survey on my blog. I am very greatful to all the people who took part of it : many thanks to the 204 voters !

But

Soon enough, some limits appeared :

1. Voting is easy. A company can easily send an email to its customers to ask them to vote. This is not really a problem, but it may not reflect the reality (what about the company who aren't aware of the survey or just don't care) ?.
2. Someone asked me what to do when you were using several tools... (There was only one possible choice in the survey).
3. The meaningless option "Other" was getting bigger and bigger, despite my efforts to be exhaustive. I finally created a post to invite people to tell me when the option was not available, but I guess it was too late and / or not convenient enough
4. A widespread tool does necessarily fit your needs. X may be perfect for a distributed team in a multinational but not for my open source project. Surveys make valuable information disappear.
5. Drawbacks are also missing. We don't know when a tool has been dropped and why.

Nous tiendrons deux sessions à l'agile conférence (ex-XPDays) les 31 Mai et 1er Juin : un atelier fun et une conférence geek. Survivre sur la lune avec la NASA ou l’importance de travailler en groupe L'idée de l'atelier est de démontrer que pour résoudre un problème, 1111 est bien plus fort que  […]