Voir la source de Priorisation des fonctionnalités par le coût du retard

Auteur : Jeff Anderson<br/>
Source : [http://agileconsulting.blogspot.com/2011/03/using-cost-of-delay-functions-to.html Using Cost of Delay Functions to Prioritize Product Delivery]<br/>
Date : 27/03/2011<br/>
----
Traducteur : Fabrice Aimetti<br/>
Date : 12/04/2011<br/>
----
Traduction :<br/>
<br/>
Dans beaucoup de projets "agiles" auxquels j’ai participé, une partie de ma stratégie consistait à découper tout ce qui passait – que ce soit des fonctionnalités, des cas d’utilisation ou des stories – et à livrer une partie à la fois la plupart du temps. Par exemple, dans l’itération 1, on livre la fonctionnalité de prise de commandes et dans l’itération 2 on livre le traitement de la commande.<br/>
<br/>
[[Fichier:Typicaliterativeapproach m.jpg]]<br/>
<br/>
Bien que cette approche nous aide à livrer efficacement en découpant le travail en petites unités, cela ne nous aide pas beaucoup d’un point de vue métier. Lorsque vous livrez un produit, l’approche agile considère le produit d’un point de vue réellement incrémental. Quel est l’ensemble minimum livrable à l’instant t qui répondra aux objectifs vitaux du produit, quel est le prochain ensemble de fonctionnalités pour rendre l’outil meilleur, et ainsi de suite jusqu’à ce que j’obtienne le produit final, une partie étant livrée à la fois.<br/>
<br/>
[[Fichier:Ineedashelter.jpg]]<br/>
<br/>
Utiliser cette approche agile n’est pas suffisant pour que les équipes développent à chaque itération des choses qui partent en production. L’organisation entière doit réfléchir à la façon de livrer de façon incrémentale des versions du produit sur le marché.<br/>
<br/>
Pour réaliser ce travail, le métier doit s’entraîner à ne plus demander la terre entière un an avant… mais plutôt de demander un petit bout la semaine suivante.<br/>
<br/>
Un de mes collègues, Alexis Hui, nous a amené une approche innovante pour gérer cette situation sur l’un des projets que nous menions. Cela consistait à étendre notre tableau Kanban avec une cartographie des caractéristiques et thèmes fonctionnels illustrée ci-dessous.<br/>
<br/>
[[Fichier:Themeorientedmap m.jpg]]<br/>
<br/>
Le tableau fut découpé en sections basées sur des caractéristiques fonctionnelles majeures que le produit devait comporter. Ces caractéristiques fonctionnelles furent ensuite découpés en thèmes fonctionnels composés d’attributs. Chaque attribut était vu comme une fonctionnalité pouvant être revisitée plusieurs fois durant le cycle de vie du projet. Chaque fois qu’un attribut nécessitait un travail, une story était étiquetée avec le thème et l’attribut concerné.<br/>
<br/>
Par exemple, la caractéristique fonctionnelle "casque" aura un thème pour la messagerie vocale avec un attribut pour l’activation et un autre pour la désactivation. Une story initiale concernera le travail nécessaire pour fournir la messagerie vocale sur un téléphone portable avec un ensemble de fonctionnalités très simples et une story finale pourra décrire des fonctionnalités plus fantaisistes comme visualiser la messagerie vocale.<br/>
<br/>
Chaque ensemble de thèmes/attributs agira comme une file d’attente persistante dans laquelle les stories sont placées.<br/>
<br/>
Nous avons ensuite utilisé un concept connu sous le nom de Coût du Retard (CDR$$NdT : COD = Cost Of Delay$$) d’une Fonctionnalité pour prioriser les stories. Pensez-y comme un moyen simple de montrer l’impact de ne pas réaliser une story donnée pour le métier. Le CDR, également baptisé le Coût d’Opportunité, est souvent schématisé sous la forme d’une courbe représentant la relation entre l’impact et le temps ; plus la pente de la courbe est raide, pire est l’impact à court terme. Le CDR peut représenter un impact financier, politique, moral ou tout autre impact défavorable pour l’organisation.<br/>
<br/>
Bien qu’il puisse être assez dur pour une organisation d’estimer l’impact exact de ne pas réaliser un élément donné sur la durée, nous sommes normalement capables d’affecter le CDR dans une catégorie ou profil donné. Lorsqu’on utilise le CDR, je recommande d’utiliser des couleurs ou des annotations sur l’élément du tableau Kanban, ceci afin de pouvoir facilement identifier son profil CDR.<br/>
<br/>
[[Fichier:Costofdelay m.jpg]]<br/>
<br/>
Puisque notre projet concernait le lancement d’un nouveau produit, nous avons décidé de baser nos profils CDR en tenant librement compte des risques du marché.<br/>
<br/>
Les tickets rouges représentaient les éléments qui furent considérés vitaux pour le lancement d’une première version du produit, le CDR est représenté comme une ligne verticale. Si nous n’avions pas livré ces fonctionnalités à la date annoncée pour la première version alors le projet aurait été voué à l’échec. Ces fonctionnalités étaient indispensables pour percer le marché.<br/>
<br/>
Les tickets beiges représentent un deuxième passage sur les tickets rouges, en prenant la plupart des fonctionnalités manuelles brutes et en les automatisant, en ajoutant une meilleure gestion des erreurs ainsi que d’autres tâches permettant de s’assurer que le produit sera pleinement opérationnel et constituera plus qu’un simple projet pilote. Ce CDR est représenté comme une courbe progressant vers la droite, nous aurions perdu de l’argent quotidiennement si cela n’avait pas été mis en œuvre, et les choses se seraient aggravées si cela n’avait pas été livré. Ces tickets étaient nécessaires pour soutenir la croissance du marché.<br/>
<br/>
Les tickets verts représentent des fonctionnalités haut de gamme comme le suivi de clientèle, des outils de productivité, des fonctionnalités personnalisées et même des fonctionnalités permettant de préserver le marché, comme conserver son numéro de téléphone lors du transfert vers une nouvelle offre. Le CDR a été modélisé ici comme celui des tickets beiges, mais avec un certain délai avant de subir des pertes et une pente de la courbe plus prononcée ; nous n’avions pas besoin de ces fonctionnalités tout de suite, même si elles se révélèrent très précieuses un peu plus tard. Ces tickets furent en effet nécessaires pour prendre des parts de marché aux concurrents.<br/>
<br/>
Les tickets bleus représentent des investissements à plus long terme. Traiter un ticket bleu n’a pas d’impact commercial notable. C’est plutôt la qualité du travail qui s’améliore. Les sujets "architecture", "former l’équipe sur les pratiques agiles", "refactoring", "documentation technique" ont tous été profilés en tickets bleus. Le CDR de ces tickets est représenté sous la forme d’une ligne horizontale avec une légère pente vers le haut, la valeur métier est loin d’être immédiate, mais ne pas les faire entraînerait plus tard des souffrances. Ces tickets furent nécessaires pour que l’équipe informatique puisse continuer à traiter les autres besoins du marché à un rythme et à un prix raisonnable.<br/>
<br/>
[[Fichier:Themeorientedmap-color m.jpg]]<br/>
<br/>
Les schémas ci-dessus montrent des stories coloriées selon le CDR. On peut facilement voir les caractéristiques fonctionnelles les plus critiques dès les premières étapes de développement et celles qui pourront être traités plus tard. On peut remarquer que prioriser n’est pas aussi simple que de choisir une couleur, puis une autre, puis encore une autre. Dans des contextes métiers ou projets différents, on choisira une affectation différente des profils CDR dépendant de leur position dans le cycle de vie du produit.<br/>
<br/>
Cette affectation du CDR dépend aussi de la nature du contexte métier, par exemple les start-ups subiront davantage d’évènements fugitifs que de grosses sociétés et auront donc plus de tickets de couleur « chaude » (rouge, beige) pour répondre à ces événements au fil de l’eau.<br/>
<br/>
Il est typique d’utiliser cette approche pour revisiter les attributs à plusieurs reprises. La première story pour un attribut peut être un ticket bleu mettant en jeu un spike, un POC ou une conception réelle. Des stories liées à l’attribut pourront impliquer des tickets rouges et beiges, dépendant du souhait de disposer d’un composant essentiellement manuelle ou complètement automatisé. Les stories suivantes seront souvent des séries de tickets bleus et verts nécessaires pour réaliser des POC sur de nouvelles technologies et poser le socle à la base d’une fonctionnalité haut de gamme.<br/>
<br/>
L’idée est donc que la simple utilisation d’une couleur peut porter un maximum d’informations pertinentes d’un point de vue métier et permettre de livrer de la valeur sur un mode réellement agile.