Weighted Shortest Job First (WSJF)

Si vous ne quantifiez qu’une chose, quantifiez le coût du délai.

—Don Reinertsen

Le Weighted Shortest Job First (WSJF) est un modèle de hiérarchisation utilisé pour séquencer les travaux (par exemple, les Features, les Capabilities et les Epics) afin de générer un bénéfice économique maximal. Dans SAFe, le WSJF est estimé en divisant le Cost of Delay (CoD) par la taille de la tâche.

Les Agile Release Trains (ART) fournissent un flux de travail continu qui constitue l’effort de développement supplémentaire de l’entreprise. Il évite les frais généraux et les retards causés par la nature de démarrage, d’arrêt, de démarrage des projets traditionnels, où les autorisations et les portes de phase contrôlent le programme et ses aspects économiques.

Bien que ce modèle de flux continu accélère la création de valeur et maintienne le système, les priorités doivent être mises à jour en permanence pour fournir les meilleurs résultats économiques. Dans un système basé sur les flux, le séquencement des tâches, plutôt que la théorie, le retour sur investissement des tâches individuelles, produit le meilleur résultat. À cette fin, WSJF est utilisé pour prioriser les backlogs en calculant la valeur relative de la charge et la taille de la tâche (un proxy pour la durée). L’utilisation de WSJF dans le Program Increment limites met à jour en permanence les priorités des backlogs en fonction de la valeur utilisateur et métier, des facteurs temporels, des risques, de la création d’opportunités et des efforts fournis. WSJF ignore également, de manière pratique et automatique, les coûts irrécupérables, principe fondamental de l’économie Lean.

Détails

Reinertsen décrit un modèle complet, appelé Weighted Shortest Job First (WSJF), permettant de hiérarchiser les travaux en fonction de la rentabilité du développement de produits [2]. Calculez WSJF en divisant le CoD par la durée. Les travaux qui peuvent offrir le plus de valeur (ou CoD) et qui ont la longueur la plus courte sont sélectionnés en premier pour la mise en œuvre. Lorsqu’il est appliqué dans SAFe, le modèle prend en charge certains principes supplémentaires du flux de développement de produit, notamment:

• Prendre un point de vue économique
• Ignorer les coûts irrécupérables
• Faire des choix financiers en continu
• Utilisation de règles de décision pour décentraliser la prise de décision et le contrôle
• Si vous ne quantifiez qu’une chose, quantifiez le coût du retard

La Figure 1 montre l’impact d’une application correcte de WSJF (voir [2] pour une discussion complète).

Figure 1. L’application de l’algorithme WSJF offre les meilleures performances économiques globales

Les zones ombrées en bleu illustrent le total de la dette dans chaque cas. Faire le travail pondéré le plus court en premier offre les meilleures économies.

Calcul du Cost of Delay

Dans SAFe, nos tâches sont des Epics, les features et les capabilities que nous développons. Nous devons donc établir à la fois le Cost of Delay et sa durée. Trois éléments principaux contribuent au coût du retard:

• User-business value – Nos utilisateurs préfèrent-ils cela à cela? Quel est l’impact des revenus sur notre entreprise? Existe-t-il une pénalité ou d’autres conséquences négatives si nous tardons?
• Time criticality – Comment la valeur utilisateur / entreprise décroît-elle dans le temps? Y a-t-il une échéance fixe? Vont-ils nous attendre ou passer à une autre solution? Y a t-il des Milestones sur le chemin critique impacté par cela?
• Risk reduction-opportunity enablement value – Qu’est-ce que cela fait d’autre pour notre entreprise? Cela réduit-il le risque de cette livraison ou d’une livraison future? Les informations que nous recevrons sont-elles utiles? Cette fonctionnalité ouvrira-t-elle de nouvelles opportunités commerciales?

De plus, étant donné que nous sommes dans un flux continu et que nous devrions avoir un backlog suffisant, nous n’avons pas à nous soucier des chiffres absolus. Nous pouvons simplement comparer les éléments de backlog les uns par rapport aux autres en utilisant les nombres de Fibonacci modifiés que nous utilisons dans «l’estimation du poker». Le CoD relatif est ensuite calculé comme suit:

Figure 2. CoD relatif

Durée

Ensuite, nous devons comprendre la durée du travail. Cela peut être assez difficile à déterminer, surtout au début, quand nous ne savons peut-être pas qui va faire le travail ou l’allocation de capacité pour les équipes. Heureusement, nous avons un proxy prêt: la taille du travail. Dans les systèmes à ressources fixes, la taille du travail est un bon proxy pour la durée. (Si je suis le seul à tondre ma pelouse et que la cour avant est trois fois plus grande que la cour arrière, cela prendra trois fois plus de temps.) Nous savons également comment estimer la taille de l’élément en Story points (voir Features). Comme le montre la figure 3, nous disposons d’un calcul relativement simple pour comparer les travaux via WSJF.

Figure 3. Une formule pour WSJF

Ensuite, par exemple, nous pouvons créer un tableau simple pour comparer les travaux (trois travaux dans ce cas), comme illustré à la figure 4.

Figure 4. Exemple de feuille de calcul pour le calcul de WSJF

Pour utiliser le tableau de la figure 4, l’équipe évalue chaque Feature par rapport à d’autres pour chacun des trois paramètres. (Remarque: avec l’estimation relative, vous examinez une colonne à la fois, définissez le plus petit élément sur «un», puis définissez les autres éléments par rapport à celui-ci.) Divisez ensuite le CoD par la taille du travail. Le travail avec le plus haut WSJF est le prochain élément le plus important à faire.

Ce modèle encourage la division d’éléments volumineux en plusieurs éléments plus petits pouvant concurrencer d’autres éléments plus petits et à faible risque. Mais c’est juste Agile. Étant donné que la mise en œuvre est progressive, chaque fois qu’un travail en cours ne se positionne pas bien par rapport à ses pairs, vous avez probablement satisfait suffisamment à cette exigence pour pouvoir passer à la suivante.

Comme nous l’avons décrit, un autre avantage du modèle est qu’il n’est pas nécessaire de déterminer la valeur absolue de l’un de ces nombres. Au lieu de cela, vous devez uniquement évaluer les paramètres de chaque élément par rapport aux autres éléments du même backlog. Enfin, étant donné que les estimations deu backlog doivent inclure uniquement la taille restante du travail, une redéfinition fréquente des priorités signifie que le système ignore automatiquement les coûts irrécupérables.

Une note sur la Job Size en tant que Proxy pour la durée

La taille de la tâche ne constitue pas toujours un bon proxy pour la durée de l’algorithme WSJF. Par exemple:

• Si la disponibilité des ressources signifie qu’un travail plus important peut être livré plus rapidement qu’un autre élément de valeur équivalente, nous en savons probablement assez sur le travail pour utiliser la durée estimée afin d’obtenir un résultat plus précis. (Si trois personnes sont disponibles pour tondre la pelouse, alors que je fais l’arrière, ces items peuvent avoir à peu près la même durée, mais pas le même coût.)
• Un petit travail peut avoir plusieurs dépendances avec d’autres éléments et peut durer plus longtemps qu’un élément plus volumineux.

Mais il est rare que nous ayons à nous soucier de ces cas extrêmes, car s’il y a une petite erreur dans la sélection, ce prochain travail important fera son chemin assez rapidement.

Apprendre encore plus

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

[2] Reinertsen, Don. Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.

© Scaled Agile, Inc.