共计 2533 个字符，预计需要花费 7 分钟才能阅读完成。
摘要：你感觉需要条目化怎么样？
已经，大略在 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。
点击关注，第一工夫理解华为云陈腐技术~
