Poupées russes

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. Donc une idée est de procéder par décomposition top-down guidée par la valeur :

• Déterminer un modèle de valeur pour le produit/projet
• Lister les features de plus haut niveau d'abord et les prioriser par la valeur ¹
• Décomposer la feature de plus haute valeur en sous-features et les prioriser à leur tour par la valeur
• Et ainsi de suite jusqu'au niveau d'une user story

Pour les features avec le moins de valeur, on ne descendra pas au niveau de la story. Par contre, il faudra procéder à une comparaison des valeurs des stories appartenant à des features différentes puisque chacune devra faire partie de la release. Ce dernier point est important.

Ce travail peut ("doit" dans certains cas) être croisé par une approche inverse bottom-up pour être sûr de ne pas avoir oublié de story importante : on oublie un moment les features et on interroge les utilisateurs à partir d'une feuille blanche sur les fonctions précises qu'ils aimeraient avoir en priorité ¹

Se pose alors particulièrement la question de qu'est-ce qu'un release ? dans un contexte qui exige une telle richesse fonctionnelle dans la première version déployée. En fait, il apparaît nécessaire de distinguer deux niveaux de release : majeure et mineure :

• Un release majeure est celle qui est déployée, c'est à dire pas avant 1 an ou plus
• Un release mineure vise à apporter de la visibilité intermédiaire pour garantir l'agilité du processus. Il s'agira donc de versions fonctionnellement partielles mais qui présenteront un intérêt suffisant pour l'utilisateur, d'un point de vue cohérance globale et complétude. On s'attachera également à ce que cette version soit vraiment potentiellement déployable, c'est-à-dire à la représentativité de l'environnement cible par rapport à celui de l'utilisateur final.

Au plus bas niveau nous retrouvons nos fameuses itérations d'un mois (environ) qui respectent les principes essentiels d'agilité : livraisons de stories finies, timebox, qualité du code etc. Mais il n'y a pas d'exigence à ce qu'une feature soit finie à la fin d'une itération.