Cycle de vie des user stories
Auteur : Henrik Larsson
Source : Lifecycle of User stories
Date : 07/09/2011, màj le 20/09/2011
Traducteur : Fabrice Aimetti
Date : 07/09/2011, màj le 20/09/2011
Traduction :
Les user stories ont un cycle de vie qui démarre avec les ensembles minimums de features apportant une utilité/valeur aux utilisateurs (MUF / MMF), puis continue avec le développement pour communiquer les attentes du produit entre les développeurs et le product owner ainsi que les parties prenantes. Les user stories pilotent également le développement du produit logiciel pour livrer de nouvelles features. Pour en apprendre davantage sur les user stories, lisez Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Dean Leffingwell). Dean a également publié A User Story Primer.
1. Réunion de planification de la release : les features sont structurées en un premier ensemble de user stories. Ceci est réalisé par le product owner et tout ou partie de l'équipe de développement. Les user stories sont placées dans le backlog produit. Une cartographie - ou anatomie - du projet peut être un puissant outil pour montrer les dépendances entre les features (et user stories) et contribuer à la réunion de planification de la release.
2. Réunion de maintenance du backlog : ces user stories qui n'ont pas encore été présentées à une réunion de planification de sprint sont révisées, décomposées en plus petites stories, estimées et examinées. Les critères d'acceptation des stories sont discutés et des exemples de scénarios peuvent être définis. L'équipe de développement et le product owner participent à cette réunion. Cette activité fournit de bonnes informations au product owner pour bien réorganiser des éléments du backlog produit.
3. Réunion de priorisation avec les parties prenantes : le product owner rencontre les parties prenantes pour finaliser la repriorisation du backlog produit avant le sprint suivant. Cette réunion a généralement lieu quelques jours seulement avant le début de la réunion de planification du prochain sprint. Le product owner dispose d'informations provenant de l'activité de maintenance du backlog et de l'état d'avancement de l'équipe (dont les obstacles) issu de la dernière mêlée quotidienne (y compris du scrum de scrums). Les parties prenantes communiquent leurs besoins métiers les plus récents et mettent à jour les priorités. Les parties prenantes peuvent être un chef produit, un responsable des ventes, un directeur de clientèle, un delivery manager, d'autres product owners, etc.
4. Réunion de planification du sprint : le product owner présente un backlog produit ordonné avec des user stories. L'équipe révise les critères d'acceptation pour les user stories. L'équipe de développement analyse le backlog produit et s'engage sur un sous-ensemble contenant les user stories de plus haute priorité qu'ils réaliseront dans le cadre de ce sprint.
5. Début du développement de la story : aussi tard que possible (mais pas trop tard) au cours du sprint, pour minimiser le nombre de stories développées en parallèle. L'équipe de développement peut contacter le product owner pour obtenir des précisions sur la story. Les tests d'acceptation de la story sont rédigés et approuvés par le product owner. Certaines équipes ont trouvé utiles d'avoir une personne dans l'équipe qui soit le "pilote" de toutes les tâches associées à la story. Tous les autres membres de l'équipe sont disponibles pour réaliser les tâches, des séances de binômage, des discussions, ou toute autre forme d'aide pour terminer la story. Le rôle du pilote tourne dans l'équipe, donc pour la story suivante, c'est quelqu'un d'autre qui sera le pilote.
6. Mêlée quotidienne : l'état d'avancement de la user story est présenté au reste de l'équipe. Si l'équipe a adopté le rôle du pilote de la user story, cette personne présente alors toutes les activités réalisées et prévues pour cette story. Des obstacles ou un état d'avancement insuffisant peuvent conduire à modifier des tâches ou à en créer de nouvelles pour les membres de l'équipe. Cela concerne non seulement les développeurs, mais aussi le product owner et le scrum master.
7. Fin du développement de la story : un peu plus tard dans le sprint, la story a été conçue, codée et passe tous les tests unitaires ainsi que la suite de tests d'intégration. Les tests d'acceptation de la story passe sans aucun problème. Rendu à ce point, le product owner doit être contacté pour accepter la user story. Rappelez-vous de la définition du fini pour les user stories !
8. Réunion de revue de sprint : le périmètre entier du sprint de développement est présenté par l'équipe de développement et examiné par le product owner et les parties prenantes. Les tests d'acceptation des user stories sont exécutés pour démontrer les nouvelles fonctionnalités du système. Rappelez-vous de la définition du fini pour les sprints !
9. Suivi de la release : chaque user story finie contribue à l'avancement d'une ou de plusieurs features du produit. Ceci est maîtrisé par le product owner pour vérifier si la date de release et le contenu peuvent être maintenus.
Je vous invite à laisser un commentaire sur votre expérience du cycle de vie des stories. Quel est le maillon faible de cette chaîne ? Comment pouvons-nous améliorer le flux pour offrir plus de valeur aux utilisateurs / clients ?
