分享实录 | 业务驱动的精益敏捷实施-阿里云开发者社区

【以下为分享实录，有删节】

我们为什么要提升研发效能

随着5G、人工智能、IOT等新技术的迅猛发展，企业的业务都将构架在软件和互联网之上。软件交付能力成为企业的核心竞争力，随着市场竞争的加剧，企业对研发效能的期望越来越高。

然而新技术、新业态的不断涌现，又使企业的业务变得越来越复杂，各个团队之间的协作也越来越困难，企业的研发效能呈现降低趋势。“期望”与“现实”之间产生了巨大的“Gap”，正是我们要努力的方向。这就是为什么我们要提升研发效能的根本原因。

提升研发效能的方向：持续地顺畅高质量交付有效价值

为了提升研发效能，我们首先要知道是什么影响了研发效能——我们究竟面临怎样的挑战？这里有三个“不等于”：

局部效率 ≠ 高效交付
如何提升“研发效率”，很自然想到是让大家都忙起来，也就是提升运营、产品和技术人员（包括开发、测试和运维）的效率或延长工作时间。大家都忙起来，局部的效率可能是提高了，但这就意味着高效交付吗？

很多时候，运营、产品、技术各自为战，虽然都很忙碌，但是却“不出活”。这个“活”不是由我们定义的，而是由用户来定义的。用户不会因为你的繁忙买单，只会因为你的交付买单。

高效交付 ≠ 持续高效
我们如果做到了“高效交付”，就可以做到“持续高效”吗？其实也不一定。有可能是你的团队突击加班了，暂时提升了交付效率，但是无法做到持续高效。也有可能你暂时产出了软件，却留下了一系列的技术债。软件的质量很差，也没有相应的测试去维护，也没有去建立工程能力，还是不会持续高效的。

高效交付 ≠ 业务成功
即使我们做到了“高效交付”，甚至“持续高效”，那么业务就一定会成功吗？其实也不一定。你可能交付了很多需求，但这些不是用户真正要的，用户绝不会长久为此买单。你能不能吸引用户、并留住用户，产生利润，这才是业务成功的关键。真正的业务成功，是要能解决用户真正的问题，所以高效交付也不等于业务成功。

精益和敏捷的方案是需要解决上面的三个问题：

• 从局部效率到高效交付，我们需要做到：顺畅高质量交付。
• 从高效交付到持续高效，我们需要做到：持续地顺畅高质量地交付。对于代码设计和质量的长期维护和提高，持续工程能力的积累，持续交付实践的实施等。
• 从高效交付到业务成功，我们需要做到：持续地顺畅高质量交付有效价值。
至此，我们定义了问题，也分解了问题，并明确了方向：持续地顺畅高质量地交付有效价值。

精益敏捷研发实践框架

精益敏捷研发实践框架分为三层，第一层是战略和目标，主要包含用户诉求、愿景目标和战略规划。第二层是产品规划层，这里需要业务、产品、技术之间的敏捷协作，将战略和目标层的业务诉求形成业务诉求条目后录入业务需求池，然后通过业务设计、产品设计、产品交付等环节，交付有效价值，并根据业务验证结果，建立业务反馈进行调整，最终达成业务结果。第三层是团队交付层，在这一层需要产品和技术团队高效协作，持续澄清，开发和验证需求，并通过自动化交付流水线和持续交付机制实现快速交付需求。

如何实现精益敏捷研发呢？我们需要做到以下四步：
第一步，我们需要打通端到端的业务价值流。什么叫“端到端”呢？就是要关注从用户的需求到用户问题的解决这一全过程，而不是中间的某一个阶段。这就需要我们的业务、产品、技术进行协作。
第二步，快速高质量交付，即更快更好地交付需求。
第三步，度量反馈和持续改进。我们期望产品交付过程是可被度量的，同时可驱动交付团队持续改进。
第四步，规模化实施。有了以上三步，其实还不够，我们需要赋能整个企业或组织，进行规模化实施。
后面，我会详细介绍这四步如何实施。

