需求条目化：一个让用户故事有效落地的套路

摘要：你觉得需求条目化怎么样？

曾经，大概在 2010 年之后的几年里，敏捷在国内变得越来越广为人知，作为重要的敏捷需求实践，用户故事几乎成为了标配。但实践者们对于它，却一直都有着非常多的疑问和困惑，尤其是用户故事和用例的争议，贯穿了国内几乎整个发展历程。虽然在我看来它们的关系很好理解、很简单，Craig Larman 在他的工作坊里面讲得蛮清楚的，也是我个人比较认可的观点。

简单来说，就是如下这个用户故事实践，确实好用，实践者往往也很容易就能喜欢上它，虽然实践起来往往都偏离得比较厉害，首当其冲的就是极少有人会真的严格遵循它的三段式去表述。

其次，当然就是在较大规模组织里面实施敏捷的实践者都会产生的困惑，故事数量多了，该怎么管理？已经完成的故事，怎么处理？跨团队的故事应该怎么处理？

实践者们解决这些问题的方法，主要是用户故事地图（User Story Mapping）和影响地图（Impact Mapping），关于这两个实践，大家可以参考此创始者 Jeff Patton、Gojko Adzic 各自所著的同名书籍。用户故事地图解决了大故事到小故事的关系问题，以及故事发布排期的问题；影响地图则侧重于思考解决从业务目标到用户行为到系统功能的关联问题。

可惜的是，即便把这两个实践都用上，也还存在着没有完全解决的问题。

在上家企业工作期间，给一个银行研发中心做过挺长时间的敏捷转型服务，刚进到项目不久，对方就问了我一个问题：“你觉得需求条目化怎么样？”。那是我第一次听说“需求条目化”这个词，但我觉得这名字蛮有意思，挺好的。当时也觉得能延续客户本身的实践和术语概念有助于实践落地，于是我就把用户故事、故事地图、影响地图、UML 部分图表、ATDD 等大量敏捷实践揉在一起，以及价值主张、设计思维等实践，作为“需求条目化”这个名字背后的操作内涵。从我的角度来看，这些实践的揉合就是让需求条目化从定义变成可操作性定义（出自戴明，Operational Definition）的关键。

为什么突然提到需求条目化？

因为它是我心目中让用户故事变得更有效、更落地的一种套路。

首先，需求条目化的需求结构如下：

我们可以认为它大致上可以对应到 Epic、Feature、Story，但实质上，这三个级别是性质上的不同，而不是 EFS 那样主要是需求规模大小的不同。需求概念位于问题域，澄清要解决的业务问题，比如为什么要启动这个项目？为什么要开发这个新版本？条目则位于方案域，虽然对于研发部门/团队来说，很容易把条目等同于系统功能，但实际上，是完全有可能而且是绝对存在不实现任何功能也可以解决问题的方案的。子条目位于实现域，主要是用来解决研发团队之间分工协作的问题，比如不同模块之间或前后台之间，对于较小型的团队，没有复杂的分工，那很有可能就不需要使用子条目。再往下，团队内部可以再拆分为具体的工作任务，解决内部团队成员之间的分工协作问题。

需求概念、条目、子条目，这三个级别，每个级别都是用户故事，都要以用户故事的质量要求对待，也即 3C 原则和 INVEST 原则。它们都要制定验收标准，然后细化出测试用例、实现测试自动化（我个人坚持 100%）、ATDD。关于验收标准和测试用例的关系，可以看看这篇文章里我跟吕毅老师的不同观点：《实例、接收标准和接收测试》。

具体来说这三个级别可以是什么呢？

• 概念：市场热点、用户痛点、竞品参考等

• 条目：端到端需求，具有终端用户使用价值的功能特性

• 子条目：比较小的端到端需求，或是因应组织现状而将端到端需求拆分到不同架构层级、模块或不同部门团队的技术型需求，例如某个端到端特性的前端呈现和后台处理功能

值得注意的是，这三个级别需求的澄清，并不追求要全部拆分清楚、罗列完毕才开始下一步具体的研发工作，而是采取边澄清边研发的滚动刷新模式。当然这是有前提的，要产生好的实效，这个前提必须做到，就是要有好的可以录入并持续刷新维护三级需求结构的工具，简单来讲就是敏捷需求工具。

澄清需求后，就是对应地纳入各级计划，此处也假设采取的是敏捷规划模式。严格来说是以敏捷规划模式为前提，传统模式通常都要求早期澄清所有或绝大部分需求才能启动研发，敏捷规划模式则强调逐渐细化、增量规划，这些主张跟需求条目化如出一辙。

按照时间顺序来讲，大致过程如下。

确定项目/版本的核心目标并进行优先级排序，剔除低优先级、鸡肋型目标，我个人认为不管项目大小、人员多少，都应该聚焦到 1-3 个核心目标。人多、项目大，那需求概念就大；人少、项目小，那需求概念就大。但不管怎样，再顺着三级结构拆解，至少到子条目都能够成为满足团队迭代排期的颗粒度。

然后呢，就是画场景图，要从用户角度画。用户角度、用户角度、用户角度！用户≠客户、用户≠客户、用户≠客户！用户是厂商所提供服务、产品或功能的实际使用者。场景图也不难，就是理清楚用户和厂商之间的交互过程和触点，比如，应该是用户和华为之间的交互，而不是用户和华为某个网站或某个系统之间的交互。这些交互过程和触点的组合，就是条目，也略等于现在的 JTBD 这个术语的意思。

把场景图里面的厂商部分，再按照系统架构层级或者服务层级或者模块拆分成不同的泳道，将场景图中厂商部分的触点细化为内部不同系统、模块或团队的交互过程，变成子条目。

需求条目化的实践对于工具的要求是很高的，至少我心目中 100 分标准对工具是有很高要求的。比如上面的整个过程，核心关键在于有一个系统维护着这个三级结构，概念、条目、子条目每一级又可以展开需求详情（比如 Wiki）。需求验收标准拆分出来的测试用例要关联至自动化测试脚本，或者本身就是可执行的，最好是跟前面的需求关联起来，形成可执行需求。而且整个结构和各节点除了易于阅读的模式，也即 Wiki、Word 文档或系统里的表单格式之外，最好还能够以一种纯文本化、代码化的形式存储，可以像代码一样进行版本化管理，并支持工具自动生成完整的需求文档，需求、测试、代码的任何修改都能够触发整个流水线执行验证，真正成为实例化需求所主张的活文档（Living Documentation）。

本文分享自华为云社区《用户故事不是银弹》，原文作者：kaverjody。

点击关注，第一时间了解华为云新鲜技术~