Tag: SAFe

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.

Comment prioriser son Product Backlog à l’aide du WSJF ?

WSJF ? Qu’est ce que c’est ? Encore un acronyme de plus dans notre vocabulaire. J’ai découvert cette technique dans le Framework SAFe. WSJF veut tout simplement dire « Weighted Shortest Job First » ou en français « la plus importante ou la plus courte fonctionnalité d’abord ! ». Organiser ou prioriser le Product Backlog est souvent un casse tête pour le Product Owner. Sur des projets complexes avec beaucoup de fonctionnalités, il est parfois très chronophage de faire l’exercice de raffiner son Product Backlog de manière efficace. Cet outil pourra nous y aide. Je vois plutôt le WSJF comme un outil plutôt qu’un indicateur. Il permet de déterminer un chiffre représentant le bon compromis entre la valeur qu’apportera la fonctionnalité si on la livre et le temps que l’on prendra à la développer.

D’où vient le WSJF ?

SAFe part du principe que toute fonctionnalité non livrée à temps à un coût : The Cost of Delay. Dans la philosophie de Lean, l’objectif est donc de réduire ce coût au minimum pour augmenter notre efficacité et livrer le maximum de valeur à l’issue d’un Sprint. Prenons quelques exemples simples. Imaginons que nous avons deux fonctionnalité à développer. Elle ont la même valeur métier mais l’une d’entre elle est plus courte à développer. Le product Owner priorisera sans aucun doute la plus courte. Par contre, si l’une des fonctionnalité prends moins de temps à développer mais est aussi moins prioritaire, il est difficile de la prioriser dans le Product Backlog. Le Product Owner devra trouver le bon compromis. L’idée du WSJF est de lui fournir un outil factuel permettant de l’aider dans cette tâche!

Comment se calcul-t-il ?

Le calcul du WSJF prends en compte les critères suivants. On utilisera pour tous ces indicateurs une notation suivant une suite de Fibonacci par ordre croissant:
– User-Business Value : la valeur métier de la fonctionnalité.
– Time Criticality : détermine si la fonctionnalité doit être livré rapidement ou non.
– Risk Reduction or Opportunity Enablement: Détermine si cette fonctionalité réduit le risque ou facilite le développement d’autres fonctionalités par la suite
– Job Size : Taille de la fonctionnalité à développer. On parle aussi d’effort. Cette valeur peut être estimée par l’équipe de développement.

Calcul du « Cost of Delay »

Cost of Delay = User-Business Value + Time Criticality + Risk Reduction and/or Oppty Enablement
WSJF = Cost of Delay / Job Size

Plus le WSJF a une valeur importante, plus la fonctionnalité pourra être priorisée. On voit ici que dans cette formule, nous prenons en compte à la fois la valeur métier mais aussi la contrainte de temps et la réduction du risque. Le facteur ayant le plus de poids sur la formule est donc la taille ou l’effort.
Cela met en évidence plusieurs chose. D’une part plus les Features sont petites, plus elles sont faciles à estimer et à ordonnancer les unes par rapport aux autres. On parle en général de MMF (Minimum Marketable Feature). D’autre part, ce n’est pas parce qu’une fonctionnalité semble importante qu’elle doit être priorisée. Il faudra prendre en compte l’impact si celle-ci n’est pas développée à court terme. Dernier point, ce calcul n’est pas figé dans le temps. L’ensemble des facteurs pourra être revu au fil des sessions de Product Backlog Refinement.

En conclusion, le WSJF est un outil relativement puissant permettant une bonne priorisation du Product Backlog en entrée de chaque Sprint. Il fera aussi gagner beaucoup de temps à la Scrum Team dans les sessions de Product Backlog Refinement où l’équipe pourra se focaliser sur les fonctionnalités les plus cruciales.

Pour aller plus loin:

http://www.scaledagileframework.com/wsjf/