交付时效提升20%，宁波银行规模化敏捷试点这一年

本文摘自QECON组委会与中国信通院联合发布的2021《研发效能实践指南》白皮书（下文简称「白皮书」）行业案例部分。宁波银行试点推行规模化敏捷转型一年来，已取得试点团队交付时效提升20%的阶段成果。本文从试点选择、方案引入、落地实践、未来规划等各个方面，对宁波银行这一年规模化敏捷转型试点进行了全面复盘。

文末有赠书活动，在评论区留言评论，留言获赞数高的读者，即有获得《研发效能实践指南》白皮书纸质版。

本文作者：龚舒聪、倪凡乐，宁波银行金融科技部PMO；周麟，Agilean高级顾问

近几年，随着研发人员迅速扩张，「人月神话」陷阱也越发困扰我们，简单增加人头已不能带来满意的产出。研发过程中大量的效能损失，促使我们踏上研发效能提升之旅。研发效能平台、效能洞察度量平台、自动化测试等平台纷纷建立起来，迅速弥补了工具上的不足。但一体化的体系建设，在针对个体团队形形色色的实际情况时，往往存在落地困难，离团队真正能用起来、用好还隔着「最后一公里」。

因此，我们开展了产品级别的规模化敏捷试点，通过研发效能实践，在提升团队研发能力的同时，将分支管理、环境管理、自动化测试等工程实践也真正落地到团队中去，打通「最后一公里」，全方面提升研发效能。总结本次实践，从客观数据上看，研发效能（需求交付时效）提升了21%左右。

下面详细介绍本次实践的关键点。

1

如何选好第一个规模化敏捷试点

选择试点团队时，作为第一个规模化敏捷试点，我们综合考虑了银行组织架构中的常见痛点，如前后端系统团队分离，产品开发测试三方人员分离，跨部门协作复杂，缺少唯一需求收口方等，选择了从更适合做敏捷实践的产品团队入手。

该团队具有以下利于开展敏捷实践的特点：

• 偏产品化管理，前后端都在同一个部门，部门外系统依赖性较小；

• 规模适当，50+人员，作为一个部落刚好合适；

• 在研发团队中有一个专职产品经理 (BA)团队，承接转化来自业务部门的需求，承担需求收集、需求细化、需求文档撰写、需求优选、需求交付管理等工作，相对来说需求可控性高，产品人员参与意愿高；

• 测试人员已进入研发团队合署办公。

2

试点团队存在哪些阻碍效能的痛点？

虽然该团队具备部分实施敏捷转型的有利条件，但团队尚未按敏捷开发方式运作。因此在转型之初，整个研发过程中还是存在不少阻碍研发效能的痛点难点，主要表现在以下几点：

组织架构上，团队成员没有端到端

交付团队按职能划分，为共享资源池模式；开发前后端分离，用户故事需要跨小队协作；测试资源混用，造成测试资源争抢等。

过程管理上，没有版本概念，按单个项目分散管理

具体表现在，团队成员所负责的项目周期经常不一致，短的一两天，长的几个月。导致同一时期，团队成员只聚焦自己的项目进度，缺少统一的目标，缺少沟通协作的动力；且并行交付的需求过多，交付周期长。

项目管理方面，由于缺少计划性和上线承诺，延期压力相对较小，项目延期情况比较普遍，团队敏感性不足。

需求管理上，没有严格的排期规则

排期时没有按研发团队容量来约束，存在较多的超量排期、倒排期、需求不明确、需求插队、需求变更等情况，成为影响研发效率的重要障碍之一。

分支及环境管理较弱

由于没有版本概念，原SIT分支是个长分支，不同时期上线的项目代码都会被放上去，混测，直到UAT测试环节，才会把能在最近上线窗口上线的项目合到UAT分支上。一方面，项目混测，影响SIT轮测试的可信度；另一方面，缺少版本晋级的概念，重新抽代码打包，在UAT环节容易出新问题，或缺陷重开。

