feature

Équipes features façon puzzle

Équipes features façon puzzle

Je continue avec mes retours d’expérience sur l’atelier Puzzle grand Scrum que j’ai animé une quinzaine de fois. Après des discussions sur par quoi commencer et sur la synchronisation des sprints, revenons sur l’organisation des équipes. Pour réaliser le puzzle avec 3 équipes, on a besoin de définir sur quoi chacune va travailler. Nous sommes dans le cas où il n’y a qu’un seul produit et je fournis au participant au jeu un seul backlog, sous la forme de 20 features (ou stories peu importe).

Glossaire E-F

L’édition 4 de mon livre comporte, et c’est nouveau, un glossaire. Voici les entrées pour E et F : Epic ou story épique : story dont l’équipe considère qu’elle est trop grosse pour rentrer dans un sprint en l’état. Équipe auto-organisée : équipe qui possède le pouvoir de décider comment faire le travail. Équipe pluridisciplinaire : équipe qui possède, collectivement, toutes les compétences requises pour développer le produit. Équipe Scrum : groupe de gens auto-organisé et pluridisciplinaire qui réalise un incrément de produit à chaque sprint.
Définition de fini multi-niveaux

Définition de fini multi-niveaux

La définition de fini est le plus souvent une simple liste. Pour être plus pertinent, on peut définir plusieurs niveaux de fini, et pour être plus complet, plusieurs aspects de la finition. Cette présentation avec 4 cercles concentriques et 3 zones permet d’élaborer collectivement une définition de fini avec bien plus de subtilité qu’une simple liste. Niveaux hiérarchiques fini pour une story fini pour une feature : tout ce qu’il faut vérifier sur une feature qui ne l’a pas été sur ses stories fini pour le sprint : tout ce qu’il faut vérifier sur l’incrément de sprint et qui n’a pas été vérifié sur les stories et les features fini pour la release : tout ce qui n’est pas fait à chaque sprint et qui reste à faire à la fin La définition de story est vivante : au cours de sprints, un contrôle peut changer de niveau.
Session d’affinage et affectation des features (SAF)

Session d’affinage et affectation des features (SAF)

Le passage à grande échelle avec des features teams demande une prise de décision supplémentaire : le choix de l’équipe qui va réaliser une feature. Comme pour les travaux d’affinage sur les stories, il est souhaitable que cela se fasse autour de conversations, mais impliquant cette fois toutes les équipes. C’est l’objet des sessions d’affinage et d’affectation des features. Pour un Scrum à plusieurs équipes, le tableau des features permet de montrer quelle équipe va travailler sur quelle feature.
Tableau de features à grande échelle

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. 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 ?
Finir une story c’est bien, finir une feature c’est mieux

Finir une story c’est bien, finir une feature c’est mieux

Arrêter de commencer, commencer à finir. Mais pas seulement. Il y a quelque temps, j’avais audité un projet dont le tableau de features, s’il avait été fait[1], aurait ressemblé à peu près à ça : Tout un tas de features commencées, aucune de finie, même après des mois de sprints. Avec cette vue, on voit bien que l’avancement peut être résumé très vite. Zéro. Rien de fini. Pas besoin de feuille de calcul.
La vie d'une feature

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. 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.
Chapitre dix-neuf

Chapitre dix-neuf

Le chapitre 19 de mon livre s'appelle Scrum à grande échelle. C'est un sujet délicat.

Le but du chapitre Il est présenté dans l’introduction : On peut distinguer trois niveaux pour la prise en compte de l’agilité dans des organisations : projet, produits, organisation. Beaucoup d’expériences actuelles avec Scrum restent au niveau projet. Nous allons approfondir les niveaux produits et organisation. J’ai évoqué, dans le chapitre 18, Transition à Scrum, la façon dont une entreprise gérait le changement vers l’agilité. Ici, il s’agit d’aborder le changement d’échelle dans ce qu’il implique sur la mécanique de mise en œuvre de Scrum, en termes d’équipes, de backlogs et de cycle de vie.
Chapitre treize

Chapitre treize

Le chapitre 13 de mon livre Scrum s’appelait “De la vision aux stories” dans les deux éditions précédentes. Dans cette nouvelle édition, il devient “De la vision aux features”, les stories ayant été poussées dans le chapitre suivant. Il a été presque entièrement réécrit, pour incorporer les nouveaux outils du Product Owner, ceux que j’ai présentés le mois dernier lors du ScrumDay 2014. Je me souviens, j’étais en train de finaliser ce chapitre il y a juste un an pour le pont du premier Mai.
De la vision à la story

De la vision à la story

Les notions manipulées pour aller de la vision à la story, avec quelques techniques de définition de produit pour y arriver. Impact Mapping, Innovation Games, Story Mapping, Revue de backlog, Spécification par l’exemple font l’objet d’ateliers ou jeux dans mes formations Scrum et Product Owner.

