Month: avril 2018

Comprendre la loi de Little

L’un des principaux objectifs de Lean est de diminuer le Lead Time c’est à dire le temps de latence entre la prise en charge d’une tâche et son execution totale. Si l’on suit une stratégie Lean, diminuer ce lead time permettra d’un part d’augmenter notre capacité à produire mais aussi d’augmenter notre niveau de prédictibilité. La première façon de diminuer le Lead Time est de réduire la taille des tâches (batch size), la seconde est de comprendre la loi de Little :

Comprendre la loi de Little

Pour l’historique, cette loi fut trouvée par John Little dans les années 60. Son principe est simple : le nombre de clients dans une file d’attente (l) est égale au taux d’arrivée moyen des clients (λ) multiplié par le temps de traitement (ω).

l = λω

En résumé, si je prends l’exemple d’une caisse de supermarché, si j’ai 3 clients par minutes qui arrivent à la caisse et que le traitement d’un client prends 2 minutes, le temps d’attente moyen d’un client est de 6 minutes.

Voici un très bon article sur la loi de Little et les processus Stochastiques. Si vous voulez vous remettre au maths, cela ne fait pas de mal :).

Et Lean dans tout ça ?

Dans une équipe Agile, le lead time est déterminé à partir du moment où l’implémentation d’une fonctionnalité est prise en charge par l’équipe de développement. Il s’en suit l’implémentation, les tests et le déploiement pour que celle ci soit totalement finalisée.

Imaginons une équipe qui délivre 10 fonctionnalités (Features) tous les 3 mois. Si l’équipe prends en charge 20 fonctionnalités en même temps, il lui faudra probablement au moins 6 mois afin de finaliser les fonctionnalités associées. Le temps d’attente moyen (Lead Time) sera donc de 6 mois quelle que soit la fonctionnalité à développer.

Limiter le WIP

Le WIP ou Work-In-Process/Progress est le nombre de tâches exécutées en parallèle par une équipe de développement. Sur un Kanban, on cherchera à mesurer ce WIP et à le limiter. En effet, limiter le nombre de tâches à traiter en parallèle est clé si l’on veut conserver un bon niveau de productivité sans mettre à mal la qualité.

Revenons à notre équipe agile, si je cherche à limiter mon Lead time, je peux jouer sur deux facteurs :

  1. Le niveau de productivité de l’équipe. Sa vélocitié de façon à ce qu’elle délivre plus de fonctionnalités en une itération donnée
  2. Le nombre de fonctionnalités sur lesquelles l’équipe travaille

Chercher à augmenter la vélocité d’une équipe agile n’est clairement pas l’option la plus satisfaisante (voir mon article précédent). Nous allons donc facilement pouvoir jouer sur le nombre de fonctionnalités dans la file d’attente.

Exemple:

  • L’équipe délivre 10 fonctionnalités tous les 3 mois
  • L’équipe travaille sur 8 fonctionnalités

Par conséquent, le temps de traitement (Lead Time) moyen sera de 2,4 mois. Il a donc de forte chances que l’équipe arrive à délivrer à l’issue de cette itération de 3 mois avec un bon niveau de confiance.

En résumé

En résumé, la loi de Little met en évidence que plus le travail en cours (WIP) est limité, meilleur est le Lead Time et notre capacité à produire.

Scrum – The Art of Doing Twice the Work in Half the Time

C’est sans doute un des titres les plus long de la littérature mais il correspond tellement bien à ce livre ! Jeff Sutherland est le co-rédacteur du Scrum Guide avec Ken Schwaber. Ensemble, ils ont créé Scrum, un Framwork Agile simple et léger permettant de développer des projets ou  produits complexes.

Jeff nous emporte dans la génèse du Framework Scrum où il expirimenta ses premières versions dans les années 80. De par ses expériences, il a pu démontrer que lorsqu’une équipe  s’auto organise et évolue de manière itérative autour d’un objectif commun, les résultats obtenus sont souvent de bien meilleure qualité qu’une équipe executant les ordres d’un suppérieur hierarchique. Cette approche permet de construire des produits ou des projets complexes, en capitalisant sur l’expérience et le professionalisme de l’équipe de développement. Vous découvirez que l’ensemble du Scrum Guide peut s’appliquer à de nombreux contextes.

Je vous conseille ce livre si vous souhaitez en savoir plus sur la génèse du Framework Scrum et sur la vie d’un de ses inventeurs.

Bonne lecture !