我是一名用户体验设计师，拥有一些敏捷开发项目用户故事的经验，用于记录表单上的功能需求：
作为[用户类型]我想[目标]以便[原因]
在与一些同事讨论后，我们确定了对[用户类型]应该是什么的三种不同解释。
谁是对的？如果我们所有人都是对的，这不会成为混淆的常见原因吗？
答案 0 :(得分：3)
用户故事以语言和产品最终用户的角度编写。
所以用户就是这样：他们是系统的用户。
示例包括：
答案 1 :(得分：0)
1和2在使用中非常常见。我与许多为他们的产品创造了许多角色的团队合作过，比如老太太简，拿着她的智能手机做所有事的时髦的达芙妮和那个让他的个人安排一切的约翰助理。
这些角色对软件的要求有很大不同，即使它们可能在系统中执行相同的功能，或者从同一角色的角度起作用。
一个的value语句甚至可能与另一个的value语句冲突。 Jane可能想要一个大字体，只有与她当前行动相关的信息，John（他的助手）可能希望拥有更广阔的视野，并且不介意可视化和小字体，如果这意味着她可以填补有关同一屏幕的更多信息。
因此，将人物角色视为进一步缩小特定角色范围并使您的用户故事更加“人性化”的方式。远离严格范围的角色。请记住，用户故事旨在真实地讲述用户的故事以及功能将帮助他/她完成什么以及将给这些人带来什么。角色＆＃34;管理员＆＃34;，＆＃34;客户＆＃34;，＆＃34;黄金客户＆＃34;往往没有情绪，往往不能引发正确的讨论。
我记得一些团队讨论，人们在讨论中谈到：＃34;虽然约翰会喜欢这样，但我们已经失去了简3步前＃34;这导致了所提议功能的改变。
对于选项3，我看到很多团队这样做，对于某些角色，它可能有意义...... 作为一名运营工程师，我需要彻底记录，以便快速分析生产事件。可以是一个例子。但团队把它带到作为需求分析师，我需要对故事27的要求，这太过分了。这些项通常属于非功能性需求桶，并且不提供真正的最终用户功能。对于这些类型的产品待办事项，您可能需要检查用户故事是否是描述它们的最佳格式。
答案 2 :(得分：0)
第一个和第二个是正确的，但它们没有区别，而是相互补充。
用户类型可以是：
在简历中，您可以为任何类型的用户使用任何上下文，因此您可以使用其中一个或混合。
希望我的英语可以承受=）。
答案 3 :(得分：0)
尽可能短的回答：这个人是＆＃34;利益相关者＆＃34;。
那个利益相关者是什么？它是具有故事任务的（最大）好处的人。
还有更多。只要它能够完成这个故事的好处。
（旁注：我从不喜欢这种故事写作方式。太多样板，但我们的敏捷教练也敦促我们用这种格式写故事）
答案 4 :(得分：0)
<强> TL; DR 一切都很有用，没有错，没有一个是唯一的方法。阅读blog post的更多内容，我写了这篇文章来跟进这个答案。
您描述的3个细微差别均有效并提供有用信息。考虑尝试每个人，看看哪个最适合你。我的建议是避免限制“用户”可能意味着什么，因为它可能会使你从有用的洞察力和更深层次的意义中切断你正在构建的东西
用户故事的目标（最初肯特贝克希望他们被称为'故事'）不是为了写出更好的用户故事;它是超越要求并进入真正的理解。为此，您需要知道该软件的用户，为其解决的问题以及为什么该问题有待解决。
将此视为一项实验，以了解您是否拥有正确的类型的用户。回答这个问题，“我是否知道我正在建造这件事会改变那些使用它的人的世界？”如果没有，您可能还不了解是谁。
答案 5 :(得分：0)
用户故事最常用于描述产品积压的要求，以便最终用户或利益相关者从他的角度看待和使用产品。 PO应该是能够评论用户故事正确性的最佳人选。如果PO正在从团队中获取用于开发用户故事的输入，则应该更多地了解产品的使用情况 而不是简单地分类用户的类型。虽然用户类型很重要，但需要强调使用，如， 1.医生访问医疗网站了解药物及其制造商的内容，另一方面需要给予他什么样的访问权限？ 2.如果药剂师正在寻找特定药物，可用数量，出货时间，则需要根据访问和工作流程提供。
从上面给出的用法中，我发现第一个是合适的，即人物角色，从他的角度来看它是系统的用法。对于系统的每次使用，都可以创建用户故事，因此可以开发工作流程。