敏捷5.1规划的核心：用户故事

Posted 2022-02-22 码农老张Zy

规划的核心：用户故事

一看到这个标题，是不是感觉马上就激动起来了，自从讲完敏捷框架之后，我估计大家最激动的地方就在今天这篇文章了。用户故事这个东西吧，现在已经是在敏捷中用来描述需求的通用工具了。但凡提敏捷，必须要问用户故事。之前我们学习过的 待办事项列表 ，迭代冲刺事项列表 之类的内容，记录的都是用户故事。在冲刺中，白板、任务板上贴的，都是用户故事。那么，真正的用户故事你知道怎么写么？

用户故事格式

用户故事（User Story）是从用户的角度来描述用户渴望得到的功能。一个好的用户故事要包括 3 个要素：

1. 角色：谁要使用这个功能

2. 活动：需要完成什么样的功能

3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值

通过这个 3 个要素，我们就可以总结出一个用户故事的标准格式：

作为一个｛角色｝，我想要｛活动｝，以便于｛商业价值｝。

比如说我们来一个例子：作为一名“打工人”，我希望“能方便地买到火车票”，以便于“不用大冷天的去火车站排队”。通过这个用户故事，12306 诞生了。

当然，这个故事的范围其实有点大了，如何买票、如何选座、怎么在线排队等等都可以细化成更细致的故事。我们也称这种范围非常大的故事叫做 史诗 Epic 。这样的故事其实并不是一个好的故事，而下面这个故事可能就相对来说好一些。

作为“公司的运营”，我想要“看到新注册的用户数”，以便于“统计产品拉新的效果”。

需要注意的是，用户故事尽量不要使用技术的语言来描述，上面这个故事是有一些偏技术了。我们应该尽量以客户和相关方的角度来以故事的形式描述要做的东西。而技术方面的语言则是在用户故事在迭代中被分配并拆分成任务之后的事情。当然，对于公司内部员工提出的这种用户故事还是可以接受的，毕竟这些数据还不算是特别的技术上的术语。

一般的用户故事都会写在一张卡片上，也称为 用户故事卡 。对于这个 用户故事卡 ，有这样一个 3C 原则。

• CARD（卡片）：写在卡片上，方便记录和讨论，也方便在任务版上的挪动。

• CONVERSATION（会话）：用户故事背后的细节，应该是来源于和客户以及各个相关方的讨论会话。

• CONFIRMATION（确认）：用验收测试来传达和记录故事的细节并决定什么时候这个故事才是正式完成了。

INVEST 原则

上面的 3C 原则可以看做是 用户故事卡 的制作原则，不过其实也隐含着用户故事的编写原则。但是，没有以下这六个特性的 用户故事 ，就绝对称不上是一个好的 用户故事 ，也有不少人会称这六个原则为 用户故事 的基本原则。这六个原则的首字母组成的就是 INVEST 这个单词，很有意思的是，这个 INVEST 的中文意思就是投入。用户故事确实也是需要我们和团队以及相关方人员以全身心投入的状态来建立和确定的。

独立的（Independent）

用户故事之间应该是独立的，怎么理解呢？就是用户故事之间没有相互的依赖。如果用户故事之间有依赖，那么被依赖的用户故事就有了天生的优先级。当然，这个东西也确实是没有办法避免的，就像我们要开发积分功能，那肯定是要先开发用户中心功能，而要开发用户中心，那必然也得先要有个登录吧，在用户表都没确定的情况下，那么后面和用户相关的功能可能真的就没办法实现了。

那么就没办法了么解决这个问题了吗？只能说，我们要尽可能要拆小用户故事，然后在一个发布周期内尽量让本次发布内的用户故事减少依赖性。

可协商性（Negotiable）

用户故事不是像签订的合同一样，签订了就不变了，它只是对用户需求的一种描述，并不包含太多的细节。因此，用户故事应该是可以协商的，如果在一开始就定义了太多限制，那么也就无法更好地沟通和协商。因为细节和限制应该是在开发阶段才确定的东西，是在用户故事分解成任务之后才进行的。同时，开发者可以参与的协商也能够让用户故事获得更多开发者的赞同和支持。

有价值（Valuable）

价值这个词其实已经不用多说了吧。之前专门就价值这个问题已经讨论过好几篇文章了。如果用户故事没有价值，那我们交付的是什么？不是说好的要以用户价值为驱动进行交付嘛。最好的方案是让用户自己去写用户故事，如果不方便的话，那么用户代理人或者 PO 也应该尽量站在用户的角度去写。一般的用户在知道用户故事并不是确定的文档待办事项，也不是合同约束条款的情况下，都会非常愿意去尝试自己编写用户故事的。

可估算的（Estimable）

一般来说，故事越大可估算性越差，比如我们上面说的那个史诗型的故事。看似很简单啊，能在网上买火车票，那你知道 12306 改过多少次版，想了多少方法才让我们现在能比较顺畅的买到火车票吗？这就有点像开玩笑时会说的，甲方说需求很简单，只是做个淘宝而已。这种东西，其实真的太虚了，根本就没法估算，所以还是那个方案，拆分，一步一步的拆分，必须要足够小，而且是让开发人员能在一个迭代内完成的。另外，领域知识对于估算也十分重要，如果没有领域知识的铺垫，估算的差距可能也会非常大。敏捷虽说不重视精确的估算，但是相差十万八千里的那种也是没法接受的。

小的（Small）

这不，马上就开始讲这个小的事情了。一个好的故事在工作量上一定要尽量短小，前面已经说过估算误差的问题了，越小的故事其实估算是越精准的，而且也要能在一个迭代冲刺周期内完成，这个完成指的是测试通过之后一致认为的那个“完成”。当然，太小了也不是什么好事，琐碎的故事列表会给维护带来很大的麻烦。比如页面上某个按钮改个颜色，改个字，这类需求应该又合并到一个合适大小的故事中更好。

可测试的（Testable）

这个特性对于用户故事来说非常重要。为什么呢？刚刚我们就讲到过“完成”的问题。测试就是可以检验是否“完成”的一个标准。另外，用户故事也为测试用例提供了基础，并且在划分任务的时候，也要以单元测试用例的通过率为标准来衡量任务的完成情况。因此，它关乎着我们这个故事如何才能结束。比如说一个用户故事是系统应该是易于使用的，易于使用这个东西没法测试，同时它也是没法估算的。

总结

用户故事这个东西，有一本非常著名的书，而且也是 PMI-ACP 考试推荐学习资料中排名第一的，是考试的必备用书，那就是 XP 创始人 Kent Beck 大神的 《用户故事与敏捷方法》。不管你是考试还是为了了解学习，这本书都是相当推荐的一本敏捷入门大作。今天的文章其实并没有写太多的用户故事的例子，主要原因其实也是因为经验不多，之前也就带过那么一次敏捷团队，而且间隔也比较久了。但是在这本书中有非常多，非常好的例子，真心还是推荐大家买来看一看。

参考文档：

《某培训机构教材》

《用户故事与敏捷方法》

《高效通过PMI-ACP考试（第2版）》

《敏捷项目管理与PMI-ACP应试指南》