---
title: "交付时效提升21%，宁波银行规模化敏捷试点这一年"
url: https://www.agilean.cn/customer-cases/18/
updated: 2023-12-13
description: "宁波银行复盘一年规模化敏捷试点，从团队选择、需求拆分、迭代节奏、环境管理和自动化测试入手，实现试点团队交付时效提升21%。"
publisher: "Agilean（爱捷软件开发（深圳）有限公司）"
language: zh-CN
---

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

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

作者：龚舒聪 发布于 2023/12/12 更新于 2023/12/13

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

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

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

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

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

1

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

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

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

- 偏产品化管理，前后端都在同一个部门，部门外系统依赖性较小；
- 规模适当，50+人员，作为一个部落刚好合适；
- 在研发团队中有一个专职产品经理 (BA)团队，承接转化来自业务部门的需求，承担需求收集、需求细化、需求文档撰写、需求优选、需求交付管理等工作，相对来说需求可控性高，产品人员参与意愿高；
- 测试人员已进入研发团队合署办公。

2

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

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

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

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

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

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

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

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

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

**分支及环境管理较弱**

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

**自动化测试缺失**

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

3

**Adapt框架与版本火车引入**

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

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

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

![](https://www.agilean.cn/cms-uploads/20_51a96f5e03.png)

Adapt框架章程图

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

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

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

**![](https://www.agilean.cn/cms-uploads/20_84948bfa29.png)**

虚拟部落制示意图

**虚拟部落制的纵向组织**

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

- 部落：相同业务领域所有小队集合，面向具体业务稳定输出，人数一般小于150人，设置部落长对整体交付过程负责，部落长常由具体业务领域负责人担任。
- 小队：业务端到端交付的最小单位，包含所需业务、研发人员，人数一般约10人。小队长常由开发负责人或产品担任。

**虚拟部落制的横向组织**

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

- 分会：同一个部落中相同能力领域内拥有相似技能的人员。设置分会长负责发展员工，设置薪水等。分会长常由职能团队负责人担任。
- 行会：跨部落的兴趣社区，定期进行知识、工具、代码和实践的分享，设置协调员来组织。

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

**![](https://www.agilean.cn/cms-uploads/20_3c4dbad0c0.png)**

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

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

4

**试点团队6大落地实践**

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

**1. 划分5个端到端小队**

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

![](https://www.agilean.cn/cms-uploads/20_734a439dc8.jpeg)

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

![](https://www.agilean.cn/cms-uploads/20_3ec0706ae2.jpeg)

![](https://www.agilean.cn/cms-uploads/20_bbc3f89455.jpeg)

**2. 版本火车节奏**

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

![](https://www.agilean.cn/cms-uploads/20_65fbd12c5f.png)

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

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

![](https://www.agilean.cn/cms-uploads/20_25668a80d5.jpeg)

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

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

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

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

- **绿色为投产日，** 在排期过程中最先确定。这是根据我行的投产日历确定的。
- 若非常规版本火车，则从投产日向前倒推，研发和测试等比例缩放。比如当研发时间为三周时，版本回归测试时间由2天变为3天。

**3. 质量左移**

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

**桌面检查**

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

![](https://www.agilean.cn/cms-uploads/20_f870fa9d25.jpeg)

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

**需求准入**

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

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

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

**4. 分支管理**

![](https://www.agilean.cn/cms-uploads/20_0f2df05e38.jpeg)

**BEFORE:**

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

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

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

**NOW：**

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

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

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

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

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

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

**5. 环境管理**

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

![](https://www.agilean.cn/cms-uploads/20_1a56c4da9c.jpeg)

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

![](https://www.agilean.cn/cms-uploads/20_8f0c2f3ec7.png)

- Dev联调环境：研发用户故事的跨系统联调环境，对接外部的SIT环境，直至桌面检查通过后的用户故事才可合入到R版本环境。
- R版本环境连外部环境：部落内各系统常规会有两个版本，版本环境的配置做了配置文件抽离（将代码里直联的内容做了配置化），版本环境需要连外部环境可修改配置文件或是通过ESB配置修改环境地址，以确保版本环境始终连接外部系统最稳定的测试环境。
- 外部环境连R版本环境：外部环境需连系统的稳定版本测试环境，只需要连统一的F5地址即可。内部版本环境在切换时，需修改F5地址的应射关系，以确保外部环境连接至系统的稳定版本环境。

**6. 自动化测试**

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

![](https://www.agilean.cn/cms-uploads/20_e2a46a7c89.jpeg)

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

![](https://www.agilean.cn/cms-uploads/20_958283aa36.jpeg)

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

5

**试点后，我们还要做哪些**

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

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

**需求人员能力培养**

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

产品经理需要具备持续管理需求流动的能力，利用[Adapt体系中的需求漏斗模型](http://mp.weixin.qq.com/s?__biz=MzA3NDE4MTkzNA==&mid=2247486336&idx=1&sn=f39146178df194b640fd8c87b30b986f&chksm=9f02f7c1a8757ed7d3a45ce034055ecb5469eb6fd4616a9c84bf00908357ac77adeb1a2a1c43&scene=21#wechat_redirect)，合理管理需求流动，提升产品经理需求孵化质量，避免研发需求断流，从全量承诺到价值优选，最大化利用资源，形成需求漏斗。

![](https://www.agilean.cn/cms-uploads/20_12f19c6d52.jpeg)

**小队长确责与全面赋能**

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

![](https://www.agilean.cn/cms-uploads/20_7b5f08de0a.jpeg)

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

**敏捷文化建立**

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

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

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

Agilean 方法论

## 本文相关的 Agilean 方法框架

- [规模化敏捷](https://www.agilean.cn/methodology/adapt-scaled-agile-framework/)：ADAPT 规模化敏捷框架；产品部落敏捷研发章程，面向金融等复杂组织的百人级产品部落。

推荐阅读

- [支付行业案例｜头部第三方支付组织产研数字化转型之路](https://www.agilean.cn/customer-cases/23/)
- [从“流程跑通”到“精细落地”：某农商行项管系统的升级之路](https://www.agilean.cn/customer-cases/24/)
- [地方性银行客户案例｜金融科技度量系统建设之路](https://www.agilean.cn/customer-cases/22/)
- [南方某大型基金从试点到规模化的数字化转型之路](https://www.agilean.cn/customer-cases/25/)
- [制造业客户案例｜IT 项目管理数字化转型案例](https://www.agilean.cn/customer-cases/26/)
- [农商行客户案例｜DeepSeek都输出不了的精益成熟度模型](https://www.agilean.cn/customer-cases/27/)
- [某华北地区农商行项管系统的革新之旅](https://www.agilean.cn/customer-cases/29/)
- [农商行转型新典范：业产研融合下的敏捷数字化实践](https://www.agilean.cn/customer-cases/28/)
- [从客制化到产品化：ToB软件公司的生存指南](https://www.agilean.cn/customer-cases/39/)
- [“价值与数据”双轮驱动的研发管理转型](https://www.agilean.cn/customer-cases/30/)
- [南方某大型基金研发数字化转型案例](https://www.agilean.cn/customer-cases/31/)
- [案例精粹——产品化管理的顶层设计与落地实践](https://www.agilean.cn/customer-cases/32/)
- [软件国产化大潮下，这家金融企业是怎么替换Jira的](https://www.agilean.cn/customer-cases/21/)
- [从进化角度看规模化敏捷，上海银行4500+人实施案例](https://www.agilean.cn/customer-cases/20/)
- [3000人云上协同，疫情期间效能不降反升25%](https://www.agilean.cn/customer-cases/19/)
- [研发交付时效优化30%，研发吞吐量提升35%](https://www.agilean.cn/customer-cases/17/)
- [华润银行敏捷转型案例](https://www.agilean.cn/customer-cases/33/)
- [研发支出资本化？关键在于研发管理精细化](https://www.agilean.cn/customer-cases/34/)
- [电动汽车出行品牌的数字化能力重塑](https://www.agilean.cn/customer-cases/35/)
- [上海银行|用知微支撑全行2500人研发数字化管理转型](https://www.agilean.cn/customer-cases/36/)
- [平安六年精益看板实践历程-拉动价值，持续改进](https://www.agilean.cn/customer-cases/38/)

联系我们

发送邮件

联系方式

地址

深圳市南山区粤海街道南油社区建南路15号恒大天璟A座A2902

邮箱

contact@agilean.cn

---

来源：[交付时效提升21%，宁波银行规模化敏捷试点这一年](https://www.agilean.cn/customer-cases/18/)（更新于 2023-12-13）