Modèle user stories

Les histoires d`utilisateurs sont écrites dans le langage quotidien et décrivent un but spécifique (quoi) du point de vue d`un individu (qui) avec la raison (pourquoi) il/elle le veut. Enfin, écrire des histoires d`utilisateurs est utile lorsque vous développez un logiciel qui est susceptible d`être réutilisé. Mais si vous voulez créer rapidement un prototype ou une maquette pour valider une idée, alors écrire des histoires peut ne pas être nécessaire. Rappelez-vous: les histoires d`utilisateurs ne sont pas de documenter les exigences; ils veulent vous permettre de vous déplacer rapidement et de développer des logiciels le plus rapidement possible, pour ne pas imposer de surcharge. Salut Deepu, Merci pour votre commentaire. Je ne recommande pas d`écrire des histoires d`utilisateur pour des sujets techniques comme ceux que vous avez mentionnés. Les histoires d`utilisateurs sont excellentes pour décrire la fonctionnalité de l`utilisateur final, mais pas comment un produit ou un système fonctionne. Si vous voulez capturer l`architecture et les exigences de conception, alors je vous suggère d`utiliser un langage de modélisation comme UML, qui est mieux adapté que le langage naturel IMO. J`espère que cela aide! Les histoires d`utilisateurs sont probablement la technique agile la plus populaire pour capturer la fonctionnalité du produit: travailler avec des histoires d`utilisateur est facile. Mais raconter des histoires efficaces peut être difficile.

Les dix conseils suivants vous aideront à créer de bonnes histoires. Les histoires d`utilisateurs sont souvent confondues avec la configuration système requise. Une exigence est une description formelle des besoins; un récit utilisateur est une description informelle d`une entité. Salut, romain, je vous remercie pour l`excellent poste. J`ai une question liée au nombre “10 ne comptez pas uniquement sur les histoires des utilisateurs” J`ai l`architecture suivante: portail pour les écoles de poste des emplois, un portail distinct pour les candidats à postuler pour un emploi, un système de CRM comme un système backend pour gérer/médiation d`un processus entre Les écoles et les candidats. Première question, devrions-nous avoir des histoires d`utilisateurs sur les trois types d`utilisateurs? Quel serait le meilleur artefact pour croiser ces histoires d`utilisateurs? Recommanderiez-vous des cartes de processus, un parcours client ou autre chose? J`apprécierais votre contribution. Je travaillais dans les opérations depuis 10 ans et maintenant j`ai rejoint en tant qu`analyste d`affaires dans une banque pour un projet agile. Le Product Owner/SME a déjà écrit Epics et créé quelques backlogs de produit.