Création d'un journal des travaux en souffrance du produit
Votre équipe crée un journal des travaux en souffrance du produit, qui contient généralement des récits utilisateur, afin de représenter les besoins et souhaits des clients. Au cours du projet, votre équipe ajoutera des informations détaillées aux récits utilisateur, divisez-les en petits récits, classez-les par ordre de priorité et évaluez-les, enfin, implémentez-les et présentez les résultats à vos clients. En rédigeant des récits utilisateur utiles et en mettant à jour le journal des travaux en souffrance du produit de façon continue, votre équipe peut être plus efficace dans la création de valeur ajoutée pour ses clients.
Bill Wake résume ce qui fait un bon récit utilisateur au moyen de l'acronyme INVEST (indépendant, négociable, valorisé, estimable, succinct et testable). Pour plus d'informations, consultez le site Web suivant : XPlorations (page éventuellement en anglais). Mike Cohn explique comment écrire des récits utilisateur dans l'un de ses ouvrages, et vous pouvez télécharger le chapitre pertinent à partir du site Web à l'adresse suivante : User Stories Applied for Agile Software Development (page éventuellement en anglais).
Lorsque votre équipe crée un récit utilisateur, vérifiez qu'il représente une valeur pour le client en répondant aux questions suivantes :
Qui est l'utilisateur ?
Quels sont les besoins de l'utilisateur ?
Pourquoi l'utilisateur a t-il ces besoins ?
Dans la plupart des cas, votre équipe peut atteindre cet objectif en créant un titre efficace. Mike Cohn suggère le formulaire « En tant qu'<utilisateur>, je dois <action> afin de <motif> ». Vous pouvez consulter cette approche dans l'exemple « En tant que représentant du support technique, je dois accéder aux informations du client afin de pouvoir répondre plus rapidement aux questions de celui-ci ». Dans de nombreux cas, la raison est évidente. Par exemple, « En tant que végétarien, je peux filtrer ma vue pour consulter uniquement des repas végétariens ».
Les récits utilisateur doivent également être définis d'une façon qui leur permet d'être implémentés dans n'importe quel ordre. Toutefois, il n'est pas toujours pratique de rendre les récits utilisateur complètement indépendants. Bill Wake et Mike Cohn présentent des techniques que votre équipe peut utiliser lorsque la création de récits utilisateur indépendants s'avère difficile.
Les récits utilisateur qui sont utiles et indépendants, comme expliqué précédemment, sont contenus dans le journal des travaux en souffrance du produit. Ils sont estimés et classés par ordre de priorité, puis, votre équipe commence à travailler sur les récits utilisateur à la priorité la plus élevée. Avant que votre équipe implémente un récit utilisateur, il doit avoir les caractéristiques figurant dans la liste suivante. Votre propriétaire de produit travaillera pour s'assurer que les récits utilisateur à la priorité la plus élevée répondent à ces critères avant de les présenter à une réunion de planification de sprints.
Assez petit pour être implémenté dans le sprint
Les récits utilisateur qui vont être implémentés doivent être assez succincts pour être terminé au cours du sprint. Votre propriétaire de produit travaillera avec votre équipe pour diviser les récits utilisateur qui sont trop importants. Par exemple, le récit utilisateur « En tant que représentant du support technique, je dois accéder aux informations du client afin de pouvoir répondre plus rapidement aux questions de celui-ci » peut être trop important pour qu'il soit terminé dans un sprint. Il peut être divisé en récits tel que « En tant que représentant du support technique, je dois accéder au nom et au résumé des appels récents du client à l'aide du numéro de téléphone du client » et « En tant que représentant de support technique, je dois accéder à l'historique complet des appels des clients afin de pouvoir faire des recherches plus détaillées sur le problème actuel ».
Un descriptif suffisamment détaillé pour estimer le travail nécessaire pour implémenter le récit
Avant qu'ils soient inclus dans un sprint, les récits utilisateur sont estimés en points de récit. Ce sont des évaluations volontairement approximatives destinées principalement à gérer le journal des travaux en souffrance et à permettre de préparer le sprint. Lorsqu'un sprint démarre, votre équipe va scinder le récit utilisateur en tâches nécessaires à son implémentation. Votre équipe travaillera avec votre propriétaire de produit au cours de la réunion de nettoyage du journal des travaux en souffrance du produit afin de déterminer quels récits nécessitent plus d'informations avant d'être scindés en tâches pour estimer les heures de travail. Votre propriétaire de produit peut rassembler ces détails et les enregistrer dans la description du récit utilisateur.
Veillez à ne pas ajouter plus de détails au récit utilisateur que nécessaire. Le récit utilisateur doit être la base d'une conversation et d'une négociation avec votre propriétaire de produit et les clients qui se poursuivent jusqu'au terme et à l'acceptation du récit utilisateur. Une trop grande quantité de détails peut nuire à la négociation et impliquer une recherche de précision qui n'est pas exacte.
Définition des critères d'acceptation
À la fin d'un sprint, vos clients ou votre propriétaire de produit acceptera le récit utilisateur comme étant terminé ou le rejettera. Avant le démarrage du sprint, les critères d'acceptation du client doivent être décrits aussi clairement que possible. Évidemment, un récit utilisateur peut ne pas être accepté pour des raisons imprévues. Toutefois, les conversations entre votre équipe et les clients permettent de définir les critères d'acceptation destinés à vérifier que votre équipe comprend les attentes de vos clients. Les critères d'acceptation peuvent être utilisés comme base pour les tests d'acceptation afin que vous puissiez évaluer plus efficacement si vous avez terminé un récit utilisateur.
Narrations et thèmes
On considère fréquemment que les récits utilisateur doivent être courts. Cela est vrai pour les récits utilisateur qui sont sur le point d'être implémentés. Toutefois, les récits d'une priorité inférieure peuvent être d'une taille plus importante. En fait, garder aux récits une taille importante est un bon moyen d'empêcher votre journal des travaux en souffrance du produit de devenir trop important à gérer. Les récits utilisateur peuvent être scindés en récits utilisateur plus petits au fur et à mesure qu'ils atteignent le plus haut du journal des travaux en souffrance du produit classés par ordre de priorité. Il est utile de considérer les récits utilisateur importants comme des narrations et des thèmes.
Les narrations sont des récits utilisateur très importants qui représentent une quantité significative de travail. Lorsque vous scindez une narration, vous pouvez créer de nombreux thèmes et récits utilisateur plus petits.
Les thèmes sont des récits utilisateur assez grands, généralement plus grands que ceux implémentés dans un sprint. Avant que votre équipe implémente un thème, celui-ci doit être scindé en récits utilisateur plus petits.
Lorsque vous classez par ordre de priorité le journal des travaux en souffrance du produit, scindez les narrations et les thèmes qui sont près du haut et donnez la priorité à des récits utilisateur nouveaux et plus petits. Lorsque vous avez terminé, les récits utilisateur qui ont la priorité la plus élevée doivent être assez petits à implémenter. Occupant un ordre de priorité moindre dans le journal des travaux en souffrance, la plupart des récits utilisateur sont généralement plus grands.
Pics d'activité
Votre équipe devra parfois s'acquitter d'un travail qui ne relève pas d'une implémentation directe d'un récit utilisateur. Ce travail est appelé un pic d'activité. Les trois types courants de pics d'activité sont les recherches, le nombre de bogues et les améliorations de processus ou d'ingénierie. Pour créer un pic d'activité dans Team Foundation, créez un élément de travail de récit utilisateur, définissez le type de pic d'activité, puis donnez-lui la priorité dans le journal des travaux en souffrance du produit avec les autres récits utilisateur.
Recherche
Les recherches se produisent en présence de questions ouvertes relatives à un récit utilisateur et qui doivent être traitées avant de pouvoir scinder le récit utilisateur complètement en tâches et de l'estimer. Par exemple, l'équipe traite le récit « En tant que voyageur fréquent, je peux réserver un voyage » pendant une réunion de planification de sprints. Après l'avoir traité, ils ont plus de questions que de réponses. L'équipe crée un récit utilisateur pour représenter le pic d'activité. " « En tant que membre de l'équipe, je peux comprendre ce que 'réserver un voyage' signifie afin de pourvoir écrire des récits à inclure dans les futurs sprints ». L'équipe détermine le nombre d'heures qu'elle peut consacrer à cette recherche et entre le nombre comme délai pour le pic d'activité. Aucun des récits écrit pendant le pic d'activité ne peut avoir lieu pendant cette itération. Le travail doit être planifié pour une future itération à l'aide du journal des travaux en souffrance du produit.
Nombre de bogues
Le meilleur moment pour résoudre un bogue est au cours de sa recherche. Si vous ne pouvez pas le résoudre le même jour que vous le recherchez, vous devez créer un élément de travail Bogue pour en assurer le suivi. Évitez d'accumuler les bogues. Si votre équipe accumule des bogues, créez un récit utilisateur, et liez les bogues au pic d'activité afin qu'il puisse être estimé et classé par ordre de priorité avec d'autres récits utilisateur et pics d'activité.
Améliorations de processus ou d'ingénierie
Votre équipe se chargera des améliorations de processus ou d'ingénierie qui l'aideront à réussir. Ces améliorations sont souvent identifiées pendant les réunions de scrum quotidiennes et les rétrospectives de sprint. Par exemple, votre équipe devra peut-être améliorer la couverture du code à l'aide des tests unitaires ou réduire le temps de génération sur le serveur de l'intégration continue.