精益思想（Lean Thinking）在数字化转型中一直扮演着重要的角色。精益源自 20 世纪 50 年代日本丰田发明的生产方法（TPS），即精益生产。基于这套方法论丰田实现了成本效益结合，大大提升了日本汽车的质量与成本优势，使得世界汽车工业重心开始由美国向日本倾斜。

在上期 DevOps 系列直播中，我们为大家带来了“精益与 DevOps 如何相得益彰”的主题分享，为大家详细地分析了精益与 DevOps 的关系及实践，本期直播我们邀请到 DevOps 解决方案架构师黄锦辉，带来《精益思想在软件交付中的应用》主题分享，深入挖掘解析精益思想的内涵，以及在软件交付领域，精益如何实践应用。

本次直播设有审核，待审核通过后即可观看

Tips：如您不方便查看回放，可阅读以下总结文章，全文约 4000 字，预计阅读时间 7-9 分钟

为什么需要精益？

在数字化转型趋势中，业务敏捷（BVSSH）是核心目标，即更快（Sooner）、更安全（Safer）地交付更高质量（Better）的价值（Value）给到客户，同时让客户和员工满意（Happier）。

B-Better：

代表的是质量（Quality），例如更少的生产事故、更短的故障恢复时间（MTTR）和代码质量等。质量必须是内建的，而不是事后再检查。

S-Sooner：

更短的上线时间。即缩短前置时间（Lead Time）、提高吞吐量(Throughput)，提升流动效率(Flow Efficiency)。

S-Safer

满足持续的合规性（Continuous Compliance），考虑性能要求(Agile not Fragile)。

H-Happier

客户满意和员工幸福。

DevOps 和敏捷开发这两类软件开发方法论已被企业广泛采用，那为什么还需要精益呢？其实尽管我们在软件交付中已经应用 DevOps 和敏捷实践，但仍然会发现仍面临着如下挑战：

1. 基本上没有人能够说清楚软件交付全过程，例如从用户提出需求开始，到最后将产品/服务交付给客户，会经过哪些步骤和工具，信息怎么传递流动；

2. 在研发过程中做了很多“优化”，软件交付周期却没有明显的缩短；

3. 过度关注在人力方面，忽视了软件交付过程，导致内部资源利用率虽然有所提升，但整体软件交付效率实际是有下降的，反而会降低软件质量。

精益思想与核心原则

精益思想的前世今生

20 世纪 50 年代，大野耐一在日本丰田发明了丰田生产系统 (TPS)，创立了高效益、低消耗的生产方式（后被 MIT 研究团队称为“精益生产”），经过多年的实践使得日本的汽车工业赶超美国。当时精益更多是应用于制造业领域。1996 年，书籍《LEAN THINKING》（《精益思想》）出版，这本书高度归纳了精益思想和原则，并将精益方式逐步扩展到制造业以外的领域。随着 2003 年《精益软件开发》的出版，精益思想真正开始应用于软件领域中。

什么是精益 IT？

精益 IT 协会将精益 IT 定义为：“精益 IT 是精益制造和精益服务的原则的延伸，用于信息技术产品和服务的开发和管理。其目标是不断提高 IT 组织为客户提供的价值以及 IT 人员的专业水平。”

精益 IT 专注于提高 IT 人员，IT 流程和信息技术，以便为客户提供更多价值。精益的本质是一种思考和行动的方式。精益 IT 还提到了如下七个概念，其中“提升客户价值”，是精益追求的目标；“减少浪费”是精益的核心，即通过不断地去减少过程中的浪费，增加价值。

精益的五个关键原则

首先，要明确客户价值，一切价值都是围绕客户展开的；

其次，基于客户价值，建立以客户为中心的价值流；

再次，建立快速的流动机制，消除过程的瓶颈和浪费；

然后，所有的价值流都是围绕客户进行的，是由客户拉动，而不是生产后再推动给客户;

最后，尽可能第一次就把事情做好，在每个阶段保障质量，并通过可视化建立反馈，持续改进。

精益的核心思想

