Pourquoi devriez-vous envisager d'arrêter les revues de sprint ? : Différence entre versions

De Wiki Agile du @GroupeCESI
Aller à : navigation, rechercher
(La Revue de Sprint a-t-elle encore un rôle à jouer dans le cadre d'une livraison continue ?)
(L'aspect éducatif des revues de sprints)
Ligne 70 : Ligne 70 :
  
 
== L'aspect éducatif des revues de sprints ==
 
== L'aspect éducatif des revues de sprints ==
Il y a aussi un aspect éducatif aux évaluations de sprint. Si une équipe livre continuellement et utilise des mini-examens ponctuels, il se peut que chaque élément soit vu par au moins un intervenant avant d'être livré. Cependant, avec cette approche, de nombreux intervenants ne seront pas au courant d'une grande partie du travail du sprint.
+
Il y a aussi un aspect éducatif que l'on peut reconnaître aux revues de sprint. Si une équipe livre continuellement et utilise des mini-revues ponctuelles, il se peut que chaque élément soit vu par au moins une partie prenante avant d'être livré. Cependant, avec cette approche, de nombreuses parties prenantes seront ignorants d'une grande partie du travail du sprint.<br/>
 
+
<br/>
Par exemple, une équipe peut se déployer 50 fois pendant un sprint. On vous en a montré cinq avant qu'ils n'arrivent. On m'en a montré cinq autres. Mais aucun de nous n'a tout vu.
+
Par exemple, une équipe déploie 50 fois durant le sprint. On vous en a montré cinq avant qu'elle n'aie fini. On m'en a montré cinq autres. Mais aucun de nous n'a tout vu.<br/>
 
+
<br/>
Cela donne au sprint review un aspect éducatif, car c'est le seul moment où tout le monde voit tout. Le fait de voir les fonctionnalités livrées dans le contexte d'un ensemble plus large de fonctionnalités peut générer de nouvelles idées (nouveaux arriérés de produits) mais peut aussi changer si les parties prenantes approuvent ou rejettent les mises en œuvre.
+
Cela donne à la revue de sprint un aspect éducatif, car c'est le seul moment où tout le monde voit tout. Le fait de voir les fonctionnalités livrées dans le contexte d'un ensemble plus large de fonctionnalités peut générer de nouvelles idées (nouveaux éléments dans le backlog produit) mais peut aussi changer si les parties prenantes approuvent ou rejettent les implémentations.
  
 
== Ce qu'il faut faire ==
 
== Ce qu'il faut faire ==

Version du 30 août 2019 à 17:37

Auteur : Mike Cohn
Source : Why you should consider stopping sprint reviews
Date : 08/2019


Traducteur : Fabrice Aimetti
Date : 30/08/2019


Traduction :

2019-08-27-why-you-should-consider-stopping-sprint-reviews-quote.png

Pour beaucoup d'équipes, la revue de sprint a fait son temps et il est temps d'arrêter de le faire.

Blasphème ? Peut-être, mais écoutez-moi.

Le But de la Revue de Sprint

Le but de la revue de sprint est de permettre à l'équipe d'obtenir des retours sur ce qu'elle a développé. Cette boucle de rétroaction peut donner lieu à de nouveaux éléments dans le backlog produit qui représentent soit de nouvelles idées de fonctionnalités, soit des ajustements sur ce qui a été récemment développé. Le product owner tient compte de cette rétroaction pour finaliser les priorités pour le sprint à venir.

Parce que son but est de recueillir des retours sur ce qui a été développé, la revue se fait traditionnellement à la fin du sprint. Pour la plupart des équipes, cela se fait immédiatement avant la rétrospective.

Mais, organiser une revue de sprint à la fin du sprint intervient trop tard pour beaucoup d'équipes. Tout retour recueilli pendant la revue arrive trop tard pour que l'équipe puisse l'utiliser dans le sprint en cours.

Les équipes le savent depuis des années. Dans presque tous les cours Certified Scrum Master dans lesquels j'enseigne, on me pose des questions comme :

  • L'équipe peut-elle s'attribuer le mérite d'un élément du backlog produit terminé s'il y a une rétroaction qui nécessite un changement ?
  • Et si c'était un petit changement ?
  • Et si le changement était vraiment une amélioration ?

Depuis des années, la réponse standard est que les équipes doivent montrer leur travail au product owner au plus tôt et de manière continue. Il n'y a jamais eu de règle selon laquelle la rétroaction ne pouvait avoir lieu qu'à la fin du sprint lors d'une revue formelle.

Mais les temps ont changé. Il y a dix ans, de grandes équipes intégraient continuellement leur code - chaque fois que le code était reversé, un build était déclenché et des tests automatisés confirmaient que tout fonctionnait encore.

Désormais, les grandes équipes délivrent ou déploient en permanence du code. Elles ne se contentent pas d'effectuer des tests automatisés après avoir reversé le code, de nombreuses équipes déploient après chaque contribution.

Cela change complètement la nature de la revue de sprint.

Considérez la situation d'une équipe qui fournit de nouvelles fonctionnalités à la production en moyenne sept fois par jour. Pour une grande équipe de développement web, ce n'est pas inhabituel de nos jours.

Comment se déroulera la discussion lors de la revue de sprint à la fin d'un sprint de dix jours ? Au cours de cette période, l'équipe a livré 70 nouvelles choses (sept par jour pendant dix jours).

J'imagine que l'équipe a demandé aux parties prenantes dans une revue : "Alors, que pensez-vous des 70 nouvelles choses que nous avons développées ?"

Et les parties prenantes répondent : "Qui se soucie de ce que nous pensons ? Que pensent nos utilisateurs ? Ils ont déjà utilisé ces fonctionnalités."

Dans le monde de la livraison continue / du déploiement continu, il est trop tard pour obtenir les retours des parties prenantes dans le cadre d'une revue de fin de sprint - les utilisateurs utilisent déjà la fonctionnalité et les meilleurs retours viendront d'eux.

Qu'est-ce qui devrait remplacer la Revue pour ces équipes ?

Si une unique et officielle revue de fin de sprint n'est pas appropriée pour les équipes qui publient fréquemment, que devraient-elles faire à la place ?

Elles devraient recueillir des retours souvent et à petites doses. Dès qu'un élément du backlog produit est terminé, les membres de l'équipe devraient le montrer à une ou trois parties prenantes qui ont besoin de le voir avant qu'il ne soit publié. Souvent, cela peut être uniquement le demandeur de la nouvelle fonctionnalité et le product owner, quand ne s'agit pas de la même personne.

Un ou deux des membres de l'équipe qui ont travaillé sur l'élément du backlog produit organisent une démonstration rapide au demandeur. Ils montrent l'élément, et s'il répond aux attentes du demandeur, il est livré, tout de suite.

Peut-être deux heures plus tard, d'autres membres de l'équipe ont terminé un autre élément du backlog produit. Ils rencontrent la ou les deux parties prenantes qui ont demandé cet élément et peut-être aussi le product owner, font une démonstration rapide et livrent cette fonctionnalité.

Ce schéma peut se répéter aussi souvent que nécessaire. Parfois, bien sûr, ces mini-revues à la volée peuvent être regroupées : l'équipe peut montrer 2 ou 3 choses au product owner en une seule fois, puis tout livrer si approuvées. Et dans de nombreux cas, un niveau de confiance entre l'équipe de développement, le product owner et les parties prenantes permet à l'équipe elle-même de prendre l'initiative d'offrir la fonctionnalité sans la mini-revue. Cela peut devenir une exigence si l'équipe sait livrer extrêmement rapidement.

Le risque à laisser une équipe prendre la décision n'est pas énorme. Beaucoup de ces changements sont isolés et ne représentent que des dizaines de lignes de code. Si une équipe publie par erreur quelque chose que le product owner n'approuve pas, la nouvelle fonctionnalité peut généralement être modifiée rapidement ou retirée.

La Revue de Sprint a-t-elle encore un rôle à jouer dans le cadre d'une livraison continue ?

Il y a une raison pour laquelle ça s'appelle la revue de sprint plutôt que quelque chose comme la démo du sprint. Cette subtile différence de nom rappelle aux équipes qu'une revue de sprint est plus qu'une démo. La démo est l'activité centrale et le point d'attention de la plupart des revues, mais il se passe davantage dans une bonne revue de sprint qu'une simple démo.

Une revue de sprint est l'occasion pour l'équipe et les parties prenantes de discuter des priorités et du calendrier pour le produit. De tels sujets sont courants :

  • Après avoir vu ce qui a été terminé dans le sprint courant, que pensez-vous qu'il faudrait faire dans le sprint suivant ?
  • Y a-t-il des éléments du backlog produit dont la priorité devrait être revue à la baisse ou à la hausse ?
  • Y a-t-il des éléments du backlog qui ne sont plus nécessaires et qui peuvent être abandonnés ? Y a-t-il une opportunité de publier le travail du sprint en cours ?

Si votre équipe livre en continu et aborde ce genre de sujets lors de ses revues de sprint, vous trouverez peut-être utile de tenir une revue traditionnelle de fin de sprint, même si les éléments du backlog produit ont été individuellement pré-approuvés à la volée de la manière que je viens de décrire.

L'aspect éducatif des revues de sprints

Il y a aussi un aspect éducatif que l'on peut reconnaître aux revues de sprint. Si une équipe livre continuellement et utilise des mini-revues ponctuelles, il se peut que chaque élément soit vu par au moins une partie prenante avant d'être livré. Cependant, avec cette approche, de nombreuses parties prenantes seront ignorants d'une grande partie du travail du sprint.

Par exemple, une équipe déploie 50 fois durant le sprint. On vous en a montré cinq avant qu'elle n'aie fini. On m'en a montré cinq autres. Mais aucun de nous n'a tout vu.

Cela donne à la revue de sprint un aspect éducatif, car c'est le seul moment où tout le monde voit tout. Le fait de voir les fonctionnalités livrées dans le contexte d'un ensemble plus large de fonctionnalités peut générer de nouvelles idées (nouveaux éléments dans le backlog produit) mais peut aussi changer si les parties prenantes approuvent ou rejettent les implémentations.

Ce qu'il faut faire

Je ne considère plus le sprint review comme un élément obligatoire de Scrum. Pour de nombreuses équipes, elle reste appropriée et aussi utile que jamais. Une équipe qui se déploie tous les trimestres, par exemple, est susceptible de bénéficier de l'examen de fin de tirage traditionnel, officiel et officiel, tel qu'il a été décrit et appliqué pendant des années.

D'autres équipes, cependant, en particulier celles qui se déploient ou livrent continuellement, trouvent l'examen traditionnel du sprint trop tard pour obtenir des commentaires utiles.

Pour ces équipes, l'obligation d'effectuer un sprint review est remplacée par une règle de "feed-back".

C'est à eux de décider quand et comment ils recevront la rétroaction, mais bon nombre d'entre eux choisissent de le faire sous forme d'évaluations ponctuelles et de mini-fonctions. Lorsqu'un élément est terminé, il est montré au petit groupe de personnes qui l'ont demandé ou qui en sont affectées. Dans certains cas, ces mini-examens peuvent avoir lieu plusieurs fois par jour.

Mais l'élimination totale de l'examen du sprint peut s'avérer trop lourde pour certaines équipes. C'est parce qu'une bonne critique a toujours été plus qu'une simple démonstration du produit. Ces équipes effectuent les mini-examens que j'ai décrits, mais elles les compléteront par un examen de fin de sprint, comme d'habitude, mais en mettant davantage l'accent sur l'aspect éducatif et le partage des connaissances de l'examen.

Qu'en pensez-vous ?

Avez-vous parfois l'impression qu'il est trop tard pour revoir le travail seulement à la fin du printemps ? Comment votre équipe s'est-elle adaptée en obtenant plus tôt les commentaires des utilisateurs et des intervenants ? Si votre équipe fournit ou déploie continuellement des services, êtes-vous passé à des examens ponctuels ? Veuillez nous faire part de vos réflexions dans les commentaires ci-dessous.