你的团队敏捷不起来？可能是被用户故事“坑”的

软件领域，到处都是易变、不确定、复杂、模糊的需求。客户说不清楚究竟要什么，开发者听不明白到底做什么。因此，敏捷软件开发方法引入“客户”角色并使用用户故事实时沟通需求，确保开发团队交付用户真正需要的产品。

用户故事说起来简单，用好它却不是一件容易的事情，团队一不小心就会掉进各种陷阱。

那么，用户故事都有哪些常见的陷阱？该如何有效地避开这些坑，高效地使用用户故事呢？

陷阱一：什么时候用？

用户故事，是描述了“什么人用了软件中的什么功能实现了什么目的或获取了什么利益”的一个记录。要实现一个功能，首先要问这个功能是为谁服务的，然后思考用户为什么要用这个功能，最后才去思考怎么实现这个功能。

那么，哪些事情适合使用用户故事呢？通常来讲，用户故事是用于业务价值陈述的一种简便格式，适合各种与用户直接相关的需求事项，特别是软件功能性特性。

对于团队需要投入时间完成的一些事项，也可以用户故事的形式来描述、跟踪和确认。但必须清楚的是，这些事项无法向客户交付实际价值，严格意义上并不能算作“用户故事”，只是某个“任务”的记录。

还有一些事项，比如基础架构的构建，是为交付项目而必须做的基础工作，使用“用户故事”来跟踪当然没问题。但这些工作的用户是技术人员本身， 以技术人员的语言来写，基于共同的技术语言，则更方便技术团队的沟通和交流。

避坑指南一

对于每个待办事项：

先弄清 用户是谁，再想 为什么要这么做，最后确定 做什么；
对 用户相关的需求，使用用户故事；
对 技术问题，使用相关人员听得明白的共同语言。

下列需求或事项，比较适合使用用户故事来描述、跟踪和确认：

功能性需求；
撰写文档、用户手册等文档；
非功能性需求；
用户报告的缺陷；
针对不确定性，获取 知识的原型、 概念验证、实验、探针等知识获取性需求。

下列事项，可以使用相关语言来描述：

架构、基础设施等方面的事项；
内部发现的功能和代码问题；
重构等技术债。

陷阱二：谁来写？

下个迭代要开始，但用户故事还没有着落。产品待办事项列表中的用户故事屈指可数，远不是下个迭代的全部工作。该谁来写用户故事、什么时候写，团队没有共识，大家觉得应该别人来写，不是自己的事儿。

用户故事是团队的需求描述和沟通方式。那么，应该由谁来编写用户故事呢？通常并没有严格的规定应该由谁来负责编写用户故事。 通常的原则是，谁靠近用户谁优先负责，也可以授权给别人。

用户故事一般是用业务语言写成，因此最好由 客户或产品负责人来写。如果用户不愿意， 开发团队可以帮助代行编写用户故事。但是，团队编写的用户故事，尤其是验收标准， 必须由客户或产品负责人进行确认。用户故事和待办事项列表的 优先级排序也一定要由能够代表用户的角色来确定，比如代理产品负责人。

开发团队可以通过访谈、问卷调查、观察和故事编写工作坊等形式来开展用户故事编写。而故事编写工作坊是快速创作用户故事最有效的方法之一，可以在开始每个发布计划之前举办。

避坑指南二

编写用户故事的职责，依次降低：

项目中的客户、用户；
项目中的市场、业务方面的人员；
产品负责人，或代理产品负责人；
研发团队中的熟悉用户和业务的业务分析人员、测试人员；
研发团队技术成员。

注：在具体的软件项目实践中，很多时候尤其是在项目前期，团队通过工作坊的形式来编写初始的一些粗粒度用户故事。如果给团队显式明确了编写用户故事责任的优先级顺序，可能会造成技术人员觉得编写用户故事不是技术人员的责任，因而消极甚至拒绝编写用户故事。为此，也可以不给团队明确责任排序，以促进自组织和团队成员的积极性。

陷阱三：谁是用户？

技术团队容易陷入“以技术为中心”思维，自以为是地闭门造车，想当然地认为自己理解的就是用户需要的。但用户是谁，却不清楚。

