精益 + 敏捷，两大管理思路让研发效能「飞」起来｜直播回顾

8 月 10 日，ONES 研发管理大师课第二期课程正式开课啦。本期邀请的大咖讲师是 ONES 研发效能改进咨询顾问董晓红老师，分享主题为《精益敏捷组合管理提升研发效能》。通过精益和敏捷管理思路，探讨如何让有价值的需求顺畅、高质量地流动起来，从而提升企业研发效能。

以下是晓红老师分享的核心内容。

研发效能提升的必要性

我先从四个视角解读一下研发效能提升的必要性。

站在组织的视角上，组织发展规模化以及技术驱动商业差异化，已经难以应对市场的快速变化；站在组织内部的视角上，竞争日趋激烈，「谷仓效应」越发突出，局部优化但是无法全局优化，破局「大船难掉头」的尴尬势在必行；站在行业技术视角上，软件研发的各个环节已经全面数字化。为研发效能的数据收集和度量做好了准备；最后，站在外部资源视角上，在经济存量的大背景下，再加上今年新冠疫情的影响，业务发展不能仅靠烧钱、人海战术。随着产品利润的下降，企业需要降本增效，提升效能。这是我理解的提升研发效能的四个必要性。

精益的起源

讲到精益，它的生产系统有三个阶段。

第一个阶段是弗雷德里克·温斯洛·泰勒提出的科学管理方式阶段，就是有流程制度的标准作业，大幅提升了作业的效率；第二阶段是大规模生产方式，代表人物是亨利·福特，他创造了大众阶层也能买得起的 T 型汽车，在泰勒的科学管理方式的基础上，提出了更加规范化、标准化的大规模生产方式，让汽车走进千家万户；第三阶段是丰田生产方式，代表人物是大野耐一。据说，当时大野耐一去美国福特的流水线参观时，发现很多浪费现象，他觉得与日本的节约理念很不匹配，他想出来一种精益生产方式——小规模、小批量「拉动式」的生产系统。

此外，精益是怎么在 IT 软件应用中演进的呢？1996 年，詹姆斯·沃麦克和丹尼尔·琼斯发布了《精益思想》，精益生产方式由经验变成理论，使精益在其他领域进一步扩展；2003 年，Mary 和 Tom 在《敏捷软件开发工具——精益开发方法》把精益原则映射到软件开发中；2004 年，大卫·安德森在微软公司可持续工程团队进行精益化管理变革，通过 5 个季度把微软绩效排名最差的团队变为绩效最好团队；2010 年，大卫·安德森发布《看板方法：科技企业渐进变革成功之道》，看板方法脱胎于丰田生产方式和高德拉特的约束理论(TOC)，是精益方法的进一步延伸；2014 年，在国内，华为最先开始推行精益看板方法，招商银行紧随其后。

接下来，我们看看精益管理的五大原则，也是精益实施的五个步骤。

第一步，定义价值，我们要站在用户的视角去定义价值。举个例子，软件开发中我们提一个需求，要站在用户的角度去思考是不是他们想要的，而不是我们自己臆想出来的，这就是定义价值。

第二步，识别价值流。我们以终为始，定义端到端过程中的一切活动。以软件开发为例，从需求的提出到评审、研发、上线整个过程就叫端到端的活动，这样才能有全局的视野。有了全局视野，我们才能看到整个过程中有没有多余的步骤、有没有阻塞、有没有瓶颈等。

第三步，增加流动。有价值流了，我们要让它像河流一样通畅流动起来。这一步有个比较重要的点，就是要从聚焦资源到聚焦价值流动。意思就是，团队要从一开始关注「人忙不忙」，逐步转变到关心「价值是不是在流动」，因为人在忙不一定能带来价值。这一点是很关键一点的，是要从思维上改变的。

第四步，需求拉动。降低库存，我们有订单后再生产，用下游拉动上游。

第五步，「完美」，也就是不满足现状，持续地去改进。在软件行业，「完美」最重要的是「质量内建」，意思就是不要把有问题的环节传到下一个环节。

这就是精益生产的五大原则，它最高的目标还是要降低成本、改善质量，缩短周期。

看板方法的核心内容与实践

「丰田生产系统-看板信号卡拉动」示意图

很多人其实对看板是有一种误解的，只把它看成「可视化的板子」。所以，理解什么是「生产制造中的看板」十分重要，它可以帮助我们理解本质，消除误解。看板一词来自于日文，本义是信号卡片，用于精益流程和及时的库存补充计划，帮助公司提高产量并减少总体库存。

