敏捷是一种态度：有了敏捷建模，就有了敏捷需求

目    录

01 缘起

02 敏捷需求5W1H的思考‍‍‍‍‍‍

03 关于敏捷需求体系的一些思考‍‍‍‍‍‍

04 写在敏捷需求后的话

01

缘起

对研发效能提升的研究，是近年来各家企业技术部门一直在研究的课题。早期，针对敏捷开发的实践，让大多技术管理者尝到了甜头，不再拘泥于三月两月一次发版，有些创新类研发项目已经可以做到一月半月乃至以周为单位进行投产。高效的科技运营促进了业务高增长，也增强了企业核心竞争力。

但对于诸如核心系统，一些一级/重要/大的系统建设，就算可以敏捷开发，但在需求侧，还未全部敏捷起来，很多企业还在走业务需求、软件需求的需求阶段成熟推进路子，这大大提高了需求工期在整个研发中的比重，不利于研发效能的提升，更谈不上敏捷研发了。

针对整个研发生命周期的考量，相对于开发侧的敏捷，需求侧的敏捷一直以来都很薄弱，虽然有些诸如创新类项目那种低量级的小需求，缩短了整个迭代周期，但这种追求速度，未进行规范导致的需求质量不高，需求资产未得到复用，特别是对高量级的项目需求，还很难敏捷起来。

也就是说，只有敏捷开发是不够的，还需要有敏捷需求。所谓兵贵神速，研发要想在效能上有所提升，其中需求的敏捷势在必行。

02‍

敏捷需求5W1H的思考‍‍

我们采用5W1H方法来全面阐述敏捷需求。

图1：敏捷需求的5W1H

2.1 什么是敏捷需求？

“敏捷”这个词，字面上的意思是灵敏快捷，通俗地理解就是简便有效，灵活快速。那么“敏捷需求”的意思，简单理解就是使需求工作简便有效，灵活快速起来。

从需求工期上来看，简便有效、灵活快速的需求工作，可大大缩短了预期的需求工期。例如原来半年的需求工期，采用了敏捷需求，在同等条件下，如需求人员数量和能力等都不变的情况下，需求工期预计可缩短为3个月，那么这个项目需求就敏捷起来了。

同样，与敏捷开发下的小量级需求工作不同，敏捷需求在保证规范、有质量的需求工作上，相对于非敏捷的传统需求工作来说的，做到了需求工作小步快跑。

这样看来，“敏捷需求”是在保证规范、有质量的需求工作上，通过简便有效，灵活快速的方法，实现了需求工作小步快跑。

图2：敏捷需求全过程

敏捷需求覆盖全部业务需求和软件需求，涵盖了部分架构设计；通过建模的方式简便有效易于结构化，模型化的方法易于灵活快速无缝贯穿需求全过程。

2.2 需求为什么要敏捷？

从研发生命周期管理来看，开发侧有敏捷开发，测试侧有自动化测试，投产侧有一键部署能力，运维侧有自动化运维，也就最前面的需求侧能力还未提升。加强需求侧能力建设，是推动整个研发敏捷能力不可或缺的一环，那么敏捷需求就成为了不二的选择。

从市场竞争，业务要求及系统不断更新迭代上来看，再遵从原来按部就班地走咨询立项、业需立项、软需立项的建设路子，只会延缓整个企业数字化转型的进程，特别是中小企业/银行，更加拖不起、等不起。唯有敏捷，方可闯出一条出路，再实现弯道超车并无不可。

从需求本身工作来说，需求交付开发的过程是存在断层的。需求的产物有流程图、界面原型、需求规格说明书等，这些需求产物交付给架构设计人员、技术开发人员，只是实现了逻辑的连贯，未能实现物理的连贯，也就是说需求产出的是把业务可理解的语言转化为技术可理解的语言，技术再根据这些语言，通过代码的形式转变为计算书可执行的程序。技术语言与代码程序之间是断层的，不可持续，这样需求就无法敏捷起来。

图3：敏捷需求工作流程‍

而敏捷需求不但追求逻辑连贯，需求规范有质量，也追求物理连贯，需求产物的技术语言可以直接转化为代码程序。这其中的抓手就是界面原型与前端页面代码之间的一体转化。

2.3 需求怎么样才能敏捷？

大凡工作敏捷化，都是追求化繁为简。需求敏捷化的追求也是一样，通过敏捷建模（即构建模型）的方式，来实现需求敏捷。

图4：敏捷建模

需求模型化工作分业务建模、流程建模、表单建模、规则建模和数据建模5个不断深入细化的环节。具体如下：

1） 业务建模

