什么是用户故事

story time

为什么要来讨论用户故事

在传统研发模式下，特别是在一些小型的产品研发领域，产品经理往往会编写一份产品需求文档（PRD），然后技术团队再依照于这个PRD文档来做开发。
这种基于PRD的开发方式在当前市场变化越来越快，研发组织越来越追求小步快跑的产品发布节奏的环境下遇到了很多挑战：

1. 产品编写一份PRD往往需要很长的时间（产品默认都会追求编写一份完整的需求文档，要考虑到方方面面），考虑到互联网非常紧张的产品发布周期压力，技术团队会抱怨产品需求给得太晚，留给技术的开发时间太短。
2. 整体的开发周期长，获取用户反馈也就晚。完整的产品需求也就可能导致只能完整的交付，当然，这个也和下面第三点有关。
3. PRD内容的丰富同时造成了优先级不清晰。虽然PRD里也会标注有优先级，但是因为里面需求的数量庞大并且相互交织依赖，最后的结果就是高优先级的需求太多，优先级不能细化导致失去价值。
4. 缺少对话。需求文档不可能承载所有需求信息，而且由于描述的角度，容易造成误解。所以需求不仅仅只是一份文档，它更应该是一个沟通的工具，可以用来帮忙大家对特性的理解达成一致。
5. 后期调整需求成本高，但不幸的是在随着产品形态不断的显露出来的时候，需求的调整是不可避免的。而且过早的决策，需求调整的可能性只会更高。

为了解决这些问题，使用用户故事的方法来表述需求逐渐流行起来。
本文试图从非常基础的角度解释什么是用户故事。

什么是用户故事

用户故事一共包含三个部分，简称3C模型：

1. Card（卡片）
2. Conversation（会话）
3. Confirmation（确认）

1.Card

作为<用户角色>，我想要<产品特性>，这样可以<价值或收益>。

这个卡片形式已经是家喻户晓的了（虽然大家不一定都能按这个来做），甚至当大家提到“用户故事”的时候也就只记得这个卡片了，在很多人心中卡片和用户故事是等同的。但显然这样是片面的，这样的理解就只是得其形而失其神。
卡片仅仅是用户故事最明显的表现形式，但他不是最重要的。

2.Conversation

卡片代表客户需求而不是记录需求。
同样一份文档或卡片，阅读的人不同，各自得到的信息也不一样。

卡片包含故事的文字描述，然而需求细节要在对话中获得。故事之所以叫故事，因为它是要讲而不是要写的。
说得通俗一点就是一张卡片只是代表了一个需求，但它远远不是需求的全部，相关干系人一起在对话中发现并探索需求的细节，这个才是更重要的。
对话肯定不是一次性的，而是持续的深度交谈：写故事的时候会有对话，宣讲的时候又有一次，估算的时候再有一次，迭代计划会议的时候还会有，迭代中在软件设计，构建和测试的时候都会有。
尽管我们说对话主要是依靠口头语言交流发生的，单我们仍然经常借助于文档的方式做说明或记录：比如一张PS的效果图，一张画在白板上的交互逻辑照片，引用某篇文档中规范内容的链接，等等。

3.Confirmation

用户故事还要包含确认信息，作为接收标准（或确认条件）。这和“完成的定义”（DoD）非常像，只不过DoD更偏向哪些general的和流程化的事项。

如果我们使用的物理化的卡片的话，正面写的是story的描述，那么背面就很适合写上确认条件。

卡片正反面

有了确认条件，开发和测试团队就能更好的理解要构建和测试的是什么，产品团队可以确认用户故事的实现是否和服预期。
“确认条件”最迟是需要在迭代planning meeting上确定的，很明显，这个是story估算的重要依据之一。但是我们不保证确认条件不会发生变化，但前提是调整和变化不会影响本次迭代的交付，如果真的有大的影响，我们就要马上调整我们的迭代计划（re-planning）。
确认条件在某种程度上也能看成验收条件，是story的测试要点，很自然的我们就想到了敏捷的另一种实践：接收测试驱动开发（ATDD）。

关于“接收测试驱动开发”和“实例化需求”，我们以后再谈。

好故事需要满足的原则

一个好的故事需要满足INVEST标准：

1. 独立的（Independent）
2. 可协商的（Negotiable）
3. 有价值的（Valuable）
4. 可估算的（Estimatable）
5. 小的（Small）
6. 可测试的（Testable）

我不太想用长篇大论来一一介绍这六个好故事特征（不然篇幅太长），这里我只用最简单的一句话来描述各个特征的好处：

• 不独立的故事会对优先级的排列和测试带来巨大的麻烦；
• 故事不是合同，故事只是占位符，它提醒我们需要更多的去对话和协商；
• 卡片的三段式写法本身就是要强调价值的，这里要强调的是价值是对用户和客户来说的，我们要尽量避免做只是对开发团队有价值的故事；
• 不能估算的故事要么是对业务还没理解，要么是团队缺少相应的技术实力，要么就是太大，总之这些都是要在开发之前解决的问题；
• 小是必须的，但是太小也不是不能合并一下，总之大小要合适；
• 如果不能测试，就不能证明它是完成的。

有兴趣深入探讨的话可以自己google或者参考Mike Cohn的《用户故事与敏捷方法》。

非功能性需求

非功能性的需求往往包含安全性、可靠性、互操作性、健壮性、易使用性、可维护性、可移植性、可重用性、可扩充性、实验性等，一般反应了系统的约束，而非系统特定行为的需求。

• 对于非功能性需求我们仍然希望能按照故事的结构来编写它，这样能帮助我们理清这些需求的价值，这往往是容易忽略的；
• 非功能性需求往往是跨所有功能性需求的，一旦你完成了一个非功能性需求，那么在以后的迭代中你要始终关注这个非功能性需求以防止它被影响而失效。那该怎么办呢？
• 考虑把非功能性的要求放到每一个功能性需求DoD中去，在一开始就考虑到系统的各种限制
• 或者和PO约定，哪些迭代里需要对非系统性需求做验证和维护

Story mapping

使用story的形式做需求管理最被人诟病的就是，相对于大而全的PRD，story是“只见树木，不见森林”。用户故事地图（user story mapping）的是给这个问题一个解决办法。

用户故事地图，就是在讲大故事的同时进行拆分。

对于story mapping暂时就不在这篇文章中详细描述了，后续会单独开一片story mapping的小文。