这节课，我们主要讲解精益看板方法。大卫·安德森最早在软件开发中借鉴和应用看板实践，并总结为完整的「看板方法体系」，包含以下三个核心内容：

第一，将流程可视化。把工作拆分成小块，一张卡片写一件任务，再把卡片放到墙上。这可以理解为，我们要做一个软件，把需求写到一张卡片上，然后再把这个卡片放到看板墙上；看板墙划分为多列，每一列都有状态，显示每件任务在流程中处于什么位置。

第二，根据能力限制在制品。明确限制流程中每个状态上最多同时进行的任务数。每个团队的能力、基础设施是不一样的，需要团队根据自己的情况去探索。它有两个目的，一方面，通过减少并行任务数量，加快价值流动，从而缩短周期时间；另一方面，它有暴露问题的张力，有助于暴露瓶颈和问题，激发团队协作解决问题。

第三，度量生产周期。这有助于对流程进行调优，尽可能缩短生产周期，并使其可预测。这个步骤可以帮助团队判断过程中有没有不必要的步骤、有没有浪费、有没有可能缩短生产周期等等。

明确好核心内容以后，我们来看看精益看板的五大实践。

第一个实践，可视化工作流程。它有三个要点：可视的是用户价值、可视的是用户价值端到端的流动过程、问题和瓶颈也要可视化显示出来。

第二个实践，控制在制品数量。每个环节内在制品数量小于设定的数量时，才可以从上一环节拉动，否则不允许拉入新工作。我们要聚焦已开始的工作，聚焦有问题的地方。

第三个实践，显示化定义规则。这里指的是看板中从一列移入另一列的规则。另外，其他规则也要定义出来，比如：需求优先级、紧急需求等定义也要显示化出来，以便团队达成共识，按照规则来执行。

第四个实践，管理工作项流动。这里有两个要点，一是就绪队列的填充，就绪队列是看板价值流的源头，只有管理好源头，才能重视价值的顺畅流动和质量。二是每日站会，站会也是管理价值流动过程的活动，重点会关注价值流动过程的问题和阻塞。

第五个实践，建立反馈，持续改进。它需要关注流动是否顺畅的反馈以及关注质量的反馈。

敏捷的起源与基本框架

说完精益的起源，我们再来说说敏捷的起源。2001 年，17 位软件开发者带着他们轻量级框架「Scrum、XP、FDD、DSDM」，齐聚在美国的犹他州的雪鸟滑雪场。他们把框架里面的共性特征抽象出来，梳理形成了敏捷的十二原则，并写下了敏捷软件开发宣言。

同时，Scrum 的历史可以追溯到 1986 年。《哈佛商业评论》的一篇文章《新型产品开发策略》描述了一种快速灵活的开发策略，以满足快速变更的产品需求。该文章第一次将 Scrum 与产品开发进行了关联。

我们再详细讲解一下 Scrum，它的目标是通过一种自组织跨职能的迭代小团队去交付价值。支撑这个目标是敏捷的三大支柱——透明、检视、适应。Scrum 框架还有很重要的「3355」原则——3 个角色、3 个工件、5 个价值观、5 个事件：

• 3 个角色：产品负责人、团队成员、敏捷教练

• 3 个工件：产品待办列表、迭代待办列表、产品增量

• 5 个价值观：承诺、勇气、专注、开放、尊重

• 5 个事件：迭代、迭代计划会、每日站会、迭代演示会、迭代回顾会

Scrum 与 Kanban 的相似与不同

接下来，我们看看 Scrum 与 Kanban 的对比。这个对比不是评价孰优孰劣，而是以此来加深对两种方法的认识，并在实践中相互借鉴。它们的相似性有这几部分：

• 都是既精益又敏捷

• 都限制了 WIP

• 都以透明的方式驱动过程改进

• 都关注于尽早交付，频繁交付可发布的软件

• 根基都是自组织团队

同时，Scrum 与 Kanban 有 6 项差异点，我们从变更导入、节奏、控制在制品、事件、角色、默认度量这 6 个维度进行了对比，详情请看下面这张对比图：

ONES 精益敏捷组合管理思路

最后，和大家分享一个 ONES 给客户做的精益敏捷组合管理的思路。如下图，我们可以看到，能效、流程、方法工具是从「事」的角度出发，组织是从「人」的角度出发。研发效能的提升，无论是看板实践还是敏捷 Scrum 实践，更多解决的是如何让有价值的需求顺畅、高质量地流动。所以，我们要想提升效能，不能仅靠部分的管理实践，还需要一些工程实践，比如要持续集成、持续部署、持续监控、自动化测试等等，形成一个闭环作业。

