Revue de sprint Agile

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

Dan Radigan Dan Radigan
Parcourir les rubriques

Les revues de sprint ne sont pas des rétrospectives. Une revue de sprint vise à démontrer le dur labeur de toute l'équipe : les designers, 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émos 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.

Commençons par examiner pourquoi la définition que donne l'équipe au terme « terminé » est si importante pour cette « cérémonie » Agile.

Étape 1 : Définir l'état « 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 de 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

Dans les équipes efficaces, chaque tâche est associée à des processus clairs et à une culture de développement. Utilisez ces questions pour évaluer vos processus et pour vous assurer qu'ils fonctionnent de manière optimale pour votre équipe :

  • Les stories sont-elles bien définies par le Product Owner, le designer 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 de 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 de l'état « 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 Product Owner pour confirmer la story ont été implémentées selon ses désirs.
  • Notes de test : conseils brefs et ciblés de l'équipe 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. Grâce à 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 de « miser sur l'esprit d'équipe ». 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 Product Owner, 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 sprint, car elles stimulent l'efficacité et le moral de l'équipe. Les revues de sprint 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 Product Owner 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 sprint 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. Assister à une démo 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 ainsi tissés 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.

suivant
Standups