敏捷开发——如何写好用户故事？

用户故事的起源

用户故事最早是极限编程里面提出的概念，并在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

敏捷开发——如何写好用户故事？

原文：https://www.cnblogs.com/zentao/p/14078968.html