4.1 案例一：迈向BizDevOps的招商银行精益管理体系

• 精益管理体系演进历程

精益管理体系紧紧地围绕招行发展战略，同时参考业界先进的研发管理方法论，结合自身实践融会贯通，推动落地。回顾招行精益管理体系的演进历程，主要分为四个阶段：

第一阶段（2008年-2013年）：“一体两翼”

• 关键词：迈向规范化、CMMI、提升软件开发过程成熟度

• 举措：在组织级层面引入CMMI模型，成立EPG(Engineering Process Group) 过程改进工作组，组建QA队伍，建立全生命周期的过程管理体系和过程资产库，建立协同工作机制和度量分析平台，重点规范研发过程和提升开发质量。

第二阶段（2014年-2017年）：“轻型银行”

• 关键词：敏捷化、轻型化 、CMMI+看板+敏捷方法+DevOps

• 举措：在CMMI基础上，引入敏捷开发模式、看板、持续集成、持续交付等多种XP实践和DevOps实践，探索研究精益开发模式。在这一阶段，核心的关键是如何让IT自身能力和研发效能获得较大提升，练好IT内功。

第三阶段（2018年-2020年）：“Fintech战略”

• 关键词：价值驱动的精益转型、 CMMI+价值驱动的精益管理+精益之星平台

• 举措：引入精益思想，建立业务、IT“以客户价值为核心”的统一价值观和价值流，构建端到端一站式协同工作平台，形成价值驱动的端到端的精益管理体系，助力招行Fintech战略落地与数字化转型。这一阶段，除持续提升IT研发效能外，更重要的，根据招行数字产品能力模型，全面提升数字产品治理能力，围绕“高质高效交付业务价值”，IT左移往前站，与业务深度融合，改变来料加工式的串行模式，形成价值驱动的精益产品研发新局面。

第四阶段（2021年-至今）：“3.0模式”

• 关键词：大财富管理的业务模式、数字化的运营模式、开放融合的组织模式；迈进原生云时代

• 举措：对齐业务战略和目标，打破组织壁垒，业务、开发、测试、 运维、管理等高效协作、开放融合、责任共担，面向价值持续交付。随着招行原生云架构转型，继续深化价值驱动的精益转型，以产品思维为导向，纵向狠抓精益实践落地的有效性，横向狠抓端到端的数字产品治理能力与价值 创造，助力招行“3.0模式”落地。

• BizDevOps的落地演进

回顾1.2章关于BizDevOps的定义，简要概括一下招行整体的落地情况：

1个总体目标：业务和技术有机融合、高效运作，赋能数字业务的持续创新和长期发展。

“价值驱动的精益管理框架”终极目标是对齐业务发展战略，合理投入资源，快速交付高价值。

3个能力要求：

以客户价值为核心的协同能力

从2016年开始，逐步推行DevOps，逐步打通Dev到Test再到Ops的价值交付链；从2020年开始，逐步延伸到Biz端，初步打通从业务开始到业务结束的完整链路和反馈闭环。

全链路的数字化运作能力

从2008年开始，研发体系的落地都伴随着IT系统的支持，特别是2014年开始引入精益实践后，自动化、线上化，将体系流程固化到工具里是整个IT部门的核心共识。遵循在关键节点上的核心流程、管理工具自研，产品化较好且有一定技术门槛的工具外购+定制的原则，确保从业务价值发掘、专题特性分析、版本规划、版本交付，上线后运营反馈等全链路的数据全量、全要素和实时的记录、串联和呈现出来。

基于高可用数据的过程透明和效能度量能力

从2008年开始，度量平台是一直持续完善的系统之一，只是在初期，很多数据都靠基层组织的度量管理员手工收集，但是其实时性和准确性受到很大的约束。随着近年来落地DevOps的相关实践，研发过程沉淀了大量的管理数据和工程数据，工程数据主要依托代码仓库、流水线、发布投产等工具的沉淀；管理数据主要依托看板、流程系统在每日的研发过程中沉淀。通过持续收集、可视化相关的数据，结合着每年研发过程改进整体目标，驱动整个组织的流程和效能持续改进和提升。

5个关键实践：

实践一：产品导向的团队组织方式