有时候，团队所认为的用户过于单一抽象，用户范围过大、过于抽象，比如“销售人员”，导致定义不清。而另一个极端是，用户角色过于精细，角色过多，导致团队对需求的精准理解产生混乱。

有时候，开发的软件可能是给别的软件或者系统用的，比如中间件、微服务等。一个复杂系统包含很多各自独立但又紧密关联的软件和组件，各个部分是整个软件或系统的组成部分，有自己的上下游接口。此外，团队自己内部系统的不同组件也可能相互调用。所以，很难为这类系统或组件定义清楚的“人类”用户，团队很容易陷入以技术为中心的思维，只关注接口，忘记其实上下游系统及本身不同部分都是“用户”——系统用户。

那么，该怎么来精准定义用户角色呢？

避坑指南三

团队可以使用设计思维工具进行用户研究：

用户画像；
用户访谈；
同理心图；
用户体验地图；
干系人图。

对系统用户，可以尝试：

定义上游的“供应方”和下游的“消费者”用户，它们是软件系统、组件或者接口。
“供应方”和“消费者”加强沟通和协调：明确彼此的需要和依赖，比如接口类型、数据格式等技术参数。
将 系统用户的需求纳入待办事项管理：由下游向上游提出需求，编写用户故事，明确技术指标，放入上游团队的待办事项列表，统一进行优先级排序，纳入发布计划和迭代计划。

陷阱四：使用不规范？

日常工作中，诸如格式不完整、用户不明确、价值描述不清晰等问题非常常见，而由此导致的交付失败也时有发生。那么，怎么才算是规范的用户故事呢？

因此，好的用户故事，应当 格式规范、 要素完整、 各自独立。故事之间还要尽量避免相互依赖。用户故事之间相互依赖，会导致排列优先级时，或者做迭代规划时出现问题，而且使用户故事的估计变得困难。

那么，规范使用用户故事，如何做到格式规范、要素完整、各自独立呢？

避坑指南四

规范使用用户故事，要做到：

使用故事标准格式：使用“作为< 角色>，我想要< 功能>，以实现< 商业价值>”模版。
遵循 INVEST原则，即：

独立的
可协商的
有价值的
可估算的
小的
可测试的

定义“ 就绪定义”：定义团队一致共识的“就绪状态”检查表。
定义“ 完成定义”：定义团队一致共识的“完成定义”检查表。
定义“ 验收标准”：就如何确认和验收用户故事达成一致并进行测试。

如果依赖不可避免，则尽量尝试：

重新整合用户故事，换一种方式对故事进行分割；
低优先级的故事依赖于高优先级的故事；
被依赖的故事给个较高的故事点，依赖其他故事的给个较低的故事点；
将相互依赖的故事放到一个迭代中进行开发和交付；
将相互依赖的故事分配给同一个人。

陷阱五：故事点大PK？承诺？

故事点考虑了事项的复杂度、不确定性、工作量及风险等因素，只是要完成工作的一个大致相对估计。故事点没有统一的大小和普遍的度量基准，不同团队故事点基准的设定不尽相同。

因此，一般会出现两方面的错误理解：

用故事点来横向比较不同团队的绩效。
用故事点估计当做团队的承诺。

要避免上述错误，可以尝试：

避坑指南五

关注价值，而非故事点。关注迭代交付了多少功能，而非故事点。
故事点只用来记录团队的工作速率并进行迭代计划。
不做团队之间的横向比较。
采用相对估算：定义基点之后，其他故事以基点为参照确定大小并进行排序。
必须理解，估算包含很多不确定性。没必要追求100%的准确性，也不是团队的最终承诺。
随着估算数值增大，其包含的不确定性、复杂度和风险也会成倍增加。采用斐波那契数列来确定用户故事的点数，拉大估算数值，体现点数所代表的不确定性和风险的大小。
使用规 划扑克：规划扑克是来自于宽带德尔斐方法的一种集体估算方法，包含了心理学的某些原理。

陷阱六：就绪——准备好了吗？

