-
Notifications
You must be signed in to change notification settings - Fork 2
Post sprint review WIP #214
base: master
Are you sure you want to change the base?
Changes from 6 commits
2d11bb5
adda8ba
e7cb6c2
4b5a2b7
2c68a5a
2d556eb
5f401f5
2e5cda1
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,102 @@ | ||
--- | ||
type: "post" | ||
title: "Présenter une revue produit en fin d'itération Scrum" | ||
date: "2018-04-16" | ||
publishdate: "2018-12-07" | ||
draft: true | ||
slug: "scrum-sprint-demo" | ||
description: "La revue d'itération, un moment privilégié pour échanger sur le produit en cours de développement" | ||
|
||
thumbnail: "/images/posts/thumbnails/50-quick.jpg" | ||
header_img: "/images/posts/headers/elao_team_front.jpg" | ||
tags: ["agile", "user stories", "Scrum", "sprint review", "sprint demo", "revue itération", "revue produit"] | ||
categories: ["methodo"] | ||
|
||
author_username: "ssolere" | ||
|
||
--- | ||
|
||
La **revue de fin d'itération** ou sprint review est un moment privilégié pour **échanger sur le produit** en cours de développement. Une **bonne organisation** de cet atelier permet d'en **tirer le maximum**.<!--more--> | ||
|
||
## La revue d'itération | ||
|
||
En fin d'itération, l'équipe Scrum (ou autre approche similaire) se réunit pour présenter le résultat de l'itération à toutes les personnes concernées (parties prenantes ou pas). Il s'agit d'un moment d'échange où les parties prenantes peuvent voir l'avancée du produit et l'équipe peut être à leur contact. | ||
|
||
On parle souvent de revue d'itération (sprint review) plutôt que démonstration car il s'agit d'un moment d'échange et pas uniquement d'une démonstration de ce qui a été fait. | ||
|
||
Tout le monde peut donc prendre connaissance de ce qui a été fait, décidé. Chacun peut alors participer à la construction du produit. | ||
|
||
### Impliquer les parties prenantes | ||
|
||
Impliquer les parties prenantes peut générer des interrogations de la part de personnes qui n'ont pas participé activement à la création du produit. Il vaut mieux les laisser s'exprimer; il sera alors encore temps pour le product owner d'inclure des modifications en discussion avec l'équipe si ces débats sont pertinents. | ||
|
||
S'il y a des divergences fortes, le product owner peut choisir de traiter ces points pendant un atelier dédié. | ||
|
||
L'équipe peut aussi avoir des retours sur des éléments qui l'impactent : | ||
|
||
* le juridique peut évoquer une nouvelle loi qui impacte le produit (RGPD par exemple), | ||
* les utilisateurs ou leurs représentants peuvent parler de leurs attentes | ||
* les experts peuvent présenter des problématiques futures à adresser dans le produit | ||
|
||
Toutes les personnes impliquées dans le produit directement ou indirectement ont la possibilité d'échanger. Le product owner peut donc s'appuyer sur ces échanges pour continuer le développement produit et encourager ces échanges aussi en dehors de la revue produit. | ||
|
||
Les parties prenantes ne peuvent pas participer, on peut filmer la revue pour la diffuser en interne. | ||
|
||
### Parler du travail de l'équipe | ||
|
||
L'équipe peut faire un bilan de ce qui était prévu, de ce qui n'a pas pu être livré et des difficultés rencontrées. Ceci permet de recadrer la planification etle budget avec les éléments les plus à jour. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. - a planification etle budget
+ a planification et le budget Manque l'espace entre "et" et "le" |
||
|
||
Il ne s'agit pas de se dédouaner, de se flageler ou de chercher un coupable. Cette transparence permet de bien faire comprendre les contraintes du développement d'un produit aux personnes qui ne sont pas directement impliquées. | ||
|
||
Les équipes impactées par le produit peuvent alors s'organiser, planifier leurs activités et de remonter leurs propres contraintes. | ||
|
||
## Organiser la revue | ||
|
||
Une revue préparée permettra de laisser plus de place aux échanges plutôt qu'à la démonstration du produit. | ||
|
||
Il est alors conseillé de préparer cette revue en amont : ce qui doit être présenté, qui doit le présenter. Pour fluidifier encore plus la revue, on peut aussi organiser les rôles de chaque membre de l'équipe. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Peut être dire aussi qu'on peut préparer des jeux de données en amont pour montrer certains cas particulier ? |
||
|
||
### Présenter l'avancement | ||
|
||
Avant la démonstration du produit, le product owner présente ce qui a été fait et ce qui n'a pas pu être fait sur l'itération. Il expliquera les problèmes rencontrés à son niveau mais laissera le soin à l'équipe de présenter le travail réalisé ainsi que l'organisation de l'itération. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. - Il expliquera les problèmes rencontrés
+ Il expliquera les problèmes rencontrés Double espace entre "problèmes" et "rencontrés" |
||
|
||
Il intervient en fin de revue pour se projeter sur les futures itérations à partir des éléments apportés pendant le sprint et de retours du la revue. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. - et de retours du la revue.
+ et des retours de la revue. |
||
|
||
### Scénariser la revue | ||
|
||
Pour faciliter un atelier, on peut attribuer des rôles dédiés. La fluidité permettra d'aller à l'essentiel. Le product owner peut alors être en retrait pour être disponible pour des discussions liées au produit. | ||
|
||
On introduit alors 3 rôles principaux qu'on peut faire tourner : | ||
|
||
* un rôle de scénariste : le scénariste s'assure de la fluidité de la revue de produit | ||
* il explique l'organisation de l'équipe sur l'itération | ||
* il organise le fil conducteur de la démo | ||
* il recueille les données utilisées pour cette démo | ||
* il aiguille l'acteur durant la démonstration et peut répondre aux questions du groupe | ||
* il ne s'agit par forcément du prduct owner mais le PO peut aider le scénariste dans cette tâche | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. - il ne s'agit par forcément du prduct
+ il ne s'agit pas forcément du product par => pas |
||
* il travaille avec les autres rôles pour faciliter cet atelier | ||
* un rôle de scribe : le scribe suit les déroulement de la démo | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. - le scribe suit les déroulement
+ le scribe suit le déroulement le déroulement ou les déroulements |
||
* il note les bugs et les micro-évolutions | ||
* il note les échanges à avoir sur des fonctionnalités | ||
* il peut aussi cumuler le rôle de gardien du temps et s'assure que les échanges trop longs soient traités au cours d'un autre atelier | ||
* un rôle d'acteur : l'acteur déroule la revue | ||
* il présente les user stories en suivant le fil décidé avec le scénariste | ||
* il anime les échanges | ||
|
||
Chaque rôle collabore avec les autres rôles pour aider à la fluidité. L'équipe peut adresser des problèmes d'organisation de la revue pendant la rétrospective. | ||
|
||
### Faire tourner les rôles | ||
|
||
Tout le monde dans l'équipe de développement peut prendre un rôle. On peut laisser à chacun le droit de ne pas endosser un rôle en particulier, par exemple le rôle d'acteur qui demande de parler en public, particulièrement si la revue se fait devant un grande partie de l'entreprise. | ||
|
||
## La pratique | ||
|
||
La préparation de la revue est importante et permet de se concentrer sur les échanges. | ||
|
||
L'attribution des rôles est moins courante. Elle permet l'implication de toute l'équipe. Une équipe en difficulté peut y trouver un cadre pour se recentrer. | ||
|
||
Les équipes Elao ont l'habitude de mener des revues sur ce format. En plus des échanges bénéfiques au produit, nous pouvons travailler sur la confiance qui permettra à nos partenaires de développer le produit dont ils ont besoin. | ||
|
||
N'hésitez pas à nous faire vos retours sur vos pratiques de revue produit. | ||
|
||
En parlant de retour, vous pouvez consulter la chaine Scrum Life : https://youtu.be/qWRrW9_h3DU |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Si avant
les parties prenantes
?