La Matrice Valeur-Complexité

De Wiki Agile du @GroupeCESI
Aller à : navigation, rechercher

Auteur : Victor Lombardi (@threefour)
Source : The Value-Complexity Matrix


Traducteur : Fabrice Aimetti
Date : 07/08/2015


Traduction :

J'aime penser que les projets sont des voyages de l'abstrait vers le concret. Voici un chemin très simple :

  • Elaborer une stratégie métier / identifier les utilisateurs
  • Faire une liste de fonctionnalités
  • Créer les fonctionnalités
  • Coder les fonctionnalités


L'étape "Faire une liste de fonctionnalités" constitue une véritable transition entre la bouillie produite par l'étape de recherche et le fait de se mettre au travail. Une fois que je connais les fonctionnalités, la liste est priorisée.

La priorisation des fonctionnalités se base sur l'identification des utilisateurs et l'élaboration de la stratégie métier, ainsi que sur les estimations initiales de la part du technique. J'aime faire cet exercice de priorisation moi-même avec toutes les parties prenantes afin que tous les points de vue soient pris en compte. Il s'agit d'une réunion préalable dont les résultats guident le reste du projet.

J'aime prendre chaque fonctionnalité et lui assigner des valeurs selon les risques et les opportunités, ou bien la complexité et la valeur... les termes peuvent changer d'un projet à l'autres (les gens qui font des affaires et les chefs de projet connaissent probablement le nom approprié pour ce tableau). Si vous mettez ces termes dans une matrice, avec des axes x et y, vous obtenez une schéma de ce type :

Value-complexity fr.jpg

Voilà comment j'interprète chaque quadrant :

  • Complexité importante / Valeur importante : il est essentiel de prendre en compte ces fonctionnalités, et parce qu'elles sont difficiles à réaliser, traitez-les d'abord pour avoir suffisamment de temps pour trouver des problèmes encore inconnus.
  • Complexité importante / Valeur faible : les fonctionnalités sont difficiles à réaliser et personne ne pense qu'elles sont importantes, donc essayez de les laisser de côté.
  • Complexité faible / Valeur importante : aucun doute, il faut les prendre en compte, mais donnez leur une priorité plus faible.
  • Complexité faible / Valeur faible : ces fonctionnalités peuvent être mises sur une liste à part, à réaliser si les moyens le permettent ; ou laissez-les de coté pour une phase ultérieure ; ou vous pouvez les réexaminer pour vérifier si la valeur associée est juste.


Tout au long du projet, en particulier si les choses dérapent, je peux me revenir sur cette matrice et m'assurer que nous sommes bien en train de consacrer nos moyens et nos efforts sur ce qui avait été initialement priorisé.

Evidemment, l'analyse des risques/opportunités continue tout au long du projet à différents niveaux, en posant notamment des questions comme "Quels marchés ciblons-nous ?", "Quels segments de clientèle n'adressons-nous pas ?", "Quel est la taille limite d'une page ?" et "Devrions-nous utiliser DHTML ?".