background preloader

Fonctionnalités Agiles

Facebook Twitter

Features et stories. Une feature est décomposée en stories.

Features et 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 rechercheen tant que visiteur je peux obtenir la liste des billets associés à un tag On dit qu'une story apporte une utilité. Le nombre de stories dans une feature varie. Certaines de ces stories sont à destination du blogueur (côté back-office) et les autres pour le visiteur.

Affinage de bac en bac. Des petits bacs plutôt qu'un gros backlog, l'idée a maintenant fait son chemin.

Affinage de bac en bac

C'est plus facile pour l'affinage. L'idée des bacs m'est venue quand j'étais encore Product Owner d'iceScrum, il y a 3 ans. Il y avait déjà le bac à sable, puis s'est ajouté le bac à glace. Pour iceScrum, ça s'est arrêté là, mais j'ai continué à expérimenter cette façon de présenter le backlog.

C'est devenu "les bacs". L'expérimentation a été un succès. L'intérêt croissant pour le management visuel et la diffusion de Kanban autour de Scrum ont contribué à pousser à mieux comprendre la vie de la story avant le sprint. Pourquoi les bacs ? Affiner c’est mieux que groomer. Hier toute la journée, mes interlocuteurs ont parlé de grooming.

Affiner c’est mieux que groomer

C’est ainsi qu’ils nomment la discussion sur le backlog, en vue de le préparer, que j’appelle la revue de backlog. Ce n’est pas un mot qu’ils ont inventé. C’est moi qui les ai formés. Dans le petit guide Scrum de Schwaber & Sutherland, dans la version 2011, et probablement avant, c’était le terme employé. J’ai dû leur dire et c’est rentré dans leur jargon (qui est fleuri). Moi je l’ai d’abord traduit par bichonner. Ensuite je suis passé au PO qui cultive son backlog et j’ai parlé de culture de backlog et de bac de culture. Force est de constater que ce n’est pas terrible. Entre temps, dans le petit guide Scrum de 2013, grooming est devenu refinement.

Mais mes scrumeurs d’hier continuent à dire grooming. Je sens bien que ma culture (de backlog) ne va pas passer. Non, la bonne traduction est affinage, du verbe affiner. Affinage, va falloir que je demande un nouveau dessin à Patrice, avec des fromages… La vie d'une feature. Une feature est un service, observable de l'extérieur, qui contribue à un impact, et dont la description se situe à un niveau tel que toutes les parties prenantes comprennent facilement ce dont il s'agit.

La vie d'une feature

Côté développement, une feature peut se voir comme un ensemble de stories et qui a sa propre existence. Un aspect fondamental du développement agile est de répondre à l'impact (et donc fournir de la valeur) en minimisant l'effort à faire pour développer la feature. C'est pourquoi la pratique de la division de feature, comme de story est si importante. La vie d'une story, avec Scrum, c'est rythmé par le sprint, ce qui limite l'éventail des états intéressants. C'est pourquoi j'ai pu définir des bacs, sans que cela soit spécifique à un contexte particulier.

Chaque bac correspond à un moment important de la vie de la story : encore une idée dans le bac à sable, en affinage, prête, en développement dans le sprint et finie. Tableau de features à grande échelle. Un tableau de features permet de montrer la décomposition du travail à faire et l'affectation aux différentes équipes dans le cadre d'un Scrum à grande échelle.

Tableau de features à grande échelle

Dans le billet la vie d'une feature, j'ai présenté un tableau permettant de visualiser et suivre le développement des morceaux essentiels d'un produit. Ce tableau de features reste unique quand le produit est gros et que plusieurs équipes y travaillent. Qu'est-ce qui change dans ce tableau quand on passe à Scrum à l'échelle ? Il y aura plus d'éléments dans les colonnes. Si on considère qu'une équipe réalise en moyenne 2 features par sprint (pour 10 stories en moyenne aussi), pour 3 équipes participant au même produit, cela fera 6 par sprint et 30 pour une release de 5 sprints.

KPI.