Quand on démarre le développement d'un nouveau produit, une étape significative est d'élaborer une liste de features, de les prioriser puis d'identifier les stories des features les plus prioritaires.
Ensuite le développement se planifie sur les sprints et les releases. Dans le billet Features et stories, avec un schéma carré, j'expliquais : "Une story est planifiée dans un sprint et une feature dans une release."
J'y montrais aussi le cycle de vie d'une feature, qui est finie une fois qu'elle est livrée.
Ce qui est aussi à considérer dans la vie d'une feature, c'est qu'elle est amenée à se diviser. Comme une story, mais pas pour les mêmes raisons.
Une story peut se décomposer en plusieurs stories. Je présente des techniques de décomposition dans le § 13.5.4 dans mon livre. L'objectif de cette division est de s'assurer -en tout cas, d'améliorer la probabilité- qu'une story soit finie dans un sprint. La définition de prêt est la pratique clé pour se rendre compte qu'une story doit être divisée.
Une feature est considérée initialement comme une fonctionnalité essentielle. Par exemple : gestion des tags, inscriptions, annonces...
L'identification de toutes les stories correspondant à une feature, puis la division évoquée ci-dessus amènent à reconsidérer la feature initiale. En effet, on n'a généralement pas besoin de toutes les stories trouvées pour livrer une première version qui apporte de la valeur. On va donc sélectionner celles qui constituent ce regroupement minimal mais suffisant. C'est la notion de MMF, le plus petit ensemble ayant de la valeur pour un client.
Ce regroupement correspond à une division de la feature initiale, le sous-ensemble devenant une nouvelle feature, dont l'état passera à fini quand elle sera livrée, tandis que les stories restantes seront associées à une ou plusieurs autres features qui seront développées dans des releases ultérieures.
Derniers commentaires