Outils | Entreprise | Compte-rendus | Humeurs |   

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.

Lire la suite...

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.

Lire la suite...

1 juillet 2011

Agile France 2011 : Star Wars et Lean

AgileFranceConference2011-logo.jpgComme 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.

Lire la suite...

16 mars 2011

Donner des cadres

cadre.jpgQuand 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.

  1. Plan : recherche des causes racines possibles et planification
  2. Do : mettre en œuvre
  3. Check : vérifier que l'action résoud bien le problème
  4. 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.

Lire la suite...

14 janvier 2011

Relever chaque obstacle rencontré

liste.jpgDans 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.

Lire la suite...

- page 1 de 2