精益敏捷研发第一步：打通端到端的业务价值流

可见，是协作的基础。我们可以通过云效的“看板”实现端到端需求流动过程的可视化，如上图所示在“看板”的最左端是需求池，最右端是“已发布”，其中包含了业务、产品、开发、测试和运维在内的端到端交付过程。打通端到端的业务价值流必须做到：用户价值驱动，即每一个流动单元体现的都是具有用户价值的业务需求；前后职能拉通，即拉通业务、产品、开发、测试等各个职能一起来看整个链路，始于用户问题的提出，终于用户问题的解决。

建立端到端的需求流动过程，并利用云效看板实现可视化，这是提升效能的基础。下一步需要明确各阶段的准入准出标准。

明确各阶段的准入准出标准，即明确流转规则，是内建质量的重要手段。团队要达成对规则的一致理解并共同守护和持续改进。

如上图所示，从阶段“业务讨论”开始到“已发布”都需要有明确的准入规则。举两个具体的例子，一个是从“产品”流入“开发”的规则：

开发、测试和产品达成一致，定义明确的验收标准；
大需求，需拆分为工作量在两周以内的故事；
与关联方（如有）确认相关计划；
-识别大的技术风险并定义应对方案；
涉及三位及以上开发人员的需求，指定需求负责人，负责协调进度。

第二个例子是从“开发”到“测试”的流转规则：

通过持续集成环境的检验，部署在测试环境；
开发对照验收标准进行了自测；
通过Show Case。

从“业务讨论”到“已发布”每个环节都需要有一个明确的准入准出规则，这里不再赘述，大家可以根据实际情况去定义自己的规则，这些规则不是一成不变的而是需要持续更新、持续迭代。

明确准入准出标准，是为了保证有质量的流转。为了更好的达成业务效果，接下来需要建立业务价值反馈闭环。

针对已上线的需求，经过一定的时间后（钉钉是需求上线后的7天，查看业务效果，即T+7读数会，不同业务可以根据自己的情况设定时长），根据产品规划时明确的业务目标和要解决的用户问题，去验证业务目标是否已达成，用户问题是否已被解决，然后做相应的优化和调整。

什么样的需求才能流转到开发中呢？我们需要为交付团队提供高质量的需求。在产品规划层：需要聚焦端到端的流动效率，并形成价值反馈闭环。而在团队交付层：需要聚焦快速交付业务需求，并保证交付质量。当需求从“产品规划层”流转到“等待开发”这个阶段的时候，需要“指派”给开发团队。需求进入开发团队后，开发同学会把它拆分为“任务”，比如说按照“前后端”会拆分为“前端任务”“后端任务”，针对无线端的任务会拆分为“iOS任务”“安卓任务”等。只有当所有“任务”开发完成后，满足“提交测试”要求了，才能“提测”。

精益敏捷研发第二步：快速高质量交付

下面我们接着讲精益敏捷研发第二步，如何快速高质量交付。在软件研发过程中，大多数的时间浪费不是协作上的等待，而是做了很多无价值的需求，以及需求不停地返工。因此发生在软件开发之前的需求澄清工作至关重要。

如何做好需求澄清呢？首先，实例化需求。我们的经验是业务、产品、开发和测试一起坐在一起，从场景出发，以用户的操作实例来澄清需求。实例是具体的，其典型形式是：“在什么情况下，做什么操作，会得到什么结果”。基于具体的实例，更加便于沟通中的双向确认，保证理解的一致和场景覆盖。

在需求澄清时需要注意：以终为始，确保需求输入质量。如上图左侧的“三角”所示，首先要讲解业务目标，也就是要解决用户或业务什么问题。其次操作及操作流程，为了实现上面目标，系统需要支持哪些用户操作？这些操作的流程是什么样的？再次是业务规则，各个操作步骤对应的业务规则是什么样的？业务规则会转化成验收标准。

完成需求澄清之后，我们进入第二步，验收测试驱动开发，确保高质量的准入准出。如上图所示：