Inventaire de définition de produit

On développe un produit dans le but de satisfaire les partie-prenantes (clients, utilisateurs). Ces stakeholders ont des besoins. On répond à ces besoins en développant des features, qui se décomposent en stories. Une fois la collecte de ces différents éléments au cours d’ateliers, notamment les Innovation Games, on peut mettre tout ça ensemble sur une carte heuristique pour préparer la constitution du backlog. Parfois c’est un peu différent : Quand on innove, on crée des features qui ne répondent pas à un besoin identifié.

Division de feature et de story

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.
Articulation entre jeux agiles

Articulation entre jeux agiles

Vous aimez bien les jeux agiles, mais, comme fierfeu qui l’a mis en commentaire sur le billet de la formation de janvier, vous voulez savoir si on peut les articuler. Bon, on n’est pas obligé de les articuler, ils s’utilisent le plus souvent de façon indépendante et un des objectifs de notre formation Innovation Games est d’aider à savoir quand les utiliser. Cependant, pour fierfeu, voici une séquence possible de jeux pour définir un produit, du concept au backlog priorisé.

Estimation de l'effort des features

L’usage courant est de définir un élément du backlog de produit comme étant une story. Dès qu’on sort de la toute petite échelle, on a besoin d’un élément de plus haut niveau, habituellement c’est la notion de feature qui y répond. Pour bien comprendre cette distinction, le mieux est de s’appuyer sur un exemple ; c’est que j’avais essayé de présenter dans le billet Features et stories écrit en août 2010.
Scrum avec plusieurs équipes

Scrum avec plusieurs équipes

Vous avez plusieurs équipes qui font du Scrum et vous voulez garder une vue générale, plutôt que d’avoir des projets séparés. Voilà une façon simple de faire du “scrum de scrums”. Equipes et Features Constituez les équipes et associez à chacune une couleur. Identifiez les features, éventuellement à partir d’une vision. Rangez-les par priorité. Montrez quelle équipe va réaliser la feature en lui donnant sa couleur. Le “backlog” de features donne un aperçu du partage entre les équipes à haut niveau :
Vision du produit en mindmap

Vision du produit en mindmap

Élaborer la vision du produit avec des cartes heuristiques

Gokjo Adzic a publié il y a quelques mois un article sur une technique de mIndmapping permettant de définir un produit. Il appelle ça Effect Maps. Cette façon de procéder permet d’obtenir, comme tout ce qui est carte heuristique, une vue très élégante de ce qu’on peut qualifier de vision du produit. Je l’ai utilisée sur un projet et comme cela a bien marché, je l’ai introduite dans ma formation, en remplacement d’ateliers comme souvenir du futur et boite du produit.

Des ateliers ludiques en formation

Pour définir la vision et d’arriver rapidement à la constitution du backlog initial. Mes amis Fabrice et Alex parlent ces jours-ci, sur leur blog, des jeux collaboratifs qu’on peut faire avec les clients pour créer des produits innovants. Ces jeux sont excellents en coaching. Utilisés pendant les formations, ils sont aussi très efficaces pour apprendre, en pratiquant par petits groupes. A partir des Innovation Games de Luke Hohmann cités par mes camarades, mais aussi avec d’autres inspirations comme Mike Griffiths, j’ai adapté plusieurs de ces jeux pour les faire rentrer dans le cursus de ma formation de 3 jours.

Séminaire 'L'agilité : du projet au programme et à la ligne de produits'

IBM Toulouse organise le 10 Novembre prochain, sur le site de la Plaine, un séminaire sur l’agilité au-delà du projet, pour des produits qui évoluent longtemps, font partie de programmes ou d’une famille de produits ou sont inclus dans un portefeuille de produits J’aurai le plaisir de faire la présentation sur ce sujet et je dispose d’une bonne partie de la matinée. Les premiers inscrits recevront un exemplaire de mon livre « SCRUM : le guide pratique de la méthode agile la plus populaire » publié aux Éditions DUNOD, qui leur sera remis le jour du séminaire.
Features et stories

Features et stories

Une 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.
Elément du backlog de produit, le modèle

Elément du backlog de produit, le modèle

A l’occasion d’évolutions dans IceScrum, j’ai remis à jour le (méta) modèle de l’élément de backlog de produit. Le backlog de produit contient des éléments. Un élément de backlog est généralement qualifié de story. Mais ce n’est pas si simple. A partir des idées de ce billet, j’ai modélisé la typologie qu’on retrouve dans Icescrum : Un élément peut aussi être une feature, avant sa décomposition en stories. Une user story correspond à un type de story qui apporte de la valeur directe aux utilisateurs.