自动化测试缺失

研发团队基本没有推行自动化测试工作，版本手工回归工作量大，风险后移，产品质量守护不足。

3

Adapt框架与版本火车引入

结合试点团队、阻碍效能提升的痛点以及期望，我们引入了Agilean公司的Adapt模型，导入产品部落制和版本火车机制。

同时，根据团队情况量身制定高度定制化的过程管理制度和工程实践方案，建立如需求准入、需求变更、分支策略、环境管理、自动化测试、测试数据镜像库等实践的细则，手把手引导团队排除落地版本火车的各种障碍，赋能团队进行版本火车自运转与持续改进的能力。

整个方案中的组织架构方面采用规模化敏捷的产品部落制模型：

Adapt框架章程图

产品部落制组织架构的目标是聚焦服务业务部门，减少过程沟通成本，降低业务需求复杂带来的系统间高耦合度，提升需求交付时效，快速响应市场变化。

完成业务需求所要的各种必要资源都会被纳入到部落中，再进行合理的分组和职责分工，主要包括部落长、架构师、产品经理、研发小队长、开发、测试、版本经理、配置管理员等，要保证部落中80%以上的需求都可以在本部落中消化，才能真正发挥出部落的作用来。

所以，系统解耦是很多传统企业在做敏捷转型时一个比较大的障碍。

虚拟部落制示意图

虚拟部落制的纵向组织

纵向组织小队和部落面向价值交付，偏重于「用兵」，以价值交付和业绩提升为方向：

• 部落：相同业务领域所有小队集合，面向具体业务稳定输出，人数一般小于150人，设置部落长对整体交付过程负责，部落长常由具体业务领域负责人担任。

• 小队：业务端到端交付的最小单位，包含所需业务、研发人员，人数一般约10人。小队长常由开发负责人或产品担任。

虚拟部落制的横向组织

横向组织分会和行会面向能力提升，偏重于「养兵」，以专业化为方向：

• 分会：同一个部落中相同能力领域内拥有相似技能的人员。设置分会长负责发展员工，设置薪水等。分会长常由职能团队负责人担任。

• 行会：跨部落的兴趣社区，定期进行知识、工具、代码和实践的分享，设置协调员来组织。

研发过程管理的方案以版本火车为模型：

版本火车强调计划性，团队聚焦在同一个版本的目标上，开发和测试同频。这样做的好处是开发人员不需要在开发下次上线内容的同时，还需要去修改本次上线内容的bug，频繁切换项目需要高额成本，且集中提测会导致在一段时间中测试压力和修复缺陷压力骤增，研发节奏不平稳。

当然，开发测试同频时，为了快速质量反馈，形成双周发布节奏，需要把用户故事拆小，尽量研发工作量在3-10人天以内，多人并行研发，最好在本迭代开发后的2天后就能陆续交付可测试的用户故事，形成流式提测。

4

试点团队6大落地实践

基于上述的试点方案，主要落地的相关实践主要有：

1. 划分5个端到端小队

将团队组成产品部落，根据业务领域划分出5个小队，每个小队都是端到端的：

对团队各类角色进行了清晰的职责认定：

2. 版本火车节奏

整个版本节奏为：2周需求准备+2周开发测试+2天新增回归+2天全量回归+4天版本准备。

实际上，需求准备的两周是可以不算在版本中的，只要在需求钻石日时，团队能保质保量给出需求待办列表即可。但由于当前团队的需求阶段还没有这么顺利，会出现排期时需求不清晰、来不及澄清等情况，故在版本火车中将需求准备的两周也列出来，在传统公司中该阶段明确出来还是很有必要的。

我们同时制定了版本日历透明给团队，让团队成员清晰了解版本进度。由于我行的上线窗口并不是完全固定的，所以为了兼容有依赖系统时要一起上线的情况，上线日期保持与全行统一上线窗口一致，导致每个版本需要倒推下版本日历。

