精益思想（Lean Thinking）在数字化转型中一直扮演着重要的角色。精益源自20世纪50年代日本丰田发明的生产方法（TPS），即精益生产。基于这套方法论丰田实现了成本效益结合，大大提升了日本汽车的质量与成本优势，使得世界汽车工业重心开始由美国向日本倾斜。
在之前的文章中，为大家详细地讲解了精益与DevOps的关系及实践，本文我们邀请到DevOps解决方案架构师黄锦辉，带来《精益思想在软件交付中的应用》主题分享，深入挖掘解析精益思想的内涵，以及在软件交付领域，精益如何实践应用，一起来看看吧。
01. 为什么需要精益？
在数字化转型趋势中，业务敏捷（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和敏捷实践，但仍然会发现仍面临着如下挑战：
① 基本上没有人能够说清楚软件交付全过程，例如从用户提出需求开始，到最后将产品/服务交付给客户，会经过哪些步骤和工具，信息怎么传递流动
② 在研发过程中做了很多“优化”，软件交付周期却没有明显的缩短
③ 过度关注在人力方面，忽视了软件交付过程，导致内部资源利用率虽然有所提升，但整体软件交付效率实际是有下降的，反而会降低软件质量。
02. 精益思想与核心原则
1）精益思想的前世今生
20世纪50年代，大野耐一在日本丰田发明了丰田生产系统 (TPS)，创立了高效益、低消耗的生产方式（后被MIT研究团队称为“精益生产”），经过多年的实践使得日本的汽车工业赶超美国。当时精益更多是应用于制造业领域。1996年，书籍《LEAN THINKING》（《精益思想》）出版，这本书高度归纳了精益思想和原则，并将精益方式逐步扩展到制造业以外的领域。随着2003年《精益软件开发》的出版，精益思想真正开始应用于软件领域中。
2）什么是精益IT？
精益IT协会将精益IT定义为：“精益IT是精益制造和精益服务的原则的延伸，用于信息技术产品和服务的开发和管理。其目标是不断提高IT组织为客户提供的价值以及IT人员的专业水平。”
精益IT专注于提高IT人员，IT流程和信息技术，以便为客户提供更多价值。精益的本质是一种思考和行动的方式。精益IT还提到了如下七个概念，其中“提升客户价值”，是精益追求的目标；“减少浪费”是精益的核心，即通过不断地去减少过程中的浪费，增加价值。
3）精益的五个关键原则
① 首先，要明确客户价值，一切价值都是围绕客户展开的；
② 其次，基于客户价值，建立以客户为中心的价值流；
③ 再次，建立快速的流动机制，消除过程的瓶颈和浪费；
④ 然后，所有的价值流都是围绕客户进行的，是由客户拉动，而不是生产后再推动给客户;
⑤ 最后，尽可能第一次就把事情做好，在每个阶段保障质量，并通过可视化建立反馈，持续改进。
4）精益的核心思想
基于以上五个原则，精益的核心思想包含如下5个方面：
核心1：定义客户的价值-谁是我们的客户
价值是由客户定义，代表了客户对于特定产品或者服务的需求。我们需要持续关注客户价值，以及他们从产品或服务中感知到的价值。
核心2：价值流思想-建立客户视角的系统思维
① 价值流：
是由将产品或者服务从概念到交付给客户的所有任务和活动组成，包含了所有的信息、工作和物料流。
② 价值流图（VSM）：
是精益制造或精益企业技术，用于记录、分析和改进为客户生产产品或服务所需的信息流或物料流。价值流图在下文“精益在软件交付的应用”中，我们会详细阐述。借助价值流图，能帮助我们：
- 提供价值交付全周期的视图；
- 建立客户视角的系统思维；
- 提供驱动改进的定量数据。价值流会量化很多数据或者指标，可以驱动我们不断持续地改善。
核心3：流动效率—优于资源效率
我们在整个软件交付周期中，经常遇到整体交付效率没有明显提升的情况，即流动效率低的问题。如何实现端到端快速价值交付？这需要从以资源效率为核心，转变为以流动效率为核心来组织软件交付过程。
▲ 图片来源于书籍《This is Lean》资源效率，是指从组织内部视角，审视各个独立环节的产出效率，关注的是内部资源及职能。而流动效率是指从客户的角度，审视客户价值顺畅流动的程度，关注的是客户价值。
前置时间：即从用户提出需求开始，到最终交付给客户整体价值的端到端的时间。例如，上文举例的医院，前置时间为42天。如果去一站式的私人医院检查，医生诊断快速，从初诊到确诊的检查报告，排队等待时间也大大缩短。因为一站式私人医院关注的是流动效率。
过度局部优化资源效率，可能会带来额外的工作，你在工作中不断切换任务，导致整体工作时间增加，使得下一个环节的人或者客户经常处于等待状态，流动效率低。
核心4：质量内建—尽早发现并解决问题
在丰田里有个实践“安灯拉绳”（Andon Cord）。在生产制造过程中，当一线员工发现其中的工序有异常，会拉动手边的绳子-安灯拉绳，值班经理便会很快看见拉动绳子的员工是在几号岗位、在车间哪条流水线，这时会和专家一起检查生产，群策群力。如在特定的时间段解决不了时，便会决定停止整条生产线的运作。
图片来源于网络安灯拉绳的做法，强调尽可能在问题出现的第一时间去发现并且解决。如暂时解决不了便会停下生产线，不把问题留着转移到生产的下一个环节，这也是质量内建的体现。
质量内建，需要3个因素来体现：
① 建立信任的心理安全的环境 整条生产线停止运作的特殊情况，在绝大多数制造业工厂里是很大的事故，而丰田给予信任、心理安全的环境，来保障质量内建的实践。
② 可视化与透明性 整条生产流水线，以及安灯系统，都是通过可视化方式展示。
③ 群策群力 需要团队共同决策、一起解决问题。
核心5：持续改善—随时随地全员参与
改善，意味着持续改进，不断否定现状，寻求更高的水平。无论是在软件交付过程，还是个人职业生涯，改善的套路提供了一种面对未知的思路，从而渐进式地不断提升，持续进化。
需注意的是，改善并不是定期改善，而是随时随地全员参与。例如当软件开发中发现可以改善的环节时，应立即去改善。
03. 精益在软件交付的应用
1）实践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）
2）实践2：消除浪费——区分3种活动类型
通过价值流把指标量化提炼出来后，我们下一步要做的是识别浪费，并进行改善。针对不同的活动类型，我们可以采取不同的方式。
① 消除非增值活动 非增值活动即完全不会带来价值的活动，例如库存、返工、等待等，这类活动需要直接消除。
② 最小化必要非增值 必要非增值，例如员工进行培训技能是必要的，但对于客户来说并不创造直接价值，这类活动需要最小化缩短时间。
③ 优化增值活动 增值活动，例如软件需求分析、代码编写等活动对于客户是增值的，这类活动需要借助工具平台（例如DevOps平台），提高端到端的效率
那么如何识别软件开发、交付过程中的浪费呢？通常浪费有如下八种：
3）实践3：内建质量——软件交付的质量门禁
从需求、分析、编码、测试到发布，每个阶段都需要设定质量门禁或者质量关卡。下图是我们实际项目中应用的DevOps平台端到端的流水线。在每个阶段对应设置质量红线，根据提前设定的规则或标准来判断是否可通行。
在以往服务的优秀客户中，东风集团、国金证券也通过携手嘉为蓝鲸DevOps平台实现了质量管控的场景。
4）实践4 精益看板
设计精益看板时，需要考虑3个核心因素：
① 如何体现价值？
② 如何反映协作？
③ 如何暴露问题？
我们可以通过“5步法”，设计精益看板：
5）实践5：改善（Kaizen—日文）
改善的工具方法有很多，我们可以借助DMAIC框架，即：定义（Define）、度量（Measure）、控制（Control）、改进（Improve）和分析（Analyze）。
04. 精选互动问答
问：精益是否是敏捷迭代升级？
答：从时间来看，精益思想是远远早于敏捷和DevOps。精益思想是对20世纪50年代在丰田里实践的总结，敏捷是2001年由敏捷联盟提出，并且制定、发布了《敏捷宣言》，DevOps概念于2009年提出。目前流行的敏捷框架，scrum、SAFe、DevOps，甚至是PMI DA体系，底层思维均依赖或借鉴了精益思想。
在当今数字化转型中，精益、敏捷、DevOps是相辅相成的，实践者需要基于自身企业的情境（Context），选择适合自己的实践，没有One Size Fits All的方法。