基于以上五个原则，精益的核心思想包含如下 5 个方面：

核心 1：定义客户的价值-谁是我们的客户

价值是由客户定义，代表了客户对于特定产品或者服务的需求。我们需要持续关注客户价值，以及他们从产品或服务中感知到的价值。

核心 2：价值流思想-建立客户视角的系统思维

价值流：

是由将产品或者服务从概念到交付给客户的所有任务和活动组成，包含了所有的信息、工作和物料流。

价值流图（VSM）：

是精益制造或精益企业技术，用于记录、分析和改进为客户生产产品或服务所需的信息流或物料流。价值流图在下文“精益在软件交付的应用”中，我们会详细阐述。借助价值流图，能帮助我们：

• 提供价值交付全周期的视图；

• 建立客户视角的系统思维；

• 提供驱动改进的定量数据。价值流会量化很多数据或者指标，可以驱动我们不断持续地改善。

核心 3：流动效率—优于资源效率

我们在整个软件交付周期中，经常遇到整体交付效率没有明显提升的情况，即流动效率低的问题。如何实现端到端快速价值交付？这需要从以资源效率为核心，转变为以流动效率为核心来组织软件交付过程。

▲ 图片来源于书籍《This is Lean》

资源效率，是指从组织内部视角，审视各个独立环节的产出效率，关注的是内部资源及职能。而流动效率是指从客户的角度，审视客户价值顺畅流动的程度，关注的是客户价值。

前置时间：即从用户提出需求开始，到最终交付给客户整体价值的端到端的时间。例如，上文举例的医院，前置时间为 42 天。如果去一站式的私人医院检查，医生诊断快速，从初诊到确诊的检查报告，排队等待时间也大大缩短。因为一站式私人医院关注的是流动效率。

过度局部优化资源效率，可能会带来额外的工作，你在工作中不断切换任务，导致整体工作时间增加，使得下一个环节的人或者客户经常处于等待状态，流动效率低。

核心 4：质量内建—尽早发现并解决问题

在丰田里有个实践“安灯拉绳”（Andon Cord）。在生产制造过程中，当一线员工发现其中的工序有异常，会拉动手边的绳子-安灯拉绳，值班经理便会很快看见拉动绳子的员工是在几号岗位、在车间哪条流水线，这时会和专家一起检查生产，群策群力。如在特定的时间段解决不了时，便会决定停止整条生产线的运作。

图片来源于网络

安灯拉绳的做法，强调尽可能在问题出现的第一时间去发现并且解决。如暂时解决不了便会停下生产线，不把问题留着转移到生产的下一个环节，这也是质量内建的体现。

质量内建，需要 3 个因素来体现：

建立信任的心理安全的环境

整条生产线停止运作的特殊情况，在绝大多数制造业工厂里是很大的事故，而丰田给予信任、心理安全的环境，来保障质量内建的实践。

可视化与透明性

整条生产流水线，以及安灯系统，都是通过可视化方式展示。

群策群力

需要团队共同决策、一起解决问题。

核心 5：持续改善—随时随地全员参与

改善，意味着持续改进，不断否定现状，寻求更高的水平。无论是在软件交付过程，还是个人职业生涯，改善的套路提供了一种面对未知的思路，从而渐进式地不断提升，持续进化。

需注意的是，改善并不是定期改善，而是随时随地全员参与。例如当软件开发中发现可以改善的环节时，应立即去改善。

精益在软件交付的应用

实践 1：价值流图在软件中的应用

第一层（最上层）为信息流，即供应商和客户之间的信息流，中间会经过发布管理过程。其中，信息流的需求，企业内部会用到许多工具，比如需求管理工具，版本工具，自动化工具等。

第二层（中间层）为生产的过程流。例如软件交付中，会经过需求分析设计、开发、测试、部署、发布投产等流程阶段。这里会涉及几个量化的指标-前置时间、周期时间、处理时间、安装时间，我们在下文再一一详细解释。