• 浅蓝色为两周的需求阶段。需要完成需求收集、澄清、估算及排期。在需求优选日，需要确定这个版本计划上线的需求，后续一周中进行需求澄清和评估工作。在预排期日，要完成所有用户故事的澄清、评估及尽可能多的提测时间。在需求钻石日（排期日），完成所有用户故事的工作量评估，负责研发人员、测试人员及提测时间的确定，形成排期表。

• 淡紫色为本版本的纯研发时间段。此时测试在做上一个版本的回归测试。

• 深紫色为研发+功能测试时间段。在这段时间的倒数第二天，截止提测，最后一天功能测试结束，缺陷清零。缺陷无法清零，需求需要下车，产品经理、研发人员和测试人员需要达成一致。如果出现分歧，可上升至部落长、业务负责人、测试分会长三方共同决议。

• 橙色为回归时间段。是新增功能回归测试+全量主流程回归测试，一般为4天。前两天用于新增功能回归测试，后两天用于全量主流程回归测试。当某个版本开发时间特别长或者特别短，回归时间可以等比例增减。回归完成的当天为封版日，是投产日T-4那一天。

• 绿色为投产日，在排期过程中最先确定。这是根据我行的投产日历确定的。

• 若非常规版本火车，则从投产日向前倒推，研发和测试等比例缩放。比如当研发时间为三周时，版本回归测试时间由2天变为3天。

3. 质量左移

质量左移也是这次的主要实践内容之一，对于塑造团队纪律，提升研发质量有明显帮助。主要分桌面检查和需求准入两部分，把质量门禁前移。质量左移实践包括以下内容：

桌面检查

主要为了提升开发人员自测的质量，业务、产品参与桌面检查，相当于提前验收，可以尽早验证开发的功能与自己设想的是否一致，及早发现因开发理解错误而引起的开发了错误功能的情况，降低调整成本。

后期，桌面检测的准时提交率、一次桌面检查通过率都会纳入版本常规考核中。

需求准入

这方面的改进对研发管理的帮助很大，因为以前排期概念不明确，哪怕有排期也往往流于形式，排进来的需求经常只有粗粒度的描述、澄清不清、插队情况严重，导致预估工作量不准确、在研发工程中挤占开发测试时间。

在这次实践中，我们明确了排期准入的标准：只有在需求钻石日前有完整需求文档、完成了需求澄清、开发/测试接受且能给出较精确预估时间的需求才能有资格进入排期。

并且在排期结束后，每个需求都需要给出明确的提测时间。

4. 分支管理

BEFORE:

• 在UAT才拉版本分支，前期多版本分支合并在一起，测的内容不可靠

• 跨版本长分支长时间没有合并代码，容易发生代码冲突，常常一次合并要解决两天的冲突

• 版本分支拉取比较靠后，在版本代码剥离过程中，容易出现代码合并遗漏等问题

NOW：

• 版本开始前拉取版本分支，测试内容为版本排期内容，可靠性更高

• 版本过程中按用户故事拉开发分支

• 用户故事通过桌面检查后，将开发分支合入版本分支

• 版本封版前，特殊情况可让"用户故事下车"，进行代码回退

• 版本发布：合入master主分支，打版本标签，并广播至其他远程分支，合并更新最新master代码

• 版本分支出制品包，代码管理有统一提交规范，避免版本代码合并遗漏问题

5. 环境管理

原来的SIT和UAT环境分离，一方面导致SIT测试内容不可靠，另一方面也会有环境切换的时间以及造数的成本。同时版本晋级本就是配置管理中比较重要的一项内容，不管做不做敏捷，都是属于应该管控起来的点。

但是由于其他系统仍采用SIT和UAT两套测试环境，试点团队的环境合并策略需要考虑到该外部因素。最终，我们找到了一个解决方案，便是由试点团队主动切换连接的外部环境，以满足不同阶段测试的要求：

