2020阿里巴巴研发效能峰会——《ALPD - 驱动业务创新的精益产品研发》

摘要：ALPD是Advanced Lean Product Development（下一代精益产品开发）的简称，它的目标是成为支撑云时代产品开发和业务创新的实践体系。本次分享，阿里云云研发部资深技术专家何勉将为大家剖析研发效能面临的挑战，并详细介绍ALPD及应用实例，展现其是如何支撑业务发展并引领业务创新的。

演讲嘉宾简介：阿里云云研发部资深技术专家——何勉

以下内容根据演讲视频以及PPT整理而成。 观看回放 http://developer.aliyun.com/topic/2020 本次分享主要围绕以下四个方面：

            一、研发效能的挑战
            二、ALPD：阿里的精益产品开发方法体系
            三、适配场景的ALPD效能解决方案
            四、总结：提升研发效能，赋能业务创新

一、研发效能的挑战

1.阿里巴巴技术发展

下图为阿里技术20年砥砺攀峰背景墙，回顾了阿里巴巴技术发展的三个阶段，特别是技术与业务的关系。

1999年~2008年：技术支撑商业发展；
2009年~2016年：技术拓展商业边界；
2016年~，技术创造新商业。

2.技术如何创造新商业

技术与商业越来越不可分割，成为驱动业务创新的内核。下图展示了阿里的技术与业务的关系。

首先，最底层（或内核）的是云基础设施以及基于云基础设施的云原生开发和运行环境。

在云原生内核之上是中台，例如：阿里在中台2.0战略中所提倡的业务中台、数据中台和AI中台。以中台为基础，可以组合并拓展新的业务形态，快速满足业务需求，和创造新的业务形态。

技术要支撑业务发展，更要引领业务的创新。这对研发效能提出了前所未有的要求，要求技术、工程和协作方法和实践的全面升级。系统整合这些实践方法，形成可落地的解决方案，提升研发效能，从而持续降低创新的成本，提高创新的效率。这是我们探索和实践ALPD（下一代精益产品开发方法）的初衷。

3.研发效能面临的挑战

研发效能究竟面临怎样的挑战呢? 下图中，我们用3个 “≠” 来描述这一挑战。

第一：局部效率不等于高效交付。局部的效率是基础，但真正的效率，必须从用户视角来衡量——快速解决用户问题、快速上线用户的需求。为了做到这一点，只有局部效率是不够的，只有系统的协同和改进，才能高效交付用户（或业务）的需求。

第二：高效交付不等于持续高效。技术、工程等多重因素影响着效率的可持续性。做的不好，随着时间的推进，组织会积累技术和工程的债务，不但陷入维护的泥沼，软件的扩展也会越来越困难。不可持续的高效交付最终还会是竹篮打水。

第三：高效交付不等于业务成功。我们的目标是业务成功，但要想成功，必须保证交付的是用户和市场所需要的，并构建起合理的商业模式。在不确定性陡增的今天，这是一个不断探索和试错的过程，需要系统的创新方法。

研发效能的提升和保障，就是要解决好并避免这三个“不等于”。

“不等于”是从负面来描述研发效能的问题。对应的，从正面角度，我们把研发效能提升的目标定义为：“持续地、顺畅高质量地交付有效价值”。

如下图所示，下一代精益产品开发（ALPD）正是面向这一目标构建的方法和实践体系。

二、ALPD 方法学：下一代精益产品开发方法

阿里巴巴在实践中构建的产品开发和创新的方法，我们称之为ALPD（下一代精益产品开发）方法学。图中的屋顶——“持续地、顺畅高质量地交付有效价值”——是我们前文所述的研发效能的目标。其底层以及两侧灰色部分是基础设施和组织保障。

图中蓝色的部分，是关于精益交付的实践。具体包括：全链路数字化的精益协作、领域为核心的技术实践，以及云原生的工程实践。其中，精益协作实践保障顺畅和高质量的交付，技术及工程实践则主要保障可持续性。

橙色部分是用户目标驱动的创新实践。分为业务探索和创新实践，以及更上层的动态投资组合管理两个部分。它们共同保障交付有效的价值。

