User Stories/用户故事
下文翻译自Mike Cohn的博客
用户故事是敏捷方法的一部分，该方法有助于将重点从编写需求转移到讨论需求。所有的敏捷用户故事都包括一个或两个书面句子，以及关于这个需求的一系列描述。
什么是用户故事？
用户故事是从需要新功能的人员（通常是系统的用户或客户）的角度出发，对功能的简短描述。它们通常遵循一个简单的模板：1
2作为一个<用户类型>，我想要<一些目标>，以便<一些原因>。
As a < type of user >, I want < some goal > so that < some reason >.
用户故事通常写在索引卡或便签上，并排贴在墙壁或桌子上，以方便计划和讨论。因此，他们将人们的注意力从写作需求转移到讨论功需求上。实际上，这些讨论比任何书面内容都重要。
可以展示一些用户故事的示例吗？
用户故事的好处之一是可以描述各种大小的需求。我们可以编写一个用户用户来涵盖大量功能，这些大型用户故事通常被称为史诗（Epics）。这是一个桌面备份产品的史诗级用户故事（epic agile user story）的示例：
- 作为用户，我可以备份整个硬盘。
- As a user, I can backup my entire hard drive.
由于史诗（epic）太大，以至于敏捷团队通常无法在一个迭代中完成，因此在进入开发之前，史诗被拆分为多个较小的用户故事。上面的史诗可以分为数十个（或可能数百个），包括以下两个：
- 作为高级用户，我可以根据文件大小，创建日期和修改日期指定要备份的文件或文件夹。
- 作为用户，我可以指示不备份的文件夹，这样我的备份驱动器就不会充满不需要保存的内容。
如何将细节添加到用户故事？
可以通过两种方式将详细信息添加到用户故事：
- 通过将用户故事分成多个较小的用户故事。
- 通过添加“满足条件”（conditions of satisfaction）。
当一个相对较大的故事分为多个较小的用户故事时，自然会添加详细信息。毕竟，已经写了更多的东西。
满足的条件只是一个高层次的验收测试，在敏捷用户故事完成之后，这个测试才是真实的。考虑以下作为另一个敏捷用户故事示例：
作为市场营销副总裁，我想选择一个假期用来回顾过去广告活动的效果，以便确定有收益的活动。
通过添加以下满足条件，可以将详细信息添加到该用户故事：
- 确保它适用于主要的零售假期：圣诞节，复活节，总统日，母亲节，父亲节，劳动节，元旦。
- 支持跨两个日历年的假期（无跨三个假期）。
- 假期可以从一个假期设置到下一个假期（例如，感恩节至圣诞节）。
- 假期可以设置为假期前的几天。
谁撰写用户故事？
任何人都可以编写用户故事。确保用户故事存在于产品待办列表（product backlog）是PO的责任，但这并不意味着PO是编写它们的人。在一个好的敏捷项目过程中，您应该期望每个团队成员都编写一些用户故事。
另外，请注意，撰写用户故事的人远不如参与讨论的人重要。
用户故事何时编写？
用户故事是在整个敏捷项目中编写的。通常，在敏捷项目开始时会举行一个故事写作研讨会。团队中的每个人都以创建产品待办列表（product backlog）为目标，该待办列表完整描述了在项目过程中或项目三到六个月的发布周期内要被添加的功能。
这些用户故事中肯定会出现一些史诗（Epic）级的需求。随后，史诗将被分解成较小的故事，这些故事更容易放入单个迭代中。此外，任何人都可以随时编写新故事并将其添加到产品待办列表中。
用户故事可以代替需求文档吗？
敏捷项目，特别是Scrum项目，使用产品待办列表（product backlog），这是一个包含了要在产品或服务中开发的功能的有序列表。尽管产品待办列表项（product backlog items）可以满足团队的任何需求，但用户故事已成为产品待办列表项的最佳和最受欢迎的形式。
尽管可以将产品待办列表视为传统项目需求文档的替代品，但重要的是要记住，在讨论故事之前，敏捷用户故事的书面部分（“作为用户，我想要…”）是不完整的。
通常最好将书面部分视为实际需求的参考。用户故事可能指向描述工作流程的图表，显示如何执行计算的电子表格，或PO/团队期望的任何其他工件。