用户故事在放入迭代进行开发之前， 需要经过深度讨论、排序，确保用户故事是“就绪”的。这需要用户、团队一起确定一个明确的“就绪”的定义，明确用户故事具备了什么条件后才算“准备好了”，可以纳入迭代规划进行开发。

“就绪”定义通常是一个检查列表，明确列出大家达成一致共识的检查事项，只有满足该检查表的各个条目，才可以将用户故事纳入迭代计划进行开发。不满足“就绪”条件的用户故事，不应该放入迭代计划进行开发。

避坑指南六

定义“就绪定义”：团队需要提前就什么是“就绪”达成一致。

明确标准：制定检查列表，明确列出一致达成共识的检查事项，只有满足该检查表的各个条目，才算“准备好了”。
在团队或项目范围内，针对不同类型的用户故事，可以制定不同的“就绪”定义。但无需为每个故事制定 “就绪定义”。
定期回 顾“就绪”定义中的条目，根据实际对其进行更新。

陷阱七：完成——搞定了吗？

用户故事怎样才算是完成了呢？如果没有统一的共识，很可能出现“自己觉得故事完成了但别人却不认为完成”这样的情况。

比如，功能代码写完就算完成吗？还是功能测试之后才算完成？还是功能上线到生产环境才算呢？

又比如，需求级别不同，比如史诗故事、特性和用户故事，是否要制定完全一致的完成标准呢？用户故事类型不同，比如功能性、非功能性、探索性的，它们的完成标准是否要一致呢？

还有， 团队眼中的“完成”和用户眼中的“完成”是否一致？用户故事最重要的是客户价值，团队“完成”，用户还需要进行最终“完成”的确认。

这是两种不同的“完成”标准。团队需要确定在迭代级别的“完成”，确保所有必须的工作都做完了。用户需要验收完成的功能，确认收到了满足需要的软件功能。

前一种是 团队眼中的“完成定义”，即常说的 Definitions of Done，简称DoD；后一种是 用户视角的接收标准，即Acceptance Criteria，简称AC。

避坑指南七

确定“完成定义”：团队一起就怎么才算完成达成共识：

为不同级别的故事定义相应的完成检查表。
为不同类型的故事制定相应的完成检查表。
明确列出完成检查列表：把共识写下来，列出完成的检查事项。
初期，完成定义可以简单些，适当宽松。随着项目基础设施的完善和团队合作的提高，可以逐渐增加严格的完成标准。
每个迭代结束，回顾和更新 “完成定义”。

定义“验收标准”：用户、产品负责人及团队，讨论如何测试所实现功能的细节及测试方法：

由用户或产品负责人编写验收测试，最好也由用户或业务人员来执行。
或团队编写、确定验收标准，但一定要由客户或产品负责人进行确认。
验收测试针对每个用户故事所实现的功能，每个用户故事需要特定的验收标准集合。
尽可能自动化验收测试。
使用GWT 格式：也叫Gherkin格式，即 “Given ...... When ...... Then ......”，可作需求文档，也可作为测试标准文档。

准确区分“完成定义”与“验收标准”：

完成定义是面向团队的，是团队为完成某个待办事项而需要完成的工作列表。而验收标准是面向用户的，是用户验收团队所实现的功能是否满足用户需求而需要满足的条件，通常是一系列的测试案例，验收标准最终在验收测试中进行验证。
完成定义是针对迭代期间正在开发的工作增量，就新功能、新特性，不是针对某一个用户故事的。而验收标准针对的是某一个用户故事，不同的用户故事具有不同的验收标准。
团队负责待办事项的完成必须满足完成定义，而用户或产品负责人负责确认该功能是否满足用户的要求。
验收标准是适用于完成定义检查列表中完成标准的有效补充，而非取代，可以称验收标准是完成定义在每一个具体待办事项上的补充。完成定义的检查列表适用于所有的待办事项。
为了不使完成定义和验收标准在术语“完工” （ Done ）方面对产品负责人、团队产生混淆，可以将满足完成定义的待办事项的状态称为“完成”（Completed），而将满足验收标准的待办事项的状态称为“接受”（Accepted）。