下面我们将介绍其中的核心实践。

1. 全链路精益协作

全链路精益协作由三个实践构成。分别是：拉通端到端的价值流；左右对齐和快速交付；保障过程和源头质量。

全链路精益协作实践一：拉通端到端价值流

组织内部往往看到这样的矛盾。一方面，各个部门或角色看上去都很忙碌；另一方面，用户的感受却是另一回事。这在产品开发组织中尤其常见 —— 产品、开发、测试等部门和人员都非常忙碌；而从用户提出诉求到需求上线的时间却很长，对外的响应很慢。

为什么会这样呢？如下图所示，绿色短线代表需求正在被处理，红色长线代表需求处于等待状态。我们经常看到，务求大部分时间处于等待状态。这就造成了，从组织和用户角度的不同感受。从组织视角来看，资源效率高——每个人或部门都很繁忙；而从用户视角来看，流动效率低——需求得不到快速响应。

等待处理时间长的原因很多，可能是：工作在不同角色间的传递和依赖；批量处理需求时大部分需求处于等待状态；问题和阻碍不能被及时处理；等待测试和批量发布等。这一模式下，工作量几天的需求，从提出诉求到上线的过程往往会超过一个月了，甚至达到数月。

除了各个环节之间的等待，中台化本身也对协作提出了新的挑战。中台化为产品研发提供了新的生产力可能，通过中台能力的沉淀和复用快速组合和满足新的业务需求。然而，生产力需要与之适配的生产关系。

中台化下，如果前、中、后台的协作关系处理不好，反而可能产生效能竖井，出现更多的依赖和等待，延缓而非加速需求的交付。这一情况绝非少见。

为了提高对外的快速响应能力，企业必须改变视角——从内部职能视觉的局部优化，转变为用户视角的系统优化。

从内部职能视角，我们看到的是相互割裂的局部，而局部优化往往会损害而不是提高整体效率；只有从用户视角出发，关注从用户提出问题，直到交付需求解决问题的全链路过程，优化整个链路，才能系统改进，提升用户可感知的研发效能。

以某个业务板块的协作改进为例，我们首先做的就是梳理并打通业务价值流，为此我们要做到两点：

第一，业务价值驱动。在相对复杂的业务中（如：产业互联网、供应链等），业务需求可能需要多个产品和系统的协作才能完成。正因为如此，在看板上流动的必须是业务价值——业务需求。只有业务需求才是不同职能有效协作的共同源头，是用户价值的基础，是协同各个职能和拉通端到端价值流的不二之选。

第二，前后职能拉通，关注并优化端到端的业务价值流。

以业务价值驱动为基础，接下来要做的是拉通前后职能。上图反映了业务价值交付过程——端到端的价值流。业务价值流串起了不同职能的工作。

可视化并管理业务价值流，让不同的职能更好的协作，优化端到端的价值流动，确保用户价值的顺畅交付。

下图中的小工具，展示了每个业务需求的交付时间线，它们在每一个阶段所停留的时间、阶段间的等待、目前所处阶段、是否发生停滞等。它帮助我们跟踪和优化业务需求的交付过程，即时发现问题，并处理过程中的停滞、等待等问题。

简而言之，团队必须关注并改善业务需求的价值流，围绕用户与业务展开协作，加速业务响应。

全链路精益协作实践二：左右对齐快速交付

为了快速交付业务价值，组织内部必须协调一致，做到左右对齐和快速交付，这里的左右对齐指的是开发任务或子产品需求向业务需求对齐。

在这个案例中，业务需求的交付，往往需要多个产品的协作。比如，一个业需求会被拆分到不同的产品。这样就形成了下图所示的分层价值流，它包含上层的业务需求价值流和下一层的产品需求价值流两个层次。

企业最终关注的是业务价值流动效率，这就要求价值流的下层向上层对齐。下图所示为价值对齐图，也是我们专门设计的工具。图中最左侧是业务需求，选中业务需求后，右侧是该业务需求拆分到各个产品的产品需求，以及这些需求的交付承诺和状态。

