David BROCARD Consultant Indépendant

Pour éviter de mettre un commetaire de 10 km sur le site de Claude, je décide de publier un billet au sujet des features et en particulier pour le cas d'un très gros spectre fonctionnel au démarrage d'un projet "from scratch".

Dans ce cas, on peut parler de 2 ou 3 niveaux (voir plus) de décomposition en features et d'une release incompressible prenant plus d'un an de développement. Lister l'ensemble des stories du produit reviendrait à en avoir des milliers, ce qui est bien entendu contre-productif.

L'expérience d'hier m'incite à publier ce billet sur les techniques d'élaboration de besoins en agilité (dans les domaines plus "classiques", on parle d'"Ingénierie des exigences")

Vue fonctionnelle d'ensemble

Dans le Business Value Game, on dispose les user stories de la façon suivante : En haut, de gauche à droite, on place les features (ensemble fonctionnel de haut niveau, autonome et consistant, répondant à la notion de service rendu de bout en bout avec un résultat observable apportant de la valeur... ouf) de gauche à droite, par valeurs décroissantes (voir la notion de valeur expliquée précédemment)

En dessous, on dispose horizontalement les user stories de haut en bas par valeurs décroissantes (valeurs divisées) et verticalement, en face de la feature à laquelle elles appartiennent.
On obtient ainsi une vue matricielle de l'ensemble. On peut alors considérer une "diagonale" bas-gauche/haut-droite en dessus de laquelle se trouve les user stories les plus intéressantes à élire pour le court terme. Évidemment, ce n'est pas le seul critère à prendre en compte (antécédences entre items, investissements techniques etc)