« Priorisation des fonctionnalités par le coût du retard » : différence entre les versions

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/>

<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/>

<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/>

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/>

<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/>

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/>

<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/>

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/>

<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/>