提示：本文共有 2252 个字，阅读大概需要 5 分钟。
在本文中，讨论User Stories创建、计划和编写User Stories相关的代码的最佳方式，以及回答一些最常见的问题。
许多团队开始使用“用户故事（User Stories）”这个术语，因为他们转向了敏捷。用户故事是一种收集客户需求的简单而优雅的技术。然而，使用用户故事来构建优秀的软件需要一定的理解和实践。
让我们仔细看看用户故事（User Stories）是什么，以及如何在项目中成功使用这种技术。
什么是用户故事?
用户故事是一个简短而简单的功能描述，它为用户或客户带来价值，并且团队可以在迭代中交付这些功能。
用户故事应该回答三个问题：
我们为谁实现它?——期望<用户>的类型
我们实现是什么功能?——我希望<功能>
我们为什么要实现它?——<价值，和好处>
在此之后，用户故事的典型格式是：
作为一个<某种类型用户>，我想要<功能>，以便<好处>。
用户故事的例子：作为注册用户，我希望能够将我的照片下载到我的个人资料中，以便其他用户可以看到我的样子。
有创建用户故事的过程吗?
没有创建用户故事的正式过程。然而，应该遵循一个指导方针来创建一个好的用户故事。它叫做3c，是由极限编程的创始人之一Ron Jeffries提出的。
卡片是用户故事的书面描述。它没有捕获应该构建的所有细节。相反，它是一个提醒，一个必须进行后续沟通的承诺。
对话用于讨论用户故事的细节。它可以通过一些文档来补充。
由用户验收测试来进行确认，以确保用户故事满足用户/客户的验收标准。
如何编写高质量的用户故事
要确保用户故事具有适当的质量，一个好的做法是遵循比尔韦克(Bill Wake)的“投资”(INVEST)首字母缩写的标准。INVEST还有助于确定用户故事是否被很好地理解并为开发团队开始工作做好了准备。
独立——用户故事不应该依赖于另一个用户故事，因此用户故事可以按照任何顺序开发。
可协商——用户故事的细节在产品所有者和开发团队之间的口头对话中协商。
有价值——用户故事应该为用户/客户带来所需的价值。
可评估——开发团队应该充分理解用户故事，以便对其进行评估。
小的-用户故事应该小到适合在一个迭代（1-3周）中。
可测试性——应该为用户故事编写适当的验收标准，以便对其进行验证。
什么不是用户故事?
让我们坦诚地告诉自己：用户故事的定义必须是从真正业务用户的角度，不可能是“技术用户（开发者本身）故事”，因为在这种情况下，它不会给用户/客户带来直接的价值。尽管如此，当许多团队需要完成诸如代码重构之类的技术任务时，他们还是喜欢创建用户故事。我建议将其他工作项用于此类任务，并与您的产品所有者就此类工作达成一致，以便他了解为什么有必要这样做。与非功能性需求任务、界面设计任务、复杂的用户交互任务或bug相关。
您可以自由地为这些任务创建其他工作项。例如，约束故事可以用来表示非功能需求。用户故事是捕获产品功能的一种很好的技术，但是我们没有义务将它用于所有目的。
用户是谁?
在编写用户故事之前，应该清楚地了解创建用户故事的用户是谁。有时，新接触用户故事技术的团队会忽略它，他们最终会创建具有不必要功能的软件。所以，做一个适当的用户调查，让所有的用户类型或用户角色或角色写下和描述。可以帮助您实现这一点的两种技术是用户角色建模和角色。
谁负责编写用户故事?
通常，客户代表(如产品所有者)负责用户故事。尽管如此，用户故事并不是高层给团队的规范，而是产品所有者和团队之间的协作技术。这就是为什么如果用户故事是合作编写的更好。一个好的方法是成立一个故事编写研讨会，由团队合作编写。
细节在哪里?
由于用户故事不是规范，所以细节以不同的方式表达:
在用户故事编写的3C原则中，第二个C是对话（Conversation）。会话是敏捷最重要的方面之一。因此，大部分细节都是通过客户代表和开发团队之间的口头交流来传达的。
第三个“C”是确认（ Confirmation）。用户验收测试是确认用户故事满足用户/客户的验收标准，并作为正式的文档细节。BDD(行为驱动开发)是编写验收测试的一种很好的技术。
如果需要，一些用户故事可能包含额外的书面细节。
如何知道用户故事何时完成?
使用已“完成”技术的定义。简单地说，Done的定义是团队成员之间对完成工作的意义的共同理解。完成的定义通常以活动检查表的形式创建，该检查表展示了商定的价值(满足用户接受标准的用户接受测试)和质量(满足质量标准的用户接受测试)。
团队有时会忽略最后一个，什么会使用户故事在迭代结束时不能交付给客户。定义Done技术有助于避免这种情况。
参看下面定义的例子
完成时：
单元测试通过了
代码是同行评议
通过用户验收测试
集成测试是通过了
回归测试是通过了
用户指南更新了
如何开始定义产品范围?
在项目的开始，我们需要定义一个产品的粗略范围，以便对它有一个全局的看法。这可以用史诗（Epics）来完成。史诗是有一个共同目标的大量工作。可以将Epic视为稍后创建的更详细的用户故事的占位符。史诗通常需要多次迭代才能完成。
组织用户故事的最佳方式是什么?
使用杰夫·巴顿发明的故事映射技术。故事映射代表了对需求组织的自顶向下的方法，也是确定优先级和计划的好方法。
敏捷扩展BABOK Guide v2 状态：
“故事映射提供了解决方案支持的活动序列的可视化和物理视图。它使用二维网格结构在水平维度上显示产品关键方面的序列和分组，在垂直维度上显示故事的细节和优先级。故事映射是一种分解技术，它允许从端到端视图开始对解决方案进行演化理解，并深入到详细的用户故事。”
故事映射的例子(由Steve Rogalsky创建)：
看到此处说明本文对你还是有帮助的，关于“敏捷开发中 User Stories最佳实践”留言是大家的经验之谈相信也会对你有益，推荐继续阅读下面的相关内容，与本文相关度极高！