• Dev联调环境：研发用户故事的跨系统联调环境，对接外部的SIT环境，直至桌面检查通过后的用户故事才可合入到R版本环境。

• R版本环境连外部环境：部落内各系统常规会有两个版本，版本环境的配置做了配置文件抽离（将代码里直联的内容做了配置化），版本环境需要连外部环境可修改配置文件或是通过ESB配置修改环境地址，以确保版本环境始终连接外部系统最稳定的测试环境。

• 外部环境连R版本环境：外部环境需连系统的稳定版本测试环境，只需要连统一的F5地址即可。内部版本环境在切换时，需修改F5地址的应射关系，以确保外部环境连接至系统的稳定版本环境。

6. 自动化测试

在自动化测试策略制定时，也是充分考虑了团队能力及性价比的因素，单元测试对于团队的压力以及成本都比较大，难以推广；UI测试适合前端界面多的产品，本产品有较多的后端逻辑，所以综合考虑接口自动化测试最为合适。

但是单接口测试，往往也有只看到覆盖率提升，难以实际替代人工测试量的缺点，投入产出比较低。所以我们最后决定并不是盲目得堆接口测试覆盖率，而是从核心回归测试案例入手，以场景化接口自动化测试落地，切切实实地替代人工回归测试工作量。

本次实践中，产品/测试共梳理了214个案例，研发人员最终完成177个案例，其余不方便用自动化测试来执行的案例仍由测试人员手动守护，实际替代了80%左右的人工回归工作量。尤其在回归阶段仍有代码变动的情况下，效益愈发明显。

5

试点后，我们还要做哪些

总的来说，本次试点无论从客观数据，还是领导、参与同事的主观反馈来说都还是不错的。同时，还有一些容易被忽略但非常重要的工作，那就是文化建设及人员培养。

试点工作最怕的就是遇到回退，外部教练一退场，没过多久团队就打回原形，试点工作前功尽弃。所以为了让团队有自运行下去的能力，在让团队领导认可试点成果，并将试点度量指标运用到绩效考核中的同时，在整个试点过程中，我们持续进行了关键人员的相关能力培养和敏捷文化导入。

需求人员能力培养

包括用户故事拆分及需求漏斗模型等能力赋能。

产品经理需要具备持续管理需求流动的能力，利用Adapt体系中的需求漏斗模型，合理管理需求流动，提升产品经理需求孵化质量，避免研发需求断流，从全量承诺到价值优选，最大化利用资源，形成需求漏斗。

小队长确责与全面赋能

对小队长需求管理、交付协同、数据分析、风险识别、进度同步、问题分析与处理能力等进行辅导。

以上的赋能矩阵，让小队长对交付管理有了意识与方法论的支撑，并在实践过程中让小队长亲身体验每个过程，连教带练，将敏捷文化植入到肌肉记忆中去。

敏捷文化建立

在整个实践过程，不断组织敏捷实践专题培训及工作坊，加强文化宣导。

并组织了内部教练培养，包含基础考试与实践材料分享，通过后可以授予内部敏捷教练证书。通过证书激励，激活敏捷实践积极分子，加深团队敏捷文化。

总的来说，授人以鱼，不如授人以渔。唯有团队自身有了不断自我提升的意识，才能在一次次迭代中通过回顾去总结精华、排除糟粕，持续进化，走上良性自运行的精益之旅。

赠书福利：Agilean与白皮书编委会，共同为大家带来了更多精美纸质版《研发效能实践指南》白皮书。在本文评论区留言，邀请好友对留言点赞。12月22日18点前，留言获赞数前10名的读者（添加小助手微信：agilean-service，将获赠纸质版白皮书一本。

推荐阅读

01   Adapt规模化敏捷框架全面解读

02  长沙银行数字化转型三年嬗变

03

上海银行：开启2500人研发数字化管理转型

04

银行数字化&规模化敏捷路线图