« Prioriser les Features » : différence entre les versions

[[Category: Portail Product Owner]]

[[Category: Portail Planification]]

[[Category: Modèle de Kano]]

Auteur : Dean Leffingwell<br/>

Source : [http://scalingsoftwareagility.wordpress.com/2010/04/08/prioritizing-features/ Prioritizing Features]<br/>

Comme nous l’avons évoqué plus haut, nous avons traditionnellement essayé de prioriser le travail en essayant de comprendre le retour sur investissement relatif, qui est le rapport entre le rendement potentiel (la valeur) et l’effort (le coût du développement) pour une feature. Au moins, le modèle était simple :<br/>

<br/>

<br/>

Si nous pouvions simplement établir la valeur et le coût d’une feature – sinon en termes absolus, du moins par rapport à d’autres features – alors nous aurions un moyen de prioriser fondé sur l’économie. Après tout, qui ne souhaiterait pas livrer une feature de ROI supérieur avant une feature de ROI inférieur ? Cela semble être totalement intuitif et (apparemment) du bon sens économique.<br/>

Lorsque le coût du retard est équivalent pour deux features, réaliser le "travail le plus rapide" (le plus petit dans notre cas) produit les meilleurs rendements économiques, comme illustré dans la figure ci-dessous :<br/>

<br/>

<br/>

L’impact est manifestement important : réaliser le plus petit travail a des retombées économiques "bien meilleures" que réaliser le plus gros travail en premier. Nous arrivons donc à notre première conclusion :<br/>

Si la quantité de travail est sensiblement la même, alors la seconde approche illustre l’effet de prioriser des travaux avec le coût du retard le plus important. Encore une fois, la théorie économique est convaincante comme l’indique la figure ci-dessous.<br/>

<br/>

<br/>

Bien sûr, cela a un sens intuitif dans ce cas aussi (même si l’intuition ne nous a pas toujours conduit à la conclusion correcte). Car si le Coût du Retard est une approximation de la valeur, et qu’une feature a plus de valeur qu’une autre et que l’on doit produire le même effort, alors on doit réaliser la première; nous le savions déjà avec notre ROI proxy Valeur / Effort. Nous avons donc notre seconde conclusion :<br/>

Dans ce cas, nous calculons le poids de la priorité relative d’un travail en divisant le coût du retard par l’estimation de sa taille. Si les coûts du retard et les tailles varient beaucoup, alors les écarts de rendement peuvent être énormes, comme l’illustre la figure ci-dessous.<br/>

<br/>

<br/>

Voilà donc l’approche que nous privilégions pour le développement de logiciels :<br/>

Maintenant, nous pouvons intégrer toutes ces informations dans une matrice d’évaluation que nous pouvons utiliser pour établir les priorités relatives d’une feature, et qui se base à la fois sur l’effort et le coût du retard. Un exemple est donné dans le tableau ci-dessous :<br/>

<br/>

<br/>

Légende :<br/>

Avec ses collègues, Noriaki Kano, un expert dans le domaine de la gestion de la qualité et la satisfaction client, a développé un modèle pour la satisfaction client qui remettait en cause de nombreuses croyances traditionnelles. Plus précisément, le modèle de Kano conteste l’idée que la satisfaction client est atteinte en équilibrant les investissements à travers les divers attributs d’un produit ou d’un service. Au contraire, la satisfaction du client peut être optimisé en mettant l’accent sur les "features discriminantes", ces "excitateurs" et "attracteurs" qui augmentent la satisfaction et la fidélité des clients au-delà de ce que demanderait proportionnellement un investissement. Le modèle de Kano est illustré dans la figure ci-dessous :<br/>

<br/>

<br/>

Le modèle illustre trois types de features :<br/>