L'inventaire, c'est du gaspillage

Publié par Louis-Philippe Carignan le lundi 13 janvier 2014 à 16:18

« In manufacturing, inventory is waste. »

Première phrase à la page 24
« Implementing Lean Software Development »
Mary et Tom Poppendick

Un peu plus bas dans cette page, les auteurs transposent ce concept en développement logiciel.

« The inventory of software development is partially done work. » 

Ok. Facile. En Agile/Lean, l’une des façons de minimiser le gaspillage est de compléter ce que l’on a commencé. Plus loin, aux pages 74 et 75 du même livre, les auteurs énumèrent ce qu’est le travail incomplet :

  • Documentation/requis qui n’est pas codé
  • Code désynchronisé
  • Code non testé
  • Code non documenté
  • Code non déployé

Pour moi, je transpose encore davantage ce concept dans ma liste de tâches professionnelles (ma todo liste). Je tiens donc ma liste de choses à faire très courte. Tout comme on ne veut pas avoir une longue liste de requis auquel on ne réussira jamais à faire au grand complet, je ne garderai jamais une longue liste de choses à faire puisque je sais très bien que je ne réussirai jamais à tout faire et que, d’ailleurs, de nouvelles tâches s’ajouteront à ma liste.

Ceci étant dit, j’étais quand même curieux d’avoir une deuxième opinion sur la question pour voir si ma réflexion était la bonne. Après tout, si je prône les valeurs Agile/Lean, je préfère prêcher par l'exemple.

Personal Kanban

Jim Benson a lancé le site personalkanban.com en 2009 où il explique comment il a transféré les principes industriels du Kanban pour visualiser et contrôler son travail personnel.

Dans son billet « Building your first personal Kanban », Jim explique comment monter son système Kanban :

  • Établir sa carte de valeur (value-stream)
  • Établir son backlog
  • Établir la limite du travail en cours (TEC)
  • Commencer à tirer sur les items du backlog

Puisque ma liste de tâches professionnelles s’exécute sous ce même principe, je lui ai donc écrit sur Twitter pour avoir son opinion à propos de la taille du backlog que l'on monte à l'étape 2.

Voici donc les réponses qu’il m’a données :

Conversation Jim Benson 

J’ai aimé ses réponses.  Lorsqu’il mentionne dans sa réponse du haut qu’un gros backlog est un signe que j’ai plus de « Work In Progress (WIP) » que je ne le croyais, c’est un signe de réviser ma limite WIP. Si ma limite WIP est très élevée, je me retrouve avec beaucoup de travail incomplet. Et puisque du travail incomplet est du gaspillage, je dois m’efforcer d’identifier ce qui ne sera jamais fait et m'en débarasser. 

Plus particulièrement, les questions suivantes dans la conversation Twitter m’ont aidé à identifier la taille du backlog :

  • What is your personal kanban goal?
  • What work is valuable there?

Dans le cas de la première question, l’objectif de mon Kanban professionnel est de réaliser les tâches avec le plus de valeur en premier.

Pour répondre à sa deuxième question, je valorise seulement le travail auquel je crois pouvoir m’attaquer rapidement (disons moins de 2 semaines). Le travail que je ne crois pas réaliser dans ce laps de temps est périssable. Quelque chose de nouveau sera plus important. 

Et votre liste de tâches professionnels?

Et qu'en est-il de votre liste de tâches? Si vous faîtes la promotion des valeurs Agile/Lean dans votre milieu de travail, est-ce que l'organisation de votre travail professionnel est elle aussi Lean?  

 

Mots-Clés :
blog comments powered by Disqus

0 Comments:

Post a comment

Comments have been closed for this post.