Revue de sprint Agile

Trois étapes pour de meilleures revues de sprints avec votre équipe Agile.

Dan Radigan Dan Radigan

Les revues de sprints ne sont pas des rétrospectives. Une revue de sprint vise à démontrer le dur labeur de toute l'équipe : les concepteurs, les développeurs et le responsable produit. Chez Atlassian, nous préférons que nos revues de sprint se passent dans une ambiance décontractée. Les membres de l'équipe se réunissent autour d'un bureau pour des démonstrations informelles et décrivent le travail qu'ils ont accompli pour cette itération. C'est le moment de poser des questions, d'essayer de nouvelles fonctionnalités et de donner votre avis. Le partage de la réussite est une partie importante de la formation d'une équipe Agile.

Avant de passer à la revue de sprint, cependant, commençons par comprendre pourquoi la définition que donne l'équipe au terme « terminé » est si importante pour cette « cérémonie » Agile.

Étape 1 : Définir statut « Terminé »

En tant qu'utilisateur régulier de Jira, il n'y a rien de plus satisfaisant pour moi que de déplacer une tâche de la colonne « Revue du code » à « Terminée ». Ce « sifflement » d'une carte Agile représente les tâches terminées que nous avons accomplies en équipe. Et voilà le travail !

Mise à jour d'un tableau Agile dans Jira

Franchir la ligne d'arrivée et terminer le travail nécessite une excellente planification, une définition claire de ce qui est « terminé » et une exécution disciplinée. La plupart du temps, cela se passe pendant la planification du sprint, mais pour assurer la réussite de la revue du sprint et du sprint lui-même, les équipes doivent aller plus loin que la planification. Elles doivent développer une culture claire de la façon de livrer le travail et de la signification d'un travail « terminé ».

Une culture de la livraison

Avec des équipes efficaces, chaque élément de travail est associé à des process clairs et une culture de développement. Utilisez ces questions pour évaluer vos process et pour vous assurer qu'ils fonctionnent de manière optimale pour votre équipe :

  • Les stories sont-elles bien définies par le responsable produit, le concepteur et l'équipe d'ingénierie avant l'implémentation ?
  • Tout le monde comprend-il et vit-il les valeurs et la culture d'ingénierie de l'équipe ?

  • Existe-t-il des définitions et des exigences claires concernant la revue du code, les tests automatisés et l'intégration continue pour encourager un développement Agile durable ?

  • Lorsque l'équipe termine une story, découvrez-vous de nombreux bugs ? En d'autres termes, « terminé » signifie-t-il vraiment « terminé » ?

La culture de l'équipe autour de la qualité et de l'achèvement devrait dépasser chaque user story, tâche d'ingénierie et bug. Cette culture reflète la façon dont l'équipe envisage et livre des logiciels.

Définition du statut « Terminé » pour chaque tâche

Une définition claire d'un travail « terminé » aide les équipes à se concentrer sur l'objectif final pour chaque tâche. Lorsque le responsable produit ajoute du travail au backlog de l'équipe, la définition des critères d'acceptation est un élément clé de son processus. Qu'est-ce que cela signifie pour une user story d'être « terminée » ? Chez Atlassian, l'équipe Jira suit les critères d'acceptation et les notes de test conformément au reste de la user story dans Jira. Ainsi, toute l'équipe a une vision claire de la réussite pour chaque ticket. Que sont les critères d'acceptation et les notes de test ?

  • Critères d'acceptation : les métriques utilisées par le responsable produit pour confirmer la story ont été implémentées selon ses désirs.
  • Notes de test : conseils brefs et ciblés de l'équipe de QA qui permettent à l'ingénieur de développement de mieux programmer les fonctionnalités et les tests automatisés.

Des tickets bien définis pendant l'implémentation permettent à tout le monde de réussir. Avec Jira, il est facile d'ajouter des champs dans la file. En tant qu'administrateur, cliquez simplement sur le bouton « admin » du ticket.