组织的目标不是追求局部效率，而是提升整体业务响应效率。决定业务响应效率的是瓶颈环节与产品。因此，我们要基于业务需求来对齐前、中、后台产品——对齐承诺，并即时跟踪产品需求状态，即时暴露并解决系统问题和瓶颈，加速需求的交付。

**全链路精益协作实践三：保障源头和过程质量
**
前后拉通、左右对齐，让整个组织围绕价值的交付更好地协作。为了让价值更顺畅的流动，我们必须要保障源头和过程的质量，减少因质量问题而带来的返工和等待。下面，简单分享一下保障源头质量的实践——实例化需求。

如果源头是垃圾，结果也会是垃圾，所谓“Garbage in，Garbage out”。与之对应，我们要做到“以终为始”——在开始开发前，明确定义和沟通最终结果应该如何，让各参与方对业务需求达成一致理解。

实例化需求是达成这一目的具体实践，它让开发、测试、产品、业务等角色可以共同参与，高效沟通和澄清需求，并以结构化的方式确保沟通过程的效率和效果，产出需求的验收标准。

源头质量得到保证，还让优化整个开发过程可能。上图表示了以实例化需求为基础，如何重构开发和验收模式。

1）在需求开发前各个角色共同澄清需求，包括：需求的目标；为实现目标而要支持的操作和操作流程；与操作流程对应的业务规则。这些流程和规则作为实例，不仅帮助不同角色共同澄清需求，建立对需求的共同理解，而且还成为将来需求的验收标准；

2）与开发过程并行，基于验收实例产出测试用例。条件和能力具备的团队还会将这些测试用例自动化；

3）开发完成后，第一时间用验收实例来验收需求，提供即时反馈。如此保证需求的过程和交付质量，做到真正的“以终为始”。

总结全链路精益协作的实践。我们分别通过三个实践，有机配合实现了顺畅和高质量地交付。它可以表示为：

顺畅高质量地交付 = 拉通端到端的价值流 + 左右对齐和快速交付 + 保障源头和过程质量

2. 云原生的工程实践

接下来，简要介绍一下云原生工程实践。实现业务的持续高效交付离不开工程实践的保障。它包含以下三个方面：

不可变基础设施：实现不可变的基础设施。它至少要做到：1）配置和镜像分离，做到一次构建在不同环境上（如开发、测试、预发、生产）的部署和运行；2）通过IaC（Infrastructure as Code）技术做到配置代码化，保障运行环境的数据和配置的一致性、可用性和稳定高效。云原生的技术（如：容器技术、服务网格、基于K8S的调度运维等）为不可变基础设施提供了有力的支持，而不可变基础设施也是高质量和高效持续交付流水线和质量保障体系的基石。

持续交付流水线：基于不可变基础设施，构建持续交付流水线。将代码提交后的所有流程（如代码扫描、系统集成、各类环境下的验证和部署等）标准化和自动化，并以此为基础，实现流程卡点、即时反馈和系统度量。如此，持续交付流水线建立了交付效率和质量的保障框架。

可信发布（质量守护体系）：在持续交付流水线的基础上，建立和不断完善质量守护体系。质量守护体系必须集成至持续交付流水线当中，确保质量保障手段在正确的时刻起到守护作用，并应用流水线的反馈不断完善它，包括：基本模块和接口质量的守护，基本的功能回归、合规性检查、性能、流量测试、安全检查等等。如此才能做到高效、高质量和可信的发布。

不可变基础设施建立了基础，持续交付流水线提供了基本机制保障，而质量守护则保障了可信和高质量的发布。云原生技术为它们提供了更优雅和有效的解决方案，它们共同构成了云原生的工程实践，保障交付的质量、效率的可持续性。

3. 领域为核心的技术实践

工程实践以外，产品开发的效率和质量提升，还是要落地到技术实践，包括：分析、架构和实现等。在现实中最挑战的是如何有机融合和落地这些实践。
我们以领域模型为核心连通相关的技术实践，形成了下图中的“领域为核心的技术实践体系”。

1） 业务引领的领域建模：结构化分析业务需求，澄清业务目标，分析业务场景以及业务流程，业务流程步骤对应的业务规则，基于业务规则定义验收标准。在分析需求的同时，深刻洞察领域的本质，产出或演化领域模型。