从「事」的角度，我们需要梳理流程规范，要确保组织上下文形成一系列的共识，包括统一的术语、业务以及研发数据流的串联、度量单位的一致性等等。有了流程规范以后，我们就通过工具去固化流程规范。在这过程中，可以兼顾一些度量埋点的设计，把我们想要的一些指标设计进去，这样数据就自然而然地落到了系统中。最后，通过度量 UI 展现层，展示出一些数据供各个领域，持续改进、持续做决策。

从「事」的角度提升效能，是有一定成效的，但更重要的还是要从「人」的角度出发。我觉得，需要有一个变革的引领者，比如说是 Scrum Master 或者过程改进专家、效能专家等等。这些人需要有：

• 引导的技能，如：能够引导团队有效地开会，引导团队实践落地。

• 教练的技能，通过这种启发式提问，让团队成员找到自己的目标、实现目标的驱动力、激发团队整体的潜能。

• 当然，这个变革者他自身必须有自驱力，他能影响团队，帮助团队成员成功，帮助团队成员光彩夺目；同时，这个人要养成成长型思维，允许团队成员犯错，这种文化也很重要。

以上是我今天分享的主要内容，希望能给大家启发，感谢聆听。

-Q & A-

Question 1：

网友：软件敏捷开发模式下，市场需求会拆分成多个产品需求，开发继续拆分产品需求到更小颗粒度去编码。因此，开发团队经常用产品需求来衡量交付，每年研发效率都在提升。但市场侧却认为从市场需求角度看，效率并没有提升。如何让双方的效率提升达成一致的看法呢？

晓红老师：研发侧有自己的持续改进度量指标我觉得没问题，通过统计数据看到研发侧效率的提升，加强了团队持续改进提升的信心。关于「市场侧不认可」，需要了解市场部不认可的原因，如果市场部觉得在业务上并没有感知到研发效率的提升，可以定义一些业务指标来牵引研发更好地支撑业务。一般来说，市场部的指标要根据市场部的战略、目标来制定。

Question 2：

网友：在企业管理场景中如何推动敏捷在企业中落地呢？

晓红老师：我觉得有以下几点。第一点，无论你推动敏捷或者 DevOps 变革，我建议要有一个目标，相当于内驱力：我为什么要做这个敏捷转型，我要解决哪些痛点等等；第二点，就像刚才说的，最好有一个变革的引领者，领导者可以是 Scrum Master，他要辅导团队怎么去做敏捷，在企业中如何落地，让大家理解这个背后的原则等等；第三点，一个好的工具是非常必要的，它可以帮助你加速整个敏捷的落地。

Question 3：

网友：我们公司践行敏捷实践也有一段时间了，但是团队中有很多人不愿意开敏捷回顾会议，怎么办？

晓红老师：我觉得可能要分以下几点。第一，和团队成员去聊一下为什么不愿意参加回顾会，是不是觉得没有价值？如果是没有价值，那就需要检视一下回顾会是不是基于目标开的，需要有明确的目标；第二点可能也要去跟团队成员去聊一下，他们期待的敏捷回顾会是什么样的，他心中完美的敏捷回顾会是什么样？大家可以集思广益。

Question 4：

网友：我们是制造业，正在敏捷转型期，在敏捷实践过程中，员工配合度不高怎么办？

晓红老师：我觉得还是要看看他们不配合的原因，或者间接地去检视他们是不是没有理解敏捷的实质。其次，还是看看他有没有什么好的工具或者方法，可以更好地帮助大家达成敏捷转型的目标。

Question 5：

网友：Scrum 核心要点「3355」是必须的，还是说可以根据企业的自身情况做调整呢？

晓红老师：我想还是要根据企业不同的情景而定。比如说，公司刚进行敏型转型的时候，还是需要尽量遵守「3355」；当达到一定的敏捷成熟度了，也许都可以不需要 Scrum Master 这个角色。我之前看到过好多客户的团队，合并两个迭代进行回顾会，却可以很好地解决问题。所以，不同的阶段，企业可以根据自身情况采用不同的方法。

ONES 研发管理大师课第一季课程还在继续，「大型软件团队高效协作的方法与实践」「研发效能度量的行业趋势及五项精进」等课程即将上线。