阿里专家谈敏捷开发：软件交付能力是企业核心竞争力

Posted 2021-04-25 阿里云云栖号

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

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

随着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”协作完成需求的开发。

总结

前面我们讲到了提升研发效能的方向是要持续地顺畅高质量交付有效价值。介绍了敏捷研发实践的三层框架：目标层、产品规划层、团队交付层。最重要的是精益敏捷研发的四个步骤：打通端到端价值流；快速高质量交付；度量反馈和持续改进；规模化实施。

 动动小手指 了解更多详情 ！