2） 领域驱动的微服务架构：以领域模型指导架构的设计和分解，应用DDD（领域驱动设计）的战略和战术模式，分解子域，明确子域之间的边界（限界上下文）和设计契约，并落地为微服务架构，沉淀可复用资产。

3） 契约导向的软件实现：领域驱动设计明确了各个子域的边界、接口和设计契约，它们将成为系统实现的依据和约束；再结合分析过程中产生的领域模型和验收实例，指导高效编码与设计，产出有效的自动测试，守护系统的边界、接口和功能；测试守护将支持系统随业务发展的重构和演进，持续地支持业务的发展和创新。

以上三个实践，以领域模型为核心，有机整合分析、设计和实现过程，既高效的分析和实现业务需求，也保障了设计和代码的长期质量。它更好的支持中台战略落地，实现中台战略的初衷——以更优质的领域资产，更高效地支持业务发展和创新。

从中台的角度讲，如果中台是新的生产力，业务驱动的全链路精益协作就是与之匹配的新生产关系；领域为核心的技术实践则是新生产工具；云原生的工程实践则是基础设施。没有生产关系、工具和基础设施的支持生产力就无从兑现。

三、适配场景的ALPD解决方案

以上介绍了ALPD方法学（ALPD-Method），它提供了系统的赋能实践，描述了理想的产品开发和交付模式。
只描绘理想模式是不够的。同样重要的是如何实施落地，特别是如何适配不同业务特征和场景给出落地的方案。这是ALPD 解决方案（ALPD-Solution）的目标。
为了适配不同的场景，我们首先总结了从战略及业务到代码及变更的全链路数字化体系。它应该满足两个要求：1）打通从战略、业务到代码的全链路过程；2）能够定制化并覆盖阿里巴巴经济体以及业界的主要场景和业务。

基于这样一套基础方案，就可以去裁剪和定制，以满足不同的场景。如下图所示，该体系分为三层：

顶层为规划层，包含两个模块：1）业务和目标管理。它从组织战略和业务发展出发，组织和管理团队的目标，目标之间可以关联和引用，目标最终要与项目或需求关联；2）战役（和项目组合）管理。战役是有阿里特色的管理方式，它聚焦于组织的战略，分解和跟踪战役的目标，设定战役的组织阵型和项目组合，并跟踪和管理战役及关联项目的实施过程。
中间为实施层，包含两个模块：1）产品管理，它承接战略和业务发展的目标，管理产品需求的规划和交付过程，并确保产品的演进和产品资产的有效沉淀；2）项目管理，它关注项目从启动到收尾的生命周期，确保项目的交付进度、范围、质量和成本。
最下层为交付层，包含两个模块：1）交付团队管理，它负责管理团队的交付过程，如迭代计划，协作和进度跟踪等；2）持续交付，它是管理团队的代码提交、集成、验证直至系统和需求的持续发布。
这三个层次，六个模块相互关联，构成了全量的方案。具体的业务和组织，可以基于这一全量的方案定制形成自己的全链路数字化解决方案。
数字化模型是解决方案设计的基线，更重要的是在具体的上下文中，分析效能问题；设计改进方案；落地实施；以及设定牵引性的改进目标和度量体系。今天限于时间就不再展开了。

四、总结

“技术创造新商业”，技术在业务中的地位越来越核心，研发效能直接关乎业务发展与创新。提升和保障研发效能，是每一个产品技术团队的挑战。ALPD（下一代精益产品开发）应这一挑战而生。

ALPD源自我们在阿里巴巴经济体以及业界的长期和深入实践，目标是：相对传统的产品开发方法：10倍响应速度；10倍过程质量和10倍有效价值。

10倍效能提升绝不容易，不可能通过单一实践实现。它需要系统的方法实践——对应ALPD方法学；更需要可高效落地的解决方案——对应ALPD解决方案。

“技术创造新商业”，十倍效能提升是我们的长期愿景。期待将来为大家深入解读各个实践，不同场景下的具体解决方案和实施案例。