用户故事的起源
用户故事最早是极限编程里面提出的概念，并在scrum中也得到了广泛地应用。和需求文档或者原型图相比，用户故事以条目化的方式组织，维护起来简单，容易估算和排序，方便研发团队以小迭代的方式来完成交付。
能否将产品拆分成粒度合适的用户故事，是整个团队能否实现敏捷的前提。
视频地址：https://www.zentao.net/xp/user-story-80289.html/?u=uplu&f=bky
用户故事是什么？
用户故事是从用户的角度，来描述用户渴望得到的功能。一个好的用户故事包括三个要素：角色、活动和商业价值。
- 角色是谁要使用这个功能；
- 活动是需要完成什么样的功能；
- 商业价值是为什么需要这个功能，这个功能可以带来什么价值。
通常，用户故事可以用一个简单的模板来概括：作为一名<某种类型的用户>，我希望<达成某些目的>，这样可以<带来哪些开发价值>。
比如“作为一名部门经理，我希望系统能有一个每日待办功能，这样我就可以了解到部门各个员工的工作进度了。”
为什么要写用户故事？
用户故事可以帮你将功能需求传达给研发团队。这样研发团队就会更容易理解，为什么要构建这个功能，用户将如何使用它。
关于用户故事，通常可以用3个C来描述它：
- 卡片（Card）
用户故事可以写在卡片上，内容包括用户故事的简短描述、验收标准等。
- 交谈（Conversation）
用户故事背后的细节，来源于跟客户或产品负责人的交流沟通。
- 确认（Confirmation）
通过验收测试，确认用户故事被正确完成。
用户故事怎么写才标准？
要写一个好的用户故事可以遵循Invest原则。
- 独立的（Independent）: 每个用户故事之间应该相互独立，尽可能避免故事间的相互依赖。
- 可协商的（Negotiable）: 用户故事无需太过详尽，只是需求的简短描述，并且是可讨论的，具体细节是客户和开发团队在沟通阶段产出的。
- 有价值的（Valuable）: 每个用户故事是对用户具有价值的，因此应站在用户角度进行编写。
- 可估算性（Estimable）: 要进行开发的用户故事可进行粗略估算，以便团队了解工作量，并由PO决定是否需要重新设计用户故事或进行任务拆分。
- 短小的（Small）: 一个好的用户故事要短小，至少确保在一个迭代或Sprint中完成。用户故事越大，在安排计划、工作量估算等方面的风险就会越大。
- 可测试性（Testable）: 用户故事是具体的且可被测试的，如果用户故事过于含糊，测试就没有标准可循。
当我们真正理解了用户故事的价值，关于如何写出用户故事、用什么格式写等问题自然就迎刃而解了，因为我们已经完成了敏捷用户故事实践的本质——激发讨论、明确价值、达成共识。
更多精彩视频分享：https://www.zentao.net/page/college.html/?u=uplu&f=bky