什么是用户故事？

为什么要来讨论用户故事

传统瀑布模式下，往往先等产品经理完成了产品PRD文档，然后技术团队再根据这份PRD文档实施开发。
在千变万化的市场下，基于完整PRD的才进行开发的模式遇到了挑战，研发团队越重视小步快跑，快速迭代，灵活满足不断变化的环境。比如出现一下状况：

• 阶段规划不合理，产品经理编写完整PRD文档往往需要一定时间，在项目特定时间交付的情况下，势必压缩开发的时间，可能导致后续的工期紧张，加班加点完成工作。
• 需求响应慢，特别是影响运作业务的需求，如果没有及时响应，则会造成业务的损失，失去抢占市场的先机，如果是乙方团队，响应慢也会降低客户满意度。
• 难以追溯需求源头，产品研发是一个长时间的过程，可能做着做着就忘记了原来的需求了，技术和产品可能就开始了互怼。
• 缺乏对话，需求文档不能承载所有的信息，而且文字的描述，理解起来各个人可能也有偏差，需求文档不仅是一份文档，它更是一种沟通工具，用它来让大家达成共同的理解。
• 价值感低，软件规格书或者产品PRD文档，虽然是大而全的需求书，但更偏向于“如何实现”，而对“为什么这样做”没有足够的描述和对话，也就没有直接的价值感知。

用户故事的概念

拆字理解，用户故事=用户+故事=人+故+事，通俗解释，就是什么人因什么原因做某事。提炼出来就是三个要素，who、why、what。用这3个要素组成最简单一句话的需求描述。

用户故事的组成

用户故事由三部分组成，简称3C原则：

• Card (卡片)
• Conversation (谈话)
• Confirmation (确认)

1. Card (卡片)

作为(用户角色)，我想要（产品特性或功能），以便于（实现利益）

卡片也称为用户故事卡，相信大家对于这个卡片很熟悉了，虽然大家未必按照这个格式写用户故事。但有些人心中把用户故事等同于用户故事卡 ，如果这样理解，就会理解片面了，卡片只是用户故事最明显的表现方式，它并不是最重要的。加上后面的沟通和确认才是完整的用户故事。

image.png

2. Conversation (谈话)

卡片代表客户需求而不是记录需求
卡片需要不断谈话澄清，以达成同样的理解

用户故事代表的是客户最原始的需求，它并不是记录大而全需求的地方。卡片承载的是用户需求故事，而需求细节则通过对话完成。
故事之所以是故事，它是用来讲的，不是用来写的。
比如一个卡片上代表一个用户故事，它不是需求的全部，而组织相关干系人进行细节讨论，探讨价值和场景，才是最重要的。
而对话往往不是一次性的，用户故事是一个需求源头，刚开始定义的时候可以对话，设计评审、技术评审，测试验收等环节都可以进行对话。也就要求我们，对用户故事进行维护更新和持续迭代。
虽然我们常说的对话以口头交流为主，但可以借助其它工具，比如业务流程图、UI高保真图等等，沟通的目的是我们对需求达成一致的理解和认知。

3.Confirmation (确认)
用户故事还包含“确认”部分，也就是我们所说的“DoD”，“完成的定义”。这个DoD是大家共同讨论出来的，是大家都愿意遵守的原则。
如果纸质版的卡片，确认部分就可以写在故事的背面，即满足了什么条件之下，这个用户故事才算被满足。

image.png

有了确认条件，技术团队则更明确要测试什么，产品团队则可以确认用户故事是否达到预期和验收标准。
注意，这里的DoD不仅仅是功能性的，也包括非功能性，这往往我们容易被忽略，比如易用性、性能等方面的要求。
当然确认条件不是不变的，如果要调整验收条件，也势必影响我们的范围和工期，可能也要调整我们的迭代计划。

用户故事满足的原则

一个好的故事要满足INVEST原则：

• 独立性（Independent）
• 可协商性(Negotiable)
• 有价值的(Valuable)
• 可估算的(Estimatable)
• 小的 (Small)
• 可测试的（Testable）

顾名思义，从字面上大家应该都理解是什么意思了，这6个特性就不一一细讲，用简单的一句话讲下这6个特性的好处。

1. 故事之间符合MECE原则，不交叉不重叠，要不然给测试和开发就带来很大麻烦。
2. 用户故事强调口头沟通，人人都理解用户故事。
3. 好的用户故事传递价值，我们不是工具人，我们做的事情对于用户来说是有价值的。
4. 不能估算可能是对业务还不理解，或者还没有做详细的设计，这些都是开发之前要去搞懂的东西。
5. 用户故事不等于用例，太小的故事可以合并，太大的故事可以拆分。
6. 如果不能测试，也就没办法验收。

用户故事的不足

讲了这么多用户故事的好处？那么它有不足吗？
如果你分解了很多用户故事，可能会发现它们是零散的，只见树叶不见森林，这个时候就要用户故事地图来把故事串联起来。
其次如果是大项目，则难以组织成千上万的故事，此时就需要结合额外的文档实现可追溯性。

本次分享到这里，有兴趣的读者可以阅读原书，附上电子书链接《用户故事与敏捷方法》