feature

Équipes features façon puzzle

Équipes features façon puzzle

Comment jouer au puzzle Scrum ?

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

Featuring feature

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

Douze cases pour placer chaque élément de la définition de fini

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 (SAAF)

Session d’affinage et affectation des features (SAAF)

Quand décider quelle équipe s'occupe de quelle feature ?

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

Qu'est-ce qui change dans ce tableau quand on passe à Scrum à l'é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. Pourtant sur le projet, l’avancement n’était pas présenté comme ça : il y avait des stories de finies, une vélocité obtenue à chaque sprint.
La vie d'une feature

La vie d'une feature

Un pattern qui va bien

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

Peetic inside

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

La vue d'ensemble

Les notions manipulées pour aller de la vision à la story, avec quelques techniques de définition de produit pour y arriver.

Ce quadrant montre 5 outils et 6 concepts situés dans 4 cases.

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

Ça peut s'articuler même si ce n'est pas obligé

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

Estimer les features indépendamment pour mieux les ordonner, les estimer avec les stories pour mieux planifier ou bien ne pas les estimer du tout (pour éviter de perdre du temps) ?

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 (voir l’image) Dans notre exemple, il y a 2 équipes, la rouge et la verte; les features sont associées à chaque équipe dans l’ordre des priorités; la feature en bleu sera associée plus tard.
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.