Écrire de meilleures histoires d'utilisateurs – Perficient Blogs

Les équipes qui prennent le backlog de produit au sérieux sont plus efficaces, ce qui signifie qu’il faut accorder plus d’attention à l’arriéré et s’assurer collectivement d’une compréhension commune de:

• Que faut-il?
• pourquoi se fait-il?

Dans ce blog, je vais explorer les idées présentées par Mike Cohn de Mountain Goat Software, qui visent à amener les équipes à écrire de meilleures histoires d'utilisateurs. De meilleures histoires, à leur tour, se traduisent par une communication plus claire des parties prenantes et par des résultats attendus du sprint plus définis et bien définis. p.ex. parties prenantes), qu’il est possible d’achever en un trimestre et qui sont suffisamment importants pour apporter une valeur réelle à l’organisation. Une fois les objectifs définis, l’ensemble de l’équipe (c’est-à-dire le responsable du produit, les Scrum Masters, l’équipe de développement, etc.) se réunit pour examiner et développer les récits utilisateur sous-jacents. Cette session devrait durer environ 1 à 3 heures, car moins d’une heure suggère que l’objet n’était pas assez grand et plus de 3 heures, c’était trop. Cela peut commencer par une carte d'histoires «Big Rock» pour définir les composants les plus importants pouvant être affinés pour créer des histoires d'utilisateurs suffisamment détaillées pour que l'équipe de développement puisse commencer. Une fois les récits définis, la liste entière est consolidée dans une carte de récits, qui fournit une visualisation des récits d'utilisateurs, ainsi que des récits techniques / opérationnels qu'il peut être nécessaire d'ajouter. Lorsque l'atelier est terminé, tout le monde est aligné sur les objectifs et comprend le travail. Il est important de noter que les histoires parfaites ne sont pas le but recherché, car une histoire peut toujours être affinée. Cependant, si nous voulons que l’histoire contienne suffisamment d’informations pour les développeurs et qu’elle ait le bon contexte, nous devrions obtenir le résultat souhaité. Si les fonctionnalités requises supplémentaires sont déterminées ultérieurement, nous les ajoutons au backlog de produit et terminons le travail.

Exemple de carte récit

Résultats attendus de l'atelier

1. Objectifs significatifs pour le trimestre (approuvés par les parties prenantes)
2. Un backlog de produits contenant le jeu initial d'histoires utilisateur, techniques et opérationnelles atteindre les objectifs
3. Une carte narrative illustrant de manière visuelle les histoires qui permettront d’atteindre les objectifs

Maîtriser l’art de scinder les histoires

Lancé, En cours, Terminé) et fournissent un mécanisme permettant de fournir des logiciels «potentiellement livrables». Le problème est que les équipes considèrent «potentiellement livrable» comme «prêt pour le marché», ce qui conduit à des engagements de scénario qui ne sont pas réalistes pour la période, donc à des objectifs de livraison de sprint.

1. Fractionnement par interface – Imaginons que nous construisons un site Web qui vous permet de rechercher des propriétés à vendre. Le travail implique à la fois une interface et une base de données. Une façon de réduire ce travail consiste à fournir un petit nombre de champs, y compris les composants de base de données, à chaque itération entièrement construite, testée et déployée. À chaque itération, plusieurs champs sont ajoutés et les lois de l'amélioration continue sont appliquées pour fournir une application qui respecte les objectifs. calculer une seule sortie. Certaines de ces entrées sont simples et faciles à réaliser, d’autres nécessitent des efforts particuliers et quelques-unes sont extrêmement complexes. Dans ce cas, une stratégie peut être de créer initialement des espaces réservés (par exemple des valeurs fixes) pour chacune de ces entrées et de développer les cas de test automatisés, puis, à chaque itération, de compléter la fourniture des entrées. Certains peuvent nécessiter plusieurs sprints, mais le résultat final est un résultat prévisible et qui s'améliorera à chaque itération.

Efforcez-vous d'ajouter Juste assez de détails, juste à temps

Le désir de préciser toutes les exigences avant le développement est fort, cependant, essayer de créer la User Story parfaite peut entraîner des retards dans les livrables et la paralysie des analyses. En revanche, si trop peu d’informations sont fournies trop tard dans le cycle d’itération, les produits livrables ne répondent pas aux besoins de l’utilisateur. Mike Cohn conseille que si vous allez pécher, "pécher par excès de vitesse et par trop peu de temps", qui englobe l’un des principes clés de Agile, qui est "Répondre au changement en suivant un plan". Cela pourrait entraîner la création de récits supplémentaires pour toute nouvelle fonctionnalité. Pour aider à cette approche, pendant l'atelier, ainsi que pour affiner l'histoire, nous devons demander «Avez-vous besoin de la réponse avant de commencer l'histoire?», Ce qui dicte la criticité de la réponse. De plus, à chaque rétrospective, nous devons nous demander «Avons-nous obtenu les réponses juste à temps avec juste assez de détails?», Ce qui nous oriente à l'avenir dans les prochains sprints.

Résumé

a déclaré au début de cette équipe qui investit du temps dans la planification de ce qu’elle veut construire sur le long terme et pourquoi ont plus de succès que celles qui ne prévoient que deux semaines à l’avance. Espérons que ce contenu vous a fourni un élément à prendre en compte lors de la progression de vos projets.