Features et stories

31 mardi août 2010 07:58

Features et storiesUne feature est décomposée en stories. Une story est planifiée dans un sprint et une feature dans une release.

Imaginez que vous développez une application comme Dotclear mon moteur de blog, mais qui n'offrirait pas encore la gestion des tags, ni la possibilité d'attacher un fichier à un billet.

Gestion de tags et attachement de fichiers sont des features. Pour savoir à quel moment on les développe, on s'intéresse à leur utilité et on estime l'effort de développement nécessaire. Cela aidera pour définir leur priorité.

Pour commencer à développer une feature, il faut la décomposer en stories.

Par exemple pour la gestion de tags :

  • en tant que blogueur je peux ajouter un tag à un billet afin de faciliter sa recherche
  • en tant que visiteur je peux obtenir la liste des billets associés à un tag

On dit qu'une story apporte une utilité. Composée de plusieurs stories, une feature apporte un utilité plus substantielle. Mettre en production une story seule n'a généralement pas d'intérêt, à la différence d'une feature regroupant quelques stories.

Le nombre de stories dans une feature varie. Pour l'exemple de gestion des tags, on peut ajouter plein d'autres stories :

  • supprimer un tag d'un billet
  • changer le nom d'un tag
  • faire un nuage de tags
  • filtrer par tags
  • supprimer un tag
  • fusionner des tags

Certaines de ces stories sont à destination du blogueur (côté back-office) et les autres pour le visiteur. Toutes ne sont pas obligatoires pour une mise en production, par exemple on peut se passer du nuage de tags ou de la fusion des tags dans une première version, c'est au Product Owner de définir le minimum indispensable.

Lors de la planification, les stories sont associées à des sprints. Réalisée dans un sprint, une story est normalement finie à la fin de ce sprint. La feature a le même comportement à un niveau de planning supérieur. Les features sont associées à des releases. Par exemple, on dira que la feature Gestion des tags sera faite dans la release R2 qui se termine en octobre.

Comme la story, la feature a un cycle de vie, en plus simple : à faire, en cours, fini. Plutôt que pour une story, c'est pour une feature qu'on peut faire une estimation (relative) de son utilité. L'estimation de l'effort d'une feature est obtenue par la somme de celles de ses stories. Chaque story possède ses tests d'acceptation. Pour tester une feature, on testera chaque story qui la compose et il sera utile d'ajouter quelques tests au niveau feature, enchaînant des tests élémentaires ou portant sur des aspects non fonctionnels (volumétrie, performance, ergonomie) ou du niveau système (comme la sauvegarde).

Billets en relation :

Commentaires

1. Le 01 mercredi septembre 2010, 08:43 par François Michas

Comme tout novice l'évidence ne me saute pas aux yeux !
Je pose donc mes questions :
- les feature se transformant en story disparaissent-elles du product backlog ? Si non, comment fait-on pour ne pas tout mélanger ? Si oui, quelle trace en garde-t'on : une photo du product backlog initial (à voir ce que veut dire initial d'ailleurs ...) ?

Je prends l'exemple d'iceScrum. Il y a un backlog pour les stories et un autre pour les features et on garde l'association entre une feature et ses stories. D'ailleurs dans l'outil, on peut donner une couleur aux features, qui est répercutée sur les stories. Il y a aussi un indicateur, le parking lot, qui donne l'avancement par feature.

A-t'on un release backlog qui contient des feature, un product backlog des stories, un sprint backlog des tâches ?
Plus exactement une liste de features (ou backlog de features), un backlog avec des stories, un plan de release dans lequel on associe des stories aux sprints et un plan de sprint dans lequel on voit les tâches nécessaires pour réaliser les stories associées aux sprints. Dans iceScrum on aura aussi bientôt une roadmap dans laquelle on pourra associer des features à une release - les feature sont-elles aussi accompagnées de critères d'acceptance ?
- où se trouvent logés les enchaînements entre stories ? Dans la feature ? Dans d'autres artefacts type user story map ?

2. Le 01 mercredi septembre 2010, 14:03 par Hugues

Sauf, erreur de ma part, je trouve ta nouvelle description de la feature dans ce billet plus complète que celle que tu donnais dans ton livre. En tout cas, je la préfère. En lisant ce billet, on comprend tout de suite ce qu'est une Feature. Tu pourrais peut-être introduire la notion de features, dans ta nouvelle version de ton livre, en te basant sur ce billet ?

Oui, ça fait partie des notions que je pense mieux présenter dans la nouvelle version.
3. Le 05 dimanche septembre 2010, 10:29 par David

J'avais commencé par écrire un commentaire mais qui s'est vite avéré un peu long !

http://davidbrocard.org/node/99

4. Le 06 lundi septembre 2010, 20:29 par Bruno

Est-ce qu'il ne faudrait pas aussi créer un type de story de tests qui permettent (en parallèle du développement) de préparer la validation des tests d'une feature, et montrer le taux de couverture d'une feature

5. Le 06 lundi septembre 2010, 22:06 par Laurent

Et j'ai répondu à David ici :
http://davidbrocard.org/node/99

6. Le 27 lundi septembre 2010, 17:54 par Anthony

Une question me vient immédiatement à l'esprit lorsque je lis "une story est normalement finie à la fin de ce sprint" : Que devient une story qui est partiellement terminée ? J'entends par là, une story correctement définie (ne peut pas être redivisée en plusieurs stories) et qui présente des défauts en fin de sprint et qui n'est donc pas terminée.

A priori, je vois deux solutions :

1) On conserve la story pour le Sprint n+1. Dans ce cas, j'imagine que l'on revoit son estimation en se basant sur le reste à faire. Mais à priori, il n'y a plus aucune trace du travail qui a été réalisé pendant le Sprint n (les points n'ont pas été inscrits au burndown du sprint N parce que la story n'était pas terminée et en sprint N+1 il y aura moins de points pour cet item puisque l'on ne réalise que ce qui n'est pas encore fait).

2) On divise la story. Une story "ce qui est fait" et une autre "le reste à faire". Dans ce cas, cela veut dire modifier les backlogs (dont le backlog de sprint N qui est terminé). Mais avec cette solution, on a l'impression que l'item a été correctement réalisé alors qu'en réalité ce n'est pas le cas.

Par contre, je ne vois pas laquelle privilégier, les inconvénients engendrés semblent plutôt gênants... Peut-être y-a-t-il une autre manière de voir la chose ?

Ni l'une ni l'autre. Une story à n points qui n'est pas finie n'est pas ré-estimée (elle reste à n points) et on ne la divise pas. C'est bien plus simple comme ça. Cela peut avoir un impact sur la vélocité d'un sprint, mais ne change pas la moyenne sur plusieurs sprints, et c'est la moyenne qui est utilisée pour planifier la release.