业务建模，也叫构建业务模型，可通过领域五级建模方法，从领域、阶段、活动、任务、步骤五个层面进行拆解细化，把整个业务逻辑刻画出来。

业务建模输出的有：概念模型ER图、业务目录、业务实体等。

2） 流程建模

流程建模，也叫构建流程模型，是在业务建模的基础上，通过L3流程建模方法，识别并定义各主分支流程名称，参与流程的角色及权限，流转的节点及流转规则等；

流程建模输出的有：逻辑流程模型图、流程功能、流程实体等。

3） 表单建模

表单建模，也叫构建表单模型，是在业务目录及流程功能基础上，定义表单模型页面字段要素及要素规则等。表单建模原则遵循业务合理性、用户最佳体验以及数据标准等。

表单建模输出的有：逻辑模型界面原型、输入输出要素（字段及字段规则等）、表单实体等。

4） 规则建模

规则建模，也叫构建规则模型，是在业务建模、流程建模、表单建模的基础上，识别并定义出业务功能规则描述、非功能规则描述等；

规则建模输出的有：逻辑规则模型、规则实体等。

5） 数据建模

数据建模，也叫构建数据模型，是在流程建模、表单建模、规则建模的逻辑模型基础上，定义数据物理模型及数据实体等；

数据建模输出的有：数据模型如数据库表、数据结构、数据实体等。

综合以上敏捷建模五步方法，需求分析人员构建业务模型、流程模型、表单模型和规则模型，架构设计人员构建数据模型。

需求规范、有序、有效、有质地把从不成熟需求转变为成熟需求，不稳定需求转变为稳定需求，沉淀实体资产，提升需求质量，降低需求缺陷。

与纯需求规格文档相比，特别是页数在1000页以上的项目需求文档维护工作来说，对文档规范强迫症犯者来说是福音，不用再花精力在文档编号规范、格式规范、形式规范、图文规范等上面，遇到能够一步自动规范还好说，不能一步自动规范就得手动规范调整时那种无效工作带来的无力感。

拿需求文档修改工作量来说是比较枯燥繁重的。遇到一个字段要素的更改，原型改一次，文档里的要素改一次，业务规则描述也可能要改一次，特别是上下文出处较多，还不能用全部替换来修订的，特别麻烦，需求规格文档编辑工作占到全部需求工作没有三分之二，也有二分之一。采用敏捷建模方法，省去了大量文档编辑工作量，同时能够实现以下能力：

I. 通过Jason入库，可支持需求原型直接转化为前端页面；

需求人员绘制的原型界面，评审通过后可通过Jason入库，自动生成为前端页面。

II. 通过规格配置，可自动生成需求规格文档；

需求人员构建的流程模型、表单模型、规则模型等，评审通过后，可自动生成配置好的需求规格文档。

III. 通过规格配置，可自动生成测试用例；

需求人员构建的流程模型、表单模型、规则模型等，评审通过后，可自动生成测试用例，便于开发人员进行单元测试，SAT人员进行测试，UAT人员进行验收。

有以上建模能力，不但实现需求态敏捷，也带动设计态、开发态、测试态的敏捷。

2.4 谁的需求敏捷了？

整个研发生命周期中，从业需、软需、设计、开发、测试、投产、运维中，参与研发的角色有很多，诸如业务人员、业务需求分析人员、软件需求分析人员、架构设计人员、前端开发人员、后端开发人员、SAT测试人员、UAT测试人员、运维人员、项目经理、技术经理、质量经理、业务主管、需求主管、架构师、开发主管、SAT/UAT测试主管、专家/评审人员等。

建立了以需求原型界面为抓手，全体研发人员都可以直观、快速地从了解需求、理解需求到熟悉需求的一个过程。其中，业务需求分析人员、软件需求分析人员和架构设计人员的建模能力要求如下：

业务需求分析人员，需要具备业务建模、流程建模等能力；

软件需求分析人员，需要具备流程建模、表单建模和规则建模等能力；

架构设计人员，需要具备数据建模等架构设计能力；

业务需求分析人员对业务的理解无法达到100%，再加上信息传递过程中的失真，软件需求分析人员对业务的理解很难超过业务需求分析人员。同样的架构设计人员对业务的理解不会超过需求分析人员，也就是说在整个研发链路上，越后面的人对业务的理解越弱，到了业务测试人员进行验收时，就会导致很多需求缺陷的存在，以及不可避免的出现大量需求变更，给研发交付/上线/投产带来不可预估的项目风险。

还有需求分析人员，重功能实现，轻用户体验的现象会大为改观。有了比较直观快速，亦或为所见即所得的敏捷建模，需求分析人员有了多余的时间来增强用户体验的改进。

