Mot-clé - lean - Developer's notebook

mercredi 4 décembre 2013

Aller plus vite

Je n'aime pas me presser au moment de partir de chez moi. Quand je le fais, je dois souvent revenir quelques minutes plus tard parce que j'ai oublié quelque chose. Se dépêcher donne l'impression d'avancer, mais tout ce qu'il génère, c'est du rework. En développement logiciel, les reworks sont des corrections de bug.

L'inverse n'est pas garanti : ce n'est pas ce qu'on prend son temps que le résultat sera parfait.

Si on demande aux clients de l'IT quel est leur plus gros problème, la réponse fera partie de cette liste :

il y a trop de bugs
les délais de réalisation sont trop longs (souci le plus fréquent)

Mon job, c'est de faire que le produit livré ait une bonne qualité dans les délais impartis. Je ne veux pas en sacrifier un pour l'autre.

mardi 22 janvier 2013

Un tableau brulant

Un scrum master de mon entreprise a commandé des magnets personnalisés super fun pour rendre les risques et les urgences encore plus visibles.

Je trouve le principe des aimants mieux que des bouts de post-its découpés, qui finissent par se fondre dans la masse des post-its. J'en profiterai pour vous parler d'autres bombes utilisées sur nos murs.

vendredi 1 juillet 2011

Agile France 2011 : Star Wars et Lean

Comme chaque année, la conférence Agile France a rassemblé plusieurs centaines de personnes au Chalet de la Porte Jaune pour des conférences agiles à gogo. Bizarrement, le tout premier séminaire Java français avait lieu en même temps... Très bizarre de la part de Zenika d'ailleurs, pourtant sponsor il y a deux ans de la conf agile. D'autant plus que l'organisation d'Agile France est constitué de bénévoles et les speakers non plus ne sont pas payés.

Plus de retrouvailles et de rencontres que de conférences pour moi, mais quelques unes ont été particulièrement sympathiques. Je vous propose un premier billet sur StarWars et le Lean dans l'informatique.

mercredi 16 mars 2011

Donner des cadres

Quand nous avons un problème, nous cherchons une action qui permettra de le résoudre. Passer par un processus de Plan Do Act Check (PDCA) permet de vérifier que ladite solution est efficace.

Plan : recherche des causes racines possibles et planification
Do : mettre en œuvre
Check : vérifier que l'action résoud bien le problème
Act : Agir, ajuster, réagir (si on a testé à l'étape Do, on déploie lors de la phase Act). En cas d'échec, le processus continue sur le test d'une autre solution. Autrement, la pratique devient un standard et le processus peut se poursuivre sur la résolution d'un autre problème.

Le fait d'en faire un standard a beaucoup d'avantages mais aussi des limites. De temps en temps, une solution convient à un instant T, avec un certain contexte projet (client/équipe) et ne plus du tout être valide quelques mois après. Sans parler du fait qu'il faut du courage pour bousculer ce standard. Résultat : l'équipe se retrouve à maintenir une habitude qui ne lui apporte plus de valeur mais que l'on ne pense pas / ose pas contester. Nous nous retrouvons paradoxalement dans une situation anti-agile. Rajouter des standards se fait plus facilement qu'en supprimer.

vendredi 14 janvier 2011

Relever chaque obstacle rencontré

Dans le cadre d'une démarche Lean, certains membres de l'équipe avaient voulu se lancer dans la mise en évidence de nos problèmes. L'idée était de pouvoir tracer un diagramme de Pareto et de régler les problèmes les plus importants.

La théorie est belle mais la réalité plus compliquée. En premier lieu, il faut se rendre compte que l'on rencontre un obstacle, puis s'arrêter pour le formaliser et l'écrire. Ensuite seulement, je peux reprendre le cours normal et tenter d'y rémédier. La première fois, on est à peu pres attentif, mais au jour le jour, on oublie facilement ce listing non naturel. A la fin, les données doivent être classées et analysées afin de dégager des tendances.

Clairement, j'avais beau vouloir tenter l'expérience, cette dernière coupait totalement mon flow. De plus, toute l'équipe n'était pas convaincue de l'intérêt de la chose. Quelques temps après, Régis nous a fait remarquer que ce n'était pas une condition nécessaire. Nous nous sommes dits que nous n'étions peut être pas si motivés pour le faire, que révéler un obstacle était peut être inconsciemment perçu comme une mauvaise chose, un aveu d'échec. Il fallait renverser ce sentiment.

Avec un collègue alors présent, nous avons donc fait une deuxième tentative : pendant trois semaines, nous noterions chacun nos obstacles et celui qui en aurait le plus gagnerait une boite de chocolats. Voici les résultats.

dimanche 5 décembre 2010

Retour sur le 6e séminaire Lean & SI

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

samedi 4 septembre 2010

Quand une métrique devient utile

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.