需求进入开发团队的队列（等待开发）后，业务、开发和测试立即通过实例化需求活动澄清需求，用结构化的方式生成需求的验收标准。
在开发实现这些需求的同时，团队会将这些需求实例会转化成测试用例，并把部分测试用例自动化，做到功能实现和自动化测试开发同步完成。
需求实现完成后，团队会有加工好的测试用例来验收这些需求。甚至可以将部分测试用例提前给到开发人员，让开发提前进行自测。

以上形成的循环被称为验收测试驱动开发,这个研发实践在阿里巴巴集团内部和外部都得到大量应用，它重构了开发过程，可有效提升团队的交付质量和效能。

当业务需求由产品规划层进入到团队交付层之后，会有两种研发模式来完成需求的开发，持续交付模式和迭代交付模式。我们先来分享一个持续交付模式的实践：限制在制品数量，提高交付速度。

如上图在云效的“看板”上，我们可以看到这里的一个“卡片”代表一个业务需求，在“开发中”后面有一个数字（上图中是3），这代表着并行开发的需求数量。限制并行需求的数量，目的是尽快完成已开始需求，加速需求的流动。更重要的是，“限制并行”能更快暴露问题。因为并行开发的需求有限，当某个需求发生阻塞时，很容易被发现。

并行的需求又被称为“在制品”。在云效看板上，所有已经开始，但还没有完成的需求（或其他工作）都是在制品。限制在制品数量的基本原则是：“聚焦完成，暂缓开始”。一般而言，在制品数量越少，交付速度越快。源自“精益思想”的“利特尔法则”解释了背后的原理，感兴趣的同学可以自己去搜索了解，这里不再赘述。

云效也支持迭代交付模式，并提供迭代管理、迭代需求管理、迭代活动管理、测试用例管理、缺陷管理、度量统计等功能，大家可以去云效官网试用体验。关于迭代交付模式(Scrum)业界有很多介绍，我们这里不详细讨论。

精益敏捷研发第三步：度量反馈和持续改进

怎样知道研发团队真的做到了高效交付呢？我们需要对研发效能进行度量，并建立反馈闭环，持续改进。

我们一般用“缺陷趋势图”来度量“交付质量”。如上图所示，图形的横坐标是日期，横坐标上方红色竖条代表这一天发现缺陷数量；横坐标下方绿色竖条代表当天解决的缺陷数量；橙色曲线代表缺陷存量。图中左右两个部分比较了两种交付模式。

左半部分，团队属于小瀑布的开发模式。“迭代”前期，团队集中设计、编码，引入缺陷，但并未即时地集成和验证。缺陷一直掩藏在系统中，直到项目后期，团队才开始集成和测试，缺陷集中爆发。

小瀑布模式下，交付质量差，带来大量的返工、延期和交付质量问题。该模式下，产品的交付时间依赖于何时缺陷能被充分移除，当然不能做到持续交付，也无法快速响应外部的需求和变化。并且这一模式通常都导致后期的赶工，埋下交付质量隐患。

右半部分，团队开始向持续交付模式演进。在整个迭代过程中，团队以小粒度的需求为单位开发，持续地集成和测试它们，即时发现和解决问题。缺陷库存得到控制，系统始终处于接近可发布状态。这一模式更接近持续发布状态，团队对外的响应能力随之增强。

缺陷趋势图从一个侧面反映了团队的开发和交付模式。它引导团队持续且尽早发现缺陷并及时移除它们。控制缺陷库存，让系统始终处于接近可发布状态，保障了持续交付能力和对外响应能力。

云效其实已经有了这种“缺陷趋势图”，而且是自动产生的，不需要手动绘制。

我们使用“周期时间控制图”来度量“交付效率”。如上图所示，横轴代表日期，竖轴是天数，一个一个蓝色的点代表已经发布的需求。期望这些蓝色的散点进行如下分布：

1）纵向上向下集中——需求交付周期和开发周期越短，业务响应能力及其可预测性越高；
2）散点密度提高——散点密度越高代表发布频率越高，发布的能力就越强；
3）横向上更均匀分布——横向上的需求分布是均匀的，代表是持续交付的。