而敏捷需求采用敏捷建模方法，可以很好地把研发链路上各个角色都统一在敏捷建模上面，以原型为抓手，兼容流程、规则、数据等模型，以及需求全过程管理中的缺陷/问题/解决方案、进度/评审/验收、讨论/评论/评价等一站式一体化呈现，大大提高了需求的质量管理、审批管理、资产管理等能力。

2.5 需求敏捷能多久？

采用敏捷需求的敏捷建模方法，提升了企业级/组织级/项目级的需求能力，而需求能力的提升，一是提高了需求的产量和质量，一是缩短了需求的工期。

一个故事点的平均需求工作量评估上，原来要10人天完成的工作量，采用敏捷建模方法后，随着需求模型化能力的成长成熟，只需要4-5人天即可完成。这里面大大节约了文档编辑的工作量。

敏捷需求能力见长，则需求产量和质量也见长，需求工期见短。同理，敏捷需求能力回退，则需求产品和质量也会回落，需求工期也会变长。这些不是简简单单靠压迫外包供应商所能管控的，而且研发能力不会完全依赖于外包，一旦被外包裹挟带来的必然是局面的被动。同样，具备需求敏捷的能力，在于外包供应商合作谈判中将获得优势。

需求敏捷是长期坚持、持续协同的工作。

2.6  需求敏捷在哪里？

1） 需求能力有所提升

敏捷需求更关注需求人员能力建设，原先需求人员需要具备需求分析能力，敏捷需求建设下，需求人员需要具备需求设计能力。

需求分析能力，注重业务语言的理解和熟悉，并转化技术语言的能力，无法超越业务。

需求设计能力，弱化业务语言转化技术语言的能力，注重对业务本质的理解并超越业务。

例如最近的个人养老金账户产品需求，需求分析人员根据业务人员设计的产品进行分析并落地实施，而需求设计人员在依据业务人员设计的产品上，结合需求资产，比如渠道需求资产，原来产品需求里只有一个通过二维码来打开手机银行APP的渠道路径，需求设计人员针对无APP用户的个人养老金账户无法覆盖的缺陷，可以根据各个渠道路径的选择，可以增加从二维码/微信公众号/微信小程序/支付宝生活号/...快速引流至H5开户页面，来避免需要下载手机银行APP，并注册用户的麻烦而退却的流量流失。

故而具备需求设计能力的需求人员，可以是业务产品经理优秀的助手，利用自己熟悉的需求资产支持业务产品设计的实现。

需求能力的敏捷，不但更多覆盖了业务侧能力，如引流设计；而且也更多扩展了需求侧能力，比如用户体验、需求质量、需求工期等；还更多辐射了设计侧、开发侧、测试侧的能力提升。

2） 需求工期有所缩短

对于低量级的小需求，在保持需求快速迭代的能力上更规范、更直观，随着需求资产的复用率提高，原来一个2周的迭代版本能够实现5个功能点的部署，需求模型化的敏捷能力，一个2周的迭代版本可实现10个功能点的部署。

对于高量级的项目需求，随着需求文档编写工作的弱化，需求工期可大大缩短，工期缩短比例在30%-50%之间。

依据需求工期缩短比例的多寡，我们可以针对敏捷需求能力成熟度进行量化评估，以高量级的项目需求为例，比如零售信贷升级改造项目，未采用敏捷需求建模方法，预估10人6月（60人月）完成，设定为敏捷能力1.0计，采用敏捷需求建模方法后，若同样10人且只需要3月（30人月）完成，敏捷能力提升了50%，那么敏捷能力即为2.0。依次类推，当一个企业项目研发的需求敏捷度，是衡量一个企业项目研发的需求敏捷能力的指标。

3） 需求质量有所提高

敏捷需求所带来的质量的改变，原先项目都以需求文档记载为准绳，业务、需求、设计、开发、测试乃至运维，不论遇到问题还是缺陷都是先看文档，再看各自的理解是否存在偏差，若是需求文档表述有歧义，很容易造成人员在需求理解上失真，这样的需求质量无法监测，也无从考核，需求质量靠主观判断，不能带来客观的评估和评价。

而敏捷需求模型化后，业务、需求、设计、开发、测试、运维等，遇到问题或缺陷，直接在原型界面上表示出来，规则区域内记录了业务规则描述，以及进度和验收；问题/缺陷区里记录来自不同角色提出的各种需求问题以及针对问题的答疑或解决方案；审批/评论区里记录了来自评委的审批意见或其他人员的评论意见等，可以直观地展现需求的成熟度。这样项目全体人员，乃至外部专家都可以直观针对需求故事点提出各种有助于需求质量提升的任何意见，同时在UAT测试阶段可避免大量的需求变更出现，并有效降低需求缺陷的存在，至少在规则描述里，针对有歧义的文字，可以直接提出意见。这些措施都集中在一个原型页面上，而不是需求文档里。

