Post sprint review WIP

content/methodo/revue-de-produit.md

@@ -0,0 +1,106 @@
+---
+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
+
+Toutes les personnes impliquées dans le produit directement ou indirectement ont la possibilité d'échanger pendant la reuvue d'itération. Le PO peut donc s'appuyer sur ces échanges pour continuer le développement produit et encourager ces échanges aussi en dehors de la revue produit.
+
+Impliquer les parties prenantes permet d'interagir avec elles directement. Cela 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 (PO) d'inclure des modifications en discussion avec l'équipe si ces débats sont pertinents.
+
+S'il y a des divergences fortes, le PO peut choisir de traiter ces points pendant un atelier dédié.
+
+### S'aligner avec les parties prenantes
+
+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
+
+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 et le budget avec les éléments les plus à jour.
+
+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.
+
+On peut préparer cette revue en amont. Pour fluidifier encore plus la revue, on peut aussi organiser les rôles de chaque membre de l'équipe.
+
+### Présenter l'avancement
+
+Avant la démonstration du produit, le PO 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. 
+
+Il intervient en fin de revue pour se projeter sur les futures itérations à partir des éléments apportés pendant le sprint et à partir 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 PO 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 pas forcément du PO mais le PO peut aider le scénariste dans cette tâche
+	* il travaille avec les autres rôles pour faciliter cet atelier
+* un rôle de scribe : le scribe suit le déroulement de la démo
+	* 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.
+
+Une préparation ne devrait pas durer plus d'une heure. On fera attention si cette préparation est longue. C'est sans doute le signe d'autres problèmes au niveau de l'organisation de l'équipe.
+
+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. Jean-Pierre parle plus en détails de la revue et de ses travers : https://youtu.be/qWRrW9_h3DU et https://youtu.be/zeXpOHpohso