在度量一个研发团队的交付效率时，我们会看这些散点分布的趋势是否是往下走的，如果是往下走的，说明交付效率在变好。此外，还会看“控制线”，在上图中，我们看到这个研发团队的周期控制线是13天，这表示85%的需求周期时间都要小于13天，这也代表了该研发团队的交付效率。

在云效上也提供了“需求开发周期控制图”，同时提供了“需求开发周期报表”，这个报表不但包含了“吞吐量”，还包含这个需求是多长时间内交付的等信息。

在阿里巴巴集团内部，也有一套可行动的效能度量体系，包含需求响应周期、持续发布能力、交付吞吐率、交付过程质量、交付质量等五组指标。

这五组度量指标内容又被归纳为三个维度，即流动效率、资源效率和质量保障。其中，持续发布能力和需求响应周期这两组指标反映价值的流动效率；交付吞吐率反映资源效率；交付过程质量和对外交付质量这两组指标共同反映质量水平。用六个字来概括这三个维度就是：又快、又多、又好。

有了度量标准之后，我们还要建立效能反馈和改进闭环，才能更好地提升研发效能。

通过日常反馈，质量和交付效能的反馈，并定期进行复盘分析，形成流程操作、基础设施、代码与设计、交付及测试守护和人员技能等五个方面的改进行动，然后持续反馈、分析和改进。

在实际的操作中，我们发现经过复盘会议后，会产生一些“改进的行动项”，但是这些“Action”的跟进却很困难，往往跟着跟着就跟丢了。在云效当中有一个比较实用的功能，可以将改进的行动项转换成督办任务进行跟进，让行动项妥妥落实，持续促进组织效能提升。

精益敏捷研发第四步：规模化实施

在讲“规模化实施”之前，我们先来学习一句话。斯蒂芬·丹宁（Stephen Denning）曾说“我们需要的是敏捷的规模化，而不是规模化敏捷（方法）”。什么意思呢？我们希望持续地顺畅高质量交付有效价值的能力被规模化，而不是简单地规模化这种方法。

如果一个研发团队做到了前面三步，即“打通端到端的业务价值流”“快速高质量交付”“度量反馈和持续改进”，我们认为该团队具备了持续地顺畅高质量交付有效价值的能力，但是这还不够，我们需要将这种能力规模化，并赋能整个企业。

前面主要讲述的是“单产品单交付团队”的敏捷研发模式，下面我们来看一下如何将这种能力拓展至“单产品多交付团队”及“多产品多交付团队” 。

如上图所示，是一个“单产品线多交付团队”的案例。在产品规划层，具有一个产品线看板，管理业务需求的端到端价值流，并将准备好的需求分配给负责任的开发团队（指派给交付团队1或交付团队2）。在交付团队层，有两个独立的交付团队，他们的操作其实跟单产品线单交付团队时并没有不同。只需要接受业务需求，分解开发任务，管理需求的开发和交付过程，快速交付。

在企业中也常常会出现“多条产品线多交付团队”的情况，比如下图所示是一家物流企业的实际案例。

他们有三层看板。第一层是公司级业务运营看板，关注公司战略的落地，如各业务线的投资组合，各业务单元的目标和关键结果，跨业务线的协作和组合创新等。第二层是产品线看板，主要关注产品需求价值流，如端到端需求流动过程，目标反馈闭环等。第三层是交付团队层，主要关注团队快速交付需求，如高质量快速交付，效能反馈闭环等。

我们可以看到每条产品线都对应多个不同的交付团队，如果各个产品线之间没有任何“交叉”就比较简单了，操作方式类似前面提到的“单产品线多交付团队”模式。但是也可能出现“跨业务线协作”，这就需要在产品规划层进行拉通。比如在这个例子中“生活业务线产品” 的某个功能可能要依赖“中台业务线产品”的某个功能，生活业务线的产品经理就需要将开发需求“指派”到“交付团队14”，让“交付团队11”和“交付团队14”协作完成需求的开发。

总结