4） 需求资产有所效益

需求模型化，带来了需求结构化。需求结构化，沉淀为需求资产。

五步敏捷建模方法，每一步都可以进行模型化、结构化，并产出相应类型的需求资产。

业务建模，产出业务模型，为业务架构中的概念模型资产，含业务实体。而业务实体作为业务目录类需求资产的唯一标识，可以被有效，不限次的复用。例如客户信息模型中的地址业务实体。

流程建模，产出流程模型，为逻辑流程模型资产，含流程实体。同样流程实体作为流程类需求资产的唯一标识，可以被有效，且不限次的复用。例如法律审查流程实体，既可以被零售信贷流程所调用，也可以被对公信贷所调用，还可以被采购流程等涉及企业合同的各个使用场景所复用。

表单建模，产出表单模型，为逻辑表单模型资产，含表单实体。在原型设计时，一些通用表单，如附件、地址、列表、表套表等组件资产，既可以页面级进行封装发布，也可以组件级进行封装发布。

规则建模，产出规则模型，为逻辑规则模型资产，含规则实体。用户在编写业务规则描述时，可以智能列出可复用的同类规则实体。比如约束条件的语句描述，可以列出一些标准的约束条件规则语句描述文本进行参考。

数据建模，产出数据模型，为物理模型资产，含数据实体。依据Jason入库，可自动建表，并克隆表单与数据的虚拟关联为实质关联，可自动生成前后端连接接口。

敏捷需求建模可产出大量不同类型的需求资产，进行可变和不可变封装之后，可形成通用的公共组件级资产。大量的公共需求资产的无限复用，带来的效益是可观的，不但节省了时间成本，丰富了知识储备，增加了需求工作产量和质量，避免了需求重复工作。

03‍

关于敏捷需求体系的

一些思考

敏捷需求体系，是对传统的研发生命周期的一次升级探索，既落地了咨询规划成果，快速驱动需求敏捷建设，同时直通设计、开发、测试。

建立有敏捷制度、敏捷组织、敏捷流程、敏捷文化等敏捷保障体系，以业务建模、流程建模、表单建模、规则建模、数据建模等敏捷建模方法为核心动力，驱动业务需求、技术需求、运维需求、数据需求等需求来源快速落地，提供需求进度、需求质量等需求管理一站式服务，提供需求结构化、组件化等需求资产一体化运营，是构建敏捷需求体系大航船在蓝海敏捷航行的整体框架。

图5：敏捷需求体系整体框架

04‍‍

写在敏捷需求后的话

敏捷是一种态度，也是一种追求。

大多数需求工作者们，不论是需求工程师、还是需求分析师、亦或是需求管控者；不论其前身是做过业务营销的人，业务管理的人，还是写过代码的开发工程师，管过项目的项目经理，做过测试的测试工程师，还是一毕业就进入需分这个岗位的人等；不论是在互联网公司从事BA、还是在银行从事产品经理的人，都或多或少使用过各种分析工具。

从用Excel、photoshop到Axure等原型设计工具，viso、wps流程等流程设计工具，xmind脑图工具，word文档编辑工具，以及一些诸如版本管理svn，协同办公工具等等，工具有很多，但是这些工具都很分散，相互之间的数据未能打通，无法实现共享。

那么集成这些工具，或者集成这些工具能力，打造成企业级建模工具，帮助企业各个岗位都能够使用，并且相互之间可以无缝对接，是具备敏捷工作的一个充分条件。

普元建立连接的思想，针对企业在各个层面，各个环节，各种维度的断层不连贯现象，建立其上下、内外、前后的全方位立体连接，帮助各个行业各大中小型企业在数字化转型方面获得成功，提供工具支撑。

普元的企业级敏捷建模工具，基于建立连接的思想应运而出。

敏捷建模工具首先集成了这些工具能力，其次植入了低开的技术底座，通过需求结构化、组件化实现了需求资产从沉淀、加工、发布到优化的一体化资产运营。

关于作者：胜棋，普元银行业务资深咨询顾问，从事银行一线营销工作有8年，银行二线研发服务工作有10年。熟悉银行信用卡、信贷、风控等方面工作，擅长IT需求、IT产品、IT咨询、IT售前等研发工作，主导或参与大中型银行业务类、数据类项目建设经验，并落地了一些涉及银行前中后台的研究成果。