background preloader

Fonctionnalités Agiles

Facebook Twitter

Planifier la release. Pourquoi prévoir à un horizon plus lointain que le sprint ?

Planifier la release

Dans l'édition 4 de mon livre Scrum, la présentation de la planification de release a été repoussée. Planifier la release constitue maintenant le chapitre 16. Dans les éditions précédentes, elle était présentée avant la planification de sprint. Cette décision de déplacer ce sujet m'a demandé beaucoup d'efforts, d'autant plus que j'en ai profité pour revoir une grande partie du contenu de l'édition 3, en intégrant des notions nouvelles inspirées du courant #noEstimates.

La raison principale de ce changement est que planifier la release est une pratique optionnelle. Voici un extrait de mon livre, page 198, qui présente des situations où prévoir plus loin que le sprint est utile. Prévoir pour préparer le déploiement du produit La release est une série de sprints. À quoi cela sert ? Prévoir pour se synchroniser Le déploiement auprès des utilisateurs finaux ne se fait pas toujours en fin de la release : Prévoir pour décider.

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. 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 ? C'est pour faciliter le travail d'affinage du backlog, par l'équipe.

Hop, on crée un bac pour mettre les stories prêtes, c'est le bac de départ. Dans le reste, il y a des idées, des demandes, des feedbacks, peut-être intéressants, mais que le Product Owner n'a pas encore examinés. 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. 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.