17 mars 2010
Dans un contexte agile, le déroulement d’un sprint (ou itération) est rythmé par la tenue de réunions:
- La planification du sprint, la réunion de lancement pour définir le périmètre fonctionnel du sprint ;
- Le daily scrum, la réunion journalière où chaque équipier répond aux trois questions
- qu’ai-je fait hier ?
- que vais-je faire aujourd’hui ?
- ai-je des problèmes ?
Elle permet de détecter au plus vite les éventuels problèmes et de prendre les mesures nécessaires à leur résolution ;
- La revue du sprint, que nous allons traiter dans le présent billet ;
- La rétrospective, qui permet de tirer bilan et enseignements du sprint qui vient de se terminer.
Nous vous recommandons vivement la lecture de Scrum and XP from the trenches, d’Henrik Kniberg, pour une présentation in extenso de ces réunions.
Dans ce billet, nous nous intéressons à la revue du sprint dans un contexte particulier dont nous sommes familiers : l’éloignement géographique des parties prenantes. Nous présenterons tout d’abord l’objectif de la revue, listerons les participants et leurs rôles et enfin exposerons comment gérer de la meilleure des manières la distance lors de cette réunion.
L’objectif de la revue de sprint
Une fois le sprint terminé, l’équipe procéde à la démonstration du produit qu’elle s’apprête à livrer. Grâce à cette revue, elle obtient un feedback direct sur les fonctionnalités qui ont été développées. Outre ce feedback, cette réunion est également l’occasion d’impliquer l’équipe de développement et de lui permettre d’être confrontée aux attentes du client.
La revue de sprint présente d’autres avantages. A cette occasion, l’équipe recueille le mérite du travail accompli. C’est aussi une ouverture vers l’extérieur : les personnes de la société qui ne prennent pas part au développement d’une application peuvent assister à sa démonstration, découvrir ce qui a été fait, partager leurs connaissances, et remonter leur feedback.
Les participants et leurs rôles lors de la revue
Tout le monde est invité !
- L’équipe de développement : elle est ici pour présenter le produit. Elle a préparé le script de la démonstration, et chaque équipier a l’occasion de présenter une ou plusieurs fonctionnalités ;
- Le Scrum Master s’assure que le feedback utilisateur est bien recueilli. Il peut également faire ses remarques sur le produit ;
- Le Product Owner lance la réunion en rappelant quel était l’objectif du sprint, liste les user stories qui ont été traitées, note scrupuleusement toutes les remarques et corrections demandées et bien sûr valide (ou pas) les user stories ;
- Les représentants des utilisateurs et le sponsor du projet sont là pour faire leurs remarques, leurs demandes de corrections et d’évolutions. La démonstration est un moment privilégié pour recueillir une partie des besoins utilisateurs.
Un contexte particulier : un client éloigné géographiquement
Pour une application que nous avons développée, nous étions dans la situation suivante : les représentants des utilisateurs étaient pour l’un aux Etats-Unis et pour l’autre en Allemagne. Que faire, sachant que se passer du client pour cette réunion, lui retirerait l’essentiel de son intérêt ?
Il n’y a alors guère plus que deux options possibles :
- Se déplacer ou faire déplacer les parties prenantes côté client. Cela n’est pas toujours possible, et peut être coûteux. Et la taxe carbone gonflerait
- Mettre en place une revue distante.
Vous l’avez compris, nous retenons la seconde option pour maintenir ce cérémonial Scrum. Cela requiert l’organisation d’une conférence téléphonique et l’utilisation d’un outil de réunion en ligne pour que les représentants des utilisateurs puissent suivre sur leur poste la démonstration. Dernièrement, nous avons opté pour Cisco WebEx qui est très efficace. L’organisation de la réunion en ligne est simple et rapide, et le rendu est suffisamment fluide pour les participants.
Concrètement, un poste est utilisé pour faire cette démonstration. A partir de ce poste, la réunion web est initiée, les participants côté client sont invités par mail. Une fois que tous les participants ont rejoint la salle de réunion virtuelle, l’écran est partagé et la démonstration se déroule. Les équipiers se succèdent pour que chacun puisse démontrer les nouvelles fonctionnalités. Dans pareil cas, il faut être encore plus scrupuleux dans la préparation de la démonstration. Attention à bien prendre en compte l’éventuelle barrière de la langue : les démonstrateurs doivent prendre encore plus leur temps et au préalable avoir préparé leurs interventions orales. Une telle démonstration est exempte des petits détails : il vaut mieux être sélectif sur les comportements à présenter, se concentrer sur ce qui est réellement important de montrer.
Pour le reste, nous rentrons dans le cadre d’une démonstration ‘classique’ : les équipiers présentent les fonctionnalités, les comportements, les clients posent leurs questions et font leurs remarques.
Conclusion
La revue de sprint permet de constater l’avancement du produit, de recueillir un feedback direct des parties prenantes, d’impliquer et de rassembler l’intégralité des intervenants régulièrement. Bien entendu, l’éloignement géographique ne peut justifier son absence. Cette réunion est nécessaire à plus d’un titre: les clients savent exactement où en est le développement du produit en y étant confronté, ils peuvent modifier ses comportements. A l’issue de cette réunion, le Product Owner est en mesure de modifier son backlog en y ajoutant, retirant ou modifiant des user stories, ou de gérer ses priorités de développement. Avec les outils de réunion en ligne actuellement disponibles, il ne serait pas raisonnable de s’en passer !
Aucun commentaire.
Ajouter votre commentaire