2008年开始，基于CMMI建立的过程管理体系，主要以项目的方式进行交付。随着2014年开始尝试敏捷、精益、DevOps，以及Gartner提出了双模研发的概念，招行也开始在局部试点敏捷的研发模式，也算是产品导向的团队组织方式的雏形。随着试点的深入，结合银行的不同业务场景的特点，发现敏捷模式不完全适合招行的实际情况，部分需求的不连续性，也容易造成资源的锁定和板结。另一方面，随着DevOps实践的不断应用，基于系统的CI/CD工程实践，配合看板方法在基层开发组（最小的交付团队形式，类似亚马逊的2 pizza team）的推广，招行的研发体系逐步发展成产品导向的团队组织形式，只是在交付过程中，可以采用瀑布和类似SCRUM的方式。2018年，随着精益模式的逐步成型，主要包括精益项目模式和敏捷产品模式，虽然还保留着“项目”的外壳，但是在招行语境下，主要是交付周期和开发测试协作模式的一种方式，这两种模式还是会持续关注产品的长期演进以及资产沉淀和应用，管理产品实际价值的达成。

实践二：业务驱动的组织协同机制

2008年开始，基于CMMI建立的过程管理体系，主要以项目的方式进行交付。随着2014年开始尝试敏捷、精益、DevOps，以及Gartner提出了双模研发的概念，招行也开始在局部试点敏捷的研发模式，也算是产品导向的团队组织方式的雏形。随着试点的深入，结合银行的不同业务场景的特点，发现敏捷模式不完全适合招行的实际情况，部分需求的不连续性，也容易造成资源的锁定和板结。另一方面，随着DevOps实践的不断应用，基于系统的CI/CD工程实践，配合看板方法在基层开发组（最小的交付团队形式，类似亚马逊的2 pizza team）的推广，招行的研发体系逐步发展成产品导向的团队组织形式，只是在交付过程中，可以采用瀑布和类似SCRUM的方式。2018年，随着精益模式的逐步成型，主要包括精益项目模式和敏捷产品模式，虽然还保留着“项目”的外壳，但是在招行语境下，主要是交付周期和开发测试协作模式的一种方式，这两种模式还是会持续关注产品的长期演进以及资产沉淀和应用，管理产品实际价值的达成。

实践三：应用为核心的研发资产和流程管理

在推广CI/CD工程实践过程中，招行建立了“系统-子系统-发布单元-服务单元”的基础术语模型，发布单元可以简单理解为一个微服务或者一个容器镜像，服务单元在发布单元的基础上加入了运维属性和环境等属性。代码仓库、流水线和制品仓库都围绕相关概念展开。通过应用这个基础术语模型，招行整体的CI/CD飞速的推广，也为敏捷协作交付带来了助推力。随着大规模上云的完成，微服务拆分过多以及带来的管理复杂性也随之而来。2022年，通过与OAM两大发起单位的密切交流，招行也开始试点基于OAM的云原生应用管理，通过标准化工作负载，对齐数字产品和应用，实现不同角色的关注点分离，一方面降低开发者的认知负载，另一方面更好地基于应用进行业务连续性保障，最终更好地保障价值交付。

实践四：适配业务特征的持续业务交付

实践五：全量、全要素、实施数据支持的度量和持续改进

由于各个业务系统的发展阶段、技术架构、业务环境和成熟度不同，持续业务交付的形势也有所不同。实际运作过程中，招行也遇到了3.3.2章节中提到的几类问题：业务需求打包为版本交付，需要等待其他需求；应用变更需要打包在发布单元一起发布，一次发布包含多个应用变更，集成发布耗时过长。在理想模型下，每个业务版本、业务需求、发布单元、变更请求都是最小化的，但在实际适配的过程中，发现这些原则都对，具体情况下又难以操作：例如很多情况下自动化测试不足，需要由测试人员手工测试，这时候必要的整合和等待成为了平衡的结果。这个实践落地时冲突比较多、挑战比较大，需要交付团队以及更上层的领域团队一同持续优化。伴随着BizDevOps工具链的逐步成熟，各级管理者和基层组织，对端到端过程中产生的各类数据也越来越感兴趣；另一方面，人员和服务数量的指数级增长，各类角色也对数据的实时性要求提出了更高的要求。招行的度量指标，主要从交付质量、交付能力、交付速度、持续交付、需求管理、资源管理、业务满意度和业务价值等多个维度进行度量，并开始基于部分重点角色和场景提供画像和洞察分析，赋能领域专家和一线管理者发现问题，持续改进。

• BizDevOps的未来之路

2022年，招行基本上完成了系统上云工作。展望2023年，围绕定制化赋能服务的打造，以下关键工作将有条不紊地展开。