没写好一个故事，做错了一个功能；
做错了一个功能，搞砸了一个项目；
搞砸了一个项目，丢失了一个客户；
丢失了一个客户，垮掉了一家公司。
软件领域，到处都是易变、不确定、复杂、模糊的需求。客户说不清楚究竟要什么，开发者听不明白到底做什么。因此，敏捷软件开发方法引入“客户”角色并使用用户故事实时沟通需求，确保开发团队交付用户真正需要的产品。
用户故事说起来简单，用好它却不是一件容易的事情，团队一不小心就会掉进各种陷阱。
那么，用户故事都有哪些常见的陷阱？该如何有效地避开这些坑，高效地使用用户故事呢？
01、陷阱一：什么时候用？
用户故事，是描述了“什么人用了软件中的什么功能实现了什么目的或获取了什么利益”的一个记录。要实现一个功能，首先要问这个功能是为谁服务的，然后思考用户为什么要用这个功能，最后才去思考怎么实现这个功能。
那么，哪些事情适合使用用户故事呢？通常来讲，用户故事是用于业务价值陈述的一种简便格式，适合各种与用户直接相关的需求事项，特别是软件功能性特性。
对于团队需要投入时间完成的一些事项，也可以用户故事的形式来描述、跟踪和确认。但必须清楚的是，这些事项无法向客户交付实际价值，严格意义上并不能算作“用户故事”，只是某个“任务”的记录。
还有一些事项，比如基础架构的构建，是为交付项目而必须做的基础工作，使用“用户故事”来跟踪当然没问题。但这些工作的用户是技术人员本身，以技术人员的语言来写，基于共同的技术语言，则更方便技术团队的沟通和交流。
避坑指南一对于每个待办事项：
先弄清用户是谁，再想为什么要这么做，最后确定做什么
对用户相关的需求，使用用户故事
对技术问题，使用相关人员听得明白的共同语言
下列需求或事项，比较适合使用用户故事来描述、跟踪和确认：
功能性需求
撰写文档、用户手册等文档
非功能性需求
用户报告的缺陷
针对不确定性，获取知识的原型、概念验证、实验、探针等知识获取性需求。
下列事项，可以使用相关语言来描述：
架构、基础设施等方面的事项
内部发现的功能和代码问题
重构等技术债
02、陷阱二：谁来写？
下个迭代要开始，但用户故事还没有着落。产品待办事项列表中的用户故事屈指可数，远不是下个迭代的全部工作。该谁来写用户故事、什么时候写，团队没有共识，大家觉得应该别人来写，不是自己的事儿。
用户故事是团队的需求描述和沟通方式。那么，应该由谁来编写用户故事呢？通常并没有严格的规定应该由谁来负责编写用户故事。通常的原则是，谁靠近用户谁优先负责，也可以授权给别人。
用户故事一般是用业务语言写成，因此最好由客户或产品负责人来写。如果用户不愿意，开发团队可以帮助代行编写用户故事。但是，团队编写的用户故事，尤其是验收标准，必须由客户或产品负责人进行确认。用户故事和待办事项列表的优先级排序也一定要由能够代表用户的角色来确定，比如代理产品负责人。
开发团队可以通过访谈、问卷调查、观察和故事编写工作坊等形式来开展用户故事编写。而故事编写工作坊是快速创作用户故事最有效的方法之一，可以在开始每个发布计划之前举办。
避坑指南二
编写用户故事的职责，依次降低：
项目中的客户、用户
项目中的市场、业务方面的人员
产品负责人，或代理产品负责人
研发团队中的熟悉用户和业务的业务分析人员、测试人员
研发团队技术成员
注：在具体的软件项目实践中，很多时候尤其是在项目前期，团队通过工作坊的形式来编写初始的一些粗粒度用户故事。如果给团队显式明确了编写用户故事责任的优先级顺序，可能会造成技术人员觉得编写用户故事不是技术人员的责任，因而消极甚至拒绝编写用户故事。为此，也可以不给团队明确责任排序，以促进自组织和团队成员的积极性。
03、陷阱三：谁是用户？
技术团队容易陷入“以技术为中心”思维，自以为是地闭门造车，想当然地认为自己理解的就是用户需要的。但用户是谁，却不清楚。
有时候，团队所认为的用户过于单一抽象，用户范围过大、过于抽象，比如“销售人员”，导致定义不清。而另一个极端是，用户角色过于精细，角色过多，导致团队对需求的精准理解产生混乱。
有时候，开发的软件可能是给别的软件或者系统用的，比如中间件、微服务等。一个复杂系统包含很多各自独立但又紧密关联的软件和组件，各个部分是整个软件或系统的组成部分，有自己的上下游接口。此外，团队自己内部系统的不同组件也可能相互调用。所以，很难为这类系统或组件定义清楚的“人类”用户，团队很容易陷入以技术为中心的思维，只关注接口，忘记其实上下游系统及本身不同部分都是“用户”——系统用户。
那么， 该怎么来精准定义用户角色呢？
避坑指南三
团队可以使用设计思维工具进行用户研究：
用户画像
用户访谈
同理心图
用户体验地图
干系人图
针对系统用户，可以尝试：
定义上游的“供应方”和下游的“消费者”用户，它们是软件系统、组件或者接口。
“供应方”和“消费者”加强沟通和协调：明确彼此的需要和依赖，比如接口类型、数据格式等技术参数。
将系统用户的需求纳入待办事项管理：由下游向上游提出需求，编写用户故事，明确技术指标，放入上游团队的待办事项列表，统一进行优先级排序，纳入发布计划和迭代计划。
04、陷阱四：使用不规范？
需求千万条，价值第一条；
故事不规范，交付两行泪。
日常工作中，诸如格式不完整、用户不明确、价值描述不清晰等问题非常常见，而由此导致的交付失败也时有发生。那么，怎么才算是规范的用户故事呢？
因此，好的用户故事，应当格式规范、要素完整、各自独立。故事之间还要尽量避免相互依赖。用户故事之间相互依赖，会导致排列优先级时，或者做迭代规划时出现问题，而且使用户故事的估计变得困难。
因此，规范使用用户故事，如何做到格式规范、要素完整、各自独立呢？
避坑指南四
规范使用用户故事，要做到：
使用故事标准格式：使用“作为<角色>，我想要<功能>，以实现<商业价值>”模版。
遵循 INVEST原则：即：
独立的
可协商的
有价值的
可估算的
小的
可测试的
定义“就绪定义”：定义团队一致共识的“就绪状态”检查表。
定义“完成定义”：定义团队一致共识的“完成定义”检查表。
定义“验收标准”：就如何确认和验收用户故事达成一致并进行测试。
如果依赖不可避免，则尽量尝试：
重新整合用户故事，换一种方式对故事进行分割。
低优先级的故事依赖于高优先级的故事
被依赖的故事给个较高的故事点，依赖其他故事的给个较低的故事点
将相互依赖的故事放到一个迭代中进行开发和交付
将相互依赖的故事分配给同一个人
05、陷阱五：故事点大PK？承诺？
老板：小王，你看隔壁团队这个迭代完成了120个故事点，为什么你们团队只完成了50个？
小王：他们承诺了130个故事点却只完成了120个，而我们承诺了45个故事点但完成了50个故事点，还超出了承诺呢。
老板：。。。。。。
故事点考虑了事项的复杂度、不确定性、工作量及风险等因素，只是要完成工作的一个大致相对估计。故事点没有统一的大小和普遍的度量基准，不同团队故事点基准的设定不尽相同。
因此，上述情景出现了两方面的错误理解：
用故事点来横向比较不同团队的绩效。
用故事点估计当做团队的承诺。
要避免上述错误，可以尝试：
避坑指南五
关注价值，而非故事点。 关注迭代交付了多少功能，而非故事点。
故事点只用来记录团队的工作速率并进行迭代计划。
不做团队之间的横向比较。
采用相对估算：定义基点之后，其他故事以基点为参照确定大小并进行排序。
必须理解，估算包含很多不确定性。没必要追求100%的准确性，也不是团队的最终承诺。
随着估算数值增大，其包含的不确定性、复杂度和风险也会成倍增加。采用斐波那契数列来确定用户故事的点数，拉大估算数值，体现点数所代表的不确定性和风险的大小。
使用规划扑克：规划扑克是来自于宽带德尔斐方法的一种集体估算方法，包含了心理学的某些原理。
06、陷阱六：就绪——准备好了吗？
用户故事在放入迭代进行开发之前，需要经过深度讨论、排序，确保用户故事是“就绪”的。这需要用户、团队一起确定一个明确的“就绪”的定义，明确用户故事具备了什么条件后才算“准备好了”，可以纳入迭代规划进行开发。
“就绪”定义通常是一个检查列表，明确列出大家达成一致共识的检查事项，只有满足该检查表的各个条目，才可以将用户故事纳入迭代计划进行开发。不满足“就绪”条件的用户故事，不应该放入迭代计划进行开发。
避坑指南六
定义“就绪定义”：团队需要提前就什么是“就绪”达成一致。
明确标准：制定检查列表，明确列出一致达成共识的检查事项，只有满足该检查表的各个条目，才算“准备好了”。
在团队或项目范围内，针对不同类型的用户故事，可以制定不同的“就绪”定义。但无需为每个故事制定 “就绪定义”。
定期回顾“就绪”定义中的条目，根据实际对其进行更新。
下图为“就绪”的一个例子
07、陷阱七：完成——搞定了吗？
用户故事怎样才算是完成了呢？如果没有统一的共识，很可能出现“自己觉得故事完成了但别人却不认为完成”这样的情况。
比如，功能代码写完就算完成吗？还是功能测试之后才算完成？还是功能上线到生产环境才算呢？
又比如，需求级别不同，比如史诗故事、特性和用户故事，是否要制定完全一致的完成标准呢？用户故事类型不同，比如功能性、非功能性、探索性的，它们的完成标准是否要一致呢？
还有，团队眼中的“完成”和用户眼中的“完成”是否一致？用户故事最重要的是客户价值，团队“完成”，用户还需要进行最终“完成”的确认。
这是两种不同的“完成”标准。团队需要确定在迭代级别的“完成”，确保所有必须的工作都做完了。用户需要验收完成的功能，确认收到了满足需要的软件功能。
前一种是团队眼中的“完成定义”，即常说的 Definitions of Done，简称DoD；后一种是用户视角的接收标准，即Acceptance Criteria，简称AC。
避坑指南七
确定“完成定义”：团队一起就怎么才算完成达成共识：
为不同级别的故事定义相应的完成检查表。
为不同类型的故事制定相应的完成检查表。
明确列出完成检查列表：把共识写下来，列出完成的检查事项。
初期，完成定义可以简单些，适当宽松。随着项目基础设施的完善和团队合作的提高，可以逐渐增加严格的完成标准。
每个迭代结束，回顾和更新 “完成定义”。
定义“验收标准”：用户、产品负责人及团队，讨论如何测试所实现功能的细节及测试方法：
由用户或产品负责人编写验收测试，最好也由用户或业务人员来执行。
或团队编写、确定验收标准，但一定要由客户或产品负责人进行确认。
验收测试针对每个用户故事所实现的功能，每个用户故事需要特定的验收标准集合。
尽可能自动化验收测试。
使用GWT 格式：也叫Gherkin格式，即 “Given ...... When ...... Then ......”，可作需求文档，也可作为测试标准文档。
准确区分“完成定义”与“验收标准”：
完成定义是面向团队的，是团队为完成某个待办事项而需要完成的工作列表。而验收标准是面向用户的，是用户验收团队所实现的功能是否满足用户需求而需要满足的条件，通常是一系列的测试案例，验收标准最终在验收测试中进行验证。
完成定义是针对迭代期间正在开发的工作增量，就新功能、新特性，不是针对某一个用户故事的。而验收标准针对的是某一个用户故事，不同的用户故事具有不同的验收标准。
团队负责待办事项的完成必须满足完成定义，而用户或产品负责人负责确认该功能是否满足用户的要求。
验收标准是适用于完成定义检查列表中完成标准的有效补充，而非取代，可以称 验收标准是完成定义在每一个具体待办事项上的补充。完成定义的检查列表适用于所有的待办事项。
为了不使完成定义和验收标准在术语“完工” （ Done ）方面对产品负责人、团队产生混淆，可以将满足完成定义的待办事项的状态称为“完成”（Completed），而将满足验收标准的待办事项的状态称为“接受”（Accepted）。
08、小结
本文探讨了技术团队在使用用户故事过程中常见的问题并提供了应对之策。
用户故事是敏捷软件开发的基本实践之一，有着十分重要的作用。有效、高效地使用用户故事管理和跟踪用户需求，对软件项目的成功至关重要。
本文来自微信公众号“CIO Talk”（ID：CIO_China_Lab），作者 吴舜贤。
管理圈经授权发布，如需转载请联系原作者。
粤公网安备 44010602010970