Étape 2 : Célébrer les accomplissements de l'équipe

Chez Atlassian, l'une de nos valeurs fondamentales est « Play, as a team ». Les revues de sprint sont un moment idéal pour célébrer l'équipe et les réalisations de chacun au cours d'une itération. Nous les organisons généralement le vendredi après-midi, quand tout le monde au bureau commence à se relâcher avant le week-end. Les revues de sprint ne sont pas synonymes de rétrospectives, alors assurez-vous d'organiser la revue de sprint après une itération, mais avant votre rétrospective. Les participants externes sont toujours les bienvenus, mais la réunion se compose généralement du responsable produit, de l'équipe de développement au complet et du Scrum Master. Au titre des bonnes pratiques, nous recommandons de passer 30 minutes à une heure sur chaque itération au cours de la réunion.

Nous aimons les revues de sprints, car elles stimulent l'efficacité et le moral de l'équipe. Les revues de sprints contribuent à souder l'équipe. La revue n'est pas accusatoire, ce n'est pas un examen. Il s'agit d'un événement collaboratif à l'échelle de l'équipe, au cours duquel certaines personnes présentent leur travail, répondent à des questions sur le terrain et obtiennent du feedback.

Si une revue de sprint ne devient pas une activité positive dans toute l'équipe, cela peut indiquer :

  • que l'équipe prend trop de travail et ne parvient pas à le terminer lors d'une itération ;
  • que l'équipe est aux prises avec une dette technique existante ;

  • que les fonctionnalités ne sont pas développées de façon durable pour s'assurer que de nouveaux bugs ne sont pas introduits dans la base de code ;

  • que les pratiques de développement de l'équipe ne sont pas aussi précises qu'elles pourraient l'être ;

  • que le responsable produit change les priorités au sein d'une itération, et que l'équipe de développement est mise sur la touche par la dérive des objectifs.

Remarque : chaque équipe rencontre des problèmes d'itération à un moment donné. Prenez le temps de comprendre pourquoi une itération change pendant la rétrospective de l'équipe et élaborez un plan pour traiter les tickets au cours du prochain sprint.

Étape 3 : Couvrir toutes les régions

Les entreprises dont les équipes sont distribuées doivent relever des défis particuliers lors du déploiement à grande échelle des « cérémonies » Agile dans plusieurs régions. Les revues de sprints ne font pas exception. Les membres de l'équipe Jira sont répartis dans le monde : Sydney, Gdańsk, Saigon et San Francisco. Même dans notre équipe distribuée, les revues de sprint constituent un élément essentiel de notre culture. Les membres de l'équipe créent des vidéos informelles et les partagent sur une page Confluence pour que tout le monde puisse les voir.

Ces vidéos informelles permettent de communiquer l'avancement du développement à tout le monde, indépendamment du décalage horaire. Voir une démonstration de la fonctionnalité directement par un développeur renforce l'équipe de deux façons :

  • Compréhension du produit : toute l'équipe est informée de l'objectif, de la justification et de l'implémentation de la fonctionnalité. Ainsi, tout le monde comprend mieux le produit dans son ensemble.

  • Team Building : les vidéos créent des liens plus personnels au sein de l'équipe. Chacun de nous peut voir qui est derrière chaque aspect d'un produit. Les liens tissés par cette pratique renforcent la cohérence au sein du groupe malgré la distance.

Un dernier conseil

Pour les équipes qui débutent dans les revues de sprint, il est très tentant d'assimiler la revue de sprint à la rétrospective. Une revue de sprint constitue une « cérémonie » indépendante d'une rétrospective de sprint. Prenez le temps de récolter les fruits de votre dur labeur. Célébrez dignement les réalisations. Des revues de sprints efficaces stimulent le moral et la motivation de l'équipe. Cette idée de « cérémonie » est vraiment essentielle dans l'équipe Jira, c'est pourquoi nous avons incorporé « en avant, célébrez » dans notre énoncé de vision.

Up Next
Standups