第三层（最底层）是根据各个阶段里量化的指标，去绘制时间流水线。例如需求分析（第一个凹处水平线）花了 0.5 小时，等待开发（第二个凸处水平线）花了 1 天，开发（第三个凹处水平线）用了 1.5 小时，继续等待（第四个凸处水平线）花了 2 天等等，以此类推，前置时间总共花了 12.5 天，处理时间为 3.5 天。

▲ VSM 价值流图（图片来源于网络）

量化指标的概念：

前置时间（Lead Time）：

从用户提出需求开始，到最终交付给客户整体价值的端到端的时间。这是对客户关键的时间，客户只关注整体花费的时间，期间的过程客户并不在意。在如上价值流图中，前置时间为 12.5 天

周期时间（Cycle Time）:

各个阶段团队处理的时间。例如需求分析花了 0.5 个小时，则周期时间为 0.5 个小时。

处理时间（Process Time）：

也称流程时间，是周期时间的总和。图中周期时间为 0.5h+1.5h+1h+0.5h=3.5h，即对客户来说，有价值的时间是 3.5h，其余等待的额外时间对于客户来说是没有价值的。

安装时间（Setup Time）：

环境准备的时间。例如代码开发需准备本地的开发环境，准备消耗了多长时间，即为安装时间

还有一种价值流图的延伸-流框架（Flow Framework），详情可见 PPT 及直播回顾。

点击下载 PPT：内容中心

实践 2：消除浪费——区分 3 种活动类型

通过价值流把指标量化提炼出来后，我们下一步要做的是识别浪费，并进行改善。针对不同的活动类型，我们可以采取不同的方式。

消除非增值活动

非增值活动即完全不会带来价值的活动，例如库存、返工、等待等，这类活动需要直接消除。

最小化必要非增值

必要非增值，例如员工进行培训技能是必要的，但对于客户来说并不创造直接价值，这类活动需要最小化缩短时间。

优化增值活动

增值活动，例如软件需求分析、代码编写等活动对于客户是增值的，这类活动需要借助工具平台（例如 DevOps 平台），提高端到端的效率。

（点击视频了解嘉为蓝鲸 DevOps 平台）

那么如何识别软件开发、交付过程中的浪费呢？通常浪费有如下八种：

实践 3：内建质量——软件交付的质量门禁

从需求、分析、编码、测试到发布，每个阶段都需要设定质量门禁或者质量关卡。下图是我们实际项目中应用的 DevOps 平台端到端的流水线。在每个阶段对应设置质量红线，根据提前设定的规则或标准来判断是否可通行。

在以往服务的优秀客户中，东风集团、国金证券也通过携手嘉为蓝鲸 DevOps 平台实现了质量管控的场景，相关案例介绍欢迎点击阅读。

软件质效领航者 | 优秀案例•东风集团DevOps改革项目

软件质效领航者 | 优秀案例•国金证券DevOps建设项目

实践 4 精益看板

设计精益看板时，需要考虑 3 个核心因素：

如何体现价值？

如何反映协作？

如何暴露问题？

我们可以通过“5 步法”，设计精益看板：

实践 5：改善（Kaizen—日文）

改善的工具方法有很多，我们可以借助 DMAIC 框架，即：定义（Define）、度量（Measure）、控制（Control）、改进（Improve）和分析（Analyze）。

关于如何用导师与学员对话（辅导套路）来传授改善套路，具体方式解析请见 PPT。

点击下载 PPT：内容中心

精选互动问答

问：精益是否是敏捷迭代升级？

答：从时间来看，精益思想是远远早于敏捷和 DevOps。精益思想是对 20 世纪 50 年代在丰田里实践的总结，敏捷是 2001 年由敏捷联盟提出，并且制定、发布了《敏捷宣言》，DevOps 概念于 2009 年提出。目前流行的敏捷框架，scrum、SAFe、DevOps，甚至是 PMI DA 体系，底层思维均依赖或借鉴了精益思想。

在当今数字化转型中，精益、敏捷、DevOps 是相辅相成的，实践者需要基于自身企业的情境（Context），选择适合自己的实践，没有 One Size Fits All 的方法。