价值流管理驱动的-DevOps-全-

价值流管理驱动的 DevOps（全）

原文：annas-archive.org/md5/b3b55ac4e82bbba864d43b4508adfbe9

译者：飞龙

协议：CC BY-NC-SA 4.0

序言

我的职业生涯开始于 德州仪器（Texas Instruments） 的一家高科技制造设施，担任年轻的工程项目经理。当时我根本没想到，关于精益生产流程的基本概念将对我的职业生涯产生深远影响，不论是在作为软件产品经理（计算机辅助软件工程 – CASE 和工作流 工具）时，还是作为顾问和 IT 项目经理，参与开发用于业务流程改进的商业应用时。然而，我在这些领域的工作始终侧重于改善 IT 部门之外的组织价值流。

精益生产理念在 2000 年代初期通过像 Mary 和 Tom Poppendieck 这样的人物的洞察，开始进入软件开发领域，他们的著作《精益软件开发：敏捷工具包》便是其中之一。到 2010 年，精益敏捷实践背后的理念开始渗透到软件开发方法论中，如 规模化敏捷框架（Scaled Agile Framework） 和 有纪律的敏捷（Disciplined Agile）。最终，我们开始看到精益生产改进理念在 IT 导向的价值流中实际应用，呈现为现代 价值流管理（VSM） 软件工具和平台。

正如你将在本书中发现的，VSM 是一种跨越所有开发和运营价值流的精益改进方法。价值流简单来说是一个端到端的活动序列，在这个过程中，工作和信息以协调和简化的方式流动，从而最有效地交付价值（例如产品、服务和结果）。

在现代的重新构想中，软件开发行业应用 VSM 工具来集成、自动化并协调 DevOps 流水线中的工作，以改进跨越开发和运营职能的端到端软件交付活动。现代 VSM 工具不仅实时捕捉关键的性能指标，还提供统一的数据模型和分析工具，以评估当前状态和未来期望状态。

简而言之，现代 VSM 工具提供了必要的数据和分析能力，帮助做出明智的决策，从而改进软件交付流程。在企业规模上实施 DevOps 方法、配置和工具并非易事，也并不便宜。另一方面，VSM 工具提供了你所需的数据，以最大限度地利用你的 IT 投资。

将这些思想和观念汇集成书的过程充满挑战，包括来自 VSM 联盟的输入，16 家工具供应商——共对 24 家软件工具公司进行了研究，再加上两家领先的 Lean-Agile 框架公司和两家领先的 Lean 培训与方法公司。

有时候，从这些不同的来源汇集所有信息就像是在赶猫一样！然而，我相信，最终的结果代表了迄今为止最全面的 VSM 方法和工具来源。此外，这本书还帮助解释了 DevOps 和 VSM 如何携手合作，在数字经济中推动竞争性成果。

回顾一下，VSM 并不是一个新概念，尽管它最近被应用于帮助在 IT 价值流中进行精益导向的改进。实践精益生产改进概念的组织，使用 VSM 方法来改进所有开发和运营价值流。作为一种战略性推动者，VSM 倡议有助于发现并优先处理跨企业的潜在改进机会，从而更有效地交付价值。而许多被识别出的价值流改进机会是数字化增强的，最适合通过软件应用实现。

例如，在我们的数字经济中，企业创造软件应用程序作为商业产品，或作为基于 Web 的信息或娱乐服务来提供服务。然而，软件也可以增强实体产品，比如汽车中的导航和控制系统。最后，企业、政府机构和非营利组织使用软件应用程序来改善其关键业务流程和价值流活动中的价值流动。

通过我的研究和与许多领先的 VSM、DevOps 和精益组织的讨论，我得出结论，组织必须将基于 IT 的 VSM 工具策略整合到企业的战略 VSM 倡议中。虽然精益在 IT 中是一个相对较新的概念，但其他部门可能已经在实施精益概念几十年了——或者，至少，他们应该已经这样做了。这不仅仅是制造业的情况，许多服务公司和医疗提供者也已经实施了精益实践。

在这本书中，你将学习如何应用一种通用的 VSM 方法论，帮助识别组织发展和运营价值流中的改进机会，而不仅仅是 IT。这种方法之所以被采用，是基于上述原因。组织使用 VSM 方法和工具识别并优先处理所有价值流中的改进机会，其中许多需要通过软件来实现改进。

换句话说，VSM 方法针对两个广泛领域进行价值流改进。首先，现代 VSM 方法和工具帮助改善基于 DevOps 的软件交付能力。其次，相同的 VSM 策略和技术帮助识别其他组织价值流中的数字化改进机会，从而指导组织改进的软件交付能力。

因此，VSM 不仅仅局限于在 DevOps 中进行价值流改进。从系统思维的角度来看，对 DevOps 进行价值流改进是一种局部优化。换句话说，如果软件交付不是我们业务系统中的瓶颈，或者我们不知道如何应用我们改进后的软件交付能力，那么在整体系统改进上的时间和资源投入可能几乎没有或根本没有影响。

如果你的组织曾经在实施 DevOps 工具链和平台上花费了时间和金钱，但却没有看到合理的投资回报，你可能已经亲身经历过这种情况。

你可能对精益实践了解不多，但没关系。你将在本书中学到，精益的核心是发现并消除妨碍流动的浪费，这些浪费导致瓶颈、延迟、过多的在制品，最终造成客户不愿支付的更高成本。正因为如此，精益实践者始终在成本和市场交付时间上相较竞争对手具有优势。

主要观点是，企业可能会在其 DevOps 和 VSM 工具倡议上投入大量时间和精力，但如果没有将这些软件交付改进应用于提升组织的其他运营和开发价值流，那么也无法看到合理的投资回报。因此，DevOps 团队应该将他们的活动与企业的所有价值流改进对齐。此外，正是通过他们的 Kaizen Bursts（未来状态改进机会场景），企业 VSM 倡议帮助识别并优先考虑那些改进后的 DevOps 能力能够产生最及时和最有益影响的领域。

出于这些原因，本书介绍了增值概念背后的历史基础、敏捷的价值观和原则、系统和精益思维，以及 VSM 及其在 IT 中的现代背景。你将发现如何将 VSM 作为一种方法论，来发现整个组织价值流中的改进领域，同时使用 VSM 工具在基于 DevOps 的软件交付管道中进行精益导向的改进。但最终，你会发现，正是 DevOps 与精益导向改进的结合，推动了整个组织价值流的改进，从而帮助证明安装 VSM 工具和 DevOps 工具链及管道所带来的时间、费用和精力的价值。

这本书逻辑上分为四个部分，副标题如下：

• 价值交付 – 它的意义以及如何进行

  第一章 – 第五章

• VSM 方法论 – 一种精益导向并经过验证的、在企业范围内实现流动改进的方法

  第六章 – 第十章

• VSM 工具供应商和框架 – 改进你的软件交付管道能力

  第十一章 – 第十四章

• 应用 VSM 与 DevOps – 推动数字化业务转型

  第十五章和第十六章

请随意在本书的四个部分之间跳跃。如果你想了解组织在实施 DevOps 平台时面临的问题，可以先快速阅读 第十五章**，定义适当的 DevOps 平台战略，在这一章中，你将听到六位专家对此主题的见解。

希望你能像我写这本书时那样享受阅读它。

– Cecil Gary Rupp

本书的目标读者

本书是为企业高管、经理、DevOps 团队成员以及其他参与数字业务转型的利益相关者编写的，旨在帮助他们改善通过组织价值流传递客户价值的过程。

本书的内容

第一章，提供以客户为中心的价值，定义了什么构成了价值的交付。

第二章，建立在精益敏捷基础上，解释了成为一个精益敏捷企业意味着什么。

第三章，分析复杂系统的相互作用，将软件开发活动视为一个复杂系统，并解释参与元素之间相互关系的影响。

第四章，通过 VSM 改善 IT 价值流，解释了价值流管理的历史和基本原理。

第五章，通过 DevOps 管道推动业务价值，评估了端到端活动以及信息流和集成工具链，这些使得 DevOps 管道在企业规模实施时变得复杂且昂贵。

第六章，启动 VSM 计划（VSM 步骤 1–3），解释了为什么组织必须承诺精益方法，如何选择价值流，以及 VSM 团队成员和其他利益相关者需要学习实施精益方法的内容。

第七章，绘制当前状态（VSM 第 4 步），解释了如何使用 CI/CD 管道流改进的用例作为示例，构建当前状态价值流图。

第八章，识别精益度量（VSM 第 5 步），解释了用于识别浪费的常见精益度量，这些浪费会导致价值流中的绩效不佳，并且最适用于评估 IT 和 DevOps 相关的价值流。

第九章，绘制未来状态（VSM 第 6 步），解释了如何构建未来状态价值流图和 Kaizen Burst（生产改进机会），并以 CI/CD 管道流改进的用例为例进行说明。

第十章，改进精益敏捷价值交付周期（VSM 步骤 7 和 8），解释了如何制定和执行一个 Kaizen 计划，以应对未来状态价值流图中识别的改进机会。

第十一章，识别 VSM 工具类型和功能，介绍了三种主要的 VSM 工具及其一般用途和功能。

第十二章，介绍领先的 VSM 工具供应商，提供了 16 家领先 VSM 工具供应商的功能描述，以及它们各自的优势和关注领域。

第十三章，介绍 VSM-DevOps 实践领导者，介绍了 VSM 联盟和两种推动 VSM 的领先精益敏捷框架——纪律化敏捷（Disciplined Agile）和 Scaled Agile Framework®。

第十四章，介绍企业精益 VSM 实践领导者，介绍了两家领先的精益培训和认证组织——精益企业研究所（Lean Enterprise Institute）和 LeanFITT™。

第十五章，定义适当的 DevOps 平台战略，提供了六位专家 DevOps 从业者的访谈，解释了组织需要注意的潜在 DevOps 实施陷阱。本章还介绍了四种 DevOps 平台实施战略，并分析了每种战略的优缺点。

第十六章，通过 VSM 和 DevOps 转型业务，解释了如何利用 VSM 和 DevOps 工具及相关实施举措，将企业转型为在数字经济中具备竞争力的可行实体。

下载彩色图片

我们还提供了一个 PDF 文件，其中包含本书中使用的屏幕截图和图表的彩色图像。您可以在此下载：static.packt-cdn.com/downloads/9781801078061_ColorImages.pdf

使用的约定

提示或重要说明

显示如下。

联系我们

我们始终欢迎读者的反馈。

一般反馈：如果你对本书的任何内容有疑问，请通过电子邮件联系我们，地址是 customercare@packtpub.com，并在邮件主题中注明书名。

勘误：尽管我们已尽最大努力确保内容的准确性，但错误仍然可能发生。如果您在本书中发现错误，我们将非常感激您向我们报告。请访问 www.packtpub.com/support/errata 并填写表格。

盗版：如果您在互联网上发现任何形式的非法复制品，我们将非常感激您能提供其位置地址或网站名称。请通过 copyright@packt.com 联系我们，并提供相关链接。

如果你有兴趣成为作者：如果你在某个领域有专长并且有兴趣参与写作或为书籍贡献内容，请访问 authors.packtpub.com。

分享您的想法

阅读完《通过价值流管理驱动 DevOps》后，我们很希望听到您的想法！请 点击这里直接前往亚马逊评论页面。

) 分享您对本书的反馈。

您的评论对我们和技术社区都非常重要，帮助我们确保提供优质的内容。

第一部分：价值交付

第 1 至第五章介绍了增加价值、精益敏捷实践、系统思维和价值流管理的核心概念。这些概念适用于现代 IT 实践和其他在整个企业中提供价值的价值流。这些概念也是你学习如何在本书第二部分应用这些概念的基础——*VSM 方法论**——一种以精益为导向的经过验证的提升企业整体流程的改进方法。

在前三章中，你将学习如何通过融合敏捷、系统思维和精益开发实践，专注于为整个企业增值。接着，在 第四章, 通过 VSM 改善 IT 价值流 中，你将了解如何通过价值流管理（VSM）这一方法来提升包括 IT 在内的所有价值流的精益生产能力。最后，在 第五章, 通过 DevOps 流水线推动业务价值 中，你将学习什么是 DevOps 流水线，以及为什么它是数字经济中交付价值的最佳方法。

现代的 VSM 工具支持在 IT 价值流中实施精益改进，并改进 DevOps 流水线的实施。在这个背景下，这些章节有助于解释为什么 DevOps 流水线的有效实施——作为一个高效的软件交付系统——是允许组织在现代数字经济中竞争的必要“基础条件”。

本节包括以下章节：

• 第一章, 交付以客户为中心的价值

• 第二章, 建立精益敏捷基础

• 第三章, 分析复杂系统交互

• 第四章, 通过 VSM 改善 IT 价值流

• 第五章, 通过 DevOps 流水线推动业务价值

第一章: 交付以客户为中心的价值

本章介绍了价值的多种不同定义，并解释了敏捷、系统思维和精益开发如何协同工作以交付以客户为中心的价值。通过这些基础的理解，价值流管理（VSM）和DevOps（开发运维）也作为互补的信息技术（IT）实践和工具被引入，以支持精益敏捷实践。

你将学习 VSM 如何帮助最大化客户价值在组织的软件开发和交付流程中的流动。例如，当开发支持业务操作的应用时，VSM 有助于改善系统开发生命周期（SDLC）过程中的工作流。

然而，VSM 不仅仅是为了在数字经济中改善商业系统的软件开发和交付实践。许多商业企业、政府机构和非营利组织提供以信息为导向的产品和服务，这些产品和服务通过基于 Web 的服务进行交付。此外，许多物理产品都集成了计算设备、软件和互联网接入，以在整个生命周期中按需提供新功能和增强功能。

基于这些原因，VSM 方法和工具的使用必须超越 IT，以帮助改善跨操作和面向开发的价值流中的工作流程和信息流。

DevOps 以互补的方式改善了 IT 部门之间的沟通，同时集成和自动化 IT 流程，使得客户为中心的价值能够在所有组织价值流中持续流动。因此，现代的 DevOps 团队可以比传统的 SDLC 和敏捷实践更加高效、快速且无错误地交付价值。

本章将教你这些实践如何协同工作，以交付以客户为中心的价值。涵盖的主题包括：

• 定义多种形式的价值这一术语

• 开发价值主张

• 创造价值

• 从精益敏捷的角度看待价值

• 理解 VSM

• 理解 DevOps 在交付价值中的作用

• 整合精益、敏捷、价值流管理（VSM）和 DevOps

定义多种形式的价值这一术语

本书的核心内容是创建数字化转型，以高效、快速且低成本地交付以客户为中心的价值。这一策略涉及将信息技术（IT）与在企业中发生的价值流转型进行整合和对齐。价值流管理（VSM）是一种精益生产改进策略，在 IT 领域找到了新的应用。由于 VSM 是本书的主要内容，让我们从 VSM 语境下的价值定义开始。

从精益导向的视角看待价值

价值流是精益生产概念，描述了从构思、创建、部署、支持、退役到维护所需的产品生命周期活动。这一概念如其名所示，价值流的重点在于确保所有产品交付活动都能创造价值。从精益的角度来看，创造以客户为中心的价值意味着不仅仅提供功能和特性，还要消除所有客户不希望其成本中增加的浪费形式。

VSM 是一种方法，旨在系统地消除浪费，提高生产力和效率，同时降低成本。更准确地说，您将学习到 VSM 涵盖了面向精益的多种方法，以改善跨价值流的工作和信息流。现代 VSM 工具支持最初由丰田开发的 VSM 方法，这些方法用于映射物料和信息流，并在 2000 年代初期（Jones, Womack, 2003）将这一方法推广到全球。

当我们进入精益-敏捷视角和 VSM 相关部分时，您还会发现有两种形式的价值流：运维和开发。我们来快速看看这两种价值流之间的区别。

区分开发与运维

面向运维的价值流为组织的外部客户提供产品和服务，而开发价值流则创造组织运维价值流使用或交付的东西。

换句话说，可以这样表达：

• 运维价值流包括定义公司——或其产品线或业务部门（LOBs）——如何开展业务、赚取收入并向客户交付服务的工作和信息流。

• 开发价值流包括构建和支持运维价值流用来交付价值的产品、服务和其他工件的工作和信息流。

面向运维的价值流通过提供产品、信息和服务（无论是在线提供还是通过个人接触）来增强客户体验。相比之下，面向开发的价值流为内部或外部客户创造产品和服务。换句话说，开发价值流负责构建东西，而运维价值流则需要向客户销售、交付并提供支持。

这两项职能都是必要的，并且具有增值作用。然而，在目标、计划范围以及谁控制和资助这些活动方面，区分开发和运维是至关重要的。例如，业务部门高管和产品负责人对其运维价值流活动中的投资优先级负责。相比之下，投资组合管理团队则控制开发导向流活动的投资优先级。

另一种看待这种区分的方式是销售、交付和支持产品的运营导向过程。这些是为我们的客户提供价值的战术性活动，通常具有相对较短的规划周期。开发价值流的投资通常更大，对组织的长期生存至关重要，需要更长的规划和实施周期。相对而言，开发导向的价值流有助于确保组织具备满足战略目标所需的基础设施、产品和服务。

乍一看，开发与运营之间的这种区分似乎支持传统的 IT 组织模型。开发团队为内部和外部客户或用户创建软件产品，而运营团队则负责保持系统的运行、安全和可用，同时通过帮助台服务解决客户和用户的问题。

本书稍后你将学到，实施精益-敏捷实践的 IT 组织应考虑将传统的 IT 开发和运营职能转移到专门的产品团队中。但我们现在先不谈这个，我们稍后将在第四章，定义价值流管理中回到这个话题。

现在，让我们来看一些 IT 开发导向的价值流如何为其他组织价值流（例如客户订单输入或产品履行）开发和支持软件应用程序的示例。

开发支持组织价值流的应用程序

以下图表展示了三个组织价值流：订单输入、履行 和 软件开发。订单输入和履行是运营导向的价值流，而软件开发活动是开发导向的价值流：

图 1.1 – 价值流示例

每个活动块标识了活动的名称、过程时间 (PT)、交付时间 (LT) 和 完成百分比与准确性 (%C/A) 指标。你将在稍后的第八章，识别精益指标（VSM 第 5 步）中学习如何使用这些指标。需要理解的主要一点是，IT 是一个关键的开发价值流，它提升了其他运营价值流的交付能力和效率。

本书故意以讨论面向运营和开发的价值流作为开篇。当前的趋势是将 VSM 视为一种基于工具的方法，用于改进 DevOps 流水线工作和信息流。DevOps 流水线流程的改进是 VSM 的一个很好的应用。然而，如果你的组织的 VSM 策略仅限于 DevOps，那么它就忽视了关键点。图 1.1 中展示的价值流示例讨论清楚地表明，基于 IT 的开发价值流如何帮助改善运营价值流。

本书提供了关于整合敏捷、精益、VSM 和 DevOps 实践的指导，以便在企业规模上实现业务敏捷性。这些方法和工具使组织能够快速、高效、以最低成本提供客户所需的产品和服务。那些成功实施这些方法的企业，特别是在整个企业范围内实施的企业，在我们日益数字化的经济中竞争时占据了优势。

我们将在本章后续内容以及整本书中讨论所有这些概念。在此之前，首先需要清楚理解在数字经济和 IT 角色中竞争意味着什么。

在数字经济中竞争

唐纳德·塔普斯科特在他的书《数字经济：网络化智能时代的机遇与危险》（1997 年）中首次提出了数字经济这一术语。书中的核心焦点是数字技术如何改变个人和社会之间的互动方式。

之后，在 2001 年，时任美国人口普查局经济项目副主任的托马斯·L·梅森堡发表了一篇名为《测量数字经济》的论文。论文描述了美国人口普查局发起的一项努力，旨在衡量电子设备作为我们当时正在兴起的数字经济基础的经济影响。

在他的论文中，梅森堡描述了数字经济的三个主要组成部分，列举如下：

• 电子商务基础设施：包括所有参与的计算、网络、通信、安全和软件系统。

• 电子商务流程：支持数字经济的业务流程。

• 电子商务交易：支持在线销售商品和服务的交易。

为数字经济构建产品

数字经济这一术语在现代语境下的意义远远超出了梅森堡最初以电子商务为中心的看法。例如，数字化技术如今允许组织通过互联网和移动技术开展业务，并提供近乎实时的全球信息和基于知识的服务访问。

此外，数字技术通过为物理产品增添新特性，从而增强了产品功能，这些功能是通过简单的材料或机械部件修改无法实现的。广义上讲，这些技术被归类为物联网（IoT），即使是在交付给客户之后，产品的功能和能力也可以进行更新。

物联网（IoT）能力的关键区分因素是能够通过网络传输数据，而无需人与人之间或人与计算机之间的互动。从概念层面看，物联网是一个由唯一标识符（UIDs）连接的计算设备系统，使它们能够通过互联网和移动连接与其他计算系统和数字设备进行交互。

物联网设备包括机械和数字增强的机器以及嵌入在制造商品、人员或动物中的物体。作为现代例子，您的汽车通过移动连接接收工厂更新，更新内容包括计算和导航系统。基于远程医疗的物联网解决方案通过外部和嵌入式监测系统实时监控患者的健康状况。最后的例子是，带有应答器的嵌入式生物芯片帮助识别动物并监控它们在野外和农场中的健康状况与位置，甚至可以识别您的宠物。

在数字经济中实现连接

我们的现代数字经济不仅仅包括电子商务和数字化增强的产品。互联网通过社交媒体工具和平台开辟了非凡的沟通途径、信息共享和协作。

基于网络的社交媒体工具使人们能够通过多种媒体格式（例如音频、视频、文字、照片、图像等）互动并分享信息和经验。社交媒体的核心在于利用内容推动人与人之间和商业与人之间的互动。

Gibbons Business Solutions LLC.的总裁 Holly Gibbons 列出了六种社交媒体内容类别，这些内容能够驱动互动（gibbons-business-solutions.com/6-types-of-social-media-content-that-drive-engagement/），具体如下：

• 推广：提供关于产品和服务的信息

• 教育：建立专业知识并启用自助

• 连接：提供关于你业务的“内部”视角

• 对话：专门针对吸引客户

• 灵感：“让人感觉良好”的信息，包含引用、事实和成功的个人故事，反映了个人或实体的愿景和价值观

• 娱乐：通过分享节日祝福、笑话、漫画、有趣但富有信息的视频、竞赛和赠品来与观众互动

社交媒体是一种变革性能力，有助于推动我们现代数字经济的发展。以下小节列出了其他数字化增强的商业转型。

在数字经济中提供价值

数字经济的其他名称包括互联网经济、新经济或网络经济。数字经济的发展迫使传统的实体公司重新思考其商业战略，否则将面临被如亚马逊（零售）、Airbnb（旅游住宿）、谷歌（信息搜索）、Netflix（家庭娱乐）、Lyft和Uber（交通服务）、特斯拉（汽车和航空航天）、YouTube（基于视频的信息和娱乐内容共享）等激烈的竞争性颠覆者挤出市场的风险。

由于传统基础设施的投资遗产，公司需要迅速找到创造性的方法，利用其传统规模经济在数字经济中竞争。在某些情况下，这意味着寻找与客户互动的不同方式。在其他情况下，将传统和数字基础设施相结合的混合方式可能会提供最具竞争力的优势。

无论如何，公司必须定义并执行其竞争价值主张。他们必须评估所有的投资和活动，以确保最大程度地为增加以客户为中心的价值做出贡献。最终，本书介绍了许多相互关联的概念，帮助组织在数字经济中创造价值，但在进入这些章节之前，我们需要对价值的含义达成共识。以下小节将讨论这一主题。

深入探讨价值的众多概念

语义学在计算机科学中至关重要——如此重要，以至于有一个专门的 IT 学科叫做本体论。如果你查找本体论这个词，你会发现它源自形而上学的一个分支，专门研究存在的本质或什么是存在。本体论是一个复合词，结合了onto（希腊语ὄν）和“存在；那就是”（gen. ὄντος, ontos）。换句话说，它是一个旨在发现什么是现实的学科。

在信息科学领域，本体论处理语义意义。问题在于，人类有一个令人烦恼的习惯，那就是使用相同的术语，但对这些词语的实际含义有非常不同的看法。我们的生活经历、教育和智力能力极大地影响了我们对所使用词汇的理解。这是我们人类常常误解沟通的主要原因。

相比之下，传统信息系统必须对其使用的术语和价值有准确的上下文理解；否则，它们无法正确交换信息。这个问题同样适用于人机交互。我们希望使用的词语可能与计算机对这些术语的理解不匹配。这种二分法是推动人工智能（AI）研究的一个重要因素。换句话说，部分 AI 研究旨在帮助计算机理解在特定人机交互中词语的上下文含义。

价值一词在商业中有许多含义，这些含义支持各种商业实践或根据语境所追求的商业结果（也就是说，价值一词的含义根据其应用场景不同而有所不同）。举个与本书相关的例子，敏捷（Agile）、精益（Lean）、价值流映射（VSM）和 DevOps 都共享一个理念，即组织必须从客户的角度交付价值。然而，它们实现这一目标的策略各不相同。此外，IT 专家和商业分析师需要理解，他们与其他部门互动时，可能会遇到对价值一词的完全不同的理解。

用一个类比来说，我们遇到的情况有点像盲人描述大象的故事。由于他们看不见，盲人只能通过触觉来了解大象的样子，理解也有限，正如下面的图示所示：

图 1.2 – 六个盲人和大象

对于不熟悉这个故事的人来说，第一个盲人触摸到大象的象鼻并喊道，“大象就像一条粗蛇”；然而，下一个盲人摸到大象的耳朵，说：“不，它像一个风扇”。接下来，另一个人摸到大象的獠牙，说：“我不知道你们在说什么；它是一支矛”。排在后面的盲人摸到大象的腿并宣称，“大象就像一根又粗又壮的树干”，但是摸到大象侧面的人认为他们碰到的是一堵墙。最后，摸到大象尾巴的盲人认为自己抓住的是一根绳子。

只有一只大象，但盲人根据他们各自的“亲身”经历以及缺乏全局观念，形成了不同的大象理论。商业分析师在试图理解什么能为企业增值时，也会面临类似的问题。因此，在讨论敏捷、精益、VSM 和 DevOps 如何提升价值之前，我们需要花一些时间理解这个词在不同语境中的多种用法。

本章探讨了带有这一目标的多种价值变体，涵盖了所有权、会计、市场营销、供应链、敏捷、精益和 DevOps 等领域。

从商业资产的角度看待价值

在最简单的语境下，价值一词指的是从金钱、物质、实用性或个人角度表达的资产价值——例如，有许多方式来表达上市公司的商业价值，如股东价值、公司货币价值、价值捕获、公允价值和市场价值。

股东价值与公司在市场中股票持有者股份的价值有关。股东的价值会随着市场对公司在维持和增长利润能力的看法而波动。从这个角度来看，一家公司的价值大致等同于其流通股数乘以当前的股价。

货币价值是对资产——如公司、产品、财产、土地或服务——如果出售时会带来的金钱数额的表达。换句话说，货币价值是指某物在自由公开市场上值多少钱。货币价值的评定来自供给与需求的动态——例如，相对需求增加时，产品供给增加会降低其价值。相反，供给有限而需求强劲时，会推动价格上涨。

如果你和一位工商管理硕士（MBA）毕业生或会计师交谈，他们可能会使用术语价值捕获。在他们的语境中，价值捕获描述的是在每笔商业交易中保留一部分价值的过程，通常表现为盈利。然而，在与公共融资相关的事务中，价值捕获意味着利用公共融资开发基础设施，从而提升一个城市整体价值以及周边商业地产的价值。

公允价值是根据一个国家的标准会计实践对商业资产（和负债）进行评估，用于财务报告，通常用于评估销售、并购中的价值。国际财务报告准则基金会（IFRS 基金会）是一个非盈利的行业标准组织，定义了全球公认的会计准则，发布为IFRS 准则。IFRS 第 13 号准则（www.ifrs.org/issued-standards/list-of-standards/ifrs-13-fair-value-measurement/) 将公允价值定义为“在计量日期，市场参与者之间进行有序交易时，出售资产或转移负债所收到的价格（退出价格）”。

最后，市场价值是对公司在当前市场条件下价值的评定。市场价值是资产在市场上的估计价格，或者是投资界对股权所给予的价值——即第三方为获得企业或其他资产的股权或证券所支付的价格。

我们现在对价值这一术语在企业和其他资产所有权中的应用有了广泛的理解。但价值这个术语也可以具有一个语境意义，指示特定商业关系的重要性，如价值链和价值网络。增值（VA）关系是下一节的主题。

从商业关系的角度看待价值

从商业资产所有权的角度来看，价值的概念在语境中的应用是直接的。人们和企业通过投入时间、金钱和资源来提升其商业资产的价值，但企业也通过与供应商和其他合作伙伴的关系来获得价值。

从最广义的角度来看，所有外部合作伙伴提供产品或服务，以支持另一个实体的业务目标，尽管两个合作伙伴都能从这种关系中获得价值。但在这里，我们仍然需要仔细定义合作伙伴关系的类型，以了解每个合作伙伴提供的价值。例如，一家公司可能有供应商提供用于其产品的组件和材料，并将其交付给消费者。其他合作伙伴可能会转售或重新品牌化其他公司的产品。这些关系有多个变体，例如转售商、VA 转售商（VAR）和原始设备制造商（OEM）。

转售商就像零售商店，购买产品后再将其转售给客户。零售合作伙伴可以是传统的实体公司、在线转售商，或是两者的混合体。

VAR 是一种通过定制或服务增强其他公司产品价值的公司。例如，一家休闲车（RV）制造商通常从一个或多个主要的汽车和卡车制造商那里购买裸车底盘、发动机和轮胎。然后，它会添加车身和内部设备，使车辆适合露营。VAR 还可以提供围绕其他公司产品的服务，如安装和配置服务、咨询、故障排除、维修或客户支持。

OEM 公司通常采用其他公司的产品，并将其重新品牌化并以其公司名义销售原始产品。OEM 还可以提供类似于 VAR 类型业务关系的产品和服务扩展。不管怎样，OEM 都会采购主要制造商额外的权利，将其产品重新品牌化为自己的产品。

建立作为价值网络的商业关系

价值网络包括任何一组互联的组织或个人，他们以集成和协作的方式工作，以便整个团队受益。面向商业的价值网络帮助成员买卖产品、组织和分配工作以及共享信息。虽然有许多类型的价值网络关系，但它们都属于两个广泛的类别：内部或外部价值网络。

内部价值网络 包括组织内部的人们合作以实现共同或互补的目标。这些内部价值网络通常在已建立的业务流程或价值流的范围内工作。业务流程和价值流都描述了结构化的工作方法。

“业务流程”一词通常与传统的跨职能和官僚化的组织结构相关联。价值流的概念来源于精益生产和精益六西格玛方法，这些方法用于产品交付。本书的后续章节将详细介绍精益生产和价值流的相关内容。现在，可以将价值流理解为一系列与客户需求对接的活动，用以交付产品和服务。此外，精益生产是一种改进产品和信息流动的方式，旨在提升价值流的效率。

一个规模化多个但小型的敏捷导向团队的组织，通过集成、协调和同步的方式来开发和交付大型产品，另一个例子是内部价值网络。这些敏捷团队也可能采用精益产品开发概念，通常被称为精益敏捷方法论或框架。

外部价值网络描述了第三方之间的跨组织互动，这些第三方超出了主要商业实体的范围，但对其成功有所贡献。换句话说，外部价值网络在支持或从主要商业实体的目标中获益方面具有共同的利益。在这种情况下，外部价值网络包括代理商、商业伙伴、客户、顾问、产品用户、利益相关者、供应商以及参与增值关系的任何其他个人或实体。

内部或外部价值网络通过其关系、跨职能或面向价值流的流程，以及它们在企业中与产品和服务相关的具体角色创造价值。这些关系必须是互惠互利的——换句话说，所有在价值网络中的各方都应从他们的关系中获得价值。如果情况不是这样，网络就无法实现其目标和期望，关系通常会变得具有破坏性。在极端情况下，网络会解体，参与者也会退出他们的商业或雇佣关系。

此外，价值网络中的参与者必须履行各自的责任。无效的参与者会削弱整个网络，其他人则必须介入填补空缺——前提是这可能实现。另一方面，拥有价值网络的一个优势是，参与者可以提供资源、技能、经验和冗余，帮助较弱的环节赶上进度或克服他们的局限性。

本节结束了我们对价值网络的讨论。在下一节中，我们将探讨一个互补的概念——价值链。与将 VA 关系视为网络不同，价值链描述了一家公司为其产品和服务增加价值的活动。

将业务关系建立为价值链

价值链是指公司通过一系列过程或活动向其产品和服务增加价值的方式。价值链包括产品生命周期活动，涵盖了产品构思、设计、原材料接收以及通过更细化的生产过程增加附加值。价值链过程还包括推广产品、接收订单，然后将最终产品销售给消费者。

迈克尔·波特在他的书籍《竞争优势：创造与维持卓越表现》（1985 年）中首次提出了价值链这一术语。波特将增加价值和竞争优势的主要价值链活动描述为以下五个要素：

• 内部物流：接收、存储和处理原材料和库存。

• 运营：将原材料转化为成品。

• 外部物流：将产品和服务分发给客户。

• 市场营销与销售：包括广告、促销、定价策略，并管理所有销售渠道（线上、内部直销、外部直销、通过转售合作伙伴的间接销售）。

• 服务：帮助维持产品并提升消费者体验，包括客户支持、产品维护和修理、退款和换货。

价值链分析提供了一种利用价值链获得竞争优势的战略。价值链分析评估了将产品或服务的输入转化为特定客户类型所重视的输出所涉及的活动。价值链分析从识别创建产品所需的每一个生产步骤开始，然后寻找提高整体价值链效率的方法。

迈克尔·波特关于价值链管理（VCM）理论的观点支持了传统的使用商业流程、最佳实践、组织资产和人力资源（HR）来实现竞争优势，从而推动市场进一步增长的观点。迈克尔·波特明确指出，他的做法是实施一种基于活动的理论来推动竞争优势。

尽管他的观点听起来与精益开发的概念有些相似，但波特的理论与精益最初注重客户的导向相对立。波特提倡一种战略，即比竞争对手更便宜、更快速地生产和交付产品，而在他看来，这种做法自动带来新的客户和增长。然而，精益实践者认为，我们必须首先关注客户需求，然后再优化活动以交付客户想要的内容，否则我们将失去方向。

既然我们已经说明了这一点，让我们从客户的角度来探讨价值。

定义客户价值

客户价值是最终客户从产品或服务中获得的价值。在前一部分中，你了解到精益开发战略强调评估活动以增加价值，并消除那些没有增加价值的活动。

精益开发策略是有意义的，因为最终，客户是决定“价值”对他们意味着什么的唯一裁判。客户通过效用、质量和利益来感知价值。我们能够提供他们所需的东西，是客户满意度的决定性因素。

但是，客户价值是一个复杂的概念。如果所有客户都看重相同的事物，那该多好啊。在一个如此同质化的世界里，我们只需生产一种产品变种，并成为最有效率的生产商。当然，我们还需要在市场营销、销售、交付和支持等环节中具备竞争力。这样的市场支持了迈克尔·波特（Michael Porter）关于利用价值链创造竞争优势的观点。

但这并不是我们所处的世界。相反，客户有不同的预算和不同的需求，偏好不同的功能和特性。在传统的大规模生产模式中，市场营销和销售组织通过告知客户他们应该喜欢哪些产品和服务来影响客户行为。这一策略使生产商能够按照迈克尔·波特的指导改善价值链。

这种策略可能有效一段时间，但直到其他竞争者开始询问客户需求并提供更好的产品时才会受到挑战。因此，面向客户的价值交付策略必须不断演变。到了 1980 年代和 1990 年代，客户关系管理（CRM）和精益开发策略成为主流实践，重点调整产品开发和交付工作，以满足大众市场和盈利性细分市场的客户需求。

精益生产，也称为精益制造，是从丰田的运营模式中衍生出来的一种现代生产方法，这一模式被称为丰田方式和丰田生产系统（TPS）。精益这一术语并非源自丰田，而是由约翰·克拉夫奇克（John Krafcik）在 1988 年创造的，当时他正在研究管理学并在詹姆斯·W·沃马克（James P. Womack）的指导下进行研究。克拉夫奇克的研究是麻省理工学院（MIT）对汽车未来的 5 年研究的一部分。克拉夫奇克的研究提供了《改变世界的机器》（Womack、Jones、Roos；1991 年）一书中引用的大部分数据。但正是沃马克、琼斯和罗斯的书阐述了精益制造的概念，并引入了精益生产这一术语。

沃马克和丹尼尔·琼斯（Daniel Jones）定义的精益概念包含五个基本原则，概述如下：

• 精确地通过特定产品指定价值

• 确定每个产品的价值流

• 让价值流动不受阻碍

• 让客户从生产者那里拉动价值

• 追求完美（Womack 和 Jones，1996，第 10 页）

CRM 是一种以数据为中心的管理客户和潜在客户信息及互动的方法。具体来说，CRM 方法和软件工具利用数据分析技术来处理客户数据，以更好地了解客户与公司之间的历史，并改善客户关系。CRM 主要是一个面向市场营销的职能，支持其改善客户留存率并推动新销售增长的目标。

通过 CRM 和精益方法，组织可以利用工具来确定从客户角度看，什么是价值，并根据这些信息调整组织活动和资源以提供该价值。其他一些方法和工具也有助于识别客户对价值的感知——例如，市场营销和产品管理职能可能会组织焦点小组，开展调查来收集客户数据。反过来，这些数据有助于通过各种分析技术进行分析，诸如以下内容：

• 客户之声：用来描述捕捉客户期望、偏好和不满的过程的术语。

• 客户效用图：一张展示六个效用杠杆的地图，用于在各个买方体验周期的六个阶段中，为买方提供卓越的效用。

• Kano 模型：一种理解、分类和优先排序五种客户需求（或潜在特征）的方法，用于新产品和服务的开发。

• 客户旅程图：一种图示，展示客户与公司互动的各个步骤，无论是实体产品、在线体验、零售销售、服务，还是这些元素的组合。

• 同理心图：一种由用户体验（UX）设计师使用的方法，用于理解用户行为，并将发现结果以视觉形式传达给其他利益相关者，以提供对潜在用户的共同理解。

• 客户价值管理（CVM）：一种评估组织产品和服务所提供的感知价值的方法。价值通过对比利益、功能、性能与价格、成本和利润率来评估。

本小节总结了我们关于价值的多种定义，并探讨了为什么产品和服务必须始终从客户角度交付价值。我们还了解了 CRM 方法和工具结合精益实践如何帮助我们发现并向客户交付价值。但是，企业如何知道自己是否拥有一个可行的价值主张呢？这将是下一节的讨论内容。

开发价值主张

Michael J. Lanning 在其与麦肯锡公司合作时，提出了价值主张这一术语。他的工作开创了在制定公司战略、目标和商业能力时，根据客户需求进行调整的概念。Lanning 在其著作《交付有利可图的价值：加速增长、创造财富并重新发现商业核心的革命性框架》（Lanning，1998 年）中阐述了这些概念。

Lanning 从客户体验的角度看待价值，因此将价值主张定义如下：

组织在某一时间段内为一群目标客户提供的体验组合，包括价格，作为客户购买/使用并按组织要求进行的回报，而不是选择某些竞争的替代方案。

换句话说，价值主张这个术语暗示了一种明确的关系，在这种关系中，目标客户通过组织提供的产品和服务获得体验，尽管这些体验是有限时效性的（即，价值随时间变化）。

该术语还设定了期望，即客户必须购买、使用并按照交付组织的要求做某些事情，而不是选择一个竞争选项。竞争选项不仅限于客户购买竞争对手的产品或服务。客户可能选择什么都不做，或者用他们内部资源创造所需的体验。

还需要注意的是，价值主张的定义并没有直接涉及它作为市场营销和销售沟通工具的使用，尽管许多人从这个角度来看待该术语的相关性。客户看重的是他们通过使用组织的产品和服务获得的体验，而不是获得的产品功能。因此，关键问题是确保组织协同工作，提供所需的体验，而不仅仅是宣传可能相关或可能不相关的功能或特性。

不幸的是，价值主张这个术语通常被市场营销和销售专业人士在有限的背景下使用，作为如何竞争性地定位商业产品或服务的陈述。但这种局限的关注点忽视了 Lanning 主要工作的意义——即通过将组织与其企业战略对齐，来提供盈利的价值。从这个角度来看，组织中的每个人都在传递盈利价值中扮演着角色。

这句话并不意味着市场营销人员不应当使用价值主张来恰当地传达组织的价值，或者销售人员不应当使用价值主张来确保他们将合适的体验卖给合适的客户。然而，从比喻的角度来看，组织必须首先解决两个问题，如下所述：

• 谁在掌舵？

• 其他成员上船了吗？

本书后续章节介绍了价值流映射技术，以识别并消除组织价值流活动中的所有浪费。但价值流团队如何知道他们需要将活动与哪些结果对齐，从价值流分析（VA）的角度来看呢？这正是通过回答五个简单问题来构建引人注目的价值主张的正确目标。

通过五个问题来对齐商业战略

价值主张回答了五个关于实体如何计划交付价值的关键问题。这些问题列举如下：

• 谁或什么是目标市场客户？

• 价值主张的规划和执行生命周期的视野是什么？

• 我们希望这些目标市场实体为我们交付的体验做些什么？

• 这些客户有哪些竞争性替代方案可以获得期望的体验？

• 假设客户按照我们的要求操作，他们获得的体验（包括价格）与竞争性替代方案相比如何？

进一步说明，兰宁明确指出，结果体验必须是具体的、可操作的和可比较的。他还指出，成功的价值主张是权衡的结果，因为某些体验不如竞争对手的替代方案。因此，重要的是优化整体体验（兰宁，1998，第 62 页）。

为组织创建一个愿景

价值主张作为战略性文件，有助于集中并整合整个业务，以传达其目的。价值主张是领导层作出的选择，与他们的组织战略、目标和使命一致。最重要的是，价值主张表达了对其目标市场客户最有利的愿景。

在这种价值背景下，执行领导层并不负责决定组织必须为客户提供哪些产品和服务，甚至不负责决定如何创建和交付这些产品和服务。这样做是围绕领导层希望做什么的内部导向产品策略的例子。

然而，答案并不是反过来问客户你们认为组织的价值主张应该是什么。在这种情况下，追求客户意见很快会变得无效，因为有许多不同细分市场的客户具有不同的体验偏好，而追求特定的客户偏好可能会错误地使组织偏离为更广泛或更有利可图的目标市场客户增加价值的方向。

稍后，您将学习如何识别和优先考虑客户需求，作为产品待办事项中的可操作工作项。目前，理解一个组织必须最终将注意力转向开发具体的增值特性和功能至关重要，但在组织建立愿景并能够通过价值主张完全表达它之前，开始这种努力也是危险的。

成功的领导者往往具有高度的创造力，并且经常在客户意识到他们需要某种产品之前，便能为企业设想并表达一个愿景。典型的例子包括史蒂夫·乔布斯和比尔·盖茨，他们看到了将计算机的力量带给大众的机会，分别成立了苹果和微软。亚马逊创始人杰夫·贝佐斯则设想了一个在线零售书店，改变了读者评审和购买书籍的方式。最终，贝佐斯彻底改变了客户的零售体验。一旦他成功找到了书籍的在线零售模式，他就设想将这一模式扩展到几乎所有商品的销售中，并在此过程中成为全球最富有的人。

埃隆·马斯克是另一位商业领袖，他运用创意和智慧定义了多个市场机会。例如，他成立了特斯拉公司以大规模生产电动汽车，成立了无聊公司来修建地下隧道以改善拥挤地区的交通，成立了SpaceX以建造可以垂直降落的可回收火箭。

需要注意的是，埃隆·马斯克在这个例子中并没有试图将所有这些独特的价值主张合并成一个公司。拥有多个价值主张的组织应在不同的产品线之间建立足够的分隔，以避免让客户感到困惑。

组织可以选择通过部门、分部或公司来区分产品线。产品线的分离程度主要取决于它们的价值主张之间的差异。通过价值主张来恰当地区分产品的原则适用于数字产品和实体产品。

提供价值

在上一节中你已经学到，成功的首席执行官具有创造力，并且通常会在潜在客户意识到需求之前，就已经为新产品构思出创意。然而，提出一个创意仅仅是开始。组织的领导者们通过回答之前提到的五个问题，共同完善了最初的愿景。

在这个过程中，领导者会在价值主张文件中深入讨论并阐明他们共同的愿景。最终，价值主张定义了组织所处的业务领域、潜在客户是谁，以及企业必须提供哪些类型的体验以赢得客户的支持。

迈克尔·J·兰宁的书名是提供有利可图的价值。只有当组织获得足够的投资回报率（ROI）以证明投资的合理性时，它才得以生存。如果没有足够的资金，企业就无法持续运营，因此盈利目标显而易见。剩下的部分，提供价值，同样至关重要。交付价值的能力是实现盈利的关键。

在价值主张的背景下，Lanning 提供了一套扩展的价值和价值交付的定义，如下所示（Lanning，1998 年，第 316 页）：

• 价值：客户在某些结果体验与某些替代方案相比所感知到的净可取性——客户应该愿意为此支付的费用

• 价值交付：选择、提供和传达一些结果体验，包括价格

• 价值交付链：与业务相关的实体——包括供应商、中介、主要实体、客户和离线实体——被理解为相互交付价值，并作为一个相互连接的关系集

• 价值交付聚焦：从选择、提供和传达一组期望的结果体验的角度理解业务，以吸引潜在客户

• 价值交付框架：整个主值交付系统（VDS）及其支持系统的相关问题和对应的行动，在价值交付链的背景下进行理解

• 价值交付选项识别：探索市场空间，以发现与传统市场细分相比，哪些主要的 VDS（价值交付系统）是可行的

• 价值交付系统（VDS）：一个端到端（E2E）的商业系统，通过协作和作为一个共同体的形式，交付完整的价值主张

本节总结了我们关于价值主张的讨论。在本章结束之前，你将了解来自敏捷、精益、价值流图（VSM）和 DevOps 背景下的价值观念。但在深入这些主题之前，我们需要快速回顾一下与创造价值相关的传统商业概念。这个主题将在下一节中探讨。

创建价值

最终，本书的主题是价值创造以及一个组织在需求、效率和持续性方面创造价值的能力。最重要的是，我们为交付价值所作的努力必须与客户对什么能为他们的体验增加价值的看法一致，这些体验包括我们的组织、产品和服务。

“价值创造”这一术语通常赋予的定义相对广泛，我们需要理解人们在使用该术语时的具体含义。最简单的表述是，价值创造是任何能够创造比其输入更有价值的输出的过程或活动。

输入-转化-输出过程的展示（即输入-过程-输出（IPO）模型）包括一个功能图，展示了输入、输出和所需的处理任务，这些任务将输入转化为输出。请参见下图以示范：

图 1.3 – IPO 模型示例

输入代表来自外部来源的信息和材料流入一个过程。处理步骤包括所有需要的活动（步骤或任务），将输入转化为有价值的东西。输出是经过处理的、流出转化过程的增强数据和材料。

图 1.3 中显示的 IPO 图形展示了增值活动。增值过程增加了商品和服务的价值，并通过延伸改进了企业的价值。只有当客户足够渴望这些产出时，价值转化过程才能发挥作用。客户创造、交付和获取的价值驱动了股东的价值。

从财务或管理会计的角度看，我们通过将输入转化为产品、服务和流程的产出，来推动组织价值链上的货币价值。然而，对于在组织内部增加价值的事物，财务定义的创建价值是有限的，不能完全捕捉到。同样重要的是，人们的无休止和持续创新、劳动和创意，以及品牌营销。

作为精益敏捷和 DevOps 从业者，您负责无休止和持续创新的努力，同时提供劳动力和创意，以从数字增强的产品和服务中产生价值。此外，产品管理和市场营销职能负责品牌营销作为他们需求创造的一部分（即促进产品的价值主张，以创建品牌知名度，从而引起客户需求并获取产品）。

记住这个简单的 IPO 模型，因为它形成了查看大多数价值流活动的基本图形方法。主要区别在于我们将分解过程函数，显示所有相关活动及其增值相互关系。

在前一节关于价值主张的部分，您了解到我们客户基于体验的价值感知随时间而变化。因此，价值创造取决于组织能够按需、高效和持续地创造价值的能力。换句话说，组织在不断变化的压力下，即使是在最佳情况下，变革也是具有挑战性的。

宏观层面上的变革发生在组织定义新的业务战略和可能有利可图的价值主张时。这种类型的变革更为艰难，特别是当组织需要从其传统的等级制度和官僚体制组织结构演变时。

这种变革不可能仅靠法规来实现，因为这种规模的业务转型战略如果没有高管支持和领导、适当的计划以及受控的推广，就会失败。我们暂时搁置这个话题，并在第六章中重新讨论它，启动 VSM 计划（VSM 步骤 1-3）。

在敏捷的价值观和原则的背景下，变化在微观层面上非常频繁，每次开发迭代都会发生。这种频繁的变化发生是因为小型的、自治的、自给自足的团队会自动自组织，以在计划的时间范围内交付可预期的增量价值——通常为 1 到 4 周。

此外，在每次迭代结束时，团队会进行回顾活动，评估改进的领域，这些改进应该从下一个迭代开始。以敏捷方式运作的团队实施如 Scrum 等过程，通过变革在重复且可控的方式下交付以客户为中心的价值。

接下来的部分将描述敏捷和精益开发概念的核心价值观和原则。

从精益-敏捷的角度看待价值

精益-敏捷实践将《敏捷软件开发宣言》（通常称为敏捷宣言）中概述的价值观和原则与最初由丰田开发、后由约翰·克拉夫奇克（Krafcik, 1988）、詹姆斯·沃马克（Womack）、丹尼尔·琼斯（Jones, 1990, 2013）以及玛丽和汤姆·波彭迪克（Poppendieck, 2003）进一步阐述的精益开发实践相结合。

注意

我之前的书籍《在现代企业中扩展 Scrum》提供了关于精益-敏捷概念和实践的更详细内容。本节提供了一个温和的介绍，足以理解本书后续章节中描述的精益-敏捷实践的应用。

理解敏捷的价值观和原则

2001 年，17 位软件开发者聚集在犹他州的一个度假村，讨论他们的开发观点，看是否存在共同的立场。尽管许多参与者是竞争对手或归属于不同的软件开发方法论，但他们在价值观和原则上找到了共同点。吉姆·海史密斯描述他们的成果为“软件开发中的模糊的价值和文化”（agilemanifesto.org/history.html）。

敏捷宣言确立了 4 个价值观和 12 条原则，阐明了敏捷软件开发方法。

敏捷宣言的核心要素是其价值观，具体表述如下：

我们通过实践开发软件并帮助他人开发，发现了更好的开发方式。通过这项工作，我们逐渐重视：

• 个人与互动重于过程与工具

• 工作软件重于全面文档

• 客户协作重于合同谈判

• 响应变化重于遵循计划

也就是说，虽然右侧的内容有价值，但我们更重视左侧的内容。

肯特·贝克 詹姆斯·格雷宁 罗伯特·C·马丁

迈克·比德尔 吉姆·海史密斯 史蒂夫·梅洛尔

阿里·范·本内克姆 安德鲁·亨特 肯·施瓦贝尔

阿利斯泰尔·科克本 朗·杰弗里斯 杰夫·萨瑟兰

沃德·坎宁安 乔恩·凯恩 戴夫·托马斯

Martin Fowler Brian Marick

《敏捷软件开发宣言》的签署人之一是 Jim Highsmith。他建立并维护了一个包含该事件及与会者发现的详细信息的网站。相关页面的统一资源定位符（URLs）如下所示：

• 敏捷软件开发宣言：agilemanifesto.org/

• 敏捷宣言背后的原则：agilemanifesto.org/principles.html

• 历史：敏捷宣言：agilemanifesto.org/history.html

这些软件开发人员代表或使用了轻量级的软件开发实践，以避免传统的计划驱动和线性顺序 SDLC 模型（即瀑布模型）的陷阱。由于他们使用了竞争性的方法论，他们未能在各自的 SDLC 实践中找到共同点，而是通过书面形式的共享价值观和原则找到了共同点。

在现代背景下，基于敏捷的开发实践具有以下共同点：

• 迭代和频繁的开发周期。

• 客户中心价值的增量发布。

• 小型、自治、独立的团队，这些团队灵活、适应性强，能够自我组织，处理任何相关的工作（即，我们不期待软件开发团队执行市场营销或销售相关的工作）。

• 与客户的频繁互动，以展示新的增量价值并获取他们的反馈。

• 开发人员需要有自由从实验中学习，知道他们可能会失败，但也知道要在短期开发周期中将失败控制在最小范围内。

• 定期回顾以评估改进的领域，并实施行动计划以在下一个迭代中落实这些改进。

• 技术卓越和良好的设计增强了团队的能力和敏捷性。

• 团队成员之间的多样性和尊重是团队进化和持续成功的关键因素。

除了这些简单的原则外，软件开发团队可以自由选择他们喜欢的方法和工具。17 名参与者代表了至少 7 种轻量级的软件开发方法论。在这 7 种方法中，Scrum 后来成为了实现小团队敏捷的事实标准。

本节介绍了敏捷方法的基本概念。接下来我们将介绍精益开发的概念，特别是它在现代敏捷软件开发中的相关性。

回顾精益开发的基础。

如前文所述，定义客户价值，精益开发的概念最初在丰田发展起来。丰田并不吝于与他们的价值链合作伙伴分享这些理念，后来—在更大范围内—通过推广一本名为丰田方式 2001的小册子，将这些理念传播到跨行业的制造公司。他们致力于帮助其价值链合作伙伴，因为这些努力为提升其价值流带来了回报。

2004 年，Jeffrey Liker 通过 14 条基本管理原则总结了他对丰田方式的看法（Liker，2004）。我在我的书《跨现代企业的规模化 Scrum》中也提供了这些原则的例子。

作为简要介绍，以下列表包含了每个管理原则的总结：

• 精益是一种长期的管理哲学。

• 关注建立持续的流程，以便快速暴露问题并消除浪费。

• 根据需求，采用拉动式方法进行订单和物料输入。

• 消除一切形式的批处理流程。

• 第一次就把事情做对，并在问题出现时立即停止生产。

• 在你的价值流中标准化任务和流程。

• 使用看板等可视化控制，避免问题被隐藏。

• 只使用经过充分测试且可靠的技术，由你的团队选择，以支持他们的流程。

• 培养未来的领导者，他们已经理解工作和组织哲学，并能将其传授给他人。

• 培养卓越的团队和人才。

• 尊重并帮助改善你的扩展网络中的合作伙伴和供应商。

• 实践现场管理—亲自去了解组织中正在发生的事情。

• 慢慢做出决策，通过共识，只有在经过尽职调查和充分考虑后才能做出决定。

• 通过反思和持续改进，成为一个学习型组织。

由于本书讨论的是通过精益敏捷实践提升组织在数字经济中的竞争力，接下来我们将讨论精益软件开发实践。

实施精益软件开发实践

Mary Poppendieck 和 Tom Poppendieck 在 2003 年出版的同名书籍中创造了精益软件开发这一术语。这本书是首次广泛推广将传统精益开发实践应用于软件开发的例子。除了采用和应用 7 条精益原则到软件开发中，Poppendieck 还识别了 22 种精益思维工具，有助于将精益应用于各种敏捷实践。

精益原则包括以下内容：

• 消除浪费：从活动中剔除任何不为客户增值的部分。

• 加强学习：投入时间和资源进行学习和实验，提升技能、技术和流程。

• 尽可能晚地做出决定，保持选择的灵活性。

• 尽可能快地交付，通过集成和自动化软件开发生命周期（SDLC）和运营支持流程。

• 赋能团队：让从事工作的人员充分发挥他们的决策权，因为他们是最了解工作、最接近工作的人员。

• 建立完整性：构建具有一致架构、可用性和适用性的可维护、可适应和可扩展的软件系统。

• 看到全貌：避免专业化的做法，因为专家往往会围绕他们的特定目标和兴趣来优化系统。

精益和精益软件开发的学科，以及 Poppendiecks 推荐的精益工具过于广泛，无法在本章中深入探讨。我们将在本书的后续章节中再次讨论这些话题。但现在，让我们继续介绍价值流的概念、它们的目的、类型，以及我们如何定义它们。

通过价值流交付价值

詹姆斯·沃马克、丹尼尔·琼斯和丹尼尔·罗斯通常被认为是定义价值流一词的人，出自他们的书《改变世界的机器》（沃马克、琼斯、罗斯；1990 年）。沃马克确实在他后来的书籍中讨论了价值流，如《精益思想》（沃马克；1996 年、2003 年）和《看见整个价值流》（沃马克、琼斯；2003 年）。然而，詹姆斯·马丁是第一个在他的书《伟大的转型：使用企业工程的七项学科对齐人员、技术和战略》（马丁，1995 年）中详细定义价值流概念的人。

很容易将价值流的概念与精益中的价值流映射概念联系起来，但这是一个错误的关联。马丁在他的书中简要介绍了精益制造的概念，但他将价值流与精益制造的关联，主要用于围绕客户价值重新设计工作流程（马丁，1995，第 102 页）。相比之下，价值流映射是一种评估信息和物料流动的可视化技术。在接下来的子章节中，我们会进一步讨论价值流映射。

马丁将价值流定义为“为‘客户’创造结果的端到端活动集合，客户可以是最终客户，也可以是价值流的内部‘最终用户’”。马丁还指出，价值流必须有一个明确的目标来满足或取悦客户。马丁将价值流作为一种重新设计业务流程的方法，目的是通过以最“简单、直接且专注”的方式开发产品来支持客户需求。

马丁在撰写他的书时，业务流程再造（BPR）是一个主流概念，IT 组织与职能和跨职能的业务组织合作，精简并自动化关键的业务流程。马丁敏锐地观察到，业务流程传统上是通过内部需求驱动的连续变革而演化的，而不是由客户需求推动的。因此，许多业务流程都臃肿、低效，且与客户需求无关。

马丁将他的价值流概念引入为一种端到端（E2E）重新设计的业务流程，从活动或任务层面来创造更好的流动性。马丁指出，许多业务系统的发展是为了支持当时存在的业务流程，而这些基础流程往往是为了支持可疑的议程和目标而发展起来的。

更好的方法是消除业务流程的概念，转而让组织重新评估其企业为一个价值流的集合，而这些价值流很可能都需要重新设计。这种方法确定了客户所重视的内容，并评估了组织中提供这些价值的活动集合（即，价值流）。下一步是简化已识别的价值流。只有在这之后，组织才应考虑开发信息系统和自动化来支持它们新形成的价值流。

在现代精益敏捷和 DevOps 环境中，我们可以更快地行动，但精益敏捷概念是在马丁的书出版后逐渐发展起来的。如今，价值流识别和价值流映射是精益敏捷实践者工具包中的关键组成部分。

识别价值流

价值流是更广泛且集成的业务系统中的组成过程，描述了利益相关者——无论是内部还是外部客户——如何从组织中获得价值。一个业务价值流包括一系列步骤或活动，必要时提供客户在更基础层面上所期望的产品、服务和体验。

价值流可以支持产品开发和交付活动以及任何其他面向客户的服务。尽管面向开发的价值流可以直接为客户或转售伙伴提供产品和服务，但更典型的场景是它们将产品和服务交付给运营或面向客户的价值流。那些不增加价值的步骤在客户眼中是浪费——换句话说，客户不想为那些增加浪费而没有增加价值的内容付费。

我们容易认为客户不会知道这些多余的活动，但在竞争激烈的市场中，关注并提供更好的以客户为中心的价值的竞争对手很快会揭露这些问题。

兰宁提出的将价值评估为客户期望的体验的概念为我们定义价值流提供了一个模型。让我们快速看一下客户通常从他们的产品、服务和解决方案提供商那里想要的内容，具体列举如下：

• 开放、可用、易于访问的知识：

  a. 关于产品和服务

  b. 比较信息——来自公司、可信代表和行业专家

  c. 产品和定价信息

  d. 采购——如何以及在何处获取产品和服务

• 简化且可能是实时的订单输入

• 按照期望的质量、特性、功能和成本开发的产品

• 推销产品升级和服务，以使客户体验更加优越

• 履行—按客户偏好的方式和时间交付

• 客户支持—按需提供，能够在客户需要时解答他们的问题并解决他们可能遇到的问题

• 持续的产品维护和增强

这个列表并不完整，但为这次讨论提供了一个很好的起点。各个组织部门协作定义和创建价值流，尽管特定部门可能主导某些价值流的定义，例如，产品管理通常负责定义目标市场和客户的相关需求。相对而言，营销部门则定义创建客户认知所需的价值流。

价值流映射

在上一节中，你了解到 James Martin 对价值流的定义进行了改进，并且精益的价值流映射概念是独立的。Martin 使用价值流这个术语来表达围绕客户价值重新设计工作流的需求。

价值流图，也叫做物料和信息流图，是一种精益方法，用于绘制和评估产品或服务生命周期中当前的现状和期望的未来状态。换句话说，价值流图为记录和评估工作流提供了一个视觉辅助工具，从最初的请求到开发和交付，直到产品或服务到达客户。

有趣的是，信息和物料流映射的概念早于精益，最早可以追溯到 Charles E. Knoeppel 于 1918 年所著的书《Installing Efficiency Methods》。今天，价值流映射更多地与精益制造和精益软件开发实践相关联。

丰田在丰田生产方式中将价值流映射作为标准实践。Mike Rother 和 John Shook 研究了丰田，并出版了关于他们在这一主题上发现的书籍，名为《Learning to See: Value Stream Mapping to Add Value and Eliminate Muda》。之后，Mary 和 Tom Poppendieck 在他们同名的书中介绍了精益软件开发。该书使价值流映射成为精益社区中的主流技术。

以下图表展示了当前和未来状态的价值流图示例。我们在此不再深入探讨价值流映射的细节，而是将讨论推迟到第七章，映射当前状态（VSM 第 4 步）：

图 1.4 – 当前/未来价值流图

本节总结了精益敏捷（Lean-Agile）概念部分。接下来的章节将介绍价值流管理（VSM）概念、方法和工具，并介绍价值流图（Value Stream Mapping）技术及其如何用来识别价值流的现状以及一个或多个期望的未来状态，以实现价值改进。在此过程中，你将发现面向开发的价值流为面向运营的价值流提供支持。

理解 VSM

本书的第二节，实施价值流管理（VSM）——改善 IT 价值流，提供了与 VSM 相关的方法和工具的全面指导，并介绍了一些领先的 VSM 软件产品。我们还将在第六章中介绍基本的 VSM 概念，启动 VSM 计划（VSM 步骤 1-3）。在我们深入这些主题之前，本节旨在解释 VSM 在帮助组织实现价值方面的相关性。

基于精益基础

如果你只阅读近期的 VSM 文献，可能会认为 VSM 是对敏捷和 DevOps 实践的一种增强，且仅限于改善与 IT 相关的价值流。那是一个误解，因为这些实践源自精益生产和精益开发策略，这些策略可以追溯到丰田生产方式（TPS）演变的早期。日本工业工程师大野耐一和丰田英二自 1948 年和 1975 年起帮助定义了这些实践。丰田公司保持并持续完善其精益实践，作为丰田生产方式（The Toyota Way）的一部分。

丰田的精益生产制造和精益生产开发实践创造了显著的竞争优势，世界其他地区也开始注意到这一点。到 1979 年，在 James P. Womack 博士的指导下，麻省理工学院（MIT）启动了一个多年的国际汽车项目（IMVP）研究计划，旨在研究全球汽车价值链和精益流程。

1991 年，James P. Womack、Daniel T. Jones 和 Daniel Roos 出版了他们的研究成果，书名为改变世界的机器：精益生产的故事，这本书帮助将精益生产推向全球主流。虽然他们的工作重点是汽车行业，但在书的后记中，作者指出，他们完全预期精益生产将成为 21 世纪的全球标准生产系统。

企业实体必须采用精益生产流程，以便有效竞争，同时利用 IT 提供与数字经济相关的产品。软件行业很快意识到实施精益生产概念的优势。带头的是 Mary 和 Tom Poppendieck，他们写了那本著名的书（至少在敏捷社区内），名为精益软件开发：敏捷工具包。

想要深入了解精益生产和精益软件开发的朋友们，可以阅读我之前的书籍，《在现代企业中扩展 Scrum》。具体来说，第五章，通过 DevOps 管道推动商业价值，介绍了精益生产的概念，而第六章，启动 VSM 倡议（VSM 步骤 1-3）则介绍了软件开发中的精益实践。

VSM 是关于改善 IT 组织的精益价值流，但并不取代敏捷的价值、原则和实践。当前 IT 的趋势是将精益与敏捷实践作为一项综合战略，VSM 是将它们连接在一起的粘合剂。让我们看看为什么。

基于敏捷方法

VSM 不能仅仅局限于安装一种新的敏捷软件开发学科。这种策略可能会有些过头。例如，Dave Thomas 写了一篇重要的文章，标题为敏捷已经死了（敏捷万岁）（在pragdave.me/blog/2014/03/04/time-to-kill-agile.html）中，他提出我们已经过度复杂化了敏捷软件交付的概念。他说得并不错误。

如果我们接受 Dave Thomas 的前提，认为我们已经把敏捷软件交付做得太复杂，那么 VSM 所增加的额外开销和复杂性提供了什么价值呢？这是一个好问题，接下来我们将更深入地探讨 VSM 概念和流程的起源，以及它们如何影响 IT 价值交付组织。

定义 VSM 的概念和流程

VSM这一术语并非最初来源于 IT 相关的缩略语。例如，Peter Hines 等人在他们的书籍《价值流管理：供应链中的战略与卓越》（Hines 等，2000 年）中使用了这一术语。该书记录了一个研究项目，涉及近 20 家制造、零售和服务公司。该研究由精益企业研究中心（LERC）进行，目的是应用精益生产概念，理解供应链环境中的价值和浪费。

该综合企业的更广泛目标是改善、加快和持续推动跨供应链的开发活动，主要集中在汽车、电子和快速消费品市场。作者使用VSM这一术语来传达他们的研究发现，即精益企业必须安装并管理长久的项目，以持续主动地减少供应链价值流中的浪费（Kaizen）。

在现代背景下，VSM 是一种精益商业实践，旨在提高软件价值交付和 IT 资源的高效利用。通过采用精益软件开发的概念，VSM 帮助 IT 组织提升向内外部客户传递价值的流动性。

现代 VSM 的背景也集中在使用软件工具和集成平台来改进 DevOps 管道流程。然而，采用精益软件开发实践的组织，可以在不使用 VSM 工具的情况下实现许多精益生产改进。始终记住——方法优先于工具！

类似于 DevOps 管道如何集成和自动化 IT 组织的开发与运维（开发与运维）流程，VSM 工具帮助集成和自动化精益价值流改进活动。现代 VSM 工具还提供直接捕捉度量和分析数据的功能，以指导改进选项。现代 VSM 工具帮助集成和自动化价值流映射、测量、监控和分析活动，跨 DevOps 管道进行。它们还支持改进所有组织的价值流。

然而，在利用工具之前，我们需要基于经过验证的 VSM 方法来建立我们的基础。

先学方法，再学工具。

Don Tapping、Tom Luyster 和 Tom Shuker 在他们的书《价值流管理：规划、映射和维持精益改进的八个步骤（创建完整的精益转型系统！）》（Tapping, Luyster, and Shuker, 2003）中提出了一种严格的 VSM 方法论。书中将 VSM 描述为一种以数据为中心、分析性的方式，用于规划和连接价值流活动。

Tapping、Luyster 和 Shuker 的书籍旨在简化基于需求的拉动、流动和生产平衡等精益开发概念，作为一个八步流程，以帮助加速、协调和维持精益开发实践，他们称之为VSM。在后来的书籍中，Tapping 和 Luyster 将他们的 VSM 概念应用于所有组织的价值流，如制造业、客户服务、工程、应付账款，当然还有——IT。

Don Tapping 和 Tom Luyster 都非常慷慨地允许我们将他们的八步 VSM 方法作为本书的基础 VSM 方法。然而，从第六章，启动 VSM 计划（VSM 步骤 1-3），到第十章，改进精益-敏捷价值交付周期（VSM 步骤 7 和 8），本书将他们的 VSM 方法应用于改进基于敏捷团队的 CI/CD 概念和工具的流程。

他们的八个 VSM 步骤如下：

1. 致力于精益。

2. 选择一个价值流。

3. 学习精益。

4. 制定当前状态图。

5. 确定精益度量指标。

6. 制定未来状态图。

7. 制定 Kaizen 计划。

8. 实施 Kaizen 计划。

请注意，Tapping 和 Luyster 的八步 VSM 过程并未明确指出 IT 实践——因为 IT 只是精益企业中众多价值流中的一个。另一方面，正如前面所提到的，IT 是一个关键的面向开发的价值流，支持几乎所有其他组织的价值流，尤其是在数字经济中。

本书的核心观点是，IT 产品需求和产品待办事项可以来自组织内的任何价值流，有些支持内部客户需求，而另一些则支持外部客户需求。同样，某些 IT 开发团队可能在多团队敏捷开发环境中支持单独的内部或外部价值流。然而，VSM 的基础精益改进概念是普遍适用的。

第六章，启动 VSM 计划（VSM 步骤 1-3） 包含了每个八个过程步骤的详细描述，这是实施组织范围精益实践的一般方法，包括 IT。但在离开本节之前，让我们快速看看 IT 行业目前如何看待 VSM。

在 IT 中实施 VSM

第六章，启动 VSM 计划（VSM 步骤 1-3） 解释了如何在绘制当前和理想未来状态之前识别价值流。识别价值流是两项任务中更具挑战性且更为关键的，因为一切与精益改进相关的工作都始于此。

传统上，软件开发团队认为将功能性和非功能性需求实例化为软件功能和特性。然而，在精益/VSM 模型中，开发和运维团队专注于改进活动，以实现持续的客户价值流。

在作为价值流运营的软件开发团队中，客户需求不会消失。功能性和非功能性需求、修复 bug 以及解决技术债务，都成为面向开发的价值流的输入。输出是开发的功能和能力。这些是我们在讨论第六章，启动 VSM 计划（VSM 步骤 1-3）时需要牢记的重要概念。

在现代背景下，VSM 实施了帮助组织通过优化价值流中的工作流程来增加其对客户的价值交付的方法和工具。此外，VSM 通常采用软件技术来集成工具套件，从而形成强大的 VSM 平台 (VSMPs)。

行业领先的 VSMP 供应商之一，Plutora，在其名为 价值流管理平台（见 www.plutora.com/）的文章中列出了九个关键的 VSMP 能力，帮助组织实现其软件目标，如下所示：

• 工具集成与互操作性

• 通用数据模型

• 绘制人员、过程和数据

• 治理和合规性

• 价值流 关键绩效指标 (KPI) 数据采集和衡量

• 数据分析与分析

• 仪表板和可视化

• 财务和预算

在本书的第二章，实施价值流管理（VSM）中，你将学习这些 VSM 能力如何帮助组织改善其价值流。此外，你还将了解实施这些能力的基本方法。但由于这是本书的主要内容，我们首先来看一下行业分析师如何评估这一新兴领域在 IT 中的重要性。

VSM 的增长前景

VSM 应用于软件开发实践，尤其是 VSMPS，均被视为新兴概念。然而，多个领先的 IT 行业分析机构，如Forrester Research, Inc. 和 Gartner, Inc.，现在都认为 VSM 是一个至关重要的需求，并且是一个呈指数增长的趋势。

例如，Forrester 定期发布Forrester Wave™关于 VSM 的报告，对领先的 VSM 供应商进行评分和加权评估。最新版本的Forrester Wave™：价值流管理解决方案，2020 年第三季度提供了对 11 家领先 VSM 供应商的评估。

同样，Gartner 关注 VSM 行业，并最近发布了题为[Gartner] 预测 2021：价值流将定义 DevOps 的未来的报告。Gartner 指出：为了加速开发并实现客户价值的持续交付，组织需要在其敏捷和 DevOps 实践中迈向下一个阶段。I&O 领导者和应用领导者必须专注于价值流管理，以最大化流动性、提高交付效率并推动创新。

在报告中，Gartner 继续列出其关于 VSM 的战略规划假设，如下所示：

• 到 2023 年，70%的组织将使用价值流管理来改善 DevOps 管道中的流程，从而加速客户价值的交付。

• 到 2023 年，用于简化应用交付的价值流交付平台的使用将从 10%增长至 40%。

• 到 2023 年，60%的受监管行业组织将在其 DevOps 工具链中集成持续合规自动化，至少提高 20%的交付周期。

• 到 2025 年，60%的 I&O 领导者将实施混沌工程，以增加弹性和提升价值流的速度，提高系统可用性 10%。

• 到 2025 年，20%的企业将超越 SRE，通过增加 IT 弹性角色来提高产品团队与传统灾备之间的弹性态势。

(Gartner, 预测 2021：价值流将定义 DevOps 的未来，Daniel Betts，Chris Saunderson，Ron Blair，Manjunath Bhat，Jim Scheibmeir，Hassan Ennaciri，2020 年 10 月 5 日)

VSM 似乎正在不断增长并且有望持续存在。现在，让我们快速了解 VSM 如何与 DevOps 实践互补。

理解 DevOps 在交付价值中的作用

在这一点上，你应该对“价值”一词在精益敏捷和 VSM 实践中的含义有了相当清晰的理解。在本节中，我们将探讨 DevOps 如何支持价值的交付。我们将从快速介绍 DevOps 背后的基本概念开始，了解它如何帮助实现敏捷的某些价值和原则。

在 IT 中交付价值

成熟的 IT 组织通过落实《敏捷软件开发宣言》中的价值观和原则，来提升其对客户的关注、交付速度和效率。组织不需要整合或自动化其基于敏捷的 SDLC 和面向运营的流程即可实现显著的收益。另一方面，那些整合了这些流程的组织能够迅速加快交付新价值的速度。

此外，IT 组织通过改善开发与运营之间的沟通与整合，获得了更显著的收益。运营反馈帮助开发团队创造出更具 VA、可持续性和更高质量的产品。合作还帮助开发团队部署更易于部署、配置、安全以及在必要时回滚的产品。

将 DevOps 看作是 IT 职能的重新工程化并没有错。重新工程化的程度取决于 IT 组织当前的状态。仍在采用传统瀑布型做法的组织需要对其流程和文化进行比采用基于敏捷的方法（如Scrum 或 极限编程 (XP)) 的组织更大幅度的改变。基于敏捷的方法论已经从实践角度重新设计了传统的 SDLC 过程，将其从线性顺序开发生命周期转变为迭代和增量的开发周期。

乍一看，瀑布和敏捷的各项活动似乎有些相似。例如，两种方法都包括以下类型的工作：

• 计划

• 需求收集和分析

• 设计与架构

• 开发

• 测试

• 客户评审与接受

• 产品发布与部署

主要的区别在于，瀑布模型将这些活动视为单一项目中的线性顺序和计划驱动的过程。传统模型延长了交付先前确定的价值的总体周期，这往往会导致在发现和修复缺陷时出现一系列问题。延迟交付可能有效地提供了客户以为他们需要的东西，但在交付时却无法满足客户的实际需求。组织必须为新增功能和修复缺陷（先前未识别的客户需求）提供合理的理由、资金支持，并启动新项目，这通常会将新工作推迟到下一财年。到那时，一切已经太晚。

相反，敏捷将 SDLC 活动视为一个循环过程，直到继续开发的投资回报不再支持添加新价值的成本为止。基于敏捷的实践通过多个迭代开发周期逐步释放新价值，形成频繁和重复的模式。短周期交付让代码在测试之间保持较小，有助于更容易发现和解决缺陷。频繁的客户评审和团队回顾帮助确保团队始终专注于客户当前的需求、优先事项以及改进的请求。

尽管敏捷宣言涉及 CD 概念，但它并未推广集成或自动化策略。这些想法是在后来提出的。相反，敏捷宣言强调改善开发职能内部的协作和沟通。DevOps 最初是一种改善开发和运维导向团队之间协作和沟通的策略。在当前的形式下，DevOps 通过跨 IT 的协作、集成和自动化，促进 IT 敏捷性，从而快速交付客户价值、更高质量的产品，并减轻压力。

自动化 IT 价值传递

DevOps 在两个重要方面扩展了敏捷模型。首先，DevOps 超越了传统的 SDLC 流程，链接了 IT 运维中的活动和人员。其次，DevOps 与 CI 和自动化能力同步发展，进一步加快了从创意到价值交付的周期，同时提高了交付质量。

业务流程改进（BPI）和 BPR 专家知道，在分析并实施所需的流程改进之前，自动化关键业务流程是没有意义的。理想情况下，组织应采用精益方法，绘制当前的现状和期望的未来价值流，以确定新流程应如何设计，并执行工作以实现所需的转型。

有句格言是，自动化一个有缺陷的流程只会让它更快速地输出糟糕的结果。换句话说，如果一个组织已经无法交付价值，自动化该过程只会更加高效地输出错误的结果。换句话说，自动化有缺陷的流程只会更快速地生成更多浪费。

因此，在任何 IT 组织尝试整合和自动化其 SDLC 和运维活动之前，他们首先需要了解需要解决哪些问题。我们将在下一节中讨论这些问题。

在 IT 开发和运维之间进行协作

从概念上讲，DevOps 最初作为一种策略，旨在改善 IT 开发和运维团队之间的协作。这种协作帮助开发团队了解运维团队在部署产品时遇到的问题。以下是一些示例问题：

• 如果没有适当的协作，工程和测试环境可能无法充分模拟生产环境，从而引发一系列问题，例子如下：

  a. 生产环境配置说明可能不充分。

  b. 测试环境中可能没有安装与生产环境相同的应用程序，这使得难以发现配置、应用程序编程接口（API）和集成冲突。

  c. 工程和测试环境中的性能测试可能无法充分评估生产环境中所遇到的负载和压力。

  d. 在工程和测试环境中开发的回滚和故障转移指令可能在生产环境中无法正确工作。

• 开发团队可能没有足够重视生产环境中的安全问题。

• 运维团队缺乏一种切实可行的方式来表达他们的关注点，并在开发团队中优先考虑他们的需求。

• 通过帮助台和客户支持职能，运维团队对客户问题和需求的改进有最直接的了解。

实际上，IT 开发团队有内外部客户需要支持。然而，当开发团队只关注外部客户时，他们往往忽视了对运维团队造成重大影响的技术债务积累。

现在我们已经识别出开发与运维之间的沟通与协作问题，并且意识到开发团队有两个客户（内外部客户），我们可以识别出典型的 IT 价值流。所以，下一节的主题就是这个。

定义 IT 价值链和价值流

IT 组织可以自由定义其 IT 价值流，只要他们识别出内部和外部客户，并花时间组织和评估他们的活动，以最大化以客户为中心的价值。VSM 章节提供了详细的指导，帮助从价值的角度映射现状和目标流程，并监控和分析交付性能，评估组织的改进目标。

另一方面，IT 组织不必从头开始——例如，Open Group 提供了其 IT4IT 参考架构（即IT for IT），作为一种标准参考架构和基于价值链的运营模式，用于管理 IT 业务。Open Group 采用迈克尔·波特（Michael Porter）对价值链的定义，作为对创建市场产品生命周期中的净价值的完整初级和支持活动集的分类方案。在 Open Group 的术语中，IT 组织即是一个价值链。

在这种背景下，Open Group 定义了 价值流，描述了 IT 价值链中某一特定领域的关键活动。价值流活动在 IT 产品或服务的生命周期中创造新的净价值单位。换句话说，序列中的每个价值流活动都是增值的。否则，该活动不应存在，或者至少不应以当前的形式存在。

IT4IT 定义了四个主要的 IT 价值流，概述如下：

• 战略到组合：推动 IT 组合实现业务创新。

• 需求到部署：在业务需要时构建所需的内容。

• 请求执行：目录、执行和管理服务使用。

• 检测到纠正：预测并解决生产问题。

加速敏捷性

敏捷开发的宣言原则之一是，敏捷过程促进可持续的开发，且不断推进。然而，现实是这些目标很难实现。客户总是有比团队能处理的更紧急的需求，团队也面临来自高层管理、市场营销和销售人员的压力，要在短时间内交付所有内容。这些压力在敏捷方法下并不会消失。

确实，当开发团队逐步交付客户所需的价值，并且客户能够看到他们高优先级请求的及时结果时，开发团队看起来像是英雄。但之前的句子依然成立：“客户总是有比团队能处理的更紧急的需求。”

在成熟的 DevOps 环境中使用的集成和自动化能力显著加快了交付的速度。在他们的书籍《加速：构建和扩展高性能技术组织》中，作者（Forsgren, Humble, 和 Kim，2018）比较了使用 DevOps 能力的高效能 IT 开发团队与未使用 DevOps 的低效能团队的指标。结果令人震惊，如下所示：

• 部署代码的频率提高了 46 倍

• 提交代码到部署的交付时间提高了 440 倍

• 平均恢复时间（MTTR）从停机时间恢复的速度提高了 170 倍

• 变更失败率降低了五倍（变更失败的可能性仅为五分之一）

本书讨论了 DevOps 的基本机制。具体来说，第五章，《通过 DevOps 管道驱动业务价值》介绍了开发 CI/CD 和 DevOps 管道的复杂性和挑战。接下来，在本书的第三部分，《安装 DevOps 管道——在我们的数字经济中竞争》，我们将深入探讨四种开发 DevOps 管道的策略。

我们已经完成了关于加速敏捷性的讨论，现在将继续理解为什么以及如何 VSM 和 DevOps 是互补的实践。

集成精益、敏捷、VSM 和 DevOps

到目前为止，您已经了解到敏捷的价值观和原则、精益生产实践以及 VSM 和 DevOps 的协作、集成和自动化能力都支持组织的主要目标：交付以客户为中心的价值。作为一名精益敏捷实践者，您的任务是帮助将这些概念和能力融入到一种无缝的工作方式中。

行业研究证实，敏捷和精益敏捷实践现在已成为主流。例如，Digital.ai 的《第 14 届敏捷状态报告》（2020）发现，75%的 IT 受访者正在实践Scrum或 Scrum 的混合型框架作为他们首选的敏捷框架，35%的受访者使用Scaled Agile Framework®（SAFe®）作为他们首选的精益敏捷扩展框架。这些数字比去年增加了 5%。

与此同时，DevOps 能力的引入越来越被视为参与全球数字经济的必要条件。高绩效者的指标表明，那些能够有效掌握 DevOps 的组织，相比那些没有掌握 DevOps 的组织，具有显著的竞争优势。

相比之下，VSM 仍然是一项新兴的实践，正在快速发展并在 IT 行业中获得认可。然而，鉴于精益生产概念在制造和服务行业的大规模成功，VSM 背后的基本精益理念增强了这一观点，即在 IT 行业中继续采用并取得成功是可行的。这个预测之所以成立，是因为 IT 价值流必须与更广泛的精益企业价值流对齐并支持它们。

在她的博客《如何在 DevOps 中使用价值流图》中，Lizz Corrigan 做出了以下观察：www.lucidchart.com/blog/

"在 DevOps 环境中，VSM 和精益方法论是针对特定行动进行定制的，例如在团队之间移动工作以创建可交付成果和事故报告。DevOps VSM 是 IT 和企业如何构建、部署和管理工作流程的统一可视化表示。它应该从 SDLC 开始，经过质量保证，再到发布/运营。"

简而言之，VSM 提供了指导和监控新需求通过 DevOps 流水线的基础设施。在本书结束时，你应该对如何将这些能力与 IT 开发和运营职能的价值导向工作相连接并加速其运作有了扎实的理解。

摘要

在本章中，你已经了解了在实施敏捷、精益、VSM 和 DevOps 实践时，为什么“价值”这一概念至关重要，才能充分发挥它们的优势。你还了解到，价值是期望客户体验的表现，而一个组织整体需要步调一致地工作，以提供这些体验。

当前的 IT 方法论通常使用精益-敏捷作为其主要区别性特征。然而，精益和敏捷是互补的概念，两者实践的融合帮助 IT 组织快速、高效且高质量地交付 VA 产品。

你还学到了，VSM 通过整合和自动化价值流识别、映射、分析、测量和监控能力，在 IT 中实现精益实践，支持端到端产品生命周期的价值交付。最后，DevOps 有助于加速价值交付。

本书第一部分《将 IT 聚焦于价值交付》中的后续章节提供了如何使用价值流映射评估当前和未来期望状态变化，以改善价值流的指导。接下来，你将学习如何使用 VSM 能力支持、分析和监控价值流改进活动。最后，你将了解为什么 DevOps 是快速、高效和经济地实施支持价值流改进的数字应用程序的关键推动力。

在进入这些章节之前，我们需要探讨组织如何将敏捷、精益和系统思维实践作为一套集成的实践方法。这是下一章的主题。

问题

1. 数字经济 这个术语最初描述了电子商务视角下 IT 应用的方式。在现代背景下，哪些其他元素构成了我们的数字经济？

2. 为什么语义问题在信息科学中如此关键？

3. 什么是价值主张？

4. 谁负责交付一个组织的价值主张？

5. 为什么关注价值很重要？

6. 什么是价值流的定义？

7. 专注于功能和特性的区别与专注于价值流之间的区别是什么？

8. 在现代 IT 背景下，VSM 的目的是什么？

9. 在 IT4IT 参考架构中，IT 价值链内的四个 IT 相关价值流是什么？

10. 实施 DevOps 能力在现代 IT 组织中扮演哪两个角色？

进一步阅读

• Krafcik, J. (1988). 《精益生产系统的胜利》。麻省理工学院（MIT）。斯隆管理评论。第 30 卷，第 1 期。 www.lean.org/downloads/MITSloan.pdf。访问时间：2020 年 11 月 16 日

• Womack, James P., Jones, Daniel T. (1996, 2013). 《精益思想：消除浪费并创造企业财富》，Simon and Schuster，ISBN 9781471111006。

• Womack, James P., Jones, Daniel T., Roos, Daniel (1990). 《改变世界的机器》。纽约：Rawson Associates，ISBN 9780892563500。

• Poppendieck, Mary, Poppendieck, Tom (2003). 《精益软件开发：敏捷工具包》。Addison Wesley，波士顿，马萨诸塞州。ISBN 0-321-15078-3。

• Rupp, Cecil G. (2020). 《在现代企业中扩展 Scrum》。在大型组织中，实施 Scrum 和 Lean-Agile 技术，适用于复杂的产品、投资组合和项目。Packt Publishing。伯明翰，英国。

• Liker, Jeffrey K. (2004). 《丰田之道：世界上最伟大制造商的 14 项管理原则》。麦格劳-希尔。ISBN 978-0-07-139231-0。

• 罗瑟, M., 舒克, J., (1999). 《学习观察：价值流图绘制以创造价值并消除浪费》，马萨诸塞州布鲁克莱恩：精益企业研究院。

• 马丁, K., 奥斯特林, M. (2014). 《价值流图绘制：如何可视化工作并协调领导力以进行组织转型》。麦格劳-希尔。纽约，纽约州。

• 塔平, D., 露斯特, T., 舒克, T. (2002). 《价值流管理：规划、绘图和维持精益改进的八个步骤》。第一版，生产力出版社，纽约，纽约州。

• 塔平, D., 露斯特, T., 舒克, T. (2003). 《精益办公室的价值流管理》。生产力出版社，纽约，纽约州。

• 海恩斯, P., 拉明, R., 琼斯, D., 库辛斯, P., 里奇, N. (2000). 《价值流管理：供应链中的战略与卓越》。皮尔森教育有限公司。伦敦，英格兰。

• 福斯格伦, N., 汉布尔, J., 金, G. (2018). 《加速：构建和扩展高绩效技术组织》。IT 革命出版社。波特兰，俄勒冈州。

第二章：构建精益敏捷基础

信息技术行业不断演变，以更快速、更高效、更高质量地交付以客户为中心的价值。一些改进理念，如敏捷和 DevOps，直接来源于软件行业。然而，精益、系统思维和价值流管理的起源则在软件行业之外。尽管如此，这些实践现在已成为软件和数字产品及服务交付行业的主流。

尽管本书是关于应用 VSM 和 DevOps 实践来加速数字价值交付，但每个组织必须建立一套基础实践。具体来说，IT 组织需要在敏捷、精益和系统思维实践的坚实、价值为中心的基础上，构建其 VSM 和 DevOps 能力。

本章将帮助精益敏捷实践者理解如何建立这一整合的基础。我们将在下一章探讨系统思维。现在，在本章中，你将了解敏捷和精益实践如何协同工作，以交付以客户为中心的价值。

本章将涵盖以下主要内容：

• 灌输敏捷的价值观和原则

• 获得利益相关者的支持

• 实施有用的度量指标

• 通过精益思维改善 IT 流动

• 消除软件开发中的浪费

• 创建精益敏捷基础

• 加速 IT 价值流中的流动

灌输敏捷的价值观和原则

在上一章中，你了解到《敏捷软件开发宣言》（也叫敏捷宣言，agilemanifesto.org/）列出了四个价值观和十二条原则，用于提升软件交付。如果你是敏捷的新手，可能不知道敏捷并不是某种特定的或单一的方法论。敏捷宣言中没有关于如何灌输敏捷价值观和原则的指导，它只描述了期望的成果或目标。

另一种理解敏捷宣言的价值观和原则的方式是“成为敏捷”而不是“做敏捷”。换句话说，虽然我们可以做很多事情来提高软件开发的敏捷性，但敏捷宣言并未提供如何实现敏捷的具体指导。

许多方法论声称自己是敏捷的。对于那些需要入门的人，我在我之前的书籍《在现代企业中扩展 Scrum》中介绍了敏捷的历史以及行业领先的敏捷和精益敏捷方法论。在撰写本书时，领先的小团队敏捷方法论是 Scrum——包括几种混合版本，能够使多个团队协同合作。

相比之下，领先的多团队精益敏捷方法论是Scaled Agile Inc.的Scaled-Agile Framework®（SAFe®）。另一种正在获得关注的精益敏捷方法论是由项目管理协会（PMI）提供的纪律化敏捷。在本章稍后“创建精益敏捷基础”部分中，您将学习精益敏捷实践如何扩展迭代和增量开发的基本敏捷实践。

目前，理解 VSM 和 DevOps 建立在敏捷（Agile）和精益（Lean）理念之上是至关重要的。因此，组织必须先建立敏捷和精益实践的基础，并让文化围绕这些实践演化，然后才能安装 VSM 和 DevOps 所采用的流程集成和自动化能力。

集成和自动化有缺陷或实施不当的流程只会加速不良流程的负面结果。不良结果包括构建客户不需要的功能和特性的产品，交付质量较差的产品，以及交付存在 bug 和缺陷的产品。没有对基础开发和运营流程进行重新设计，集成和自动化无法解决这些问题。

敏捷和精益敏捷方法论帮助组织通过它们所实施的实践来灌输敏捷的价值观和原则。然而，规模和支持的程度驱动了大多数关于哪种敏捷方法最合适并且支持软件开发团队或项目需求的决策。我们将在接下来的部分简要回顾领先的 Scrum 和精益敏捷方法论。

领先的 Scrum 和精益敏捷方法论

没有什么规定组织不能自己弄清楚如何在其运营中变得更加敏捷和精益。另一方面，既然有经过验证的方法论可以帮助指导其努力，为什么要从头开始呢？问题是，哪些方法论和实践最适合该组织？

我之前的书籍，在现代企业中推广 Scrum（Rupp，2020），由 Packt 出版社出版，详细描述了许多历史上以及目前领先的精益敏捷实践。与其重复那些信息，本节将简要介绍当前行业领先的 Scrum 和精益敏捷方法论和框架：

• Scrum：Scrum 于 1990 年代由 Ken Schwaber 和 Jeff Sutherland 开发，并在 2010 年将其Scrum 框架正式化为Scrum 指南。Scrum 实施了一个基于经验主义的框架——经验主义是一种理论，认为所有知识都来自通过感官观察获得的经验（即视力、听力、触觉、味觉、嗅觉、空间感等）。经验主义者重视通过经验、观察和实验假设测试（即科学方法）得出的基于证据的知识。

  Schwaber 和 Sutherland 继续更新 Scrum 指南，最近的版本在 2020 年 11 月发布。他们的最新版本宣称 Scrum 的基础也包括精益概念。然而，他们并没有在之前的版本中提出这一主张，而他们在最新的 Scrum 指南中的精益讨论仅限于精益思维减少浪费，聚焦于核心要素的声明。

  总的来说，Scrum 框架实现了迭代式冲刺，作为一个容器来实施其他实践和活动，所有这些都以敏捷的方式执行，在短而频繁的周期内交付增量价值。容器的概念至关重要，因为 IT 行业使用着无数的技术、方法、工具和技巧。让单一的敏捷方法强行采用某个特定的开发策略是没有意义的。相反，Scrum 框架引导团队以敏捷的方式使用他们偏好的方法和工具，在每个冲刺中交付增量价值。

• Scrum-of-Scrums：最初的 Scrum 扩展，通过团队间合作的结构实现 Scrum 实践，应用于多个团队之间的协作。Scrum-of-Scrums 模型被广泛应用于协调小型团队的工作，超越了 IT 职能，所有团队共同协作以交付相同的产品。

• 大规模 Scrum：Jeff Sutherland 对 Scrum 指南的扩展将基础的 Scrum-of-Scrums 概念扩展到整个企业和各个业务领域，并通过最小可行的官僚体制（MVB）以及无规模限制的架构进行扩展。

• Nexus 框架：Ken Schwaber（Scrum.org）对 Scrum 指南的扩展，通过实施网络集成团队（NITs）来管理跨团队的依赖关系以及集成和同步问题，应用于多团队的软件产品开发工作。

• 大规模 Scrum（LeSS）：这一规模化 Scrum 方法由 Craig Larman 和 Bas Vodde 提出，包含两种 Scrum 扩展框架，帮助协调多个团队的活动。LeSS 框架围绕功能协调多个 Scrum 团队，而 LeSS Huge 框架则围绕需求领域协调活动。这两个框架支持多团队协作，开发大型且复杂的软件产品。

• 有纪律的敏捷（DA）：这是一种精益敏捷的开发方法，提供了六种产品开发生命周期、众多的流程指南以及成百上千种潜在的有用技术。DA 方法允许团队根据他们独特的业务和组织需求与情况选择自己偏好的工作方式。最初由 Scott Ambler 和 Mark Lines 开发，项目管理协会（PMI）在 2019 年收购了他们的公司，同时收购了企业转型流（FLEX）以及Net Objectives的相关内容。FLEX 与 DA 结合，运用精益和系统思维，提升组织的商业敏捷性。

• Scaled Agile Framework®（SAFe®）：SAFe 有四种配置，是一种适用于大规模组织的精益敏捷方法，专注于大型产品开发。SAFe 帮助大型组织利用规模经济提供更高的效率，同时融入精益敏捷实践，促进企业规模的业务敏捷性。SAFe 的四种配置如下：

  • Essential SAFe®：这是一个基础的多团队精益敏捷扩展模型，围绕一个名为敏捷发布团队（Agile Release Teams，简称 ARTs）的团队协作概念构建。每个 ART 的规模通常在 50 到 125 人之间，受邓巴数的限制，源于人类在稳定关系中能积极维持的数量的认知限制。

  ART 内的团队协作以支持单一的大型产品或个别价值流。ART 内的小团队根据具体情况实践极限编程（XP）、Scrum 和 DevOps，并共同协作，在固定时间周期的项目增量（PIs）中交付集成的增量价值，这些周期通常为 8 到 12 周。XP、Scrum 和 DevOps 在较短的时间间隔内运作，并与每个 PI 同步。

  • Large Solution SAFe®：这一配置扩展了Essential SAFe的精益敏捷基础，以协调和整合支持非常大产品或大量产品的多个 ARTs 的工作。Large Solution SAFe同步任何数量的 ARTs 以及数百到数千的团队成员。

  • Portfolio SAFe®：通过围绕价值流组织精益敏捷企业，将投资组合执行与企业战略对齐。SAFe 投资组合是由开发和运营导向的价值流组成，这些价值流在一个业务单元内运作。此 SAFe 配置还加入了精益投资组合管理（LPM）概念，以便监控和评估跨时间的投资组合投资需求。

  • Full SAFe®：将Essential、Large Solution和Portfolio SAFe作为一套集成协调的流程和活动进行连接。

之前讨论过的任何 Scrum 和混合 Scrum 方法论和框架都可以帮助你的组织提高单个或多个团队的敏捷性，协作开发单一产品或产品线。DA 和 SAFe 也包含了实施精益软件开发概念和投资组合管理流程的强大方法，以支持战略规划、资金优先级和跨多个产品线的资源分配。

无论你选择采用哪种 Scrum 或精益敏捷方法，其成功主要取决于相对于实施的规模和范围的赞助支持水平。领导力和高层支持是下一节的主题。

引领方向

实施敏捷和精益实践对整个组织有广泛的影响，这会影响任何实施的潜在成功。此外，实施的规模越大，影响越广，拥有适当的领导力和赞助层级对其成功至关重要。理想情况下，组织的首席执行官应引领这一进程。

小型软件开发团队有时可以在小团队层面实施 XP 和 Scrum 实践，且只需要最小的赞助。然而，这种实施往往在没有适当的产品负责人领导的情况下，难以获得客户需求和优先事项的信息。

此外，开发团队可能无法摆脱其组织传统的资金和资源分配方式所带来的项目导向思维。敏捷实践则专注于产品导向。高管、客户和其他利益相关者可能会抵制为支持产品导向模型的迭代开发和增量发布策略所需的组织变革。坦率地说，敏捷和精益专注于产品和客户，这需要他们付出更多努力，而他们可能看不到其中的价值。

价值是存在的，但受影响的内部组织和客户需要接受教育，并看到结果才能认同。所以，花点时间来讨论如何获得他们的支持。

获取利益相关者的支持

敏捷和精益实践要求跨业务职能之间更加频繁和紧密的互动，参与者必须对新产品或产品增强的成功有利害关系。在传统的软件开发模型中，管理层和客户的互动仅限于最初的需求收集活动，然后是在定期的里程碑审查、阶段门和后期的用户验收测试中进行最小化互动。精益敏捷方法论要求更多。

敏捷的好处直接来自于团队和利益相关者之间频繁且持续的互动，所有关键数据必须具有完整、准确和最新的可见性。但早期的采用者如何鼓励组织内部和客户中的其他人考虑这种改变呢？

早期采用者可能在教育其高管关于敏捷和精益敏捷实践的好处方面取得了一些成功。然而，根据个人观察和经验，最不成功的做法是去争取高管的注意并让他们发布立即改变的命令。没有适当的领导、指导和资源支持，命令往往会失败。

相反，组织可以遵循以下实际步骤：

• 内部宣传：创建关于提议的敏捷或精益敏捷实践的教育材料，以便分发和审阅。

• 执行赞助人：找到一位具有权威、资金支持和前瞻性视野的关键执行赞助人，以便看到交付加速价值的好处。

• 内部试点：确定一个具有高能见度且具有重要潜力的产品，作为内部试点和案例研究。

• 试点团队：组建一支由志同道合的早期采用者组成的小团队，他们看到了敏捷和精益敏捷实践的价值，并希望站在变革的前沿。此外，还需要对试点团队和其他参与方进行培训。

• 基础设施：建设支持试点项目所需的基础设施。理想情况下，敏捷团队应在一个地方操作，配备专用的会议室、个人工作区、笔记本电脑和服务器、软件开发和测试工具以及网络访问。

• 规划试点实验：规划活动和时间表，以引导初始试点通过一系列迭代，每个迭代都交付增量价值。

• 进行试点实验：以敏捷方式进行待办事项的优化、计划、开发和测试周期，每个周期都交付增量价值。同样重要的是，确保高层领导、客户和最终用户保持承诺并积极参与每次迭代回顾。他们的指导和意见对团队交付增量且以客户为中心的价值至关重要。

• 检查和调整：在最初的试点项目中，团队和其他相关方通过回顾会议和产品演示评估他们的表现，改进活动以提高效率，执行计划中的改进，进行监控，并根据需要继续调整。这个检查和调整过程是永无止境的。

• 新试点：在成功完成第一次试点后，寻找两个到三个新的试点项目，进一步证明并扩展组织的新开发方法。大多数人都希望参与成功的项目，每一次新的试点成功都会鼓励其他产品团队评估并采用这种方法进行开发工作。

• 检查和调整：在后续的试点项目中，新团队和相关方通过回顾会议和产品演示评估他们的表现，改进活动以提高效率，执行计划中的改进，进行监控，并根据需要继续调整。检查和调整过程从未停止。

• 路线图：随着初始试点证明了新工作方式的有效性，组织的高层领导必须制定详细的路线图，指导全企业范围的部署。从实际角度来看，没有一个初始且更新的计划，就无法准确地衡量、监控和指导未来的部署。

  在新模型下，可能需要重新定义产品和产品线，以使其与新的精益价值流模型对齐。这种重新调整不仅仅影响软件产品。业务需要从增值的角度评估所有内外部客户关系，以定义其运营和面向开发的价值流。

  需要组建产品团队，包括招聘和指导产品负责人和 Scrum 大师。需要开发和部署培训、辅导和指导资源，帮助员工迅速掌握新的精益敏捷实践。建立一个或多个卓越中心（CoE）来提供辅导和指导资源，并引导价值流转型可能是有益的。

• 发布：执行路线图中概述的部署计划。确保已定义适当的度量标准，并监控进展情况。

• 检查和适应：在推进过程中，新团队和相关利益相关者通过回顾和产品演示评估他们的表现，改进活动以促进提升，执行计划中的改进，进行监控，并在必要时继续调整。这里，检查和适应的过程永无止境。

  如你所见，检查和适应活动贯穿整个敏捷和精益敏捷转型过程，以及所有产品生命周期。此外，提供可视化是检查和适应过程的关键。度量标准和其他信息形式帮助组织可视化它们与计划和过去表现的对比。

在前一章中，我们学习了评估团队表现的四个最关键的度量标准，如下所示：

• 部署频率：衡量团队代码部署到测试和生产环境的频率

• 交付周期：衡量从开发人员在共享代码库中提交代码到在生产环境中成功运行所需的时间

• 修复或恢复的平均时间（MTTR）：衡量当发生影响用户的服务事件或缺陷时，恢复服务所需的时间（例如，计划外的停机或服务受损）

• 变更失败率：衡量生产环境中变更导致服务降级或失败的百分比（例如，导致服务中断），进而需要修复（例如，热修复或回滚）

然而，还有其他有用的度量标准和信息，每个团队可以选择维护并公开。例如，Intellectsoft确定了五个敏捷度量类别和 15 个有用的度量标准，这些标准提供了一个良好的起点（15+ Useful Agile Metrics in Scrum & Kanban: Measure Quality, Productivity & Performance. 2018，你可以参考www.intellectsoft.net/blog/agile-metrics）。VSM 供应商Plutora也有一篇类似的文章，标题为Agile Metrics: The 15 That Actually Matter for Success（www.plutora.com/blog/agile-metrics）。我们将在下一部分快速回顾这两篇文章中提出的度量标准。

实施有用的度量标准

并非每个敏捷或精益敏捷团队都需要相同的度量指标。高层管理人员和客户会影响选择，并可能要求提供本小节未列出的信息。此外，产品负责人可能需要额外的信息，以了解产品的架构、设计和技术深度问题如何影响已识别和优先排序的产品积压项的交付。

以下列出了产品团队及其相关方可能认为有用的标准度量指标。这些度量指标广泛支持敏捷、精益和看板性能衡量标准及软件质量度量的主要质量、生产力和项目目标。

敏捷质量度量指标

本小节中描述的度量指标支持基于敏捷开发实践的通用质量改进目标：

• 产品积压：这是一个按优先级排列的新特性、功能、增强、错误修复、基础设施更改或其他工作项的列表。该度量指标关注的是识别出的工作项在基于价值和交付成本的基础上被精炼和优先排序的程度。

• 逃逸缺陷：这是衡量已发布到生产环境中并且之前通过了团队的“完成定义”的缺陷数量。由于完全防止缺陷是一个理想目标，因此较高的逃逸缺陷数量表明在定义验收标准或在测试能力和程序方面存在问题。

• 失败的部署：这是衡量软件部署到生产环境中失败并需要回滚的频率。理想情况下，开发团队的工程和测试环境以及他们的测试工具和程序，应该在部署到生产环境之前捕获并解决可能导致系统失败的问题。

  除了测试以发现缺陷和不符合验收标准的情况外，测试环境必须准确地模拟生产环境中对相同应用和配置组合的需求负载。测试环境可能会执行许多性能测试，例如负载测试、耐久性测试、容量测试、可扩展性测试、突发性测试和压力测试。在 DevOps 中，理想状态是自动化这些测试以及所有其他测试。

• 发布净推荐值 (NPS)：这是一种最初定义用来衡量客户体验、预测客户忠诚度和业务增长的指标。发布导向的 NPS 通过定向问题来衡量客户对每次新发布或重大发布的满意度，评分范围是 1 到 10。在 NPS 模型中，贬低者是指那些在评分中给出 6 分或以下的客户；中立者将发布评分为 7 或 8 分；推广者则将发布评分为 9 到 10 分。NPS 的计算方法是用推广者的百分比减去贬低者的百分比：

  

  贬低者 是一个问题，因为他们更可能选择我们的竞争对手的产品，并且批评我们的产品。中立者 通常对新版本既不支持也不反对。支持者 通常会更热衷于推广一家公司、产品或新版本。

  理论上，任何高于 0 的排名意味着发布有更多热情的支持者，而不是不满的贬低者。然而，组织应努力做到比 0 更好。

敏捷生产力度量

本小节描述的度量标准支持敏捷开发实践中生产力改进的目标：

• 交付时间：如前所述，这一度量衡量的是从代码提交到其发布到生产环境中的时间。它是评估软件开发团队有效性的四个度量之一。然而，在敏捷背景下，交付时间是衡量从用户故事或工作项进入产品待办事项到冲刺结束或功能发布到生产的时间。交付时间包括工作项请求在产品待办事项中等待的时间，如下图所示：

图 2.1 – 交付时间/周期时间图

• 周期时间（控制图）：这是交付时间的一个子组件，衡量在价值流中完成一项活动或一组活动所需的时间。换句话说，周期时间是衡量作为在制品的时间，而不包括所有之前的等待时间。交付时间越接近周期时间，流程就越高效。

  以下图表展示了一个周期时间控制图的示例。在我们的示例中，VSM 团队收集有关其管道中特定活动的周期时间数据。在我们的示例中，软件开发团队可能会使用 VSM 工具来捕捉新增代码增量进行端到端测试所需的时间度量。无论如何，周期时间控制图包括数据点、平均值和已设定的控制阈值（限值）。

  这种类型的测试自动化应用程序的工作流，从头到尾，通过每种可能的操作排列来复制常见的用户场景，以发现应用程序在与硬件、网络、外部依赖、数据库和其他应用程序接口时的故障。团队认为，进行此测试的可接受周期时间是 5 到 8 小时之间，并且通常在夜间进行这些测试，以避免软件开发的停机时间：

图 2.2 – 周期时间（控制图）

从前述的控制图示例中，我们可以看到，过去 30 天的表现未能保持在 5 到 8 小时（6.5 小时平均）可接受的范围内。更糟糕的是，测试在六次情况下超出了分配的 8 小时。通过这些信息，团队可以获得所需的数据，探索是什么事件导致了冗长的端到端测试。团队可以将这些信息与这些日期的测试结果进行匹配，查看他们可以采取哪些措施，防止未来出现类似问题。

注意

在基于敏捷和精益/Kanban 的系统中，周期时间是衡量工作项在进行中的工作（WIP）阶段所花费的时间，这个阶段从故事已经精炼并进入进行中阶段开始。在这个上下文中，周期时间不包括工作项在构思、产品待办事项精炼以及后续在产品待办事项队列中的等待时间。周期时间从工作项被接受为 Sprint 待办事项中的一项工作项，或者从 Lean 或 Kanban 的价值流中拉取进入生产阶段时开始计算。

尽管如此，在敏捷、精益和 Kanban 的系统中，周期时间仍可能包括等待时间。其区别在于，周期时间始终包括敏捷 Sprint 中接触和等待时间，但我们希望在面向精益的软件价值流中，尽可能将所有等待时间分开并加以消除。

• 等待时间：产品或材料在延迟状态下处于不活动状态，直到工作开始所花费的时间。在精益和 Kanban 系统中，我们力求消除所有等待时间。

• Sprint 燃尽图：衡量和可视化团队的预测速度作为完成率，通常以估算的故事点数为单位，表示从 Sprint 待办事项跨越一个或多个 Sprint 的工作进度。Sprint 燃尽图的主要目的是展示团队对 Sprint 目标的进展（见图 2.2）。

  团队最初预测每个工作项所需的工作量，以故事点的形式表示。Sprint 燃尽图追踪与 Sprint 待办事项中的实际故事点数完成的工作量相对照的进展情况。图表通常有两条线：一条显示计划的速度，另一条显示 Sprint 的实际速度。

• 史诗和发布燃尽/燃起图：与 Sprint 燃尽图相同的概念用于追踪跨定义的史诗和产品发布的工作进展。史诗是一个庞大的、尚未精炼成更小故事的、计划中的相互关联的工作范围：

图 2.3 – 一个月的 Sprint 燃尽图

使用此类度量标准的主要问题在于，不要将图表用于寻找团队进展的错误。周期越长，需求越不明确，越难以准确估算工作量。史诗级和产品发布完成度图仅显示与最初计划的进度相比的完成情况，并不能帮助理解原因。

• 完成度图：请注意，我们可以使用与 Sprint 完成度图相同的数据来可视化整个 Sprint 完成了多少工作以及剩余多少工作，如下所示：

图 2.4 – Sprint 完成度图

请注意，在前面的图中，较小的虚线表示最初计划的已完成工作的预测。在我们的示例中，团队按计划提前完成了最初估算的 300 个工作点。

• 速度：这是一个度量团队在一段时间内完成的估算工作量的标准，通常在每个 Sprint 中进行测量：

图 2.5 – Scrum 团队速度图

目标是使用速度图来判断未来的表现。然而，数字中的差异越大，团队或团队在估算产品和 Sprint 待办事项中的工作范围时就越困难，规划交付也将变得更加困难。

在大型组织中的 DevOps 中，速度衡量的是在天数甚至小时内完成的故事数量。

• 控制图：也称为 Shewhart 图（以沃尔特·A·谢沃特命名），这是一种统计过程控制工具，用于确定一个过程是否处于受控状态。在敏捷和精益开发实践中，团队使用控制图来跟踪任务从 进行中 到 完成 的持续时间：

图 2.6 – 过程控制图

在理想的情况下，所有活动都会非常可预测，并且永远不会偏离理想的平均值。然而，实际情况往往并非如此，我们使用控制图来查看我们的流程是否朝着错误的方向发展。控制图具有上限和下限边界，定义了最优持续时间以及上限和下限控制限，以指示超出范围的测量值。当团队看到他们的度量指标趋向于上限或下限控制边界时，他们知道自己需要解决问题。

控制图的典型用例是显示在某个活动或过程中的缺陷发生率。然而，当用于衡量活动持续时间时，控制图有助于显示团队的速度及其速度趋势。

敏捷项目度量标准

本小节描述的度量标准支持敏捷开发实践中工作流的管理：

• 看板板和卡片：看板是一种“拉动”信号系统，最初在日本为支持精益生产和即时生产（JIT）概念而开发。看板由“Kan”（即卡片）和“Ban”（即信号）组成，合起来的意思是广告牌或标志牌。在看板系统中，生产过程不会开始，直到接收到信号卡，表明所需的零件或工作数量和类型。整个价值流过程仅在有客户订单时按需启动。

• 可视化工作流：团队可以使用带有列的白板来表示团队定义的工作阶段。以 IT 为例，这些阶段可能包括待办事项、精炼、开发和测试、验收和交付。

  以下图像展示了一个看板板示例，显示了跨越故事、待办事项、进行中、待验证和完成的工作进度活动：

图 2.7 – 看板板与看板卡片

在前面的图像中，标签映射到由软件开发团队管理的敏捷管道看板活动。故事是管理在产品待办事项中的用户故事。待办事项是最高优先级的用户故事。进行中包括正在开发中的用户故事。待验证包括已完成但需要团队成员和产品负责人验证的用户故事。最后，完成表示可以发布到生产环境的用户故事。

• 限制在制品（WIP）：理想情况下，除了初始的产品待办事项外，工作或材料不应有排队情况。下游过程仅在它们有能力执行工作时才会拉动工作。如果没有这个简单规则，工作和材料会在管道的较慢过程处积累，我们知道这会因为过多的存储需求和持有成本而导致浪费。此外，过多的在制品会隐藏排队产品中的缺陷和缺点。这些缺陷变得越来越难以发现，修复起来也更为昂贵。

• 管理流动：使用看板卡片作为信号装置，表示来自内部和外部客户的新请求。这些卡片会进入看板板上的队列。当下游的容量准备好接受来自上游的工作时，承担工作的个人将他们选中的卡片移到看板上的下一个列，以表明他们已接受这项工作。换句话说，工作仅在下游有容量时才会被拉入下游过程；工作从不会被推送到下游过程。

• 明确政策：组织必须提供简单、清晰、可见的政策，描述期望的工作实践、批准的技术、采购流程和人力资源管理。这些政策必须根据新的学习不断发展，采用更好的方法。

• 反馈：看板中的反馈通过协作会议实现。传统的看板实践包括七种类型的会议：

  a. 战略评审：这些是企业层面对业务使命、目标和受资源、时间、竞争和技术约束的目标的评估。

  b. 运营评审：帮助团队评估他们的看板实践、价值流活动和资源，以交付价值。

  c. 风险评审：识别风险并制定缓解策略和应急计划。

  d. 服务交付评审：评估支持产品交付所需的服务（也称为操作价值流）。

  e. 补充会议：这是一种基于看板的待办事项管理活动，用于识别必须从待办事项中拉取的任务。通过将任务分配给服务类别（CoS）并为每个 CoS 拉取的任务数量设置限制来完成这一任务。CoS 任务的示例包括紧急请求、固定交付日期、缺陷、标准任务和维护任务。

  f. 看板站立会议：这与每日 Scrum 会议的概念相似，团队成员简短地聚集在一起讨论工作进展、剩余工作以及阻碍工作的因素。看板会议的主要区别在于将工作管理为连续流动，通过消除瓶颈最小化交付时间，并减少 WIP（在制品）。团队成员会在他们的看板面前开会。

  g. 交付规划会议：当组织在固定日期正式发布产品时，必须举行此会议。交付规划会议帮助团队解决实施问题、支持和维护交接、数据迁移、培训开发和交付要求以及其他服务水平协议（SLA）问题。

• 持续改进（Kaizen）：改进的想法来自观察、协作、回顾和产品演示。利用基于团队的回顾会议回顾并分析之前的问题，进行立即的实验以解决这些问题，并且不断进行这些迭代的持续改进工作。此外，利用客户演示来帮助从他们的角度指导开发优先级。

• 累计流图（CFD）：这是一种通常与看板方法相关的分析工具。从概念上与敏捷的 Burnup 图类似，CFD 提供了关于每个价值流阶段累积工作量的可视性（例如，软件开发的价值流）。

  在理想的世界里，工作项在一个同步协调的开发流水线中按照一系列活动流动，活动持续时间略有差异，没有返工，也没有由于缺陷和错误导致的损失。但我们并不生活在那个世界，发生的事情会在我们开发流水线的各个环节上导致工作积压。

  以下图表展示了一个 CFD，跟踪了软件交付管道中以下四个阶段的工作：

  a. 工作项请求（蓝色）

  b. 需求精炼（橙色）

  c. 开发与测试中的工作进展（灰色）

  d. 交付（黄色）：

图 2.8 – 持续流图（CFD）

CFD 允许团队可视化他们价值流过程中的潜在障碍，并且是观察价值流活动影响的最有效工具。与相对平稳、起伏轻微的图表不同，突然上升或下降的图形表明存在障碍。

• 代码覆盖率：这是衡量和可视化团队产品代码被单元测试或测试套件覆盖的程度。典型的代码覆盖率度量标准包括方法或函数覆盖率、语句覆盖率、分支覆盖率、条件覆盖率、多条件/决策覆盖率（MC/DC）、参数覆盖率和环路复杂度。

  测试中的代码覆盖率越广泛，软件的潜在可靠性和质量就越高。任何代码覆盖率的空白都可能导致软件故障和 BUG。即使团队的代码覆盖率很高，仍然有可能漏掉一些问题。另一方面，如果代码覆盖率良好，这种情况应该是少数和罕见的。

敏捷团队的健康度量/敏捷绩效度量

本小节中描述的度量标准支持精益和敏捷开发实践中的员工满意度目标：

• 员工幸福感：这是一个相对主观的衡量标准，但对于保持员工的长期留任至关重要。幸福感通过简单的员工调查来衡量，调查询问员工他们对公司有多满意，最喜欢什么，不喜欢什么，以及哪些因素能提高他们的幸福感。当然，管理层需要积极行动，基于这些信息做出积极的改变，以帮助吸引和留住优秀员工。

• 团队士气：团队层面的士气测量通常能提供更好的工作满意度指标。同样，调查是最有效的，但问题不应为开放式问题。相反，调查要求团队成员在 1 到 7 的评分范围内评价他们对问题的认同感。问题会询问团队成员是否觉得自己适合团队，是否为自己的工作感到自豪，是否对工作充满热情，以及是否在工作中找到意义和目标。

核心精益和看板度量

本小节中描述的度量标准支持精益软件开发实践中的生产力提升目标：

• 故事交付时间：这个交付时间指标再次出现，不过这次是在精益和看板系统的背景下。由于精益和看板实施了价值流动，故事的交付时间从它进入产品待办事项列表开始，直到完成为止。因此，交付时间总是包括产品和材料在队列中等待的时间。

• 故事周期时间：作为交付时间的一部分，周期时间衡量完成价值流内一组活动所需的时间。在 DevOps 的背景下，这是衡量工作通过团队开发流水线所需时间的管道流量度量。具体而言，交付时间涵盖从工作项创建到完成的整个过程，而周期时间衡量工作项作为在制品所花费的持续时间。

• 功能交付时间：这是故事交付时间的一个变种，重点是实现特定功能。用户故事代表用户或客户期望的功能，这些功能可能在范围上非常细致。例如，一位在线汽车买家的用户故事可能是：“作为一名汽车买家，我希望查看经销商提供的汽车颜色，以便找到符合我颜色偏好的汽车。”从这个例子中可以看出，用户故事是从用户的角度陈述的需求。

  相比之下，功能实现了一个业务功能的切片，可能包含多个用户故事请求。在这种情况下，经销商的在线功能可能包括所有客户在线汽车查找偏好，包括品牌、型号、年份、价格、颜色和其他差异化选项。换句话说，功能是从业务角度实施的一个功能块。

  区分用户故事和产品功能是至关重要的，因为客户购买的是功能，而如果没有明确说明，客户可能不知道某个功能提供的具体能力和好处。回想我们之前讨论过的通过价值主张清晰陈述产品的能力和好处的必要性。

• 功能周期时间：与故事周期时间类似，这是开发人员积极设计、开发和测试功能所涉及的总时间。换句话说，周期时间衡量的是进行中的工作时间。

• 故事等待时间：这是衡量产品需求或进行中的工作处于闲置状态的非增值时间的指标。目标是尽可能减少等待时间。

• 故事吞吐量：这一速度度量衡量在一段时间内通过开发流水线（或其他价值流）的故事数量。较小的故事有助于以两种方式提高吞吐量。首先，较小的故事实现起来更快，因为需要完成的工作量较少。其次，较小的故事往往不那么复杂，因此更容易并且更快速地调试已发现的错误。

  在基于精益（Lean）或看板（Kanban）的环境中，保持故事的大小相对一致是至关重要的。在精益系统中，目标是使活动持续时间相匹配，以防止较慢活动中的排队。当然，使用与可用容量挂钩的拉式订单输入系统也有助于最小化排队。

  同时，记住任何价值流的理想周期率是可用生产时间除以同一时段内的客户请求数量（也称为TAKT 时间）。因此，如果你的软件开发团队每天平均处理 10 个故事，而每个工作日为 8 小时，那么TAKT 时间是

  换句话说，在你的 DevOps 或看板开发流水线中的活动需要与订单输入的速度保持一致。如果你比TAKT时间慢，你将无法完成所有客户的订单；如果你操作得更快，你将生产出不被需求的产品。

• 创作到完成比率：这是衡量进入价值流的工作项数量与在一段时间内完成的工作项数量之间差异的指标。当进入价值流的工作项数量超过完成的工作项数量时，就会形成队列，假设工作项已被输入到产品积压队列中。

  如果订单输入层级稳定，开发团队可以通过简化价值流活动或增加产能来解决问题。然而，也有可能一些故事的优先级不足，或者在成本上没有充分理由被纳入产品积压队列。无论如何，过高的创作到完成比率表示当工作是客户优先且已证明其成本效益时，存在机会损失。

在敏捷中衡量软件质量

本小节中描述的指标支持基于敏捷的开发实践中的软件质量改进目标。

• 静态代码分析：这是一种用于调试软件的方法。它通过检查源代码与预定义的规则和标准的符合情况来实现，而无需执行程序。开发人员在最早的代码开发阶段进行静态代码分析，在单元测试之前，或者在与源代码仓库的主干代码集成之前。其目标是在最早的时间找到并修复编码错误。

  静态代码分析可以作为手动测试运行。但手动测试耗时、繁琐，并且容易出现人为错误。更好的方法是使用静态代码分析工具（SAST）来扫描和检查代码是否符合规则，如语法违规、未定义的值、死代码或未使用的代码、编程错误、安全漏洞、性能问题等。SAST 的输出是一个总结报告，展示你的代码健康状态。

  虽然有许多开源和商业的 SAST 工具，但现代编译器也会在运行代码之前进行语法或技术错误检查，捕获许多相同类型的错误。

• 动态代码分析：这是在编译代码并通过产品测试生命周期运行它后识别缺陷的过程，包括单元测试、集成测试、系统测试、验收测试和回归测试。动态代码分析旨在检查系统对在应用程序内动态变化的变量的响应。

  动态代码测试的主要好处是，测试能够在相同的时间框架内，对比人工可以手动实现的数千倍以上的数据输入排列组合。例如，动态代码分析可能涉及数万种或更多的数据输入配置，并针对多个组件和集成系统进行操作，在一个持续数小时的批处理运行中完成。

• 质量智能：数据分析工具有助于改善生产出差或不理想质量结果的软件开发过程。静态和动态分析工具侧重于识别正在开发中的代码中的问题。然而，质量智能旨在发现开发过程中那些在速度、质量和效率方面持续产生问题的领域。质量智能工具帮助团队组织并分析整个软件开发生命周期中各个活动的数据。

本节结束了我们对有用的精益敏捷度量的讨论。在下一节中，你将学习如何通过在 IT 组织中实施精益生产和运营实践来改善 IT 流。

通过精益思维改善 IT 流

在下一章中，你将学习如何应用系统思维来减少涉及一至六组活动的六种潜在价值流中的复杂性（见图 3.2，该图展示了节点、潜在连接、实际连接和网络密度）。所提供的图示展示了如何通过将价值流活动作为精简流来减少活动之间可能的连接和交互。因此，线性顺序方法是价值流中最有效的操作方式。

然而，如果我们没有减少较长活动的设置时间和周期时间，允许工作项在价值流中的较慢活动处排队，我们仍然可能把事情搞砸。如前所述，理想的目标是将每个活动和整体生产率与接收客户订单或需求的速度相匹配。我们可以通过将生产工作项的时间除以在此时间间隔内请求的项目数量来计算这一点，这也被称为Takt 时间。

从概念上讲，精益生产消除所有妨碍我们交付以客户为中心的价值的浪费形式。在传统的精益制造观念中，有七类不同的浪费，如下所示：

• 等待：处理延迟，包括产品在等待或排队中的任何时间。

• 过度生产：生产超过需求或客户当前需求的数量。

• 过度加工：过度加工或进行任何非增值活动。

• 运输：将产品和材料从一个地点搬运到另一个地点所浪费的时间、资源和成本。

• 运动：人们进行的不必要的移动、动作或活动。

• 库存：携带和存储任何没有进行增值活动的材料和产品。

• 缺陷：产品或服务中出现的任何缺陷。

之前列出的精益浪费主要在制造业中发展，但它同样适用于面向服务的公司，例如软件开发公司。软件开发实践中的浪费是下一节的主题。

消除软件开发中的浪费

2003 年，Mary 和 Tom Poppendieck 发布了他们的书《精益软件开发：敏捷工具包》，在书中他们讨论了如何将精益制造概念应用到软件开发中。他们的书将软件开发中的七种浪费形式映射回原始精益浪费概念，如下表所示：

图 2.9 – 将精益制造浪费映射到其软件开发等效项

这些精益生产和精益软件开发中的浪费定义分别已经存在了近 3 年和近 2 年。自那时以来，围绕精益实践的思考有了很大的发展，我在之前的书《在现代企业中扩展 Scrum》中对此进行了阐述。为了简便起见，我将在本节中概述主要概念。然而，我鼓励那些想深入了解的读者，去阅读我前一本书中专门讨论这一主题的两章：第五章，通过 DevOps 管道推动业务价值，以及第六章，启动 VSM 计划（VSM 步骤 1-3）。

当你阅读以下精益概念列表时，请理解它们同样适用于物理产品、数字产品以及混合物理-数字产品和服务的开发：

• 价值：客户总是定义价值。我们有多少经验或多聪明并不重要；我们提出的任何想法，充其量都是一种风险，直到通过目标客户进行充分验证。

• 持续改进（Kaizen）：目标是通过团队合作、改进程序以及员工和客户的协作，使工作更加高效和有效。持续改进的工具包括质量控制机制、及时交付、标准化工作、快速设置、简化流程、更高效的设备和废物消除。此外，改进还应帮助员工的工作更加充实、减少疲劳并提高安全性。

• 视觉管理：这涉及诸如看板卡片等控制手段，用于管理工作项的流入，以匹配价值流动。控制图是另一种图表形式，帮助我们查看在任何指标上何时偏离正常范围。

• 内建质量：这意味着在问题被引入时立即发现并修复它们。在精益系统的持续流动中，我们可能需要停止所有工作流，并集中所有人的努力快速解决问题。内建质量帮助我们消除因产品召回、返工以及在产品开发的后期阶段寻找和修复缺陷所带来的高成本。

• 提升知识：这是精益和敏捷实践中持续改进的重要组成部分。无论是通过经验、试错，还是通过向他人学习，我们都可以将这些学习应用到新的工作方式中，使其更有效、更高效。团队必须抽时间进行观察、分析和学习。

• 推迟决策和承诺：虽然这似乎与精益原则相悖，但由于信息不足做出错误决策会带来成本。当我们有足够的信息来降低风险时，推迟决策是更好的选择。从长远来看，组织通过打造客户真正需要和重视的产品，而不是我们认为客户想要的产品，节省了时间和金钱。

• 通过自动化检测缺陷（自动化管理，Jidoka）：日本精益概念中的“自动化管理”指的是带有人工触感的自动化。Jidoka 是一个质量控制原则，建议使用自动化技术来检测异常，停止流程，解决即时问题，然后找出原因及其影响，探索预防或减少未来发生的方式。

• 消除错误（Poka-Yoke）：这也被称为防错。这种消除浪费的方法可以防止员工或产品用户执行错误操作。目标是设计一个过程或机制，使得某个特定活动无法被错误地执行。例如，团队的持续集成（CI）实践可能会实现一个自动执行静态分析和测试驱动开发指令的构建过程。CI 自动化流程有助于确保开发人员的代码符合组织的编码实践和客户的验收要求，然后才允许他们将代码与主分支（也称为主干分支）合并。

• 消除浪费：评估并消除精益生产和软件开发中之前识别的七种浪费形式。

• 停止多任务处理/任务切换：因为这类活动会分散我们的注意力，破坏我们当前正在做的事情，使得大脑在任务之间迅速切换。实际上，多任务处理是一种任务切换。换句话说，当你在做多任务时，并不是在同时思考两个主题，而是在它们之间来回切换注意力。

  多任务处理仅适用于有限的一些活动，这些活动将我们的认知活动分布在大脑的左右前额叶皮层，例如在走路时与朋友聊天。此外，多任务处理只适用于在执行相对独立的运动技能与认知任务的同时进行——即便如此，你做这两项任务的速度也会变慢。

  当我们在多个认知任务之间工作时，我们的思维涉及一个顺序切换的过程，这在任务切换时会产生瓶颈。在切换主题时，我们的大脑需要时间和精力来重新调整思维并重新开始，而在这个过程中我们会丢失一些信息。因此，我们会失去思路，完成思考和工作所需的时间会变得更长。

  但多任务处理和任务切换还有其他不良影响，包括犯错、增加压力、扰乱短期记忆，以及在任务切换时错过关键细节。任务切换还会对创造力产生负面影响，可能导致你多次回顾同一个主题以完成任务。

• 实践 Gemba（即，到源头去）：这有助于你了解当前的情况。当应用于精益生产时，管理者会走到生产车间，查看进展并与工人交谈，讨论他们的问题和担忧。在软件开发的背景下，我们有协作团队，并通过每日站会和其他活动来沟通进展、问题和想法。开发过程中会展示大型图表，并频繁更新，以简化与任何需要或希望了解进展的人之间的沟通。

• 实施单件流：这是精益生产和精益软件开发实践中的理想方式。这个概念延伸了我们对最有效价值流的讨论，强调了为何最有效的价值流会建立一系列线性顺序的活动以简化工作流程。生产力的另一大杀手是批量处理，尤其是在活动之间的批处理和活动持续时间不匹配时，问题会更加严重。

  直观上，大批量处理似乎成本较低，因为它们可以在一次批处理中处理数百个项目。然而，在现实中，由于漫长的等待时间、生产设备间过多的产品更换时间，以及在大批量中隐藏的错误和缺陷，节省的成本实际上是丧失的。

  理想的情况是，每个价值流活动都有一个工作项流。应避免冗长的设置或更换要求。活动周期时间应该尽可能短，并在所有价值流活动中保持一致。最后，价值流的生产吞吐量应等于订单录入的速度（即 takt 时间）。

• 水平化工作负载（Heijunka）：我们必须设定一个目标，防止大量订单或请求进入系统，导致等待和其他相关问题。Heijunka 涉及在固定时间内平衡生产类型和数量。

  在精益软件开发的背景下，我们可以举一个产品负责人接收需求的例子，这些需求每天都在变化，取决于提供信息的来源和产品管理活动。然而，为了说明这个例子，假设整体需求大致保持在每周约 25 个新的高优先级需求，尽管这些需求并不是每天固定的五个。

  假设我们的精益开发团队能够处理每天五项工作的负载，产品负责人保持一个足够的产品待办事项清单，以维持每天五项工作的稳定发布。新请求的数量可能会因日而异，但目标是保持新工作项的稳定流入生产。

• 拉动生产系统：执行规则，只在直接响应需求时生产商品，而不是提前生产产品或功能，从而造成浪费，例如未售出的库存和客户可能永远不会需要的产品和功能。精益价值流在拉动型生产系统中不会开始工作，直到有客户订单或需求为止。看板系统是一种方法，用于在整个价值流中执行拉动型生产系统的纪律。

• 准时交付（JIT）：这是另一种将生产速度与客户需求相匹配，并消除所有不增值活动的浪费的策略。然而，JIT 最初是解决库存管理问题的。与其提前订购和储存一批材料，JIT 仅允许与客户需求匹配的新采购和物料交付。此外，生产商安排材料的到达时间正好与制造订单产品的时间相匹配。

  JIT（准时生产）在数字化环境中有多种应用方式。首先，软件开发团队在没有客户需求的情况下不会开始新的功能或特性开发。此外，当数字产品支持其他组织价值流时，我们需要确保交付与消费价值流的需求对接。

• 优化整体：这是一种聚合单件流、平衡工作负荷、拉动生产系统和准时制（JIT）子系统中的概念的方式。目标是查看整个价值流，以简化和减少复杂性并消除浪费。目标是使生产过程尽可能高效和简化。与其扑灭火灾，不如只允许订单或需求按照接收速率流入系统。并且绝不允许新订单的进入速度超过生产系统可以处理的负荷，保持持续和无中断的流动，避免等待。

  我们的价值流代表了一种简化复杂生产和面向运营的系统的方法，同时确保我们始终专注于增加或改善以客户为中心的价值。在此背景下，价值流是对整个（即全部）复杂开发或运营系统的端到端优化。

• 拒绝未完成的工作：在精益软件开发的背景下，这指的是任何已进入生产环境但尚未满足完成定义的工作。然而，未完成的工作会在价值流的各个阶段造成混乱。如果开发人员或其他工作人员感到被迫在工作完成之前提交，潜在的下游影响包括额外的错误、缺陷、故障、返工、延误和不满意的客户。作为政策，组织应永远不允许下游价值流活动接受来自上游活动的未完成工作。

• 尊重他人：这是建立高效组织的显而易见的要求。然而，层级化和官僚化的组织往往会创造出敌对的环境，这种环境不鼓励跨团队或跨组织的沟通与协作。此外，这些流程在问题超出流程范围时，以及通过层级结构中的响应和批准延迟时，会产生压力。

  敏捷和精益实践都强调尊重与责任并重。这些概念不同于你小时候被教导的“黄金法则”——“你希望别人如何对待你，就如何对待别人”。

让我们快速回顾一下黄金法则在精益导向的软件开发中的应用：

• 按时工作，消除加班，保持可持续的工作节奏。

• 帮助团队成员理解他们为客户提供的价值。

• 建立以持续学习和技能为核心的薪酬和激励计划。

• 挑战团队成员而不是贬低他们。

• 对团队而非个人负责其承诺。

• 实施安全的工作环境，使团队成员在遇到问题时可以寻求帮助而不受惩罚。

• 让团队成员参与分析问题、探索因果关系，并提出解决当前问题的方法。

• 去除障碍以减少挫败感。

• 在寻求稳定的同时，也要提供多样性，以防止枯燥。

• 通过培养稳定的员工、基于可展示的知识和技能发展的晋升体系，以及精心的继任计划，来保护组织的知识库。

我们已经到达了关于精益思维部分的结束。总结来说，精益思维是围绕价值（产品、服务、信息）组织工作，并优化工作和信息流动。到目前为止，您已经学会了如何通过系统思维和因果回路图评估价值流。这有助于评估参与价值流系统的节点或元素之间的相互关系。

在 第七章，《当前状态映射（VSM 第四步）》和 第八章，《识别精益指标（VSM 第五步）》中，您将学习如何使用价值流映射评估当前的价值流活动，并评估替代的未来状态，以改善价值流中的价值。但在我们继续之前，让我们快速看一下组织是如何将精益和敏捷概念结合起来的。

构建精益-敏捷基础

本节内容是关于将敏捷和精益概念与实践结合起来。乍一看，敏捷和精益的实践在提升客户价值方面有相似的目标，但这两种开发哲学似乎以不同的方式来实现这个主要目标。那么，问题来了，我们如何将两者的优势结合起来，创造出更好的成果？

在本章前面，您已经了解了敏捷是一组价值观和原则，通常作为一个迭代和增量的过程来实施，从而交付以客户为中心的价值。基本的思想是，敏捷团队在拥有灵活性、能够增量地交付小块价值并频繁进行客户和用户回顾时，能够为客户创造最大的价值。这有助于确保产品始终与当前的需求和优先级保持一致。您还了解到，Scrum 是一种基于敏捷的方法论，实施的是经验主义框架。这鼓励团队尝试不同的想法，并利用他们的经验和观察来发现更好的工作方式。

相对而言，精益通过消除所有浪费形式，专注于只做客户需要的事情，从而提升以客户为中心的价值。一些精益实践者喜欢将精益中的浪费概念理解为避免在客户不愿支付的活动上浪费时间和精力。这个思维方式的挑战在于，它有些目光短浅。例如，一个组织可能会在基础设施、培训和流程改进上花费资金，这些投资虽然短期内客户可能没有直接受益，但却间接为客户提供了更多的价值。

了解到敏捷和精益方法论的主要关注点是创造客户价值，主要区别在于开发周期。敏捷实践者倾向于通过小型团队在小范围的迭代发布中逐步提供新的价值。尽管这种迭代发布可能相对较小且频繁，尤其是与传统的瀑布模型相比，但每个敏捷冲刺仍然是一个批量过程。

使敏捷实践更加精益的一个有效方法是用基于看板的拉动模型取代冲刺迭代模型。这一策略将进行中的工作限制为最少的工作项，并同时用单件工作流取代冲刺批量过程。

但是，看板是一种手动过程，我们可以做得更好。例如，我们可以通过简化、整合和自动化我们的 IT 流程，来实现精益的全部好处。这就是下一节关于加速流程的主题。

加速 IT 价值流

在上一节中，你了解到敏捷和精益的目标是以不同的方式改善客户价值和管理产品流程。你还了解到，将敏捷和精益实践结合的最快最简单的方法是通过使用看板和卡片，从批次冲刺模型转向持续流模型。然而，我们也可以通过集成和自动化策略来简化并加速我们的价值交付流程。持续集成（CI）、持续交付（CD）、DevOps、平台和软件工厂帮助我们实现这些目标。

首先，CI 和 CD 能力帮助 IT 开发团队简化、整合和自动化他们的软件开发生命周期（SDLC）流程。这并不是说整个 SDLC 流程应该一次性地被简化、整合和自动化。对于一个没有实施 DevOps 平台或软件工厂的小型 IT 团队或大组织中的小团队来说，快速采用可能不可行。但从精益角度来看，最终实现软件开发价值流的端到端简化、整合和自动化是理想目标。

通过 CI/CD 能力，DevOps 将精益概念作为集成的价值流应用到 IT 运营的功能中。具体来说，IT 组织可以实施价值流管理能力，以整合前端和后端流程。同样，试图一次性管理所有这些变化对于大多数组织来说并不实际。然而，理想的目标是尽可能快速地达到这种集成能力的阶段。

流式处理、集成和自动化端到端的 CI/CD 和 DevOps 流程有助于 IT 组织加速价值交付。它们还帮助提高交付产品和服务的质量。在本书的第二部分（第六章，启动 VSM 倡议（VSM 步骤 1-3），至第十章，改进精益敏捷价值交付循环（VSM 步骤 7 和 8））中，你将学习价值流管理如何帮助从概念到交付和支持的价值交付，同时将其业务价值交付目标与软件交付能力联系起来。

第三部分（第十一章，识别 VSM 工具类型和能力，至第十四章，介绍企业精益 VSM 实践领导者）识别了主要的 VSM 工具供应商和方法论者。VSM 方法论者分为两派：一派是实施 VSM 以支持数字化业务转型，另一派支持精益实践的一般实施。

最后，本书的第四部分（第十五章，避免 DevOps 实施陷阱，至第十七章，结论 – 促进精益业务转型）讨论了使用 DevOps 平台或软件工厂策略来加速组织的努力，从而精简、整合并自动化 DevOps 流程，作为业务转型的一部分。DevOps 平台是商业产品，包含集成的 DevOps 工具链，开发团队可以在最小挑战下使用。这种方法的潜在缺点是平台提供商所采用或开发的工具的限制。

另一种方法是让内部或外部的 IT 开发组织构建软件工厂，实施完全配置的 DevOps 工具链作为代码。通过现代工具和管理配置作为代码，团队可以在几分钟内下载并搭建一个完全配置的 DevOps 环境，按需使用。

有了这个，我们将结束本章内容。

总结

在本章中，你学习了敏捷如何通过建立价值观和原则来改进软件开发实践，以及 Scrum 如何成为主流的敏捷方法。Scrum 实施了一种敏捷框架，结合了经验主义，帮助小团队通过观察和实验来改进他们的开发实践和产品。我们触及了系统思维，以理解软件价值流作为由多种元素形成复杂关系的复杂体系。这些关系使得理解交互部分如何响应系统内变量变化变得困难。因果回路图（CLD）为我们提供了一种工具，分析这些复杂交互对系统的整体影响。

本章还向你介绍了精益思维和精益软件开发的概念，通过精简、集成和自动化价值流活动，并根据需求和生产能力拉动匹配的工作来增加价值。最后，你学习了如何融合精益和敏捷概念，从而加速 IT 价值流的价值交付。

在下一章中，你将学习如何从参与的元素及其相互关系的角度评估复杂系统。

问题

1. 领先的敏捷方法论是什么？

2. 行业领先的精益敏捷方法论是什么？

3. 精益组合管理的目的是什么？

4. 至少列出两个敏捷质量指标。

5. 看板（Kanban）看板和卡片如何帮助改进交付流程？

6. Takt 时间的目的是什么？我们如何计算它？

7. 拥有多个节点的系统中，最简单的配置是什么？

8. 我们如何加速价值交付过程？

9. 精益中的七种浪费形式是什么？

10. 精益和敏捷实践的主要目标是提高效率并增加以客户为中心的价值。它们在方法上的主要区别是什么？

进一步阅读

• Beck, K., 等人 (2001) 敏捷软件开发宣言。agilemanifesto.org/ 访问于 2020 年 12 月 2 日。

• Rupp, C.G., (2020) 在现代企业中扩展 Scrum：在大型组织中实施 Scrum 和精益敏捷技术，适用于复杂产品、组合和项目。 PACKT Publishing. 英国伯明翰

• Poppendieck, M., Poppendieck, T. (2003) 精益软件开发：敏捷工具包。 Addison Wesley. Boston, MA.

第三章：分析复杂系统的交互

IT 组织在多个层面上代表着复杂的系统。首先，软件开发过程是一个系统，运营和支持功能也是如此。其次，团队成员的加入增加了软件开发系统的复杂性，计算设备、网络、工具和软件应用也增加了复杂性。

假设 IT 部门支持多个敏捷或 DevOps 开发团队共同开发一个单一的产品。在这种情况下，每个产品团队将既作为一个独立系统运作，又作为更大系统的一个组成部分——一个“团队的团队”。在这些场景中，所有团队必须协作，以支持软件产品或数字化服务的持续开发。本章提供了评估这些（以及任何其他类型系统）复杂性的方法，重点评估构成系统的元素、它们之间的连接以及交互的类型。

价值流管理的一个基本分析工具是建模和可视化技术，称为价值流映射。这个技术将在下一章作为价值流管理介绍的一部分进行介绍。然而，如果一个价值流团队只检查他们的活动，他们可能会忽略那些影响其价值流作为一个系统的更广泛因素。他们也可能错过这些因素如何影响他们的系统。这种跨领域复杂性分析是系统思维的领域，本章将讨论这一主题。

本章我们将讨论以下主要内容：

• 通过系统思维解决 IT 复杂性

• 分析因果关系

• 计算潜在连接

• 限制连接

• 学习系统思维的词汇

• 可视化系统元素之间的相互关系

• 阅读因果环图（CLDs）

通过系统思维解决 IT 复杂性

系统思维是一种评估大型系统复杂性的方法，它不是将系统看作一个个独立的部分，而是看作参与系统的元素之间的相互作用。我在《Scaling Scrum Across Modern Enterprises》一书的第四章中详细讨论了这一主题，并介绍了与基于 Scrum 的敏捷实践相关的 17 个因果环图。因此，本书中我们只会简要触及系统思维这一主题。

系统思维还帮助分析其他复杂的业务流程，包括连接的价值流之间的相互作用。然而，在本书中，主要关注的是使用价值流图来评估和改进业务流程。尽管如此，系统思维仍然是价值流图的前提活动。因此，精益-敏捷的从业者必须理解系统思维的术语，分析系统级别的因果关系，评估减少网络密度的方法，并运用系统可视化技术。

尽管系统思维和价值流图都运用可视化和建模技术来评估流动，它们的目标不同。系统思维旨在识别所有有意和无意参与系统的元素，确定系统内哪些元素相互作用，元素如何相互作用以及它们的因果关系。相比之下，价值流图是一种评估当前和未来工作方式的技术，然后寻找改进的方式。

互动元素的影响、原因和效果是评估复杂系统的整体行为时需要解决的最关键问题。让我们花点时间来了解为什么。

分析系统中的因果关系

系统思维中的一个关键概念是整体大于系统内各部分之和。这一说法对于系统的能力和复杂性都适用。正是部分之间的相互关系在系统内部创造了复杂性。但这些相互关系也正是让系统能够执行有用或无用的事情。如果我们不了解系统内部相互作用的原因和影响，我们就无法开始理解如何以有益的方式控制这些相互作用。

参与者的关系和互动在系统内可能是偶然的或有意的。例如，我们可以将一个制造生态系统视为代表一个包含任何数量参与元素的单一系统，这些元素相互作用，导致既有意图的也有非意图的影响。部分元素是有意为制造商的运营和交付职能提供支持。然而，制造系统也可能对其他无意的参与者产生负面影响。

在制造生态系统中，有意的参与者包括供应链合作伙伴、分销商、员工、承包商、客户以及其他支持运营的利益相关者。无意的参与者包括在行业通过不安全的环境实践造成健康或安全问题时受到影响的人和其他元素。

从系统思维的角度看，我们需要更深入地理解组织如何在更细化的层面上开展业务。我们还需要理解参与元素之间的互动关系。元素是构成系统的任何事物，包括材料、人员、流程、信息和技术。系统中的元素有时也被称为节点。在CLD 建模中，我们使用节点和箭头构建因果关系的有向图模型。

从技术角度看，一个有向图模型包括了随机变量对图中节点的影响概率。换句话说，因果关系可以在每次系统互动的不同值范围内变化。然而，在本章中我们不需要深入探讨这些细节。

理解系统中元素之间相互关系的挑战在于，我们可能不知道这些关系的存在，也不知道这些互动如何在系统中展开，除非进行详细的系统级分析。稍后我们将通过 CLD 建模回顾如何可视化元素及其互动关系，放在可视化系统元素之间的相互关系小节中。然而，在那之前，我们先快速看一下系统中元素数量的增加如何显著影响相互关系的数量。此外，在进入阅读 CLD部分之前，我们还需要了解一些系统思维中的术语。在下一节中，你将学习如何计算潜在的连接，以展示系统复杂性通过几何增长的参与元素的方式呈指数增加。

计算潜在连接

系统代表的是相互连接的网络。例如，一个大型企业中的 IT 组织可能有数百甚至数千名员工和承包商在其开发和运营职能中工作。此外，这些员工和承包商与其他部门、合作伙伴、员工、利益相关者和客户合作并相互影响。IT 系统还包括计算机、网络、应用程序以及参与 IT 生态系统的众多其他元素。

该组织创建了政策和流程，以帮助协调业务职能和人员活动，从而通过以盈利或在预算范围内生产增值产品和服务来实现期望的结果。每一个这样的流程接触点代表了更广泛的业务系统中的一次互动。当然，也存在许多无意的、计划外的以及可能不理想的互动。

到现在为止，你可能已经意识到，随着大规模系统中的连接增长，问题可能会变得相当复杂。然而，除非你已经熟悉管理网络密度的概念，否则你可能并未意识到这些相互连接和潜在关系增长得有多快。

幸运的是，我们有一种相对简单的方法来计算系统内相互作用的元素之间的潜在连接（以下公式中的PC）。我们还可以计算网络密度，作为实际连接与潜在连接的百分比。让我们从潜在连接的算法开始，这是系统内相互作用的最高测量值。

潜在连接的计算公式为，其中 n 是系统内节点或元素连接的数量。在任何系统中，参与的元素是通过相互作用产生复杂性的节点。节点越多，复杂性越大。让我们来看一些例子：

如果 n=1，那么潜在连接的数量是 0，因为没有其他东西可以连接。再加一个节点，潜在连接的数量仅增加一个，即！。再加一个节点，总共有 3 个节点时，连接的数量增加到 3。

到目前为止，关系和互动的数量看起来非常可控。但现在，我们将连接的数量增加到 7，这是一个中型敏捷团队的规模。在这种情况下，潜在连接的数量为 21。随着团队规模的扩大，或是我们增加更多团队一起合作，潜在连接的数量将呈爆炸式增长。

现在，让我们将团队成员的笔记本电脑添加到我们的敏捷团队示例中。通过将笔记本电脑加入我们的系统，我们在 IT 团队中创建了与设备相关的相互关系。笔记本电脑使我们的敏捷系统中的节点数量增加到 14，并且潜在连接增加到 91。换句话说，团队及其笔记本电脑形成了 91 个互动，这些互动可能影响团队的互操作性。

但敏捷团队每个迭代周期也会致力于交付一个 Sprint 待办事项。在这个例子中，我们假设每个 Sprint 有 10 个工作项。所以，连接的节点数量现在增加到包括 7 个团队成员、7 台笔记本电脑、10 个工作项——总共 24 个元素，并且潜在连接的数量每个 Sprint 急剧增加到 276 个潜在连接。

你是否在多团队环境中工作？为了演示这如何进一步增加管理敏捷团队的复杂性，让我们为我们的 IT 产品开发系统增加一个大小相同的第二个团队。因此，连接的节点数量现在增加到包括 14 个团队成员、14 台笔记本电脑和 20 个工作项，总共扩展到 48 个元素。因此，潜在连接的数量增加到 1,128。

我们可以将客户和他们必须互动的其他员工包括在内，但我想你已经明白了。每一个潜在的连接都是潜在的失败点，或者有可能在每个 Sprint 中造成不理想的结果。系统连接的增长情况如下图所示：

图 3.1 – 潜在系统连接的增长

作为潜在连接在系统内指数增长的一个例子，图 3.1提供了一个图形化示例，展示了从 0 到 100 个互联元素的潜在连接（PC）如何在系统内指数增长。一个 10 人团队有 45 个潜在连接，而一个有 100 名成员的 IT 组织有 4950 个潜在连接。

在我们离开这个话题之前，理解一个概念很重要，那就是通过限制实际连接的数量，我们可以消除一些潜在的负面后果。这也是下一节的主题。

限制连接

通常，系统中的所有元素并非都相互连接。减少系统复杂性的最简单方法是减少元素之间进行通信或协作的机会。另一种方法是减少参与系统的元素数量。

如果你学习过 Scrum 或 Lean-Agile 扩展策略，你可能注意到它们都利用了小团队的概念。即使在非常大的产品开发活动中，有时也涉及到数百或数千人，它们依然采用这种方式。通过将工作分配给多个小团队，可以限制参与产品开发人员之间的互动次数。

例如，Scrum of Scrums将跨团队的互动限制为少数几位团队成员，这些成员被称为大使（Ambassadors）。Nexus方法通过实施网络集成团队（NITs）来管理跨团队的依赖关系、协调和同步活动。类似地，规模化敏捷框架®（SAFe®）通过极限编程（XP）和Scrum团队的形式实施小型团队，并设有一个更高层次的团队，称为敏捷发布列车（ARTs），用于整合和协调跨大型产品开发工作的各个方面，或涉及 50-125 人的多个价值流，这些人被划分为 5-12 个 XP/Scrum 团队。

无论它们具体的策略如何，所有的扩展版 Scrum 和 Lean-Agile 方法都力求通过减少参与者之间的关系和互动来最小化复杂性。换句话说，我们希望系统中的实际连接数少于潜在的理论连接数。

实际连接与潜在连接的比率被称为网络密度。网络密度的概念非常重要，因为它提供了一种方法，通过最小化大型系统中潜在连接的数量，来减少它们可能引发不良影响的潜力。

图 3.2展示了一组六个精益价值流活动，它们作为顺序节点沿一条线连接。该图还显示了每个已识别价值流的最坏情况，其中所有活动都相互连接。每个价值流包括标识节点数量（n）、潜在连接（PC）、实际连接（AC）以及网络密度（ND）的度量：

图 3.2 – 显示节点、潜在连接、实际连接和网络密度的图形

从图示中应该可以清楚地看出，最少的互动次数，也就意味着最少的复杂性，出现在具有线性顺序流程或活动的价值流中。在本书中，您将学到，线性顺序流是精益生产实践、持续集成/持续交付（CI/CD）和 DevOps 管道的标志。当我们通过减少实际连接来降低网络密度时，我们减少了潜在的故障点数量。

通过我们之前的例子，减少网络密度的方法包括拥有备份笔记本电脑和访问替代软件产品。改善复杂系统中的成果的另一种方法是改进那些能够减少影响或修复故障连接的政策和流程。例如，能够迅速重新配置笔记本电脑和软件的 IT 支持团队可以减少因无法访问这些资源而导致的停机时间。

我们还可以减少团队成员与工作项之间的相互连接。例如，如果我们的团队成员具备广泛的技能，他们可以拆分工作项，从而减少工作项之间的依赖关系。我们还可以限制团队内部和团队之间的互动数量。在跨团队互动中，这个问题至关重要。这也是为什么许多规模化的 Scrum 方法会实施大使或网络集成团队来最小化跨团队互动的原因。

在精益系统中，理想的目标是通过价值流创建一套简化的活动流程，类似于装配线，使得工作可以通过一系列独立的活动按一个方向流动，而无需返回到先前的活动。从图 3.2中展示的例子应该能明显看出，线性顺序的流动方式要简单得多，且更为精简。还应该清楚地看到，随着价值流系统中活动（节点）数量的增加，网络密度问题变得越来越迫切需要解决。

到目前为止，我们的示例系统交互非常简单。现实生活要复杂得多，因为每个系统交互可能会产生不同类型的影响。元素之间的复杂系统交互被建模和分析为因果链。但是，在我们深入探讨这个话题之前，让我们花点时间来介绍系统思维的词汇。

学习系统思维的词汇

系统思维的词汇是独特的，并不直接与敏捷或精益实践相关联。但系统思维背后的概念非常强大且有用，有助于团队在分析大规模复杂业务系统中的元素及其相互关系时进行协作。以下是系统思维及因果环图中常用的基本术语列表：

• 系统：这些是由有形和无形事物、原则、程序以及社会和政治环境组成的复杂结构，这些元素共同服务于某种目的或功能。

• 元素：该术语指构成系统的各个部分的集合。这些部分可以是有形的或无形的事物、原则、程序或参与并引导系统行为的社会和政治环境。

• 相互连接：这些关系——包括物理、信息、正式或非正式的联系——将元素联系在一起，形成系统内部的纽带。

• 功能：非人类系统的目的、目标或意图。

• 目的：以人为基础的系统的目的、目标或意图。

• 库存：这些是系统内可量化、可测量的变量，受流动行为的动态变化影响。元素一词指在任何给定时刻的事物类型；库存一词则指在特定时刻，元素的属性及其可观察的数值。例如，一个元素可能是价值流活动，而其库存可能是工作项或材料。

• 流动：这些动作动态地改变系统内库存的方向，包括流入和流出。

• 流入：这些表示一种流动方向，用于增加可测量的库存量。流入显示通过带箭头的线条指向正在积累库存的元素。

• 流出：这些表示一种流动方向，用于减少可测量的库存量。流出显示通过带箭头的线条指向远离库存减少的元素。

• 延迟：当流入大于流出时，会发生延迟，导致库存积累。延迟的显示通常在连接元素的箭头上标注延迟字样，或在连接箭头上画上双井号。

• 反馈回路：这些是调节流动的机制，旨在使系统稳定或在系统内强化某一特定趋势。

• 平衡反馈回路：这些提供信息或资源，使系统或元素达到平衡，并保持在期望的范围内。

• 增强反馈回路：这些提供信息或资源，支持系统内的趋势或支持系统内的元素。该趋势可以是正向或负向的。

• 因果回路图（CLD）：一种将系统内元素（即变量）之间的相互关系可视化的方法，将元素表示为节点，节点之间的联系表示为链接（即边）。

• 正因果联系：这意味着两个连接节点之间的因果关系会导致观察到的属性朝相同（正向）方向变化，从而增加监测属性的值。

• 负因果联系：这意味着两个连接节点之间的因果关系会导致观察到的属性发生相反（负向）变化。

• 开放系统：这些系统的特点是存在系统外部的流入和流出——也就是说，能够进入或离开系统的事物。

• 封闭系统：这些系统的特点是系统内没有任何流入或流出——也就是说，系统完全自给自足并且平衡。

• 标签：在因果图中的所有元素上使用标签，以便评审人员了解这些元素和链接在系统模型中所代表的意义。

现在你已经了解了系统思维和因果循环图的基本术语，我们来快速看看在分析基于敏捷的开发团队作为一个系统时，如何使用它们。

可视化系统元素之间的相互关系

本节使用了前一本书《Scaling Scrum Across Modern Enterprises》中的一个 CLD 示例，描述了基于 Scrum 的 Sprint 规划过程（见图 3.3）。本练习的目的是并非解释 Sprint 规划过程，而是展示 CLD 建模过程如何运作，并以敏捷为参考。再次提醒那些希望更详细理解如何使用系统思维和 CLD 技术来评估精益敏捷流程的读者，我建议你们阅读《Scaling Scrum Across Modern Enterprises》一书。

这里展示了一个 Sprint 规划的示例：

图 3.3 – Sprint 规划因果循环图（CLD）

需要注意的是，CLD 中的箭头总是关闭系统循环，以显示一个强化或平衡的反馈回路。换句话说，所有 CLD 节点都会连接回入口点，形成一个回路，无论系统多大或多复杂，都能产生强化或平衡的效果。

强化回路是一个循环，其中改变一个变量会在系统中传播，导致某一趋势的增强或减弱。相比之下，平衡回路是一个循环，其中改变一个变量的效果会传播通过回路，并迫使系统做出反应，以抵消新的趋势。我们为 Scrum 基础的 Sprint 规划过程所举的 CLD 示例就是一个强化回路的形式，因为进入 Sprint 待办事项清单的工作项减少了产品待办事项清单中的工作项数量。

在因果循环图（CDL）中，我们用线条表示流动，箭头表示这些流动的影响。例如，正箭头（+）表示一个正向因果关系，趋势朝同一方向发展，而负箭头（-）则表示负向因果关系，即相反的趋势。

在这个模型中，客户和最终用户的需求来自于 Sprint 评审（即上一个增量的演示）或直接来自外部源。这种关系是正向因果关系，因为趋势朝同一方向发展。换句话说，随着客户和最终用户提出新的需求，潜在工作项的流量会增加。

相反，请注意产品积压中项目数量与精炼项目数量之间的关系，这是一个负向因果关系。这个关系表明，精炼过程通常会减少从积压中流出的工作项目数量。

阅读 CLD

在本章结束之前，让我们回顾一下 Sprint 规划过程（在上一章的图 2.10中展示）。这个练习将帮助你理解如何评估 CLD 模型中描述的各个关系。

Sprint 规划是基于 Scrum 的敏捷方法的一部分。我之前提到过，在我以前的书中有 17 个 CLD 模型。然而，这 17 个 CLD 模型跨越了三个不同的过程：

• Sprint 规划

• 从项目到产品团队的转型

• 企业实施的 Scrum

这三个 CLD 模型都与分析 IT 功能相关，但每个模型的范围和目标各不相同。例如，Sprint 规划模型由五个独立的 CLD 组成。五个 CLD 大致分为团队可能希望分析的特定关注领域。这些领域包括：

• 分析产品积压优先级的 CLD 模型

• 产品积压精炼活动的开放 CLD 模型

• 设计和工作澄清的 CLD 模型

• 分析工作与团队能力的 CLD 模型

• 谈判和权衡活动的 CLD 模型

只有一个结果 Sprint 规划的 CLD 模型，但团队可能更愿意根据关注点逐步拆解工作，并逐步构建 Sprint 规划 CLD 模型。现在让我们简要看一下这些子 CLD 模型。

分析产品积压优先级的 CLD 模型

这个 CLD 模型的目标（见图 3.4）是理解构建客户和最终用户需求积压的相关元素。模型如下所示：

图 3.4 – 分析产品积压优先级的 CLD 模型

客户和最终用户的需求流入或通过 Sprint 回顾过程以及超出本 Sprint 规划 CLD 模型范围的外部过程。带有正号（+）的箭头表示正向因果关系，意味着趋势或影响朝同一方向发展。换句话说，需求的增加会使产品积压中的项目数量增加。

但请注意，这个正向因果关系并不意味着流程仅仅是一个加法过程。箭头上的（+）和（-）符号并不表示数学上的加法或减法过程，只是表示流程是否强化了某个趋势。因此，正向（+）的流向作为元素之间的关系，也意味着需求的减少。这导致产品积压中项目存量的减少。

产品积压精炼活动的开放 CLD 模型

这个 CLD 的目标（见图 3.5）是理解涉及精炼产品待办事项列表中的工作项的元素。具体来说，这意味着将史诗分解为用户故事，并理解开发任务。我们可以在以下图中看到这一点：

图 3.5 – 产品待办事项精炼活动的开放 CLD 模型

图 3.5中显示的示例包括具有负趋势（-）的箭头，这意味着元素之间的关系是负向因果链接，涉及待办事项列表中的项目数量和已精炼的产品待办事项列表项目数量之间的关系。产品待办事项列表中已精炼项目的数量与待办事项列表中的优先排序项目数量之间也存在类似的负向因果链接。

初看时可能有些难以理解，特别是对于那些不了解细节的人。负向因果链接表示，当链接开始的节点增加时，另一个节点会减少，反之亦然。换句话说，精炼和优先排序活动对工作项的存量有对立作用。这种对立效应发生是因为团队能够精炼和优先排序的工作量是有限的。

举个例子，假设客户希望将一个新功能包括在下一个发布版本中。该项目作为史诗或用户故事被加入到产品待办事项列表中。该项目必须经过精炼，以确保团队完全理解需求，并确定其优先级。负向链接表明，精炼后的项目数量趋势与最初进入待办事项列表的项目数量趋势相反。

同样的趋势出现在产品负责人决定哪些精炼后的工作项具有高优先级时。然而，这些高优先级的工作项会使 Sprint 目标朝同一方向发展。换句话说，高优先级工作项的数量增加，Sprint 目标的范围也会增加。同样地，如果精炼和优先排序后的工作项数量减少，Sprint 目标的范围会变小。

设计和工作澄清的 CLD 模型

下一个 CLD 的目标（见图 3.6）是理解设计和工作澄清的 CLD 模型中涉及的各个元素。这个 CLD 是工作项设计和范围界定活动的可视化。请注意，元素之间的所有关系都有正向因果链接：

图 3.6 – 设计和工作澄清的 CLD 模型

在这个 CLD 中，团队需要从产品负责人和其他来源（如客户和最终用户）获得对需求细节的澄清。改进澄清细节能够改善设计和界定工作范围的能力，反之亦然。

请注意，模型的另一部分也有一个正向因果关系，描述了产品待办事项中根据优先级确定的 Sprint 目标。理解 Sprint 目标有助于更好地理解设计需求和工作范围。

最后，定义设计要求 元素与 确定工作范围 元素之间存在正向因果关系。随着团队对设计的理解加深，他们能够更好地理解即将到来的 Sprint 中的工作范围。

分析工作与团队能力对比的 CLD 模型

这个 CLD（见图 3.7）旨在理解分析工作与团队能力对比的 CLD 模型中涉及的元素。虽然这是一个更大、更复杂的 CLD，但概念保持不变，我们只需通过其关联进行分析：

图 3.7 – 分析工作与团队能力对比的 CLD 模型

如果没有将这部分 CLD 与整个 Sprint 计划 CLD 一起考虑，就很难确定应该从哪里开始。然而，我们应该从标题为 定义的 Sprint 目标与产品待办事项优先级的关系 的元素开始。在接下来的子章节中，我们将看到这个 CLD 中的交互如何通过 Sprint 待办事项节点中的项目数量 导出到另一个 CLD。同时，请注意，这个 CLD 包含多个较小的 CLD 循环。各项活动通过参与评估团队能力与待办事项优先级之间的关系而相互连接。

这个 CLD 的重要性在于它定义了必要的元素和交互，旨在在团队能力和他们围绕 Sprint 计划工作自组织的能力的背景下定义初步任务。最终，这些关系导致了对 Sprint 待办事项中添加的工作项数量（和类型）的决策。请注意，这些项目还强化了产品在 Sprint 中开发的设计标准。

谈判与权衡活动的 CLD 模型

这个 CLD（见图 3.8）的目标是理解谈判与权衡活动的 CLD 模型。前一个 CLD——分析工作与团队能力对比——中的元素和互动影响了与设计相关的决策。但请注意，团队增加了一个 CLD 循环，用于分析与设计相关的影响与他们的能力对比，以确定是否需要与产品负责人进行权衡和谈判。例如，可能存在需要在处理一些更高优先级的工作项之前解决的技术债务问题：

图 3.8 – 谈判与权衡活动的 CLD 模型

我们现在已经完成了对整个 Sprint 计划 CLD 和本章主题的回顾。关于 CLD 建模，关键的事情是没有普遍的真理。在你的价值流中有效的方法，在另一个组织的价值流中可能不适用，尽管它们的目的可能相似。

在下一章，我们将深入探讨价值流管理的基础，作为一种以精益为导向的建模和可视化工具。但在此之前，让我们总结一下你在这一章学到的内容。然后，进行快速测试，看看是否有任何需要复习的地方。

小结

在这一章中，你学到了系统比其部分的总和复杂得多。随着参与元素数量的增加，潜在连接和相互作用的数量呈几何级数增长。你学会了如何运用系统思维来分析元素及其关系的复杂性。你还学会了系统思维的词汇，并了解了如何使用 CLD 作为建模和可视化技术来处理复杂的相互关系。接下来，你将运用你新获得的系统思维和 CLD 可视化知识来回顾 Sprint 规划过程。最后，你了解到系统思维与价值流映射在建模和可视化流程上的方法是不同的。

通过这些知识，你现在具备了评估系统中参与元素及其相互关系的能力——这些关系通过相互作用贡献了复杂性。系统思维是一种分析方法，用于理解相互连接和交互元素的影响、原因和效果。相比之下，价值流映射是一种评估当前和未来工作方式的技术，然后找到改进的方法。

系统思维为我们提供了发现和评估相互关联元素影响的工具，而价值流映射则为我们提供了改善工作和信息流的工具。我们将在下一章探讨价值流管理的组成部分。

问题

1. 系统思维的价值是什么？

2. 系统内元素之间的两种关系类型是什么？

3. 为什么我们要建模系统内元素的连接和相互作用？

4. 在因果回路图中，闭环的目的是什么？

5. 什么是一个多节点系统的最简配置？

6. 确定系统中潜在连接数量的公式是什么？

7. 为什么我们要尝试减少实际连接的数量？

8. 计算网络密度的公式是什么？

9. CLD 图中的箭头有什么作用？

10. 正向因果关系和负向因果关系有什么区别？

进一步阅读

• Rupp, C.G., (2020) Scaling Scrum Across Modern Enterprises: 在大型组织中实施 Scrum 和 Lean-Agile 技术，跨复杂的产品、组合和项目。Packt 出版，伯明翰，英格兰

第四章：定义价值流管理

价值流管理（VSM）正在迅速成为 信息技术（IT）领域的核心能力，特别是作为评估和消除软件交付过程中的非增值活动（浪费）的一种手段。然而，VSM 并不是一个新概念。在本章中，您将了解 VSM 的起源及其在精益生产、供应链、办公和 IT 定向流程中的应用。

VSM 提供了一种方法，系统性和持续地评估所有组织的开发和运营价值流。VSM 实践和工具有助于改进所有价值流，而不仅仅是 IT 领域的价值流。VSM 项目的目标是确保我们的价值流最为高效，与公司战略保持一致，并以最小的浪费为客户创造价值，但没有必要学习多个 VSM 策略。

在本章中，您还将学习 VSM 的基本方法和工具。具体来说，您将了解一种通用的八步 VSM 方法，用于规划、映射和维持精益改进。本书旨在教授一种经过验证的方法，而不是学习一种高度针对特定 VSM 工具集的方法，无论价值流的应用或工具如何。

VSM 八步法总结如下截图：

图 4.1 – VSM 八步法

采用这种通用方法来处理 VSM 的原因是，在我们的数字经济中，IT 解决方案通常支持其他组织的价值流，且在过程中变得不可分割。因此，理解 VSM 的基本概念至关重要，因为每个基于 IT 的 VSM 项目都必须支持组织的更广泛目标，以在所有价值流中构建并维持精益企业。

稍后，在本书的 第二部分 中，我们将深入探讨基于 IT 的 VSM 实践案例。在此以及接下来的两章中，我们的重点是学习 VSM 的基本要素，而不考虑其应用。

在本章中，我们将涵盖以下主要内容：

• 实施精益理念

• 确定价值流

• 应用 VSM 方法和工具

• 定义 VSM 的八个步骤

技术要求

本章没有特定的要求。

实施精益理念

VSM 基本上涉及在组织内实施精益理念，并将精益开发和交付过程变为一种生活方式。VSM 被应用于简化以开发和运营为导向的工作，以便在现代精益实践中更加高效地交付以客户为中心的价值。在此背景下，基于 IT 的开发和运营活动是组织价值流，同样可以通过运用 VSM 功能受益。

具体来说，VSM 支持 IT 部门通过实施持续集成（CI）和持续交付（CD）能力，通常作为更大范围的DevOps过程集成、自动化和协作策略的一部分，推动其精益化。换句话说，使用 VSM 来推动 DevOps 开发和交付能力，本质上是组织实施 IT 价值交付的精益价值流策略。

在他们的书《价值流管理：八个步骤规划、绘制和持续精益改进》中，作者对 VSM 的定义如下：

"价值流管理是一种通过简单的数据捕捉和分析来规划和连接各项举措的过程。"（Tapping, Luyster, Shuker, 2002，第 2 页）

请注意，他们对 VSM 的定义不仅限于在 IT 价值流中进行精益生产改进。事实上，这些作者共同撰写了三本书，应用可重用的 VSM 方法论于制造业、精益行政办公室以及医疗保健价值流中，正是他们的八步方法论被应用于本书的第二部分《实施价值流管理（VSM）方法与工具》中，用于分析、规划和执行 CI/CD 管道流动用例场景中的精益改进。我们将在本章的后续部分应用 VSM 方法与工具中介绍 VSM 的八个步骤。

在我们现代的数字经济中，IT 几乎支持着每一项组织活动。因此，VSM 实践不能仅仅聚焦于改善 IT 价值流。相反，面向 IT 的 VSM 有助于改善整个企业的所有价值流活动。此外，由于组织价值流往往是相互关联的，我们必须改善跨所有连接价值流的客户交付流。

让我们来看一个快速的例子。在我们的场景中，一个客户有兴趣购买一款可定制的产品，因此他们上网访问供应商的网站查看可选项。在网站上，他们决定购买的产品并提交了订单。订单触发了其他价值流活动，涉及下单、付款、更新会计系统、订购替换材料、执行生产，最终执行组织的下游履行或供应和支持流程。在此过程中，IT 系统从头到尾发起这些流程，确保正确的信息和材料在正确的时间和地点出现。因此，所有的组织价值流在某种程度上是相互关联的，而 IT 价值流作为一个至关重要的推动力发挥着作用。

在本书的进一步阅读部分，你可以看到一些书籍列表，这些书籍专注于将 VSM 应用于制造业的精益生产过程、精益办公、精益供应链和精益 IT 价值流。在一个真正的精益企业中，所有的组织价值流都需要持续改进，并与其他关联的价值流进行协调。这就是 VSM 的前提。

实施信息流

在数字经济中，每个价值流都有信息流。在许多情况下，数字价值流的材料是信息元素（表单、图形、商业智能（BI）、原始数据或信息支持服务）。在前一段中，你了解到信息流对支持精益生产过程至关重要，但信息流同样对支持所有前端和后端价值流过程至关重要。

前端过程直接帮助客户，而后端过程则包括所有不需要面对面互动的内部支持活动。例如，前端过程包括销售支持活动，可以通过人员或在线产品信息系统进行。同样，组织的客户支持过程也是前端过程的例子。相反，后端过程的例子包括供应和合作伙伴管理实践以及履行。

换句话说，前端和后端这两个术语与产品生命周期中的顺序无关。相反，可以将前端理解为指那些在客户面前进行的过程，而后端过程则发生在幕后。

然而，在精益术语的词汇中，我们使用上游和下游这两个术语来指示产品生命周期中活动的关系，如下图所示。在精益中，客户始终是我们的关注点，因此，产品或服务的交付是最终的精益过程目标：

图 4.2 – 上游与下游价值流活动

在这个背景下，精益价值始终是向下游流动的，任何前面的活动都是上游的。同样的概念适用于每个价值流。离客户最远的活动总是位于离客户最近的活动的上游。

在图 4.2中进一步阐述了上游和下游的例子，价值流包括一系列材料和信息的组合，这些材料和信息在每个后续的价值流活动中逐步积累，直到准备好作为产品或服务交付给客户。

定义价值流的类型

价值流一词在现代精益环境中已经扩展为包括企业内部所有增值和非增值活动。一些价值流直接有助于产品和服务的开发，而另一些则专注于面向运营的活动，以交付产品和服务。

精益企业研究院（LEI）对价值流的定义如下：

“所有的行动，包括增值和非增值的，都是将产品从概念到发布（也称为开发价值流）以及从订单到交付（也称为运营价值流）所必需的。这些包括从客户处处理信息的行动和在产品向客户交付过程中转化产品的行动。”

– 摘自《精益词汇》，第 5 版

请注意，价值流的定义包括了处理来自客户的信息所必需的行动。同时，回顾一下丰田最初将价值流映射称为物料和信息流映射。在精益中，我们致力于改善物料和信息流，以高效地提供以客户为中心的价值。在本章中，您将了解为何基于 IT 的策略在推动和维持企业精益计划中的重要作用。

现代的 VSM 系统提供了一套方法和工具，用于绘制现有和未来的活动图，定义改进的指标，并监控我们在绩效目标上的进展。此外，分析工具提供了评估因果关系的能力，并在做出承诺和投资之前，模拟不同的业务改进策略。

我们将在本章稍后更深入地理解 VSM 如何帮助识别和改进价值流。但在此之前，让我们先花点时间理解一下价值流和 VSM 背后原始而仍然重要的概念。

使用 VSM

VSM 作为一个概念已经存在了一段时间。有趣的是，20 世纪 90 年代的 IT 领导者之一詹姆斯·马丁在他的著作《伟大转型：使用企业工程的七个学科来对齐人员、技术和战略》（马丁，1995 年）中，将价值流一词应用于软件开发实践。马丁的书籍出版不到一年后，詹姆斯·沃马克和丹尼尔·琼斯在《哈佛商业评论》上首次提出了这一术语，文章名为《从精益生产到精益企业》（沃马克和琼斯，1994 年 3-4 月）。

在第 104 页，马丁将价值流一词定义为“由‘客户’（可能是最终客户或价值流的内部‘最终用户’）产生的一系列端到端活动”。

注意

VSM这一缩写代表价值流管理，与价值流图示（value stream mapping）所使用的缩写相同。这一缩写的重复使用是一个不幸的巧合，因为价值流图示是整个 VSM 过程的一个子集。为了保持清晰，书中所指的VSM始终表示价值流管理。为了进一步减少可能的混淆，本书将始终拼写出价值流图示，或缩写为VS 图示或VS 绘图。

虽然詹姆斯·马丁定义了“价值流”这一术语，但在描述改进价值流的活动过程时，他倾向于使用“价值流重塑”这一术语。马丁对使用“过程”这一术语以及业务流程重组（BPR）这一概念持有异议。

在第一个案例中，马丁认为“过程”这个词过于宽泛，且远离精益理念中增值、以客户为中心的概念。他对“BPR”这一术语的主要问题在于，他认为他那个时代的大多数过程根本没有经过设计。相反，大多数业务流程是为了支持层级化的商业结构而演变出来的，其中的活动往往更多地与保护组织的领地和权威相关，而非提高效率。

后来的其他作者在他们的书中引入了VSM这一术语，包括以下内容：

• 价值流管理。规划、绘制和维持精益改进的八个步骤。唐·塔平（Don Tapping），汤姆·莱斯特（Tom Luyster），和汤姆·舒克（Tom Shuker）（精益生产，2002）。

• 精益办公的价值流管理。规划、绘制和维持行政领域精益改进的八个步骤。唐·塔平（Don Tapping）和汤姆·舒克（Tom Shuker）（精益办公，2003）。

• 价值流管理。供应链中的战略与卓越。彼得·海因斯（Peter Hines），理查德·拉明（Richard Lamming），丹·琼斯（Dan Jones），保罗·考辛斯（Paul Cousins），尼克·里奇（Nick Rich）（普伦蒂斯·霍尔/皮尔逊教育，哈罗，英国，2000）。

汤姆·舒克（Tom Shuker）非常慷慨地授权使用他们的八步流程作为本章的示例，展示如何在整个组织中实施 VSM 战略。这一八步 VSM 流程帮助组织通过精益规划简化需求、流动和平衡等基本精益概念，并帮助实施整体流程以加速、协调和持续精益工作。

是的——这是一本关于 VSM-IT 转型应用的书。但请问自己这个问题：在数字经济中，我们到底在改善哪个商业价值流？为了回答这个问题，让我们回顾一下詹姆斯·马丁（James Martin）关于这一主题的原始和开创性著作。

确定价值流

詹姆斯·马丁（James Martin）从根本上理解了为什么企业组织投资于信息技术（IT），以实施和维持支持其价值流的卓越业务流程。马丁超越了时代，但他的思想依然延续——例如，开放组架构框架（TOGAF）在其业务架构标准中仍然运用了詹姆斯·马丁的价值流概念（开放组指南，价值流，2017 年 1 月）。

但詹姆斯·马丁使用“价值流”一词时到底是什么意思呢？马丁不仅仅是寻找改进 IT 开发和运营过程的方法。他的目标是帮助组织重构其价值流，并实施软件应用程序来支持、维持并持续改进所有价值流中的价值交付。

在他的书中，詹姆斯·马丁引用了 T.H. 达文波特（T. H. Davenport）发表的《过程创新》一书中的研究，该研究发现，在 5 家大型企业中，平均有 14 个价值流。参与的公司包括IBM、Ameritech、道化学公司、施乐以及一家大型但未透露名称的保险公司（哈佛商学院出版社：波士顿，1993 年）。

马丁综合了达文波特论文中的研究，识别出了 17 个典型的价值流（马丁，1995 年，第 107 页）。他列出的 17 个传统的业务价值流包括以下内容：

• 客户互动：获取客户、了解客户需求；销售，确保客户满意

• 订单履行：接收订单，履行订单，收取付款

• 客户服务：向客户提供诸如使用产品帮助、规划和咨询等服务

• 制造：生产商品、维护库存、与供应商互动

• 采购服务：协助选择供应商、签订合同和管理

• 产品设计工程：设计产品及其制造设施

• 研究：探索潜在的有价值的科学和技术

• 市场营销：确定客户需求，设计产品，哪些功能是必须的；广告宣传

• 市场信息采集：获取销售信息；收集竞争情报

• 产品维护：修理产品以及在客户现场进行预防性维护

• 法务部门：解决法律问题；起草合同

• IT-应用开发：开发和修改系统和软件

• IT 基础设施：建立公司范围的网络、数据库及分布式计算设施

• 人力资源（HR）：协助招聘、培训、薪酬、照护规划

• 租赁和资本资产管理：管理建筑物和资本资源

• 财务管理：会计、与银行谈判、现金管理

• 企业工程：设计、实施和改进价值流；工程化企业学习过程

现在我们对典型的面向业务的价值流有了更好的理解，接下来理解如何建立其边界和接口就显得至关重要。

建立价值流边界

每个价值流都有特定的起始和结束活动，这些活动确定了其边界。这个概念如此重要，以至于一些业务架构领域的人士通过其起始和结束活动来称呼他们的价值流（例如，从潜在客户到订单和从订单到交付的价值流）。James Martin 提供了选定价值流的起始和结束活动示例。

下表展示了 Martin 书中提到的价值流命名约定（Martin, 1995, 第 108 页，第 7.3 图表）：

图 4.3 – VS 命名约定

现在你已经理解了如何应用价值流边界和命名约定，我们来看看价值流改进如何帮助交付商业价值。

改善商业价值

重要的是要记住，James Martin 在撰写他的书《伟大转型》时，几乎所有的企业仍处于利用 IT 支持其关键业务流程的早期阶段。Don Tapscott 在 1995 年出版的《数字经济：网络智能时代的承诺与风险》一书中创造了“数字经济”这一术语，这与《伟大转型》出版的年份相同。但 James Martin 和 BPR 以及业务流程改进（BPI）领域的其他人已经理解到，重新设计或逐步改进业务流程，利用 IT 的新能力，具有重要意义。

企业必须在数字经济中开发更高效、更快速、更灵活的组织价值流，Martin 理解到其 IT 功能必须支持这些努力。Martin 对价值流重塑的看法是，替代传统的跨职能和孤立的业务流程，"采用一种新的工作流程，该流程快速、简单、尽可能自动化，并由一个专注于取悦客户的小团队（或个人）执行"（Martin, 1995, 第 64 页）。

James Martin 进一步指出，价值流重塑是一种改进策略，旨在回答几个根本性问题，例如以下问题：

• 组织的价值流是什么？

• 谁是价值流的客户？

• 客户需要什么？

• 我们需要做些什么才能让这些客户满意？

作为在数字经济中工作的 IT 专家，我们必须问自己这个根本性问题：如何利用 IT 和软件应用程序，以尽可能高效、低成本、快速地支持组织的以客户为中心的价值流？

从精益的角度来看，答案是多方面的，且从概念层面理解并不难：IT 组织支持自动化和集成组织的价值流活动，同时提高价值流信息流的准确性和及时性。在许多情况下，IT 还支持在实体产品中实现数字功能和特性。

我们现在明白了利用 IT 提升商业价值交付的重要性。接下来，让我们深入了解为什么组织的高级管理人员必须推动这一努力。

引领变革

精益策略并不容易实施。精益开发和交付活动通常需要对组织及其设施进行一定程度的结构调整，实施新的业务流程和设备，发展新的技能，并在 IT 上进行投资。只有组织的最高管理层或业务线（LOB）高层才能授权这些变更。

本书的一个主要主题是支持企业规模的精益计划，做出明智的 IT 投资，包括技能和工具。不幸的是，改变组织结构、发展新技能和投资新的 IT 方法与工具依然是一个困难的任务。有无数的技术和产品选择需要调查，大多数都需要额外的时间和资源来进行配置和集成工作。

这些是领导力必须发挥作用的领域。与其他企业精益（Lean）计划一样，只有高层领导才能指导价值流图（VSM）战略，并进行必要的工具、基础设施、集成和配置投资。将 DevOps 纳入其中会增加这些投资成本。我们稍后将在第六章《启动 VSM 计划（VSM 步骤 1-3）》中讨论这个话题，即 DevOps 工具、基础设施、集成和配置方面的投资。

持续集成（CI）、持续交付（CD）和 DevOps 能力已经发展到一个阶段，IT 部门能够更好地支持詹姆斯·马丁（James Martin）在 1990 年代提出的理念；此外，价值流图（VSM）提供了一套方法和工具，帮助并指导组织的精益转型。然而，所有这些能力都需要投资，高层领导必须获得足够的知识，才能做出明智的投资决策。

你可能不是高层管理人员或业务线高层，但你依然可以在你在组织中的职位或角色中提供教育、思想领导力和支持。一个组织在精益计划上的成功依赖于每个人的参与和支持。

为了便于讨论，我们假设组织得到了高层支持，并且愿意进行必要的结构调整，安装经过培训的导师和教练，并投资于必要的技术和工具。那么，下一个问题是：如何启动并执行持续的价值流映射（VSM）策略？ 这个问题将是本章最后部分的主题。但在讨论这个主题之前，让我们快速了解一个关键的 VSM 可视化和分析工具——价值流映射。

价值流映射

本节的目的是解释价值流映射的重要性。稍后，在 第七章中，映射当前状态（VSM 第 4 步），你将学习如何创建价值流图，这是一种评估当前（现状）和未来（目标状态）过程的技术。价值流映射帮助 VSM 团队评估完成所需工作量，以过渡到理想的未来状态，旨在精简价值流活动，最小化浪费，并提供以客户为中心的价值。我们将继续使用价值流映射来帮助指导并优先排序我们的持续改进（CI）活动。

丰田起源了价值流映射技术，但他们将这一实践称为物料和信息流映射。换句话说，丰田明白，即使是在分析制造过程时，改进信息流与改进物料流同样重要。

及时且准确的信息是支持制造组织内部物料流动的必要条件。如果信息流动不畅，生产过程会因为正确的物料未能在正确的时间、正确的数量到达而被延误，从而影响精益生产过程。当然，客户订单信息必须与物料一起流动，以确保为每个客户制造正确的产品集。

詹姆斯·马丁也是早期的价值流映射倡导者之一，他在他的书《伟大的转型》（Martin, 1995）中 dedicates 一个章节专门讲解价值流映射，章节标题为 第八章。然而，马丁的方法早于迈克·罗瑟（Mike Rother）和约翰·舒克（John Shook）在他们的书《学习看见》（Rother, Shook, 1999）中提出的现代价值流图技术。

本书讲授了罗瑟和舒克提出的现代价值流映射方法，后来由凯伦·马丁和迈克·奥斯特林在他们的书《价值流映射：如何可视化工作并对齐领导力以进行组织转型》（Martin, Osterling, 2014）中进行了更新。现代的价值流图结合了活动和信息流数据，这些数据对于评估价值流中精益状态至关重要。相比之下，詹姆斯·马丁的价值流图采用的是一种相对传统的过程流图技术。

无论您的组织偏好哪种建模技术，都必须确保采用标准化方法，并且每个人都经过相关技术的培训。否则，VSM 团队可能会在沟通、解释和分析中遇到问题。

在我们讨论价值流的过程中，理解这一基本概念至关重要：所有的价值流代表了跨越整个组织的端到端价值流动。在这个背景下，精益价值流的运作类似于亨利·福特第一代 T 型车组装线背后的大规模生产概念。一个关键的区别是，精益生产结合了拉动式生产和订单管理生产过程，而不是推式生产控制策略。暂时不讨论推式与拉式生产控制策略的概念，大规模生产和精益生产共享同步和自动化流动的概念。

例如，客户订单记录了一个新需求，启动了产品的生产或交付。生产过程遵循一个围绕初始组件的价值流，例如前面提到的 T 型车生产示例中的车架。另一个例子是在计算机系统组装过程开始时，构建笔记本电脑或服务器的机架或底盘。在这两种示例中，当这些车架穿越生产线上的各个活动时，额外的价值组件（如材料、零件和信息）会被添加到产品中。在精益的术语中，我们在价值流过程的每一步都会为产品添加价值。

以下截图展示了现代汽车组装线的一个画面。尽管使用了机器人技术和其他自动化能力，但亨利·福特最初的大规模生产概念仍然保留，作为一个端到端的同步过程：

图 4.4 – 汽车组装线

本书并非讨论如何在制造业中实施精益流程——对于这类信息，有许多其他优秀的资源。然而，我们将讨论如何将 VSM 应用于面向开发的流程，组装线就是其中一个例子。此外，我们还将讨论如何使用 VSM 来支持面向运营的价值流，这些流程更多地涉及前台和后台的工作。

如前所述，前台操作流程面向客户，而后台操作流程通常是行政性的。与面向开发和运营的价值流一样，所有业务流程都可以通过应用 VSM 方法和工具来实现精益化并进行改进。

在使用了前台和后台这些术语后，请注意，您很可能会决定，在您的组织中，并没有一个固定的标准来评估从客户视角出发的增值活动。价值流并不受组织层级、技能或业务职能的限制。价值流是一套从初步请求到交付所需的端到端活动。这些活动的客户可以是组织内部的，也可以是外部的。

在下一章中，我们将探讨如何将 VSM 实践作为一个由八个步骤组成的结构化过程来实施。然而，在进入下一章之前，让我们先快速浏览一下规划、绘制和维持精益实践的八个 VSM 步骤。

应用 VSM 方法和工具

每个 VSM 工具供应商都有其独特的 VSM 流程，通常根据其业务起源和软件工具的重点或优势进行定制。我们不需要软件工具来实施 VSM 能力，尽管它们是一个巨大的推动力。然而，在投资 VSM 工具之前，我们必须首先了解实施 VSM 实践背后的基本概念和方法。

如本书所述，VSM 实施遵循 Don Tapping、Tom Luyster 和 Tom Shuker 在其《价值流管理》一书中概述的八个步骤（Tapping, Luyster, Shuker, 2002；Tapping, Shuker, 2003）。具体来说，这八个步骤引导组织通过 VSM 过程来规划、绘制和维持精益改进。

以下截图介绍了八个 VSM 步骤：

图 4.5 – 八步骤 VSM 过程来规划、绘制和维持精益实践

与 Tapping、Luyster 和 Shuker 的书籍不同，他们的书籍聚焦于精益管理、精益医疗和精益办公，本书专注于将 VSM 应用于 IT。然而，请注意，IT 涉及到数字经济中组织内的所有事务。此外，正如 James Martin 所指出的，IT 的角色是通过精益计划支持组织的流程和价值流的重塑。因此，任何 VSM 计划很可能包括规划、绘制、改进和维持活动，作为一个参与式的价值流，但不一定是主要的价值流。

前面的段落指出了一个关键点。几乎所有现代的 VSM 工具都专注于对 DevOps 流程进行建模，以展示相关概念。改善 DevOps 价值流固然重要，然而 VSM 的更大好处来自于将 DevOps 活动与支持 IT 之外的企业精益计划相联系，包括面向运营和开发的价值流。

定义 VSM 的八个步骤

Tom Shuker 非常慷慨地允许我将他们的八步 VSM 流程纳入本书。在我们结束本章并进入执行他们 VSM 策略的细节之前，我们将快速回顾一下 Tapping 和 Shuker 如何定义他们的八个步骤，用于规划、映射和维持精益改进，具体如下：

1. 承诺精益 (步骤 1): 一个成功的精益计划需要高层领导和员工及利益相关者的支持。所有参与 VSM 计划的人员必须理解精益实践的重要性，以通过价值交付提供更可持续的业务。精益的目标是延长人力资源的价值，而不是裁减职位或采取捷径。

2. 选择价值流 (步骤 2): 我们不能在一夜之间在整个组织中实施和改进精益实践。识别和实施价值流改进需要时间和努力，优先级基于对最具价值、最低成本的工作的识别。此外，VSM 团队将继续识别并在产品生命周期内开展新的改进优先事项。

3. 了解精益 (步骤 3): VSM 旨在改进组织价值流中的精益实践。因此，所有 VSM 团队成员以及被分配到价值流中的员工必须具备操作精益生产系统的日常实践的卓越知识。

4. 映射当前状态 (步骤 4): 在完全理解系统如何运作之前就开始调整系统是危险的。我们需要了解我们的工作如何在价值流中流动，多少工作是增值的，多少时间花费在增值活动和等待之间。最后，我们需要识别其他形式的浪费，这些浪费增加了成本却没有增加价值。这些就是在映射我们开发或运营导向的业务实践的当前状态时的目标。

5. 识别精益指标 (步骤 5): 在完成当前价值流图后，VSM 团队将注意力转向识别可以帮助组织实现业务目标的指标。如果我们不首先识别客户的需求、潜在的浪费区域以及价值流的生产力目标，我们就无法评估未来 VSM 工作的成功。满足客户需求并消除浪费是降低成本并获得可持续产品价格的最可靠路径。

6. 映射未来状态 (步骤 6a)—客户需求: 这是构建我们所期望的未来状态计划的三个阶段中的第一阶段。目标是评估客户对我们产品和服务的需求。在这个映射练习中，我们输入了之前识别的精益指标，包括可接受的质量、单位需求量和所需的交货时间。

7. 绘制未来状态 (第 6b 步)—持续流动：这是未来状态绘制的第二阶段。目标是标准化工作执行方式，并找出如何组织工作、材料、零件和信息的流动，以便持续流动。在很多情况下，甚至大多数情况下，可能需要移动设备和办公隔间以改善流动。信息系统是另一个关键支持因素，帮助建立跨价值流活动的高效信息流动。还应采取措施，通过最小化活动设置、更换和周期时间之间的差异来平衡工作流。最后，我们应决定实施哪些生产控制策略，如准时制（JIT）、先进先出（FIFO）和看板（Kanban）。

8. 绘制未来状态 (第 6c 步)—平衡：这是未来状态绘制的最后阶段。在此阶段，我们应该已在价值流中安装了 Lean 实践，并最小化了影响生产力的更关键的浪费因素。现在，我们需要实施策略来平衡客户需求的流动。此 VSM 工作涉及实施基于拉动的策略，减少过度排队和等待，减少批量流程中与批次处理相关的队列和等待时间，并实施价值流的交付和提取系统——即看板卡片或看板文件夹以及工作项。

9. 创建 Kaizen 计划 (第 7 步)：VSM 实施以 Lean 为导向的变更，涵盖大规模和小规模的变化。Kaizen 计划概述了我们不断改进开发和运营导向的价值流的策略，但许多 Lean 导向的投资需要大量资金，而 VSM 团队无法授权。此外，计划中的变更可能需要多个规划周期来实施，其 Kaizen 计划可能随时间变化。因此，VSM 团队需要制定变更计划（Kaizen 计划），以使计划中的变更范围可见并得到管理。

   Lean 和 Agile 的关键区别在于，Lean 评估所有潜在的改进领域，不考虑所需的投资、权限、时间和资源。相比之下，Agile 的回顾性通常专注于小型 Agile 团队在下一个 Sprint 迭代中可以授权和完成的事项。

   Lean 和 Agile 的从业者都理解持续变革的重要性，但 VSM 更强调长期规划周期，并可能包括需要更多资本投资的变更，这些变更在 Agile 回顾性中通常不会考虑。

   最后，需求、问题和优先级随着时间的推移会发生变化，因此 Kaizen 计划需要定期审查和更新。创建和修改 Kaizen 计划是此步骤的主要活动。

10. 实施 Kaizen 计划 (第 8 步): 最后，我们需要实施所有我们制定的 Kaizen 计划。此外，我们还需要定期回顾和更新它们。商业中的一个常态是持续变化，因此我们需要不断改进精益实践，并保持与客户需求的对齐。我们还需要不断评估如何通过发现和消除额外浪费来改善我们的价值流活动。

现在，我们已经介绍了规划、绘制和维持精益改进的八个关键步骤，让我们更详细地了解每个步骤中发生的事情，从对精益的承诺开始。这是下一个章节的主题。

总结

这就是 VSM 的介绍章节。你已经了解到，VSM 提供了一种系统地、持续地评估所有开发和运营价值流的方法。VSM 的目标是确保一个组织始终与企业战略保持一致，并为客户提供以客户为中心的价值。

你还了解到，VSM 并不是一个新概念，相关的概念和实践支持在组织的价值流中实施和维持精益生产实践。组织通常拥有多个价值流。IT 领导者 James Martin 对以价值流形式进行业务流程的端到端重塑的需求进行了全面的讨论。Martin 还是价值流图绘制的早期倡导者，尽管他的方式早于我们将在第六章中使用的现代格式，即“启动 VSM 计划（VSM 步骤 1-3）”中所涉及的价值流绘制与改进。

最后，你现在可以识别出八个 VSM 步骤，用于规划、绘制和维持跨价值流的精益改进。在下一章中，我们将继续学习如何执行与 VSM 规划相关的步骤，包括承诺精益、选择 VSM 计划的价值流以及学习精益相关内容。

问题

为了增强你的学习体验，请花几分钟时间回答以下 10 个问题：

1. VSM 的主要或基本目的是什么？

2. 丰田如何称呼其价值流图绘制活动，这有什么重要意义？

3. 在精益生产的背景下，上游和下游之间的区别是什么？

4. 对还是错：价值流始终包括创造价值和非创造价值的活动。

5. James Martin 是如何定义价值流的？

6. 价值流有哪两种类型？

7. VSM 的八个步骤是什么？

8. 在承诺 VSM 计划时，建立坚实基础的五个关键要素是什么？

9. 哪个著名的原则或法则帮助指导你的 VSM 决策过程？

10. 用于识别价值流的良好命名规范标准和方法是什么？

进一步阅读

• Martin, J. (1995). 《伟大的转型》。运用企业工程的七大原则来对齐人员、技术与战略。美国管理协会，现为哈珀·柯林斯领导力的一个部门。纽约，纽约。

• Womack, J. P., Jones, D. T. (1994 年 3 月至 4 月). 从精益生产到精益企业。作者：詹姆斯·P·沃马克和丹尼尔·T·琼斯。哈佛商业评论. hbr.org/1994/03/from-lean-production-to-the-lean-enterprise 访问时间：2021 年 6 月 26 日。

• Open Group 指南。价值流（2017 年 1 月）。（必须注册才能访问） publications.opengroup.org/downloadable/download/link/id/MC45NDQ2MjkwMCAxNjA4MzM2NjcwNzM2ODYwNzU1OTU2MjUx/ 访问时间：2020 年 12 月。

• Tapping, D., Luyster, T., Shuker, T. (2002) 价值流管理。规划、绘制和维持精益改进的八个步骤。生产力出版社。纽约，纽约。

• Tapping, D., Luyster, T., Shuker, T. (2003) 精益办公室的价值流管理。规划、绘制和维持精益改进的八个步骤。生产力出版社。纽约，纽约。

• Tapping, D., Koslowski, S., Archbold, L., Speri, T. (2009) 精益医疗中的价值流管理。规划、绘制、实施和控制各种医疗环境中改进的四个步骤。MCS 媒体公司。切尔西，密歇根州。

• Gregory, L. (2018 年 9 月). 丰田的组织结构：一项分析。 panmore.com/toyota-organizational-structure-analysis 访问时间：2020 年 12 月 28 日。

• Ohno, T., Bodek, N. (1988) 丰田生产方式：超越大规模生产。生产力出版社。劳特里奇/泰勒与弗朗西斯集团。英福玛商业。伦敦，英格兰。（原版于 1978 年在日本出版）

• Hines, P., Lamming, R., Jones, D., Cousins, P., Rich, N. (2000) 价值流管理。供应链战略与卓越，普伦蒂斯·霍尔/皮尔逊教育。哈洛，英格兰。

• Martin, K., Osterling, M. (2014) 价值流图示：如何可视化工作并对齐领导力以实现组织转型。麦格劳-希尔教育。纽约，纽约。

• Rother, M., Shook, J. (2003) 学会看。价值流图示以创造价值并消除浪费。精益企业研究所。剑桥，马萨诸塞州。

• Jones, D., Womack, J. (2011) 看见整个价值流，第 2 版。精益企业研究所。剑桥，马萨诸塞州。

• Brenton, F. (2019) 什么是价值流管理？企业领导力入门指南。 www.forbes.com/sites/forbestechcouncil/2019/07/08/what-is-value-stream-management-a-primer-for-enterprise-leadership/?sh=50a0be77b678 访问时间：2020 年 12 月。

第五章: 通过 DevOps 流水线推动商业价值

在前四章中，你学习了有多种不同的方式来定义“价值”这一术语，以及理解其在特定语境中使用的重要性。因此，我们花了一些时间学习这些术语，以确保在讨论如何使用价值流管理（VSM）和 DevOps 交付以客户为中心的价值时，能够拥有共同的语义理解。

你学习了精益（Lean）和敏捷（Agile）实践如何互补，帮助组织交付以客户为中心的价值。你还学习了为什么我们需要采取系统思维的视角，在大型复杂的组织中改善价值交付。

本章解释了 IT 组织如何以及为何代表着两大主要职能之间非常复杂的系统：开发和运营。在传统的 IT 组织中，开发和运营部门作为独立的部门运作，分别进行不同的活动，每个部门有不同的关注点和文化。这种人员和职责的分离只会增加 IT 组织的复杂性。

本章将解释为什么 IT 组织中的这种职能分裂可能会成为一个问题。你还将学习到一种合作与集成策略，可以用来解决这些问题。这个策略被称为DevOps，即开发和运营的合成词。

本章所介绍的主题是我们在第二部分中将讨论的 VSM 工具和方法实施之前必要的前提。

在本章中，我们将讨论以下主题：

• 打破障碍

• 通过 DevOps 流水线改善流程

• 理解虚拟化

• 定义持续集成（CI）

• 定义持续交付（CD）

• 启用 CI/CD 和 DevOps 流水线流程

• 理解 DevOps 的范围

• 集成IT 服务管理（ITSM）

• 从项目转向产品

在本书第一部分的最后一章中，你将了解开发具有竞争力的 DevOps 流水线能力所涉及的不同技术、投资组合层级的投入以及真正的复杂性。让我们从理解导致 DevOps 在软件行业演变的商业驱动因素开始这段介绍。

打破障碍

现在，只需在互联网上快速搜索，你会发现许多行业分析师和评论员会同意，DevOps 已经成为在现代数字经济中有效竞争的基础（Dietrich, 2019）。那些掌握开发和运营 IT 价值流中各类活动工具的集成与自动化的组织，在软件交付的速度、质量和效率上有着数量级的优势。

正如精益实践在制造业和其他服务型公司中改变了竞争格局，DevOps 也同样改变了 IT 行业。具体来说，DevOps 流水线实现了一种软件开发策略，这与制造业及其他行业中的精益生产流程概念相当。因此，那些有效实施 DevOps 流水线的组织，在响应新的市场机会、不断变化的竞争压力和客户需求时，具有显著的竞争优势。

此外，DevOps 是精益（Lean）和敏捷（Agile）实践的结合，简称为精益敏捷（Lean-Agile）。敏捷提供了指导以客户为中心的软件开发实践的价值观和原则；而精益生产概念则提供了经过验证的方法，旨在消除浪费并实现高效的软件价值交付。正如你将在本书第二章中学习到的那样，现代的价值流映射（VSM）方法和工具使得组织能够在其 IT 价值流中实施精益转型。

DevOps 的概念在 2008 年开始浮现。具体来说，Andrew Shafer 和 Patrick Debois 因在同年举行的敏捷大会上，在一次私人会议中首次讨论了这些概念而受到认可。随后，DevOps 在 2009 年 Patrick Debois 组织的第一次DevOpsDays大会上变得广为人知，该会议在比利时举行。

需要注意的是，DevOps 起初是在敏捷系统管理中作为一种协作策略开始的。其目标是克服敏捷软件开发团队之间的冲突，这些团队现在可以更频繁地交付新的软件产品和功能（即，提高了速度），而传统上更为保守的系统管理组织则不愿接受这种变更。

CI 能力，我们将在本章稍后介绍（见定义 CI），使得开发人员能够提高应用交付到 IT 运维功能的速度。然而，原先并没有多少集成的流程或协作文化来促进新软件产品频繁发布到组织的测试和生产环境中。

在传统的 IT 组织中，开发和运维是两个独立的职能。它们有不同的目标和任务，也有不同的思维方式。软件开发人员在变化的环境中蓬勃发展，不断交付新的功能和能力。这是件好事，因为客户和用户希望获得能够增加价值的新功能，而且越快越好。

另一方面，系统管理员不喜欢变更，因为他们负责确保所有网络、系统和应用程序的运行、稳定和安全。简而言之，变更可能会破坏他们的系统、基础设施和安全性。而他们的犹豫是件好事，因为我们需要确保网络和软件的正常运作和安全。

可以将文化差异理解为这样的对比：开发人员擅长进行变更，并且当他们发布支持客户和用户需求的新功能时，会获得奖励。相比之下，运营中的任何变更都是可怕的——因为这些变更可能会破坏已部署的网络、系统和应用程序。更糟糕的是，当系统发生故障时，系统管理员将受到责备，而他们自己将承受所有压力，直到系统恢复正常运行。

共享责任

首先，DevOps 是一种沟通和协作策略。在这种背景下，DevOps 的目标是让两个团队以协调的方式共同工作，信息双向流动。开发人员需要了解为什么他们的新版本在生产环境中失败。相比之下，运营团队需要有关安装配置、系统管理和支持信息的详细信息，以及产品发布是否已经通过系统测试、安全测试、性能测试、负载测试和压力测试进行彻底测试。然而，当开发和运营团队因各自的责任、期望的结果以及成功标准的差异而分开时，这种协作几乎是不可能的。

开发团队经常希望发布他们已经构建并测试过、并且认为准备就绪的新版本。但由于运营团队传统上与开发团队分开工作，运营团队会不愿意发布新版本，直到确认该产品不会在生产环境中导致故障或其他系统配置、性能或安全问题。

当开发团队实施新变更时，运营部门负责确保一切在部署中正常工作。例如，运营团队可能会进行用户验收测试（UAT），这种测试本应在开发早期完成。如果软件失败，运营团队必须将错误和缺陷列表返回给开发团队，然后尝试将这些问题作为开发优先事项。

其他测试，如性能测试、负载测试、压力测试和系统测试，需要复制组织的生产环境。如果开发团队无法在其测试环境中完全复制生产环境，他们可能无法发现应用程序扩展中的潜在问题。这意味着，性能和集成问题可能要等到应用程序进入生产后才会被发现。即使那时，也可能需要一段时间，直到一组事件触发故障。结果，看起来像是运营团队的失误，实际上却是没有在类似生产环境中彻底测试系统的失误。

理想情况下，开发或运维团队会构建一个预生产或暂存环境，以模拟其生产环境。当这不可行时，运维团队可能被迫直接在生产环境中运行一小部分测试，尽管这样做是希望能够尽量避免问题，但仍然要做好应对最坏情况的准备。

运维团队的所有测试都需要时间来规划和执行。除此之外，这些测试只有在开发团队已经进入下一个迭代周期，开始开发新的特性和功能时，才会进行。运维团队发现的任何错误或缺陷都需要重新进入产品待办事项列表，以便重新排序和安排，这可能会延迟客户期待的新特性发布。而且，任何失败的发布责任和指责往往会转嫁到运维部门。

如果开发和运维团队仍然各自为政，这种文化上的障碍是无法解决的。利用你在第二章中学到的精益-敏捷概念，构建在精益-敏捷基础之上，组织需要整合、简化并协调信息和工作的流动，跨越 IT 开发和运维团队。

组织必须消除那些使这些职能相互隔离的障碍。对于较小的组织来说，消除沟通障碍可以简单地通过在每次发布之前让两个团队提前进行良好的沟通。然而，较大的组织可能拥有多个产品线、多个软件开发团队，甚至不同的运维支持团队。在这些情况下，沟通、整合和同步的挑战呈指数级增长。对于大型组织来说，消除开发和运维之间的隔阂的唯一实际方法是将这两项职能整合到产品团队或产品线中，并让每个团队成员对每次发布的速度和质量负有同等责任。

这种战略的实际影响是，开发和运维的活动必须与每个正在开发的产品紧密关联、简化并同步。换句话说，开发和运维需要作为一个单一的产品团队进行协作。

产品团队成员共同负责每一个新特性的发布，从创意到交付。产品团队还需要有效地支持产品生命周期中的运维相关活动。

另一个问题源自两个 IT 组织——开发和运维——的速度不同。传统上，运维团队需要更多的时间来管理将新版本部署到组织的生产环境中所带来的风险。速度上的不匹配会造成瓶颈，进而减缓新特性发布到生产环境的速度。

在下一部分，你将学习现代CI和CD功能如何解决这些问题。

通过 CI/CD 管道改善流动

在第六章**，启动 VSM 倡议（VSM 步骤 1-3）到第十一章，识别 VSM 工具类型和功能，我们将使用你在本节中学到的概念作为一个用例，介绍如何利用八步 VSM 方法学来改善 CI/CD 管道中的工作和信息流。然而，在进入该用例之前，我们需要对 CI/CD 管道的目的、其组成活动以及实现完全集成和自动化工具链的复杂性有一个基本的理解。这些就是我们将在本小节中讨论的话题。

CI/CD 工具链使得软件开发生命周期中的工作项和信息流能够在管道中流动。另一种有用的方式来看待 CI/CD 管道是，它们使得在 IT 价值流中实施精益生产理念成为可能。在我们讨论 CI/CD 管道的组成部分之前，先来回顾一下其两个组成元素的目的：

• CI：这提供了基础设施，允许多个软件开发者甚至不同的开发团队在开发中的软件产品上实现并测试代码更改。

• CD：这使得开发、测试和生产环境的自动化配置成为可能，作为可配置项。

支持 CI/CD 管道实施的三个关键能力和相关工具如下：

• 配置管理（CM）

• 任务管理/自动化

• 容器化

让我们更详细地看看这三种支持技术和工具。

建立 CI/CD 管道的工具

CM 帮助我们跟踪和管理构成每个软件发布的 CI 的正确版本。可配置项是一个系统组件或关联信息文档，已被唯一标识用于版本和变更控制以及标识目的。源代码管理（SCM）工具帮助开发人员维持源代码和其他 CI 的版本控制。

Git 和 GitHub 是两种比较知名的源代码管理（SCM）工具。但还有其他工具，如Apache Subversion（SVN）、Azure DevOps Server（前身为 Team Foundation Server）、Bazaar、Bitbucket Server、CVS、GitLab、Gerrit、Kallithea、Mercurial、Monotone、Perforce Helix Core、Rational ClearCase，以及版本控制系统（RCS）。

任务管理工具促进了 CI/CD 和 DevOps 工作流的自动化。在 CI/CD 和 DevOps 平台中，软件行业将自动化的工作流称为管道（pipelines）。通常，CI/CD 工作流自动化了规划、设计、开发、测试、供应和交付软件发布的管道活动。此外，任务管理还支持跟踪工作项的进度，监控和分析管道中的关键指标，并报告结果。

一款广为人知的任务管理工具是 Jenkins，它以其社区被誉为提供行业领先的开源自动化服务器。Jenkins 用于自动化软件的构建、测试和部署过程，在 CI/CD 环境中运行。尽管 Jenkins 是免费的，但一些人认为它已经过时且使用繁琐。Jenkins 有一些替代品，包括 AutoRABIT、Bamboo、Bitrise、Buddy、Buildkite、CircleCI、CruiseControl、FinalBuilder、GitLab CI、GoCD、Integrity、Strider、TeamCity、UrbanCode 和 Werker。

容器化是一种机制，用于将应用程序的代码及其相关的配置文件、库和其他依赖项打包，以便在目标硬件环境中运行应用程序。从概念上讲，容器实现了一种虚拟化策略，以最大化计算资源的利用率。

在虚拟化技术出现之前，组织必须为运行特定应用程序（如电子邮件、基于 Web 的应用程序和后台业务应用程序）专门配置服务器。拥有专用应用服务器极其低效且不灵活。

两种广为人知的容器技术是Docker和Kubernetes，它们共同协作。Docker 是开发人员用来构建和部署容器的软件工具，而Kubernetes（即k8s或Kube）负责协调和管理集群中的多个容器。协调是必要的，用于调度和自动化容器化应用程序的部署、管理和扩展。

与 SCM 和任务管理一样，行业中也有许多 Docker 和 Kubernetes 的替代工具。Docker 的替代品包括 Canonical（Ubuntu）、Linux Containers（LXD）、CoreOS rkt、Open Container Initiative（OCI）、LXC Linux Containers、Mesos Containerizer 和 OpenVZ。Kubernetes 的替代品包括Amazon ECS（Elastic Container Service）、AWS Fargate、AZK、Azure Kubernetes Service（AKS）、Cloudify、Containership、Google Kubernetes Engine（GKE）、OpenShift、Marathon、Minikube、Nomad 和 Rancher。

如果你认为支持这三种技术的工具数量让人不知所措，那就等着看看我们将在稍后探讨的支持整个 DevOps 工具链的更多工具选择吧。这些工具只是 DevOps 管道工具的一个小子集，既有商业化工具，也有开源工具。稍后在 第十一章中，识别 VSM 工具类型与功能，你将了解到支持 DevOps 价值流交付平台（VSDP）的工具有 17 个类别，且超过 400 种工具可以供选择。

我们将在本章稍后重新审视这三种技术。然而，在深入探讨容器化之前，你需要理解虚拟化背后的基本概念。

理解虚拟化

IT 组织，尤其是大型 IT 组织，需要最大化其计算资源的灵活性、利用率和可扩展性。没有虚拟化，这些目标很难（甚至不可能）实现。虚拟化是 IT 组织用来简化操作并更快响应不断变化的业务需求的方法。

虚拟化提供了一种实际的方法，将应用程序分布在任意数量的计算设备上。例如，在许多情况下，由于负载需求过高，单一计算设备不足以运行业务应用程序。在一个相关的例子中，应用程序的需求负载会随着时间变化而波动，覆盖整个组织的应用程序。虚拟化提供了一种方法，可以在服务器间重新分配负载，随着需求变化，确保关键需求应用的高可用性，同时简化应用程序的部署和迁移过程。

此外，现代数据中心使用部署在机架中的服务器以最大化计算资源的利用率。虚拟化使得协调使用机架式服务器成为可能，从而最大化资源的利用。这些基于机架的服务器策略减少了计算设备的功耗和空调需求；此外，还减少了数据中心对土地和设施空间的需求。

虚拟化数据中心资源

虚拟化创建了一个逻辑（虚拟）计算环境，它位于物理计算环境之上。每个虚拟化环境模拟了硬件、操作系统（OSes）、存储设备以及运行特定软件应用所需的其他系统和安全组件。

虚拟化使得 IT 组织能够将单个物理计算机或机架服务器划分为虚拟机（VMs）。每个虚拟机独立运行，并且可以在共享单一主机资源的同时运行不同的操作系统或应用程序。

虚拟化的主要好处是，每个物理计算系统可以管理多个虚拟环境，从而最大化其利用率。此外，IT 部门可以自动化构建和拆除虚拟环境，以匹配需求负载和业务应用的需求，从而最大化 IT 组织的响应能力和灵活性。

虚拟化概念使用特定的语义描述来区分物理环境与虚拟化环境，以及主机与客户机。主机是用于虚拟化的物理机器，而客户机是虚拟机。主机与客户机的术语使得区分运行在物理机器上的操作系统与运行在虚拟机上的操作系统变得更为简单。

使用虚拟机监控程序软件进行虚拟化

图 5.1展示了传统应用服务器架构（左侧）和虚拟化服务器架构（右侧）。该图清楚地表明，传统模型需要为每个应用程序需求配备独立的计算机作为服务器。相比之下，虚拟化的主机通过共享其资源为所有虚拟化的客户机及其应用程序提供支持：

图 5.1 – 传统（左）与虚拟化（右）服务器

在原始虚拟化模型中，虚拟机监控程序（即虚拟机监控器，VMM，或虚拟化程序）安装在主机上，以便多个虚拟机作为客户机在一台物理服务器上运行。虚拟机监控程序是一种轻量级操作系统，作为抽象层将应用程序及其所需的操作系统与服务器的操作系统隔离开来。

虚拟机监控程序有两种工作模式：

• 裸金属虚拟机监控程序在单一硬件服务器上运行多个操作系统。

• 托管虚拟机监控程序安装在硬件标准操作系统之上，但将虚拟化应用程序的操作系统隔离开来。

图 5.2展示了两种标准虚拟机监控程序软件实现模型，即裸金属和托管模型：

图 5.2 – 虚拟机监控程序软件实现模型

使用虚拟机监控程序软件进行虚拟化的好处包括：

• 它在配置虚拟机时提供更高的速度、效率和灵活性，而不需要为每个软件应用程序安装一台或多台物理服务器。

• 它允许多个操作系统驻留在同一台主机上。因此，软件应用程序无需重新编写即可在主机的操作系统上运行。

• 所有虚拟化的应用程序共享相同的虚拟计算、存储和内存资源，从而减少了计算设备的需求、机房空间、能源成本和设备维护成本。

• 它通过简化和加速创建和恢复快照映像来提高灾难恢复能力。

• 它简化了将测试环境创建为虚拟机（VM）的过程。

为了更好地理解虚拟化的强大功能，在大型企业中，通常会有成千上万的服务器专门用于支持一个关键的业务应用程序。事实上，最大的商业数据中心可能会在成千上万的机架上部署超过一百万台服务器，运行着为无数客户提供服务的各种应用程序。

这些数据中心提供基于云的服务，网络上托管了远程服务器。随着时间的推移，数据中心可能会采用不同的技术。服务器虚拟化对于外部客户的数据存储、管理和处理至关重要，无论其底层物理环境如何。

然而，事实证明，基于虚拟机监控程序的虚拟化并不是一个完美的解决方案。由于虚拟机监控程序软件模拟虚拟硬件，它必须包含所有客户端机器的应用程序操作系统和系统功能，使得它们相对低效。

在接下来的子节中，你将学习容器如何通过共享轻量级操作系统来解决这些问题。

使用容器进行虚拟化

容器和虚拟机监控程序都能使应用程序更快、更具可移植性，并且更高效地部署。然而，它们实现这些目标的方式不同。你已经学过，虚拟机监控程序软件通过在宿主机的环境上实现一个轻量级操作系统。而与此不同，容器的操作系统比虚拟机监控程序软件更小、更高效。容器将应用程序及其依赖项打包，并将它们作为宿主机上的操作系统进程运行。

容器包可以在安装了容器引擎的任何地方运行。例如，请参考图 5.2，了解基于容器的架构的图示，然后将其与下图所示的虚拟机监控程序虚拟化架构进行比较：

图 5.3 – 基于容器的虚拟化

乍一看，基于容器的虚拟化模型看起来与托管虚拟机监控程序模型相似。它们都在宿主操作系统和应用程序之间提供一个抽象层。然而，虚拟机与虚拟机监控程序通过隔离硬件及其操作系统来运行虚拟化应用程序的完整操作系统。相比之下，容器引擎在硬件操作系统之上提供一个抽象层，使得应用程序能够直接运行其首选的操作系统，而无需使用安装在虚拟机上的操作系统。

商业操作系统，如 Linux、Windows 或 macOS，需要提供许多常见服务，以支持在其安装的硬件上运行的计算机应用程序。然而，大多数服务并不是单个应用程序所需要的。因此，容器不包含完整的操作系统——只有运行其支持的应用程序所必需的最基本元素。

基于容器的虚拟化方法比基于虚拟机监视器的虚拟机更加轻量级和灵活。例如，虚拟机可能需要几十 GB 的空间，而容器可能仅需几十 MB。此外，由于每个容器的操作系统是自包含的，因此容器通常更安全，因为对恶意行为（例如通过恶意软件或入侵攻击）的入口点较少。

隐喻上，容器扮演着一种运输功能，模拟了用于通过船舶、火车和卡车移动物理产品的集装箱（例如，一种容器类型从起点到最终目的地）。在软件类比中，开发人员通过容器构建产品，并将其部署到目标主机环境。但在我们的软件类比中，容器将应用程序及其在目标主机物理环境中运行时所需的资源一起作为虚拟化客户端。

这些资源包括代码、运行时、系统库、系统工具和配置设置。容器被构建为镜像，与其运行时环境分开。因此，它们可以在任何地方部署 - 只要目标环境安装有容器引擎，比如 Docker Engine。

在软件开发的现代方法中，特别是在面向 DevOps 的流水线中，将定义和创建非常小的代码片段作为独立服务，称为微服务。基于微服务的开发策略允许将新功能快速编码、测试和部署到生产环境中 - 这通常可以是每天多次。在概念上，微服务方法模仿了精益生产实践中单件流概念的概念。

您将了解在第七章中实施单件流的价值，映射当前状态（VSM 第 4 步），以及第八章，识别精益指标（VSM 第 5 步）。目前，重要的是理解单件流代表最高效的精益开发流程。

容器引擎提供两项关键服务：集群和编排。集群将两个或多个服务器连接为一个虚拟化的计算机。服务器的集群允许它们并行操作，容器引擎管理跨服务器集群的负载均衡和容错活动。

容器编排自动化容器的部署、管理、扩展和网络配置。在调度数百或数千个由微服务组成的单个容器时，编排至关重要，这些微服务跨多个集群运行。

当使用软件容器时，软件开发人员无需担心在多种生产环境中部署，也不用担心硬件资源的虚拟化；容器具有在桌面、组织后端服务器或云中提供应用程序运行所需的一切。

兼得其利

IT 组织可以在部署和管理应用程序时，通过部署虚拟化策略，例如半导体和基于容器的虚拟化策略，来最大化其灵活性。两种虚拟化技术，即半导体和容器引擎可以在同一台物理服务器上共存。

在基于云的环境中，容器表现良好，并且当开发人员希望构建称为微服务的细粒度服务时，容器表现良好。没有太多传统应用程序的 IT 店可能更倾向于从一开始采用这种方法，因为微服务提供了构建、测试和部署新 IT 服务的最大速度和灵活性。

另一方面，虚拟机提供了所有成熟操作系统中可用的管理功能和安全工具。虚拟机提供了消除与底层硬件兼容性问题的硬件抽象层（HAL）。虚拟机有效地利用了内存容量和多核 CPU 中的多个核心，允许在每个物理系统上合并大量应用程序和任务。实际上，虚拟机非常适合运行需要持久性和高事务量工作负载的应用程序。例如，具有大型事务数据库的应用程序——考虑需要具有弹性和持久性后端的银行 ATM，不得丢失数据，并且具有高输入/输出（I/O）事务需求。最后，一些第三方应用程序尚未采用容器模型，可能也不会采用。

现在您了解了支持 CI/CD 所需的必要工具，我们可以介绍包括在 CI 和 CD 进程中的活动类型。我们将从定义 CI 的活动开始。

定义 CI

从根本上说，CI 是一种加快软件开发速度的开发方法。CI 在技术层面上强制执行一种纪律，即将所有开发者的代码工作副本几次每天合并到共享存储库中。其目的是通过软件构建和测试过程验证每个增量代码集成的功能。其目标是确保主要软件代码始终处于工作且可能部署的状态。

成熟的 CI 流水线包括自动化构建和自动化测试功能；尽管这两种功能不是原始定义的一部分。今天，CI 工作流程涵盖了从主分支（即主线代码、主干或主）获取每个新代码提交，并运行适当步骤以验证该提交的过程。

基本的 CI 流水线涵盖以下软件开发活动，如图 5.4所示：

图 5.4 – CI 管道流程

上面的图示是一个更复杂过程的高层次视图。作为复杂性的一个例子，以下任务通常通过 CI 自动化服务器（如 Jenkins）来管理：

• 将源代码移至版本控制系统。

• 管理版本控制系统的推送、拉取和合并功能。

• 执行软件构建过程（例如，编译源代码，链接目标文件和库，以及打包库和工具）。

• 执行静态代码分析。

• 运行自动化单元测试。

• 执行代码覆盖率分析。

• 提供测试服务器。

• 设置测试环境（例如，设置测试环境的代码，并在测试完成后将其恢复到原始状态）。

• 运行自动化测试。

• 发布日志和报告。

• 将信息发送给开发者。

CI 过程看起来是一项繁重且高度复杂的工作——确实如此，特别是在作为手动过程实施时。然而，作为自动化的 CI 过程，完整的反馈循环应该在 10 到 20 分钟内完成。目标是使这个过程快速且简单到，开发者每天都能毫不犹豫地多次启动它。

CI 策略解决了两个根本性问题。第一个问题是确保每一块新代码在变更成为主代码的一部分之前，能够根据需求和验收标准正确实现其功能。第二个问题是确保新集成的代码不会在应用程序的主干代码中引起问题或错误。

鼓励频繁测试

从根本上来说，CI 是一个用于快速且频繁地开发和测试小增量新功能的软件开发过程。这个策略支持《敏捷软件开发宣言》中的第一条和第七条原则（Beck 等人，2001 年）。

《敏捷宣言》原则 1 和 2

1. 我们的首要任务是通过早期和持续交付有价值的软件来满足客户需求。

2. 可工作的软件是进展的主要衡量标准。

请参阅 agilemanifesto.org/principles.html 获取更多详情。

虽然第一条原则很有价值，但事实证明，第七条原则通常更为重要，至少在持续集成（CI）的好处方面是如此。让我们花点时间来理解为什么。

在传统的瀑布模型中，软件开发者在启动任何测试之前，首先创建实现所有已识别需求的所有代码。这个开发策略的一个重大问题是，当代码集越来越大时，软件漏洞的源头变得越来越难以定位和解决。一个更好的策略是，每一步都对新代码的小增量或单元进行测试。这样做的好处是，当测试中出现错误或漏洞时，开发者可以更准确地知道他们在代码中做了什么修改。

此外，频繁的代码更新有助于识别代码合并冲突、代码策略的分歧以及重复尝试。换句话说，借助 CI 和自动化测试，开发人员必须在问题出现时立即处理这些问题，而不是等到它们变得极其复杂、耗时且昂贵时才解决。

本节结束了我们对 CI 的讨论。接下来，我们将学习 CD 功能如何增强和改善软件交付中 CI 阶段的速度。

定义 CD

CD 功能使产品团队能够快速搭建新的环境，以最小的人工干预测试新的代码更新。CD 的主要目标是将新更新转变为常规的、高速的任务，开发团队可以按需执行。

正如 CI 具有一系列连续的步骤，CD 过程也如此，如图 5.5所示：

图 5.5 – CD 管道流程

上述图表中展示的 CD 管道视图提供了一个高层次的视图，类似于 CI 管道，它也可以被分解为一系列相关活动的更长列表。这些活动可能包括以下内容：

• 进行静态代码分析

• 进行单元测试

• 进行 API 测试

• 部署到测试环境

• 并行测试（例如，可用性/可访问性测试、探索性测试、UI 测试和性能测试）

• 部署到预生产环境

• 执行应用程序测试（例如，验收测试、探索性测试、容量测试、负载测试和压力测试）

• 执行软件和网络安全测试

• 进行用户验收测试（UAT）

• 将应用程序部署到生产环境

再次强调，这个列表并不打算全面总结团队可能需要执行的所有测试。

一个最终的评论是，CI 作为一个过程的结束与 CD 开始之间并没有明确的界限。例如，一些分析师将合并代码过程——一个源代码集成活动——放在 CI 管道中，而其他人则视其为 CD 管道活动。实际上，CI/CD 管道代表了整个系统开发生命周期（SDLC）中的连续流程。除了为了传达每个管道部分的工作类型外，没有理由去做这种区分。

一旦开发团队确定了要运行的测试和所需的工具，他们可以通过编写机器可读代码中的配置指令来自动化测试的执行。

通过代码自动化配置任务

在 CD 方法和工具出现之前，开发团队必须要求运维人员设置测试和预生产环境。然后，运维人员手动按照配置文档中的指示设置网络、计算设备和软件。这样的手动过程既昂贵又耗时。

在现代的持续交付（CD）环境中，开发人员可以将软件和系统配置指令作为机器可读的代码进行部署。此外，这些配置可以在源代码控制库中进行管理，并作为自助服务提供，供快速部署使用。基础设施和软件资源在云环境中按需提供，并在执行机器可读代码后几分钟内即可使用。

软件行业中用来描述自动化部署配置的术语是基础设施即代码（IaC）。然而，您可能也遇到过“配置即代码”（CaC）这一术语，它是单个 IT 从业者和供应商用来表示将配置作为源代码进行实现的通用说法。我们将在本章后面讨论 IaC 和 CaC 之间的语义差异。

目前，理解基础设施即代码（IaC）和配置即代码（CaC）如何通过机器可读的代码实现配置指令，用于按需搭建和配置环境以及软件至关重要。在详细讨论 IaC 和 CaC 之前，让我们首先理解为什么配置管理（CM）如此重要，以及为什么某些配置项不能以代码形式进行部署。

基础设施和软件配置广泛地属于软件配置管理这一学科，具体内容请参见以下小节。

保护我们的软件资产

复杂的软件发布涉及部署和配置大量硬件、网络和应用安全、软件组件及其他相关信息工件。配置管理确保我们对构成每个独特软件发布的状态和工件有一个完整的理解。没有这些信息，我们很难，甚至不可能，回溯修复 bug 和缺陷、维持产品或增强以前的软件版本。

随着软件的演进，每个新版本都有其独特的配置。每次发布时，某些组件会发生变化，而其他组件则不会。尽管所有组件可能从相同的版本控制编号开始，但随着时间推移，这些版本控制 ID 会在软件组件和其他信息导向的工件之间有所不同。因此，单单给发布版本分配一个版本控制 ID 是不够的。我们需要了解构成该发布的每个信息工件和软件组件的具体版本。

现代版本控制库，如 Git（本地仓库）和 GitHub（基于 Web 的协作源代码管理平台和仓库），使用树状结构作为隐喻来管理与每个软件发布相关的配置项。

回到应用于软件配置管理（SCM）仓库的树形隐喻，开发人员会创建（并演化）、集成和测试作为应用程序独立分支的组件，然后再将它们与主干代码合并。主代码是任何给定时间点上最接近发布的代码集。并不是说主代码一定能发布，但它在集成功能和测试方面是最为成熟的。

然而，除了追踪源代码外，我们还需要追踪与每次发布相关的所有其他信息工件，这就是软件配置管理（SCM）的目的。

在软件配置管理（SCM）下的信息和软件工件涵盖了整个软件开发生命周期（SDLC）过程，包括以下内容：

• 软件需求：这包括在规范、用例、史诗和用户故事中指定的功能性和非功能性需求。

• 环境：这包括网络交换机、防火墙、路由器、服务器、操作系统、安全网络系统、数据库和其他关键基础设施元素。

• 软件构建：这包括编译、链接和将源代码文件转换为独立软件工件的指令，以便它们可以在计算机上运行。

• 软件发布计划：这提供了如何将产品发布到生产环境中的指示，包括其时间表、交付日期以及面向生产的测试要求，如用户验收测试（UAT）、质量保证（QA）测试、预生产测试（例如压力测试、负载测试和性能测试）以及现场测试等。

• 软件评审：这可能包括同行评审、软件质量保证（SQA）评审或由第三方进行的独立验证与验证（IV&V）测试。

• 版本控制：这包括当前和过去所有软件系统组件及相关工件的版本信息，通常在源代码控制仓库中进行管理。

• 配置项：这包括所有软件组件和工件，它们由独立的名称和版本控制 ID 标识，并属于特定的发布版本。

• 测试信息：这包括与每次软件发布相关的测试用例、测试脚本、测试场景和测试结果。

• 用户支持：支持团队的信息提供用户帮助指南，并在产品实施和使用过程中协助解决用户问题。

• 文档：这可以包括培训工具、系统管理文档、架构和设计文档。

• 问题跟踪：这用于记录与缺陷和漏洞相关的信息。漏洞是由编码错误引起的，而缺陷则是已识别的与需求偏离的地方。

• 任务管理：这用于维护开发和交付生命周期中活动的信息。

大多数与版本发布相关的信息组件并不属于应用程序的源代码。因此，产品团队必须实施流程和系统，记录并维护每个产品版本的这些信息。我们需要按版本管理所有这些信息，以确保在生产环境中的可操作性和可持续性，发现后修复错误或缺陷，并在产品生命周期内进行改进。

现在我们了解了更重要的软件配置问题，让我们来看一下管理和执行 CaC 与 IaC 之间的区别。我们将从描述 CaC 开始。

CaC

CaC 是一个广泛的术语，意味着在源代码库中实现配置文件，但该术语通常更广泛地应用于应用程序的配置信息。CaC 的目的是促进在不同环境之间迁移应用程序配置的版本化。

CaC 配置通过配置文件以机器可读的代码形式实现，重点关注安装软件应用程序、服务器和操作系统所需的设置和参数。开发人员通过 CaC 指定配置设置，参数可以更改以影响目标信息系统的远程硬件、软件或固件组件。这些配置设置和参数会影响系统的安全级别和功能。

必须在 IT 产品中实现和维护几乎无尽的潜在配置，特别是在可以定义与安全相关的配置设置的产品中。美国国家标准与技术研究院（NIST）特别出版物 800-53（第 4 版）列出了以下可配置项目的示例：

大型主机、服务器（例如，数据库、电子邮件、身份验证、Web、代理、文件、域名）、工作站、I/O 设备（例如，扫描仪、复印机和打印机）、网络组件（例如，防火墙、路由器、网关、语音和数据交换机、无线接入点、网络设备、传感器）、操作系统、中间件和应用程序（nvd.nist.gov/800-53/Rev4/control/CM-6）。

NIST 出版物还列出了标准的安全相关参数，如下文所示：

与安全相关的参数会影响信息系统的安全状态，包括满足其他安全控制要求所需的参数。

(i) 注册表设置，

(ii) 账户、文件、目录权限设置，

(iii) 功能、端口、协议、服务和远程连接的设置。

已建立的设置成为系统配置基准参数的一部分。在手动过程中的软件开发人员会创建安全配置检查清单、锁定和加固指南、安全参考指南和安全技术实施指南。操作人员根据这些指南正确配置系统和应用程序。CaC 的价值在于它自动化并简化了配置设置和参数的建立过程。

与 CaC 相对，IaC 是关于配置 IT 基础设施，包括服务器、网络、负载均衡和安全性，如以下小节所述。

IaC

正如其名称所示，IaC 允许开发人员使用编程或脚本语言生成一组可重复的代码或脚本指令来配置 IT 基础设施。通过 IaC 功能，开发人员不需要手动配置或更改基础设施组件的配置，例如服务器、操作系统、数据库连接、存储、网络、虚拟机、负载均衡器和网络拓扑。

如果没有 IaC 功能，开发人员必须每次都手动设置和配置新的系统环境，当他们想要开发、测试或部署软件应用程序时。从精益的角度来看，因此从客户的角度看，这些活动是不必要的重复且没有增值的。这并不是说这些活动不必要。然而，自动化这些过程能提高周期时间，并消除以人为或其他错误形式的浪费。

人为错误的问题尤其令人担忧，因为配置错误的积累会导致环境漂移，其中每个新的环境配置都与以前的配置截然不同。开发人员称这些新配置为雪花，因为它们有一个相似的特征——每个配置都是独一无二的。

管理环境漂移

环境漂移的问题在于，每次系统配置的更改都可能影响之前部署的资产。回想一下，操作的功能是保持环境和应用程序的稳定、安全和可用。然而，假设某个开发人员未能将新的配置更改通知基础设施或应用程序，那么这些修改可能导致生产环境失败或暴露于与安全相关的风险。

对于工程和测试环境，情况也是如此。配置更改使得从配置变化而不是代码中的 bug 或缺陷中隔离和修复错误变得越来越困难。同样，每个新的配置更改都可能引入以缺陷形式的浪费，这些缺陷需要花费大量时间和成本来解决。

有无数的问题会导致环境漂移。然而，这些配置变更大多数来源于文档不当、沟通不畅或在搭建服务器、配置网络或其他计算资源时引入了新的或修改过的参数。

上述示例显示人类错误是根本原因。计算机在执行通过代码精确描述的配置时更擅长执行重复指令。然而，这些类型的错误可以在测试过程中被发现，从而避免负面后果，并限制新发布版本进入生产时的风险。

避免配置错误

与 CaC 概念类似，开发团队使用 IaC 编写脚本或代码来描述配置设置和参数。每个配置文件代表一个单一的、权威的环境定义来源，并随时间推移更新环境设置。

代码或脚本被保存为独立的配置文件，并检查到开发团队的版本控制和 SCM 系统中。将 IaC 文件管理在 SCM 系统中的好处是，可执行的例程通过自服务模型自由地提供给所有开发人员和运维人员。

换句话说，CaC 和 IaC 有助于提升软件交付速度，同时减少错误。

提高交付速度的同时减少错误

通过 CaC 和 IaC，IT 人员可以按需下载并执行配置文件，在几分钟内搭建新的环境而不引入人工错误。自服务模型意味着开发人员无需涉及运维团队即可搭建和配置新的测试环境。此外，运维团队可以确保在发布新版本到生产环境之前，代码和配置已经过充分的测试。

IaC（基础设施即代码）使得持续交付（CD）能够达到与开发人员通过其持续集成（CI）工具所能获得的相同速度。通过 CI/CD 流水线，开发人员可以实时更改代码和配置，并快速搭建测试环境，以确保一切正常运行。此外，高效的团队每天可以部署多次新功能，且交付时间不超过 1 小时（Forsgren 等，Accelerate，2018）。

IaC 是指定 CI/CD 和 DevOps 流水线配置及流程的关键工具。手动配置过程过于缓慢且效率低下。如你将在《VSM、CI/CD 和 DevOps 流水线》章节中发现的，当这些流程得到充分实施时，CI/CD 和 DevOps 流水线能够在所有 IT 价值流中实现精益生产概念。

然而，在我们深入这些章节之前，我们需要理解 CI/CD 和 DevOps 流水线如何支持整个 IT 价值流中的工作和信息流。

启用 CI/CD 和 DevOps 流水线流程

本书清楚地区分了 CI/CD 和 DevOps 工具链及流水线：

• 工具链是多个工具的组合，这些工具共同执行一组特定的 IT 任务或功能。这个术语可能包含集成或自动化策略，也可能不包含，因此有些模糊。

• DevOps 流水线和 CI/CD 流水线包括一系列集成工具，用于简化和自动化 IT 任务或功能，贯穿整个 IT 价值流。流水线更类似于本书后续介绍的精益和 VSM 概念。现在，让我们将 CI/CD 和 DevOps 流水线理解为提高软件价值交付的速度和可靠性。

工具链（toolchain）一词指定了支持 IT 价值流活动的一系列工具。仅仅这个术语本身并不一定暗示集成或自动化策略。虽然不是最理想的情况，开发人员仍然可以手动设置以下工具，以便与之前工具的输出相对应。

更好的策略是通过集成和自动化工具链来提高效率，从而协调和简化工作和信息流。在此背景下，流水线（pipeline）一词表示流动。对于精益生产理念，我们希望工作和信息能够在 IT 价值流中实现简化和高效流动。

CI/CD 和 DevOps 工具链已经集成并自动化，以支持在所有 IT 价值流中高效、简化的工作和信息流。当工具被集成并自动化，以支持简化和高效的工作和信息流时，CI/CD 和 DevOps 工具链被称为流水线（pipelines）。

改善流水线流

工具链与流水线之间的区别非常重要。例如，一个基于敏捷的软件开发团队可以采购一组工具，这些工具共同构成一个工具链。然而，在项目驱动的运营模式下，团队不太可能有足够的时间或预算来实施集成或自动化的工具链。

在这种情况下，敏捷团队无法像实施完整流水线的产品导向团队那样实现相同的生产效率。由于产品团队贯穿其产品生命周期，因此他们能够证明并摊销 CI/CD 和 DevOps 流水线工具链的投资。

然而，敏捷团队有一种解决办法。例如，敏捷团队可以通过商业或内部 DevOps 平台提供商，作为基于云的服务访问集成和自动化的工具链。你将在本书的第三章了解更多这些选项。在本章的其余部分，我们将超越 CI/CD 活动，探讨与 DevOps 相关的全面活动。

理解 DevOps 的完整范围

CI/CD 活动只能将我们带到传统的 SDLC 过程，即从概念到部署。但是 IT 组织还必须维护和支持其软件应用程序。在本章的剩余部分，你将学习到 DevOps 超越了软件开发和交付，确保已部署软件产品的适当生命周期支持。

虽然 DevOps 仍然包括你在本章中学习的基本 CI/CD 活动，但 DevOps 的总体工作范围扩展到了涵盖软件生命周期的所有阶段。这些阶段包括以下内容：

• 构建自动化和 CI

• 测试自动化

• CD 和供应

• 部署自动化

• 操作、监控、支持和提供反馈

• 发布协调和自动化

让我们讨论一下这些活动在软件开发和交付的 CI/CD 阶段之外的内容。在以下小节中，我们将开始定义 CI/CD 流水线和 DevOps 流水线之间的边界。

定义 CI/CD 和 DevOps 流水线的边界

正如你在本章开始时所学，DevOps 最初作为一种协作策略，旨在实现敏捷系统管理。其主要目标是作为一种风险管理策略，改善 IT 开发和运维团队之间的信息流。然而，DevOps 必然会发展以解决速度不匹配的问题。换句话说，运维服务的速度需要与基于敏捷的开发团队的速度相匹配。

在传统的 IT 行话中，我们使用术语 SDLC 来指代由开发团队实施的 IT 价值流活动和工具。相比之下，运维团队使用术语 ITSM 来描述与设计、创建、交付、支持和管理与 IT 服务相关的活动及其支持工具。

毫不奇怪，术语 DevOps 流水线 包含了 SDLC 和 ITSM 的活动与工具，最终形成了一个集成的 DevOps 流水线。在接下来的小节中，我们将探讨 CI/CD 模型如何扩展成为 DevOps 流水线。

扩展 CI/CD 模型

CI/CD 模型涵盖了通常由软件开发团队执行的活动，跨越一个迭代的 SDLC。DevOps 将 CI/CD 流水线的概念扩展到包括 IT 运维团队的活动。换句话说，DevOps 旨在将开发和运维的活动合并，理想情况下是在产品团队层面。

在一篇名为 8 个 CI/CD 最佳实践助你成功 的文章中，Taz Brown 创建了以下图表，展示了在 IT 功能中实施和支持精益价值流的更大复杂性。这个图表将价值流分为三个不同的流，即 软件开发、用户支持 和 事件管理：

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/drv-dop-val-st-mgt/img/B17087_Figure_5.6.jpg)

图 5.6 – IT 价值流

opensource.com/article/20/5/cicd-best-practices (Taz Brown, CC BY-SA 4.0)

此图简化了构建、部署和支持产品所需活动的视图。虽然从 DevOps 的角度来看，这个模型是不完整的，但它确实突出了开发与支持相关活动之间的分离。

图表的第一行位于边界线内，描述了一组标准的 CI/CD 流水线活动。请注意，在边界内有一个决策点，用来决定开发和运维团队是否准备好将软件部署到组织的生产环境中。

由于它位于边界线外，部署产品节点暗示了一个手动决策和流程。然而，情况并非一定如此。通过成熟的 CI/CD 流水线能力，软件发布可以实现自动化。

开发和运维团队可能仍然倾向于在发布前进行一些手动审查流程。然而，当通过自动化测试功能和在向更大用户群体部署版本前，自动化用户验收测试（UAT）对小部分用户进行测试，并且以更高的速度发布微小增量的新功能时，即使是这种需求也变得不再必要。

从图 5.6的第二行和第三行来看，我们进入了运维团队的传统 IT 支持和事件管理职能。这些活动属于 ITSM 过程。

然而，这个模型仍然缺少面向运营的IT 运维管理（ITOM）流程。ITOM 涵盖了 IT 运维的控制和设施管理，但也与技术管理和应用管理有重叠。一个非常成熟的 DevOps 流水线将在产品团队层级集成并自动化这些活动。

我们将在本章的最后部分深入探讨 ITOM 和 ITSM。但在我们进入这些话题之前，让我们先看看开发和运维之间速度不匹配如何成为推动 DevOps 策略、后来的 DevOps 工具链和流水线发展的动力。这是我们下一小节的主题。

解决速度不匹配问题

正如前一小节所提到的，开发的速度通常超过了运维管理有效地频繁部署新版本所面临的风险管理能力。然而，所有这些问题都可以通过 CD 和持续部署能力来解决。

许多基于敏捷的 IT 开发人员采用创新的实践，使用 CI 方法和工具频繁地部署小增量的新功能。CI 能力通过自动化前端 SDLC 开发流程，在开发人员每次将代码提交到源代码库时，执行自动化的代码集成、构建和集成测试。

持续交付（CD）最初是为了支持自动化测试需求而发展起来的，测试需求位于开发和运营之间的边界。开发团队应在部署前彻底测试所有新的软件发布，包括系统、验收、负载、压力、性能以及其他关键测试。手动设置测试环境以支持这些测试需求需要时间、计算资源和人力。

简而言之，手动测试过程无法与持续集成（CI）的速度相提并论。持续交付（CD）自动化了读取应用程序和基础设施配置代码、配置测试服务器、安装和配置应用程序，然后运行所有必要测试的活动。

持续部署将配置过程进一步推进，自动化了生产环境中的部署过程。此外，持续部署还可以在接近实时的情况下自动化基础设施资源的配置，以满足变化的生产需求。

运营职能可以通过使用 CI 方法和工具以及 CD 和部署能力来匹配基于敏捷的开发团队的速度。精益生产过程强调高质量产品和服务的快速交付，以及准时交付，它为将 IT DevOps 管道活动整合到单一 IT 价值流中提供了一个方法。

当你阅读到本书的第二部分，即实施价值流管理（VSM）时，你将学到如何在 IT 价值流中实施精益生产理念，以创建精益管道流程。但在我们进入书中的这一部分之前，我们需要了解 DevOps 活动的完整范围。

确定 DevOps 管道活动的范围

事实证明，完全发展的 DevOps 管道包含了许多超出 CI/CD 管道流程的集成活动。在本节中，我们将探索这些更高级别的活动，以及它们如何作为一个持续的迭代和增量开发与支持过程运作。

在阅读本节时，请记住你在第一章《交付以客户为中心的价值》中学到的内容，关于组织有两种类型的价值流：开发和运营。提醒一下，面向运营的价值流将产品和服务交付给组织的外部客户，而开发价值流则创造供组织的运营价值流使用的东西。

DevOps 这个缩写令人困惑，因为该术语暗示运营和开发是同一价值流的一部分，实际上它们确实是。但是，DevOps 中“开发”和“运营”这两个词的语义，与精益生产中的语境意义有所不同。DevOps 范式包括与 CI/CD 管道相关的迭代软件开发生命周期（SDLC）活动，而运营活动则包括产品的 IT 服务管理（ITSM）活动。

图 5.7 是 DevOps 流水线的标准展示。虽然 DevOps 流水线可以显示为线性顺序流，但更常见的方法是显示为无限循环。无限循环暗示迭代和增量的 DevOps 交付活动作为连续流动进行：

图 5.7 – 无限的 DevOps 流水线流程

现代敏捷和精益敏捷实践都实施了交替开发周期，以提供客户价值的频繁增量。DevOps 简单地扩展了迭代和增量开发模型，以涵盖 IT 服务管理活动。

此 DevOps 模型过于简单化，因为它的重点仅在于传达高级管道流程。正如我们在 CI/CD 管道活动中发现的那样，DevOps 管道的 ITSM 部分包含的活动比 DevOps 无限循环图表中描绘的要多得多。

您已经知道如何将 CI/CD 活动作为管道集成到 DevOps 管道模型中。在下一节中，我们将看一下与 ITSM 相关的活动及其流程。

整合 ITSM

在 第一章，交付客户中心的价值，您了解到组织价值流支持开发或运营，并经常是相互关联的。您还了解到，以 IT 为基础的开发导向价值流通常创建支持运营导向价值流的软件产品。

例如，保险公司的内部软件开发团队可能会创建支持公司保险产品推广、销售和交付的基于 Web 的服务。同样，医疗软件提供商有多个开发团队支持多个价值流。这些可能包括患者注册、理赔管理、财务管理、会计、诊断和计费代码、患者健康数据、预约安排、合规性和报告。

然而，正如您已经了解的那样，IT 价值流不仅限于实施软件开发和交付活动。除了这些能力之外，IT 组织或软件产品团队还必须安装 ITOM 能力和 ITSM 流程及平台。

ITSM 关注 IT 团队如何交付服务。相比之下，ITOM 关注事件管理、性能监控和 DevOps 流水线中 OPS 部分中所使用的活动和工具。理想情况下，IT 组织在产品团队层面安装 ITOM 和 ITSM 活动作为其 DevOps 流程的一部分。

令人方便的是，ITIL 4 已经从 服务价值系统 (SVS) 的视角解决了 ITOM 和 ITSM。如果组织已经实施了 ITIL 4 的实践或等效实践，VSM 团队需要评估 DevOps 管道中与运营相关的工作。

交付服务价值

在之前展示的 图 5.7 中，DevOps 管道的 OPS 部分包括 发布、部署、操作 和 监控 作为其主要活动。其中两个活动，发布 和 部署，是过渡活动，要求产品团队的开发和运维方面的支持。

然而，在本节中，你将学习到，这些 4 个面向运营的过程被分解为至少 34 个独立的 ITSM 领域，涵盖 3 个管理实践。领域一词意味着指定的活动或知识领域。在 ITSM 的背景下，你可以假设领域一词包括特定的知识领域和相关的一系列活动。

服务管理广义上描述了旨在改善公司客户服务流程的实践和活动。服务管理包括涵盖战略、设计、开发、集成、运营和服务改进的活动。ITSM 然后包括支持客户使用 IT 组织生产或获得的相关基础设施和安全组件的软件的实践和活动。

产品团队可以选择使用多种 ITSM 框架，例如 ISO/IEC 20000-1、ITIL 4®、COBIT 5、FitSM、微软运营框架 (MOF)、The Open Group IT4IT 参考架构、VeriSM™、SIAM® 和 YaSM®。鉴于其领导地位，本章评估了 ITIL 4® 如何将其 服务价值链 定义为其最佳实践的一部分，以在 DevOps、敏捷和精益方法的背景下交付 ITSM。

ITIL 4® 将 服务价值链 定义为一组“在 ITSM 价值流中使用的连接实践、活动和行动。”换句话说，ITIL 4® 的服务价值链代表了一种流程。当然，我们知道 ITSM 价值流仅仅是更大 IT 价值流工作和信息流的一部分，而这些工作和信息流被包含在 DevOps 管道中。

在我们深入探讨服务价值链的活动和流程之前，首先让我们快速看一下帮助交付价值的 ITSM 四个维度。

包括 ITSM 的四个维度

ITIL 4 将服务管理的四个维度描述为 ITSM 提供者能力的基础。从系统思维的角度来看，这四个维度是参与基于价值的 ITSM 交付的要素。它们包括以下内容：

• 组织和人员：这是为了构建正确的组织结构和能力。

• 信息和技术：这是为了构建使用正确技术的 IT 系统和基础设施，以支持服务交付。

• 合作伙伴和供应商：这是为了实施在财务和技术上适当的第三方服务交付合同。

• 价值流和流程：这是为了开发高效且以客户为中心的服务价值交付能力。

服务管理的四个维度有助于产品团队提供服务价值。软件产品团队必须协调其服务价值链响应，涵盖所有四个维度。如果没有，服务交付功能将无法最佳运行，无法为客户和产品用户提供价值。

最后需要注意的是，以下外部因素可能会影响服务交付的四个维度：经济、环境、法律、政治、社会和技术。这些因素在决定如何部署服务管理的四个维度时必须考虑。

现在我们了解了服务管理的基础要素，接下来让我们探讨与 ITSM 相关的活动流程。

定义 ITSM 交付流程

与任何价值流一样，ITIL 4®服务价值链代表了一个活动流程；虽然它在高层次上进行了描述，正如我们将在接下来的小节中看到的那样。服务价值链包括六个主要活动，以从价值交付的角度响应 IT 服务需求：

1. 规划：这是对服务能力、需求和政策进行现状/待办评估，以制定共同愿景，明确所需服务及其交付方式。

   交付的价值：新服务的识别与供应计划。

2. 改进：确保在服务管理的四个维度中持续改进所有产品、服务和实践。

   交付的价值：达成服务级别目标。

3. 互动：确认我们对利益相关者需求的理解，并确保及时的互动和与利益相关者的积极成果。

   交付的价值：管理和解决用户投诉。

4. 设计与过渡：确保产品和相关服务的新版本不断满足利益相关者在质量、成本和市场时间方面的期望。

   交付的价值：启用业务应用程序的下一版本升级。

5. 获取/构建：确保服务组件在需要的时间和地点可用，并且符合约定的规格。

   交付的价值：及时和准确地完成用户请求。

6. 交付与支持：确保按照约定的规格或服务级别协议交付和支持服务，同时满足利益相关者的期望。

   交付的价值：成功解决所有事件报告。

这六个活动展示了定义、创建和交付以客户为中心的服务的工作流程。因此，正如软件开发有一个从构思到交付的流程，ITSM 也提供了一个价值流流程，用于定义和交付 IT 服务。在 DevOps 中，我们需要将这两个流程整合，如图 5.7所示。现在，让我们定义涉及交付基于价值的 ITSM 的全部潜在工作范围。

提供 ITSM 价值

在本节前面，我们提到过，虽然没有明确归因于 ITIL 4®，但服务价值链文档涵盖了 34 个独立的 ITSM 领域，跨越了 3 个管理实践。再次说明，领域一词既指知识领域，也指相关的活动集。本书的范围限制了我们深入描述每个领域的能力。然而，ITIL 4®提供了关于规划、管理和改进这些管理实践及其领域相关活动的详细指南。

三个管理实践组包括以下内容：

• 一般管理实践：这一组涵盖了 14 个服务管理领域，涉及一般业务管理，有助于支持工作或实现特定目标。领域包括以下内容：

• 服务管理实践：这一组涵盖了 17 个领域，确保服务能够提供约定的可用性水平，以满足客户和用户的需求。领域包括以下内容：

• 技术管理实践：这一组涵盖了三个领域，以实施服务管理实践，将焦点从技术解决方案转向 IT 服务。领域包括以下内容：

应该很明显，ITSM 引入了更多广泛的实践和活动，以在面向 DevOps 的价值流中实施、改进和支持。然而，在本书中没有必要深入探讨 ITSM 的细节。本章的主要目标是介绍构建和简化 DevOps 作为编排管道流程所涉及的工作范围。

我们接近本章的结束。到目前为止，你应该已经意识到，在开发简化的 DevOps 生产流程时面临的复杂挑战。需要在工具链上进行投资，并实施、集成、自动化和编排无数活动。

本书并不试图解决你在 CI/CD 和 DevOps 管道流程中遇到的具体问题，而是为你提供解决问题的工具。具体来说，本书的第二部分介绍了一个八步 VSM 方法论、现代 VSM 工具及其功能。在这个背景下，VSM 涵盖了你可以使用的方法和工具，用于改善 CI/CD 和 DevOps 管道中的精益生产流程。

在我们结束本章和本书的这一部分之前，还有一个话题需要讨论，那就是从项目导向的开发模式转向产品导向的开发策略。

从项目到产品的转变

传统的瀑布模型用于软件开发是基于项目的。在行业的早期，由于软件开发中的高成本、复杂性和风险，项目导向的方法似乎是合乎逻辑的。

让我们回顾一下最适合传统项目管理实践的工作类型。例如，基于项目的工作的特点包括以下内容：

• 项目有可定义的交付成果或输出，形式可以是产品、服务或结果。

• 基于项目的交付成果是相对独特的，因此，工作具有显著的风险。

• 项目约束在项目章程中定义，由客户或执行发起人批准，具体限制包括授权的范围、时间表、成本和质量。

• 面向项目的工作高度定制，以支持每个产品的独特需求，因此，从一个项目到另一个项目，工作内容相对不具重复性。

• 鉴于软件产品需求相对独特，工作的完整细节和范围可能只有在项目推进过程中才能显现（这一点对于基于敏捷的方法的工作也同样适用）。

• 项目团队采用正式的变更管理实践，以最小化范围蔓延、预算不足和进度超支。

• 时间表有助于强化项目的临时性，明确项目的开始和交付日期，以及预定义的活动、依赖关系和持续时间。

• 基于项目的工作往往跨越组织边界，因此需要涉及多种技能。

在一组强制性的约束条件下管理高度定制化的工作似乎是一个矛盾——确实如此。尽管如此，我们应该理解客户为什么会对项目相关工作设定约束条件。具体而言，我们的付费客户设定项目约束，是为了确保预计的投资回报率（ROI）能够在时间框架内实现，并且在成本上具有经济意义。

然而，在基于项目的约束下开发软件会产生一系列问题，其中有三个是至关重要的。首先，鉴于每个软件产品的独特性质，开发团队无法预见他们可能遇到的所有问题。其次，客户和用户往往不知道他们需要什么，直到他们手上有了一个可以评估的软件版本。第三，客户需求会不断变化，优先级也随时间而改变。

关键点是，无论项目团队在项目规划上投入多少时间和精力，这些规划在执行前都会变得过时。

现代软件方法和工具已经发展，以支持软件开发的独特需求，例如响应客户需求和优先级变化。这种响应能力在传统的瀑布式项目管理模型下是无法实现的。通过完全发展的 CI/CD 和 DevOps 流水线，最成熟的软件开发团队可以迭代、增量并快速地交付新功能，甚至可能一天多次。因此，CI/CD 和 DevOps 流水线在功能上等同于现代制造设施。

在本书的第二章，我们将探讨如何通过 VSM 帮助改善 DevOps 流水线中的精益生产流。但在此之前，让我们先花一点时间了解为什么基于产品的开发和交付模型优于传统的基于项目的瀑布模型。

产品资金支持

不需要将软件开发活动限制在特定的范围、时间表、成本或质量指标内。相反，正如制造工厂只要有新的客户订单就会继续运营一样，现代软件工厂也会在客户的产品需求不断发展的情况下持续运作。

实体产品往往会磨损，迫使客户进行更换。相比之下，软件产品不会物理磨损。另一方面，驱动最初软件开发目标的需求通常有其生命周期。在这种情况下，客户最终需要更换或更新他们的软件应用程序。

基于这些原因，将项目模型转变为产品导向的开发模型是合理的。在产品导向的开发模型中，产品团队取代了项目团队，团队会一直维持下去，直到客户不再使用该产品。

团队的组成可能会随着时间的推移而变化，以支持不断变化的需求。在产品生命周期的初期，开发在工作量和成本中占据主导地位。到生命周期的后期，开发资源可能会减少，资源重点转向面向运营的支持。

基于产品的资金支持模式不同于基于项目的资金支持模式。基于项目的资金支持依赖于预计未来的投资回报。基于项目的资金支持有两个风险。首先，存在产品能否在授权的限制条件内完成的疑问。其次，存在未来市场是否会存在并支持这项投资的问题。

基于产品的资金支持风险较低，因为它颠覆了基于项目的模型。与其问“产品是否最终能够回报投资”，基于产品的资金支持模型会评估当前的成本和收入，以此来评估投入开发和运营支持的资金数量。

初始开发成本投资依然存在风险。然而，这些风险转移到了投资组合层面，企业高层管理人员决定他们需要做出哪些投资，以便为公司未来的业务定位做好准备。这些投资可以开发新产品，或者作为对现有产品的增强，以吸引新市场细分中的客户。投资组合层面的投资具有战略意义，而对产品团队预算的持续调整则是根据实际成本与实际收入对比所做出的战术决策。

本节完成了本书第一章的最后一部分。我们将以总结部分和一组 10 个问题来结束，这将帮助你分析自己对本章内容的理解。

总结

本章介绍了实施 CI/CD 和 DevOps 流水线流的复杂性。该信息是本书第三章的前置内容，在那里你将学习如何运用 VSM 的方法和工具，在你的 IT 价值流中实施和改进精益生产流。

具体来说，在本章中，你学习了实施成熟 CI/CD 和 DevOps 流水线的复杂性。你了解到虚拟化，主要通过基于容器的技术，是支持高效利用 IT 基础设施资源并实现快速交付小规模的新软件功能的关键。最后，你学习到 CI/CD 流水线集成并自动化了传统的 SDLC 过程，而 DevOps 则将 CI/CD 流水线扩展到包括服务管理功能。

有了这些知识，你现在已经为理解如何使用 VSM 方法和工具实施并改进作为精益生产导向的 DevOps 活动做好了充分准备。VSM 方法和工具构成了本书主题的下一部分——第二章，实施价值流管理（VSM）方法和工具——以改善 IT 价值流。

问题

1. 什么驱动了 DevOps 概念的产生，后来又推动了其方法和工具的发展？

2. 支持 CI/CD 流水线实施的三个关键能力和相关工具是什么？

3. 什么是 CI，它的目的是什么？

4. 软件开发团队和 IT 运维团队之间有哪些显著的文化差异？

5. 什么是 CD，它的目标是什么？

6. IaC 和 CaC 有什么区别？

7. 使用“工具链”和“流水线”这两个术语时，主要区别是什么？

8. 仅用两个术语，如何最好地描述构成 DevOps 流水线的 IT 价值流？

9. 如何区分 ITOM 和 ITSM？

10. 项目导向团队与产品导向团队的资金来源有何不同？

进一步阅读

• Dietrich, E. (2019 年 6 月) DevOps Table Stakes: The Minimum Amount Required to Play the Game. DZone/DevOps Zone。dzone.com/articles/devops-table-stakes-the-minimum-amount-required-to。访问日期：2021 年 2 月 2 日。

• 美国国家标准与技术研究院（NIST）信息技术实验室。国家漏洞数据库 NIST。特别出版物 800-53（修订版 4）。联邦信息系统和组织的安全与隐私控制。nvd.nist.gov/800-53/Rev4/control/CM-6。访问日期：2021 年 2 月 2 日。

• Forsgren, N., Humble, J., Kim, G. (2018) Accelerate. Building and Scaling High-Performance Technology Organizations. IT Revolution. Portland, OR.

第二部分：VSM 方法论

本书的这一部分介绍了价值流管理（VSM），作为一种通用方法论，可应用于帮助识别、优先排序和规划跨企业和任何价值流的改进。考虑到在 IT 和其他组织的价值流中实施和改进精益生产能力所涉及的工作范围，它也是本书最大的一部分。

在现代背景下，VSM 工具支持跨组织 IT 价值流的精益改进，旨在通过基于 DevOps 的管道改善软件交付能力。但工具仅仅是行业 VSM 解决方案需求的一部分。IT 行业还需要采纳一种经过验证的 VSM 方法论，以从其 VSM 工具中获得最大价值。

以此为目标，第 6 到第十章介绍了一种稳健且经过验证的 VSM 方法论，并将其应用于以 IT 为基础的 CI/CD 管道实施策略，作为一个示例案例。

VSM 不是一个新概念，这些技术已经应用于制造业、供应链管理、办公室管理和医疗保健管理中的精益改进。但将 VSM 应用于解决 IT 价值流中的生产力和价值交付问题则是一个相对较新的概念。

尽管 IT 社区才刚刚开始采用 VSM，但 VSM 概念和工具在 IT 社区中正迅速获得关注。例如，Gartner 报告指出，到 2023 年，70% 的组织将使用 VSM 来改善其 DevOps 管道中的流动性，从而加快客户价值的交付。

在我们现代的数字化世界中，IT 触及着几乎每个业务方面。因此，对组织 IT 价值交付能力的改进也有助于改进几乎所有的业务方面。

本节包含以下五章内容：

• 第六章， 启动 VSM 计划（VSM 步骤 1-3）

• 第七章， 映射当前状态（VSM 步骤 4）

• 第八章， 识别精益指标（VSM 步骤 5）

• 第九章， 映射未来状态（VSM 步骤 6）

• 第十章， 改进精益敏捷价值交付周期（VSM 步骤 7 和 8）

第六章：启动 VSM 倡议（VSM 步骤 1-3）

在上一章中，你已经学习到价值流管理（VSM）提供了一种系统性且持续评估所有开发和运营价值流的方法。VSM 倡议的目标是确保组织与企业战略保持一致，同时增加以客户为中心的价值。你还学习了支持 VSM 团队在规划、映射和维持精益改进中的八个关键步骤。

理解 VSM 的基本原则至关重要，因为每个基于信息技术（IT）的 VSM 倡议必须支持组织更广泛的目标，以构建和维持精益企业。本章将指导如何应用前三个 VSM 步骤。你将学习如何在第六章中执行剩余的五个 VSM 步骤，即启动 VSM 倡议（VSM 步骤 1-3），以及在第十章中，改进精益-敏捷价值交付周期（VSM 步骤 7 和 8），你将在这里学习如何映射、分析和改进你的价值流。

本书的这一部分通过第五章，通过 DevOps 流水线推动业务价值，一直到第十章，改进精益-敏捷价值交付周期（VSM 步骤 7 和 8），融入了持续集成/持续交付（CI/CD）流水线的案例。该用例将帮助你在实际的 IT 导向价值流应用中，直观地了解如何使用 VSM 方法论。在这一初始章节中，重点是学习准备启动 VSM 活动的基本要素。

本章将涵盖以下主要内容：

• 承诺于精益—VSM 步骤 1

• 选择价值流—VSM 步骤 2

• 学习精益—VSM 步骤 3

承诺于精益—VSM 步骤 1

VSM 旨在对组织的价值流进行精益改进。大多数 VSM 倡议会影响战略和投资组合层面的规划决策。因此，我们需要高层管理和利益相关者对精益的承诺，才能在 VSM 中取得成功。这是本节的主题。

应该显而易见的是，如果一个组织不认真实施精益生产（开发）和交付（运营）实践，那么它不可能真正认真地采用 VSM。如果你的 VSM 倡议仅仅是关于改进 DevOps 价值流，那么组织就偏离了核心目标。VSM 的目的是在所有价值流中实施和维持精益实践，最终在企业层面推广。

在我们决定承诺于精益之前，我们应该了解它的起源和目的。这是下一个小节的主题。

探讨精益的起源

精益的起源可以追溯到亨利·福特早期的汽车组装线和大规模生产概念。亨利·福特的方法显著提高了生产率和质量，同时降低了成本，但他的流水线方法无法容纳产品线的变种。

例如，他早期的流水线将汽车产品限制为仅有一种颜色（黑色）、一种型号（T 型车）以及每个组装零件的唯一规格。没有任何考虑来组装不同类型、车身风格、颜色、底盘或其他汽车零件。

后来，通过丰田喜一郎、大野耐一、丰田佐吉和慎吾茂的努力，丰田改进了亨利·福特的流水线和大规模生产概念，在支持多个产品线变种的同时，保持了生产流程的连续性。丰田对精益生产概念的贡献是多方面的，经过了几十年的演变，并且持续发展。

这些努力始于 1930 年，当时丰田喜一郎实施了准时生产（JIT）概念，以提高稀缺且昂贵资源的利用率，消除生产过程中不增加价值的浪费。简而言之，JIT 就是按需生产，按时生产。

大野耐一、丰田佐吉和丰田喜一郎改进了 JIT 概念，并实施了基于自主与自动化的自働化（Jidoka）概念。JIT 和 Jidoka 构成了丰田生产方式（TPS）的两大支柱。慎吾茂曾在丰田工作，实施了丰田的单分钟换模（SMED）和** poka-yoke**（防错）概念，并发布了丰田生产流程的首个详细评估。这本书名为丰田生产方式研究（Shingo, Dillon；2005—英文版）。

在现代形式中，丰田生产方式（现在称为丰田方式）包括 JIT 制造、消除浪费和持续改进（Kaizen），但丰田并没有创造精益这个术语。

John Krafcik 因在其论文精益生产方式的胜利中定义了“精益”这一术语而获得了认可，该论文发表于Sloan Management Review（1988）。论文描述了他在麻省理工学院（MIT）斯隆管理学院攻读工商管理硕士（MBA）期间进行的研究，同时他还在 MIT 的国际汽车项目（IMVP）担任精益生产研究员和顾问。

在 James P. Womack、John Krafcik 和 IMVP 团队的指导下，他们对 15 个国家的 90 多家汽车制造公司进行了研究，旨在了解精益生产实践如何帮助西方制造公司与采用丰田 TPC 概念的日本同行竞争。Womack 在他的著作改变世界的机器（Womack, Jones, Roos；1990）中发布了 IMPV 研究的结果。

将精益与价值交付联系起来

精益企业寻求实现世界级的价值交付能力。精益组织在可能的情况下减少成本，生产行业中最高质量的产品，满足交付要求，并消除客户价值流中的所有浪费。

VSM 团队成员明白他们的责任是帮助改善组织的价值流，并同时帮助组织比任何同行更好地满足客户需求。他们通过推动精益导向的改进，在组织价值流中实现这些目标。

精益公司通过持续改进其业务运营，比其他公司更具竞争力。精益企业通过尊重员工的工作并将责任下放到执行工作的人手中，显得更加友好。这些员工友好的策略有助于减少阻碍生产力的官僚主义和等级化的组织结构，进而最终减少员工的压力和疲劳。同样，精益管理还承诺员工培训、认可、沟通以及精益工具的使用。

世界级组织遵循一种成本降低原则，即永不批准将更高的成本转嫁给客户，因为其运营已被精简并提高了效率。目标是让竞争对手无法通过更好的定价占据市场份额。世界级组织努力实现零缺陷，并消除价值流活动中的一切浪费，从而进一步降低成本，同时提升竞争力。

精益组织不会在生产或运营职能中推送工作，直到有足够的产能来完成这些工作。比生产流速更快地将订单和物料推入生产环境，只会导致库存持有成本、等待时间和隐性缺陷等浪费。因此，精益企业的高层知道，员工必须在产能可用时才将工作拉入价值流，并且物料、零件和信息必须在恰当的时刻到达，以支持运营，而不是提前。

在不妥协灵活性的情况下改善生产流程

丰田在改善生产流程的同时保持产品变异灵活性的工作意义不可低估。没错，福特早期的流水线效率高，生产的汽车质量也很高，但由于产品线变异缺乏灵活性，使得公司容易受到竞争对手的挑战，后者找到了在保持灵活性同时仍能实现高效流程的方法。提供以客户为中心的价值意味着我们必须在客户需要时、以竞争力价格提供他们所需的产品特性和功能。

同样的经验教训也适用于我们现代的 IT 开发运维（DevOps）实践。现代的持续集成/持续交付（CI/CD）和 DevOps 流水线使得生产流程更加高效，而不会妥协组织在需要时、按需开发正确产品的能力。完全自动化的 CI/CD 和 DevOps 流水线并不限制软件开发中的创意方面，但它们确实消除了重复性和无价值活动的繁琐操作。

本节的其余子章节强调了持续沟通、管理层参与以及为长期成功设定适当的起始条件的重要性。精益方法强调在生产流程的开发和维持过程中进行持续改进（CI）。VSM 的方法和工具支持精益产品生命周期承诺过程。虽然这个精益承诺步骤只是你 VSM 之旅的开始，但起步时做到位至关重要。

为 VSM 安装合适的操作系统

需要注意的是，丰田从未认为有必要脱离传统的等级化组织结构。相反，随着丰田成长为全球化的大企业，他们在地区和产品线层面建立了更多的决策权，并在各分部层级赋予更多决策权。设立地区分部使得每个地理业务单元可以根据本地市场需求定制产品和服务。相比之下，产品线分部帮助丰田发展和维护其产品品牌。

在业务线（LOB）层级保留高层和职能管理职位并不符合精益哲学，但精益生产实践也将决策权下放到组织中实际可行的最低层级。

例如，本地操作员和主管最了解事物如何运作以及哪些地方可以改进。价值流团队有权在不涉及超出其权责范围的投资或生产延误的情况下，在本地层面进行改进。

这并不意味着管理层和高层领导不参与决策。在第七章，当前状态映射（VSM 步骤 4）中，您会了解到Gemba的实践（这一术语翻译为“实际”或“真实”的地方），这是一种管理者和 VSM 团队走上生产车间，了解实际情况的做法。Gemba 的价值在于，当决策需要上升到更高权限时，管理者和高层领导已经意识到并了解了问题。

精益价值流在等级化组织中的所有业务职能上都得到叠加，产品线作为独立的业务单元运作。精益的理想情况是高层管理人员、经理和操作人员之间有开放的沟通和持续的协作。在精益企业中，沟通既向上流动，也向下流动，穿越等级或部门的业务结构。

看起来保持层级组织结构可能违背了敏捷方法要求的小团队操作或通过团队-团队模型进行规模化的理念，这种模型是完全自给自足且大多自主的生产交付结构。然而，仔细观察后发现，精益价值流具有专门的资源，这些资源在类似的独立性和自主性下运作。

在精益管理中，当功能性管理结构存在时，它们支持所有开发和运营导向的价值流的价值交付。每个价值流可能有较小的独立团队，这些团队作为半自治单元运作。然而，它们必须始终与支持精益导向的工作和信息流对齐，贯穿于其更大价值流和其他互联价值流中。

另一个推动精益改进的关键方面是，高管和经理不能是唯一提出想法或单独做决策的人。执行工作的员工往往拥有如何改进工作的最佳想法。自由流动的沟通和对所有团队成员的尊重使得这些想法能够迅速获得支持并传递给决策者。

在约翰·科特（John Kotter）2014 年出版的《为更快发展的世界构建战略敏捷性》一书中，他提出我们需要两种商业“操作系统”。双操作系统利用大型企业的规模经济，这并不是通过拆除功能性层级结构，而是通过将精益价值流叠加在管理结构上来实现的。

将层级结构与价值流叠加的概念通过沿价值流对资源进行对齐来支持数字化转型。功能性结构有助于发展和维护增长所需的资源。面向开发和运营的价值流有助于提升敏捷性和对客户需求的响应能力，并推动对新兴商业机会的投资。

你现在已经知道 VSM 是一种持续推动精益改进的方法，并且明白了为何精益是从客户角度提供最佳价值的重要战略。接下来，让我们深入了解如何启动和支持 VSM 计划。

管理 VSM（价值流管理）计划

高管和经理在指导精益企业中扮演着至关重要的角色。他们对 VSM 项目的成功负有最终责任，因此需要对结果承担全部责任。他们的角色是确保价值流组织通过比竞争对手更高效、更聪明、更精益的方式创造更多价值。

高管们负责制定和指导战略、治理政策以及投资决策。他们有受托责任和法律责任来监督这些职能。他们还制定企业的使命和愿景，并指导组织的价值观。

相反，经理将战略、使命、愿景、政策、价值观和投资决策转化为可操作的工作。换句话说，经理能够促进并指导具体实施战略计划目标和宗旨的工作。

在战术层面，经理在每月、双月或季度会议中审查客户订单，回顾客户状态和投诉、供应商和定价信息。经理评估并上报关于设施、设备和工具的新投资请求，以满足客户需求。

无论作为产品经理还是产品负责人这一正式角色，经理们是否还会审查竞争对手的产品和定价，并将这些信息分享给所有产品团队成员和其他相关利益相关者。业务线经理会表彰员工的努力，并支持实施价值流流程改进活动。

在协助 VSM 工作时，执行经理确定 VSM 冠军和初始核心团队成员。赞助高管建立 VSM 章程，指导 VSM 倡议，并选择一名 VSM 经理来领导该工作。

如果价值流已经存在，赞助高管、VSM 团队负责人和价值流经理应该已经实践Gemba（即走到实际的地方，在那里发生价值流工作），但在 VSM 倡议启动时，他们必须一定要这样做。他们在 Gemba 的目标是打破任何妨碍跨职能协作的沟通和层级障碍。VSM 负责人还会审查现有的持续改进（Kaizen）计划（如果存在的话）。

在 VSM 倡议开始时，VSM 团队负责人应创建检查清单，以确保团队实现其目标。拥有检查清单是没有问题的，因为它们只是另一种待办事项清单的形式，以便我们不忘记需要做的事情。然而，如果检查清单变成强迫做不必要的工作的指令，因为“就是这么做的”，并且被用作工具来惩罚那些未完成指派工作的人，它们很快就会失去价值。

例如，检查清单可能包括以下活动：

• 确保 VSM 章程已由执行赞助人制定并批准

• 制定初步的 VSM 倡议计划，概述目标、宗旨、指标和资源

• 计划并组织启动会议

• 分配时间和资源用于培训

• 为 VSM 团队成员和支持实现 VSM 目标的员工创造激励措施

• 制定沟通计划，并保持执行和更新计划的谨慎

• 根据一组与预期结果相匹配的指标，监控团队活动

• 与 VSM 团队合作，识别并消除精益倡议的障碍

• 为支持 VSM 倡议分配足够的资金

• 对日期和时间保持灵活，但在推动精益目标上不容妥协

• 保持参与，参加启动和评审会议，并保持信息更新

关于 VSM 负责人角色的最后一点说明是，VSM 团队必须作为一个协作且互相尊重的团队共同工作，不必害怕来自专制或独裁领导的报复。

例如，团队成员必须有权停止工作并请求帮助，以解决任何影响交付质量的问题。这个概念在日语中叫做安灯（Andon）。这个词意味着灯笼，其含义是，当工人发现质量问题时，他们可以打开灯作为信号，停止生产线。任何人，无论其职级或职位如何，都会因采取此行动而受到尊重，且不必担心遭遇报复。

正如敏捷实践中一样，VSM 负责人是一个促进者和服务型领导，帮助清除阻碍团队工作的障碍。VSM 团队领导者还会辅导、引导并为 VSM 负责人提供精益生产过程方面的指导。

在 IT 社区中集成精益-敏捷实践的原因之一，是因为这两者的基本理念（即哲学和文化）非常相似，正如我们在这里所看到的：

• 作为一个团队工作

• 尊重所有团队成员和利益相关者

• 专注于根据客户需求增加价值

• 作为一个团队协作，立即解决问题，即使这意味着停止其他工作

• 查找并解决根本原因，以防止问题反复出现

• 消除一切形式的浪费活动

• 通过迭代、增量和实验的方式解决问题

• 永远不要停止寻找改进的方法

现在我们已经了解了执行赞助人、经理和 VSM 团队负责人在 VSM 计划中的角色，接下来我们来看看 VSM 团队启动的要求。

启动 VSM 计划

在为 VSM（价值流映射）计划选择一个价值流之前，我们必须为开展一个高效的 VSM 项目建立合适的环境。本节的学习目标就是这个主题。

在选择精益改进的目标价值流之前，我们需要确保目标 VSM 项目与公司的战略计划相连接。我们也可能要求 VSM 计划支持一个投资组合目标。

换句话说，VSM 团队必须清楚理解为何公司要在其项目上进行投资是合理的。改善那些无法积极支持组织使命和战略的价值流活动几乎没有任何意义。当然，在做出 VSM 投资决策时，传统的投资回报率（ROI）标准同样重要。

高层管理人员和经理需要确保为 VSM 计划批准适当的资源。这些资源需要承诺参与工作，并在规划、绘制映射和改进计划中充分参与。

VSM 倡议与基于敏捷开发项目的迭代和递增方面相同。以下图显示了八个 VSM 步骤作为迭代和递增值交付周期，以表示此概念：

图 6.1 - 八个 VSM 步骤作为迭代和递增值交付周期

每个完整执行八步 VSM 规划、映射和改进周期的迭代，每次迭代都逐步提供新的值交付能力。

注意，VSM 团队可能会在八个 VSM 步骤之间来回反弹，通常是为了在迭代的 VSM 周期内获取额外信息。进行 VSM 周期的主要目标是确保工作朝着期望的精益价值流改进活动的连续性进行。

就像基于敏捷概念一样，每个 VSM 迭代都会逐步增加组织实施精益能力的价值。因此，组织的高管必须抵制定义和指定具体结果作为 VSM 努力正当化的诱惑。只要继续在他们的工作中投资是成本合理的，VSM 团队的倡议就会继续存在。

为确保 VSM 倡议具有长期可持续性，高管必须指定一个项目经理或 VSM 冠军，或者在敏捷背景下可能是 Scrum Master 来指导团队的努力。在 VSM 努力期间，VSM 团队负责人、VSM 团队成员和价值流管理者必须全力以赴，致力于他们的价值交付改进工作，并愿意在 VSM 倡议的整个生命周期内维持他们的精益努力。

无论做什么，都值得花些时间准备和规划——不需要很多时间，但可能会有几周的时间。最初，组织的高管或其指定人必须制定 VSM 宪章。宪章正式批准和资助倡议。VSM 宪章还概述了目标和目标，以及工作的广泛范围，并确定了 VSM 团队负责人和成功的高水平度量和结果。

制定并由高管签署 VSM 宪章有助于确保 VSM 倡议有一个或多个高管赞助并希望推动该倡议。组织的高管必须支持并主导这一努力，以获取 VSM 团队支持其确定的改进倡议所需的资金和批准。

一旦批准 VSM 宪章，VSM 团队将制定初步的 VSM 计划。计划在团队工作的概述方面不应过于繁琐或压迫。但是，至少，VSM 计划需要确定以下内容：

• VSM 团队成员

• 可用或需要进行培训和指导的资源

• 用于 VSM 团队工作及其建议的改善 Kaizen 的资金

• VSM 团队为指导组织精益改进所采取的步骤，如本书中概述的八个步骤

• 可用的 VSM 软件工具

• 关于持续的团队和利益相关者沟通的指导

在 VSM 宗旨和计划制定并批准后，VSM 团队负责人会启动一个启动会议，以确保每个人都在同一页上，并理解各自的角色和责任。至少，VSM 团队负责人、所有 VSM 团队成员、赞助高层（即负责预算的高层）以及关键利益相关者必须参加。

随着 VSM 启动会议的召开，VSM 项目正式启动并准备开始工作。

维持 VSM 项目

虽然精益概念相对简单易懂，但实施起来具有挑战性，并且随着时间的推移，维持精益的持续性更加困难。人类天性使得我们容易去关注其他事物或开始放松对细节的把控。

VSM 与敏捷实践有几个共同点——例如，沟通和尊重人员有助于确保困难信息被共享并有效处理。与 Scrum 一样，精益实践鼓励实验和观察（即实证主义），以及通过小的迭代和渐进步骤提升价值，VSM 团队必须愿意展示他们的发现（透明性），检查他们的发现（检查），并在必要时灵活应对并积极改变（适应性）。

最重要的是，执行赞助商和团队领导必须始终全力投入并领导该项工作。参与价值流的人员很快会察觉到，当领导者没有认真对待他们的改进建议时，团队成员会因沮丧而放弃改进努力。

价值流改进活动的可视化是 VSM 维持活动的一个重要组成部分。同样，类似于敏捷概念，VSM 使用视觉辅助工具，提供更新的团队信息和指标，持续告知高层、经理和其他利益相关者工作目标和状态。我们将在本章的 学习精益 部分更详细地讨论视觉辅助工具。

本节总结了对精益承诺的必要性讨论。现在你已经知道承诺精益的重要性，接下来我们来看支持这一目标的工具。

承诺精益 - 工具

本节讨论的工具帮助我们实现对精益的承诺。包括以下工具：

• VSM 宗旨

• 启动会议

• VSM 故事板

每个工具将在接下来的子章节中详细讨论。

VSM 宗旨

VSM 宗旨是一个关键工具，帮助确保你获得高层的承诺。宗旨是管理层和 VSM 团队成员对他们希望达成目标的正式承诺。VSM 宗旨应涵盖以下内容：

• VSM 项目标题

• VSM 宗旨的使命

• 可交付成果

• 预期的范围/方法/活动

• 战略对齐因素

• 时间框架/持续时间

• 团队资源

• 团队流程

• 预期结果

• 主要客户和供应商

• 假设

• 风险

• 内部问题

• 外部问题

附录 A 包括一个 VSM 宪章 的示例。

启动会议

一个 启动会议 是一个重要的会议，确保每个人都准备好开始 VSM 倡议，并知道他们的角色和责任。VSM 倡议的冠军应该出席这次会议，解释团队为什么被组建以及如何被选中。VSM 冠军向 VSM 团队解释为什么执行管理赞助并资助 VSM 倡议。例如，VSM 项目可能解决竞争压力、新兴或利基市场客户需求、减少交货时间、提高质量或其他关于浪费的担忧。

至关重要的是，VSM 冠军必须强调对 VSM 团队成员学习精益原则和工具的重要性，我们稍后在本章中将会详细讨论这一点。

VSM 故事板

VSM 故事板 是本书中介绍的重要工具之一。它作为您 VSM 项目的指南，带领您完成规划、映射和改进所选价值流的八个步骤过程。

VSM 故事板包括以下部分：

• 起始日期

• 已识别的价值流

• VSM 冠军

• VSM 团队成员

• 问题类别

• 主要精益工具

• 当前（现状）状态图

• 未来（预期）状态图

• 指标

• 改善提案/计划

附录 B 包括一个 VSM 故事板模板 的图表。请花点时间查看这个图表，因为我们将在本书的本章和其他章节中经常回顾这个模板。

注意

对于这个最初的 VSM 步骤，“致力于精益”，VSM 冠军完成 VSM 故事板的“第 1”和“第 2”部分，表明初始项目状态、潜在的价值流（如果已确定）、VSM 倡议的负责人姓名以及 VSM 团队成员。

有了这一点，我们已经完成了致力于精益的部分。现在，承诺已经做出，是时候讨论 VSM 团队如何确定最佳的组织价值流来支持其努力了。

选择价值流 - VSM 第 2 步

本节涉及帮助 VSM 团队选择其精益改进倡议的价值流的活动。从长远来看，最初的 VSM 团队可能会继续评估其他价值流。然而，更大的组织也很可能启动多个 VSM 团队，以支持其他价值流的精益改进倡议。

VSM 倡议必须具有紧迫感，以证明对资源和时间的投资是合理的。我们已经知道，组织通常有多个价值流，并且可能没有时间和资源同时处理所有这些流程。因此，我们需要优先考虑团队的努力。

问题变成了：我们应该从哪些方面开始改进？ 根据帕累托原则（也叫80/20 法则和帕累托法则），一些价值流的改进对组织的即时成功比其他的更为关键。组织的高层管理人员可能已经识别出了效率低下、成本高昂、未能生产客户需求的产品或表现出其他浪费特征的领域，但我们仍然需要做工作，识别我们的价值流并优先考虑改进领域。例如，VSM 团队可以进行以下操作：

• 评估组织在多大程度上已识别出其价值流

• 评估每个价值流与以客户为中心的价值交付之间的关系

• 进行研究，发现哪些价值流具有最高的成本和延迟

• 进行客户调查，了解组织在多大程度上满足了他们的需求

• 使用精益指标来识别浪费最多的价值流

• 与员工讨论他们关于需要解决的价值流问题的观察

• 如果有条件的话，进行竞争分析，确定公司在行业中的表现如何

• 识别关键的基准指标，包括公司内外的对比，看看它们与公司内其他业务以及拥有类似价值流的其他企业的比较情况

• 在做 VSM 投资决策时，可以使用SMART缩写——Specific（具体）、Measurable（可测量）、Attainable（可实现）、Relevant（相关）、Time-based（时间导向）

无论采取哪些步骤，VSM 团队必须始终以交付以客户为中心的价值为目标，并尽可能以最精益的方式实现这一目标，无论是在短期还是长期。因此，为了做出这些决定，让我们花点时间重新探讨一下价值这个话题，但在 VSM 的上下文中。

在 VSM 上下文中定义价值

本节重新探讨了与价值流图（VSM）相关的价值概念。你已经知道，从精益的角度来看，价值意味着以产品、服务或成果的形式为内部或外部客户提供价值。此外，价值的概念还意味着活动所提供的结果是客户愿意购买的。

事实上，我们的价值流总是包含某种程度的浪费。那些产生与客户需求无关的结果的活动就是浪费，我们需要尽最大努力消除它们——这正是改善（Kaizen）的核心，Kaizen 是持续改进的日语词汇。

精益中的价值一词适用于我们在价值流和 VSM 活动中所做的工作。但你可能会问，流这个词意味着什么。它字面上的含义与我们所想的非常直接。从隐喻上讲，流指的是一系列顺序的活动，这些活动创造价值，因此 VSM 改善了我们组织中价值的流动。

概念上，工作项沿着价值流活动向下游流动，就像水在小溪或河流中向下游流动一样。比喻来说，正如水流最终汇入大海，精益导向的价值流也最终流向我们的客户。

精益实践者明白，价值流包括增值和非增值的工作活动。从长远来看，我们希望消除非增值的工作活动，尽管在短期内可能不实际做到这一点。

以下图表提供了一个通用的活动工作流程模型的图示，展示了价值流中四个活动的周期时间和等待时间：

图 6.2 – 活动工作流程模型

这个模型开始引入一些在价值流图中使用的图标，但我们将在后续章节中更详细地讨论当前状态和未来状态的价值流图。现在，可以使用图例来解释图表中的信息。

例如，假设我们的工程师知道如何改善活动 2，使其周期时间降低到 1 小时。乍一看，这似乎是一个合理的做法。然而，问题在于系统的主要瓶颈出现在活动 4，因为它的周期时间明显更长，为 3.5 小时。改善上游活动的速度只会意味着更多的产品在活动 4的入口处排队，而流动并没有得到改善。

这个例子是基础的，因为在改善流动时，还需要考虑其他变量。我们可能有可以通过更好的工具改进的设置时间。我们可能有高水平的缺陷，这些缺陷给组织带来的成本超过了活动 4的缓慢输出。到目前为止，我们的价值流图没有说明批量大小或缓冲库存限制，这些都可能显著改变各个已识别活动中的吞吐量和排队情况。

到目前为止，我们所知道的仅仅是活动周期时间和物料的基本流动。然而，我们已经可以看出，这个模型并没有体现精益价值流。相反，它可能更像那些尚未过渡到精益的组织中的情况。例如，箭头表示物料被推送到每个下游活动，并且每个活动之间有缓冲库存，用于处理因周期时间不匹配而产生的溢出。

请注意，总等待时间为 37 小时，总交付时间为 44.5 小时。换句话说，整体交付时间中只有 7.5 小时是工作时间。最可能的原因是周期时间和批量大小不匹配，但我们需要分析整个价值流的流动情况，以确认实际的原因和影响。

精益组织还必须考虑另一个问题，那就是价值流之间的整合或接触点。这个话题将在下一小节中讨论。

整合价值流

价值流互动发生在一个价值流以产品、服务或信息的形式为其他价值流提供所需的价值时。例如，在 IT 行业中，我们经常看到，当以 IT 开发为导向的价值流生产软件产品后，这些产品会通过以运营为导向的价值流交付给内部或外部客户。

我们还可以看到，价值流互动发生在产品和营销管理价值流进行有助于识别客户需求的活动时，这些需求将帮助产品设计、开发和交付导向的价值流。例如，组织可能会开发或采购软件应用程序，以支持其产品和营销管理功能，如下所示：

• 战略规划

• 市场分析

• 产品规划

• 市场进入活动

• 销售赋能

在数字经济中，所有价值流都被 IT 集成并支持，以提供基础设施、计算设备、软件、网络和安全组件。许多物理产品和服务都内置了计算、网络和软件组件作为功能，来增强产品的能力。使用数字功能的价值在于，产品更新可以实时传输到产品中，从而在没有昂贵维护或服务电话的情况下增强现有产品。

但让我们暂时简化一下问题，回到使用数字服务来支持与产品和营销管理相关的价值流的主题。作为我们的示例，图 6.3 显示了一个适应性产品化过程，该过程包括三个产品管理子流程——战略规划、产品规划和市场分析——以及两个营销管理子流程——市场进入和销售赋能。

每个子流程包括多个工作流，如轮辐所示，这些工作流在适应性营销过程中传递价值。理想情况下，每个工作流都经过精简，能够以最小的浪费（如果有的话）交付价值。在这种背景下，每个轮辐都是一种价值流形式。此外，基于每个产品的独特需求以及产品生命周期中的各种需求，这些流程的执行会随着每个产品的生命周期而有所变化。

流程如图所示：

图 6.3 – 产品管理与营销管理流程

产品和营销管理价值流是以运营为导向的——换句话说，它们并不为外部客户开发产品，但它们确实支持我们为外部客户提供帮助和交付价值的能力。在接下来的部分，我们将通过适应性产品化过程为例，深入探讨以运营为导向的价值流是如何运作的。

以运营为导向的价值流整合

根据定义，面向操作的价值流直接与内部或外部客户进行接口，但不直接参与产品开发。面向操作的价值流通常收集、分析并为其客户提供信息。面向操作的价值流也可能直接向组织的客户交付产品和服务。

本小节介绍了支持产品管理和市场营销管理功能的面向操作的价值流活动，我们将以自适应产品化过程作为示例。

自适应产品化过程是一种以客户为中心的方法，帮助组织追踪并响应客户需求。自适应的产品和市场管理方法是为了支持新兴的商业模式而发展起来的，如软件即服务（SaaS）、通过 Web 2.0 实现的新推广和销售市场渠道，以及通过企业对企业（B2B）和企业对消费者（B2C）行业细分向客户销售。

自适应产品化过程的一个关键要素是利用基于社交媒体的营销。因此，自适应产品化过程非常适合在我们的数字经济中工作。

自适应营销过程利用数字化手段支持组织的价值链——换句话说，产品和市场管理价值流已经演变为支持我们在现代数字经济中开发、销售和交付产品的方式。产品和市场管理子过程通过市场和客户信息为客户中心视角的产品需求提供价值。

图 6.3 通过图示方式展示了自适应产品化过程作为中心辐射过程模型——换句话说，工作文档和信息在自适应产品化过程中可以向任何方向流动。因此，当我们设计产品管理和市场营销管理的价值流以及相关的信息系统时，需要考虑这些问题。

使用 IT 类比，我们需要一种价值流集成方法，模拟中心辐射式消息代理的工作，以简化通信、数据流和异步转换。不幸的是，点对点过程和信息集成策略不起作用，因为集成点太多。此外，开发团队无法预见自适应产品化过程中所有可能的信息流或活动交互。

更好的方法是将每个辐射环节中的活动集评估为整体价值流的潜在元素。每个环节代表一个独立的活动或子过程。此外，随着需要的出现，每个子过程可以由其他子过程触发。对于每个产品或产品系列，评估整体产品管理和产品营销价值流，以识别在哪些地方流动瓶颈形成阻塞，哪些地方的浪费妨碍了整体流程。

中心辐射类比并不意味着在自适应产品化过程中，工作是从一个营销价值流推送到另一个营销价值流。在精益导向的生产过程中，工作总是根据上游客户或后续活动的需求按需拉动。

尽管如此，中心辐射类比仍然有其用处，因为工作在所识别的自适应产品管理和产品营销任务中的流动高度依赖于每个产品在其生命周期中的需求。

以Go To Market过程为例，产品定位、市场渠道以及其他相关子过程是潜在的价值流工作流组件。每个工作流组件可能包含多个活动和技术。这些组件子过程有不同的周期时间和等待时间。它们通常都有增值和非增值活动的混合，以及应当随着时间清理的其他形式的浪费。

始终优先改进活动，以消除整体价值流过程中当前的瓶颈。如果你有时间和资源在多个价值流改进计划中开展工作，始终确保将优先级放在解决主导流动瓶颈或最高成本驱动因素上。本章后面会介绍如何使用当前的（现状）和未来的（目标）价值流图，帮助你做出这些评估。

自适应产品化价值流相比最初由 James Martin 定义并概述的产品和营销导向价值流，呈现了一个更复杂的视角。然而，图 6.3中所展示的众多子过程依然具有重要的相关性。该图表还更好地展示了活动的复杂性以及产品和营销管理价值流之间可能的相互作用。通过这个类比，你应该能理解为何 VSM 和 DevOps 是提高整个组织精益价值流的关键推动力。

面向开发的价值流整合

从概念上讲，面向开发的价值流包括了从最初概念到开发完成，再到收到付款所需的所有增值和非增值活动。面向开发的价值流为外部客户生产产品，或者支持组织内部的操作导向价值流。

在制造业中，每个产品系列都有一个独立的价值流。产品系列通常会将共享相似工艺流程的零件或零件编号进行分组。整体目标始终是确保合适的零件和材料在恰当的时间、恰当的地点准时到达，以支持开发过程。

从概念上讲，这意味着与产品订单相关的信息必须在所有上游的面向开发的价值流活动中流动，以将零件与产品及其相关的开发活动匹配。零件和材料必须按正确的顺序到达缓冲区，随后才能支持客户订单的特定生产活动。客户订单信息返回库存管理系统，以触发新的零件和材料替代订单，供应链合作伙伴进行补充。

每个产品领域都有三个主要的价值流，这些价值流相互重叠并共同流动，正如下面所示：

• 一个从概念到发布的价值流——包括所有将概念或想法推向产品设计和工程的活动，确定竞争性定价，建立供应链和采购材料的流程，设计客户订单和报价活动，并确定控制计划发布过程。

• 一个从原材料到成品的价值流——包括所有制造材料和信息活动，以最高质量、最低成本、最短周期时间将产品交付给客户。

• 一个从订单到收款的价值流——从客户订单的接收到付款的收讫。

从概念到发布和从订单到收款是面向运营的价值流，而从原材料到成品则是一个面向开发的价值流。上述三种面向开发的价值流的命名约定遵循之前确定的策略，以明确名称的起始和结束活动。你不必以这种方式命名你的价值流，但这种方法可以帮助更容易地构思每个价值流中的工作内容及其交付物。

就像面向运营的价值流一样，面向开发的价值流也包含多个流程和活动。这些活动在不同行业和公司之间有所不同，因此 VSM 的一个关键要素是定义那些能为你带来更大竞争优势的活动。

这个问题值得反复强调：永远不要试图在没有完整了解价值流的情况下改善单个流程。如果没有当前价值流的图示，你无法知道瓶颈和浪费在哪里。如果改善的流程不是瓶颈所在，那么它可能几乎不会有任何效果，而且在任何时刻，价值流中总是只有一个主要瓶颈。

根据帕累托原则（即 80/20 法则），一旦你解决了当前的主要瓶颈，其他活动的周期时间会在价值流中变得相对较长，从而形成新的瓶颈。这个原则同样适用于解决价值流中的任何形式的浪费。这是我们必须始终实践 Kaizen（即持续改进我们的工作实践，消除下一个最大约束和其他形式的浪费）的主要原因。

在他们的著作《精益办公室中的 VSM》一书中，Dan Tapping 和 Don Shuker 指出，60%到 80%的产品开发成本是非生产性成本。换句话说，最高的成本累积来自于从概念到发布和从订单到现金的价值流。由于这些主要是信息驱动的价值流，因此 VSM 和 DevOps 是所有精益实施活动的关键推动力（Tapping, Shuker; 2002, 2003）。

在我们结束这一小节之前，快速回顾一下帮助识别哪些价值流具有最高机会改善我们价值交付能力的工具。

选择价值流——工具

在每个 VSM（价值流管理）项目开始时，VSM 团队成员应该进行四项活动，以帮助他们选择适合下一个项目的价值流。这些活动包括以下内容：

• 识别未得到充分解决的即时客户需求和关注点

• 执行工作单元路线分析

• 根据最显著的净正面影响来优先选择目标价值流

• 更新团队章程并持续进行头脑风暴

VSM 团队用于协助这四项活动的主要工具包括产品数量（PQ）分析、产品路线（PR）分析、工作单元路线分析以及 VSM 故事板的更新。以下是详细的说明：

• PQ 分析：这涉及创建一个帕累托图，其中包含过去 6 个月内生产的零件或工作项的列表。每个条目包括零件编号、生产数量、累计数量、生产百分比以及生产累计百分比。该分析帮助 VSM 团队快速识别哪些产品线对提升生产量具有最高的贡献和影响。

• PR 分析：如果 PQ 分析的 PQ 比率为 40:60 或更高（即 40%的产品占据 60%以上的零件总数量），则使用 PR 分析来帮助选择你的价值流。换句话说，我们希望围绕具有相似价值流活动的高产量产品形成产品家族。

  使用矩阵或表格格式，在第一列列出产品及其工作量，然后水平列出它们的产品活动序列。接下来，将具有相同过程序列的产品分组并分析过程路线的组合。你的分析应该包括对最高工作量产品、最高成本产品、最低效流程以及当前和未来客户需求的评估。以下截图展示了该分析的示例：

图 6.4 – PR 分析表

在这个示例中，产品团队创建了 PR 表，并可以迅速看到最高工作量的产品1-3都包含活动C、E和G。此外，产品1和3都需要活动A和F。因此，创建一个包含活动A到C以及E到G的价值流作为专用工作站可能是有意义的。然而，在最高工作量的产品列表中，只有产品C需要活动D。需要进一步分析以确定是否将活动D添加为专用工作站进入价值流是否具有成本合理性。

• 工作单元路由分析：这是面向服务的等效于 PR 分析，但不是在矩阵中列出产品线，而是列出你所关注的改进领域中的工作单元或客户群体。

  以下截图展示了工作单元路由分析的工作表格式示例：

图 6.5 – 工作单元路由分析

第一列列出了为客户生产的工作项类型，第二列列出了每个已识别的工作项或客户在一段时间内的平均工作量。接下来的几列在矩阵中列出了支持生产工作项的过程或活动序列。在矩阵中形成的网格中，标记出生产每种产品类型所需的活动或过程。最后，将具有相似流程的工作单元分组，然后根据它们的工作量对所有流程进行排序。

我们的示例显示，工作项类型1、5和6有相似的工作流，总工作量为 1000 个工作项。我们将其称为A 组。另外，工作项1和4具有相同的流程，总工作量为 225 个工作项，我们称其为B 组。工作项3单独存在，仅需要25个单位。

应该很明显，A 组代表公司最大量的工作，其次是B 组。工作项3的生产需求相对较小，除非它异常盈利或为其他产品线造成瓶颈问题，否则可能不需要太多分析。

• 更新的 VSM 故事板：你现在应该明确知道你的 VSM 团队计划专注于哪些价值流进行精益改进活动。更新 VSM 故事板以反映在第二部分中识别的价值流。

到目前为止，你已经学习了八步 VSM 流程中的前两步，这些步骤涉及规划、映射和维持精益改进。第 1 步包括识别并启动核心 VSM 实施团队的活动。接下来，第 2 步的活动帮助识别出最优先的价值流进行 VSM 项目。现在，是时候查看第 3 步了。

了解精益——VSM 第 3 步

在第 3 步中，VSM 团队必须确保他们对精益概念有深入的理解，并且确保在价值流中工作的团队成员理解精益生产的概念。

有许多资源可以用来了解精益生产实践。本节内容是为那些刚刚开始精益学习之旅的人提供的快速入门指南。最重要的是，VSM 团队成员必须学习精益的基本概念，然后加以应用。正是精益原则的应用帮助培养了未来所有 VSM 项目的技能。

制定学习计划

为确保所有团队成员都能发展出足够的技能和理解精益概念，VSM 团队应该通过制定精益学习计划来启动他们的学习活动。制定培训计划通常包括以下六个步骤：

1. 记录所需的技能和知识。

2. 进行当前技能和知识评估。

3. 进行技能和知识差距评估。

4. 设计培训方法（例如，讲师主导的课堂培训、互动小组会议、实操培训、计算机基础和电子学习培训、视频培训、辅导和指导）。

5. 安排并进行培训。

6. 评估培训的效果并进行必要的调整。

基准测试

假设这是你团队的首次 VSM 项目。在这种情况下，他们可能还不清楚在行业中安装精益生产能力的最佳实践和衡量标准是什么。此时，花时间从类似企业或部门收集信息，制定一套基准进行对比分析往往很有帮助。这类活动被称为基准测试，通常涉及使用质量、时间和成本指标分析竞争性做法。

VSM 团队应该通过明确想要改进的内容来开始基准测试活动。坦率地说，团队应该从一开始就这么做，因为这正是 VSM 项目的核心所在。当团队接触潜在的基准测试组织时，他们需要理解这是一个大要求，必须保持谦逊。

你不太可能让你的竞争对手分享这些信息，因此，团队的首要任务是识别与 VSM 团队价值流所执行的工作类型相似的组织和行业。

当 VSM 团队联系其目标标杆合作伙伴时，首先应花时间了解合作伙伴的业务。如果你还没有花时间了解合作伙伴的情况，那么你很难说服潜在的合作伙伴花时间与您合作。此外，向他们表明，你的目标是建立一个双方都能通过共享信息获得双赢的关系——不仅是在短期内，可能还会在长期内实现。这样，两个组织可以继续共同发展和改进，且标杆合作伙伴也不太可能感觉自己被利用。

一旦你知道了 VSM 项目的目标，利用这些信息制定一系列问题来询问你的标杆合作伙伴。这项工作应在与他们会面或甚至联系之前完成。再次强调，这种预备工作将向他们展示你已经做了功课，并且你为合作关系带来了价值。

当你与标杆合作伙伴会面时，VSM 团队应至少有一名成员参与。你不需要让整个 VSM 团队都去，但至少需要两个人——一个记录笔记，另一个提出问题。

你可能提出的问题在涉及机密和专有信息时可能会显得具有侵略性。因此，你需要对他们的担忧保持敏感，并尊重他们的隐私。

面对面的会议几乎总是最适合观察人们的反应并对他们的关切做出适当回应。你的合作伙伴甚至可能愿意在你参观他们的现场时向你的团队展示他们的活动示例。然而，尤其是在当今 COVID-19 大流行的时代，在线电话会议当然也是可行的且合适的。

会议结束后，感谢你的标杆合作伙伴的时间和考虑，并确保按照承诺跟进并分享信息。具体来说，你应该分享你在价值流中实施的 VSM 实践的成果。

标杆实践的目的是拥有一套可以与自身进行比较的指标和程序。假设你选择了标杆合作伙伴，因为他们在你所衡量的领域展示了卓越的能力。在这种情况下，你将拥有一个可靠的基准，能够评估当前状况并定义对未来理想状态的期望。

在实施精益培训计划后，VSM 团队需要确保所有参与者和积极的利益相关者都能充分利用这次培训。具体来说，他们必须理解精益的六个领域。我们将在下一小节中讨论这六个基本概念。

学习精益的基本概念

有六个基本概念，你需要理解才能创建一个精益系统。这六个概念包括：

• 成本降低原则

• 精益的七种浪费

• 精益的两大支柱——JIT 和自动化（Jidoka）

• 5S 系统

• 视觉化工作场所

• 精益应用的三个阶段——需求、流动和平衡

我们将在接下来的子章节中简要回顾这六个精益概念。

成本降低原则

精益中的成本降低原则与主流定价方法相对立，后者通过将成本加总后，再加上期望的利润率来计算产品价格。这种策略的问题在于，焦点既不在顾客身上，也不在如何改进上。如果我们不理解顾客如何评估价值，我们就无法知道他们愿意支付什么价格。此外，如果我们不专注于优化价值传递并根据此定价，我们就可能面临失去业务给竞争对手的风险。

相反，精益组织允许顾客设定售价，而成本和利润则成为变量。换句话说，精益组织通过分析来确定一个可接受的价格，然后评估在整个价值流中必须做什么以消除浪费，从而能够在可接受的价格下交付产品和服务。

七种致命浪费

七种精益浪费增加了成本和时间延迟，或阻碍了质量，而没有为顾客增加价值。精益的七种浪费包括：

• 过度生产：当我们在没有顾客订单或外部顾客历史需求的情况下生产过多的某些东西，或者在工作项尚未被内部顾客要求之前就开始生产时，便会发生过度生产。

  过度生产还会发生在我们获取或开发与其他价值流活动的流动速率不匹配的批量处理过程或高速设备时。回想单件流的理想状态，我们已经知道批量处理会导致队列的形成并造成过量库存。此外，花费金钱、时间和资源来加速某一活动，可能会导致等待时间、瓶颈和队列在整个价值流中形成。

  回想80/20 法则（帕累托原则或帕累托法则）总能提升在你效率问题中排名前 20%的表现，因为这通常代表了你当前浪费和低效的 80%到 90%。通过解决当前的瓶颈问题，你能改善整个价值流中的流动性和产能。

• 等待（Q 时间）：指的是任何事物——包括人、材料、设备或信息——在没有增加价值的工作时所浪费的时间。这种浪费源于隐藏的错误和缺陷、库存持有成本和额外的存储设施。

• 运输：指的是为了执行下一个活动，需要将某物搬动到比实际需要更远的位置，这代表着时间和精力的浪费。运输适用于物料、人员和基于纸张的信息流。

  与运输相关的浪费通常发生在迁移到精益生产之前，当价值流活动在功能或部门内，或由外部供应商提供时，未能为特定产品线支持高效的流动。

  作为浪费的运输，也发生在物品被临时归档、储存、堆放或以其他方式移走时。

• 过度加工：当我们为产品添加客户未要求的功能和特性时，就会发生过度加工。它们可能不被重视，我们不应该在确认有客户需求来证明工作的合理性之前，就开发或交付任何产品功能。此外，只有产品经理或产品所有者进行商业机会评估，了解是否有成本合理的市场来支撑这些增强功能时，我们才能知道这一点。

  过度加工是一种关键的浪费形式，因为我们无法找回我们的时间和资源，而必须承担客户不重视的工作的成本。即使识别出了市场，这些功能或特性也可能不是最优先的，且可能不具有成本合理性。我们的客户可能不愿意支付开发和交付所需的费用来证明成本。

• 库存：指的是任何不立即需要的物料、产品，甚至是资源的过剩库存。我们只需要足够的物料来平衡流程，不需要更多。

  记住，理想情况是所有价值流活动中的单件流，且所有活动的周期时间相等，并且没有切换时间。如果我们能实现这一理想，包括 JIT（准时生产）物料配送，就没有库存的理由。

  与此同时，库存占用空间，可能影响安全，可能在特定情况下过期，或者隐藏库存批次中的缺陷和问题。库存还需要大量资金购买和存储，更糟糕的是——当你最终将库存物料与客户订单匹配时，它们可能不是你需要的（即错误的零件号、型号或类型）。

• 运动：包括任何不必要的动作，去完成操作的过程。运动是一种浪费形式，通常由无效的工作流程或设施布局引起，往往会导致比必要的更多步行、伸手或弯腰。在数字化赋能的背景下，这可以视为过多的过程开销和延迟，或者内建的推式系统和工作流。

  这种浪费形式类似于运输，但规模较小。可以将运输视为跨设施或跨地区的流动，而运动仅限于在或跨链接的价值流活动中的移动范围。

• 缺陷：这是一个隐形的浪费形式，表现为物理产品中的缺陷或软件开发中的漏洞。尽管有时可以互换使用，缺陷在软件开发中指的是产品增强缺少客户要求的功能，而漏洞是指软件代码中的缺陷。

  缺陷通常需要返工或销毁材料和产品。无论是哪种情况，缺陷都非常昂贵。

尽管不包含在原始的七大浪费之一，部分精益思想领袖描述了另一种被称为未被利用的才能的浪费形式。人类拥有能够为组织增加价值的智力和身体素质。特别是，我们员工的智力属性可以通过获得相关经验、知识和技能来增长。

假设我们没有启动改进员工智力潜力的计划。在这种情况下，我们通过限制人力资本的增长以及员工为工作场所带来的创新，允许浪费的产生。人力资本是对我们员工贡献的经济视角，它评估员工的技能、知识和经验，并认为这些因素对组织既带来了价值，也带来了成本。

在这一部分的最后要指出的是，所有在价值流中的浪费形式都包括在产品的整体成本中，因此也影响其价格。这个精益理念至关重要，因为消除浪费代表着改进价值流的机会，从而提供以客户为中心的价值。在这种情况下，浪费的产生是因为我们没有充分利用未被利用的人类才能。

本节总结了我们关于消除浪费的讨论。接下来，我们将继续理解支撑 TPS 的两个精益支柱的重要性：JIT 和 Jidoka。

TPS 的两个支柱

回想一下我们之前关于 TPS 的讨论。在他的书中，大野耐一声称 TPS 基于两个主要概念或支柱：JIT和Jidoka（即自动化）。

TPS 的目标是尽可能快速和高效地生产客户订购的车辆，并尽快交付价值。让我们快速回顾一下 JIT 和 Jidoka 如何为这些目标做出贡献，如下所示：

• JIT 生产：这是一个理想的连续流状态，其中物料按照正确的顺序、在正确的组装点和恰当的时间到达。当客户订单进入时，信号会沿着生产线或价值流传播，以指示每个生产阶段的新物料需求。在先进先出（FIFO）的订单输入系统下，价值流中的订单和物料会向前流动，直到与正确的产品在生产的正确阶段、正确的时间相遇。

  换句话说，JIT 系统是通过客户订单驱动的拉动系统来补充零部件。理想的情况是优化精益流程和价值流活动，使得在需求发生的时刻和地点能够实现单件流补充材料。例如，JIT 系统会在接收到上游客户订单后，触发第三方供应商的零部件和材料配送。在面向 IT 的价值流中，我们通过看板（Kanban）板和卡片来实现相同的概念。

  JIT 是精益生产系统的核心，建立了其脉搏，以确保在需要的时候、需要的地方提供正确的信息、材料和零部件的节奏。

• Jidoka（也叫做自働化）——这利用自动化来执行重复性和危险性的任务。其目标并非用自动化来取代人工。相反，自働化的能力帮助解放工人的时间，让他们能够在价值流中执行需要灵活性和思考的多任务。

  为了实现这一目标，我们必须区分需要人工指导的工作与重复性工作、危险性工作或容易出错的工作，因此这些工作最适合由自动化设备来执行。自働化包括为所有组装和测试过程开发缺陷检测和预防装置以及自动化能力。

  请注意，Jidoka 同样适用于自动化任务，如软件开发中的测试、配置和供应过程。换句话说，CI、测试自动化和 CD 中使用的自动化能力让开发人员能够专注于与需求分析、架构与设计、编码和问题解决等价值增值任务相关的工作。

  Jidoka 的目标是使工作场所高效、安全，同时尽量减少交付低质量或有缺陷产品的可能性。最终，Jidoka 帮助防错你的价值流，同时提供效率和产量，以符合客户需求的速度交付产品（即 Takt 时间）。

  Jidoka 有四个基本概念，概述如下：

  a) 简化或自动化异常发现

  b) 立即停止所有失败或正在失败的活动，即使这意味着需要停工整个价值流，因为我们不希望形成排队。

  c) 在重新启动生产线之前修复问题

  d) 调查并解决问题的根本原因

  这四个过程确保问题能够被迅速发现并解决。此外，Jidoka 的目标是通过防止问题恶化为产生更多浪费，来避免问题失控。最终，我们需要找出根本原因，以便能够防止未来的事故发生。

现在我们已经讨论了 JIT 和 Jidoka 的概念，接下来讨论 5S 系统，这是一个精益生产工具，有助于通过消除浪费来提高工作场所的效率。

5S 系统

与前一部分讨论的精益两大支柱一样，5S 系统是在日本作为 TPS 制造方法的一部分开发的。在启动精益改进计划时，通常会发现价值流过程不协调、杂乱且低效，甚至可能根本不存在。

这种情况常发生在生产多个产品线的制造流水线中，以及在操作导向的价值流中，存在无组织的纸质系统、文件、物资、工具、设备和书籍。5S 系统的主要目的是消除杂乱，改善价值流活动的流动，以结构化的方式进行。

5S一词的来源来自日语中的Seiri、Seiton、Seiso、Seiketsu和Shitsuke。幸运的是，我们有五个以字母S开头的英文词汇，恰好能代表这些日语原词。5S 系统包含了五个步骤，每个步骤的名称都以S开头，如下图所示：

图 6.6 – 5S 系统

每个字母代表一个改进和保持精益实践的步骤。所以，让我们花一点时间来回顾每个步骤所涉及的工作，具体如下：

1. 整理—Seiri（整顿）：首先审查所有的物资、零件、设备、文件、文档、书籍或任何其他杂物，清除在修订或新价值流中不再需要的东西。

2. 整顿—Seiton（有序）：组织剩余的物品以支持高效的工作流程，包括确定并存储库存和缓冲库存区域。安排所有必需的物品，使其便于高效访问。最重要的是，努力保持有序性。

3. 清扫—Seiso（清洁）：在前两个步骤的基础上，花时间清洁区域并检查设备，确保一切正常运作。定期清洁和检查每个工作区。定期清洁的过程有助于确保工作区和设备得到适当的维护，从而减少产生浪费或意外工作停顿的潜在风险。

4. 标准化—Seiketsu（标准化）：这里的目标是标准化活动，以维持价值流中的工作环境——换句话说，创建 5S 标准操作程序，以维持秩序、清洁和工作环境的维护。让你的 5S 标准在工作区内可视并显而易见。

5. 维持—Shitsuke（纪律性）：5S 标准的维护不是偶然发生的。它需要持续的细致关注和纪律性，以确保价值流团队保持对任务的掌控。价值流的倡导者或领导者必须分配责任、跟踪进度并继续循环。他们还负责教育和告知团队成员 5S 过程和标准，以确保持续合规。

5S 系统背后的概念非常简单易懂，但实施和维护却具有挑战性。我们正在工作的价值流必须注重尽职调查和持续关注。消除浪费并防止浪费重新进入价值流系统的回报是值得的。

由于我们已经介绍了将已实施的 5S 系统和标准可视化的概念，以帮助维持纪律性，接下来我们来谈谈视觉辅助工具如何改善价值流图（VSM）的其他方面。

视觉化工作场所

如果你是一个敏捷实践者，你应该已经非常清楚在工作环境中创建视觉辅助工具的重要性，以便提供与你团队工作相关的及时信息。这些视觉辅助工具以大可视化图表（BVCs）和信息辐射器的形式存在。尽管大视觉显示的概念最早起源于 TPS，但正是 IT 创新者 Kent Beck 和 Alistair Cockburn 使得在敏捷实践者的 IT 社区中，使用视觉辅助工具的做法得到了广泛传播。

Kent Beck 在他的书《极限编程解释》（1999）中创造了术语 BVC，而 Alistair Cockburn 在他的书《敏捷软件开发》（2001）中创造了术语 信息辐射器。信息辐射器 是指敏捷或精益敏捷团队在其共用工作区内，以易于看到的位置放置的任何手写、绘制、打印或电子显示装置。

拥有大规模的视觉显示旨在使所有产品团队成员、管理者和其他利益相关者能够迅速找到并查看有关产品待办事项和正在开发的工作项的更新信息。关于生产数据的可视化，请记住那句老话：一幅图胜过千言万语。信息辐射器可以包括看板、燃尽图、燃起图、自动化测试的状态和数量、事件报告、CI 状态，以及任何其他与理解产品团队目标、进度和优先级相关的信息。

现在，让我们继续讨论精益应用的三个阶段，包括需求、流动和平衡的概念。

精益应用的三个阶段——需求、流动和水平化

虽然很诱人想要立即在整个价值流中实施精益实践，但这可能不会取得良好的效果。更好的方法是将分析和实施过程分为三个阶段，首先关注客户需求，其次是持续流动，最后是平衡。

各个阶段应按照以下顺序发生：需求、持续流动和平衡。我们将在下一章的价值流映射中看到这一点，特别是未来状态的映射。但在进入这一主题之前，我们先来看看这些阶段中发生的活动，如下所示：

1. 客户需求阶段：包括一组活动，用于确定我们的客户是谁以及他们的需求。本阶段使用的工具包括 Takt 时间计算、排程计算、缓冲区和安全资源、办公室 5S 以及问题解决方法。

2. 持续流阶段：包括一组活动，帮助在价值流中建立持续流动，以确保正确的单元在正确的时间、以所需的数量到达，支持客户的订单，既包括内部订单也包括外部订单。本阶段使用的工具包括在制超市、看板系统、FIFO 生产线平衡、标准化工作和工作区域设计。

3. 平衡阶段：包括将工作均匀且有效地分配到价值流中的活动。此阶段的工具包括可视化的排程板、负载平衡（heijunka）箱以及运行系统。

前述描述应能明确显示，每个未来状态映射阶段都包括一组独特的活动和工具。如前所述，未来状态映射工作还有一个隐含的流程。我们需要在改善工作流程之前，了解客户需求如何影响我们的价值流；并且在我们能够平衡工作负荷之前，需要先改善工作流程，以应对新的客户订单进入我们的价值流系统。

实施八个 VSM 步骤的指南为在目标价值流中实施精益实践以及保持和改进精益改进提供了坚实的基础。然而，学习如何实施精益实践中的需求、流动和平衡阶段，以实现期望的未来状态目标，也是至关重要的。

以下截图展示了精益应用的三个阶段：需求、流动和平衡，以及每个阶段的工具和阶段的顺序：

图 6.7 – 精益应用的三个阶段：需求、流动和平衡

高层管理者不能强制执行精益实践——这是一个涉及所有团队成员支持价值流映射（VSM）活动的全员参与过程，同时也包括在价值流中工作的员工。员工的参与是下一小节讨论的主题。

员工全面参与

员工被鼓励通过持续改进活动，也就是Kaizen，为改善工作区域做出积极贡献。需要注意的是，在精益管理中，Kaizen 事件与敏捷回顾的理念是等同的。在这两种情况下，产品团队都会预留时间来评估哪些方面做得好，哪些方面做得不够好。目标是探索改善那些不太顺利部分的方法。

Kaizen 这个词来源于日语的两个词根：Kai（拆解）和 Zen（改善）。因此，我们的目标是将问题拆解开来，探索其原因和影响，然后找出如何改变我们做事的方式，从根本上消除问题的根源。

Kaizen 事件或敏捷回顾的结果是制定一个行动计划，列出团队可以立即采取的活动，以改善其表现。在 Kaizen 和回顾过程中，重点必须放在改善工作本身，而不是指责个人。后者只会导致相互指责和团队成员之间的功能失调。就像任何系统一样，一个团队的力量远大于其各个部分的总和，但一个功能失调的团队不再像一台运转顺畅的机器。

每个团队成员必须对眼前的工作有共同的愿景，并将价值流视为一个整体。如果价值流中的某一部分出现问题，那么整个价值流作为一个功能系统就会崩溃。发生这种情况时，所有人需要分享想法，鼓励反馈，并获得认同，以确定解决问题的策略。

请记住，这些好的想法来源于组织的各个层面，包括管理者、利益相关者和员工。因此，所有的想法都需要仔细考虑，无论其来源如何。每个人都需要感受到自己对结果拥有一定的归属感，并鼓励他们改善材料和信息在价值流中的流动，消除成本高昂的浪费。

我的一个好朋友，也是本书的技术审阅者，Enrique Gomez，曾讲述了他在六西格玛培训时学到的一个故事，关于 Kaizen 事件如何具有相当强的攻击性。他举的例子据说发生在一家日本制造厂。某个特定工位的生产任务执行混乱不堪。然而，管理者并没有逐步改进这个工位，而是将工具一股脑扔在地上——这是一个非常生动的拆解例子。然后，操作员们作为一个团队重建了工位，将东西放回需要的位置，移除不必要的工具，并替换掉那些无法正常工作的工具或设备。

通过这种方式，Kaizen 事件虽然相当具有破坏性，但在解决阻碍生产效率的根本问题方面非常有效。简而言之，并非所有的 Kaizen 事件都像友好的敏捷回顾那样进行。它们可能采用高度破坏性的措施来强制实施必要的改进。

类似地，我们也可以通过翻新房屋作为另一个例子，来说明有时需要进行颠覆性的改变。例如，为了使房屋中的厨房更加实用，最好拆除现有的墙壁、设备、台面和橱柜，以便创造一个更好且更实用的工作环境。长期的收益超过短期的干扰。

本节结束了精益概念学习的部分。正如你需要知道精益的模样一样，你还需要知道精益不是怎样的。这就是下一个小节要讨论的内容。

了解何时不属于精益生产

现在，既然你已经了解了精益生产的概念，我们来讨论如何评估在价值流中实施的精益实践的状态。为此，我们需要观察组织中的开发和运营导向流程，并且需要问自己一系列问题。这些问题围绕着流程、订单处理、批量大小、客户需求、清洁度、库存管理和活动换线等方面。

在进一步讨论之前，请注意，在本书中，精益、精益生产和精益产品开发这三个术语是可以互换使用的。三个术语都意味着在运营和开发导向的价值流中实施精益概念。

第一组问题涉及工作、零件、材料和信息的流动。

流程问题

与流程相关的问题有助于评估浪费的运输、运动和等待程度。具体来说，你需要提出问题，了解你的组织在以下方面的实施程度：

• 改变设施布局，以支持工作的连续流动

• 消除导致过多库存、瓶颈和排队现象的批量处理

• 采取措施最大限度地减少所有价值流活动中换线和周期时间的差异

• 采取措施最大限度地减少在价值流活动中运输货物的距离

• 采取措施减少执行每项价值流活动所需的运输距离、运动、重物搬运和弯腰操作

接下来，我们将看一下帮助我们评估订单管理活动精益程度的问题。

订单管理问题

一旦我们解决了流程问题，我们就需要评估订单是如何处理的，包括零件、材料和信息的到达。以下是你在操作中应该问的有关订单处理的问题：

• 零件和材料是否仅在支持现有客户订单时才进行订购和供应？

• 订单在收到时是否会推送到生产中，不管是否有能力承担工作？

• 订单是作为批量处理并处理，还是单独处理？

• 操作员只有在有能力的情况下才能拉取工作吗？

• 价值流操作员是否一次处理多个工作项？

• 在价值流活动中，正确的物料是否在正确的地点和时间出现？

• 在每个活动中，是否可以按需获得所有订单和流程信息，以便执行当前的工作？

到这个阶段，我们应该对流程的效率有一个相当清晰的了解，特别是关于流程流动和订单处理。接下来，我们需要评估订单在价值流中如何根据批量大小来处理。

批量大小问题

VSM（价值流图）实践者试图使价值流的输入、输出和中间活动的持续时间与客户需求同步。换句话说，产品订单进入系统并通过每个活动的速率应该与客户希望交付产品的速率匹配。

例如，如果一个客户每周需要交付 40 个产品，那么理想的生产速率是每周 40 个产品，或者每小时一个产品。为了满足客户在我们的价值流管道中的需求，我们可能会每小时向生产系统引入一个新的工单，生产一个产品。同样，每个中间活动也会每小时循环一次，输出一个产品。生产控制在我们必须批量生产且生产与运输活动之间的持续时间变化时，会变得更加具有挑战性。

从概念上讲，生产控制经理“指挥”工作的流动，就像指挥家指挥乐队保持节奏一样。精益实践者使用“Takt time”（或者更简单的“Takt”）来指代满足客户需求所需的生产节奏。Takt 是德语中指挥家用来调节管弦乐团或乐队节奏的指挥棒的词。

因此，精益生产的理想目标是在所有价值流活动中以一个恒定的速度（等于 Takt 时间）协调所有物料和部件的单件流动。为了实现这一目标，以下是你在运营中应该提出的关于批量大小的问题：

• 在你们的开发和运营价值流中，工作项的批量大小是多少？

• 组织是否已经识别出价值流中每个活动的批量大小（也就是说，某些设备可能最适合处理较大的批量，这可能导致瓶颈和上下游的等待）？

• 组织是否已经采取措施，在所有价值流活动中向单件生产转变？

• 组织需要做些什么才能在所有价值流活动中实现单件生产？

在回答了流动、订单处理和批量大小的问题之后，我们需要根据已知的或预测的客户需求来评估价值流的 Takt 时间。

客户需求问题

在这一部分，我们需要了解客户订单的频率。在圣诞高峰等季节性需求大的行业中，这个问题可能尤为具有挑战性。以下是你应该询问的有关运营中客户需求的问题：

• 你计算过你的价值流程的 Takt 时间吗？

• 是否有历史数据显示 Takt 时间随时间的趋势？

• 你是否需要根据季节调整 Takt 时间？

• 是否有特定的客户一次性下大批订单？

• 你的价值流程生产速率是否与 Takt 时间匹配？

• 确保你的价值流程生产速率与 Takt 时间相等，可以采取哪些措施？

• 组织在管理不同客户需求下的流程方面做得如何？

• 组织管理不同客户需求的订单输入过程是什么？

精益生产旨在匹配生产能力以满足客户需求。提出前述问题的目的是识别组织能够如何调整生产速率以满足客户需求，同时不会影响生产效率或导致其他形式的浪费积累。

你在5S 系统部分早就学到了保持清洁和秩序状态的重要性。做出这些决定是下一组问题的焦点。

清洁度问题

到现在为止，你应该已经对材料、零件和信息在价值流程中的流动情况有了相当好的理解，但是总是问一些具体问题来帮助辨别任何与流动问题有关的原因，特别是与设施的清洁和秩序有关的问题。以下是你应该询问的有关清洁度和运营中秩序程度的问题：

• 你的价值流程工作区是否凌乱或不干净？

• 上次工作区域清洁是什么时候？

• 上次工人清理并去除多余的材料、供应品、文件、文件夹、文档和其他文件是什么时候？

• 在支持最佳流程方面，你的价值流程工作区是否杂乱无章？

• 价值流程中存在哪些维持清洁和组织的过程？

• 是否有清洁和维护流程的视觉展示？

• 是否有检查表来确保遵守清洁和维护流程？

开发清洁和维护流程，然后展示并遵守它们可能看起来有些过度，但投资于这些努力显著降低了停机、延迟、缺陷以及长期成本增加的风险，这导致了我们下一组问题的提出，即库存管理的问题。

库存管理问题

组织通常允许材料作为安全库存和缓冲库存进行排队。缓冲库存允许在客户需求突变时积累材料和零件以维持流动。安全库存存在于价值流或生产线上，以支持在周期时间和批次或批量大小不匹配的情况下，上游和下游过程的正常运行，但无论是安全库存还是缓冲库存，都代表着在持有成本、延迟以及可能隐藏缺陷和问题方面的浪费。

考虑到这些问题，以下是关于库存管理方面你应该询问的几个问题：

• 你的价值流工作区域是否允许零件和材料的排队？

• 你的价值流工作区域是否有明确的存储缓冲区？

• 你的价值流是否执行严格的存储缓冲区限制规则？

• 是否存在材料和物资自然积累并排队的生产活动？

• 你的组织是否知道为什么在运营的某些阶段会出现库存排队？

• 你的组织是否发现库存和缓冲区内有隐性的缺陷和问题？

• 你是否有关于周期时间、等待时间和整个价值流的总交货时间的历史数据？

• 你的价值流是否有流程来最小化材料和零件库存的排队、等待、运输和运动时间？

我们的提问即将完成。我们尚未涉及的一个领域是设定和零件切换时间的影响。这是下一组问题的主题。

活动切换问题

设备设定和零件或工作项目的切换要求似乎是内建的必要条件，但冗长的设定和切换事件会影响库存和库存缓冲区的大小，这些缓冲区用于存储材料和在制品。因此，从精益的角度来看，它们是延迟和等待等形式的浪费的另一个主要原因，同时它们也可能隐藏有缺陷的工作项目和材料。

我们需要进行投资，以减少甚至消除我们价值流中的设定和切换要求，但首先，我们需要了解问题的严重程度。为了回答这个高层次的问题，我们需要通过一系列问题来寻找潜在的原因，涉及设备设定和零件切换要求，例如以下问题：

• 你的设备是否需要定期停机，以便为订单、材料或零件号的变化进行设置？

• 你知道在价值流活动中，由于零件号或客户订单的变化，切换设备所需的时间吗？

• 设定设备时需要哪些信息？

• 支持设备切换所需的工具和模具有哪些？

• 你的设备、设定程序或配置多久会发生一次故障？

• 是否有一个流程来确保当工具和模具发生故障时，可以迅速获得备件？

• 你是否与你的前导时间、周期时间和等待时间一起，测量了设置和换线的时间？

• 你的价值流团队成员是否有积极的项目来评估和改进过多的换线时间？

• 哪些换线活动在等待、排队零件和材料，以及处理延迟上造成了最多问题？

上述问题帮助 VSM 团队评估目标价值流中的精益实施情况。这些问题大多数直接与面向开发的价值流（如物理产品的制造）相关，但由于运营与面向开发的价值流之间的相互依赖，某一价值流中的问题往往会在其关联的价值流中引发负面且意外的后果。

现在你应该对如何了解开发与运营导向的价值流中的精益生产过程有了一个较好的理解，从而能够优先考虑并进行未来的改进。但在我们完全离开这一部分之前，让我们花一点时间回顾一下那些帮助组织学习精益的工具。

学习精益 – 工具

在这一小节中，你将了解组织可以实施的各种工具，来帮助团队成员及其他利益相关者学习精益生产过程的基础知识。主要工具包括以下内容：

• 培训计划

• 基准测试清单

• 需求阶段工具

• 流程阶段工具

• 定级阶段工具

我们将通过回顾精益培训计划的组成部分来开始这次讨论。

培训计划

培训计划是帮助组织引导员工及其他利益相关者提升技能和知识的重要工具。精益培训计划应包括以下几个部分：

• 所需技能和知识领域列表

• 计划评估受影响团队成员的现有技能和知识水平以及他们的培训需求

• 列出可用或期望的培训资源和材料，包括以下内容：

  a) 微学习：这包括开发和部署简短且精确的内容单元，用于教授关键的精益理念或实践。这些模块必须易于发现、具有吸引力，并且具有实际应用价值。

  b) 视听：这包括整合视觉和听觉格式，通常以幻灯片或视频内容和录制的语音形式，来展示精益理念。可能会加入音乐覆盖层，以使内容更加吸引人。

  c) 互动内容：这可以是基于网页的，或者是多媒体演示的一部分。这种教学方式要求员工完成特定任务，如参加测验或调查、参与社区讨论板，或通过游戏化的方法测试学生解决特定问题的能力。

  d) 图像：与文本说明结合提供的照片、信息图和图表，有助于说明精益理念和活动。

  e) 播客：音频或视听内容可以帮助员工在非传统学习环境中，从组织的导师和教练那里找到时间学习精益理念——也就是说，在课堂或办公室之外。

• 培训内容开发计划

• 培训交付计划

• 用于评估培训效果的过程

基准测试清单

基准测试是一个强大的工具，用于收集其他组织的价值流——甚至其他组织——如何采用精益实践的信息，但要充分利用这种方法，基准测试评估团队必须在与基准组织会面之前准备好他们的问题清单。基准测试清单应明确你想要获取的信息。

你必须确定一个你认为在你希望效仿的精益价值流领域中具备世界级能力的组织，确保基准组织充分有动机与你的团队合作会有帮助。这个任务可能具有挑战性，因为你需要弄清楚对方为何支持你的努力。同时，提前了解一些基准组织的情况，也有助于让他们知道你已经做了功课，不会浪费他们的时间。

最好在会议前提前发送你拟定的问题，以便对方有时间准备。与基准组织会面时，最好有不止一位人员参加基准测试团队，以便分工合作，一人提问，另一人记录笔记。同样，你也可以要求基准组织派出不止一位成员，以便充分提供所需的专业知识来涵盖你希望讨论的主题。

现在，让我们继续讨论精益需求阶段工具。

注意

术语阶段和阶段性在需求、流动和水平化这三个精益应用过程中可以互换使用。

需求阶段工具

在本章中，你学习了三个精益应用阶段：需求、流动和水平化。本小节介绍了需求阶段的工具，如下所示：

• Takt 时间：这是顾客需求的节奏。Takt 时间是可用生产时间除以同一时期内所需的总数量（即秒、分钟、小时、天、周或月）。简而言之，Takt 时间是时间除以数量的衡量标准。

• 提速：这是基于 Takt 时间的一个量度，表示上游操作将预定数量的在制品交付给下游客户所需的时间。当上游过程必须一次性批量交付一批物品时，这个问题就显得尤为重要。

  例如，客户可能会批量订购产品，按箱装、卡车装或集装箱运输。大宗订单通常更便宜，成为客户采购决策的一部分，即使这些到货量未必符合公司理想的单件流目标。另一方面，作为生产商，你可能更喜欢知道客户愿意每月下订单订购 1,000 个小部件，因此你希望以最具成本效益的方式进行运输。

  解决这个问题的方法是计算一个投放率，该率等于 Takt 时间乘以大宗包装质量。如果你的 Takt 时间是 6 分钟，理想的运输单元为每个集装箱 100 个小部件，那么你的投放率就是 600 分钟。因此，你应该能够在每 10 个生产小时内释放 100 个小部件。这个投放率也意味着，你可以每 10 小时将 100 个客户的月度小部件订单交付到价值流中。公式如下所示：6 分钟（Takt 时间） X 100 个小部件 = 600 分钟。

  投放概念也适用于反向情况——例如，假设你的价值流无法实现单件流。假设某个价值流的 Takt 时间为 30 秒，但必须以 20 件为批次进行生产。在这种情况下，价值流的投放率是 300 秒，这意味着每 5 分钟释放 10 个新订单。公式如下所示：30 秒（Takt 时间） X 10 件 = 300 秒。

• Takt 图像：这是一种可视化过程，其中价值团队成员必须有实现单件流的愿景，并消除所有形式的浪费。理想状态永远无法完全实现。遵循 80/20 规则（即帕累托原则），总有一些我们可以改进的地方——这正是要点。永远不要停止可视化改进你价值流活动的方法，始终追求精益理念。

• 缓冲和安全库存：缓冲库存和安全库存是浪费的形式，应尽量避免。然而，在短期内，直到达到改进后的未来状态，你可能需要缓冲和安全库存来满足客户需求。

  缓冲库存是用于确保当客户需求突然增加时能够交付的成品存货——换句话说，是用来防止 Takt 时间出现大幅波动的库存。

  相比之下，安全库存是用于应对内部问题的成品存货，这些问题可能会减慢或阻止在制品的生产（例如，劳动力问题、物料供应问题、质量问题、设备可靠性问题和换线问题）。

• 成品超市：从概念上讲，想象客户像从超市货架上取商品一样，在需要时从你的价值流货架上取订单。在超市中，员工会定期以批量处理方式补充货架上的商品，但客户会根据需求以小批量从货架上取商品。

• 无人值守制造：在概念上，这包括任何可以在没有操作员参与的情况下自动运行的精益生产过程。例如，在 DevOps 中，我们可能会在夜间运行自动化测试流程，以检查软件开发人员第二天上班时可以修复的错误和缺陷。

  如果你的价值流的部分或全部以这种方式运作，这里有一些需要考虑的因素：

  a) 自动化过程有多耐用？

  b) 执行过程所需的材料和信息的可靠性如何？

  c) 执行过程所需的材料和信息流有多复杂？

  d) 在自动化模式下运行的最佳批量是多少？

这一节完成了我们对精益需求阶段工具的介绍。我们将继续介绍支持精益流程改进阶段的工具。

流程阶段工具

本小节介绍了流程阶段或阶段的工具。首先，我们将从连续流程的介绍开始，如下所示：

• 连续流程：这也被称为一对一制造。连续流是一种理想状态；价值流中的每个活动从上游活动中拉取一个工作项，并且只处理这一个产品。但连续流也可以在一个较少理想的状态下工作，其中每个活动从上游活动中拉取一个小批量，然后在完成该小批量的工作。并不需要让整个价值流都同步移动，但这是理想的目标。

• 工作单元：工作设施的布局对敏捷和精益实践都至关重要。在时间和空间允许的情况下，最好将工作站和设备按顺序安排以支持工作流程。对于劳动密集型活动，通常有逆时针流动以支持绝大多数右撇子工人的努力是有用的——研究表明，70%到 90%的人是右撇子。

  将设备和工作站靠近考虑安全因素，以最小化站点间的运动和传输。虽然我们希望我们的工作顺序流动，但并不需要线性流动。相反，通常最好将价值流的最后一个站点靠近第一个站点，这意味着 U 形工作环境通常是最优的。但是，其他形状也可以工作，例如 C 形，L 形，S 形或 V 形的单元。设备和资源约束以及可用性通常决定单元设计的最佳形状。

• 线平衡：尽管我们尽力而为，但往往参与价值流的活动的周期时间有所不同。在这样的环境中很难实现连续流，导致过多的排队和等待时间。克服这个问题的一种策略是线平衡。

  线路平衡是一个过程，在这个过程中，我们将工作活动进行合并，以分配工作流，从而创建大致相等的周期时间（即加工时间）。根据定义，周期时间是从活动开始到完成的时间。我们希望我们的周期时间与 Takt 时间相同，但这种情况很少发生，尤其是当 Takt 时间随着时间变化时。

  以下图示提供了一个 U 型价值流的示例，展示了如何将活动分组，以便平衡流动，使周期时间匹配。目标是使每个分组的周期时间大约为 30 秒，这与最长活动A1、A4、A7和A12的周期时间相匹配：

图 6.8 – 线路平衡示例

另外，注意到所有 12 个活动的总周期时间是 210 秒，其中包括 7 个单元，每个 30 秒。当然，我们没有包括等待时间。由于我们已经平衡了我们的生产线，我们希望在这个示例中不会有等待时间。

不幸的是，我们很少能得到像图 6.8中所展示的那样理想的世界。例如，价值流通常会生产多种产品、服务或结果的变体。每种产品变体可能需要不同的处理时间，并具有不同的设置或转换要求。它们甚至可能以不同的工作模式穿越价值流，并以不同的方式利用劳动力。

在这种情况下，分析平衡价值流的方法超出了本书的范围。然而，如果你发现自己处于这样的情况，开发一个操作员平衡图作为各个活动的工作元素、时间要求和操作员的可视化展示将会有所帮助。

开发操作员平衡图是一个两步过程。首先，我们希望创建一个快速表格，展示每个产品线活动的周期时间。我们还希望显示每个活动所需的操作员数量，以及整个价值流活动所需的操作员总数。

以下截图提供了操作员平衡图准备表的示例：

图 6.9 – 操作员平衡图准备表

接下来，我们创建一个条形图，显示活动及其周期时间，并绘制一条表示 Takt 时间的线。下一步是评估通过将周期时间较短的活动进行合并，以及共享资源的方式来平衡流动。

以下截图展示了单一产品的操作员平衡图示例。类似的图表需要在产品线之间进行开发：

图 6.10 – 操作员平衡图

现在，让我们关注一种视觉展示，它有助于确保工人通过标准化工作表以标准化的方式执行其活动。

• 标准化工作表：这种工作表是一种以图表形式呈现的视觉辅助工具，展示价值流中操作的顺序。标准化工作表应展示活动的周期时间、质量检查、安全措施、标准工作流程、作为在制品（WIP）的件数、节拍时间、总周期时间以及操作员数量。

  以下截图展示了这种格式的标准工作表：

图 6.11 – 标准化工作表

另一种展示方式是通过表格形式创建工作表，展示活动顺序、活动描述和活动持续时间。以下截图展示了一种采用这种格式的标准工作组合表：

图 6.12 – 标准工作组合表

接下来我们将讨论快速换模方法，它能将换模时间保持在一分钟或更短。

• 快速换模：顾名思义，这种方法旨在确保我们能够迅速从一种活动切换到另一种，即使产品类型发生变化。这一概念来源于丰田的 Shigeo Shingo 的工作，旨在开发能够实现 SMED（单分钟换模）的方法。

  从客户的角度来看，设备和物料之间的换装时间和精力完全是浪费。他们希望支付成品费用，而不是设备设置或信息检索的活动费用。后者（及时检索正确信息）尤其影响协助价值流改进的 IT 专家。

• 自主维护：在制造环境中，自主维护活动旨在消除潜在的设备故障原因。换句话说，我们可以将这些策略视为预防性维护。我们在以操作为导向的价值流中也有类似的社区需求，来实施适当的维护、安全、回滚和故障切换功能。

• 在制超市：如前所述，超市提供成品库存缓冲区，客户可以按需取用产品。然而，当在价值流中难以实现连续流动时，在制超市策略允许在流程中建立排队，使得上游活动在其能力可用时有在制品（WIP）可以提取。这种策略有助于缓解当多个需求针对单一机器或活动时的生产不足。

• 看板系统：这是一种基于信号的池式系统，利用附在物料容器上的卡片来指示标准批量大小。当容器中的物料耗尽时，卡片会指示需要更换的物料及其数量。

  看板系统在基于 IT 的精益敏捷社区中变得非常流行，尽管这一方法与原始的精益生产概念略有不同。基于 IT 的看板系统通常采用一个白板，白板上用垂直线将其分割成几个列，列与团队的开发过程活动步骤相对应。团队成员在便签上写下产品待办项的名称，以便将其放置在各个列中。当团队成员有空接受新任务时，他们会查看上游活动列，看看有哪些可供他们选择的工作项，并从中做出工作选择。

  基于 IT 的看板系统的价值在于它促进了软件开发活动中工作的持续流动。在传统的敏捷流程中，例如 Scrum 或极限编程（XP），工作项作为一个批次被拉入 Sprint 待办事项列表，Sprint 的持续时间限制了这一批次工作项的流动。

• FIFO lanes（先进先出通道）：FIFO 是一种在精益价值流中使用的生产控制策略，适用于工作项之间存在较大差异，并且多个价值流汇聚以进行最终组装或定制产品的情况。在这种情况下，我们需要确保零件不会因无人处理或无法进行必要的变换而卡在队列中。FIFO 策略确保在队列中等待时间最长的产品始终具有最高优先级。

• 生产调度：这与调度零件和材料以支持精益价值流中的工作流动有关。你还可以将信息调度纳入其中，确保客户订单要求的信息也能在正确的时间和正确的上下文中出现在价值流中的每个活动中。关键点是，在拉动导向的系统中，生产调度和库存控制系统必须协调上游活动，以支持离客户最近的下游操作的需求。

  的确，理解拉动导向的生产流程可能具有一定挑战性。从直觉上看，当有新的客户订单进入时，我们应该立即将其推送到生产车间，并让每个后续的生产阶段推动产品通过制造过程。然而，正如你现在所知道的那样，将产品推送通过生产过程只会造成排队和等待时间，隐藏缺陷和缺陷，并产生其他形式的浪费，从而阻碍生产力，同时增加成本。

  在精益企业中，较好的策略是从概念上让每个下游活动通过生产过程拉动订单。实施拉动式生产调度策略可以立即暴露问题，因为下游活动由于上游障碍而缺乏工作。此外，组织需要完善其信息系统，以确保零件和物料按照正确的顺序、到达正确的位置、在正确的时间到达。

  精益组织中的 IT 部门必须与价值流协同工作，以开发支持新精益流程的业务信息系统。

本节完成了我们对支持持续流动的工具的介绍。接下来，我们将介绍精益平准化阶段的工具。

平衡阶段工具

在解决了客户需求和流动问题之前，我们不能开始改进生产负荷水平，但现在我们已经解决了这些问题，接下来可以看看帮助我们平衡价值流中生产流动的工具，使其变得更加高效和生产力更强。本小节介绍了平准化阶段或阶段的工具，具体如下：

• 节奏化提取促进了在客户希望以标准包装量交付产品时的配送，而不是逐个交付。然而，节奏化提取仅在价值流中没有产品变异的情况下有效。换句话说，生产流动是稳定的，产品线之间几乎没有或根本没有换线，并且周期时间大致相同。

  节奏化提取的时间等于节拍。回顾一下，节拍等于 takt 时间乘以包装量。节奏化提取通过将下游客户的总需求在指定的时间内分配到等于包装量的批次大小，帮助平衡生产流。

• 平准化（负荷平衡）是一个更好且更强健的方式，用于平衡具有不匹配生产活动的价值流中的生产计划。平准化使用基于节拍的节奏化提取法来平衡生产，但它根据生产产品的数量和种类，将其拆分为基于看板单元的计划。

  图 6.12展示了一个平准化负荷表的示例。假设这个精益价值流每天可以生产 500 个单位的产品，涵盖五个基本的产品线变种（即产品A到E），并且假设下游客户的批量交付要求为每批 25 个单位。

  此外，我们的价值流每天仅运行一个班次，总的可用生产时间为 28,800 分钟。因此，我们的 takt 时间等于可用时间 28,800 分钟除以我们的生产量 500 个单位，即 57.6 秒，而我们的节拍等于 takt 时间乘以我们的批量大小 25，即 1,440 秒（24 分钟）。换句话说，每 24 分钟，我们需要能够发运 25 个单位的产品。

  但现在，我们需要决定按产品线交货的频率。为此，我们需要知道每种产品的每日生产量。通过将每日需求量除以包装大小，我们可以确定每天为每种产品类型形成并释放多少个看板。下图展示了每种产品类型所需的看板数量：

图 6.13 – 平准化负载表

我们还可以看到，每班次需要生产 20 个每个 25 个单元的看板。最后，平准化表帮助我们评估看板如何在各产品类型间分配（如图 6.13底部行所示）。

现在我们已经知道每种产品类型所需的看板数量，我们可以确定如何将它们安排进生产。接下来将讨论的平准化盒子是一种不错的方法。

• 平准化盒子，最初的构想是一个物理盒子，用来将看板卡片放入槽中，槽对应于一天中的特定时间段。平准化盒子的目标是平衡固定时间段的工作负荷。然而，我们也可以在电子图表或表格中以类似的方式调度和平衡看板。下图展示了一个这样的例子：

图 6.14 – 平准化盒子

有时，我们必须依靠蛮力来迅速完成任务。生产调度和平衡的这种方法是接下来要介绍的内容。

• 跑步员是指从一个活动地点到另一个地点，快速移动物料并及时解决生产问题的人。跑步员的主要目标是确保生产节奏得以保持。他们通常在生产节奏范围内沿指定路线行走，拾取看板卡片，供应工具和物料，并在合适的时间将它们送到合适的位置。

  生产线上的“跑步员”不能只是任何一个新员工，或者是对价值流生产活动和要求有深入理解的员工。他们必须具备出色的沟通技能，能够识别问题并报告任何阻碍流程的异常情况。他们必须理解精益概念以及 takt 时间和生产节奏的重要性。最后，他们必须能够高效且准确地完成工作。

VSM 故事板更新

在学习精益 VSM 步骤时，你需要准备好使用的另一个工具是 VSM 故事板。回顾一下，VSM 故事板是一个可视化工具，用来更新 VSM 项目的信息、指标和价值流图。该阶段对 VSM 故事板的主要更新是记录 VSM 团队可能选择解决的问题类别或问题。

如果你还没有这样做，你应该现在创建你的 VSM 故事板。你需要的仅仅是一个简单的大白板和一些标记笔，放置在一个共享或集中式的空间中。你可以使用附录 B中提供的 VSM 故事板作为示例，帮助你的 VSM 团队构建他们的故事板。请注意，附录 B中的示例 VSM 故事板使用了编号图标来指示在每个 VSM 步骤中需要更新的信息。

根据你在本章中学到的信息，你现在已经准备好开始绘制你当前状态的价值流图，这是下一章的主题。

总结

本节结束了我们关于 VSM 参与规划和准备的章节。在本章开始时，你了解到 VSM 是一种精益商业方法，旨在改善组织内价值流的流动，并从端到端管理和监控开发和交付生命周期。你已经了解到 VSM 并不是一个新概念。规划、绘制和改进精益生产流程在开发和运营导向的价值流中的传统步骤有八个。

最重要的是，你学到了 VSM 不仅仅是关于在 DevOps 范式中改善 IT 操作。相反，VSM 在我们的数字经济中作为一个强大的倍增器，通过利用精益和 DevOps 能力，改善、监控和管理组织中所有开发和运营导向的价值流。

在下一章中，你将学习如何绘制你价值流操作的当前状态和未来状态。你还将学习如何持续实施精益 Kaizen（即持续改进）过程。但在我们进入下一章之前，让我们花一点时间回顾一下你在本章中学到的内容。

问题

为了增强你的学习体验，请花一些时间回答以下 10 个问题：

1. VSM 的基本内容是什么？

2. 列出三个精益实践对组织至关重要的原因。

3. 确定所选价值流“精益度”程度的可行策略是什么？

4. 精益应用的三个阶段是什么？

5. 为什么基准测试是一个重要的精益评估工具？

6. Heijunka 的目的和目标是什么？

7. VSM 与组织之间的关系如何？

8. 有哪三条主要的价值流是交叉并一起流动的？

9. 列出你需要理解的六个基本概念，以创建一个精益系统。

10. 精益的七种致命浪费是什么？

进一步阅读

• 丰田公司（2013）准时生产—完全消除浪费的理念 (www.toyota.com.cn/company/vision_philosophy/toyota_production_system/just-in-time.html)

• 新乡清（Shingo），S.，迪龙，A. P.（2005）。《丰田生产方式研究：从工业工程角度看（按需生产，及时生产）》第一版，英文翻译。CRC 出版社，泰勒与弗朗西斯集团。佛罗里达州博卡拉顿。

• 克拉夫奇克，约翰·F.（1988 年秋季）。《精益生产系统的胜利》。斯隆管理评论，1988 年秋季；30，第 1 期；ABI/INFORM Global，第 41 页。

• 科特尔，J.（2014）。《加速（XLR8）：为快速变化的世界构建战略敏捷性》。哈佛商业评论出版社。波士顿，MA。

• 马丁，J.（1995）。《伟大的过渡：利用企业工程的七个学科来协调人员、技术和战略》。美国管理协会，现在是哈珀柯林斯领导力部门的一部分。纽约，NY。

• 塔平，D.，卢斯特，T.，舒克，T.（2002）。《价值流管理：规划、绘制和维持精益改进的八个步骤》。生产力出版社。纽约，NY。

• 塔平，D.，卢斯特，T.，舒克，T.（2003）。《精益办公室的价值流管理：规划、绘制和维持精益改进的八个步骤》。生产力出版社。纽约，NY。

• 格雷戈里，L.（2018 年 9 月）。《丰田的组织结构：分析》。(链接) 访问日期：2020 年 12 月 28 日。

• 大野耐一（Ohno，T.），博德克，N.（1988）。《丰田生产方式：超越大规模生产》。生产力出版社。劳特利奇/泰勒与弗朗西斯集团。英格福出版公司。伦敦，英格兰。（原版于 1978 年在日本出版）

第七章：绘制当前状态（VSM 第 4 步）

在前两章中，你学习了价值流管理（VSM）的目的以及如何规划 VSM 计划。接下来，我们将深入探讨在 VSM 计划中进行的分析类型。具体而言，你将学习如何创建价值流图来描述当前的流程。这是我们八步 VSM 方法论中的第 4 步。

虽然直接开始工作并实施变更以消除感知中的浪费领域可能很有诱惑力，但问题在于，如果没有适当的分析，你的努力可能无法得到你和你的 VSM 团队预期的结果。如果没有当前状态的价值流图，你可能没有意识到当前价值流活动所带来的系统性影响。具体来说，我们需要记录现有的活动流程、订单录入系统、生产控制系统、周期时间、设备设置和产品换型时间、批量和批次大小、质量水平、缺陷以及不同步的物料和信息流。

在本章中，我们将讨论以下主要内容：

• 评估精益实践的当前状态

• 开始绘制价值流图

• 开始绘制价值流图

• 创建信息技术（IT）价值流图

根据本章提供的指导，你将能够在几乎任何类型的价值流中创建当前状态的价值流图。此外，本练习中使用的持续集成/持续交付（CI/CD）案例将帮助你可视化如何使用价值流图来评估面向软件开发的价值流。

评估精益实践的当前状态

在经典的业务流程分析技术中，常见的做法是分析当前的工作方式（现状），然后评估需要改进的领域，以实现期望的未来状态（目标状态），进行分析以了解为实现这些变化所需的全部工作（差距分析），最后创建并执行过渡计划。你会发现，VSM 实践遵循了类似的模式。本章介绍了如何从精益导向的视角，利用价值流图评估我们 CI/CD 活动的当前现状。

如前所述，在第四章中，定义价值流管理，价值流图的概念已经存在一段时间了。然而，它主要归因于丰田使用的一种分析方法，称为材料与信息流映射。正如材料和信息流这一术语所暗示的，价值流图提供了一种图形化的技术，用以同时建模材料和信息在价值流活动中的流动。但在深入了解价值流图之前，让我们先了解这种技术与其他业务建模技术的不同之处。

对比业务流程建模技术

参与业务流程改进（BPI）或计算机辅助系统工程（CASE）工具的人，可能对业务流程建模技术比较熟悉。例如，对象管理集团®（OMG®）业务流程模型和标记（BPMN）规范是 IT 社区中业务流程建模的标准规范。

其他流程建模标准包括统一建模语言（UML）中的活动图和流程描述捕获方法集成定义（IDEF3）。UML 最初由 Rational Software 公司创建，但现在已成为 OMG 标准，而美国（US）空军在集成计算机辅助制造（ICAM）计划下开发了 IDEF3。此外，IT 专家可能还熟悉各种工作流建模工具和技术，例如Web 服务业务流程执行语言（WS-BPEL），通常简称为BPEL。BPEL 是一种标准的可执行语言，用于在 Web 服务中指定业务流程操作。

鉴于有这么多正式的业务流程建模标准，你可能会想知道为什么我们需要一个不同的标准来建模精益业务实践。答案在于每种建模技术的重点不同。

价值流图提供了一个高层次的视图，展示信息和材料的流动，并提供了一个理想的图形设计，用于记录、传达并最终消除影响效率的浪费，以及影响组织提供以客户为中心的价值的能力。正如其名称所示，价值流图迫使组织将增加价值的活动与其他活动以及由官僚膨胀积累的浪费行为区分开来。价值流图的总体目标是识别并消除妨碍生产力的浪费——从创意生成到产品和服务的交付——并妨碍组织提供以客户为中心的价值的能力。

价值流映射的另一个重要方面是为 VSM 和价值流团队成员及其他利益相关者之间的视觉协作提供一个平台。这些图示使参与者能够更好地沟通他们对当前运营的理解，并且在之后评估和传达替代的变革方案。

相比之下，业务流程改进和以工作流为导向的流程建模技术，专注于识别工作流的协调，并为业务流程自动化工作提供关于数据和数据流的详细信息。BPMN 是通过软件应用程序促进 BPI 的经典方法。而 BPEL 是通过基于 Web 的应用程序来建模和改进业务流程数据和信息流的现代方法。

业务流程模型提供了跨领域和跨职能业务环境中技术与组织活动相互作用的详细视觉展示，强调了复杂的互动和决策点。业务流程模型通常用于支持业务流程再造和改进活动，并创建自动化这些改进的业务系统。

换句话说，IT 社区和 BPI 分析师使用的标准化业务流程建模技术专注于建模业务流程以实现自动化。而价值流映射技术则建模跨价值流的工作和信息流，以消除浪费，作为精益改进倡议的一部分。

顺便提一句，在 1990 年代初到中期，作为领导AT&T 全球信息解决方案（AT&T GIS）的 CASE 工具和工作流策略的产品经理，我与《电子绩效支持系统》一书的作者Gloria Gery合作（Gery, 1991）。我们的合作目标是确保我们的专业服务组织构建的电子绩效支持系统（EPSS）能够支持客户业务流程中既有专家又有新手从业人员的需求。

我当时以及现在仍然最关心的一点是，许多业务系统并没有帮助支持从价值流角度流动的工作。例如，假设你的业务系统没有帮助强化工作和信息流的期望目标状态，那么你将很难实现 VSM 倡议的目标和任务。

业务流程的自动化与精益实践并不矛盾，正如你将在下一节中看到的那样。因此，两种建模方法——价值流映射与流程建模的结合——对于实现 VSM（价值流映射）倡议的更广泛效率目标至关重要。

业务流程的自动化

在 Lean 实践中，使用流程建模工具（尤其是 BPEL）来自动化业务流程并不矛盾，因为这样的活动与丰田生产方式（TPS）中的自働化（也称自动化）概念是一致的。但在我们不知道一个业务流程是否高效并且具有增值之前，自动化该流程是没有意义的。

确实——我们可能能够采用自动化和数字化信息系统，也许是现成商业软件（COTS）解决方案的组合，使我们的流程更加高效。但过快推进的危险在于，可能会出现吞吐量不匹配、隐藏缺陷，或充斥着没有增值的工作，最终我们会把浪费进行自动化。而且，即便是 COTS 解决方案，通常也需要高度定制才能实现有效的业务流程，使得组织具备高效、增值和竞争力。

在奠定了这些基础后，让我们开始进行价值流映射练习。

开始映射

对于这一部分，我们假设你的组织和 VSM 团队已经完全准备好并致力于 Lean 实践。你们也已经选择了价值流，并学习了 Lean 实践的基本原理。现在，是时候开始工作，开始向 Lean 企业过渡了。没有理由再拖延了。用丰田的泰一千·大野的话说：

去做吧！

由于这是一本关于 VSM 推动开发-运营（DevOps）能力的书，我们的示例遵循 Lean 方法在 IT 价值流的持续集成（CI）和持续交付（CD）部分中的改进。如你在第五章《通过 DevOps 管道推动商业价值》中学到的，CI/CD 实践是更广泛的 DevOps 管道的一个子集。因此，我们的 CI/CD VSM 用例示例旨在简化分析范围，重点介绍如何使用 VSM 方法和工具。

别忘了，DevOps 几乎是数字经济中所有价值流改进的关键推动力。然而，本书中介绍的原则和技术同样适用于所有 VSM 项目，无论正在改进的是哪个价值流。

最后一条提示：请花点时间查看附录 B中的 VSM 故事板。它是记录当前和未来状态价值流映射活动的主要工具。

构建价值流映射图标标准

价值流映射的一个关键组成部分是坚持使用特定的图标来描述你的价值流系统元素——例如，图 7.1，你很快就会看到，展示了最常见的价值流映射符号作为图标。当然，你的组织或 VSM 团队也可以选择使用其他图标。这没有问题，因为没有一个权威标准机构来管理价值流映射的图标。

然而，确保每个人都完全理解在您的价值流图中使用的图标定义，并且不允许人们在没有适当协议和沟通的情况下创建非标准图标。没有标准，VSM 团队成员和其他审核图的利益相关者之间的沟通和理解会迅速恶化。本书中使用的价值流图符号按类别组织，如下所示：

• 过程：识别跨越客户和供应商的工作活动，包括专用和共享流程、活动工作单元以及数据框，显示关键的信息和指标。

• 材料：指示材料在价值流各个阶段的处理方式，包括库存和缓冲库存，以及生产控制策略，如超市、拉动和先进先出（FIFO）。

• 运输：包括所有识别出的用于运输材料、零部件和产品的机制，包括空运、叉车、卡车、船只或轮船。但您的组织也可以包含用于显示由铁路、自动化线、机器人或第三方运输公司进行的运输的图标。

• 信息：捕获度量指标，以提供当前状态（现状）和期望的未来状态（目标状态）分析，并提供支持开发和运营价值流工作流的信息。图 7.1 中显示的图标表示从多个来源收集的信息，例如：

  a) Gemba（现场观察）活动或口头沟通

  b) 在企业资源规划（ERP）/物料需求计划（MRP）系统中维护的信息

  c) 来自生产控制数据或策略的信息

• 价值流图：用于显示价值流中的特定点，团队希望在图中突出显示某些感兴趣的区域，如 Kaizen 爆发（即快速过程改进（RPI）计划要求）、操作员、时效性或质量问题。

• 看板箭头：显示材料和信息在运输和生产过程中的流动。请注意，直箭头通常表示推式产品控制策略，而弯箭头表示拉式策略。弯曲箭头表示电子信息流。

您可以在以下截图中看到最常见的价值流图图标：

图 7.1 – 常见的价值流图符号

请注意，图 7.1 中显示的常见价值流图符号包含了本书中使用的 41 个标准精益图标。图形显示了跨越之前确定的七个 VSM 图标类别的符号。

每个 VSM 工具提供商都会提供一个带有自己图标集的价值流图工具。尽管大多数现代 VSM 工具都具有价值流图绘制功能，但许多图形工具提供了易于使用的图形用户界面（GUI）工具，配有预定义的图标来绘制价值流，且通常价格要低得多。

VSM 团队可以使用标准的价值流图符号绘制目标价值流中的工作和信息流。然而，在绘制图之前，还有一步是收集数据，以了解价值流活动中的工作和信息流。

创建准确的价值流图所需的理解并不是通过阅读规格和文档就能获得的。相反，他们必须走进车间，与做实际工作的人员会面，提出大量问题，并亲自观察工作和信息是如何在价值流中流动的。

进行现场观察（Gemba）

当前的价值流图绘制活动的主要目标是识别增值活动，同时消除那些造成浪费（Muda）的活动。因此，在开始当前状态图绘制活动之前，我们的 VSM 团队必须先去现场（Gemba），了解价值流的运作方式，然后再进行绘制和提出改进建议。

有些书籍让人觉得 Gemba 观察只是一个简单的一次性活动。这是很遗憾的，因为一次价值流观察并不能完成任务。例如，作为德州仪器（Texas Instruments）的一名年轻制造与工业工程项目经理，我在车间的时间远远超过了我在办公桌前的时间。我的工作涉及规划和指导三项大型工厂改进项目，涵盖两个地理位置分隔的制造工厂。我所需的生产信息并不在办公桌上，而是在车间，并且主要在执行工作的人的脑海中。

Gemba 和当前状态绘制活动提供了对阻碍物料和信息流动的浪费区域的洞察。另一种理解浪费的方式是，它几乎总是会导致额外的行政开销和处理时间。我们的重点始终应该放在客户身上，而这类行政任务大多是开销和非增值的。

在进行 Gemba 活动时，有三条基本规则，如下所示：

• 亲自去看发生了什么。

• 多问为什么，以找到问题的根本原因（即5 个 W或5 个为什么）。

• 尊重他人：你的工作是帮助解决问题，而不是寻找过错。

当 VSM 团队成员进行 Gemba 观察时，需要有条理地进行。以下步骤概述了一个合理的 Gemba 观察策略：

1. 确定目标和任务。

2. 让价值流团队知道你即将到访及访问的原因。

3. 以两人或更多 VSM 团队成员一起行动。

4. 跟随价值流的流动。

5. 聚焦于识别价值流过程和工作活动中的问题，而不是指责人。

6. 记录调查结果。

7. 提问——即通过五个 W（谁、什么、何时、哪里、为什么）或“为什么”五次来充分理解问题并找出根本原因。

8. 听取意见——不要在最初的走访中建议变更。你的目标是学习。

9. 后续跟进与价值流员工，分享你的观察和建议。

10. 再次前往 Gemba 确认实施和改进的结果。

11. 再次前往 Gemba 启动新的 Kaizen 改进周期。

一个同步且有序的价值流，从流动的角度来看，几乎是自动化的。在一个组织良好的价值流中，工作流的流动有自然且直线的顺序。信息和物料流动没有障碍或瓶颈。所需的正确信息和物料会在需要时立刻到位，而不会提前或滞后。这就是理想的未来状态。利用你的 Gemba 走访来识别当前状态下这些事情没有发生的区域和原因。

最后，VSM 团队必须了解收集准确的实时信息的重要性，包括实际工作活动、信息流和物料流，无论现有的活动是增值（VA）还是充满浪费。如果未能记录所有不同步的流动和浪费，就无法将价值流评估为一个整体系统。此外，缺乏从系统角度看待价值流的全貌，也就无法理解影响其表现的动态。

以客户为中心开始我们的流程图

从最终客户交付开始进行当前状态绘制，向上游（回溯）绘制各个流程。记住——目标是交付客户所需的产品、服务或结果。如果不在进行当前状态评估时考虑客户的需求和预期结果，VSM 团队可能会错过那些初期或中期活动对价值交付产生负面影响的部分。

下图直观地展示了价值如何流向客户：

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/drv-dop-val-st-mgt/img/B17087_Figure_7.2.jpg)

图 7.2 – 价值流图从客户开始

在传统的流程模型中，我们通常从第一个活动开始，逐步绘制跨活动和工作地点的工作流。在价值流图绘制中，我们从客户接收价值的起点开始收集数据，然后向上游回溯。每一步，我们都要问自己，当前的活动是否与客户需求对齐，或者是否在某种形式上增加了浪费。

分析的顺序并不意味着我们打算按照这个顺序解决浪费问题。相反，VSM 团队必须根据最大价值影响来优先改进。我们将在第九章，绘制未来状态（VSM 步骤 6）中详细讨论这个话题，但现在，了解我们通过价值流逆向绘制的原因是非常重要的，原因包括以下几点：

• 它将焦点保持在客户的需求上。

• 它帮助我们将思维导向基于拉动的流程。

• 在生产环境中，处理多条装配分支的复杂流程时，我们可以更好地应对挑战。

后续问题，管理多个分支，增加了管理流程的复杂性。在推式生产调度系统中，几乎不可能让物料流在需要时可用，从而避免排队等待。然而，正如你将在第九章，绘制未来状态（VSM 步骤 6）中发现的那样，使用拉动式生产调度和准时生产（JIT）物料与信息交付系统，可以更容易避免瓶颈。

在这里，你可以看到一个包含多个分支的价值流图：

图 7.3 – 多分支的价值流图

现在我们已经明白，我们需要以客户为中心来开始 VSM 图绘制，让我们来了解一下在进行当前状态绘制时需要做的准备工作。

准备绘制

你已经学会了收集当前状态图所需信息的 Gemba 基本步骤，但让我们更详细地看看在进行当前状态绘制之前所需的准备工作。VSM 团队在绘制前通常需要执行四个常见步骤，如下所述：

• 确定 VSM 团队成员分工

• 绘制价值流的粗略草图

• 开始你的 Gemba 练习

• 讨论数据

VSM 团队需要为每个成员分配具体角色，以简化他们在任何当前状态绘制练习中的数据收集和绘制工作。虽然 VSM 团队可以使用电子工具或翻转图表来绘制图，但最好从一个可擦写的白板开始。你将在整个练习过程中定期更新它，并且一个更大的白板更便于每个人查看和参与讨论。最好还指定一个人负责记录，或者更好的是，在团队成员之间轮换这个角色。

需要另一个人负责促进映射活动，确保团队专注于当前目标并监控时间。如果团队保持日程安排并有时间休息，他们会更容易集中精力完成工作——如果需要，可以稍后安排更多时间回去完成工作。甚至可以允许在更新映射之间留出时间，让团队休息并反思已完成的工作，审查地图以识别可能遗漏的信息。

我们还需要一个人在 Gemba 走访期间充当计时员。他们的职责是记录在 Gemba 走访过程中观察到的价值流活动的周期时间和换班时间。他们还应记录在走访中发现的其他重要信息，例如问题、原因、影响、延迟或其他浪费领域。

让我们停下来讨论创意工作与标准化工作之间的区别。开发者进行软件架构和设计、编写代码的工作是创意性工作。没有两个业务需求是完全相同的，开发者必须思考所涉及的工作，并设计合适的解决方案。相比之下，标准化工作包括在受控环境中不应有显著变化的重复性任务。

标准化工作是精益的核心，消除浪费，从而提高结果的可预测性。不幸的是，在敏捷实践中，标准化工作往往不受欢迎，因为许多敏捷从业者不希望被束缚于特定的工作方式。然而，当组织试图在持续集成/持续交付（CI/CD）和 DevOps 流水线，或任何其他精益价值流中构建和维护持续流动时，没有标准化的方法和工具会带来额外的风险。

例如，假设我们已经花费了时间、精力和资金来设计精简的价值流，包括工具的采购。在这种情况下，我们不应随意进行更改，而应彻底评估我们的需求和目标，并评估更改活动和流程可能带来的负面后果。价值流图（VSM）是评估我们精益企业持续改进的适当方法。

无论是使用敏捷（Agile）还是精益（Lean）理念，我们仍然希望保持与我们节拍时间（takt time）相匹配的生产流程。换句话说，理想情况下，我们的生产速率（Takt）应与客户的需求速率相匹配。唯一具有挑战性的地方是在软件开发生命周期（SDLC）的前端，在那里产品负责人和团队会识别、优先排序并细化需求。接下来，软件团队必须评估涉及的工作量，以设计和实施这些需求作为软件功能和特性。最后，产品待办事项的精炼具有创意性质，这使得预测工作范围和持续时间变得更加困难。

一旦工作项进入开发周期并作为精炼任务执行，工作的流动可以遵循一套标准的、具有时间限制的活动，这些活动是合理标准化且可预测的。然而，强行对产品待办事项的精炼创意工作施加任意的时间限制要困难得多。相反，改善设计相关工作的可预测性的最佳策略是将初步的高层需求细分成尽可能小的部分。

基于微服务的架构在最小的规模层面上分解需求，以描述最细粒度的独特业务服务。除了更好的设计可预测性，基于微服务的架构的其他好处包括能够创建高度可维护、可测试和可独立部署的功能单元，作为松散耦合的业务服务。

在 Gemba 走访之前绘制当前状态图的目标是确保 VSM 团队成员理解价值流中的工作。因此，让熟悉价值流的人来引导这一工作可能会很有帮助。

粗略的地图有助于在 Gemba 走访之前改善 VSM 团队对价值流活动的理解，从而使他们在走访中的时间更加高效。此外，草图有助于团队后来识别价值流中与他们对流程应如何运作的原始预期不符的区域。

当团队开始进行 Gemba 走访时，应准备好捕捉以下信息：

• 每班次或每日的总工作时间

• 价值流中的计划停机时间和休息时间

• 实际执行工作的可用时间

• 支持价值流的员工和承包商或合作伙伴的数量

• 每个价值流工人的工作量

• 价值流中每项活动的交付频率

• 每项活动的周期时间，从开始到完成

• 每个价值流活动的等待（排队）时间和数量

• 标准流程的任何例外情况

• 价值流中其他相关的独特信息项

在开始 Gemba 走访之前，团队应尊重价值流工人的时间和努力。出于礼貌，VSM 团队成员需要寻求价值流经理的批准，并根据 VA 经理和员工的日程安排规划走访，以最小化对其工作的影响。

花时间沟通你计划在哪里进行走访以及你希望达成的目标。然后，当你参与 Gemba 走访时，确保你和你的团队成员自我介绍，并提醒团队你此次访问的目的。诚实回答他们的问题，并且不要回避解释精益生产实践的目标和益处。

请记住，您需要获得他们的支持。在您走访时，请尊重工作人员的时间和工作区域。最重要的是，要记住他们是价值流中执行工作的专家。

VSM 团队现在可以开始他们的 Gemba 走访。VSM 团队成员不应在收集到数据之前进行分析。这只会浪费宝贵的时间并妨碍价值流工作人员的工作目标。走访结束后，将有充足的时间反思和分析数据。

既然我们已经进行了 Gemba 走访并收集了数据，现在是时候开始我们的当前状态映射练习了。

开始绘制地图

到目前为止，您已经完成了以下步骤，为当前状态映射练习做好准备：

• 确定客户需求和优先事项

• 制定价值流映射计划

• 分配角色和责任

• 进行信息收集的 Gemba 走访

• 开发当前状态图的粗略预草图

现在是时候使用这些信息来创建我们的当前状态价值流图了。再次建议使用大白板或海报板进行此操作，并根据需要使用可擦除的标记笔或铅笔，以便您可以纠正任何错误或遗漏。再次提醒，您可以使用软件工具来创建您的图表，但请确保有足够大的屏幕供所有人围绕并查看。

尽管数字化的 VSM 映射工具能制作出更好看且更易读的图纸，但它们也可能会使映射过程变慢，尽管有些工具比其他工具更容易使用。在团队准备好展示和分发工作成果之前，手工绘图可能更为合理。团队需要凭借自己的判断来决定哪种方法最适合他们。

按八个步骤绘制当前状态图

绘制价值流图并没有单一的最佳方法。然而，最好有一个共同的策略来指导整个过程，确保没有遗漏。秉持这一目标，以下八个步骤按此顺序应用，提供了一种务实的当前状态映射方法。

1. 绘制客户和供应商：识别提供需求并接收交付成果的外部或内部客户。请注意，在图 7.3中，地图从客户的角度识别了产品待办事项。此外，注意到图 7.3中客户图标出现了两次，这是不必要的。在这种情况下，使用图标两次——一次表示需求，另一次表示交付——表明产品待办事项包含了所有客户需求，而交付成果则送给特定客户。最后，识别任何提供材料、产品或零部件的供应商、承包商或合作伙伴，他们为价值流提供贡献。

2. 绘制进出活动：在以 IT 开发为导向的价值流中，进入点可能是待办事项精炼或 Sprint 目标的确定。相反，退出点可能是部署活动。由于活动代表着工作，因此一种好的做法是使用动词和动词短语来命名活动。此外，由于我们活动的预期输出是有形的——以产品、服务或结果的形式——一种好的做法是使用名词和名词短语来命名输出。

3. 绘制进出口过程之间的所有活动：虽然你最初是从客户的角度反向收集数据，但你可以从最远端（即从左到右）开始绘制活动。这种方法使得以图形方式描述工作流程更为简便。确保使用带有分段字段的活动框来记录必要的数据，例如周期和转换时间、等待时间、资源、批次或批量大小、缺陷及其他重要细节。

4. 列出所有活动属性：这些包括交货时间、周期、转换时间、等待时间、资源、批次或批量大小、缺陷以及其他必要的细节。

5. 绘制活动之间的队列和等待时间：使用不同的图标来表示队列的类型，例如等待材料、安全库存、缓冲库存和预期库存。等待材料是由于生产速率不匹配而在工作单元之间形成的队列。安全库存是为确保在材料短缺时可以继续工作而储备的材料。缓冲库存有助于抵御客户引起的需求波动或激增。最后，预期库存包括为应对预计的需求激增（如节假日需求）而存放的成品。

6. 绘制价值流内的所有通信：使用不同的箭头类型来指示通信是口头的、邮件的还是电子信息流。

7. 绘制推式或拉式图标以识别工作流类型：使用直箭头表示推式流动。使用圆形箭头表示拉式流动。使用不同的箭头类型来表示外部材料和产品的运输与价值流内部的材料和产品流动。

8. 记录所有其他收集的数据：使用附录 B 中的价值流故事板来说明你可能需要收集的信息类型——即地图日期、价值流名称、VSM 主导者、团队成员、问题类别以及其他与活动和流程相关的重要信息。

可能会很想快速完成当前状态图的绘制，但不要急于求成。团队可能会犯错或遗漏，后来可能会影响团队的可信度以及他们未来状态图和建议的准确性。

同时，不要轻易将你当前状态价值流图中的现有信息应用到标准化实践中，比如车间流程或指南。这些来源通常代表理想化的方法和预期的指标，但可能无法反映实际的做法。再一次，这也是为什么我们使用 Gemba 亲自去现场观察的原因。

创建 IT 价值流图

VSM 已成为在 IT 相关价值流中实施和改进精益实践的关键能力。通常，采用 VSM 方法和工具的组织可能已经建立了敏捷实践，并可能实施了 CI/CD 工具链。但现在，他们的目标是实施 CI/CD 实践，将其转化为精益管道。VSM 团队的主要目标是改善协作，并在面向开发的价值流中同步信息和工作流程。

这些活动中的任何一个都不能保证 IT 部门已从以客户为中心的精益视角出发，致力于消除浪费。然而，VSM 帮助我们做到这一点。此外，在此次映射过程中，假设执行管理层与 VSM 团队合作，已选择一个软件开发项目作为其目标价值流进行改进。

更准确地说，在本书中使用标准化八步 VSM 方法的示例中，我们假设组织有一个或多个使用敏捷实践的软件开发团队，并购买了工具链来实现 CI/CD 能力。我们并没有假设组织会利用购买的工具集成或自动化 SDLC 过程。

此外，我们的公司高管已批准甚至强制执行 DevOps 实践，但可能并未完全理解执行如此重大的价值交付转型所涉及的问题。该问题的解决超出了本 CI/CD 用例的范围，但我们在本书的 第三部分 中讨论了这个问题，安装 DevOps 管道以在数字经济中竞争。

在开始工作之前，VSM 团队成员必须接受所有精益实践的培训——假设这是他们的第一次 VSM 项目。接受精益培训后，团队会再次召开会议，为接下来的当前状态映射工作做准备。作为准备工作的一部分，他们分配角色和责任，并初步勾画出他们预期看到的 IT 开发流程。最后，他们进行 Gemba 走访，收集所需数据。

在这一阶段，VSM 团队讨论他们已收集的数据，并构建当前状态图。在映射过程中，团队会通过几次会议讨论数据，并构建当前状态图。他们可能还进行了额外的 Gemba 走访，以收集更多数据，并验证之前收集的数据，后者可能看起来不完整或不准确。

记录我们的 Gemba 走访发现

在我们开始绘制当前状态图之前，我们需要收集足够的信息来绘制我们的地图。以我们的示例为例，VSM 团队必须记录以下活动，涵盖从程序 IT 价值流的开始到结束：

• 计划：任务包括用户故事的细化、更新待办事项优先级、进行架构和设计审查、分配团队任务以及更新发布计划。

• 编码：任务包括开发测试、编写软件代码和配置、将源代码提交到版本控制下的源代码仓库、进行静态代码分析以及进行自动化和同行代码审查。

• 构建：任务包括编译代码、进行单元测试、检查代码度量（大小、复杂性、耦合度、内聚性和继承性）、构建代码容器或包、准备或更新部署配置以及监控仪表板。然而，VSM 团队注意到，构建过程会因所使用的编程语言和工具不同而有所不同。

• 测试：任务包括——但不限于——冒烟测试/构建验证、回归测试、性能测试、负载测试、压力测试、用户界面（UI）、端到端（E2E）测试和系统测试，并且根据需要，可能还会有其他特定的测试。

  测试可以手动执行，或者更好地通过运行自动化测试脚本来配置服务器并启动测试。理想情况下，多个测试会在不同的测试服务器或容器上并行运行。但这属于未来状态的考虑。相反，VSM 团队需要了解 IT 组织如何设置其测试环境，所需测试类型，以及开发团队如何执行当前状态图中的测试活动。

• 合并：任务包括在源代码管理（SCM）仓库中创建分支、推送、拉取和合并代码。

• 配置：任务包括设置或更新基础设施配置，以适当的方式包括开发/工程、质量保证（QA）/测试、暂存和生产环境。

  当 VSM 团队进行 Gemba 走访时，他们注意到开发团队会在所有新的测试实例上重新执行冒烟测试，包括暂存和生产环境。他们的目标是验证最新的软件安装是否稳定，并符合所有验收标准。

• 部署：作为正式发布过程的一部分，任务包括准备发布说明，冻结代码、配置和功能的决策，以及开发系统管理员（sysadmin）、用户和流程指南及培训材料（如有必要）。

• 操作：任务包括通过仪表盘和错误日志监控性能和安全性。监控工具通常包括在网络、服务器或应用程序在预设的性能和安全度量标准下变得不稳定、失败或故障时触发警报的功能。安全信息与事件管理（SIEM）是操作监控的另一个关键组成部分。

在他们的 Gemba 走访过程中，VSM 团队还注意到运营部门已实施基于信息技术基础设施库（ITIL）的IT 运营管理（ITOM）和IT 服务管理（ITSM）实践。然而，在初步的 VSM 工作中，团队选择专注于记录开发团队的 IT 价值流工作和信息流，以改进他们的 CI/CD 管道流。

VSM 团队计划稍后处理面向操作团队的工作和信息流。目前的问题是开发和运营团队未能作为一个集成的 IT 价值流共同运作。尽管 DevOps 能力的实施作为战略是组织高层管理团队的既定目标，但 VSM 团队决定价值流改进工作超出了他们批准的范围，并需要单独的任务授权。

在 VSM 团队观察这些活动时，他们会监控并记录活动的前置时间、增值时间（VA 时间）、故障平均间隔时间（MTBF）和恢复平均时间（MTTR）以及每个价值流阶段中，完成并准确的与活动相关的工作百分比。此外，VSM 团队还观察了整个价值流中的工作和信息流，并记录了 IT 组织标准软件交付流程中的例外情况。

绘制 IT 当前状态价值流图

对于本节内容，请参阅图 7.4，展示了 VSM 团队当前状态的 IT 价值流图的最终图示。

请注意，图 7.4中的 IT 价值流图包括监控活动，这本质上是一个 IT 运营导向的任务。VSM 团队选择将监控活动展示为信息源和产品待办事项的积压项。产品待办事项作为一项活动展示，用于记录精炼过程，但你也可以展示一个客户待办项的库存或等待队列。

图 7.4中展示的当前状态图似乎相对详细且复杂；然而，它并不那么详细。提供的信息相对高层，VSM 团队需要付出更多的努力，以进一步细化这些活动。

例如，Karen Martin 和 Mike Osterling 在他们的书《价值流图》中，描述了基于 Scrum 的 IT 开发组织中的变更请求（CR）过程，这是整个 IT 价值流中的一个小子集。他们的 CR 过程当前状态图包括十个不同的活动和六个信息系统，用来管理工作和信息流（Martin, Osterling; 第 181-186 页，2014 年）。

花点时间回顾一下图 7.4，包括 VSM 收集的度量指标。LT（代表前置时间）是一个度量，汇总了价值流中每个活动的周期时间和等待时间。相反，VA是指开发人员在活动中执行的工作时间，提升了每个活动中工作项的价值。最后，%C/A（即完成且准确的百分比）是一个度量，表示通过该活动的工作项百分比，这些工作项无需返回进行某种返工：

图 7.4 – DevOps 价值流图

这些是任何类型精益改进计划中监控的标准精益度量指标，但还有许多其他指标。以下部分将我们引导至 VSM 方法中精益改进的第 5 步——识别精益度量指标，但在进入该部分之前，让我们先花点时间回顾一下我们在绘制当前状态图时使用的工具。

当前状态绘制——工具

本节总结了在当前状态绘制过程中使用的工具，其中大部分工具我们已经在本章中提到过——例如，用于当前状态绘制的工具包括图 7.1中识别的价值流图符号。你还需要一个大幅海报板或白板，确保每个人都能看到信息并参与绘制过程。正如附录 B所示，价值流故事板是另一种重要工具，用于记录价值流数据和当前的价值流图。白板最适合团队合作，但价值流故事板则提供了 VSM 绘制活动和分析的永久记录。

在前往价值流工作区进行 Gemba 走访之前，你的团队应该制定一个活动清单和关键指标（即属性），并记录下来。然后，你的团队将指标直接记录在价值流图上。一种好的策略是列出活动和相关属性的项目清单，以便记录在 Gemba 走访中发现的信息。

当你和你的 VSM 团队成员从 Gemba 走访回来后，你可以开始绘制当前状态图。

本节介绍了另一种八步绘图过程，作为绘制价值流图并记录关键属性和活动信息的工具，完成了我们关于执行当前状态价值流绘制练习的讨论，这是我们 VSM 方法论中的第四步。

总结

在本章中，你学会了如何创建一个价值流的当前状态图，以便从精益生产概念的角度评估工作和信息流。你还学会了价值流图与其他过程建模概念（如 UML、IDEF3 和 BPEL）之间的区别。

作为绘图练习的一部分，你学会了如何使用一套标准的精益符号作为图标。这种策略旨在简化你的价值流图，同时确保其他人能够理解图表所表示的内容。

也许最关键的一点是获取有效的信息，这与构建图表无关。在本章中，你学会了如何通过 Gemba 走访亲自观察工作现场的情况。此外，你还学到，执行工作的操作员是关于如何执行工作以及如何改善工作和信息流的最佳信息来源。

在下一章中，你将学习使用度量来分析价值流的表现，既包括当前状态，也包括理想的未来状态。

问题

1. 为什么不建议直接开始绘制价值流的理想未来状态？

2. 价值流图与过程建模技术有何不同？

3. 为什么在改进工作和信息流之前，我们不应该自动化一个业务流程？

4. 一旦 VSM 团队、价值流操作员和其他关键利益相关者学习了精益流程，是否还需要在执行他们的 VSM 计划之前做些什么？

5. 为什么要为价值流图绘制提供一套标准的符号和图标？

6. 作为价值流图绘制的一部分，进行 Gemba 走访的总体目的是什么？

7. 在实践 Gemba 时，有哪些三条基本规则？

8. 绘制当前状态图时，从哪个方向开始？为什么？

9. VSM 团队如何实施精益改进到价值流中，顺序如何？

10. 绘制当前状态图的八个步骤是什么？

进一步阅读

• Gery, G. (1991) 《电子性能支持系统：如何通过战略性使用技术重塑工作场所》。ISBN 978-0-9617968-1-5。Weingarten 出版公司，波士顿，MA。

• Tapping, D., Luyster, T., Shuker, T. (2002) 《价值流管理：规划、绘制和维持精益改进的八个步骤》。生产力出版社。纽约，NY。

• Tapping, D., Luyster, T., Shuker, T. (2003) 《精益办公室的价值流管理：规划、绘制和维持精益改进的八个步骤》。生产力出版社。纽约，NY。

• Tapping, D., Kozlowski, S., Archbold, L., Sperl, T. (2009) 《精益医疗中的价值流管理：在所有类型的医疗环境中进行规划、绘制、实施和控制改进的四个步骤》。MCS 媒体公司，切尔西，MI。

• Martin, K., Osterling, M. (2014). 《价值流图》：如何可视化工作并将领导力与组织转型对齐。麦格劳-希尔教育图书。纽约，NY。

第八章：识别精益度量（VSM 第 5 步）

完成当前价值流图后，我们现在将注意力转向评估潜在的未来状态机会，以同步我们的流程并消除浪费，从而为客户创造更多价值。但首先，我们必须以量化和可度量的精益度量为形式，明确我们的目标。这将是 VSM 的第五步，并将在本章中介绍。

如果没有衡量当前状态和期望未来状态的指标，改进就变得困难。这就像是开车前往一个新目的地，却没有地址或地图。没有这些信息，你就不知道该走哪条路，得走多远，甚至不知道何时到达。 本章帮助你识别关键的度量指标，这些指标将为你构建价值流图、定义期望的未来目标提供决策支持。

阅读完本章后，你将了解帮助组织和 VSM 团队评估几乎所有价值流中的改进领域的基本精益度量。你还将学习最适用于评估现代 DevOps 基础的软件交付团队和管道绩效的度量。最后，你将了解支持收集精益度量的工具。

在本章中，我们将讨论以下主要内容：

• 定义通用精益度量

• 评估精益绩效

• 衡量关键软件交付度量

• 将流程度量和分析添加到 VSM 中

• 实施精益度量工具

定义通用精益度量

在前一章节关于当前状态价值流图的讨论中，我们已经介绍了一些精益度量。然而，我们没有花时间定义与软件交付性能明确相关之外的精益度量。此外，还有许多传统的精益度量，你和你的 VSM 团队需要了解如何使用，以下是一些列出的度量：

• 周期时间（CT）：CT 是指从开始到完成一个过程或价值流活动的时间跨度。CT 实际上是产出的衡量指标（每单位时间的产出）。因此，如果我们可以在 40 小时的工作周内生产 40 个小部件，那么我们的周期时间就是。VSM 团队仅包括工作时间，不包括在制品（WIP）或价值流活动之间的等待时间。然而，CT 并不总是完全等于增值时间（VT）。在活动中可能存在一些非增值工作的元素，通常表现为浪费。这些浪费包括缺陷、库存、运动、过度加工、过度生产、运输和等待。

  举个例子，假设一个操作员拉取了一个工作项，但必须等待检索信息、材料或审阅信息才能开始工作。在这种情况下，这种等待仍然是该活动的 CT 的一部分。此外，用于设备设置或更换材料的时间也是 CT 的一部分。

  举个现实生活中的例子，最近我在后院做了一些景观工作。材料供应商将物品送到我的车道上，堆放在托盘上。我不得不支付景观承包商团队的人工费，用来拆开托盘并手动将材料搬到后院。作为一名付费客户，我更希望托盘能直接送到后院。因此，我支付的 CT 费用包括了增值的景观工作，也包括了搬运材料这一非增值的工作，这就是精益生产中以“动作”为形式的浪费。

• 库存天数：这是以每日生产使用量为单位储存和量化的物料、零件或产品的数量。例如，如果我们每天使用 20 个小部件，且库存有 100 个小部件，那么我们就有 5 天的库存。

• 每百万机会缺陷数（DPMO）：这是衡量每百万次发生缺陷的机会中有多少次出现缺陷的指标。例如，我们可能在每百万次活动中有 40 次缺陷。或者，在每百万行生产的代码中，可能有 40 个缺陷。因此，我们需要简明地解释 DPMO 所测量的缺陷比率类型。

  我们的质量目标始终是努力消除所有缺陷及其原因，防止错误或故障的发生。我们希望在任何高度重复和连续的流程中，监控并记录缺陷，借助控制图的最小值和最大值来看我们的流程何时开始出现问题。随着我们的指标接近上限或下限，我们仍然有时间在问题变得灾难性之前进行纠正。

  例如，精益生产从业者常常在精益生产过程中使用六西格玛计算方法，作为期望的质量目标。六西格玛质量目标是每百万机会中出现 3.4 次缺陷的衡量标准。

• 停机时间：这是与正常运行时间相反的概念。停机时间是一个比率，衡量设备无法在总时间内执行工作的计划外时间占比。

• 一次通过能力（也叫一次通过合格率，或FTT）：这是衡量生产过程中没有缺陷、错误或需要返工的产品比例的指标，通常以价值流中生产的总单元百分比表示。80%的 FTT 意味着每生产 100 个产品中有 80 个没有缺陷，不需要返工。

• 库存或工作项周转：指在特定期间内，物料、零件或产品的使用或销售次数。这个指标至关重要，因为更频繁的周转与更好的流动性、更高的回报和减少的库存持有成本相关。

• 交付时间 (LT)：这是从接到订单到订单达到内部或外部客户的整个周期时间和等待时间的总和。在这个上下文中，LT 通常适用于整个价值流、业务流程，甚至适用于价值流中一个或多个活动之间。无论如何，LT 包括测量的工作跨度内等待时间和周期时间的总和。

• 故障间隔时间 (MTBF)：这是衡量活动或过程失败频率的时间度量，通常以小时为单位。例如，MTBF 为 89 意味着我们可以预期该活动或设备每 89 小时会发生一次故障。

  当然，事情永远不可能完美无缺。我们还应该测量偏差和概率分布，以更好地了解我们的故障频率。我们还需要查看故障的原因，看看如何减少或消除它们。

  VSM 团队应评估价值流设备、软件发布、以及由于安全漏洞、网络或计算机系统故障导致的停机时间的 MTBF 指标。

• 修复/恢复时间中位数 (MTTR)：这是从发现问题或故障到我们拥有有效的解决方案，能够继续工作的时间度量。MTTR 值通常适用于我们价值流的设备，但也适用于我们软件产品的可用性以及 IT 基础设施和安全性。

• 准时交付：这是衡量我们如何满足客户需求的指标，以按时、完整且无错误或遗漏地交付给客户的所有订单的成品或服务的百分比表示。

• 总体设备效率 (OEE)：这是精益价值流中工业机械或设备有效性的百分比的可量化表达，包括质量、速度和可用性度量。具体而言，OEE 通过将质量、速度和可用性等指标的百分比相乘来计算设备效率，正如我们在这里所看到的：

举个例子，OEE 为 100%意味着操作能够在 100%的最佳生产速率下生产符合质量标准的零件，并且 100%的时间没有中断。但是请注意，如果质量、速度和可用性都下降到 90%，会发生什么情况。在这种情况下，OEE 降至 72.9%（即 OEE 为 0.729）。

换句话说，即使所有因素的效率达到 90%，所测量的价值流活动或设备的效率仍然下降到总体生产效率的 73%。

• 排队（等待）时间：这是物料、零件、产品或信息在下游过程中等待的时间。当不同的批次大小和周期时间在价值流活动中不匹配时，无论是在推式还是拉式生产控制系统中，都会发生等待。

  推拉导向的生产过程有助于减少等待和库存，只要操作人员在限制缓冲区大小和在准备好执行工作时拉入新工作方面有纪律性。发生的任何等待时间都表现为活动之间的延迟，直到上游活动的工作项被拉入下一个下游活动。

  使用推动导向的生产调度过程，您可以预期等待时间和队列时间显著增加。在价值流程中，如果循环时间和批量大小不匹配，那么减少库存和等待时间将变得更加困难。在相同工作单元或设备上具有不同流程的产品线进一步加剧了这些问题，因为预测哪些工作项将出现在哪些工作站上以及何时出现变得极为困难。

• 可报告的健康和安全事件：在美国，职业安全与健康管理局（OSHA）实施健康和安全法规。但我们关注的不仅仅是法律，因为任何安全问题都代表着对实体的生产力、财务和法律责任。如果事件严重到需要报告，那么我们应该对其进行测量并采取措施，以减少甚至消除其原因。

• 整个价值流程的工作在制品：在精益生产中，理想状态是让一个工作项在我们的价值流程中流动，即所谓的单件流。如果我们的价值流程中有 10 个不同的活动，我们的偏好是在 WIP 总数不超过 10 个工作项。这个目标在短期内可能不可实现，但我们的目标是监控、控制和限制整个价值流程中的 WIP。

• 总循环时间 (TCT)：这是价值流程中所有活动的循环时间总和。与特定活动的循环时间一样，我们不包括工作项在活动之间等待的时间，但我们包括与非增值工作相关的时间。

• 总流程时间 (TLT)：这是价值流程中所有循环时间和队列时间的总和。这个指标让您了解从接收客户订单到交付所需的时间。TLT 可以针对内部或外部客户在价值流程中进行测量。

  请注意，TLT 值可能还包括参与交付的多个开发和操作导向价值流程中的 LT。无论如何，清晰地指出价值流程和与指定 TLT 度量相关的活动的范围至关重要。

• 正常运行时间：这是可用性的表达，计算方法是设备在所需时间内可用进行工作的总时间与所需时间的比率。注意，计算可用时间时不包括计划的停机时间（也称为非生产性活动），例如预防性维护、设备设置或工作项目的变更。无论计划的工作是否增值或非生产性，都不关心，关键是设备是否可用。

• 增值时间 (VT)：这是一个价值流活动或过程的 CT，减去所有浪费时间。理想的目标是使活动的 CT 完全等于 VT 的 100%。(这意味着设计一个没有缺陷、库存、移动、过度加工、过度生产、运输和等待的活动。）不幸的是，我们很少能实现这个理想目标，但我们会不断努力消除所有形式的浪费。

前面列出的标准精益指标对于任何精益改进计划来说都适用，无论是哪种类型的价值流。然而，有四个关键指标往往能最好地预测 IT 组织的软件交付价值流的表现。我们将在衡量软件交付表现一节中讨论这一点。但在进入该主题之前，让我们回顾一下 VSM 团队在评估和收集精益指标时需要注意的事项。

收集精益指标

当你的 VSM 团队审查哪些精益指标最能支持当前的价值流映射工作时，请牢记以下几点：

• 回顾你团队的章程，明确战略方向和期望的结果。

• 从消除浪费和提供以客户为中心的价值的角度评估价值流。

• 确定你需要收集哪些精益指标。

• 为你团队选择的指标争取管理层的支持。

• 基于标准化流程或活动数据计算最佳可能结果。

• 使你的指标对所有团队成员、操作员和利益相关者可见且易于获取。

现在，您已经了解了评估所有价值流所需的标准指标和收集它们的策略，我们来看看哪些指标在评估 IT 价值流的表现上最为有效。

分析当前价值流图的指标

回到我们当前状态的价值流图，在第七章**，当前状态映射（VSM 步骤 4）中，图 7.4 中展示了 LT、VT、完成和准确百分比以及滚动完成和准确指标。现在，让我们开始使用这些信息来分析价值流的表现。

下表显示了总交付时间 (TLT)、总增值时间 (TVA)以及整个价值流的滚动完成和准确百分比：

图 8.1 – TLT、TVA 和滚动完成/准确的表格

该表格分为三行数据，分别表示跨 IT 价值流三个部分的 TLT、TVA 和滚动 C/A 值。表格中第一个部分的数据显示了产品待办事项的精炼和设计工作项活动。第二列数据覆盖了从规划到资源提供的所有开发活动。第三列数据包括与将产品发布到生产环境相关的活动。

现在，让我们更仔细地看看 IT 价值流交付活动中的细节。图 8.2 总结了由 VSM 团队收集的精益指标和信息，涵盖了整个 IT 价值流中的所有活动，涉及软件交付。数据和信息被分别划分为与工作相关的类别，涵盖待办事项精炼、开发和发布，如下图所示：

图 8.2 – 跨 IT 价值流的精益指标表

有可能一些发布任务，例如开发指南和培训辅助工具，可以并行执行。但 IT 价值流还将功能整合到计划的双周发布中，这也是 80 小时周期时间的原因。实际上，发布过程是 IT 开发与运维人员之间的过渡或集成点。它涉及 IT 组织双方的人员，但工作更偏向运维，并据此进行了划分。

请注意，从规划到发布的总周期时间（TLT）为 328 小时，或稍超过 8 周的时间，从需求进入产品待办事项直到作为功能或特性发布到生产环境。然而，增值工作时间总计只有 57 小时（约 1.5 周）。虽然我们还不知道原因，但在我们的 IT 价值交付系统中，内建的等待时间太长了。

工作项的大部分非增值时间积累在产品待办事项中，总计为 168 小时。这是项目根据优先级排队等待的地方。回想之前提到的，精炼和设计过程由于工作内容的创造性方面，通常难以估算和控制。这可能解释了一些延误的原因。然而，产品精炼和设计活动的总周期时间与增值时间之间的巨大差距表明，我们在下游的开发和发布活动中可能存在吞吐量问题。

然而，IT 价值流中开发和发布阶段的工作项周期时间分别各自增加了 80 小时，或者接近一个月，导致整体产品周期时间增加。所以，我们在这些活动中也有很多内建的等待时间。根据这些数据，似乎我们可能有一些内建的限制因素，阻碍了开发和发布中的流动。或许我们面临设备和资源的限制，以及审批流程，这些都影响了我们的流动性。

我们现在离开当前价值流图指标分析的主题，进一步关注构成 CT 指标的时间要素。

细分 CTs

在整个 IT 交付价值流的 VA 时间中，我们可以看到精炼活动占据了最大比例，其次是发布活动，最后是测试活动。这三个领域是我们需要改进的地方，以减少成本并提高流动性。

当我们开始更加仔细地查看 VA 时间时，我们将探讨一些导致浪费的非增值活动，例如以下几点：

• 等待所花费的时间：这包括材料或工作项在队列中等待处理的时间。等待可能由多种原因引起。其中一个突出的等待原因是当生产控制将更多的产品推送到价值流或某个价值流活动中，而它的处理能力不足时。另一个等待时间的原因是多个活动的输出速度超过了单一活动的处理能力。此外，当某个价值流活动的速度慢于上游活动时，也会发生等待。

• 走动所花费的时间：这是一种精益浪费，称为运动。运动是非增值的时间和精力。目标是尽可能消除运动。实现这一目标的方式包括将工作活动靠得更近，可能还需要重新配置工作单元在价值流位置内的布局。

• 输入数据所花费的时间：这虽然是非增值工作，但通常是必要的工作。使用条形码、图像扫描仪和射频识别（RFID）标签及读取器可以显著缩短数据输入所需的时间。

• 检索文件所花费的时间：这也是一种等待，属于非增值工作。然而，在这种情况下，材料和操作员都在等待完成活动所需的信息。

• 发送和审阅电子邮件或其他消息所花费的时间：这正是它听起来的样子——进行增值工作所需的信息在需要时并未及时提供。这一问题类似于与长时间文件下载相关的问题。

• 增值工作：与前面列出的所有项不同，这项工作是唯一能为产品增加价值的努力。

我们现在已经查看了当前价值流图的交付时间和周期时间。接下来，让我们来看看准确度指标的完成百分比。

改进准确度完成百分比（%C/A）指标

另一个我们需要关注的最终问题是累积的 C/A 值。图 8.2中的%C/A 值乍一看似乎在每个活动中都相对合理。但仔细看看影响测试。77%的 C/A 比率对最终的累积平均值（在这个例子中为 41%）产生了过大的影响。完成准确率（%C/A）指标，更简单地说，是衡量一个工作项或信息在 100 次通过一个活动或一系列活动时，未要求返工或纠正错误的次数。

每个活动都有一个%C/A 值，而累积的%C/A 度量则是将所有活动的%C/A 数值相乘。因此，仅仅一个异常值就可能产生巨大的负面影响。此外，测试中的低%C/A 值是我们在未来状态映射过程中需要关注的另一个领域。

现在我们已经回顾了当前价值流图中使用的度量指标，接下来让我们回顾一下评估精益绩效所需的工具。

评估精益绩效

到目前为止识别的精益度量帮助我们评估价值流中的流动效率，并作为识别浪费领域的手段。但我们还需要评估那些需要特别关注的领域，以便在我们持续的改善活动中消除浪费。一种实际的方法是通过开发精益评估雷达图。

精益评估雷达图将你已经学到的具体精益目标映射到一个网格上，像辐射线一样从中心向外扩展。完成的雷达图看起来有点像蜘蛛网，如图 8.3所示。该图包含了一个精益评估雷达图的示例图形展示：

图 8.3 - 精益评估雷达图

雷达图使用刻度来排名能力，从中心的无承诺开始，到外部半径的世界级能力等级。附录 C中的示例从 0（无承诺）开始，向外扩展，涵盖四个改进的能力水平。

在我们的精益评估雷达图示例中，如图 8.3所示，辐射线具有以下排名：

0：无承诺。

1：开始实施精益。

2：变化开始变得可见。

3：各级别的结果在不断改进。

4：世界级水平。

快速查看图 8.3中的雷达图显示，我们最需要改进的领域是持续流动、质量和可视化控制。相比之下，五常法系统和培训的实施似乎都已经得到了很好的掌控。

如果没有精益度量指标作为目标，那么该度量将变得主观。VSM 团队必须努力确定在每个评估的精益实践中，世界级绩效的表现是什么样的。我们示例雷达图中评估的精益评估度量指标包括以下内容：

• 持续流动：这表示流动中的同步性和效率，理想目标是实现单件流。

• 精益五个 S：这是指价值流的工作区域是否清洁、整洁、安全、有序，并且已实施、安排并以视觉方式展示了 5S 实践。

• 订单平衡：组织在多大程度上采用了 Heijunka 和其他精益平衡实践。

• 质量：价值流在多大程度上达到其既定的质量度量，同时始终朝着理想目标努力，即没有错误、缺陷、返工或失败。

• 培训：所有价值流成员都已完成精益培训，并可以获得教练和导师的帮助，以及随时访问精益培训资料。

• 团队成员参与度：VSM 团队成员和价值流操作员在遵循价值流的标准精益实践、参加精益评估会议、应用 5S 实践、参加精益培训项目以及支持持续改进目标方面的参与程度。

• 视觉控制：VSM 团队、VA 操作员和经理在维护和展示他们的精益度量、5S 标准以及标准活动信息方面的程度。

• 工作单元移动：价值流在限制等待、应用准时和拉动导向调度概念以及将流动与 Takt 时间匹配方面的程度。

在进行 Gemba 走访之前，VSM 团队应讨论并决定每个精益评估类别的 0 到 4 的数值应是什么样的。他们还需要确定计划查看的内容，以便正确评估每个类别。

例如，假设在 5S 类别中，价值流内每个五个“S”实践的积极观察都会为总共可能的 4 分积累 0.8 分。因此，VSM 团队为每个类别获取了多个数值，最终计算出的平均值会有小数点。

这些精益评估度量是我们 Kaizen 努力的重要基础。与敏捷团队一样，精益团队必须不断努力改善其价值流活动和流动。精益评估度量帮助我们看到团队可以在哪些方面改进他们的活动。

我们即将完成精益度量部分。但是在结束之前，让我们快速回顾一下与收集和应用精益度量相关的工具。

衡量关键软件交付度量

到目前为止，分配给活动的指标仍然是相对传统的精益指标，适用于任何组织的价值流。然而，Nicole Forsgren、Jez Humble 和 Gene Kim 在《Accelerate: Building and Scaling High Performing Technology Organizations》一书中（2018 年，第 17-19 页）确定了一组预测软件交付性能的关键指标。基于他们对来自 2,000 个独立组织的 23,000 个调查回答的详细统计分析，他们发现以下四个指标对于衡量软件交付性能至关重要：

• 交付交付时间

• 部署频率

• 平均恢复时间（MTTR）

• 变更失败百分比

他们的工作在DevOps 研究与评估（DORA）团队的指导下继续进行。这个谷歌研究小组开展了为期 6 年的项目，旨在衡量和理解整个 IT 行业的 DevOps 实践和能力。DORA 的研究成果在 2014 年至 2019 年的《DevOps 年度报告》中展示，并可以在cloud.google.com/devops/state-of-devops查看。

我们将在接下来的四个子章节中更详细地讨论这些指标。

交付交付时间

交付交付时间是将客户需求从创意阶段到客户满意所需的总时间。在软件开发中，满意意味着产品增强满足其完成定义。换句话说，团队和客户都同意交付的项目符合其已定义的接受标准。

但是，作为一个以精益为导向的指标，交付交付时间的计算是比较复杂的。在 第七章，当前状态映射（VSM 第 4 步），特别是在准备映射部分中，你学到了定义和验证需求与设计的活动是创造性的任务。相比于开发和测试代码、配置和部署等相对标准化的工作，执行创造性工作所需的时间和精力是很难预测的。当我们谈论使用交付交付时间来衡量软件交付性能时，通常最好在产品待办事项列表中的需求被充分细化，开始编码工作时启动计时。

高绩效的软件交付组织可以在不到一小时的时间内，将一个新的需求开发、测试并交付为有效代码，并推送到主代码库分支。相比之下，最低绩效的组织在最近的数据显示（2017 年），他们每周到每月才将有效代码部署到主分支，而在之前的年份中，有的甚至需要每六个月才能部署一次。

部署频率

部署频率是指将代码发布到生产环境或发送到应用商店的频率。如前所述，编写和测试较小增量的功能优于一次性构建和部署大规模的代码更改。表现较差的团队往往会承担更多的功能增量，增加了编码、测试和调试的复杂性，从而将部署频率推迟到 1 到 4 周的范围内。相比之下，表现最好的团队根据需求接受新功能要求，按小的增量构建功能，并且每天发布多次部署。

请注意，软件开发的价值流等同于理想化的生产流概念——单件流。当组织自动化了从代码到生产发布的 DevOps 管道时，就会发生单件流。单件流是 CI/CD 管道的终极目标。换句话说，每次将软件代码提交到 SCM（源代码管理）仓库时，都可以自动流经管道并进入生产环境，而无需人工干预。

理论上，这仍然是一个连续流的例子，最终停留在预生产环境进行最终审批。但如果这一环节还涉及到分阶段和发布多个功能，那么这一部分的过程现在就变成了批处理过程。无论原因或优点如何，所有批处理都会阻碍价值流向客户的过程。

恢复平均时间

恢复平均时间是一个关键的指标，因为它代表了应用程序或系统失败并未为客户提供服务的时间。通常，当系统或功能出现故障时，我们别无选择，只能回滚更改，直到我们能识别并修复问题。因此，关键在于快速发现故障并执行回滚到先前的工作版本。理想情况下，我们希望看到这一 MTTR 值低于一小时。表现较差的团队通常需要一天到一周的时间来恢复失败的服务。

变更失败率

变更失败率指定了代码变更导致失败所需的时间百分比，通常表现为 bug 或缺陷的形式。借助现代管道部署能力，新版本发布可能仅涉及回滚新发布的功能。但失败也可能表现为系统崩溃和服务丧失。无论如何，表现较差的团队的变更失败率在 31%到 45%之间，而表现最好的团队的变更失败率则在 0%到 15%之间（Forsgren 等，2018 年）。通过编写测试脚本（如测试驱动开发和自动化测试能力）的改进，有助于降低变更失败率。

现在你对常见的价值流度量以及最常定义软件开发组织绩效水平的四项度量有了全面的了解。在接下来的子部分中，我们将探讨如何使用当前的价值流度量来分析现状。

向 VSM 中添加流程度量和分析

除了DORA 四项度量，软件开发的趋势是实施流程度量和分析能力，为业务领导者、产品经理和价值流团队提供可见性，从而持续改进其流程。次优流程和团队表现可能对组织的精益敏捷转型工作产生负面影响。

或者，当组织能够访问准确且一致的业务操作和价值流度量时，可以指导改进活动和辅导。这些度量必须始终可用、最新，并对所有利益相关者可见。

现代 VSM 工具使捕获价值流度量变得更加容易。这是因为它们充当自动化活动，避免了可能影响结果的人工操作和报告。数据捕获自动化使信息更加可用、及时、准确且易于使用。业务领导者、团队成员和其他利益相关者必须对数据及其准确性充满信心。

数据可能来自参与价值流管道流程的许多不同工具或系统。现代 VSM 工具应用通用数据模型，对数据进行标准化，从而提供跨整个价值流管道的端到端数据视图。此外，某些分析工具利用人工智能功能，使高层管理人员和 VSM 团队成员更容易评估当前状态活动中的流程，并评估未来状态的替代场景。

此外，投资组合经理和产品负责人可以使用相同的流程度量和分析功能，评估与其产品和发布路线图的进展。因此，业务负责人和相关利益相关者将能获得更高的产品交付状态和相关生产成本的可见性。

超越 DORA 四项度量

DORA 四项度量非常有用，因为它们有助于识别定义最佳软件交付能力的关键度量。它们还为软件开发团队在向精益敏捷实践转型过程中提供了一组有价值的度量目标。

然而，在精益敏捷企业中，组织应跟踪许多其他度量，以识别持续改进的领域，并验证其改进目标的实现。例如，Gartner 分析师 Bill Swanton 在名为《软件工程领导者如何使用价值流度量提高敏捷效能》的Gartner 报告中识别了 18 项流程度量。这些领域显示在下图中：

图 8.4 – Gartner 确定的流程度量列表

Swanton 提到，以下是应该考虑的一些流度量示例，并指出：“就像精益制造过程中的度量指标一样，它们衡量工作如何顺畅地流动，并且团队对需求变化的响应速度如何。”

他进一步指出：“供应商们已经开始提供与您的软件开发、基础设施和监控工具（版本控制、工作管理、测试管理等）集成的系统，以便持续收集、计算和展示这些度量指标。”

一家在这一领域做了大量工作的公司是 Tasktop，在公司首席执行官 Mik Kersten 的领导下，推出了 流程框架®。

实施流程框架

Tasktop VSM 工具在 第十二章* 中进行了更详细的介绍，题为“介绍领先的 VSM 工具供应商”。然而，鉴于流程框架与本节的相关性，我们将花点时间解释现代 VSM 工具如何帮助捕捉和分析流程度量。

流度量和流程框架背后的概念最早在 Mik Kersten 博士（2018 年）的《从项目到产品》一书中介绍。自那时以来，IT 领导者们在全球范围内采纳了这些概念，以缩小技术人员与业务利益相关者之间的差距。具体来说，流程框架提供了一个方法论和词汇，系统地发现并消除那些减缓软件交付速度并对业务结果产生负面影响的瓶颈。

流程框架的目标是确保业务层面的框架和转型举措与实现敏捷和 DevOps 相关的技术框架相连接，同时也涵盖未来将出现的方法论。Tasktop 的流程框架扩展了 DevOps 的三种方式 —— 流动（加速开发、运营直至客户交付）、反馈（创建更安全的工作系统）和 持续学习与实验（促进信任和科学方法以推动组织改进和风险承担）—— 到整个业务。这些概念最早在《DevOps 手册》一书中提出（Kim 等，2016 年）。

借助现代 VSM 工具，任何组织都可以收集数百个有价值的度量指标，用于评估过程、生产力、质量、成本、收入以及标准遵循的改进。关键是要将所有信息理清楚。不幸的是，许多组织常常缺乏对端到端管道流程的可视化，导致难以回答下图所示的问题：

图 8.5 – 流程框架的流度量

流动指标有助于识别和解决系统瓶颈，消除当可见性仅限于孤立工具数据时可能存在的低效局部优化。它们还提供了你表现的历史视图，让你了解选择和变化如何影响你的流动。

四个流动项构成了一个由利益相关者通过产品价值流拉动的业务价值单位。这些项包括功能、缺陷、风险和债务，如图 8.6 所示。流动指标对每个流动项进行单独和集体测量。下图展示了这些项目：

图 8.6 – 四个流动项

流动项代表对组织有价值的项目。换句话说，我们如何处理功能、缺陷、技术债务和风险的优先级，将影响我们交付客户价值的能力。因此，业务和技术领导者必须通力合作，分析这四种价值类型的流动、速度和优先级。

例如，功能通常具有优先级，但有时我们需要修复 bug、减少技术债务，或者解决关键风险和问题。如果我们不平衡这四个流动项目所关联的工作，最终会付出沉重的代价。

尽管软件交付工作复杂且难以捉摸，流动框架通过定义如何从执行工具中提取必要的数据（集成模型），使得流动指标（以及 VSM 的日常实践）对任何组织、任何结构都变得可达。这些数据被抽象为流动项和流动状态（活动模型），并以与业务对齐的视图呈现（产品模型）。

通过上述展示和分析，流动指标可以用来帮助领导者和团队做出决策，以实现有针对性的业务成果。Tasktop 的 VSM 平台通过一个点选界面提供这些功能。图 8.7 展示了流动框架的海报视图：

图 8.7 – 流动框架海报

Tasktop 强调，除了流动框架外，还有其他重要的框架（如有纪律的敏捷（DA）、规模化敏捷框架®（SAFe®）、大规模 Scrum（LeSS）和 Nexus），这些框架帮助组织规模化敏捷，并将这些实践与业务目标联系起来。你会记得，敏捷是一套价值观和原则，帮助组织围绕增加以客户为中心的价值和灵活应对变化来调整其资源和活动。

相反，VSM 能够增加商业价值的流动，从最初的客户需求到最终交付给客户。Flow 框架是一种结构化的、规定性的方法，用于软件交付组织中的价值流管理，旨在为企业提供一个面向客户的流动视图，涵盖整个软件交付过程。因此，敏捷方法有助于确保我们在正确的时间交付正确的客户中心价值，而 VSM 则确保我们快速且高效地交付这一价值。

创建一个安全的工作环境

一直保持与敏捷的价值观和原则一致，我们绝不应将流动度量作为惩罚或奖励个人和团队的工具。相反，它们的目的是帮助引导我们的持续改进工作。

精益敏捷实践强调基于团队的绩效，当事情出现偏差时——这在所难免——我们需要采取全员参与的方式来解决当前的问题。如果团队和个人害怕惩罚，那么你可以预期他们会避免发声，甚至可能隐瞒那些影响他们有效、快速和高效交付软件价值的关键问题。

因此，当我们的价值流发生中断时，我们需要立即停下来，让所有团队成员共同合作解决问题。试图保持生产持续进行会导致排队、活动等待、产品延迟，甚至可能导致更多缺陷的积累，这些只会增加我们的成本。

拥有实时流动度量的好处是，我们可以在问题出现时立即发现它们。这使我们能够更早地解决问题，从而减少生产时间损失和其他浪费。此外，这些度量和分析有助于团队评估问题和根本原因，并集思广益，提出替代的解决策略。

实施精益度量工具

在本章关于精益度量的内容中，你了解了常用的度量指标，这些指标通常用于衡量精益生产实践。你还了解了四个特定的度量指标，它们能最佳地预测软件交付团队的表现。传统的价值流图（VSM）实践采用手动工具来捕捉和分析价值流度量。此外，你还了解了现代 VSM 工具、流动度量和分析如何帮助提高软件交付的速度和效率，同时确保软件开发与业务目标和宗旨保持一致。

关于手动工具，你了解了如何使用一个大型白板或图表，或者电子屏幕，使你的度量指标高度可见。你还了解了如何更新你的 VSM 故事板，以保持所有 VSM 团队数据的集中并能从一个单一来源访问。最后，你了解了如何评估价值流的精益实践。这些实践涵盖了八个类别，并以精益评估雷达图的形式展示。这些都是与 VSM 实践同时发展的手动工具。

现代 VSM 工具的优势在于它们能够捕捉端到端的管道信息，并提供跨统一数据模型的分析工具。在它们的现代复兴中，VSM 工具供应商实施了捕获和分析度量指标的功能，以支持 CI/CD 和 DevOps 管道流动，使用与所有其他组织价值流中采用的相同概念和类型的度量指标。因此，分析师可以评估管道活动的性能，无论其集成了多少第三方工具。

但是现代 VSM 工具不仅仅限于数据捕捉和分析。它们还支持管道流动的集成、自动化和编排。我们将在下一章的未来状态映射中开始探讨这些主题，并在本书的第三部分中深入讨论 VSM 供应商。

本节结束了我们关于精益度量指标的讨论，这是我们 VSM 方法论中的第五步。在下一章，第九章，映射未来状态（VSM 第 6 步），我们将开始在三个阶段中绘制理想的未来状态：评估与客户需求的对齐，实施持续流动，以及通过生产控制和编排策略实现生产流动平衡。

总结

本章提供了关于帮助我们从精益角度评估价值流有效性的关键度量指标的指导。你还学习了如何收集有用的精益度量指标（我们通用 VSM 方法论中的第五步）。

尽管 VSM 团队可以手动收集和分析度量指标，但这是一个劳动密集型的过程。相比之下，现代 VSM 工具越来越重要，主要原因在于它们能够实时捕捉和显示这些信息。此外，VSM 工具的分析功能和假设能力支持未来状态分析。

在下一章中，你将学习如何通过三个不同的阶段，涵盖客户需求、持续流动和生产平衡，进行未来状态映射练习。在进入下一章之前，花点时间回答以下问题。如果你暂时记不清或不完全理解所有问题，别担心。回去寻找答案将有助于你更好地理解和记忆这些知识。

问题

请回答以下 10 个问题：

1. 为什么识别精益度量指标如此关键？

2. 什么是周期时间（CT）？

3. 周期时间（CT）与增值时间（VT）是一样的吗？

4. 六西格玛的相关性是什么？

5. 精益软件交付中最重要的四个度量指标是什么？

6. 列出那些导致浪费的非增值活动类型。

7. 变更失败率的相关性是什么？

8. 精益评估工具的核心是什么？

9. 精益评估雷达图上通常的径向线是什么？

10. 在其现代复兴中，VSM 工具供应商实现了带有度量和分析功能的平台，以支持哪三项功能？

进一步阅读

• Tapping, D., Luyster, T., Shuker, T. (2002) 《价值流管理：规划、映射和维持精益改进的八个步骤》。生产力出版社。纽约，纽约州

• Tapping, D., Luyster, T., Shuker, T. (2003) 《精益办公中的价值流管理：规划、映射和维持精益改进的八个步骤》。生产力出版社。纽约，纽约州

• Tapping, D., Kozlowski, S., Archbold, L., Sperl, T. (2009) 《精益医疗中的价值流管理：规划、映射、实施和控制各类医疗环境中改进的四个步骤》。MCS Media, Inc. 切尔西，密歇根州

• Forsgren, N., Humble, J., Kim, G. (2018) 《加速：构建和扩展高效能技术组织》。IT Revolution 出版社。波特兰，俄勒冈州。

• Kim, G., Humble, J., Debois, P., Willis, J. (2016) 《DevOps 手册：如何在技术组织中创造世界级的敏捷性、可靠性和安全性》。IT Revolution 出版社。波特兰，俄勒冈州。

• Kersten, M. (2018) 《从项目到产品：如何在数字化颠覆时代通过流动框架生存和发展》。IT Revolution 出版社。波特兰，俄勒冈州

第九章：映射未来状态（VSM 第 6 步）

在上一章中，你学习了如何映射当前状态，进行精益办公室评估，并观察和记录价值流的关键精益指标。你还学习了如何记录与工作和信息流动相关的重要信息。最重要的是，你学会了如何从精益的角度来可视化工作和信息流动。

当前 VS 映射练习中执行的工作是文档性质的。它不涉及太多的想象力——只是准确的发现（通过 Gemba 走访）、记录和映射。现在，我们将进入精益价值流映射的创意阶段，设计一个改进的未来状态。未来状态映射发生在三个连续阶段，以帮助评估方法并改善价值流在满足客户需求、建立和保持持续流动以及均衡客户订单分配方面的能力，从而最大化运营效率。

本章将涵盖以下主要内容：

• 建模三个未来状态目标

• 未来状态映射的第 1 阶段 – 客户需求

• 未来状态映射的第 2 阶段 – 持续流动

• 未来状态映射的第 3 阶段 – 均衡

具体来说，你将学习如何结合精益和敏捷实践，通过实施持续改进，发展自己的技能，并将精益思维的概念融入到 CI/CD 和 DevOps 管道实现中。你将从介绍未来状态建模的三个阶段开始学习：客户需求阶段、持续流动阶段和均衡阶段。

建模三个未来状态目标

本节提供了如何在三个阶段进行未来状态映射练习的指导，包括分析客户需求、持续流动和均衡。以下列表简要描述了每个阶段所涉及的工作：

• 客户需求阶段：这包括分析客户对产品或服务的需求，以确保它们包含质量目标和交付时间。

• 持续流动阶段：这一阶段有助于改善流动，以便我们的客户能在正确的时间、以正确的特征和数量，获得正确的产品或服务。

• 均衡阶段：这一阶段有助于在产品线之间均匀分配工作，减少等待时间，并消除批量处理（即，目标是实现单件流动）。

尽管三个阶段之间可能会有重叠，但初步分析将遵循这三个阶段。

价值流作为管道流动的形式运作，具有输入、工作活动的顺序和输出。在更复杂的环境中，我们可以预期会与其他价值流或活动集成分支。因此，如果我们不理解需求如何流入我们的价值流，几乎不可能理解我们优化的连续活动流目标应是什么。

当我们识别并协调需求流输入时，VSM 团队可以分析如何改善活动和信息流，以匹配需求速率。最后，我们可以预期客户需求会随时间变化，因此我们需要理解如何平衡生产工作负载，以持续最小化瓶颈、等待和其他形式的浪费。

由于未来状态阶段遵循上述分析顺序，我们将按相同顺序介绍三个阶段，从分析客户需求开始。

阶段 1 – 客户需求

未来状态映射练习的这个阶段明确设立，确保 VSM 团队以客户需求为中心，开始精益改进目标。但我们并不是在谈论从功能和特点的角度理解客户需求，因为这种分析属于产品管理职能。换句话说，工作项的识别、选择和优先排序是 IT 环境中敏捷产品管理和产品待办事项梳理过程的一部分。

在这个阶段，你需要回答以下问题：

• 你的客户对这个价值流的需求是什么？

• 你有多少个客户？

• 支持的客户类型、市场细分或利基市场有哪些？

• 所有客户或按产品线分类的客户的订单可预测性如何，包括季节性调整？

• 你是过度生产、生产不足，还是正好满足需求？

• 你满足客户需求的能力会随时间变化吗？如果会，为什么？

• 你能用当前的资源和能力按时交付给客户吗？如果不能，为什么？

• 你需要携带缓冲或安全库存吗？如果需要，是什么类型的，为什么，需要多少？

• 当前需要解决的问题是什么？

• 你的价值流的设施和操作有多干净和有序？如果不足，负面影响是什么，我们需要做些什么来减少杂乱和无序？

在精益生产中，满足客户需求的重点在于履行领域。换句话说，VSM 团队致力于帮助价值流提高交付速率。提高未来状态下满足客户需求的能力是一个多步骤过程，涉及以下问题：

• 计算节拍时间。

• 确定目标。

• 调整缓冲区和库存。

• 改善工作环境。

• 解决当前问题。

VSM 团队通过计算价值流的节拍时间，开始他们的未来状态——与客户需求相关的分析。

计算节拍时间

理解 Takt 是首要任务，因为它是衡量价值流需要多频繁地交付产品或服务以满足客户需求的指标。如果我们不知道需求目标，就无法了解需要多少改进来提高交付效率。

Takt 时间是客户要求交付我们产品或服务的速度或频率。我们通过将净可用操作时间除以所需交付产品的数量来计算 Takt 时间。净操作时间是指在特定时期内可用的工作小时数（例如，7 小时的班次、一天 14 小时的运营时间，或每月 2,240 小时）。

计算净操作时间时，确保从总时间中扣除会议、健康休息、午休和其他非增值活动的时间。因此，在一个 8 小时的工作班次中，若有两次 15 分钟的健康休息、一个 30 分钟的午休以及一次 15 分钟的每日 Scrum 或站立会议，那么净操作时间为 405 分钟：

净操作时间 = ((8 小时 * 60 分钟) – 15 分钟 – 15 分钟 – 30 分钟 – 15 分钟) => 405 分钟

如果我们的每日客户需求率是 810 个单位，那么我们的 Takt 时间可以按以下方式计算：

405 分钟 ÷ 810 单位/天 = 0.5 分钟/单位

换句话说，Takt 时间为每个单位 0.5 分钟时，你需要每分钟生产两个单位。大型商用飞机或船舶制造商通常没有每天交付多次的要求。然而，汽车和电子设备制造商通常有这个需求。

在传统的瀑布模型或软件开发生命周期（SDLC）模型中，软件开发团队通常每年发布新产品——这些产品通常作为与财政年度预算对齐的时间限定项目启动。不幸的是，这种策略由于多种原因并未取得良好的效果。相比之下，现代敏捷实践使得软件开发团队能够在 1 到 4 周的时间内交付新功能。

然而，即使采用敏捷实践，软件产品经理可能仍然选择较少频繁地将软件发布到生产环境中。对于商业产品，交付活动可能需要与市场营销和销售推广相协调。在 BPI 的背景下，新的软件增强功能会影响业务流程，这需要附加活动来创建和部署系统管理员支持指南及培训资料，并提供给操作人员和用户。

另一方面，持续集成和持续交付（CI/CD）工具和实践能够增强敏捷实践，使得新软件版本的部署频率大大提高。IT 开发团队可能会从整合软件工程工具开始，形成集成工具链，帮助自动化并加速软件开发生命周期(SDLC)过程中各个环节的流转。

随着成熟度的提升，IT 组织实施了一条集成化且自动化的工具链，支持跨软件开发和运维功能的信息和工作流。通常被称为DevOps 流水线或DevOps 平台，这些集成和自动化工具显著提升了软件交付的速度和可靠性。

例如，一个现代的 DevOps 环境的持续部署能力使得新功能和功能可以一天多次发布到生产环境中。此外，成熟的 DevOps 流水线允许开发团队按需启动多个测试环境，并在部署之前迅速检查功能、系统负载、性能和压力能力。

大型在线零售商、保险公司、制造企业和医疗服务提供商之间的竞争变化的快速节奏帮助证明了对 DevOps 流水线和平台的投资是合理的。正如前面提到的，DevOps 能力是我们在数字经济中竞争并满足客户不断变化需求所必需的基础条件。Takt 时间则设定了节奏。

建立 pitch

Pitch是指一个价值流生产一个产品容器所需的时间。在理想的情况下，客户订单将按单个订单、每次一件的批量、以恒定的速度到达，我们能够以相同的速度处理这些订单，作为单件流。然而，对大多数生产商来说，这种情况很少见。此外，我们的供应链合作伙伴可能无法仅为了满足一个客户订单而交付材料和零件，至少由于运输大宗产品的成本通常较便宜这一原因，情况往往是这样。

当软件通过互联网连接进行交付时，运输成本不是问题。但当软件以 CD-ROM 或作为实体产品的一部分打包时，软件交付就成了一个问题。

由于这些原因，将生产速率与精确的 Takt 时间匹配具有挑战性，生产调度员必须找到有效的方式来应对这些差异。这就是建立pitch的目标——确保组织能够以最有效的方式应对需求变化。

在学习如何计算 pitch 之前，我们需要理解包装数量，因为它是 pitch 度量的一部分。包装数量是客户（内部或外部）希望一起交付的物品数量，通常在运输过程中以容器形式搬运。

理解包装数量最简单的方法是想象生产足够的零件来填满运输纸箱或运输集装箱，以便交给客户。如果我们能够实现单件流并一次只发运一个零件，那么我们的包装数量就是一。但如果我们要为零售商的订单提供产品，包装数量可能会根据季节、产品类型和每个客户的销售量而有所不同。

Pitch 的计算相当简单，即Takt 时间乘以包装数量。例如，如果产品A的最优包装量是每批 100 个零件，而我们的 Takt 时间是每天 400 次产品A的发布，那么我们的 pitch 可以这样计算：

Pitch=每天 400 个零件 X 每批 100 个零件 = 每天 4 批

换句话说，价值流必须每天运送四批 100 个产品。

在考虑什么是“pitch”时，必须理解 Takt 时间是由客户驱动的，但包装数量可能会受到限制。因此，在考虑你的 pitch 时，有几个因素是你必须考虑的。

客户可能不会选择一次购买或接收一个产品。有些客户可能要求不同批量大小的发货，可能是由于季节性调整。此外，由于长时间的设置和更换时间以及批量处理，组织可能还无法最有效地生产单件流的产品。

相反，允许价值流以更大的批次大小进行流动可能更为可取，以最小化零部件和物料的更换。最后，运输成本通常是确定最优交付批量大小时的重要因素。

在软件交付组织中，包装数量和 pitch 成为在敏捷冲刺（Sprints）中发布的敏捷团队中的重要因素。例如，一个敏捷Scrum团队评估他们的包装数量为每个 Sprint 完成的用户故事数量，这就是他们的 pitch。

许多 IT 组织面临基础设施的限制，这些限制可能限制它们能够并行运行的测试服务器数量。在这种情况下，包装数量就是它们可以并行运行的测试数量，而它们的 pitch 是测试活动的持续时间。

最后，客户可能不愿意在生产中一次接收一个新功能，特别是当这些功能影响到业务流程且需要通知和培训员工时。在这种情况下，每次发布都具有一定的功能包装数量，而 pitch 是发布之间的时间间隔。

理解生产控制

当组织必须以更大的批量大小处理工作项时，调度员应该实施生产控制机制。例子包括看板（Kanban）箱或平准化（Heijunka）箱，通过按工作量和生产的工作项类型来平衡工作项的流动。

价值流操作员仍然将工作项拉入他们的工作站。但是，他们拉取的是整个批次，而不仅仅是一个零件。例如，在制造业中，零件可能是通过一个容器提供的，操作员按其特定活动设计允许的单件速率完成工作。然后，一旦容器被重新填充，下一个排队的操作员在有可用容量时可以将整个批次拉入他们的工作站。

在软件交付价值流中，软件工程师从 Sprint Backlogs 中拉取工作项，并完成相关用户故事功能的实现和测试。实际上，Sprint Backlogs 作为 Heijunka 箱的类型，用来管理一组用户故事的流动，这些故事会一起经过开发和测试活动。

下图展示了 Sprint Backlog，作为容器呈现了即将在下一个 Sprint 中进行开发的用户故事：

图 9.1 – Sprint Backlog 作为一种 Heijunka 箱

团队已经选择了接下来 2 周 Sprint 的六个最高优先级的工作项。然而，产品负责人每 4 周会向产品待办事项列表中发布平均 20 个新需求。基于这一点，你需要管理开发团队的能力，以支持客户的需求。

假设开发团队成员在休息和会议后，每天工作 7 小时，四周的月总计为 140 小时的净操作时间，或者每个 2 周的 Sprint 期间为 70 小时。因此，无论你选择哪种持续时间，你的 Takt 时间将是每个工作项 7 小时。换句话说，新的工作项平均每 7 小时就会进入我们的 IT 价值流。

由于开发团队为 Sprint Backlog 选择了六个工作项，因此该批次的 Pitch 时间是 Takt 时间乘以选择的工作项数量，即 42 小时。换句话说，开发团队必须在 42 小时内启动新的六个工作项批次，以匹配 Takt 时间的交付速率。

由于每个 2 周的 Sprint 期间都有 70 小时的净操作时间，因此很容易认为应该能够满足需求。但等等，VSM 团队的工作还没有完成。首先，我们需要评估这段时间内，处理一批六个工作项跨越整个价值流所需的时间。

如果我们的 IT 价值流能够实现自动化和持续流动，我们或许不必太担心这个问题。然而，在基于 Scrum 的敏捷实践中，开发团队只能在接下来的 2 周内专注于这六个工作项。

查看当前价值流图中显示的度量指标，以及 第八章**，识别精益度量（VSM 第 5 步） 中的度量表，在 图 8.1 (总交付时间、总增值和滚动 C/A 表) 和 图 8.2 (IT 价值流中的精益度量表) 中。我们知道整个 IT 价值流的 总交付时间 (TLT) 为 328 小时，约为 8 周多一点的时间。大部分时间都花费在产品待办事项队列中，或者等待新版本作为功能发布。

从积极的方面来看，我们的总增值时间（TVT）是整个 IT 价值流中的 57 小时，这在 Sprint 可用的 72 小时净工作时间内完全是可以接受的。从消极方面来看，开发相关活动有 80 小时的提前期，发布相关活动也有 80 小时的提前期。

VSM 团队需要做一些工作来解决与等待和不匹配的周期时间相关的问题。例如，如果基础设施未设置为按需处理单件流的测试，工作项可能会在测试时再次排队。类似地，经过测试的软件工作项，现在作为已测试功能可用，可能会再次坐在队列中，等待发布到客户的生产环境中。

在敏捷环境中，产品发布到生产环境可能会在每个 Sprint 中进行，但更常见的是通过较少频繁和更正式的产品发布进行发布。正式发布给我们提供了时间来实施市场推广和销售活动以便于商业交付，以及当软件交付影响关键业务流程时的社会化和培训。

等待是示例 IT 软件交付价值流中的一个主要问题。既然我们已经注意到队列有时是必要或不可避免的，我们就来讨论如何管理它们。

管理缓冲区和安全库存

到目前为止，你已经学习了如何使用 Takt 时间和生产节拍来管理流动以满足客户需求。但是，我们还需要管理我们的缓冲区和安全库存，以确保始终有在制品（WIP）来支持客户需求。然而，我们不能拥有过多库存，以至于人为引入问题，导致产品延迟并增加我们的持有成本。我们已经知道WIP等待在示例 IT 价值流中是一个问题，因此我们从这里开始。

消除在制品队列

在深入讨论之前，必须理解消除所有在制品缓冲区（WIP）的工作项和物料的必要性。WIP 队列仅仅是隐藏问题的方式，并不能在任何方面帮助改进流程。WIP 队列只是隐藏流动问题的机制。精益只允许携带成品作为库存，但即便如此，也有严格的限制。

同样重要的是，不要将库存的概念与处理工作项批量的概念混淆，正如在前一部分中关于建立生产节拍所述。库存一词指的是我们价值流管道中或管道的某些部分中包含的所有物料、工作项或产品的总数量。相对而言，批量大小是一种机制，用来将一定数量的工作项（物料或产品）一起流经价值流，从而改善流动。

例如，当一个软件开发团队从产品待办事项列表中选择工作项时，产生的冲刺待办事项列表实际上是团队判断最适合在即将到来的冲刺中完成的批量大小。

冲刺待办事项中的工作项流动

在短期内，直到我们能够实现单件流时，可能更高效的是以较大的批量流动工作项。这一局限性源于价值流活动之间的不均匀流动速率，周期不匹配、设置时间和批处理过程等问题。

这正是我们 IT 价值流示例中的情况。通过实施敏捷实践来实现迭代和增量开发，并通过冲刺待办事项列表最小化在制品批量大小，我们提高了生产力。实际上，这也是 IT 相关价值流中冲刺待办事项列表的目的：控制产品开发流程，使其易于管理。但以批量流动工作项与允许这些工作项在活动间排队等待是不同的。

在敏捷环境中，一个常见的做法是从产品待办事项列表中选择一批工作项，为即将到来的冲刺做准备，然后使用看板（Kanban）管理冲刺过程中的流动。稍后，当 IT 部门实施成熟的 CI/CD 或 DevOps 流水线——以简化、集成和自动化软件开发生命周期（SDLC）过程——时，IT 价值流可以针对产品待办事项列表中排队的工作项实施单件流。

使用看板管理流动

另一种策略是完全取消基于敏捷的冲刺，而改为采用纯粹的看板导向生产控制策略。在看板系统中，开发团队成员直接从产品待办事项列表中拉取已精炼和优先排序的工作项。团队成员从头到尾处理每个工作项，贯穿整个开发流水线。

要有效实施看板导向的 IT 生产控制策略，需要相对成熟的 CI/CD 能力。如果没有 SDLC 活动的集成和自动化，团队将会花费大量时间在与设置和配置开发、测试环境以及等待测试结果相关的非增值工作上。

在一个合适的看板系统中，冲刺待办事项列表中的所有工作项必须经过SDLC流程，才能进入敏捷/敏捷框架团队的下一个工作。换句话说，看板和敏捷实践并没有消除传统的 SDLC 活动，如编码、构建、集成、合并代码、配置、开发和测试环境的配置、执行单元测试、集成测试、系统测试以及其他许多关键测试。

但这些活动执行得更加频繁，以适应每个迭代开发周期中小规模新功能增量的生产。集成和自动化改善了流程，帮助消除 SDLC 中的浪费，而价值流管理则帮助优先处理并推动 IT 价值流的改进。

下图展示了在 IT 价值流中实施的看板生产控制策略。请注意，看板板并未引用开发管道中的特定 SDLC 任务。相反，这些活动都被封装在看板导向的产品工作流中的进行中和验证阶段：

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/drv-dop-val-st-mgt/img/B17087_09_02.jpg)

图 9.2 – IT 价值流的看板板

与此同时，看板的拉动式生产控制策略防止 Scrum 团队在完成 Sprint 待办事项中的用户故事之前承担新的工作。

唯一的解决方法是 Scrum 团队将用户故事分配给团队成员，并在所有相关的 SDLC 活动中，从前到后逐一处理每个用户故事，直到系统，包括负载、压力和性能测试。如果它们确实发生，那些类型的测试活动通常会在产品发布到生产环境之前以批处理方式进行。

使用 CI/CD 管道改进流程

不幸的是，在产品发布前推迟测试会带来与批处理相关的问题。任何潜藏在代码中的缺陷或错误都会在 IT 部门计划发布软件产品时被发现，这将推迟发布日期。此外，在这个晚期阶段，集成代码的复杂性使得隔离和调试问题代码、API/ Web 服务、查询、安全、计算或网络相关的问题变得困难。

简而言之，除非开发团队拥有成熟的 CI/CD 管道，否则看板和 Scrum 是矛盾的实践。有了 CI/CD 能力，开发团队可以从头到尾独立地处理每个用户故事和功能，而不会有任何延迟。此时，团队需要评估 Sprint 的长度以及他们希望在 Sprint 待办事项中排队的工作项数量。记住，精益的目标是最终实现单件流。这个目标对精益敏捷实践同样适用。

既然你已经知道允许 WIP 队列不是精益实践，接下来我们看看在什么情况下允许队列和等待是有意义的。

允许成品库存

在精益中，我们需要在价值流中管理两种类型的库存：缓冲库存和安全库存。这两者都是成品库存的例子。成品这一术语意味着产品已完成开发并通过了 QA/测试，但在销售之前由于某种原因被暂时保留。

在软件开发中，软件组件和产品的发布可能会在满足完成定义的验收标准后被推迟（存储），即使这些产品技术上已经准备好交付给客户、零售或应用商店，或安装到生产环境中。造成这种推迟的一个主要原因是确保交付的其他要素已经到位。

例如，软件产品可能作为物理产品发布的一部分发布，或由于作为更大范围功能发布的一部分而被延迟。软件交付也可能会推迟，以便与市场营销和销售促销活动，或者与新业务流程的部署相协调。

缓冲库存是组织为应对客户需求变化（即节拍时间的变化）而持有的额外成品库存。与此不同，安全库存是用于满足持续客户需求的成品库存，当价值流的流动受到干扰时使用，例如设备故障、电力中断、劳动问题和意外的质量问题。缓冲库存和安全库存是分别存储并独立管理的，因为它们服务于两个完全不同的目的。

然而，理解成品的概念也很重要，它不仅包括由你的价值流生产的完成的工作项目。成品还可以包括从供应链供应商处采购的材料和零件。如果你的价值流合作伙伴，或者他们的运输或配送服务遇到交付问题，那么持有一些此类库存可能是有意义的，以防止你的价值流“断粮”。

当你的软件产品嵌入到物理产品中时，这些概念尤为相关，例如制造设备和汽车中的控制系统，或支持基于物联网的价值交付能力。

物联网（IoT）

物联网（IoT）是描述一种物理对象网络的术语，这些对象嵌入了传感器、软件和其他技术，使其能够进行基于互联网的连接，并与其他连接的服务器、设备和信息系统交换数据。此外，物联网的能力使我们能够提供产品功能增强，例如更新汽车、卡车、飞机、船舶及其他运输系统中的导航系统。

随着软件产品为我们现代产品和服务提供动力，组织必须仔细管理工作项库存（即软件、硬件和其他物理产品及组件）。然而，组织也必须在所有组织价值流中管理其资源，以支持客户需求的变化。

管理缓冲和安全资源

库存概念不仅仅局限于管理零件、材料和完成工作项的库存。价值流可能需要缓冲和安全资源来应对高需求时期的生产提升，或者当我们的价值流操作人员请假时。缓冲和安全资源包括加班、雇用临时工或退休人员，或借调其他部门的员工。

同样地，我们可能需要在设备或工具中安装过剩的产能，以应对不同的客户需求负荷，或者在价值流因任何原因意外停机时弥补失去的时间。也有可能将过剩的工作交给其他价值流、合作伙伴或承包商，他们拥有多余的设备和人力资源。在后者的情况下，组织必须采取积极措施，确保合作伙伴/承包商能够提供相同质量和成本的交付。

使用成品超市

库存有助于在需求中断以及零部件、材料和产品的可用性中保持流程顺畅。但我们也可以利用库存来执行我们的拉动式生产控制策略。用于此目的的库存被称为成品超市。

这里的理念是，根据客户订单从成品库存中按需拉取产品，并且价值流会快速补充这些商品。从概念上讲，成品超市的运作方式与您当地的杂货店非常相似。顾客从杂货店的货架上取走产品，而补货员则从他们的成品缓冲区商店中补充这些库存。

超市跨越价值流和价值交付链工作。顾客从组织的成品库存中拉取产品，即使物理拉动过程涉及运输部门和货运公司。价值流会根据生产和操作流程上游补充成品库存。类似地，供应链合作伙伴会在交付组织的价值流拉取时补充组件材料和零部件。

超市是 JIT 生产理念的精髓。顾客作为最下游的活动触发工作、信息和材料的流动。所有其他上游的价值流和价值链活动都会同步补充它们的增值工作，并且是 JIT 以满足下一个客户的需求。

在 IT 环境中，最接近携带成品的做法是我们在发布前积累功能。但拥有软件成品库存的目的并没有太大区别，因为目标仍然是确保产品在客户准备好接受时已准备就绪。

到现在为止，您的 VSM 团队已经计算了所有产品线和客户的 Takt 时间，并且他们已经建立了一个或一组提升流程的节奏，以满足客户的交货需求。您还可以改善工作环境，以帮助价值流更好地满足客户需求。

改善工作环境

精益组织使用5S 系统来改善工作环境。由于我们已经在第六章**，启动 VSM 计划（VSM 步骤 1-3）中介绍了它如何改善工作空间，因此无需花费太多时间讨论这个话题。5S 系统的目标是创建一个功能齐全且清洁的环境，提升工作环境的效率、效果和安全性。

5S 系统的一个核心要素是，它提供了一个持续的机制来观察并解决可能妨碍流动、导致延误并掩盖问题的无序和杂乱问题。在精益管理中，我们总是从七大浪费的角度来看待问题：运输、库存、动作、等待、过度加工、过度生产和缺陷。回顾一下，精益的七大浪费在第六章**，启动 VSM 计划——七大致命浪费中已被介绍。

简单回顾一下，以下表格列出了 5S 系统和潜在浪费领域的方法，以及精益的七大浪费：

图 9.3 – 5S 系统的方法和潜在浪费领域

5S 系统按数字列出，因为这些活动的执行往往遵循这一顺序。精益浪费的类型和程度会因组织和每个价值流的不同而有所不同。我们会根据浪费对我们交付价值能力的影响程度，从最高到最低的顺序来解决浪费。这里要强调的主要观点是，5S 系统帮助 VSM 团队、价值流操作员及其他相关方消除任何妨碍精益生产过程的浪费。如果你需要进一步复习 5S 技术，请参考第六章，启动 VSM 计划（VSM 步骤 1-3）。

现在，让我们进入评估如何提升满足客户需求能力的最后一个工作领域。在接下来的部分中，你将学习如何利用问题解决方法来改善价值流的表现，以便更好地满足客户需求。

解决需求相关的问题

由于客户需求常常随着时间变化，无论是数量还是产品需求，需求相关的问题始终是价值流操作员和经理必须解决的持续性问题。从客户的角度来看，需求相关的问题通常在于：下订单困难，或者无法获得他们所需的功能和特性，质量不可接受，或者交货日期超出了他们愿意等待的时间。

VSM 团队可以使用多种问题解决模型来解决客户需求问题。我喜欢的一个模型是由爱荷华大学人力资源部发布的。让我们来看一下它。

以下是8 步问题解决过程：

步骤 1 – 定义问题

要理解这种方法，你必须思考以下问题：

• 问题是什么？

• 你是如何发现这个问题的？

• 这个问题是从什么时候开始的？这个问题已经持续多久了？

• 是否有足够的数据来控制问题，并防止其传递到下一个过程步骤？如果有，控制问题。

步骤 2 – 澄清问题

在尝试解决问题之前，我们需要确保真正理解问题的范围。我们可以通过提问以下问题来避免这个问题：

• 有哪些数据是可用的，或者需要哪些数据来帮助澄清或全面理解问题？

• 此时，解决这个问题是否是最优先的任务？

• 是否需要额外的资源来澄清问题？如果需要，将问题上报给领导，帮助找到合适的资源并组建团队。

• 考虑进行一次精益活动（Do-it、Burst、RPI 或项目）。

• 确保问题已经得到控制，不会传递到下一个过程步骤。

步骤 3 – 确定目标

在软件开发中，我们总是想知道新特性或功能必须交付哪些能力，以满足客户的需求。在敏捷中，我们称之为完成定义。在解决需求相关问题时，同样的概念也适用。我们需要定义目标，以明确未来状态的改进目标：

• 你的最终目标或期望的未来状态是什么？

• 如果解决了这个问题，你将达成什么目标？

• 解决此问题的期望时间表是什么？

步骤 4 – 确定问题的根本原因

我们不能只关注症状，而忽视解决我们需要解决问题的根本原因。关注解决症状就像是服用阿司匹林来缓解头痛——它提供了暂时的缓解，但因为我们没有解决其根本原因，头痛最终还是会回来。以下列表提供了寻找与客户需求相关问题根本原因的策略：

• 确定问题的可能原因。

• 优先考虑可能的问题根本原因。

• 有哪些信息或数据可以验证根本原因？

步骤 5 – 制定行动计划

通常，与客户需求相关的问题很复杂，需要许多活动和人员的参与才能妥善解决。在这种情况下，VSM 团队应制定一个行动计划，明确所需的活动、时间框架以及角色和职责，具体内容如下：

• 列出解决根本原因并防止问题反复发生所需的行动。

• 为每个行动分配负责人和时间表。

• 设置状态以确保完成。

步骤 6 – 执行行动计划

当然，制定行动计划和执行行动计划是两回事。必须有专人负责确保工作按时完成并达到满意标准。与精益和敏捷实践一致，价值流映射（VSM）团队可以审查进度和结果，但必须有专人跟踪并引导工作，如以下列表所示：

• 执行行动计划以解决根本原因。

• 维护并显示进度的可视化图表。

• 验证所有行动项是否完成。

第 7 步 – 评估结果

这一步验证了第 3 步中列出的目标是否达成，并总结了行动中的经验教训。首先，我们需要确保在离开某项活动之前已完成我们的行动项目标。但我们也不希望重新发明轮子，如果我们过去已经进行过类似的发现和分析工作。事实上，如果我们保持关注并维护准确的历史记录，我们可能已经有了解决当前问题的方案。以下清单列出了评估我们的发现和结果的活动：

• 监控并收集数据。

• 您是否达到了第 3 步中定义的目标？如果没有，请重复 8 步流程。

• 是否有任何无法预见的后果？

• 如果问题已经解决，删除之前为控制问题而增加的活动。

第 8 步 – 持续改进

最后一步有助于捕捉并解决任何未完成的事项。例如，我们是否有足够的数据来完全解决客户需求问题？我们能做得更好吗？如果能，我们该如何改进？第 8 步包括以下活动：

• 寻找额外的机会来实施更好的解决方案。

• 确保问题不会再发生，并沟通经验教训。

• 如有必要，重复 8 步问题解决过程以推动进一步改进。

欲了解更多信息，请参考爱荷华大学人力资源，组织效能：

https://hr.uiowa.edu/development/organizational-development/lean/8-step-problem-solving-process

绘制客户需求图

现在我们拥有足够的信息来制定未来状态图，这将帮助我们改进满足客户需求的能力。需求阶段的未来状态图使用相同的 VA 映射符号，但映射过程不同。以下清单描述了绘制未来状态需求阶段图所需的步骤顺序：

1. 在白板、海报板或电子系统上开始绘制新的未来状态客户需求图，同时使用 VSM 故事板作为指导。

2. 从在白板顶部绘制客户和供应商（如果供应商与客户不同）开始。

3. 记录客户需求和需求履行要求，以 Takt 时间和节拍为单位。

4. 将最后一项活动（即最下游的活动）放置在绘图区域的最右边。

5. 在白板的左侧绘制启动客户请求或需求的上游流程。

6. 在客户和供应商之间绘制一个手动或电子通讯链接。

7. 用适当的 VA 符号绘制缓冲区和安全库存。

8. 绘制价值流操作员需要实施 5S 系统以进行改进的位置。使用 Kaizen Burst 图标，代表改进活动。

9. 确定需要实施问题解决项目的地方。（使用 Kaizen 爆发图标表示。）

下图展示了客户需求阶段改进的未来状态图，这可能就是你未来的 IT 价值流：

图 9.4 – IT 价值流未来状态图 – 需求阶段

未来状态图上的数字表示之前列表中标注的映射步骤。在我们的示例中，VSM 团队已决定集中关注三个关键领域，以提高 IT 价值流对客户需求的响应能力。第一个计划的 Kaizen 爆发使用 5S 系统来发现可以改善流程和消除浪费的低垂果实。第二个改进活动是帮助引导开发团队在软件开发和测试工具上的集成工作，使其能够实施更有效的 CI/CD 工具链。他们计划的最后一个 Kaizen 爆发是使用问题解决技巧来帮助开发团队实施看板系统。这一策略能够更快速地响应来自客户的请求。

本节完成了我们对未来状态客户需求映射的讨论。在进入未来状态客户流动阶段之前，让我们回顾一下在需求阶段使用的工具。

未来状态 – 客户需求工具

在未来状态映射的这一阶段使用的工具帮助 VSM 团队改善价值流对客户需求变化的响应。我们首先计算了 Takt 时间，涵盖了不同客户和产品之间的变化，以及假期或其他季节性调整的变化。

接下来，VSM 团队为价值流设定了 pitch，它计算 Takt 时间与工作单位数量的乘积。Pitch 的目标是确定通过我们的价值流传递工作项时最合适的批量大小。

接下来，你学会了如何结合 缓冲库存和安全库存 来确保需求和流量波动不会使价值流陷入瓶颈，并防止其无法进行增值工作。你还学会了如何利用成品超市来强制实施拉动式生产控制策略，覆盖整个价值流，甚至是你的价值交付链。

另一个改善价值流对客户需求变化响应能力的关键工具是 5S 系统。价值流操作员使用 5S 系统清除杂乱，组织工作区域以改善工作流和效率，并普遍提高操作员的健康与安全。此外，5S 系统帮助价值流团队评估并消除浪费源。

在这一阶段，VSM 团队开始评估妨碍价值流响应变化的客户需求的问题，并分析每个问题的原因及其影响。在这一部分，您学习了如何使用8 步问题解决过程来解决与需求相关的问题。

最终，您开始开发未来状态地图，以可视化显示价值流的预期变化，同时更新了 Takt 时间和节拍的数据。VSM 团队将未来状态地图绘制在一个大白板或海报板上，或使用任何能够在大屏幕上显示的电子工具。理想情况下，VSM 团队应该使用 VSM 故事板格式（见附录 B），将所有关键信息集中在一个地方。

本节总结了我们关于绘制未来状态地图以改进以满足客户需求的讨论。接下来，我们将学习如何开发未来状态，以便我们可以分析并展示改进，以实现并维持价值流中的连续流。

第二阶段——连续流

现在，VSM 团队已经解决了客户需求的问题，他们可以开始着手改进生产流，以满足客户的需求。在这一部分，我们将继续进行未来状态映射活动，并解决与建立和维持精益连续流相关的问题。

连续流是一种精益策略，旨在实现将单个工作项通过价值流中的每个步骤，而不是将大量工作项作为批次集合并一起移动的理想目标（也称为一次制作，一次移动；单件流；单件生产流）。其目标是尽可能连续地生产和移动一个工作项，或者至少是最小的实际工作项数量，通过一系列的价值流活动。作为基于拉动的生产控制策略的一部分，每个活动只生产满足下一个活动请求所需的内容。

促成精益连续流的是价值流的机制，确保其内部和外部客户在正确的时间、正确的数量收到正确的工作单元。我们最初将精力集中于改善单个工作活动，而忽略了价值流系统中的其他活动并不罕见。不可避免地，这种局限性的关注会导致整体工作流的问题。相反，我们需要从系统思维的角度来审视我们的价值流。

在这一部分，您将学习如何通过不同的方法改善价值流中的连续流。

评估价值流作为一个复杂的系统

组织通常专注于单个活动的改进，因为改进工作交给了在该活动中有深厚技能的专家或工程师。从某种程度上来说，这些技能对于改进活动是必需的。但无法仅仅通过计算单个活动的吞吐量来理解它对整体系统的影响——回想一下我们在第三章中关于分析复杂系统交互的讨论。

我们需要从系统的角度来看待我们的价值流，而不是将每个活动独立地看待，以便理解和控制阻碍工作、物料和信息在价值流中流动的机制。在价值流的各项活动中，客户订单、周期时间、批量或批次大小、设置时间以及零件更换时间的差异都会阻碍连续流动。

VSM 团队必须将价值流视为一个复杂的集成系统，来解决这些问题。他们的任务是确定如何以最有效的方式控制价值流中的工作流动。他们必须评估机制，以平衡工作流，使得需求增加时不会使系统陷入困境，而需求较低时也不会让系统处于停滞状态。

他们还需要与价值流操作员合作，实施标准化的工作流程。这有助于消除阻碍流动的差异，并减少生产力和质量一致性的波动。在许多情况下，VSM 团队需要设计更高效的设施和工作站布局，并获得执行管理层的资金和批准，以便进行所需的变更。

应用连续流的概念

从概念层面来看，连续流的理想状态是每次客户从我们的成品库存中取走一个工作项时，就补充一个工作项。如下面的图示所示，这一概念有时被称为一个生产，一个移动：

图 9.5 – 连续流 – "一个生产，一个移动"

价值流通过在多个活动之间同步进行中的工作，以继续补货活动，如前面的图示所示。换句话说，补货过程必须在所有上游活动中以协调和同步的方式继续进行。

前面的图示使用了弯曲的物理拉动箭头，而不是直线的推动箭头，表示该价值流采用了拉动导向的生产控制系统。拉动导向的生产调度方法控制着上游活动的协调方式，以实现同步和连续的流动。

连续流的速度是另一个问题。只要一切都能一起流动，流速是每 5 分钟一次还是每 5 小时一次并不重要。如果每个活动都只有一个部件流过，还是 10 个部件作为一个批次一起流过也不重要。只要部件和材料的流动是同步的，并且它们能以相同的速度一起移动，你就有了连续流。

在未来的连续流状态中，我们最关心的是提高价值流的整体效率，即提高吞吐量和减少瓶颈（即消除不匹配的生产速率、工作项排队和等待）。因此，流动的改进始终来自于消除各种形式的浪费。

评估流动的障碍

大多数 VSM 团队不能期望一蹴而就地做出大规模变革。这曾是业务流程再造（BPR）的初衷。但很少有组织能够承受一次性做出激进变革所带来的投资和干扰。相反，大多数公司通过根据成本效益评估识别的改进机会，逐步进行变革，从而获得更好的结果。

虽然通过未来状态的价值流改进计划可以一次性实施激进的变革，但这并不推荐，原因与 BPR 不再流行相同。除非组织面临燃烧平台的生死存亡局面，否则更好的选择是通过逐步改进来实现变革。

事实

燃烧平台这个术语来源于 1988 年 7 月 6 日发生在北海派珀·阿尔法石油平台上的一起可怕事故。该油平台发生爆炸，造成了大规模火灾，夺走了 167 条生命。然而，三名最初将自己锁在远离火灾的房间里的人，最终走到了外面，面临着跳入冰冷海水还是被火焰吞噬的选择。两名男子跳了下去，虽然受了重伤，但设法幸存并被救起。不幸的是，第三名待在燃烧平台上的男子未能幸免。

在这种情况下，VSM 团队评估最具影响力的机会，消除浪费和实施成本，并据此优先考虑变更计划。遵循帕累托原则，那些能显著改善流动和投资回报的变更计划应始终具有最高的实施优先级。

VSM 团队通过回答一系列问题来评估价值流中的流动，如下所示：

• 哪些价值流活动、设备和系统需要连接，以获得同步和连续的流动？

• 现有的价值流活动能支持单件流吗？

• 如果不能，什么是最优的批量大小，直到我们能够更好地优化流动？

• 哪些工作单元或活动充当瓶颈？为什么？（即，较长的周期、设置和转换时间、批量处理、过度移动或运输时间等。）

• 解决已识别瓶颈的优先顺序是什么？

• 我们可以在导致瓶颈的工作单元或活动中做些什么？

• 我们可以做些什么来减少导致瓶颈的延迟？

• 我们如何改善设施布局以提高工作流效率？

• 我们如何改善信息系统以提高信息流动？

• 我们可以采取哪些措施来改善内部物料流动？

• 我们必须与供应链合作伙伴做出哪些过程和合同变更，以更好地对接进货材料和零部件与客户的需求？

• 我们如何控制上游工作，以便它与下游需求相匹配并同步？

• 我们能否使用看板系统，并且需要做哪些改变来支持看板系统？

• 价值流是否应采用先进先出（FIFO）生产控制策略？

• 如果有的话，我们是否需要设置过程中的超市、缓冲区和安全库存，以应对客户需求的变化或供应商交货周期长的问题？

• 还有哪些问题影响我们支持持续流动的能力？

上述问题引导 VSM 团队、VS 操作员和其他利益相关者通过发现过程，找出价值流中持续流动的障碍。每个障碍都指向一个改进机会，并在未来状态图上标记为 Kaizen 突发点。与产品待办事项列表完善的过程类似，VSM 团队对改进活动的列表进行完善，定义和优先排序以完成改善流动所需的工作任务。

请注意，前面的列表包括三种生产控制策略（即看板、FIFO 和超市），这些策略可以帮助我们在价值流中保持持续流动。让我们花点时间在这个背景下回顾一下它们。

实施生产控制策略

我们的价值流工作流控制策略必须支持持续流动。我们在前面几节介绍了三种工作流控制方法，VSM 团队可以选择在单一价值流中使用这三种策略。这些工作流策略如下：

• 超市：这是一种基于拉动的工作流策略，通过允许下游客户从有限的工作项目缓冲区中拉取物品来帮助执行 JIT 规则。当库存低于预定的下限时，上游活动会补充这些库存。

看板或其他控制机制可以防止操作员将工作推进到下游活动中，这在软件开发场景中尤为重要。相反，精益敏捷团队从 Sprint 或产品待办事项中拉取工作到工作站，但只有在完成前一个任务并且有能力承担新工作时。

在 CI/CD 和 DevOps 流水线中，集成和自动化工具链将各项活动链接起来，以提高流动速率并实施面向拉动的生产控制编排，从而最小化在制品（WIP）。

• FIFO：此规则要求队列中的第一个物品在工作顺序中始终具有最高的工作优先级。FIFO 工作流策略在延误可能导致工作项质量下降或无法完成独特客户订单时非常有用。

• 看板：这是一种纯粹的拉动式工作流，利用信号指示价值流活动中的工作需求。这些信号以卡片、便签、标志、电子信号或文件夹的形式显示。这些工作项可以独立流动或成批流动，通常存储在一个与批次一起移动的储物箱中。

看板信号告诉每个下游活动应生产什么以及数量。在制造业价值流中，看板卡可能包括以下所有或部分信息：

• 部件/物品编号和部件/物品描述

• 用于提取额外订单、车间工艺信息和图纸的条形码

• 所需的物品或零件数量

• 看板箱或盒子的容量

• 起源（下游）和后续（上游）活动名称或位置——用于没有顺序流的工作车间情况

• 材料或零部件供应商

• 安全库存的位置和数量

• 补货触发点和数量

• 交货期（即，物品到期前的持续时间）

• 负责人

• 订单和到期日期

• 其他重要信息

在面向 IT 的价值流中，看板卡通常列出用户故事及其接受标准。如果看板卡来源于操作，卡片应包括一个工单号、问题描述（缺陷或漏洞）、问题日期以及报告人的信息。

最后，看板卡还应包括在开发或测试过程中发现的任何问题或漏洞（也称为阻塞因素），这些问题或漏洞会妨碍工作进行。

加权最短作业优先（WSJF）：这一排队模型在精益敏捷社区，特别是在 SAFE 实践者中得到了广泛认可。该方法最初由 Don Reinertsen 在其著作《产品开发流的原则》中定义（Reinertsen, 2009）。

WSJF 优先级模型用于对工作进行排序（例如，功能、能力和史诗），以产生最大经济效益。在 SAFe 中，WSJF 通过延迟成本（CoD）除以工作规模来估算。

例如，假设我们的产品待办事项中有三个工作项，产品负责人需要一种方法来评估这些工作项在即将到来的开发迭代中的优先级。下表列出了各个工作项的预计持续时间（作为交货期，单位为周），延误造成的收入损失成本，以及每个工作项的调整权重：

图 9.6 – 加权最短作业优先 (WSJF) 示例

上表显示，每延迟一周发布功能 A 将给组织带来 $10,000/周的损失，而功能 B 的成本为 $100,000/周，功能 C 的成本为 $150,000/周。如果我们的 CoD 和持续时间估算相对准确，那么功能 C 应该是最高优先级，其次是 B，最后是 A。

除了管理工作项在价值流系统中的流动外，我们还需要平衡流动，以保持持续流动。这个话题将在下一个小节的产线平衡中讨论。

平衡我们的价值流

如果前序价值流活动中没有可拉取的工作项，那么实施基于拉动的生产控制系统几乎没有价值。我们需要引入产线平衡技术，以防止上游活动的饥饿现象。为此，我们必须优化在价值流中进行中的工作分配，使其与我们的 Takt 时间匹配。

在一个完全自动化的系统中，产线平衡是系统设计的一部分。例如，汽车在装配线上的推进是通过传送带连接的，因此所有的作业都以相同的速度同时进行。然而，许多开发和运营导向的价值流中的工作站并未集成，也未自动化。此外，操作员可能会在工作站和设备之间移动，以支持跨价值流的多个工作活动。

产线平衡是一种优化价值流中人员利用率的策略。目标是确保操作员不会过度负担或未被充分利用。VSM 团队使用以下公式来确定在价值流中的任何给定活动所需的工人人数：

所需工人人数=总处理周期时间/Takt 时间

回想一下，在图 9.1 中，我们的 IT 价值流的 Takt 时间为每个工作项 7 小时。VSM 团队已经识别出我们 IT 价值流中每个活动的总周期时间，如下表所示。所以，我们有了所需的数据，可以确定支持 IT 价值流的开发团队成员数量。

以下表格使用之前识别出的产线平衡公式来计算支持整个 IT 价值流所需的工人人数：

图 9.7 – 产线平衡公式用于确定所需操作员的数量

我们的总增值时间是对 IT 价值流活动中所有周期时间的度量。而增值时间（周期时间）是处理一个工作项所需的度量。由于开发团队是一个基于 Scrum 的敏捷团队，我们必须通过六倍的系数来调整 Takt 时间，以便考虑生产六个工作项所需的总时间，这个时间是 42 小时，这也是我们对该价值流的预估。

因此，VSM 团队得出结论，他们需要 7.8 名开发团队成员来支持 IT 价值流。但是，事情从来不会这么简单。一方面，开发团队成员在精化、计划和发布过程中同时处理整个六个工作项，但在编码、构建、测试、合并和提供过程中是独立进行的。

下表显示了为调整小时数以匹配工作项吞吐量所做的批量大小调整，然后计算每个 IT 价值流活动所需的工作人员数量：

图 9.8 – 为计算所需工作人员数量而调整的每个工作项的周期时间

下表重新评估了与调整后的总增值时间 90.5 小时相对应的工作人员数量。调整后的 90.5 小时的 TVA 除以我们原始的 Takt 时间 7 小时，表明 IT 价值流需要 12.9 名工作人员来支持这一负荷：

图 9.9 – TVA 和劳动调整

然而，让我们回过头来看图 9.7。应该显而易见的是，各个价值流活动中的劳动水平差异显著，从 0.4 名工人到 3.4 名工人不等。如果我们试图通过单件流操作这个价值流，就会遇到资源分配问题。

为了继续我们的评估，让我们将与开发相关的活动与与发布相关的活动区分开来。组织中的其他人员通常执行发布相关的活动，而开发团队中的一部分成员则在每个 Sprint 迭代前作为一个小组进行精化活动。

VSM 团队创建了当前状态工作者平衡图，以开始评估开发流，如下图所示。该图表明，如果我们将资源分配到每个活动，并以 Takt 时间的速率工作，那么所有工人都会有很多浪费时间在等待新的工作，除了那些专门从事测试的工人。这是因为测试人员在每个工作项的 Takt 时间（每个工作项 7 小时）内没有足够的时间来进行测试：

图 9.10 – 当前状态工作者平衡图

应该很明显，你不需要为每项活动专门分配一个工作人员。敏捷的核心思想是建立跨职能和自给自足的团队，让所有开发团队成员能够执行软件交付价值流中的大部分（如果不是全部的话）任务：

图 9.11 – 未来状态工人平衡图

如我们所见，通过任务组合，有三个逻辑区域可以拆分工作。在团队内部，一人或多人可以负责计划、编码、构建和合并等活动。与此同时，其他人员负责配置服务器并设置、运行、分析和分发测试结果。

请注意，软件测试可以以无人值守自动化的方式运行。一旦测试设置完成并启动，测试便会以自动化的方式运行，而无需人工干预。看管计算机并不增加价值，这也是为什么测试自动化如此重要的原因之一。

稳定工作实践

本节讨论了一个主题——创建标准化实践——一些 IT 专业人员可能会对这个话题有所质疑。初看之下，实施标准化工作实践可能看起来限制性较强，特别是对于那些认为软件开发既是一门艺术又是一门科学的人来说。然而，正如本书后续所示，成熟的 DevOps 管道——一个集成并自动化软件开发生命周期（SDLC）实践的管道——只有在我们拥有标准化流程时才能发挥作用。

标准化工作是一套公认的工作程序，旨在确定完成每个定义的价值流过程的最佳当前方法和活动顺序。换句话说，标准化实践实施的是在价值流中执行工作的最佳、最简单、最安全和最快的方式。

请注意，精益中的标准化工作概念似乎与敏捷倡导的理想有所偏离，在敏捷中，团队通常可以自由地尝试新的工作方式。精益的重点是消除浪费并改善持续流动，而敏捷的重点则是适应性强，并支持在每个新产品发布之前将需求转化为可操作的架构和设计的创造性方面。

问题实际上是创新与生产之间的界限问题。创新通常是一个创造性的过程，也被称为模糊前端，它很难界定范围。相比之下，生产开发过程在标准化时能够最好地发挥作用，从而实现最佳的价值交付。

模糊前端（FFE）

模糊前端这一术语描述了每个新产品或功能开发生命周期中的“创新阶段”。具体来说，模糊前端包括创建新产品或功能的初始阶段，在这个阶段，机会被识别，架构和设计概念被发展，并且构建和交付策略在进入产品开发阶段之前得以演化。模糊前端现象在精益和敏捷开发场景中都存在。

一旦软件开发进入生产阶段，就没有必要对那些各个活动存在如此大变动，以至于无法控制工作流或消除缺陷和错误的集成过程进行自动化。实现 CI/CD 或 DevOps 管道的核心目的是改善工作和信息流，以提高价值交付。而我们无法在没有标准化流程和活动的情况下改善这些流动。

VSM 团队需要与工程师、领域专家和操作员一起，首先解决这些问题。之后，我们可以利用技术帮助集成和自动化底层活动。

VSM 团队可能会发现，使用以下图片中展示的标准工作组合时间表来记录在 Gemba 走动过程中收集的信息非常有用。该工作表提供了记录跨越价值流中关联工作流步骤的行。换句话说，操作员必须在开始处理另一个工作项或“批次”工作项之前，完成所有这些步骤。VSM 团队记录完成每项任务所需的时间，并说明该工作是手动任务、自动化任务，还是与搬运或运输相关的任务。

在我们的示例中，VSM 团队确定了以下九个高级步骤（活动），这些步骤定义了软件开发团队的 CI/CD 管道流程。团队按执行顺序列出了这些活动：

需求分析：定义用户故事及其验收标准。

功能设计：确定软件功能实现需求和开发测试。

编写测试脚本：作为测试驱动开发（TDD）实践的一部分，开发必要的测试，以证明代码符合需求。

开发代码：根据接受标准创建实现所需功能的源代码。

单元测试：在进行集成测试之前，对每个代码段进行测试，确保它们符合用户故事和验收标准中规定的要求。

合并代码：在单元测试通过后，将源代码与源代码控制仓库中的主干代码进行集成。确保集成过程中没有错误。

配置预生产服务器：执行基础设施即代码（IaC）配置指令，自动化搭建预生产服务器的测试环境。

启动预生产测试：在预生产测试环境中执行自动化测试，测试内容如产品测试计划中所定义的：

图 9.12 – 标准工作组合时间表

该标准工作表还提供了显示工作随时间流动的空间。一个垂直线显示了工作项的 Takt 时间，展示了与工作流相关的整体时间。当整体工作流时间超过 Takt 时间时，我们就知道这个价值流段无法按当前设计满足客户订单需求。

这里展示的标准化工作组合时间表示例记录了 IT 价值流开发工作中与工作项相关的所有任务。该工作表告诉我们，在与客户需求相关的 Takt 时间内，无法将一个工作项完成所有的开发和测试任务。我们可以通过实施 CI/CD 工具链和 DevOps 流水线，集成和自动化 SDLC 流程，评估解决这些问题的方法。

这一概念本质上就是现代 CI/CD 和 DevOps 工具链和流水线的核心——消除系统开发和运营活动中的变异。在敏捷和精益实践中，团队通过员工的创造力，利用其产品交付技能和 Kaizen（改善）或回顾会议，持续改进标准化流程。Kaizen 的目标是做出能减少风险的改进，而不是增加风险。

总结一下，标准化工作做了以下几件事：

通过我们收集的信息来完成标准化工作组合时间表，VSM 团队可以开始评估消除浪费和改善流程的方法。一种常见的浪费形式是运动；也就是说，工作活动和工作站的布局相隔太远，以至于我们增加了非增值时间和资源，仅仅是在人与物料之间移动。这一部分中，你将学习如何改善工作区域，以消除因过度运动造成的浪费。

改变工作布局

无论你的 VSM 团队是在与价值流合作，构建实物产品、软件产品，还是支持行政运营，设施布局对改善流程至关重要。关键问题是消除过度运输和移动带来的浪费。这些问题通常来源于低效的设施布局，或是将部门、业务职能或操作分布在不同的地点或地区。

VSM 团队需要与高层管理合作，获得资金和批准，重新布置价值流活动，并改变其布局，以实现精益生产流程。在第三章**，《分析复杂系统交互》中，你学到，精益流程的最佳表现形式是以图示的方式呈现工作过程的线性顺序流。然而，在实际的物理工作环境中，线性顺序流可能并不是最好的选择。

相反，通常更好的做法是让工作流程回绕，以减少与操作员过度运输材料和在价值流中移动相关的浪费。因此，一个设施中的最佳流动可能具有U、C或L形状的工作区域，如下图所示：

图 9.13 – 设施布局设计

当 VSM 团队评估替代布局时，他们需要叠加工作流。这是下一小节的主题。

显示标准化工作

当 VSM 团队致力于改善标准化工作方法和流程时，所有在价值流中工作的人员必须理解如何在多个活动中执行工作。这种策略提供了在所有活动中保持流程所需的最大灵活性。

组织可能采用详细文档或车间流程来描述开发和面向操作的价值流中的工作。在许多情况下，所有操作员需要的只是一个简单的标准化工作任务视觉提醒。标准化工作图表就是这种展示的一个例子，如下所示：

图 9.14 – 标准化工作图表

此时，VSM 团队已经分析了可以改善客户流动的工作元素。现在，让我们继续开发价值流的连续流动未来状态图。

绘制连续流动阶段图

在 VSM 团队开始绘制连续流动的未来状态图之前，他们应该回顾分析工作：

1. 首先，团队必须回顾当前状态图和需求阶段图。

2. 然后，VSM 团队成员必须回顾流动问题，以及他们在 Gemba 走访中获得的信息，来回答这些问题。

3. 接下来，如果他们还没有这样做，VSM 团队成员必须绘制当前和未来状态的工人平衡图。

4. 最后，他们必须回顾我们在图 7.1中识别的价值流符号。

与之前的图表一样，有一系列推荐的活动顺序，有助于生成未来状态——连续流动图，如下所示：

1. 使用需求阶段图作为起点。

2. 使用标准工作时间表和标准化工作图表作为指导，在地图上按照正确的顺序绘制工作位置。

3. 在 VSM 故事板中（参见附录 B），输入在地图上工作区域提议的周期时间中工人的数量。

4. 在适当的工作区域位置输入所有已识别的属性。

5. 确定支持连续流动的任务。

6. 在地图上标明开始拉动式生产控制策略的位置。

7. 如果需要，显示超市库存的放置位置。

8. 显示 FIFO 工作流程发生的地方。

9. 确定需要 Kanban 信号的位置。

10. 确定其他需要改进的活动，以优化流程（例如，Kaizen Burst 图标）。

11. 在地图上显示所有必要的通信链接。

当 VSM 团队开始绘制未来状态持续流图时，他们需要牢记以下几点：

• 实施持续流意味着排队和等待被消除。

• 评估工作区设计并提出变更建议。

• 团队需要高层批准和资金支持，以进行重大更改。

• 精益生产控制拉动上游工作，以确保与客户需求同步。

• 传达所有变更建议的原因和益处。

以下图表展示了 VSM 团队提出的未来状态图，展示了跨 IT 价值流的持续流改进：

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/drv-dop-val-st-mgt/img/B17087_09_15.jpg)

图 9.15 – IT 价值流中持续流改进的未来状态图

在审查未来状态图时，注意地图现在如何显示以下多个通信链接：

• 积压改进。

• 为每个用户故事创建完成定义。

• 开发过程中，开发团队获取需求澄清。

• 传达自动化测试的测试结果。

• 将代码进出源代码管理库。

• 传达用于配置的服务器配置。

VSM 团队还识别了四个新的改进计划，这些计划通过 Kaizen Burst 图标标识，用于在两个位置实施看板信号，作为与产品和冲刺待办事项相关的看板拉取：

• 开发团队设施的新设计

• 看板信号和可视化生产控制系统

• 开发和测试之间的 FIFO 生产控制策略

• 实施测试自动化功能，使测试能够在“灯熄”状态下进行操作。

最后，注意我们已将单独的开发步骤替换为两个活动领域——一个用于开发，另一个用于测试。技术上，还有一个与配置相关的第三个领域——数据中心。然而，所有与数据中心的交互都通过电子通信进行，以帮助通过代码实现基础设施更改。这也被称为基础设施即代码 (IaC)。

发布过程与开发过程分开，因为这些活动不属于 IT 开发流域。这并不是说开发团队成员不参与发布活动。VSM 团队决定稍后在一个单独的映射练习中审查这些活动。

本节完成了未来状态——持续流改进映射部分。在我们完全离开这一节之前，让我们快速回顾一下本节使用的工具。

未来状态 – 持续流工具

在本节中，你学会了提出几个问题，帮助 VSM 团队评估价值流中的持续流动状态。然后，你了解了使用拉动式生产控制策略来管理持续流动的重要性。三种拉动式生产控制策略包括使用超市库存、FIFO 工作流和基于看板的信号传递。

你了解了建立标准化工作的重要性，作为实现价值流活动集成和自动化的前奏。用于评估工作活动的两种主要工具是标准化工作时间表和标准化工作图表。

改善工作和物料流动的另一个重要考虑因素是设施的设计和布局。精益流程可以实施线性顺序流动，最大限度地减少与运动和移动相关的浪费。然而，在许多情况下，重新引导线性顺序流动使其回到前端是有意义的，例如通过“U”形或“C”形单元，或者通过“L”形工作单元将其引导到一侧。

在许多价值流中，操作员最有效的时间利用方式是能够在工作单元或设备之间移动。为了以这种方式利用我们的人力资源，他们必须在多个（如果不是所有的话）价值流活动中接受交叉培训。此外，U 形和 C 形单元提供了较少的工作位置之间的移动。

在本节中，你还学习了如何使用工人平衡图来平衡操作员在价值流活动中的利用率。

最后，正如我们在整个价值流管理章节中所做的那样，你学习了如何更新 VSM 故事板，以展示管理持续流动改进的未来状态变化。你还在本练习中使用了几个流阶段符号（图标）。

本节完成了我们关于制定未来状态图以评估价值流中持续流动改进领域的讨论。现在，我们将继续学习如何使用未来状态图来改善工作平衡。这使我们能够高效地利用价值流资源，同时满足客户需求。

第三阶段 – 工作平衡

到此为止，VSM 团队已经进行了多次 Gemba 走访，收集了用于价值流映射练习的信息。他们已经建立了当前状态图和未来状态图，以指导满足客户需求和实施持续流动的改进。最后，他们将构建的未来状态图帮助指导生产平衡方面的改进。

工作平衡是一种策略，用于分配支持客户需求所需的工作量。我们的目标是以 Takt 时间的节奏持续向价值流输入新的客户订单，以便在等待新订单到达时不会浪费生产时间，并且避免在其他时间价值流中存在超过其承载能力的工作量。

在理想状态下，生产平准化旨在以 Takt 时间的速率持续生产相同数量的物品。不幸的是，客户订单往往不会以连续流的方式到达。它们可能是批量到达的，每个客户请求的物品数量也会有所不同。因此，我们必须实施策略来平衡需求曲线，使其与我们的价值流的生产速率相匹配。

所使用的时间增量取决于与我们产品相关的总增值和总交货时间。在某些情况下，我们可以在小时、天或周之间进行工作平准化。然而，如果我们在建造大型建筑、飞机或船只时，我们可能需要跨月甚至跨年进行工作平准化。

通过类比平准化流

通过类比，你可以将尝试通过软管流水的过程进行思考。假设我们有一条花园软管，可以在任何给定时刻容纳 1 加仑的水。如果我们试图一次性流动 10 加仑水，软管的大小限制了水流，且软管一次只能容纳 1 加仑的水。

除非我们有一个非常灵活的软管，能够让水在管道中膨胀流动，否则 10 加仑的水只能以软管能承受而不爆裂的速度逐渐通过软管；也就是说，1 加仑水通过软管从一端流到另一端的速度。

同样，如果我们将软管分成八个相等的部分，每个部分在任何时刻都将包含正好 1/8 加仑的水。为了完成我们的类比，水必须从软管的最后一部分流出，才能使上游部分的水流入相连的下游部分。精益价值流恰恰是以这种方式操作的，作为连续且均匀的流动。

我们使用 流水线 这个术语来指代我们价值流中的流动。作为示例，下面的图示显示了 DevOps 流程作为跨越八个主要活动的线性顺序工作流：

图 9.16 – DevOps 流水线作为线性顺序过程展示

当然，在现实生活中，监控活动会获取已经反馈给开发团队的信息，作为未来规划活动的输入。因此，DevOps 流水线通常以一个无限循环的形式展示，如此处所示：

图 9.17 – DevOps 流水线展示为一个无限循环

两种图形模型都不理想，因为新的需求来自多个来源。我们将在平准化生产流部分讨论这个问题。在我们进入那个话题之前，先看看 VSM 团队在 VSM 项目这一阶段会问哪些问题。

评估平准化需求

与之前的未来状态映射练习类似，VSM 团队可以提出问题，以帮助评估生产平准化的需求。让我们快速浏览一下这些问题：

• 客户订单是否大致以一个恒定且可预测的速度到达？

• 由于客户需求的变化，价值流的操作员是否会经历高峰和低谷的活动？

• 我们能否将接收的订单进行分组，以平衡需求负荷？

• 我们是否能够充分预测未来的订单，包括数量和类型，从而提前生产？如果可以，我们能够提前多久生产而不带来过大风险？

• 我们能否将订单按批次进行分组，以改善流动？

• 当物料或零件必须流入我们价值流的各个阶段时，我们将如何分发看板卡片，以确保物料能够准确流动并与工作项目同步？

• 我们应该在价值流的哪个环节安排生产/工作需求？

• 我们是否可以使用定速取货或 Heijunka 箱来管理批次流动？

• 我们是否需要使用跑道工来保持物料流动并确保平衡？

• 我们还能使用哪些其他方法和工具来改善生产平衡？

既然我们知道了需要回答的问题，让我们在参考 IT 价值流模型的同时，描述生产平衡背后的概念。

平衡概念

在未来状态映射的这一阶段，我们需要集中精力绘制有助于价值流平衡生产的元素。本阶段解决的问题是客户很少能够可预测地向我们下订单。当订单集中到达时，我们可能没有足够的生产能力来迅速处理它们。而有时，订单可能以较慢的速度到达，这又导致我们的生产能力没有被充分利用，进而导致价值流缺乏工作任务。

生产平衡的目标是将工作分配到不同的时间段，以满足客户需求。在高容量生产环境中，我们可能需要每班次甚至更频繁地平衡流量。另一方面，零售制造商在假日季节的销售量可能大幅增加，这迫使他们提前生产。

VSM 团队会等到这一阶段后期才开始处理生产平衡问题，因为他们需要了解 Takt 时间和最佳节拍，以便让他们的价值流与客户需求相匹配。此外，VSM 团队还需要时间来梳理价值流活动，以最大限度地优化流程。换句话说，通过解决满足客户需求和改善流程的问题，可以在生产力方面获得更大的提升。生产平衡更多的是一种微调工作，而非重大变革。

在我们之前提到的 IT 价值流示例中，我们指出，产品负责人平均每四周会向产品待办事项中添加 20 个新需求。这些需求来自多个来源，包括 IT 部门的运营人员、直接来自客户、行业来源以及产品和市场管理团队。

产品负责人不太可能每天都会收到确切的一个新需求。相反，需求通常是随机且成批到来的，特别是在产品营销团队进行客户访谈和焦点小组会议后。当新需求成批到达时，它们会被添加到产品待办事项列表中，排队等待开发团队开始工作。

在基于 Scrum 的敏捷实践下，开发团队评估他们认为可以在 Sprint 周期内承担并完成的产品待办事项中的工作量。在我们的示例中，团队从产品待办事项列表中提取一批用户故事，作为六个工作项的一批来通过 Sprint。一旦选择了工作项，团队将工作分配给团队成员，团队成员将从头到尾完成每个用户故事的工作。

在理想的世界里，所有开发团队成员都具备在整个 SDLC 过程中完成任务所需的所有技能。但实际情况并非总是如此。此外，根据工作项的复杂性，团队可能会指派多个成员来实现单个用户故事中概述的功能。

这里的 Scrum 团队示例是一种跨 Sprint 的生产平衡方法。这些任务作为一批被接受，并通过 SDLC 流程独立完成。但存在一个问题，因为团队需要在 10 天内完成六个工作项。在同一段 10 天的时间内，产品待办事项列表很可能会收到 10 个新的工作项。换句话说，IT 价值流忽视了每个 2 周 Sprint 期间的四个新客户需求。这不仅代表着丧失的业务，而且还为竞争对手填补了空白。

仅仅进行生产平衡并不能解决这个问题。VSM 团队需要与系统工程师合作，实施 CI/CD 和 DevOps 工具链及管道，以加速工作流程。从长远来看，VSM 团队应与 IT 部门合作，实施符合每个工作项每日完成的 Takt 时间的能力。更快的流动速度提供了应急能力，并在 IT 系统故障时能够弥补丢失的时间。

回到图 9.15，在成熟的 DevOps 管道下，每天会有一个工作项离开管道，其他工作项也以相同的速度在管道中流动。这意味着每天可以有一个新的工作项进入 DevOps 管道。但由于客户需求是随意且经常成批到来的，开发团队仍然需要一个输入缓冲区，即产品待办事项列表，用于存储和管理新需求，直到它们被提炼、优先排序并纳入 IT 价值流。

在 IT 部门实施新的 CI/CD 工具链时，VSM 团队开始制定他们在新开发和测试环境中的生产平衡策略。让我们来看看他们可以用来平衡生产量的方法。

平衡方法

VSM 团队可以探索多种方法来进行生产平衡。在本节中，您将了解用于平衡的 5S 方法，包括 看板、定速提取、平准化箱、视觉控制 和 看板文件夹。

并非所有这些策略都适用于每个价值流。此外，精益敏捷生产具有足够的独特性，推动了相对较新的看板变体的发展，该变体使用便签和白板来平衡跨 Sprint 的流程。我们首先介绍这种调度和平衡方法，即 看板。

看板

产品负责人通常会在 IT 环境中将新的工作项带到开发团队的关注下。每个需求的新工作项指令通常会写在便签卡片上，并放置在白板上的 产品待办事项 列中。便签卡片是看板信号，白板被称为看板。请参阅 图 9.9 – IT 价值流的看板。

然而，最初的需求以业务和用户需求的形式表达，可能定义得过于宽泛，难以形成一组简明的功能性和非功能性能力。开发团队成员与产品负责人合作，将需求细化为独立的小型用户故事，代表能够定义的最小工作单元。

用户故事通常从客户的角度表达需求。以此为参考，用户故事的典型格式如下：

作为（用户类型），我想要（描述期望的功能），以便（原因）。

用户故事还应该定义验收标准，最终指定故事的完成定义。以下格式有助于定义用户故事的验收标准。请注意，每个用户故事可能需要多个验收标准声明来定义所有潜在场景：

假设[某个场景]，当[某件事发生时]，那么[描述期望结果]。

然后，产品负责人与开发团队合作，确定已识别用户故事的优先级。然而，开发团队最终决定每个用户故事所涉及的工作量以及他们可以维持的工作节奏。

这种细化工作发生在每个 Sprint 的规划阶段，输出是 Sprint 目标加上支持实现该目标的已选用户故事。开发团队将每个用户故事的看板卡片移入看板上的 Sprint 待办事项 列中。

用户故事可能需要进一步的澄清，才能让开发团队成员开始开发和测试与每个用户故事相关的功能。一旦用户故事得到充分开发，Kanban 卡片将被移入 Kanban 看板的待办部分。开发团队成员从待办列中拉取 Kanban 卡片并将其放入进行中列，开始开发和测试与该卡片用户故事相关的功能。

一旦开发人员完成工作，他们将 Kanban 卡片移入待验证列。验证过程会有另一双眼睛审查工作，以确保新代码实现了期望的功能，并符合接受标准。一旦验证了新代码的功能，Kanban 卡片将被移入完成列，表示工作符合用户故事的接受标准。

一些团队可能选择在 Kanban 看板上实施额外的列，以更精细地跟踪他们执行的工作。没问题。关键问题是不要追求过于细化的细节，以至于跟踪工作变得过于繁琐。

有节奏的提取

我们之前描述的 Kanban 看板最适合支持在一起工作的团队平衡工作，通常是在同一个房间内。因此，Kanban 看板在软件交付或其他行政或面向运营的价值流类型中非常有用。相反，有节奏的提取生产平衡方法适用于开发实物产品的环境，且工作站和设备分布在大面积区域。

有节奏的提取方法使用人工处理器（也称为跑者）在价值流的活动中移动信息和工作项，遵循价值流的流程顺序。处理器设定价值流的节奏，当它们从一个操作移动到另一个操作时，将部件和信息从一个工作地点移动到另一个工作地点。

以下图示展示了有节奏的提取生产平衡方法：

图 9.18 – 有节奏的提取平衡方法

让我们仔细看看使用上述图示的生产流程平衡是如何工作的：

1. 跑者（处理器）通过从 Heijunka 盒子中取出当前的生产 Kanban 开始一个周期。生产 Kanban 只是一个详细的列表，列出了需要在特定时间完成的所有项目。Heijunka 盒子有槽位，这些槽位对应一天中的特定时间间隔。每个槽位可以容纳一个文件夹，里面包含该时间段内计划的客户订单。

2. 跑者将生产 Kanban 带到最上游的工作区域，交接新的订单。

3. 跑者稍后在活动 2 的地点取走在制品，并将其移到下一个工作区域，进行活动 3\。

4. 当活动位置 3 的工作完成后，跑者将该部分移至活动 4 的工作站。

5. 当跑者到达最下游的活动时，他们将成品移入超市以存放库存，直到产品被客户提取或发货。

6. 在这一点上，操作员接收新的客户订单（即以生产看板信息的形式），并将这些文件移到价值流的平准化盒子中。

这完成了原始周期，操作员重新开始循环。关键是将操作员的周期时间与节拍率匹配。这个策略将生产数量限制为在制品，同时匹配流程以满足客户需求。

你可能会想，为什么要学习适用于构建实物产品的价值流的平准化策略。简短的回答是因为我们都在一个数字经济中运营。IT 团队通常支持制造和其他类型的开发导向价值流的改进，因此 IT 专业人员必须理解精益流程在其他组织价值流中的运作。

例如，IT 部门可能会实施变更，以支持不断变化的客户需求和商业机会，这些变更可能涉及组织的企业资源规划（ERP）或制造需求计划（MRP II）系统。这些现代商业应用有助于集成和自动化涉及库存管理、仓库管理、会计和财务管理、订单管理、调度、采购、运输、客户关系管理（CRM）以及电子商务的业务流程。这些职能在组织内部作为价值流运作，而在这些价值流中的大多数精益改进需要对企业业务系统进行相关的变更。

平准化盒子

如前所述，平准化盒子本质上是一个带槽的柜子，用于存放生产看板文件夹。下图展示了两个平准化盒子的示例：

图 9.19 – 平准化盒子

每个文件夹都包含该批次生产看板项的生产看板指令。平准化盒子中的槽位指示生产物品应在何时生产。

左侧的平准化盒子被划分槽位，以支持两个班次，每个班次之间安排 1 小时的时间段。换句话说，每个槽位包含一个看板文件夹，其中包含生产看板指令，用于在 1 小时节拍内构建所需的工作项批次。

右侧的平准化盒子被划分槽位，以支持一个班次内三种产品类型的生产。调度员正在确定具有多种产品类型的价值流中的生产能力。这决定了在每个槽定时间段内每种类型的物品可以生产多少。

尽管我们提到了作为定速撤回平衡方法一部分的平准化盒（Heijunka box），但平准化盒也可以独立作为一种平衡工具。在这种情况下，平准化盒是一种可视化的工作流控制方法。员工不再像在行政办公室等共同工作空间中那样使用跑者，而是可以直接从盒子中提取工作。

可视化控制

VSM 团队可能会选择实施一个可视化投放板，以指导一天中的生产流动。投放板是一个表格，显示每个操作员在其班次内不同投放时间段的工作分配情况。这是一种有效的机制，适用于面向操作的价值流，用于在行政区域内平衡工作流。

例如，假设一个价值流每小时平均接收到 20 个新工作项请求，且有四个操作员被分配到这些任务上。这种类型的可视化辅助工具适用于开发和面向操作的工作流，所有人都能轻松看到可视化的投放板显示。换句话说，我们不需要跑者，操作员可以直接从生产控制系统中提取他们的生产看板卡。

以下是一个行政部门的可视化投放板示例：

图 9.20 – 可视化投放板 – 订单录入价值流示例

在这个示例中，平均投放量为每小时 19 个客户订单，但最少为 18 个，最多为 20 个客户订单。调度员已分配工作，以确保每位订单录入员每小时的订单量不会过多。

每个操作员的最大订单录入率为每小时五个订单，每个订单录入活动的周期时间为 12 分钟。但在每个 1 小时的时段内，一至两名订单录入员只需要处理四个客户订单，这样他们就有 12 分钟的空闲时间。此外，这些人员还可以进行其他增值任务，例如接听客户电话或处理电子邮件。

分配给个别工人的工作项数量（投放）可以根据他们的技能和可能执行的其他职责而有所不同。同时请注意，投放板仅按工作量分配工作负载，不包括有关所需工作的说明。在这种情况下，员工会收到包含这些说明的彩色看板文件夹。

看板文件夹

看板文件夹包含生产看板信息。它们用于定速撤回系统，或者在独立的平准化盒中使用，或分发给通过可视化的投放板（Visual Pitch Board）接收工作任务通知的团队成员。例如，生产看板包含有关标准化工作绩效和客户订单要求的信息。此外，可能会对看板文件夹进行颜色编码，以表示工作已分配给哪个操作员，或指示正在执行的标准化工作类型。

在定速提取系统中，看板文件夹随着工作流动，并由 Runner 移动。在独立的 Heijunka 箱中，操作员从与他们执行的工作类型和时间段相关的槽位中提取工作。通常，当使用可视化排程板时，本地经理会按标准间隔将看板文件夹直接分配给操作员。这些间隔设定了节奏，而文件夹帮助将工作拆分并分配给操作员。

本节总结了我们关于平准化方法的讨论。在评估并选择适当的平准化方法之后，VSM 团队可以继续绘制未来状态的价值流平准化图。

绘制平准化阶段地图

VSM 团队现在拥有他们所需的信息，以便为平准化阶段绘制未来状态的价值流图。与其他阶段一样，团队通过一系列相关问题来评估平准化机会，如下所示：

• 最优流动的最小工作项组大小是多少？

• 在价值流的工作环境中，哪种类型的看板信号方法有效？（即，看板板、看板卡、看板箱或可视化排程板？）

• 看板卡或文件夹将如何分配？（即，经理分配、Heijunka 箱或 Runner/操作员？）

• 如果适用，哪些类型的平准化箱或可视化辅助工具是必需的？（即，展示已分配给价值流操作员的工作或按部件类型分配的工作？）

• 如果需要使用 Runner，最优的路线和节奏应该是什么，以便平准化流动？

在绘制平准化阶段地图之前，VSM 团队应决定计划使用哪些图标来表示 FIFO、Runner、Heijunka 箱、看板卡、看板文件夹和可视化排程板的生产平准化要求。

VSM 团队在之前评估过的未来状态——连续流动图的基础上，加入了帮助平准化流动所需的元素。在之前的连续流动练习中，VSM 团队评估了使用基于看板的系统来帮助建立更好的产品流动的需求。他们已经精细化了思路，并决定实施带有粘性便签的看板板作为理想的信号传递方式。

下图显示了与实施基于看板板的平准化和粘性便签相关的 Kaizen 冲击：

图 9.21 – 基于看板板的平准化平面图，使用粘性便签的 IT 价值流未来状态图

看板板帮助 IT 价值流管理其流动的节奏，同时在任何给定时刻平准化 WIP。开发人员仍然进行 Sprint 规划会议，以精细化产品待办事项中的用户故事，并与产品负责人合作，以优先处理工作项。

许多选定的项目支持开发客户请求的增强功能。然而，一些用户故事涉及技术债务、安全性以及架构和设计改进。VSM 团队通过在未来状态地图的开发阶段添加看板图标来注释拟议的变更。VSM 团队还添加了关联的 Kaizen 冲击，以表示持续改进活动。

在本章中，我们讨论了如何将以精益为导向的概念作为软件开发实践的叠加层。然而，如果软件开发团队已实施敏捷实践，我们可能需要撤销一些由冲刺积压所实施的批量导向做法。批处理会造成等待和过多在制品的浪费。

如果一个软件开发组织已经围绕 Scrum 实施了敏捷实践，他们可能希望在未来状态映射（future state mapping）活动中调整基于看板的生产调度概念。因此，在我们结束未来状态映射活动之前，让我们花一点时间讨论如何改进敏捷实践，以消除跨冲刺批量处理工作项的负面影响。

消除基于敏捷的批量处理

冲刺积压（Sprint Backlogs）本质上是批量生产过程。敏捷团队从产品积压中提取工作项作为一个“批次”，然后将其放入队列中，直到开发团队成员有时间处理它们。排队处理工作项可能导致过度等待和队列中的在制品（WIP），以及任务切换。这三种做法都是浪费的表现。

一些组织实施看板板来可视化并管理冲刺中的在制品（WIP）。通过这种方式，看板板帮助开发团队在每个冲刺周期内平衡生产流。

然而，敏捷团队实施看板（Kanban）板并不是一种支持优化持续流动的策略示例。团队仍然在跨冲刺（Sprints）中移动工作项，并且批量大于一项。然而，随着 CI/CD 和 DevOps 流水线的实施，工作项可以在价值流中作为单件工作流动。此外，开发团队还可以利用他们的看板板在产品积压（product backlog）级别直接平衡客户需求，只要工作项已被完全细化并且进行了优先级排序。

是的，精益（Lean）可以成为 Scrum 和其他敏捷实践的一部分。但重要的是要理解，使用冲刺作为控制需求流动的机制，就变成了批处理过程，这与精益理念中实现单件流的理想是不一致的。

这是否意味着冲刺和其他基于节奏的开发形式——例如在 SAFe 中的开发方式？简而言之，答案是否定的。冲刺和其他形式的开发节奏迫使价值流团队花时间计划即将进行的活动。团队向客户和其他利益相关者提供产品和解决方案演示，同时检查并调整他们的工作，并进行基于 Kaizen 或回顾的反思，以支持他们的持续改进目标。

本节完成了我们关于未来状态（第三阶段）映射的讨论，以改善客户需求流平衡。在我们完全离开本节之前，让我们回顾一下支持平衡的工具。

未来状态——平衡工具

在本节中，你了解了何时以及如何使用看板板来管理流经价值流的在制品。看板板在面向 IT 的价值流和其他面向行政或运营的价值流中都能有效工作。

价值流经理可以使用物料搬运工或“跑腿人员”来搬运必须手动跨越大距离的材料和零件。跑腿人员可以通过将在制品和生产看板卡或文件夹从一个工作地点移动到另一个工作地点，来设定价值流的节奏。跑腿人员跟随价值流的流程，每次循环时设定节奏。

Heijunka 盒子提供了一种存储生产看板卡和文件夹的方法，将它们放置在盒子的插槽中。Heijunka 盒子作为视觉辅助工具，表示特定时间段内的日常计划工作。Heijunka 盒子可能会显示哪些个人负责执行工作，或者要生产的产品类型。

另一种视觉辅助工具是视觉看板，它与 Heijunka 盒子类似，根据价值流的节奏展示超时的计划工作。但不同的是，价值流经理手动将看板卡和文件夹分发给操作员，而不是将生产看板文件夹放置在盒子中的插槽里。

顺便提一下，IT 部门可能会被要求实施看板板、Heijunka 盒子和视觉看板的电子版。在本书的第二部分，我们将学习 VSM 工具如何提供这些功能。

最后，我们需要使用未来状态映射——平衡阶段改进来更新 VSM 故事板。VSM 团队需要决定他们计划使用哪些图标来表示看板板、定速撤离、Heijunka 盒子、看板文件夹或卡片，以及视觉看板。

本节完成了我们对未来状态映射的介绍，这是我们 VSM 方法论中的第六步。在下一章中，你将学习如何实施 Kaizen 计划，以引导你的持续改进行动。

总结

在本章中，你了解了未来状态价值流映射的三个阶段。这些阶段包括评估价值流管理客户需求的能力，实施持续流动，以及平衡客户订单以优化生产能力。此外，你还学会了如何在这三个阶段中发展和演变未来状态图。

在你的学习过程中，本章继续以原始的面向 IT 的价值流示例，展示 VSM 团队如何从工作和信息流的持续状态评估转向分析一个理想的未来状态。你通过练习完成了这一部分，注意到敏捷和 Scrum 的基于冲刺的实践固有地实现了批处理过程，这在精益中是一种浪费。然而，你现在知道，批处理可以通过转向基于看板的生产调度以及实施集成和自动化的 CI/CD 和 DevOps 流水线流来消除。

通过阅读本章，你现在掌握了评估和实施精益改进的知识，可以在价值流中解决与生产对齐客户需求、改善持续流动以及平衡生产以应对客户需求变化相关的问题。凭借这些信息，你已经制定了以离散的 Kaizen 突发为形式的改进策略。

在下一章中，你将学习如何创建和实施 Kaizen 计划，以执行你的未来状态改进策略。

问题

请花些时间回答以下问题，以确保你已充分掌握未来状态映射：

1. 未来状态价值流映射的三个阶段是什么？

2. 客户需求阶段的目标是什么？

3. 持续流阶段的目标是什么？

4. 平衡阶段的目标是什么？

5. Takt 时间是如何计算的，它的目的是什么？

6. 投放（pitch）是如何计算的，它的目的是什么？

7. 在管理价值流中的客户需求时，什么是一个关键问题？

8. 第 2 阶段——持续流的主要目标是什么？

9. 在理想状态下，生产平衡的目标是什么？

10. 为什么迭代的敏捷和基于 Scrum 的冲刺固有地实现了面向批量的过程，这些策略如何得到改进？

进一步阅读

Tapping, D., Luyster, T., Shuker, T. (2002) 价值流管理：规划、映射和持续精益改进的八个步骤。生产力出版社。纽约，NY。

Tapping, D., Luyster, T., Shuker, T. (2003) 精益办公室的价值流管理：规划、映射和持续精益改进的八个步骤。生产力出版社。纽约，NY。

Tapping, D., Kozlowski, S., Archbold, L., Sperl, T. (2009) 精益医疗的价值流管理：规划、映射、实施和控制医疗环境中所有类型改进的四个步骤。MCS 媒体公司，密歇根州切尔西。

第十章：改进精益-敏捷价值交付周期（VSM 第 7 和第 8 步）

在前面的章节中，你已经学习了如何开展 VSM（价值流管理）计划，绘制当前状态图，并绘制三个阶段的理想未来状态。此时，VSM 团队已经准备好开始改进活动。VSM 实施了 Kaizen（持续改进）理念，以实现持续的改进。VSM 团队现在知道如何应用 VSM 工具，在他们的 IT 价值流和其他组织价值流中进行精益改进。

精益改进在工作范围、时间框架、成本和权限方面与基于敏捷的改进有显著不同。在本章中，你将了解到精益改进通常解决战略层面的问题，这些问题需要投资组合的投入和高层决策，至少在初期是如此。相比之下，基于敏捷的改进通常在战术层面进行，并且是在敏捷团队的范围内，且时间框架较短，通常以单个冲刺（Sprint）为单位进行衡量。

精益和敏捷实践都是必要的，且应在组织中融合。然而，由于本书的主题是价值流管理，我们的重点是进行以精益为导向的价值流改进，特别是在 IT 导向的价值流中。

在我们的通用 VSM 方法论中，有三个与 Kaizen 相关的步骤：首先，识别 Kaizen 爆发点——作为改进机会；然后，规划并实施你的 Kaizen 计划。你在前面的章节中已经学习了如何识别 Kaizen 机会。本章将提供关于如何构建 Kaizen 计划以及如何实施它的指导。

精益改进本质上是业务转型。VSM 计划有助于重新设计业务流程，将其转变为精益生产流程。生产流程一词并不总是意味着产品是为外部客户开发的。例如，一些面向软件的价值流开发并交付软件产品，以支持其他内部业务运营或面向运营的价值流。

我们将在这一章中涵盖所有这些主题。具体来说，到本章结束时，你将能够创建并实施 Kaizen 计划，作为你精益业务转型的一部分。

在这一章中，我们将涵盖以下主题：

• 结合精益和敏捷实践

• 持续进行精益-敏捷改进

• 创建 Kaizen 计划——VSM 第七步

• 实施 Kaizen 计划——VSM 第八步

• 总结 VSM 方法论

结合精益和敏捷实践

目前，敏捷方法学家中的当前趋势是将敏捷背后的软件开发概念与与精益生产过程相关的概念结合起来。在玛丽和汤姆·波本迪克在其著作《精益软件开发：敏捷工具包》（波本迪克，2003）中将精益作为敏捷实践的一个组成部分推广后，精益和敏捷实践的整合才逐渐成为主流。他们的书产生了重要影响，大多数现代敏捷方法论，如Scrum、大规模 Scrum（LeSS）、Disipline Agile（DA）和规模化敏捷框架®（SAFe®），现在都声称具有精益的基础。

尽管如此，精益-敏捷实践的概念作为 IT 学科相对较新。大多数所谓的精益-敏捷方法论并不提倡或教授全面的方法来进行精益导向的生产改进。相反，大多数精益-敏捷方法论指出，精益或精益思维原则已融入其方法论中。

换句话说，那些声称仅仅遵循他们的实践就可以使组织变得精益的方法学家们认为，精益实践可能会使组织变得精益。但是，精益实践相当成熟，将精益的概念嵌入其他方法论中，而不实施价值流管理的学科，则削弱了其已被证实的生产和价值交付改进方法的严谨性。

尽管敏捷和精益从业者都提倡持续改进的概念，但在改进过程、时间框架和涉及的工作范围方面存在根本性差异。我们将在下一节中详细探讨这些差异。

进行持续的精益-敏捷改进

到现在为止，你一定已经意识到组织的价值流管理倡议并非一次性事件。相反，它们是产品线生命周期内持续且循环进行的。然而，在这一章中，你会发现，许多最初的精益改进倡议往往比基于团队回顾的敏捷连续改进具有更大的规模。

这并不意味着在小范围内不能进行精益改进。从根本上讲，精益组织鼓励每个人发现妨碍工作的问题，找到解决方案并加以实施。然而，敏捷团队和个人通常无法对设备和工具进行全面更改，也不能在没有高层批准的情况下采购新的设备和工具来改善价值流的持续流动。精益和价值流管理的学科在实施大规模改进和业务转型时表现突出。

当 IT 组织希望实施持续集成/持续交付（CI/CD）或 DevOps 流水线时，大规模 IT 价值流改进问题会显现。这些投资通常大于一个敏捷软件开发团队，甚至一个软件产品团队可以批准的金额。基于这些原因，精益导向的改进范围通常比敏捷要大——至少在初期阶段——因此时间框架和投资也往往较大。

精益敏捷的目标是结合两种业务模式的优势。这两个概念有更多的相似之处而非不同。例如，敏捷和精益的概念都专注于交付以客户为中心的价值。两个概念都寻求提高生产效率、改善质量和快速交付。而且，两个概念都鼓励持续改进。

敏捷、Scrum 和精益都共享持续改进操作的理念。然而，精益实践者采用价值流管理实践来指导改进，而敏捷实践者则倾向于使用回顾会议。

VSM 实现了一个比基于敏捷的回顾会议更为严格的持续改进过程，称为Kaizen。与敏捷回顾相比，精益基于 Kaizen 的改进倾向于从整体上看待价值流，从头到尾进行改进，以便改善产品和信息流。因此，基于 Kaizen 的改进可能跨越时间框架和投资规模，超出小型敏捷团队能批准的范围。

换句话说，有时候，我们需要先把复杂的事物拆解开来，然后再弄清楚如何将它们重新组合成一个更好的操作系统。由于这些投资非常巨大，我们需要根据每个提议的变更对其贡献进行优先排序，以便在最短的时间内提供最大价值。

在我们对 IT 价值流进行持续性和未来状态映射练习的过程中，我们识别出了许多改进机会。具体来说，Kaizen Burst 图标突出了我们在未来状态图中识别出的改进机会。敏捷和 Scrum 实践寻求基于对实时问题的评估进行增量改进，这些问题需要立即关注。相比之下，价值流管理则采取更长期的视角来评估组织、工作和信息流的结构性变更。

VSM 团队将与价值流操作人员和利益相关者合作，逐步实施推荐的 Kaizen 改进。然而，规划的视野要比敏捷和 Scrum 推荐的视野长得多，至少在 VSM 团队初次参与时是如此。此外，VSM 的改进通常具有战略性，投资决策通常在投资组合层面做出。

两种持续改进概念——敏捷（Agile）和精益（Lean）——都是至关重要的。但正如你在第五章《通过 DevOps 流水线推动业务价值》中发现的那样，实现跨开发和运维部门的精益 IT 价值流需要大量的投资。这样的高成本改进需要高层管理的支持和批准，而且 IT 部门需要时间和精力来实现成熟的 DevOps 能力。

现在你已经了解了精益与敏捷基础的持续改进目标之间的不同，我们可以继续前进，了解如何制定基于 VSM 的 Kaizen 计划。

创建 Kaizen 计划——VSM 第七步

在逐步实施 CI/CD 或 DevOps 工具链和流水线时，存在真正的失败风险，特别是在临时基础上进行实施。首先，高层管理者可能无法完全理解涉及的时间和成本，并且当他们看到需要批准的资本支出（CAPEX）请求时，可能会产生抗拒。开发和运维团队如果他们的工具链和平台请求未被批准，将会感到沮丧。在开发 DevOps 流水线时，必须解决工具、流程集成和安全问题，内部客户和利益相关者可能对改进所需的时间抱有不切实际的期望。

DevOps是一项业务转型活动。它更像是业务流程再造项目，而不是增量的业务流程改进计划，因此 DevOps 计划需要相应的对待。换句话说，DevOps 是一个战略投资，必须在投资组合层面进行规划和执行。这意味着 VSM 团队必须进行严格的规划，提供详细的预算和时间表，并为其实施制定路线图，以支持组织其他精益价值流的计划。

在本节中，你将学习如何为 VSM 计划构建 Kaizen 计划。那我们就开始吧。

与业务战略的连接

随着三阶段未来状态映射练习的完成，VSM 团队对需要进行的改进有了广泛的理解。现在，VSM 团队必须学习如何实施这些改进，这就需要一个计划。

不需要在开始时就试图把计划做对并完成。最好从我们已知的开始，找出我们不知道的部分，并随着团队的推进对计划进行有根据的改进。这种方法与敏捷对软件改进的观点一致。首先，我们必须实施我们认为客户需要和想要的东西。然后，我们展示给他们我们所做的，再根据他们的反馈进行逐步改进。相同的策略也适用于 Kaizen 计划的制定和实施。

在 VSM（价值流图）计划的每个阶段，团队都会通过一系列问题开始工作。这个策略同样适用于 Kaizen 规划。但这一次，VSM 团队的重点是将改进活动与战略目标对齐。换句话说，组织的高层管理者批准 VSM 计划时设定的目标和任务是什么？一些相关的问题如下：

• 价值流的客户是谁，他们如何从 VSM 改进中受益？

• 这个 VSM 计划如何支持组织的战略目标？

• VSM 计划的成本是如何被证明为一个高优先级投资组合的？也就是说，是什么样的高层管理期望证明了这些投资的合理性？

• VSM 计划支持哪些内部或外部产品？

• VSM 计划影响了哪些内部和外部组织？

• 该计划预期的质量改进是什么？

• 精益 IT 价值流将如何支持组织的其他精益价值流？

• 是否有价值流的部分，改进会对系统的整体生产力产生更大的影响？

  a. 换句话说，价值流中是否存在对整体流动性和吞吐量产生负面影响的部分？

  b. 是否有价值流中相互关联的活动可以合并成更简单、更高效的活动？

• 我们应该如何优先处理在未来状态映射活动中识别出的流改进活动？

• 实施每个 Kaizen 改进计划需要哪些类型的投资？

• 为支持每项已识别的改进建议，需要什么样的培训或技能？

• 实施已识别 Kaizen 改进的最佳时间表是什么？

VSM 团队必须清晰地定义所有前述问题的定性和定量指标。最终，这些指标将定义每项改进行动的有效性。

在各个阶段规划精益改进

就像 VSM 团队在三个阶段内确定了未来状态改进，改进计划的实施也应遵循相同的三个阶段。这些阶段如下：

• 子计划：满足客户需求

• 子计划：改进过程流

• 子计划：平衡工作负载

这三项子计划直接对应于上一章中识别出的未来状态 Kaizen 计划（第九章，未来状态映射（VSM 步骤 6））。快速回顾一下，未来状态映射指导跨越以下三个阶段的改进：

• 客户需求阶段：评估产品、工作项和服务的客户需求，包括客户驱动的质量、特性或功能的变化，以及交付时间。

• 持续流阶段：旨在改进生产流动，以匹配客户需求。

• 平衡阶段：实施策略来分配工作，无论是按量还是按种类，以减少瓶颈和等待时间，并尽量减少批量大小。回忆理想的批量大小是一个。

别忘了，VSM 团队为每个阶段识别了多个改进机会。因此，Kaizen 计划应涵盖每个阶段的所有推荐改进措施。

制定 Kaizen 计划

再次强调，不同于 Agile 概念中在每个Sprint中识别和实施改进，精益改进通常需要几个月才能推出。其主要原因之一是需要识别实施必要工具、设备和布局变更所需的投资，获得高层批准，并将其纳入预算周期。

提议的变更同样需要时间来设计、采购、部署和测试所需的工具、平台和设备。VSM 团队不能忽视让组织的人才快速适应这些变化的需求。Kaizen 计划应包括时间和资源用于辅导、指导和培训。在本节中，您将学习如何使用三种主要工具来制定 Kaizen 计划；即月度 Kaizen 计划表、VSM 目标和可衡量指标图表以及详细的月度 Kaizen 计划表。

如果 VSM 团队愿意，他们可以使用项目管理调度工具，如 MS Project，来开发 Kaizen 计划的甘特图。但一个简单的工作表或大白板已经足够用来创建月度 Kaizen 计划表。

下图展示了作为 Excel 工作表的月度 Kaizen 计划表示例。该工作表直观地展示了各个 Kaizen Burst 在未来状态改进的三个阶段中的计划改进举措。此外，VSM 团队会根据随着时间的推移而识别的新的改进举措更新月度 Kaizen 计划工作表：

图 10.1 – 月度 Kaizen 计划表

月度 Kaizen 计划工作表概述了计划中的精益改进举措；因此，它并未提供与每个精益改进举措相关的任务的详细信息。随着计划的推进，更多的细节将被揭示，VSM 团队将使用不同的视觉展示来跟踪这些细节并告知他人其进展。详细计划可能被称为Kaizen 里程碑图或月度 Kaizen 计划。

VSM 团队持续使用位于月度 Kaizen 计划表底部的符号（图 10.1）来更新每个 Kaizen Burst 在其日历字段中的状态。

另一个重要的可视化展示是显示精益可衡量指标的图表，包括基准线和目标值、目标、拟议变更的状态，以及已识别的风险和问题。这个图表称为VSM 目标与可衡量指标图表，它的目的是提供 VSM 改进活动的高可视性展示，包括改进目标、目标和指标。它还标识了与每个推荐改进目标相关的风险和问题。

下图展示了一个 VSM 目标与可衡量指标图表的示例。

图 10.2 – VSM 目标与可衡量指标图表

请注意，风险和问题是分别列出的。原因在于，根据定义，风险是可能发生的事件，而问题是已经影响我们项目的事项。两者的区别至关重要，因为 VSM 团队应该在风险发生之前识别潜在风险，并决定为避免或缓解风险的负面影响而采取哪些必要的步骤。此外，VSM 团队还应该为最严重的潜在风险定义应急计划，以便在发生时能立即采取措施，将影响降到最低。

例如，假设 VSM 团队建议采用新的源代码管理（SCM）库和持续集成工具。如果安装过程中出现问题，我们希望能够有备份和恢复功能作为应急计划，将原始环境和数据恢复到故障发生之前，直到我们弄清楚导致新系统切换失败的原因。

详细的月度改善计划包括与月度改善计划相同的要素，如阶段、计划任务和月份。但详细的计划应包括额外的信息，例如责任分配、估计完成时间以及任务是否逾期。它还提供了比按月划分更为细化的时间展示，按周为单位。变更状态字段更新了在 VSM 目标与可衡量指标图表底部识别的符号（图 10.2）。

下图提供了一个详细的月度改善计划示例展示。顾名思义，该计划旨在了解拟议的 VSM 改进活动。具体而言，计划提供了识别所有改进措施的空间，直到任务级别：

图 10.3 – 详细的月度改善计划

《详细月度 Kaizen 计划表》为每个推荐的改进目标提供了一个任务编号，并进一步细化到任务层级。描述性的任务名称突出了涉及的工作，计划应标明谁负责完成工作，以及目标是否已达成。时间表提供了开始日期、持续进行的工作以及完成日期的可视化展示。VSM 团队还应进行注释，标明计划任务是否已逾期。

里程碑标志着重大事件的开始或完成，使用在《详细月度 Kaizen 计划表》（图 10.3）底部标识的符号。因此，对于每项改进活动，VSM 团队需要识别重要事件，用于衡量其变革举措的开始、进展和完成。所有里程碑必须在变革目标的量化方面可度量，并且能够衡量活动完成所设定目标的程度。

重要的是要理解，VSM（价值流管理）举措是基于项目的工作，而不是基于敏捷开发策略的工作。这并不是说 VSM 举措与精益实践不兼容。尽管如此，基于敏捷的回顾通常受时间和范围的限制，并且仅限于小型敏捷团队的权力范围和一个迭代周期（Sprint）的持续时间。

相比之下，精益举措往往具有更长远的规划周期，涉及更大的投资，需要高层的支持和赞助，并且通常更符合支持企业战略。

VSM 举措的任务是识别出实施和改进精益实践所必需的关键变革，这些变革横跨整个价值流。工作范围和投资需在高层获得批准，并直接影响组织实现战略目标的能力。

在这种情况下，VSM 举措具有项目的特征。换句话说，它们有明确的工作范围、明确的交付任务、明确的预算和明确的时间表。然而，随着精益转型的初步完成，并安装到基于敏捷的框架上，持续改进工作将在长期内转交给敏捷团队，作为其常规迭代回顾的一部分。通过这些初步的精益转型，IT 导向的价值流将作为精益敏捷实践进行改革。

现在，VSM 团队已经制定了他们的 Kaizen 计划，他们需要获得继续进行的批准。此批准要求将是下一小节的主题。

获取继续进行的批准

如前所述，精益改进举措通常涉及大量的投资。但它们也可能会干扰价值流日常活动。因此，VSM 团队必须在开始新的变革举措之前，寻求并获得适当的批准。

注意，这一层次的批准通常不适用于基于敏捷的持续改进活动，因为它们通常集中在局部层面的程序性变更。但考虑到大型 VSM 举措所涉及的时间、资源和投资，获得高层批准是必要的。

VSM 团队可以使用其VSM 故事板和Kaizen 计划来总结其精益转型的概念。在高层审核时，VSM 团队应该准备回答以下问题：

• 这个项目如何与组织的战略目标相关？

• 为什么 VSM 团队选择了这个价值流、相关价值流或部分价值流来进行此次精益改进？

• 精益方法将对我们的内外部客户产生什么影响？

• 预期的吞吐量变化是什么？

• 预期有哪些产品质量改进？

• 预期的成本节省是多少，时间框架是多少？

希望高管团队参与了早期的规划会议，并正式支持了 VSM 团队，明确了授权书，以授权他们的时间和资源。然而，提醒高管团队 VSM 举措的目的和目标，以及团队的工作如何支持组织的战略目标和使命，总是没有坏处的。

VSM 团队的建议可能乍一看显得过于激进且成本高昂。团队必须准备好用可靠的逻辑、准确的数据和规避风险的 Kaizen 策略来支持他们的建议。在准备演示文稿时，VSM 团队应牢记以下几点：

• 设定现实的目标和预计完成日期。

• 在正式演示之前，与高管、价值流经理、操作员和其他关键利益相关者进行开放对话，以获得他们的支持。

• 向所有与价值流相关的人员展示草稿版的 VSM 演示文稿和图示，并获取他们的意见。

• 保持主要演示文稿简洁，用要点列出关键内容，但准备好详细的幻灯片来深入探讨必要的细节。

• 使演示文稿更具视觉冲击力，使用图形和大字体的幻灯片，并展示大型 VSM 故事板。

• 确保优秀的工作得到认可，包括 VSM 团队成员、VA 操作员和其他重要利益相关者的工作。

• 获得批准后，花时间庆祝一次，再在每次成功的精益改进举措后再次庆祝。

这就是关于 Kaizen 规划的所有内容。如果您已经熟悉敏捷概念，您知道在 IT 领域，详细的项目和时间表计划是没有意义的。在我们开始与价值流客户合作之前，我们无法知道哪些解决方案是最好的或最优的。此外，需求和优先级随着时间的推移而变化，这使得详细的计划在我们开始工作之前就过时了。更好的选择是将您的基本 VSM 计划整理好，推进它，然后在工作过程中逐步和增量地改进它，以不断改善价值流。

本节结束了我们对 Kaizen 规划的讨论。在下一节中，您将学习如何实施 Kaizen 计划。

实施 Kaizen 计划 – VSM 第八步

在本节中，您将学习如何实施您的 Kaizen 计划。这最后一步也是最简短的 VSM 方法，但可以说是最关键的一步，也是最长的活动——它持续整个价值流的生命周期。与敏捷一样，在精益实践中，我们永远不会停止改进的努力。

这个 VSM 步骤也是最难实施的。原因是许多人，如果不是大多数人，天生对变革有抵触情绪。VSM 团队的精益改进建议是否成功，取决于他们能否让全组织的人认可。您必须从解决变革问题开始这一步骤。

解决变革问题

获得组织的认同以实施 VSM 团队的建议不是一蹴而就的。最好与一个高度激励的价值流团队合作，这个团队愿意作为创新者和早期采纳者，参与组织的精益企业倡议。

与商业流程再造的原始目标不同，VSM 团队不应一次性实施其建议。唯一的理由是，如果组织处于燃烧的平台状态，延误可能导致组织破产或失败。相反，VSM 团队需要通过其已识别的 Kaizen 爆发点，逐步和增量地实施变革。这并不意味着过程应该不必要地延长时间。目标是实现快速的成功，并利用这些早期成功，然后通过快速跟进的成功来传达整个 VSM 计划的价值。

根据技术采用生命周期原则，最早由 Joe Bohlen 和 George Beal 在他们的论文《扩散过程》中提出，一旦组织成员确信变革的好处，其余成员也会跟随新的实践。下图提供了典型的技术或产品采用曲线的图示：

图 10.4 – 技术采纳曲线

技术采用生命周期是一个社会学模型，描述了新产品或创新的采用或接受情况。当你查看前面图中的贝尔曲线时，你会注意到曲线上标注了几个标签：创新者、早期采用者、早期大众、晚期大众和滞后者。让我们花点时间来理解这些标签的含义：

• 创新者：他们是行业或组织中最早实施新方法、工具和运营模式的人。他们喜欢变化，较少规避风险。在某些情况下，他们可能处于危机模式（即“燃烧的平台”），别无选择，只能改变他们的做事方式。

• 早期采用者：他们是第一个看到创新者带来好处的人，并迅速采纳新的工作方式。他们通常也愿意接受变革并承担一定风险，但他们不会是第一个行动的人。

• 早期大众：在技术或商业转型的生命周期阶段，此时事情开始起飞。足够多的人已经为证明新技术或新工作方法的好处铺平了道路，更多的人也开始愿意承担采用新方法的风险。

• 晚期大众：这些人是最保守和最规避风险的人，他们会等到变革的动力如此强大，以至于新的方法成为唯一的做事方式。

• 滞后者：这些人根本不喜欢变革，可能信息不全，或许只是缺乏做出改变的资源。因此，他们是最后做出改变的人。

虽然创新者和早期采用者引领了变革，但当早期大众、晚期大众和滞后者看到利益大于风险并接受新的工作方式时，变革才会在组织内生根发芽。

到现在，你可能在想，如何启动一个新的精益变革倡议。答案是，这不仅仅是一个过程，更是一个潜在的变革支持行动清单，具体如下面的列表所示：

• 每一步都要沟通原因和意图。

• 理解那些离工作最接近的人，通常会有很好的想法，知道什么需要修正，为什么以及如何修正。

• 立即解决任何人员问题或不当行为。

• 奖励并认可支持 VSM 倡议的人。

• 解决障碍和问题——并且不要让它们阻止你前进。

• 不要害怕实验，去发现更好的运营模式。

• 高层赞助人和价值流映射（VSM）团队需要保持可接触性、灵活性，并愿意听取来自价值流操作员和利益相关者的意见，同时也要专注于精益改进目标。

• 在进行渐进性变革时，积极的效果是累积的。

• 记住，我们是为长期而来。

既然你已经有了应对变革中人类因素的策略，那么让我们来分解实施策略。

引导精益业务转型

正如本章引言中所提到的，精益是通过进行大规模的业务转型来改善价值交付，并且在整个组织生命周期内持续对整个价值流进行改进。从技术角度来说，协调精益业务转型工作有三个阶段：准备、实施和后续跟进。

我们在前一节的 Kaizen 规划中已经讨论了准备工作。实施是实际落地的时候，此时是进行变更的时机。接下来，VSM 团队需要跟进，确保这些变更得以贯彻实施。此外，VSM 团队还需要确保价值流达成那些能够证明精益改进投资的目标和指标。

记住，精益持续改进努力与基于敏捷的持续改进活动是不同的。精益侧重于长期规划和投资，使组织在竞争激烈的市场中具有难以超越的优势。另一方面，基于敏捷的回顾往往是局部的、相对较小的，通常不涉及投资，并且是在非常短的迭代中实施的。

通过其精益改进导向，VSM 的目标是消除所有形式的浪费。目标是帮助 VSM 团队构建从客户角度看高效、响应迅速、增值的价值流。然而，借助帕累托原则，我们知道每一次改进都会将其他问题提升至优先级列表的顶部。每一个新的精益改进都将价值流朝着为客户提供卓越服务的方向前进。

VSM（价值流管理）倡议是大局观的改进活动，逐步和持续地实施。VSM 团队使用他们的故事板来指导活动，并向其他利益相关者解释结构化的价值流管理过程如何改善价值交付。

拆解精益改进工作

在需求、持续流动和水平化改进的三个未来状态阶段中，VSM 团队专注于对 Kaizen 突发事件中识别出的改进进行实施。每个 Kaizen 突发事件中的改进活动可以是相对较小的，也可以是非常大的举措，包含多个任务，可能还涉及重大投资。

将每个 Kaizen 改进活动的工作拆解为事件的目的是全面暴露所需的工作，并让所有相关的利益相关者参与评估。VSM 团队可能会选择使用用户故事格式，如在“水平化阶段”的看板部分所描述，用以表达每个 Kaizen 事件的目标和目的。这些 Kaizen 事件可以类比为产品待办事项中的工作项。

实际上，在 IT 价值流中，Kaizen 事件可以作为产品待办事项的一部分，因为改进工作很可能涉及到价值流运营人员的努力。也可以使用看板（Kanban Board）来管理和展示更大范围的 VSM 倡议在 Kaizen 爆发和事件中的工作流程。

无论你选择哪种管理 Kaizen 事件的方法，VSM 团队必须收集并沟通额外的信息。为此，遵循以下步骤：

1. 确定 Kaizen 事件的目标并进行沟通。

2. 确定分配支持 Kaizen 事件的人员的角色和职责。

3. 定义团队工作范围；例如，通过故事或史诗（Epic）格式。

4. 确定支持 Kaizen 事件所需的培训或信息需求。

5. 在详细的月度 Kaizen 时间表计划中，展示 Kaizen 事件的预计开始和完成日期，作为里程碑。

6. 识别潜在的风险和问题，并根据需要制定缓解策略和应急计划。

7. 计划并协调完成 Kaizen 事件所需的工作。

8. 如果需要额外的投资或资源，超出最初设想，请寻求高层管理支持和批准。

9. 如果需要新团队成员支持工作，更新 VSM 团队章程。

再次强调，一些 Kaizen 事件比其他事件更容易规划和执行。因此，只需进行足够的准备和规划工作，确保事情朝着正确的方向发展。但也要知道，通过反复试验，你对需要做什么的理解会随着时间的推移而改善。

从长远来看，VSM 团队需要准备好重新审视其价值流图的时效性，并相应更新。现场观察（Gemba walks）永不停止，价值流改进也永不停歇。每个 Kaizen 事件都需要一个完整的 VSM 团队和高层领导的承诺，始终如一。否则，工作可能会滞后，甚至无法完成。

本节完成了我们关于实施 Kaizen 计划、在价值流中安装精益改进的讨论。但在离开 Kaizen 话题之前，让我们花几分钟讨论一下，为什么 VSM 倡议需要作为投资组合级别的项目获得高层批准。

将 VSM（价值流图）倡议作为投资组合级别的项目进行管理。

VSM 团队及其支持的高层管理人员需要在努力过程中保持耐心。VSM 倡议涉及大规模的业务转型，旨在实现精益的产品和信息流。转向精益的业务转型可能需要几个月甚至几年的时间才能完成。目标是给予 VSM 团队时间和资源，以完成至少一个 VSM 迭代，涵盖未来状态改进活动的所有三个阶段（即需求、持续流动和平衡）。

一旦 VSM 的未来状态价值交付改进周期完成，VSM 团队可能会觉得有必要转向另一个价值流，支持精益改进工作。组织的高层领导必须持续支持跨企业评估精益改进机会的努力，并在其组合规划活动中对投资优先事项进行对齐。大型组织可能会同时进行多个 VSM 项目。

所有 VSM 项目都需要资金、时间和资源，并需要投资。没有足够的前期分析，组织的高层领导无法知道如何最好地部署有限的资源以获得最大收益。这也是现代精益敏捷实践（如纪律敏捷和规模化敏捷框架® (SAFe®)）在其工具包和方法论中实施严格的组合分析技术的原因。

由于缺乏精益敏捷框架，VSM 团队必须将其活动与组织的组合管理优先事项对齐，并通过组合管理过程寻求投资。由于没有正式化的组合管理过程，VSM 团队必须与高层领导合作，建立正式机制，审查团队的精益投资策略和优先事项。没有这些批准，就无法有效推进实施已识别的精益改进。

与与八个 VSM 步骤相关的其他部分一样，我们将在讨论改善时总结一节，概述用于支持改善实施活动的工具。

利用改善工具

如果您的 VSM 团队仍然使用手动系统，改善实施工具与用于改善规划和价值流映射阶段的工具相同。不同之处在于，现在这些工具用于支持实施变革过程。您所学到的 VS 方法和工具可以用于改进跨开发和运营导向的价值流中的精益实践。

支持您的改善规划和实施活动的工具包括以下内容：

• VSM 故事板

• 当前和未来状态的价值流图

• 每月改善计划

• VSM 目标和可衡量指标图表

• 详细的每月改善计划

通过第六章《启动 VSM 计划（VSM 步骤 1-3）》到第十章《改进精益-敏捷价值交付周期（VSM 步骤 7 和 8）》的学习，你已经掌握了启动并执行 VSM 计划的实践知识，从而在价值流中实施精益改进。在本书的剩余部分，即《实施价值流管理（VSM）方法和工具》章节中，我们将重点了解现代 VSM 工具如何支持 CI/CD 和 DevOps 管道开发与改进活动。在继续阅读剩余章节之前，让我们快速回顾一下 VSM 方法论。

回顾 VSM 方法论

在第四章《定义价值流管理》和第六章《启动 VSM 计划（VSM 步骤 1-3）》中，本书通过应用八步流程介绍了价值流管理，并通过一种通用方法定义了已验证的 VSM。例如，这一八步 VSM 方法论已在制造业、办公室管理、供应链和医疗行业中证明了其有效性。

八个步骤如下：

1. 承诺实施精益

2. 选择价值流

3. 了解精益

4. 绘制当前状态

5. 确定精益指标

6. 绘制未来状态

7. 创建 Kaizen 计划

8. 执行 Kaizen 计划

这八步 VSM 方法论同样适用于 IT 导向的价值流，正如本书本部分提供的 CI/CD 管道案例所示。IT 导向的 VSM 案例故意将复杂性限制，以便专注于学习 VSM 方法论。但选择使用 IT 导向的案例并非偶然，因为现代价值流管理工具支持在 IT 导向的价值流中实施精益实践。

然而，在一个组织中采用多个 VSM 方法论是没有意义的，使用一个方法就足够了。每个 VSM 团队应该自由地修改基础的 VSM/精益改进策略，以提升其在独特环境中的有效性。此外，在数字经济中，跨企业的每个 VSM 计划可能都需要得到组织 IT 部门的某种支持。

在前面的章节中提到，DevOps 能力是我们在现代数字经济中竞争所需的“最低要求”。因此，大多数现代 VSM 工具支持 DevOps 能力的实施、集成和改进。但这些工具供应商也指出，VSM 与 DevOps 的结合还支持组织的精益改进目标。因此，DevOps 是为组织生产的任何产品和服务增值的关键推动力。

总结

本章讨论了持续改进我们价值流工作和信息流能力的重要性。你了解到 VSM 和敏捷有共同的原则，但它们的时间线和工作范围是不同的。例如，敏捷团队使用回顾会议来评估他们在下一个冲刺中可以进行的小规模改进。

相对而言，VSM 团队将精力集中在更重要的、精益导向的改进计划上，这些改进计划跨越较长的时间框架并需要更大的投资。此外，敏捷团队的持续改进通常不需要高层管理的批准；而 VSM 团队的改进建议几乎总是需要高层管理的批准。

在继续进行我们的八步 VSM 方法论时，你学习了如何创建改善计划（VSM 第七步）并实施改善计划（VSM 第八步）。你还学习了如何开发和使用几种工具来规划和实施改善计划，比如每月改善计划、VSM 目标和可衡量指标图表以及详细的每月改善计划。

在下一章中，你将学习 VSM 工具如何通过提供对关键 IT 价值流数据、基于仪表盘的可视化和度量的实时访问，支持在 DevOps 流水线中的精益改进。VSM 工具帮助 DevOps 团队成员和其他相关方监控并改善信息和工作流在 IT 价值流中的流动，并专注于客户。

问题

1. 日语词汇“Kaizen”在英语中是什么意思？

2. 为什么实施 DevOps 能力是授权高层管理支持的 VSM 计划的理想项目？

3. 每月改善计划的目的是什么？

4. VSM 目标和可衡量指标图表的目的是什么？

5. 详细的每月改善计划的目的是什么？

6. 未来状态改进计划和活动涉及哪三个阶段？

7. 当 VSM 计划中的项目型工作转交给敏捷团队时会发生什么？

8. 鉴于 VSM 计划所涉及的变化范围，哪种生命周期模型最能代表组织如何演变以采纳新的精益原则？

9. 为什么 VSM 计划被视为投资组合级别的决策？

10. 哪两种调度和可视化方法适用于管理与 Kaizen 冲刺相关的工作？

进一步阅读

• Poppendieck, M., Poppendieck, T. (2003 年 5 月) 精益软件开发：敏捷工具包。Addison-Wesley。波士顿，马萨诸塞州

• Tapping, D., Luyster, T., Shuker, T. (2002) 价值流管理：精益改进的规划、映射与持续的八个步骤。生产力出版社。纽约，纽约

• Tapping, D., Luyster, T., Shuker, T. (2003) 精益办公室的价值流管理：精益改进的规划、映射与持续的八个步骤。生产力出版社。纽约，纽约

• Tapping, D., Kozlowski, S., Archbold, L., Sperl, T. (2009) 精益医疗中的价值流管理：规划、绘图、实施和控制各类医疗环境改进的四个步骤。MCS Media, Inc. Chelsea, MI.

第三部分：VSM 工具供应商与框架

本节将向您介绍现代 VSM 工具的功能、VSM 工具供应商，以及领先的 VSM 方法学家或思想领袖。从第十一章， 识别 VSM 工具类型和功能开始，您将了解现代 VSM 工具的功能。具体而言，您将了解 Gartner 定义的三大类 VSM 工具，包括 DevOps 价值流管理平台（VSMP）、价值流交付平台（VSDP）和持续合规自动化（CCA）工具。

然后，在第十二章， 介绍领先的 VSM 工具供应商中，您将了解来自 15 个 VSM 工具供应商的产品，涵盖所有三个类别。我没有简单地重复其他行业分析师提供的信息，而是邀请了 24 家供应商与我分享他们如何定位自己的产品在 VSM 工具行业中的地位，以及他们认为自己在竞争中的优势。这 15 家 VSM 工具供应商同意接受采访，并展示他们的能力。

第十三章， 介绍 VSM-DevOps 实践领袖，将向您介绍 VSM 联盟、项目管理协会的精益敏捷（DA）方法和 Scaled Agile 公司（Scaled Agile Framework®）作为应用于现代 IT 实践的 VSM 方法论的最大思想领袖和提供者，旨在改进 CI/CD 和 DevOps 管道流程。它们也是现代关于将精益敏捷实践应用于数字商业转型的思想领袖。与 VSM 工具供应商的做法类似，这些组织也与我直接合作，展示他们与价值流管理相关的方法和活动。

最后，第十四章， 介绍企业精益-VSM 实践领袖，将介绍价值流背后的原创思想领袖——精益企业研究所（LEI）和 LeanFITT™。与精益企业学院一起，这两个组织是现代精益和 VSM 实践背后的主要研究者和思想领袖之一。

例如，在 1994 年，《哈佛商业评论》（HBR）的一篇题为从精益生产到精益企业的文章中，LEI 创始人詹姆斯·沃马克（James Womack）与他的合作者丹尼尔·T·琼斯（精益企业学院创始人兼主席）共同提出了“价值流”（value streams）一词。此外，Don Tapping、Todd Sperl 以及他们在 LeanFITT 的合作者们共同编写了超过 50 本关于精益实践的书籍，其中包括一些关于价值流图（VSM）作为实施精益生产改进的一般方法论的原著。

本节包括以下四个章节：

• 第十一章, 识别 VSM 工具类型和能力

• 第十二章, 介绍领先的 VSM 工具供应商

• 第十三章, 介绍 VSM-DevOps 实践领导者

• 第十四章, 介绍企业精益-VSM 实践领导者

第十一章：识别 VSM 工具类型和功能

在 2021 年预测：价值流将定义 DevOps 未来报告（2020 年 10 月 5 日发布）中，Gartner 表示：“到 2023 年，70%的组织将使用价值流管理来改善 DevOps 流水线中的流动，从而加快客户价值交付。”（www.gartner.com/）显然，Gartner 认为 VSM 作为 IT 改进策略，正在迅速成为主流。

正如你从前面的 Gartner 引用中看到的，VSM 工具在 IT 行业中迅速获得关注。但在理解 VSM 的更大目标以及如何在价值流中实施 VSM 活动之前，开始实施这些工具是一个错误。问题在于，VSM 工具提供的数据和指标，除非我们首先理解精益价值流改进的目标和原则，否则几乎没有实际用处。这就是为什么你花了前四章时间学习如何应用通用的 VSM 方法论。

现在你已经了解了与价值流管理相关的目标、指标和活动，我们必须看看支持我们持续进行 VSM 活动的工具。本章将提供关于如何使用市场上主要 VSM 工具类型的指导。你还将了解现代 VSM 工具中提供的不同功能。

在本章中，我们将涵盖以下主题：

• 利用 VSM 工具和平台

• 启用 VSM 工具功能

• 突出 VSM 工具的重要功能

• VSM 工具解决的关键问题

• VSM 工具实施问题

• 促进业务转型

• VSM 工具的好处

利用 VSM 工具和平台

本节将介绍现代 VSM 工具中可用的工具类型和功能。你还会发现，VSM 工具行业宣传其帮助实施精益改进到 IT 价值流的能力。但这些 VSM 工具所提供的信息也可以通过它们的数字触点支持跨所有组织价值流的精益改进活动。

VSM 工具通过提供对关键 IT 价值流数据、基于仪表板的可视化和指标的实时访问，帮助在 DevOps 流水线中实施和改进精益实践。这些信息帮助 DevOps 团队成员和其他利益相关者监控和改进信息流和工作流，贯穿 IT 价值流。此外，VSM 工具提供有助于保持 IT 价值流聚焦于为客户创造价值的信息和分析。

在本章中，你将学习 VSM 工具所提供的功能。但在此之前，我们将先进行一场关于支持 IT 价值流客户交付能力的 DevOps 工具和流程类型的简介讨论。

在本章介绍中提到的同一篇文章中，Gartner 概述了三种支持 DevOps 工具，这些工具能够转变 IT 价值流快速且可靠地交付客户价值的能力。这些工具和流程包括以下内容：

• DevOps 价值流管理平台（VSMPs）：提供开箱即用的连接器，整合不同的 DevOps 工具链，促进跨规划、发布、构建和监控活动的 IT 活动编排。VSMPs 通过提供 IT 价值流的可见性和分析，帮助提高速度、质量和客户价值。当你在现代背景下查找价值流管理（VSM）工具时，你通常会发现这些类型的工具。

• 价值流交付平台（VSDPs）：提供集成工具链作为开箱即用的解决方案，通常作为基于云的 CI/CD 或 DevOps 平台提供。VSDPs 还包括支持软件交付价值流中活动的可见性、可追溯性、可审计性和可观察性的工具。这些功能远远超出了传统 DevOps 平台的能力。在这个意义上，VSDPs 将 DevOps 平台的能力与 VSM 工具的能力相结合。你会发现 DevOps 平台供应商和 VSM 工具供应商正在融入这个共享领域。

• 持续合规性自动化（CCA）工具：这些工具帮助自动化和加速合规性和安全性相关的任务，取代了手动检查表、政策和工作表。此外，这些工具还能够在 SDLC 周期的早期阶段提供潜在问题的可见性，此时修正问题更为容易且成本较低。CCA 工具不应孤立运作，应该与组织的 CI/CD、DevOps 和 VSM 平台及工具集成。最好将它们作为自动化测试能力的一部分，与集成的 VSM 工具一起，这有助于支持实时监控、合规性和安全性测试结果的可见性。

Gartner 还确定了两个关键的过程，混沌工程和IT 弹性角色，这有助于优化 IT 价值流的流动。书中的后续部分将讨论事件管理和服务恢复的重要性。这些是事后问题解决策略。混沌工程进一步识别了 IT 部门可以采取的预防措施，以在复杂环境中提供高可靠性。

与前面的讨论类似，灾难恢复（DR）也是一种事后问题解决方法，用于将失败的系统恢复到在线状态。IT 弹性角色是一种将 DR 团队与产品团队联系起来的预防措施，有助于在 DevOps 价值流中实现更好的弹性。

启用 VSM 工具能力

对于任何产品负责人来说，一个好的策略是评估客户在其能力方面的需求。换句话说，我们的客户期望我们的产品在解决他们可能遇到的问题或需求时提供哪些能力？提供能够解决客户问题或需求的能力，就是我们提供价值的方式。在这个背景下，产品的特性和功能通过它们提供的能力来传递价值。

根据定义，能力一词意味着一种能力或做某事的权限。在软件开发中，需求分析定义了客户无法做或实现某些期望的领域。目标是创建能够提供这些能力的软件产品。

但是，认为能力一词仅仅指代某些功能或特性的交付是错误的。实际上，客户购买的东西，例如软件，是为了满足基本的人类需求，如以下几个方面的改善：

• 性能或生产力

• 健康和福祉

• 经济学或财务

• 个人形象

VSM 工具也不例外。VSM 工具需要为用户增加价值，以支持其组织的 IT 价值流改进计划。是的，生产力和性能的提高是精益生产改进的核心。但这些改进也有助于提升组织的健康和福祉，并可能对其客户产生积极影响。而一个成功的 VSM 项目可以改善组织的经济状况。

但不要忽视最后一个关注点：形象。对 VSM 和 DevOps 工具及平台的大规模购买和投资，可能对高层管理和利益相关者的决策和认可产生巨大的情感影响。当高层管理做出关于组织结构和工作活动的全盘变动时，员工的担忧也是成立的。最终，最强大的动机可能就是通过改善组织在行业中的形象来推动投资和结构性变革。

但我偏离了主题。接下来，让我们继续了解现代 VSM 工具所提供的功能以及这些功能为何至关重要。

在阅读了本书前四章关于应用通用 VSM 方法的内容后，你可能已经猜到，VSM 工具应该支持 VSM 流程，包括映射、度量和分析。如果你还猜到了集成、自动化和编排，那么你就更接近理解现代 VSM 工具所提供的扩展价值了。

在识别 VSM 工具能力一节中，我们将介绍许多领先的 VSM 供应商。我们将介绍的其中一位供应商，ConnectAll，提出了一种观点，即工具无关的 VSM 解决方案必须实现以下六个关键特性：

• IT 与业务对齐

• 可操作和相关的数据

• 数据驱动、以结果为导向的分析

• 动态价值流可视化

• 工作流编排

• IT 治理

这个清单是一个很好的起点，让我们花几分钟时间来了解这些功能提供的能力。换句话说，在你继续阅读之前，最好将每项内容中的 features 替换成 capabilities，这样会更有帮助。

IT 与业务的对齐

在我们现代的数字经济中，IT 功能几乎支持业务的各个方面。例如，组织可以将 IT 解决方案作为独立的产品提供，或与实物产品集成以提供增强的功能和特性。但 IT 解决方案同样能提高其他开发和运营导向价值流的生产力。

出于这些原因，VSM 的作用必须超越单纯改进 CI/CD 和 DevOps 管道流的目的。这些改进还必须支持整个业务的战略、目标和使命。换句话说，你的价值流不仅仅局限于软件开发。软件价值流扩展到业务，支持所有组织的价值流。

在这种背景下，VSM 解决方案必须帮助组织通过提供以下能力，使其 IT 功能与业务对齐：

• 实施实时指标以支持精益价值流改进

• 实施并可视化关键绩效指标（KPIs），覆盖开发和运营导向的价值流，以提高交付的速度和质量

• 提供端到端的关键指标和结果的可见性，覆盖所有投资组合投资

访问实时数据在 VSM 中是一个游戏规则的改变者。然而，如果数据不可操作且与提高交付价值的能力无关，它的价值就微乎其微。

可操作且相关的数据

VSM 是从精益生产的角度出发，对我们价值交付流的持续改进活动。VSM 工具应提供用于衡量价值流活动表现的指标，以便实现预期结果。

CI/CD 和 DevOps 管道涉及在复杂的工具链中集成、自动化和编排工作项流。与此同样重要的是，支持跨系统开发和生命周期支持过程的工具之间实时数据的流动。

正如在 第六章，《启动 VSM 活动（VSM 步骤 1-3）》到 第十章，《改进精益-敏捷价值交付周期（VSM 步骤 7 和 8）》中定义的手动 VSM 流程一样，VSM 工具帮助组织识别浪费，表现为瓶颈和由低效、不匹配的流程导致的等待。然而，软件开发相比于典型的大规模生产线在产品需求上有更多的不确定性。基于这个原因，我们还需要一些信息，帮助我们识别由废弃软件（abandonware）、定义不准确的配置、不明确的需求和不增值的、不必要的测试所引起的延迟。

此外，作为未来状态建模的一部分，必须具备将当前状态指标替换为所需变量进行 假设测试 的能力。实际上，我们可以使用 VSM 工具，通过使用当前状态的地图、指标和流程作为实验基准，来模拟未来状态的操作。

数据驱动、以结果为导向的分析

VSM 团队对价值流表现的评估与推动它的指标质量息息相关。在 第八章，《识别精益指标（VSM 第 5 步）》中，你学到了哪些指标有助于支持精益导向的生产改进。你还了解到，获取这些指标的一个优秀方法是通过现场走访（Gemba Walks）并与价值流操作员会面。

但如果你能够获取实时数据，这些数据直接与 VSM 团队定义为监控和改善价值交付与生产性能所需的关键价值流指标相匹配，情况会如何呢？这正是现代 VSM 工具所承诺的。

当然，我们首先需要做功课，定义我们当前状态的流程、浪费和指标。这是一个 VSM 工具无法消除的人类活动。

从我们关于价值流映射的讨论中回想，我们总是从下游开始评估客户的交付；然后，逐步向上游推进，评估我们如何交付价值。换句话说，我们从描述期望价值交付结果的客户需求开始分析，然后逆向分析价值流活动——这有助于我们从客户的角度亲自看到它们是否在为我们提供价值。

因此，在我们能够利用 VSM 工具提供的数据之前，我们需要可视化价值流工作和信息流，以及浪费的区域。快速回顾 第七章，《绘制当前状态（VSM 第 4 步）》，让我们总结一下当前状态映射过程，因为这项工作为我们未来状态的改进分析奠定了基础：

1. 确定客户（内部或外部需求；对于任何合作伙伴关系也需如此）。

2. 绘制价值流的入口和出口点。

3. 绘制从入口到出口的所有流程，从最下游的活动开始，向上游扩展到最初的订单/待办事项入口点。

4. 确定并定义所有活动属性（与每个活动相关的信息、材料和约束）。

5. 绘制活动之间的排队，并包括等待时间指标。

6. 绘制作为信息流在价值流中发生的所有通信链接。

7. 绘制每个价值流活动中实施的生产控制策略——主要记录推式与拉式工作和信息流。

8. 完成地图，并添加任何其他有助于完善我们对工作理解以及标准流程例外的数据。

应该明确的是，整个 VS 映射过程需要人工操作才能完成地图，直到第八步。但最重要的不是地图本身——而是走出去观察事情如何运作，这才是驱动改进的真正洞察。现代 VSM 工具的集成和分析能力使我们能够按需获取实时数据，确保我们的发现和分析是准确的。

CI/CD 和 DevOps 工具链的集成与自动化功能隐藏了大量活动细节和指标。VSM 工具帮助将这些活动和指标可视化，并在需要时立即提供。此外，监视器和触发器可以立即指出需要解决的异常（超出期望绩效指标的度量）。

这并不是说传统 VSM 中的 Gemba 漫步概念没有帮助。在现代的敏捷软件公司中，团队成员经常聚集在一起评估改进机会。更重要的是，所有软件需求和生产数据都可以随时、清晰地呈现给管理者、高层和其他利益相关者。现代 VSM 工具使产品生产和交付数据的可视性更准确、更易访问，并且可以随时获取。

随着组织在数字化转型中前行，价值流变得数据驱动，VSM 工具是解锁这些数据的关键。例如，一旦连接，VSM 工具会提供关于关键绩效指标的准确数据，如过程时间、周期时间、交付时间、流动时间、等待时间、增值时间、修复平均时间（MTTR）、逃逸缺陷率、在制品（WIP）、阻塞数据、排队、吞吐量和生产影响。

VSM 工具可以提供数据和分析工具，帮助团队评估产品问题和风险，包括错过的发布日期、不合格的 NPS 分数、未充分利用的产能和不够的测试覆盖率。这些分析帮助决策者评估成本降低、竞争定位和产品在市场中的契合度等备选方案。

简而言之，VSM 捕获数据，而分析工具帮助组织评估价值流的表现，并做出更好的决策，以实现其预期的结果。这些结果必须与业务的目标和宗旨，以及组织客户的预期结果相吻合。毕竟，收入和盈利能力取决于我们为客户提供价值的能力。

VSM 提供按需访问实时数据的能力，并提供分析工具，它们还帮助使数据和分析结果可见。

动态价值流可视化

拥有实时数据和强大分析工具的访问权限是现代 VSM 工具提供的关键能力。但与敏捷实践一致，我们还需要确保数据对需要它的人高度可见、可评估并且易于消费。VSM 工具提供通过安全网络或基于互联网的连接分发访问的仪表板，以支持可视化需求。

VSM 工具和平台提供跨所有连接的产品价值流的可视化，配有度量和可视辅助工具，展示跨流的集成、关系和编排。在多个团队的大型产品开发环境中，VSM 工具提供每个工作项的端到端可视性，以及它们如何跨价值流流动。VSM 工具提供的信息，使独立的功能团队或更大的需求领域能够发现并帮助解决依赖、集成和同步问题。

虽然 VSM 工具动态地提供实时数据访问，但它们也提供跨价值流的历史数据访问。这一点非常重要，因为历史数据使我们能够诊断问题，确定问题是如何、何时以及为何演变的。当然，它们的假设功能也使我们能够在投入时间、资源和金钱之前，探索替代解决方案。

许多 VSM 工具最初作为工具链集成和自动化平台出现。换句话说，CI/CD 和 DevOps 管道发展成集成工具链并自动化传统软件开发生命周期（SDLC）过程中的活动。但不久后，软件行业意识到，工具链集成和自动化只是面向精益的 IT 价值流改进活动的一部分。我们还需要编排。

工作流编排

CI/CD 和 DevOps 管道通过集成工具链、自动化 SDLC 以及潜在的 ITSM 过程，并编排工作和信息流来实现最有效的操作。大型软件产品在多个产品团队之间分配工作，创造了一个更复杂的环境。团队必须处理集成、协调和同步问题，以确保组件工作项在更广泛的集成系统中正确运作。

许多 VSM 平台支持多个开发团队之间的协作，这些团队必须协调和组织他们的工作。VSM 功能的扩展源于其作为集成平台的历史背景以及对 CI/CD 需求的支持。编排功能的例子包括构建的自动触发、自动化测试和部署。

自动化触发假设开发团队已经将他们的配置作为代码进行应用。通常接受的基于代码的配置有两种类型：配置即代码（CaC）和基础设施即代码（IaC）。

CaC 涉及开发配置文件，这些文件在源代码仓库中进行管理，用于指定如何配置软件应用程序以便在不同平台或计算环境中运行。CaC 支持应用程序配置的版本控制、跨各种环境部署的每个软件配置版本的可追溯性，以及无需重新部署应用程序即可部署新的软件配置。

基础设施即代码（IaC）支持通过机器可读的定义文件自动配置计算数据中心资源，从而消除手动过程和干预以重新配置计算设备。在传统环境中，数据中心操作员必须在每次软件部署之前手动配置服务器、网络、安全系统和备份系统。这种方法是繁琐的、昂贵的且劳动密集的，涉及多种技能。配置必须精确且一致，以确保对其性能进行适当的监控和可见性。因此，许多事情可能出错，增加了部署的延迟和成本。IaC 有助于避免所有这些问题。

作为一个编排平台，VSM 工具可以集中管理构建、CI/CD 测试和发布/部署。DevOps 的跨职能特性以及其支持的 VSM 平台提高了开发、质量和运维团队之间的协作。最后，VSM 仪表板提供数据和分析工具，以洞察配置和流程变化如何影响未来的发布。

IT 中的另一个关键问题是对 IT 治理政策和合规要求实施有效控制，我们将在下一个小节中讨论这一问题。

IT 治理

CIO 和其他 IT 高管有责任管理和保护组织的 IT 资产和投资。还有一些财务、监管和法律要求必须遵守，以帮助我们避免法律和财务风险。因此，IT 组织需要对开发和支持组织计算系统、网络、安全系统和软件应用程序的团队进行一定的控制。

为了支持合规要求，IT 组织通常会实施 IT 框架，如 ITIL、CMMI、COBIT、HIPAA、INFOSEC 和 ISO 27001 等。还有许多其他 IT 框架可供选择。这些框架大多富含政策和程序，但在执行能力和细节方面存在不足。

虽然编写文档以指定标准、政策和程序要求相对容易，但提供监督以确保每个人都遵循指导原则却要困难得多。幸运的是，IT 治理是 VSM 供应商提供自动化支持的另一个领域，帮助管理组织的 IT 政策、合规要求和标准。

现代 VSM 工具能够通过支持上述 IT 框架来协调与治理 IT 能力相关的流程。在这种能力下，VSM 工具提供了对整个产品价值流中的工作流的集中治理。VSM 平台提供的数据和度量有助于提供 IT 价值流管道的可见性，以及产品质量目标和合规要求。可用的信息还提供了基于数据的证据，支持工具投资决策、人员需求和生产力目标。

本小节完成了我们对一般 VSM 工具功能的讨论。在下一节中，我们将学习常见的 VSM 工具类型及其如何支持 IT 价值流生产和交付改进能力。

突出显示重要的 VSMP/VSM 工具功能

本节将介绍现代 VSMP/VSM 工具提供的基本功能。这是一类专注于支持 DevOps 环境中 VSM 活动的工具。更具体地说，VSMP/VSM 工具收集来自 DevOps 导向的价值流的信息，并提供可视化的 VSM 仪表板，以支持向精益导向实践的数字化转型。

VSMP/VSM 工具通常包括以下类型的 VSM 支持功能，以适应 DevOps 环境：

• DevOps 价值流映射：当前和未来状态 IT 价值流的端到端映射，包括工作流和信息流。

• DevOps 工作流度量：这有助于衡量价值交付的速率，包括四个关键的 DevOps 度量：部署频率、变更平均前置时间、恢复平均时间和变更失败率。

• DevOps 分析：包括用于评估当前 DevOps 工具链状态并根据未来状态推荐进行能力处理的工具。分析可以包括记录和分析跨越以下 DevOps 价值流活动的前置时间和周期时间度量：

  i. 问题解决

  ii. 从规划新特性到首次代码提交

  iii. 从功能分支创建到合并请求

  iv. 执行自动化测试

  v. 执行代码审查

  vi. 配置、提供和编排开发、测试和预发布环境

  vii. 部署到生产环境

  viii. 启用应用程序和特性回滚以及服务恢复

• DevOps 协同 orchestration：这有助于通过协调和同步 DevOps 工具链中的工作项和数据流来消除 DevOps 价值流中的浪费。

• DevOps 工作流优化：这有助于平衡跨集成和自动化的 DevOps 工具链和管道中的工作流。

• DevOps 信息流可视化：这通过报告和仪表板可视化的形式提供数据和信息输出，具有接近实时的相关性。

• DevOps 流程指标：这帮助团队分析 DevOps 管道在周期时间、交付时间和等待时间方面的性能。

分析工具帮助 IT 组织评估从创意到部署开发一个“完成”特性或功能的速度、新特性和功能随时间推出的吞吐量（也称为 速度），用于提升业务价值的工作时间（例如，特性、缺陷、风险 和 技术债务），在制品（WIP）的数量，以及投入的价值增值工作时间与等待时间。

• DevOps 数据清理：这提供了发现并修正或删除支持 DevOps 工具链的损坏、不正确或不完整数据记录、表格或数据库的工具。

  许多 VSM 工具提供一个价值流数据模型和数据存储，能够规范化跨活动的数据，以及来自不同但集成的 CI/CD 和 DevOps 工具链的数据输入。规范化是指将数据在数据库中组织，以消除冗余和不一致的关系与依赖性。通过规范化的单一 VSM 数据源可以实现跨价值流和每个产品生命周期的端到端数据分析。

• 假设分析：来自分析工具的这一功能帮助 DevOps 或 VSM 团队评估更改 DevOps 价值流过程和指标的影响，而不会直接影响价值流管道的过程和活动或它们的工作和信息流。实际上，VSM 工具捕获的当前状态指标和活动流形成了进行 假设分析 的基准，以评估未来状态改进概念。

• DevOps 工具集成：这包括 应用程序编程接口（APIs）、适配器和连接器，必要时将 DevOps 工具链与 VSM 工具集成，整合 CI/CD 和 DevOps 工具链，自动化活动并协调工作和信息流。

现在让我们快速查看一下当前在这三类工具中已识别的供应商提供的产品。

对 VSMP/VSM 工具供应商的分类

DevOps VSMP 提供数据和工具，用于监控和评估战略指标，如发布速度和 DevOps 操作效率。虽然 Gartner 将这些工具称为 VSMP，Forester 则将它们称为 价值流管理（VSM）工具。

VSMP 和 VSM 工具作为第三方 DevOps 工具的集成、自动化和编排平台，有很多工具可供选择。例如，Digital.ai在其2020 年 DevOps 工具周期表中提供了一个综合的 DevOps 工具列表，涵盖了跨 17 个类别的 400 种产品。

目前符合 VSMP/VSM 类别的工具包括ConnectAll、Digital.ai、Plutora、CloudBees 价值流管理和Tasktop Viz。

对 VSDP 工具供应商进行分类

与之前提到的 VSMP 和 VSM 工具相比，VSDP 的关键区分点在于它们是否直接在其 VSDP 平台中提供 DevOps 工具。在某些情况下，VSDP 供应商可能提供许多 DevOps 工具作为现成的解决方案，以消除管道集成任务。在其他情况下，集成的 DevOps 工具可能来自第三方供应商，但集成和自动化工作已经完成。

DevOps 价值流交付平台（VSDP）有助于协调 DevOps 工具链，以集成和自动化与构建、交付和部署软件相关的 SDLC 流程。由于 VSDP 平台控制这些工具，它们可以创建一个中央数据存储库，存储标准化数据，并提供从端到端的所有管道活动的可视化和分析能力。

我们将在下一章中更详细地了解现代 VSDP 工具的功能。但目前，作为简要介绍，我们可以指出 VSDP 支持众多的 SDLC 和 ITSM 流程，包括以下内容：

当前符合 VSDP 类别的 VSM 工具包括ServiceNow、GitLab、HCL Accelerate、IBM UrbanCode Velocity、Jira Align和ZenHub。

VSMP、VSM 和 VSDP 的目的和功能相似。关键的区别在于供应商提供完整 DevOps/VSM 解决方案的程度，或者提供一个平台来集成您选择的 DevOps 工具。但目前，我们将简要了解一些具有不同但同样重要作用的 CCA 工具，这些工具有助于提高业务绩效。

对 CCA 工具供应商进行分类

CCA 工具也被称为治理、风险和合规性（GRC）平台。这些工具实现了管理组织整体治理政策、企业风险管理评估以及遵守法律和法规的能力。GRC 的目标是将 IT 与组织的商业目标对齐，同时管理风险并满足合规要求。

CCA 工具/GRC 平台有助于改善与业务战略和产品线目标对齐的 IT 决策。它们通过确保足够关注企业合规、风险管理和合规性问题，帮助改进 IT 投资的优先级排序。CCA 工具/GRC 平台还帮助 IT 部门从企业层面支持公司政策、管理风险和确保合规。

最后，CCA 工具/GRC 平台功能的一个关键要素是确保 IT 系统和数据的安全性。它们并不取代用于保护应用程序和基于 Web 的服务的安全软件。相反，它们有助于确保政策、合规性和风险管理评估的持续执行，这对于保持 IT 系统和数据的安全至关重要。

GRC 平台和工具往往不重新发明优秀的实践，而是实施行业指定框架的基础流程和政策。因此，CCA 工具/GRC 平台可能会实施特定的合规框架，如 COBIT，风险管理框架如 COSO，或 ITSM 框架如 ITIL。

TrustRadius，一个可信的商业技术评论网站，列出了当前 GRC 平台的示例（www.trustradius.com/）：

到目前为止，我们已经评估了 VSM 工具和平台的类型及其功能。你了解了支持将 IT 价值流转化为精益 DevOps 管道环境的三种基本工具或平台类别。接着，我们深入探讨了现代 VSM 工具提供的功能，这些工具通过 DevOps 导向的 IT 价值流来支持数字化转型。我们将在下一章评估 VSDP 和 CCA 工具的功能，届时我们将探讨如何通过 DevOps 管道推动业务价值。现在，让我们来看一下实施 VSM 工具和平台所解决的一些关键问题。

VSM 工具解决的关键问题

在我们的数字经济中，软件产品通过三种形式实现价值交付。首先，软件通常作为独立产品进行销售。其次，软件支持其他组织的价值流，例如在 第四章 中讨论的内容，定义价值流管理，包括在 识别价值流 部分中讨论的内容。第三，VSM 可以帮助改善 CI/CD 和 DevOps 管道流中的软件交付速度，从概念构思到交付和支持。

在本书中，你已经学到软件交付的驱动因素包括协作、集成、自动化和编排。但你也学到，软件交付的速度必须支持其他组织价值流的流动和交付。因此，软件开发的速度必须与依赖它的其他组织价值流的需求同步。

诚然，软件交付价值流本身就很复杂。但考虑到软件交付对其他组织价值流的关键影响时，它们变得更加复杂。简而言之，我们的新兴数字经济推动了通过软件交付价值的需求，同时也推动了 IT 网络和基础设施的需求，以支持所有组织价值流中的价值交付。

生活中很少有值得追求的东西是免费的，或者容易获得的，甚至是没有问题的。所以，让我们通过识别任何 VSM 团队或倡议可能面临的问题来正确设定期望。

VSM 工具实施问题

与任何一组软件交付工具一样，组织在承诺采购 VSM 平台之前，必须解决实施问题。本节中突出的问题适用于在企业规模上安装 DevOps 和 VSM 能力。我们将在稍后的第十五章《定义适当的 DevOps 平台策略》中更详细地讨论 DevOps 平台和工具的实施问题。所以，目前我们将讨论 VSM 工具实施问题，包括以下内容：

• 打破组织壁垒

• 发展知识、技能和资源

• 获得高层支持

• 知道如何开始

• 缺乏过程成熟度

• 克服预算限制

• 维护治理和合规性

让我们深入了解这个列表，了解问题是什么，以及我们可以采取哪些方法来直接解决它们。

打破组织壁垒

保护地盘问题不是一个新问题，但它是任何组织面临的最关键问题之一。成功的组织不断发展，建立起规模经济，使其更加高效和盈利。问题在于，组织规模的扩大往往导致膨胀、过度处理、低效的管理层次，以及将决策从产品线逐渐移远的职能导向部门。结果是效率降低，灵活性和敏捷性大大减弱。

现代规模的 Scrum 和 Lean-Agile 实践提供了打破组织壁垒的方法。一个有助于打破壁垒的方法是 DevOps，在这个方法中，开发团队和运维团队协作，确保信息在 IT 组织中双向流动。

开发人员需要与运营团队合作，确保他们开发的产品在投入生产后得到充分测试和支持。同样，运营团队也需要向开发团队反馈他们在支持、运营、保障和维护业务应用程序时遇到的问题。

精益流程实施连续流，但基于拉动导向的范式。实际上，管道活动之间的沟通既受到精益的拉动导向产品控制系统的支持，又受到其制约。

然而，组织可能仍保留一些职能导向，以在价值流之间建立领域技能和能力。在这种情况下，组织中的每个人都必须理解，决策和权力应尽可能下放到价值流。对于那些超出地方性权力范围的问题，高层管理人员必须建立开放的沟通渠道，并能通过图表和仪表盘实时访问信息数据和指标。

正如你在第七章中所学到的，当前状态映射（VSM 步骤 4），高层管理人员、经理和 VSM 团队成员必须实践Gemba。换句话说，他们必须前往实际工作场所，亲眼观察发生了什么，并直接从价值流操作员那里了解障碍和问题。通过与操作员的合作，高层管理人员、经理和价值流团队成员可以共同解决这些问题，获取做出有效决策和计划所需的信息。

开发知识、技能和资源

在 CI/CD 或 DevOps 管道环境中开展软件开发所需的技能，并非 IT 部门可以轻松解决的问题。但是，在较小的团队中，团队通常会随着时间的推移逐步发展这些技能。然而，在企业规模上构建实施 DevOps 管道所需的知识、技能和资源是一个不可小觑的巨大挑战。

在接下来的子章节中，我们将处理平台和工具链投资成本的问题。但也存在一个问题，即许多软件开发团队可能正在处理遗留应用程序和企业级商业现成软件（COTS）应用程序。它们在这些应用程序上工作得越久，团队的技能可能就越与现代方法和工具脱节。

尽管这些问题并非无法克服，但希望转向以 DevOps 为中心的软件交付方式的高层管理人员必须在其人员上进行投资。我们员工的开发成本与平台、基础设施和工具方面的投资一样，都是业务转型费用和投资回报的组成部分。

获得高层管理人员的支持

生活中很少有免费的东西。我处于一个情况，组织高层希望减少某个供应商的应用生命周期管理平台的成本，并利用 DevOps 转型计划为这一举措提供正当理由。不幸的是，决策者并未充分认识到过渡过程中的人员和工具投资成本。

虽然高层可以强制转型为 DevOps，但这可能比他们想象的需要更为重大的人员和工具投资。加入 VSM 来改善管道流动性是一个明智的举措，但这项工作也会增加在技能、平台和工具开发方面的投资成本。

这个问题在第六章中已经讨论过，启动 VSM 计划（VSM 步骤 1-3）。很难让高层关注并支持将人员抽调到执行不直接为客户提供价值的工作。然而，进行精益改进对于确保整个组织能以最佳方式提供价值至关重要。这需要在人员、流程和工具上进行投资，以改善价值流管道的流动性。

同样的问题也出现在通过 DevOps 和 VSM 平台与工具投资开发 IT 价值流管道的过程中。组织中有适当权力的人将必须建立商业案例，在人员、流程和工具上进行这些投资。理想情况下，领导这一工作的应是首席技术官（CTO）、首席信息官（CIO）或首席执行官（CEO），或者至少是某一业务线的高管。如果没有，那么组织中某个人需要挺身而出，抓住机会并建立商业案例。

在下一节中，你将学习如何根据投资回报率（ROI）来评估应用程序，以便为安装 DevOps 和 VSM 功能的投资提供合理依据。

克服预算限制

让我们面对现实吧：组织的预算始终处于压力之下。总是有更多的东西值得投资，而组织无法承受这么多。这是无可避免的。与 DevOps 和 VSM 相关的投资属于投资组合级决策。换句话说，它们影响着企业的使命和战略，因此需要以此为依据进行评估。

规模化敏捷框架®（SAFe®）作为一个例子，从两个方面处理投资组合级的投资。一方面是与产品相关的，另一方面是他们称之为架构跑道的内容。产品相关的投资容易理解，因为它们直接与组织所交付的价值相关。

架构跑道 这个词可能听起来有些奇怪，且不——我们不是在谈论设计和建造机场。实际上，架构跑道指的是为了构建未来的技术基础设施，以支持开发商业举措并实施新特性和功能所做的投资。DevOps 和 VSM 是组织在其架构跑道上进行的主要投资，以提升其在数字经济中的价值交付能力。

知道如何开始

这个话题就是你购买本书的原因，我希望如此。在第六章《启动 VSM 举措（VSM 步骤 1-3）》到第十章《改善精益敏捷价值交付周期》（VSM 步骤 7 和 8）中，你学习了如何应用通用的八步 VSM 方法论。你知道如何在任何类型的价值流中开展 VSM 举措。随着时间的推移，你可以修改本书中教授的方法，使其成为你自己的方法。

但我想强调的一点是，现代的 VSM 工具帮助协调你的流程，它们为你提供了度量指标和可视化，帮助你在 IT 价值流中进行精益导向的改进。但这些工具不应取代人类在协作、理解和改进流程方面的作用。从隐喻的角度讲，不要害怕作为一个团队合作，深入数据和 VSM 的分析工作中。

缺乏流程成熟度

本小节的标题并不是要暗示实施一个正式的过程成熟度计划。然而，正如俗话所说，熟能生巧。好吧，同意，这不是一个敏捷或精益导向的概念。在我们精益敏捷的导向中，我们不断寻求改进我们的流程和活动。但精益方法不能生效，除非我们也拥有成熟的标准化实践。

在第四章《定义价值流管理》中，已经讨论了标准化问题，特别是在 5S 系统这一节中提到了标准化工作的必要性。回想一下，5S 系统中的第四项是清洁（Seiketsu）——将 5S 融入标准操作程序。创建指导方针，确保流程保持有序、清洁，并使标准变得直观易见。

标准化流程的原因在于，如果我们已经努力减少浪费，并确保浪费不再悄悄回流，那么我们就无法实现最佳的流程。是的，我们可以并且应该继续寻求改进我们价值流的流程，但我们始终应该以经过验证的标准化流程为基础进行构建。

维护治理和合规性

我们列出的 VSM 工具实施问题中的最后一项涉及治理。回想本章第一节 利用 VSM 工具和平台 中提到的，Gartner 将 CCA 工具列为一种重要的 DevOps 工具类别，这些工具有助于改变 IT 价值流快速且可靠地交付客户价值的能力。

在 IT 治理 子节中，你还了解到 CIO 和其他 IT 高管有责任管理和保护组织的 IT 资产和投资。在该子节中，我们主要讨论了 IT 治理作为确保财政责任并最小化法律责任的关键因素。然而，关于健康（例如健康隐私和安全方面的 HIPAA）、安全（例如遵守 OSHA）和用户可访问性问题（由 508 合规性管辖）等还有其他治理问题。还有许多其他的合规要求，其中许多是由政府机构监管的。

本节关于 VSM 工具实施问题的内容到此结束。在这一节中，你了解到预算编制和高管支持是关键问题。如果没有高管的支持，预算将无法为实施 DevOps 和 VSM 平台提供资金。高管们需要看到支持商业使命和战略的价值，以便为他们的投资提供正当理由。带着这个目标，我们现在将探讨 VSM 和 DevOps 如何支持商业转型，帮助组织在我们的数字经济中有效地竞争。

促进商业转型

在本书中，你已经了解到 VSM 是一种用于实施精益改进的方法。而且，你还学到，精益改进通常需要比小型敏捷团队能够批准和授权的更大规模的投资。但精益转型的结果和收益也远远更大。

VSM 是在整个组织中交付商业价值的变革过程。正是在这种背景下，组织需要评估他们在 VSM 项目和工具上的投资。本节将探讨一些帮助高管们为 VSM 工具和流程的战略投资提供理由的应用程序。

提供显示商业价值的度量指标

如果你没有跳过 第四章，定义价值流管理，你应该已经理解了捕获相关度量指标以改进价值交付的重要性。现代 VSM 工具使得实时捕获数据快照变得更加容易。

此外，在现代的 CI/CD 流水线中，活动流程是以微秒为单位来衡量的。人类无法通过时钟或秒表捕捉到这些时间框架中的有意义的度量指标。但 VSM 工具可以做到这一点。这使得人类可以专注于进行分析。这些度量指标告诉我们哪些地方存在低效的流程、等待和瓶颈。它们甚至可以告诉我们这些浪费发生在哪个流水线环节。然而，最终需要人类介入，进行工作以找出如何解决任何已识别的问题。

理解跨组织价值流的成本

识别成本的能力与度量指标密切相关。在精益（Lean）中，所有形式的浪费都会阻碍我们交付价值的能力，因此所有形式的浪费都会产生非增值的成本。

回顾第四章中，定义价值流管理部分，James Martin 记录了 17 个常见的组织价值流，以下表格再次展示了这些内容。我们连接的价值流越多，非增值成本积累的速度就越快：

图 11.1 – James Martin 的 17 个常见商业价值流列表

在本书中，我们讨论了软件开发价值流如何支持其他运营价值流，例如前面表格中列出的那些。例如，软件开发团队可能会实施软件产品，无论是 COTS 还是定制软件，以改善订单履行或客户服务交付。软件交付延迟可能会使这两个面向运营的价值流造成客户订单或未来业务的损失。

同样的原则适用于市场营销和市场信息捕捉。我们在第六章中讨论了这些问题，启动 VSM 计划（VSM 步骤 1-3）部分，整合价值流部分。在这里，我们实施了自适应产品化过程。在现代敏捷环境中，产品负责人根据由市场营销和产品管理价值流创建的市场情报做出开发决策。然而，市场驱动的情报的速度、准确性和可操作性都被手动过程严重制约。

此外，软件可能推动与在现代制造设施中构建物理产品相关的许多过程改进。例如，制造设备通常具有控制系统，能够监控过程以及物料、信息和工作的流动。

此外，劳动力成本较高的国家已经发现，有必要实施现代化的工厂自动化和机器人技术，以在降低劳动力成本的同时提高质量和生产力。但工厂自动化和机器人系统必须进行编程。

通过这些例子，应该显而易见，IT 价值流与组织的其他价值流是相互关联的。正如我们正在使用 VSM 和 DevOps 平台来集成、自动化和协调 IT 价值流一样，我们必须在所有关联的价值流中应用相同的能力，以确保整个价值交付链条中流动的优化。

理解价值流的前置时间和周期时间

提高我们市场交付的时间是几乎所有业务转型活动的基本要求。提高价值交付的关键在于改进价值流的前置时间和周期时间。我们在前面的章节中已经详细讨论过这个话题，所以这里没有必要再解释一遍。

这里需要强调的关键点是，VSM（价值流管理）平台提供了一个准确的视图，可以看到整个 DevOps 管道中从前到后的价值流前置时间和周期时间。此外，作为 VSM 工具解决方案的一部分，拥有“假设”分析功能可以让组织尝试不同的改进场景。

需要记住的是，在活动层面进行局部优化可能对提高整体生产力和吞吐量没有实际影响。换句话说，周期时间的改进可能并不会带来前置时间的改进。这是因为我们需要解决那些最阻碍流动的活动，了解哪些活动的周期时间最长，进而妨碍了我们的管道流动。

另外需要考虑的是，客户看不到也不会重视活动层面的周期时间改进。他们关心的是交付时间，而这通常是通过前置时间来衡量的。

管理跨价值流的风险

VSM 和 DevOps 工具平台通过显著减少意外问题出现的可能性，改善了 IT 价值流中的风险。现代 VSM 工具集成了能够支持信息和工作持续流动的工具。DevOps 平台的 CI/CD 能力有助于自动化管道中的 SDLC 活动，从而最大程度地减少人为错误和延迟的可能性。这些 VSM 工具提供了协调能力，影响持续和优化的流动。

此外，当我们的管道发生变化时，无论是客户需求的变化还是流动的不优化，VSM 工具的度量标准和分析能力会提供所需的信息，帮助你在风险变成问题之前评估替代方案并做出决策。

分析模式和趋势

在传统的精益产品流程中，产品开发团队使用六西格玛技术来监控性能参数，这些参数指示我们生产过程和质量目标的上限和下限趋势。

我们在第八章中识别的指标，识别精益指标（VSM 第 5 步），确定了我们价值流活动的目标。当前和未来状态的映射活动帮助我们确定了优化管道中的物料、信息和工作流所需操作的上限和下限边界。正如你可能猜到的，现代 VSM 工具提供了监控和可视化功能，帮助我们看到价值流活动如何与这些目标和边界的趋势相匹配。

VSM 工具还提供了对产品积压工作的可见性。这帮助我们监控工作如何在管道的前端排队，并跟踪其在管道中的进展。我们可以看到，一旦工作引入开发管道，需求的精炼和范围与现实的匹配情况如何。我们还可以利用 VSM 工具的数据监控和可视化功能，查看我们的 DevOps 管道，甚至是生产环境中是否出现了故障。例如，了解何时以及是否有应用程序、数据存储、网络、服务器或安全组件出现故障是非常有帮助的。在传统的 IT 环境中，这些功能是孤立的。在现代 VSM 工具出现之前，将所有数据汇集到一个监控和可视化平台中是具有挑战性的。

加速使用人工智能的改进

在 VSM 工具中使用人工智能（AI）是现代 VSM 平台中出现的另一个功能。从定义上讲，基于人工智能的工具和平台模仿人类的思维能力，这些被称为认知功能，包括学习、感知、解决问题和推理等类人活动。然而，认知人工智能只是人工智能这一更大领域的一个子集。那么，在深入了解人工智能之前，我们先来看一下两者之间的区别：

• 认知计算：这是人工智能的一个狭窄子集，旨在创建能够理解和模拟人类推理与行为的系统。

• 人工智能：这些系统通过在大数据集中应用模式识别能力，增强人类思维以解决复杂问题。

机器学习通过实现从经验中学习和改进的能力，推动了人工智能的进一步发展，而无需显式编程。这一人工智能分支创建了能够从海量数据中发现模式和趋势的应用程序，并利用这些数据通过反复试验发现达到预定目标的最佳方法。

换句话说，具有机器学习能力的人工智能系统会根据目标评估数据，然后应用不同的策略来实现这些目标，而不需要程序员告诉它们如何操作。

实际上，机器学习系统应用了与敏捷程序员用来实现目标的相同类型的迭代和渐进式开发过程——不同的是计算机能处理更多的信息，并且比人类快得多。然而，AI 系统快速识别出的模式和策略并不能取代人类对发现结果的分析、决策以及解决负面趋势所需的工作。

AI 研究人员将人工智能学科分为四种类型和七种模式。四种 AI 类型形成了越来越高层次的能力，包括以下几种：

• 反应式机器：这是最古老和最简单的 AI 形式。在这种情况下，AI 应用程序被编程为执行单一目的，并根据其指令对输入做出反应，而不会保存任何发现。换句话说，这些 AI 系统仅仅是“反应”当前的输入，可能在每种遇到的情况中应用数百万次计算，从而选择最佳结果。

  这种类型的 AI 系统的一个例子是与人类竞争的应用程序，例如国际象棋。

• 有限记忆：这是比反应式机器更进一步的步骤，AI 系统在其中结合有限的记忆，以保留从先前学习的信息、存储的数据或观察到的事件中获得的知识。这类系统的目标是建立即时有用，但时间和目的上短暂的经验性知识。

  例如，自动驾驶车辆会监控周围环境以识别威胁和障碍物，预测轨迹，作出相应反应，然后继续评估周围环境并根据情况继续反应。这类系统需要保留足够的周围环境信息，但之后需要忘记这些信息，并迅速转向评估新的数据并根据下一个环境条件做出适当响应。

• 心理理论：这类 AI 系统试图模仿人类决策和沟通过程，采用相同的情境思考和情感，这些都影响着人类的行为。这类 AI 系统必须迅速学习并对与其互动的人的面部表情、肢体语言和情感反应作出反应。

  心理理论 AI 系统的应用包括与人类建立类人反应和富有同理心的沟通。随着这些能力的发展，基于心理理论的 AI 系统在呼叫中心和客户服务环境中提升了类人沟通的能力。

• 自我意识：AI 系统试图达到人类水平的意识。在这里，我们可以想到那些能够理解自身存在、能独立思考、拥有欲望以及具有情感和体验的机器人和计算系统。

  自我意识的人工智能系统尚未出现。这类潜在的应用可以帮助人类完成各种生活或工作任务，其中同理心和自我意识有助于确保与人类互动时的安全条件。在老版的《杰森一家》卡通中，你可以将清洁机器人 Rosey 想象成一种未来的应用。

  当然，这类能力的一个著名负面例子来自阿瑟·C·克拉克的小说和电影《2001 太空漫游》中的虚构 AI 计算机Hal。Hal 是发现号太空舱中的一个机载计算机，他变得具有自我意识。当 Hal 犯下无意的错误时，他害怕自己会被关闭，从而被终止。于是，他开始杀害太空舱的宇航员，担心他们会发现他的错误。

好的，在表达了这个负面担忧之后——并非要贬低它——我们来继续讨论 AI 技术的当前现实、局限性和能力。根据Cognilytica，一家领先的人工智能应用市场研究公司，AI 的七种模式如下：

• 自主系统：这些 AI 系统专注于特定任务，旨在实现目标或与周围环境进行互动，且几乎不需要人工干预。自主系统分为两类。第一类是面向物理和硬件的产品，如自动驾驶车辆。第二类是包括软件系统或虚拟自主系统的，如软件机器人。

• 对话和人类互动：这些系统通过自然对话直接与人类互动，互动形式包括语音、文本、图像及其他书面格式。其目标是使计算机与人类之间能够使用日常语言进行交流，甚至可以在人类间进行沟通，尤其是在语言差异或障碍干扰的情况下。这样的系统还可以生成文本、图像、视频、音频及其他供人类消费的媒体格式内容。

  另一个目标是实现心智理论能力，旨在提升参与者之间的理解。这类应用提供了在商业或社交互动中，信息双向准确传递至关重要的情境。

• 目标驱动型系统：这一系统应用机器学习及其他认知方法，通过试错学习寻找最优解。有些人认为，理论上，试错过程可以应用于学习任何事物。

  目标驱动的 AI 系统在我们知道期望结果是什么，但不确定如何实现时最有价值，尤其是在有许多替代方法可以选择的情况下。回想一下我们在第三章中讨论的有关大型复杂系统中节点间指数扩展相互关系的问题，分析复杂系统交互。目标驱动系统通过评估所有潜在场景，应用蛮力方法来发现最佳结果。

• 超个性化：这是一种机器学习应用，用于开发个体的独特档案，并随着时间的推移进行持续学习和适应，以支持各种目的。例如，基于个人偏好，AI 系统可能会展示相关内容，推荐相关产品，并提供个性化的建议和指导。超个性化系统将每个人视为独一无二的个体。

  超个性化的应用包括提供个性化的医疗保健、金融服务、定向洞察、产品信息、一般建议和反馈。

• 模式与异常：这些可以通过应用机器学习和其他认知方法来检测。目标是识别数据中的模式，并发现信息之间的更高阶连接。更准确地说，目标是了解在更大数据集中的任何给定数据是否符合现有模式。如果符合，则数据符合并强化该模式；如果不符合，则是异常值。换句话说，这个模式的主要目标是找出哪些事物相似，哪些不相似。

  该 AI 策略应用于 VSM 工具和平台，以发现模式和趋势。

• 预测分析与决策：该策略利用机器学习和其他认知方法，理解如何通过分析系统行为、交互和数据来获得的洞察，帮助预测未来的结果。

  预测分析是现代 VSM 工具和平台中的另一个 AI 应用，因为预测结果可以帮助人类做出决策。这个模式最重要的方面是，人类仍然在做决策，但工具正在帮助人类做出更好、更有信息支持的决策。

• 识别：基于识别的 AI 系统使用机器学习和其他认知方法来识别和确定某些形式的非结构化内容中的对象或其他需要识别的事物。

  结构化数据是高度组织化并格式化的数据，可以在关系型数据库中存储、管理和检索。相比之下，非结构化数据没有预定义的格式或组织，这使得收集、处理和分析变得更加具有挑战性。

  非结构化内容的示例包括图像、视频、音频或文本文件格式中的信息。基于 AI 的识别系统的目标是识别、识别、分割或以其他方式分离某些内容部分，以便对其进行标记和标签，以备将来使用。通过标记和标签化非结构化数据，文件和元数据可以在关系数据库和其他结构化数据中进行管理。

  使用识别系统的价值在于，它们比人类执行完全相同的识别和分类任务更快，且潜在地更准确。这类应用包括图像和物体识别、面部识别、声音和音频识别、物品检测、手写和文本识别、手势检测，以及识别内容中的模式。

到现在为止，你应该已经明白，AI 系统并不像它们看起来那样是完全的“黑箱”，并且并非所有 AI 模式都适用于在 VSM 工具和平台中使用。

AI 和机器学习系统在 VSM 中承担了繁重的工作，通过搜索大量数据找到关系和模式，这些是人类需要数百个工时才能找到的。AI 系统并不是在施展魔法；相反，它们遵循一组规则和任务，这些规则和任务是人类指引的。

计算系统可以忠实地遵循其编码规则和算法，精确地应用数学和逻辑表达式无数次，同时在大量数据中进行搜索——没有错误。相比之下，人类无法很好地完成这些任务。此外，假设有任何人希望在 DevOps 环境中进行这种任务，工作速度以微秒为单位测量，没有人类能够跟得上。

最后，和人类一样，一些 AI 系统会从经验中学习，并重新应用他们学到的知识，获得新的见解并评估解决复杂问题的潜在方案。

人类一直在创造工具，使他们的生活更轻松、更舒适。当这些工具是基于 AI 的 VSM 工具时，情况也不例外。它们使我们的工作变得更轻松，工作效率更高。但是，与任何工具一样，人类必须控制 AI 工具，以实现生产性和人道的目的。

软件交付过程的治理

我们在上一小节中讨论了 IT 治理，标题为保持治理和合规性。这里的背景是保持 IT 必须支持的治理政策和标准。这里的问题是使用 VSM 和 DevOps 工具来改善整体软件交付过程的治理。

在 DevOps 流水线流程中，系统的开发生命周期遵循与传统和敏捷模型相同的模式，只是速度大大加快。换句话说，我们依然遵循一个流程，其中包括识别业务或用户问题、收集需求，然后进行架构设计、开发、测试和部署解决方案，以交付以客户为中心的价值。但在 DevOps 流水线中，速度如此之快，以至于我们需要确保在执行过程中对流程进行适当的治理。

在软件交付过程中，实施治理无疑涉及到业务、行业和监管合规方面的要求，而这些合规要求也需要以加速的速度运行。

这里的关键能力是，VSM 工具与集成和自动化的 DevOps 流水线运行速度相同。现代 VSM 工具在没有人工干预的情况下实施和强制执行治理政策，从而减少了人为错误漏掉关键流程和合规要求的风险，这在软件开发和交付的加速节奏下尤其重要。

将价值流作为连续流进行管理

传统的瀑布式软件开发模型的关键问题在于，它没有强制执行以精益为导向的生产流程。整个系统开发生命周期被割裂，并且延伸至不合理的长度。传统的瀑布模型完全与组织在其他价值流中实施的精益生产流程脱节。

敏捷实践通过实施迭代和增量开发模式提供了一些帮助。但早期的敏捷方法论，如 Scrum，仍然强制采用批处理方式进行冲刺（Sprints）。看板（Kanban）帮助改善了冲刺内的流动，但并未改善整体系统开发流水线的流动性。

CI/CD 和 DevOps 流水线实施了集成的工具链和自动化策略，以改善端到端的工作和信息流动，包括扩展至面向运营的支持活动。但这仍然留有编排方面的问题，需要确保流水线流程的正确性和高效性，并且在整个软件交付过程中管理治理和合规要求。

现代 VSM 工具实现了从头到尾的编排能力，覆盖软件开发和面向运营的价值流。通过 DevOps VSM 工具，组织能够实现持续且优化的软件交付和支持流程。

可视化价值流

在现代 DevOps 流水线中，大多数活动都是自动化和编排方式进行的，无需人工干预。如果没有可视化能力，我们只能凭信念认为流水线按照预期运行。不幸的是，这意味着如果出现问题，通常我们只能在事后发现，届时由于错过交付或遗漏需求，我们将面临更严重的问题。

现代的价值流管理（VSM）工具提供了可视化功能，能够展示关键的度量标准和管道流动。这些工具还提供图形化的可视化，帮助描绘工作项的排队和等待情况。简而言之，现代 VSM 工具帮助识别需要改进的浪费区域，并提供可视化功能以查看这些浪费所在。

改善跨职能和跨团队的协作

这一领域是 DevOps 的初衷：使开发团队与运维团队之间能够进行协作。但沟通与协作必须跨越整个价值交付链条和所有价值流，而不仅仅局限于开发和运维团队。

在我们现代的数字化世界中，团队分布在多个工作地点、地理区域，甚至国际边界的情况并不罕见。用于沟通、协作和协调工作的工具包括项目管理软件、视频会议、办公聊天或即时消息系统、文件共享、在线及实时协作文档修订工具、文档管理和同步工具、在线白板和版本控制工具。

这些能力的价值在于，如果没有持续和适当的沟通与协作，几乎不可能维持工作流程和任务的持续性和协调性。组织及其客户和供应链合作伙伴的地理分布越广泛，这些工具就越加必要。

改善价值流效率和交接

本书的核心内容是改善各类价值流的生产流程，尤其是面向 IT 的价值流。IT 行业已经经历了一个范式转变，从传统的项目驱动型流程转向敏捷的批量工作流，再到现代的 CI/CD 和 DevOps 流水线流程。那些能够有效实施 DevOps 能力的组织，相比那些未实施的组织，具有明显的竞争优势。

虽然 DevOps 背后的某些概念在没有集成工具链和自动化流程的情况下也能实现，但这些环境无法与那些已经全面投资于 DevOps 和 VSM 工具的其他组织竞争。简单来说，DevOps 和 VSM 平台提供的加速软件交付与比传统和敏捷基础的实践更高质量的软件。

这并不意味着 DevOps 或 VSM 与敏捷方法有所不同。通过类比，乌龟和兔子都是动物，但兔子比乌龟快得多。在 IT 领域也一样，DevOps 流水线比传统或敏捷基础的工作流程在交付软件价值的速度上要快得多。它们还更高效，且往往交付更高质量的产品。

提高质量

前一节提到，实施了 DevOps 和 VSM 平台的 IT 团队通常能交付更高质量的产品。我们来花点时间看看为什么。

在传统的瀑布模型中，测试是部署前进行的最后一项活动。这个方法的问题在于，到那时代码库已经完全构建完成，很可能隐藏了大量的漏洞。或许这样说有点夸张，但确实会有许多 bug——这是可以保证的。更糟糕的是，它们很难在最后阶段被隔离和修复。

敏捷实践的优势在于，开发团队以迭代方式构建较小的代码增量，并在每个增量中测试新功能。因此，即使软件在多个迭代周期内被推迟，作为正式发布版本，它的代码通常会比传统模型下的代码测试得更好。

然而，CI/CD 和 DevOps 流水线将事情提升到了一个新的层次，通过自动化测试和按需配置测试环境来实现。例如，我曾在一个团队工作，每天的代码都会经过一系列测试，通常是成千上万的测试，每晚都会执行。结果是，发现 bug 进入生产环境的情况非常罕见。

这种能力可以被安装在敏捷团队中。但下一步是交付微小的功能增量——通常被称为微服务——这些增量通常是一天多次，甚至在一小时内进行多次更新，并根据需要动态生成类似生产环境的测试环境来测试每个新的微版本的软件。这就是持续交付的核心。

但一些组织进一步发展了持续交付（CD）的概念，允许每次通过所有功能、非功能和性能测试的新代码版本直接进入生产环境。开发团队可以将新特性和功能按角色分配给选定的用户群体，在生产环境中发布。这有助于通过让小范围的用户验证功能或特性在大规模部署到所有用户之前的可用性，从而降低风险。

执行假设分析

本书中我们已经多次提到这个话题。组织投入、DevOps 技能和工具链并不便宜，而且在较大组织中实施这些也需要时间。这些组织需要逐步进行变革，以便负担这些投资，并尽量减少开发团队逐步适应过程中可能带来的干扰。

如你从阅读 VSM 方法论章节（第六章**，启动 VSM 计划（VSM 步骤 1-3）到第十章**，改进精益-敏捷价值交付周期（VSM 步骤 7 和 8））中了解到的，VSM 通过逐步的增量改进来实现理想的未来运营状态。基本思路是评估你价值流中的所有活动，并根据最少成本消除最多浪费来优先处理这些活动。这一策略将迅速而经济地逐步改善价值流。最重要的是，精益-敏捷的流程改进活动永远不会停止。我们总是可以做得更好。

但问题是，我们如何知道哪些替代方案是最佳的，能够将我们从当前状态带到更好的未来运营状态？这时，VSM 工具和平台的假设情境功能就派上用场了。实际上，我们可以在进行投资之前，通过模拟对产品、设备、流程和活动的更改，来查看其对整个价值流生产力的影响。

通过重用模板来更好地标准化工作项

DevOps VSMP、VSDP 和 CCA 工具可能包括一些有助于简化繁琐但相对常见工作的工具。例如，VSMP 工具可能包括适配器表单和模板，用于输入参数来连接数据库和应用程序。VSMP 和 VSDP 都可能包括价值流映射工具和模板，以加快当前状态和未来状态地图的开发。另一方面，CCA 工具可能包括其系统填充的模板，作为审计痕迹以证明符合监管要求。

统一数据和文档

拥有多个产品线的大型企业，必须在职能部门和价值流使用不同的数据源和文档来监控、治理和记录其活动时，评估价值流的生产力。当组织依赖人工劳动来捕捉并重新格式化信息以供管理层、客户和利益相关者使用时，情况会变得更加复杂。

精益和价值流管理（VSM）实践为我们提供了共同的语义，用来描述如何改善价值交付。这解决了问题的一半。另一半则是消除收集、转化和交付信息的人工劳动。虽然这些信息对于决策可能非常有价值，但它们可能是滞后的，从客户的角度来看，这些工作是没有增值的。现代的 VSM 平台通过实时自动捕捉数据来解决这些问题，并且提供工具，允许数据使用者随时用多种工具和格式可视化并分析价值流数据。

集成、自动化和编排价值流活动

精益产品改进包括无论何种价值流，价值增值活动的集成、自动化和编排。目标是通过消除浪费，更快速且更高质量地交付以客户为中心的价值。现代 DevOps 和 VSM 平台通过消除浪费，提升软件开发、交付、运营和支持过程中的生产力。

然而，软件可能涉及所有组织的价值流。因此，我们必须使用 DevOps 和 VSM 方法和工具，通过软件解决方案集成、自动化并编排所有价值流活动。

提供一个共同的数据架构

许多 IT 组织允许其开发团队选择不同的工具来集成 CI/CD 和 DevOps 工具链。提供这种灵活性是 DevOps VSMPs 运作的前提。虽然 VSMP 策略提供了很大的灵活性，并允许使用最好的工具，但缺点是每个工具可能有不同的数据存储和数据模型，这使得跨工具链检索、规范化和使用数据变得更加困难。

VSDP 供应商通过最小化工具选项并将其集成到单一数据存储中，跨所有价值流活动实现数据规范化，从而解决了这个问题。使用 VSMP 工具时，每个数据源必须映射到中央存储库。在任何情况下，拥有一个包含规范化数据的单一数据存储的价值在于，查询能够端到端地操作所有已管理的与价值流相关的数据项及其活动。简而言之，单一数据源存储与数据规范化使得生成报告、进行分析和创建管道流的图形可视化变得更加容易。

制定并填充关键绩效指标

定义上，关键绩效指标（KPIs）是组织定义的关键进展指标，用以衡量朝着预期结果的进展。组织可能定义 KPIs 来支持战略和战术目标。KPI 是基于指标的，因为结果必须是可衡量的，以确定与我们的目标和任务的进展情况。

现代 VSM 工具提供最新且准确的指标，这些指标与组织的 KPIs 映射，为高管的决策过程提供更大的信心。例如，作为投资组合管理的一部分，主要高管和产品经理会根据客户需求、竞争价格点、历史和计划成本因素做出投资决策。此外，在产品开发过程中，访问实时指标至关重要，以评估实际与计划的表现，这有助于实现及时的调整。

我们已经结束了促进业务转型部分。在接下来的最后一部分，我们将探讨投资 VSM 技能、工具和平台的好处。

VSM 工具的好处

在上一节中，你了解了现代 VSM 工具和平台提供的能力。现在，你将学习如何解释它们的好处。

接下来将讨论实施 VSM 工具所带来的一些关键好处。许多这些好处在上一节中已经讨论过了。所以，下面我们简要回顾一下：

• 提升发布质量：VSM 工具和平台监控 DevOps 性能参数，强制执行标准的生产流程和合规性要求，确保价值流活动在上下边界点内进行，从而实现最佳工作流并达到质量目标。

• 更快的发布周期：VSM 工具和平台帮助集成、自动化并协调 DevOps 流水线流程。它们还帮助贯彻精益理念，消除浪费，以实现最快和最高效的软件价值交付系统。

• 可衡量的业务价值成果：VSM 工具提供了组织所需的度量标准，用于衡量当前状态的表现，预测未来生产和交付能力，并确保过渡符合预期。

• 减少风险和浪费：VSM 工具和平台严格执行标准流程和合规性要求，确保没有错误，最大限度地减少引入风险和无价值浪费的可能性。

• 成本降低：通过 VSM 工具指导 DevOps 生产，组织可以确保以最小的浪费达到最佳运营效率。实时度量和分析工具帮助组织发现并消除次优活动，并评估改进生产力和价值交付的替代方法。

• 更好的工具链协调：VSM 工具的协调能力有助于发现 DevOps 流水线中的瓶颈，实施标准化流程，集成并强制执行安全性和合规性要求，同时同步和协调开发和发布应用所需的步骤——包括手动活动。

• 提升合规性和可审计性：CCA 工具帮助自动化和加快合规性和安全相关任务，替代手动检查表、政策和工作表。最重要的是，CCA 工具帮助消除与合规失败相关的风险和法律责任。

本节完成了我们对如何利用 VSM 工具和平台能力的讨论，以及如何改进精益敏捷价值交付周期的章节内容。接下来，让我们总结一下本章内容，并查看一些问题，帮助你巩固本章所学。

摘要

在本章中，你了解了 VSM 工具如何通过提供对关键 IT 价值流数据的实时访问、基于仪表盘的可视化和度量，支持 DevOps 流水线中的精益改进。VSM 工具帮助 DevOps 团队成员和其他利益相关者监控并改进信息和工作在 IT 价值流中的流动，聚焦于客户。

您还了解到三种主要类型的 VSM 工具 - VSMP/VSM、VSDP 和 CCA，以及它们应提供的功能。接下来，我们涵盖了在组织中推广这些工具时可能遇到的实施问题。然后，您了解了 VSM 工具和平台的众多潜在应用及其能够证明投资的好处。

下一章将介绍当前行业领先的工具。我们将探讨每个工具的优势，并讨论实际应用案例，同时突出它们在特定场景下的优势。

问题

1. 为什么这本书在讨论 VSM 工具的主题之前介绍了一种经过验证的八步 VSM 方法？

2. 哪三种 DevOps 工具可以帮助您快速可靠地交付客户价值的 IT 价值流转化？

3. DevOps 价值流管理平台（VSMP）中的主要功能是什么？

4. DevOps VSMP/VSM 工具的关键好处是什么？

5. GRC 工具和平台的目的是什么？

6. 价值流交付平台（VSDP）内可用的主要特性是什么？

7. VSDP 的主要好处是什么？

8. DevOps 工作流程指标的目的是什么？

9. DevOps 管理编排的目的是什么？

10. “假设分析工具”的主要好处是什么？

进一步阅读

• Betts, D., Saunderson, C., Blair, R., Bhat, M., Scheibmeir, J. Ennaciri, H. (2021 年 10 月)，Gartner Research Predicts 2021: Value Streams Will Define the Future of DevOps Report（2020 年 10 月 5 日发布），ID: G00734377. www.gartner.com/en/documents/3991376/predicts-2021-value-streams-will-define-the-future-of-de. 访问日期：2021 年 3 月 1 日。

• Condo, C., Mines, C., Giudice, D.L., Dobak, A., Hartig, K. (2020 年 7 月) The Forrester Wave™: Value Stream Management Solutions, Q3 2020 Report. www.forrester.com/report/The+Forrester+Wave+Value+Stream+Management+Solutions+Q3+2020/-/E-RES159825 . 访问日期：2021 年 3 月 1 日。

• Corporate, 2019 年 4 月 4 日. AI FUNDAMENTALS, The Seven Patterns of AI. www.cognilytica.com/2019/04/04/the-seven-patterns-of-ai/#:~:text=The%20Seven%20Patterns%20of%20AI%201%20The%20Seven,9%20Combining%20multiple%20patterns%20in%20a%20project.%20. 访问日期：2021 年 4 月 30 日。

第十二章：介绍领先的 VSM 工具供应商

在上一章中，你学习了现代 VSM 工具的一些基本功能。你还了解了如何识别三种 VSM 工具分类。

我们还深入探讨了常见的 VSM 工具实施问题，VSM 工具在支持数字化业务转型中的作用及其关键优势。现在，我们将介绍行业公认具有 VSM 能力的领先软件工具供应商。

我没有重复其他行业分析师所写的内容，而是联系了领先的 VSM 工具、方法论和服务提供商，请他们告诉我们为什么他们的客户选择他们的产品。那些选择接受本书采访的供应商将在本章中列出。在采访中，我请他们的指定代表解释他们认为自己特别的优势所在以及原因。他们还有机会展示一到两个他们认为有助于展示其 VSM 工具和服务优势的客户案例。

在本章中，我们将涵盖以下主题：

• 让现代 VSM 工具具备正确的视角

• 提升价值交付

• 在 CI/CD 和 DevOps 之外使用 VSM

• 列出领先的 VSM 工具供应商

我们将从谨慎的提醒开始，踏上探讨领先 VSM 方法和工具的旅程。

让现代 VSM 工具具备正确的视角

从前面的章节中，你现在知道 VSM 背后的概念并不新颖，已经被应用于许多行业和无数的价值流。你也知道 VSM 起源于精益生产改进的学科。与传统的层级化和以职能为中心的过程改进观念不同，精益改进将组织活动结构化为协调的流程，以最佳方式向内部和外部客户交付价值。

由于 VSM 本质上是一种帮助组织调动资源进行精益改进的策略，我们在本书中花了一些时间学习精益。从这些培训中，你现在知道精益是一种规划和实施持续过程改进的系统。它的核心在于通过从客户的角度消除各种浪费，来发展高效的生产和信息流。提醒一下，常见的浪费类型包括缺陷、库存、动作、过度加工、过度生产、运输和等待。

提升价值交付

在第四章**，定义价值流管理中，你了解到 James Martin 阐述了 17 种常见的价值流。在他的著作《伟大的转型》中，Martin 写到了定义和改进价值流动在任何业务流程重设计中的重要性。

Martin 的概念建立在 Thomas Davenport 的论文 Process Innovation: Reengineering Work through Information Technology 的基础上。在这篇论文中，Davenport 将组织价值增值流程分为三类：

• 产品设计、开发和制造流程

• 面向客户的流程，包括营销和销售管理、订单管理和客户服务

• 管理和行政流程

重要的结论是，Martin 和 Davenport 都通过价值导向或价值交付改进的视角来评估流程重组和流程改进举措，并且 IT 是推动业务流程创新的重要推动力。此外，他们的写作解释了为什么组织不能通过建立保持现状的流程和系统来找到真正的业务流程改进，尤其是在等级制、官僚制度和职能领域中。换句话说，Martin 和 Davenport 主张利用 IT 重新设计业务流程，但要从增加价值的角度来进行。

根据你在本书中学到的内容，应该显而易见，VSM 作为一门学科，与软件工具几乎没有关系，甚至与改善你组织的 CI/CD 和 DevOps 流程也没有直接关系。VSM 的意义远比这些更大，更重要。

在 CI/CD 和 DevOps 之外使用 VSM

商业公司、政府机构和非营利组织的存在是为了在产品、服务或其他期望的结果和成果中创造价值。在我们现代的数字经济中，Martin 和 Davenport 的洞察比以往任何时候都更加重要。改进我们的 CI/CD 和 DevOps 流水线可以提高我们在所有组织价值流中交付价值的能力。

但当然，如果你的 IT 组织没有与支持组织其他价值流的需求同步，你的 CI/CD、DevOps 和 VSM 工具链投资就不会有什么成效。因此，必须理解，你的组织可以花费大量时间、金钱和精力购买 CI/CD、DevOps 和 VSM 工具，但仍然可能无法提高价值交付能力。

CI/CD、DevOps 和 VSM 工具链投资是潜在的 Kaizen Burst 活动的例子，用于推动其他关键价值流的改进。因此，这些投资并不便宜，并且成为支持组织核心业务使命和战略的投资决策。然而，CI/CD、DevOps 和 VSM 工具链投资是基础性的，因为它们支持任何其他 VSM 举措，必须从这个角度进行评估。

这一问题正是本书在讨论如何在 IT 功能之外实施 VSM 时，所花费大量篇幅的原因。然而，改善 IT 的主要驱动力是改善它所支持的其他面向开发和运营的价值流。换句话说，你的 IT 导向的 Kaizen Bursts 将受到其他价值流改进需求的推动。了解这一点后，我们来介绍当前 VSM 的工具和思想领袖。

列出领先的 VSM 工具供应商

本章向你介绍了各大行业分析师如 Forrester Research、Gartner Inc.、GIGAOM、SD Times 等所识别的领先 VSM 供应商。然而，我有意避免重复这些行业报告中关于具体产品的看法。

相反，本书的目标是识别出领导者，然后让每个 VSM 供应商如果愿意的话，讲述他们自己的故事。这些故事会出现在接下来的章节中。但在进入这些章节之前，我们需要首先了解谁是被认为的领导者。因此，图 12.1 显示了当前的 VSM 工具和方法供应商列表，按字母顺序排列：

图 12.1 – 领先的 VSM 方法和工具供应商列表

我已添加了三家 VSM 方法学公司，Disciplined Agile、SAFe 和 价值流管理联盟（VSMC），它们提供关于如何将 VSM 应用于扩展精益和敏捷实践的指导。不过，它们的产品描述会在下一章中介绍，第十三章，介绍 VSM-DevOps 实践领袖。

在阅读每个列出的 VSM 供应商信息时，请记住它们是如何从精益导向的角度支持 CI/CD 和 DevOps 管道的改进的。同时，回顾一下，成熟的 CI/CD 或 DevOps 管道的三个关键元素是集成、自动化和编排能力。

最后，回顾一下，VSM 是一种经过验证的、有效的、并且有条理的逐步方法，用于理解和应用精益思维的原则和实践。VSM 作为一门学科，已经实践了几十年，适用于所有组织的价值流，其根基来自于丰田生产系统（TPS）中采用的精益生产理念。

本节的其余部分介绍了行业当前领先的 VSM 工具供应商，概述它们的能力。需要注意的是，并非所有这些工具都声称其关注点是 VSM 支持。例如，一些 DevOps 和 CI/CD 工具供应商，如 Atlassian，在软件项目和产品管理中发挥着至关重要的作用。但我们需要探讨它们的产品如何在 VSM 项目中得到应用。

Atlassian

Atlassian是一家澳大利亚团队协作软件工具公司。尽管 Forrester Research 将 Atlassian 包括在其Forrester Wave™: Value Stream Management Solutions Scorecard (Q3 2020)中，但 Atlassian 并没有明确的价值流管理策略。尽管如此，Forrester 对该公司的产品愿景、性能、合作伙伴生态系统和市场存在给予了高度评价。

当我向 Atlassian 询问他们在价值流管理方面的立场时，我得到了以下回答：

"虽然我们没有专门销售 VSM 解决方案，但我们的产品决定性地用于跨越从概念到客户再到学习回路（学习循环）的开发和运营价值流程。我们信奉开放的方法，因此我们与几乎所有东西都集成，并且我们主张保持一定的中立，以便我们的客户可以设计他们最优的工作方式。"

有了这些信息，让我们看看 Atlassian 如何适应 VSM 的格局。

两位大学同学，Mike Cannon-Brookes 和 Scott Farquhar，在 2002 年开发了可以说是排名第一的项目管理软件Jira。最初，Jira 是一个为软件开发人员设计的问题追踪平台。然而，现在的 Jira 软件帮助敏捷软件开发和支持团队规划、跟踪和发布他们的软件。

Jira 的能力不仅限于软件开发和 IT 运营活动的计划、跟踪和支持。组织还使用 Jira 来支持产品管理、营销和销售等其他价值流程的协作。其目标是支持跨团队协作，协调产品战略、演进、开发、支持和维持活动。

Atlassian 在其近 20 年的存在中规模和产品都有了增长，并且目前提供了 13 种产品，涵盖以下 4 个解决方案领域：

• 计划、跟踪和支持

• 协作

• 编码、构建和交付产品

• 安全和身份

Atlassian 的工具共同提供了企业规模的实时可见性，并帮助企业聚合团队级别的数据，以实时使整个组织的所有工作可见。

公司提到了价值流映射作为一种优化持续交付管道的分析技术在一篇名为What is value stream mapping? at www.atlassian.com/continuous-delivery/principles/value-stream-mapping的文章中。但 Atlassian 并没有作为现成解决方案提供集成的价值流映射工具。

组织通常将 Jira 集成作为支持其 CI/CD 和 DevOps 工具链及 VSM 平台的协作解决方案。例如，一个常见的 Jira 集成是与 ServiceNow 的集成，支持跨 CI/CD 和 DevOps 管道及 ITSM 过程的双向协作，涵盖问题和项目管理。

Atlassian 网站：www.atlassian.com/

CloudBees

CloudBees 是另一家 VSM 解决方案提供商，其根基在于连接 DevOps 工具链，自动化并改善软件交付过程。Forrester Research 将 CloudBees 排名为强劲表现者，而 GigaOm 则将 CloudBees 评为 快速移动者，进入其 VSM GigaOm 雷达的内圈。

CloudBees 通过提供核心功能（持续集成（CI）、持续交付（CD）、发布编排、分析和功能标志）将软件交付和 VSM 结合成一个平台。通过这样做，组织可以在开发生命周期中大幅提升可视性、一致性和协作——这是 VSM 的本质。将这些核心工具集中在一起，还能扩展审计准备性，因为团队和流程更容易被衡量和管理，同时消除了执行平面和控制平面需要独立产品的需求。

图 12.2 提供了 CloudBees 平台提供的核心功能的快速列表：

图 12.2 – CloudBees 平台功能

CloudBees 的平台支持公司所称的软件交付自动化和管理的五大支柱：

• 连接的流程：协调软件交付，高效地连接功能，以最大化价值和采用率，将创意带入市场。

• 合规即代码：在所有管道中集中执行政策、访问和标准，并确保仅使用经过批准的、不变的组件、自动化和环境。

• 通用数据模型：使数据从端到端可用，并以标准化的数据模型进行捕捉和存储，以促进协作、连接的流程和共享的洞察。

• 通用洞察：使整个组织中的所有职能都能从数据中理解和持续学习。

• 持续的 协作与改进：允许围绕软件交付组织跨职能和团队进行协作，放大其价值创造和交付努力。

CloudBees 的客户基础深植于开源 Jenkins 开发社区；Jenkins 用于在 CI 和 CD 环境中构建、测试和部署软件。因此，他们的工具重点提高开发和部署过程的效率。

CloudBees 平台通过建模从代码提交到生产的软件交付管道来映射价值流。该管道模型包括到生产的路径、批准的组件、门控和阈值、测试协调、部署自动化、工具链集成（及数据）等内容，呈现为图形视图。内置分析包括可配置的仪表板，用于 DORA 指标，以及每个阶段的等待时间、执行时间和持续时间。AI/ML 组件根据开发者、代码库和 CI 影响生成每次发布的风险评分。

在他们的报告中，行业分析师表示，他们希望看到 CloudBees 发展其 VSM 能力，以支持通过更好的业务指标和仪表板与业务结果的改进关联。CloudBees 已经作出回应，开发了包括一系列流程指标和业务指标（如价值、成本、质量和幸福感）在内的更多指标。

总之，除了在 CI/CD、发布编排和功能标志能力方面的优势外，CloudBees 平台还提供了从创意到生产全程映射、管理和治理价值流的能力，并提供对集成第三方工具的卓越支持。

有关更多信息，请访问 CloudBees，并可以在www.cloudbees.com/找到其提供的服务。

ConnectALL

ConnectALL的根基在于为应用生命周期管理（ALM）工具（如 Sarena（现为 Micro Focus ALM））开发适配器和连接器，连接到其他用于开发、配置管理和项目管理的软件工具，包括 Perforce、ClearCase 和 Jira。此外，公司还不断发展其连接器，以支持与 IBM Rational、HEAT Software、Git 和 Rally 的集成。

ConnectALL LLC 于 2018 年正式成立，最初作为 Orasi 和 Go2Group 之间的合资企业。Lance Knight 和 Brett Taylor（现为董事会成员）于 2016 年 12 月开始讨论对价值流管理需要采取新方法的议题。Lance Knight 于 2017 年加入公司，担任总裁兼首席运营官，他与 Brett 一起开始战略性地定位 ConnectALL 以推动这一变革。同时，Tom Stiling（现为 ConnectALL 董事会主席）加入了这一努力。因此，三位合作伙伴于 2018 年开始将 ConnectALL 作为一个独立实体建立，专注于 VSM。

Andrew Fuqua，产品高级副总裁，于 2018 年加入公司，帮助推动公司的产品战略。此外，Eric Robertson，战略顾问高级副总裁，最近被聘请以引领公司在 VSM 行业的未来。该团队的合作和由此产生的产品获得了Forrester Research、Gartner和SD Times的好评。

ConnectALL 的战略目标是“传递给软件的‘人性化’方面”。因此，虽然 ConnectALL 的集成工具一流，但他们并不认为 VSM 仅限于提供集成工具和流程编排能力。相反，他们认为 VSM 工具的更大价值来自于以人为驱动的评估。这些评估帮助 ConnectALL 的客户发现提升敏捷性、可追溯性、可预测性和速度的领域。VSM 评估实际上实现了以人为导向的精益改进措施，如本书第 6 到第十章所讨论的那样。

ConnectALL 的 VSM 评估从客户进行 VSM 工具采购投资之前开始，并且评估将持续到工具购买之后。最重要的是，ConnectALL 的 VSM 愿景不仅仅局限于改善 CI/CD 和 DevOps 流水线流动，它还旨在将数字化计划对齐整个组织，以改善业务成果，并提升客户交付软件的速度。

ConnectALL 在 VSM 中的重点是帮助组织看见、衡量并自动化它们的价值流。它们通过连接工具来实现这一目标。虽然集成无疑是 ConnectALL VSM 解决方案功能的一个重要组成部分，但它们的更大愿景是将工具连接作为主要的价值主张。工具的连接使公司能够收集指标、绘制价值流、分析替代方案并编排优选的价值流。

ConnectALL 产品的一个关键差异化因素是其专利申请中的通用适配器。通用适配器使其平台能够与任何其他具有 REST API 的工具连接，从而使得在 CI/CD 和 DevOps 流水线中快速集成其他工具成为可能。

ConnectALL 在其价值流评估工作坊中使用其价值流可视化工具作为辅助工具。图 12.4 说明了 ConnectALL 价值流图的一个示例：

图 12.3 – ConnectALL 的价值流可视化工具

ConnectALL 的 VSM 平台提供四项关键功能：集成、流程指标、工作流 编排和治理。该平台通过提供内置的供应商适配器，实现工作和信息流在整个价值流中的双向或单向同步，从而连接软件交付价值流中的工具。平台还提供开箱即用的工作流编排和治理功能。

ConnectALL 的洞察分析产品利用 ConnectALL 的适配器将支持价值流的不同工具中的原始数据提取到其标准化的数据模型中。此外，洞察分析的可视化功能使得诸如流动性、精益、DevOps 和 IT 性能等指标的数据变得可见、透明且易于获取。

您可能对这个着陆页感兴趣，其中包含一些案例研究：www.connectall.com/resources/case-studies/。

ConnectALL 的网站：www.connectall.com/

Digital.ai

Digital.ai 拥有一个独特的 VSM 平台，解决了大多数大型企业面临的一个常见问题：通过“允许团队选择”并继续使用他们选择的工具来保持开发人员的满意度和生产力。做到这一点需要为数百种不同的 DevOps 解决方案提供预构建的智能集成。

Digital.ai 发布了年度DevOps 工具周期表，其中包括实践者评级的 DevOps 应用程序，用以说明不同工具链的问题。其 2020 年版本的周期表涵盖了 17 个独特类别中的 400 多种产品。您可以在这里下载：digital.ai/periodic-table-of-devops-tools。

Digital.ai VSM 平台连接了整个软件交付生命周期，无论您选择的工具和供应商是什么。将 Digital.ai 面向开发者友好的平台与从零开始使用单一供应商的新技术相比，成本高昂的替代方案进行比较。

起初，这种方法有许多预期的好处，包括接触前沿技术和新的思维方式以及解决问题的方法，这也是为什么它通常是一个具有吸引力的初步考虑。但一旦理论与现实相碰撞，大多数企业发现，撕掉并替换工具增加了风险和复杂性，增加了停机时间和成本，且通常需要学习新工具和新流程。

更糟糕的是，围绕这些现有工具构建的数百个支持流程和自动化可能需要被更改。采用这种“重构”方法会消耗团队的精力和可用容量，使团队的焦点偏离数字化转型的目标。相反，组织必须实现数字化，以提高运营效率，成为一个能够快速创新的数字化企业。

Digital.ai 的统一 VSM 平台连接了您的业务和开发价值流。它提供了端到端的 DevOps 管道和其他支持工具和组织（如投资组合规划、客户支持、运营和销售等）的监管和治理，帮助改善业务成果。

虽然大多数价值流工具仅帮助改善软件开发和 DevOps 效率，Digital.ai 的解决方案连接了敏捷规划与投资组合管理、持续测试、应用保护、软件开发生命周期管理、发布与部署协调，以及端到端的 AI 驱动智能。其平台使大型复杂企业能够优化 CD 管道，以最大化价值交付和质量，而不是仅仅遵循固定的交付计划。

Digital.ai 认为 VSM 平台必须提供端到端的 DevOps 流水线监督和治理。它通过整合整个软件生命周期工具链的数据，应用业务分析和 AI/ML 技术，提供实时可见性，揭示业务和开发价值流的指标和 KPI，提供可操作的洞察（图 12.5）：

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/drv-dop-val-st-mgt/img/B17087_Figure_12.4.jpg)

图 12.4 – Digital.ai：智能价值流平台

Digital.ai 是少数（如果不是唯一）理解应用 AI/ML 并连接业务与开发流指标和 KPI 需求的 VSM 平台解决方案提供商之一。通过提供统一的数据模型及评估客户价值流动所需的预构建指标和仪表板，他们的 VSM 平台帮助实现了这一目标。

作为这些功能的一个示例，Digital.ai 利用 AI/ML 技术洞察并跨组织孤岛汇总数据，形成信息的整体视图。然后，它提供跨销售、营销、财务、开发、运营和技术团队的可操作洞察。

Digital.ai 提供多个支持价值流智能和变更风险管理的解决方案，具体包括以下内容：

• 用于计划与创建、集成与测试、发布与部署、运营与监控生命周期阶段的分析视角，以及结合业务与技术数据的全生命周期视角全景镜头

• 使用 AI 和 ML 优化服务管理、变更风险预测、流动加速和质量改进

Digital.ai 的价值流编排解决方案包括以下内容：

• 敏捷规划和组合管理的敏捷性（以前是Collabnet | VersionOne）

• 发布与部署 DevOps 解决方案，用于发布和部署编排（以前是XebiaLabs）

• 持续测试（以前是Experitest）

• 应用保护（以前是Arxan）

Digital.ai 的解决方案的更多信息，请参见本书第二部分，识别 VSM 方法论提供商。

Digital.ai 价值流平台的基本元素如下：

• 应用智能：Digital.ai 平台自动且智能地指导软件交付编排，加速价值流动，并预测变更失败和计划风险。

• 通用数据模型（CDM）：Digital.ai 的 CDM 有助于聚合和协调数据，并应用人工智能（AI）和机器学习（ML）。Digital.ai 强大的 AI 平台功能分析跨所有价值流的数据，创建 360 度的业务成果和技术输出的数字视图。

• 标准化视图：CDM 支持一个智能层，提供客户数字世界的整体视图或镜头，适合技术高管和商业领导者的消费。

• 全景 360°数字视图：360 度视图使得从概念到现金的价值交付得以提升，将技术改进与组织的更广泛商业目标和战略对齐。

Digital.ai 价值流平台的主要亮点如下：

• 多租户、专为云端托管或本地部署而构建。

• 共享服务（例如，用户管理、单点登录、授权）促进用户、工具、方法论和团队的无缝协作与对齐。

• CDM 和平台整合了来自各类工具和业务系统的数据。

• 分析视角提供了全景式的 360 度视图，使得业务和技术团队能够最终对齐并衡量技术投资对业务结果的影响。

• 智能软件生命周期编排应用 AI 和 ML，帮助可视化生产解决方案所需的所有工作，并识别延迟、瓶颈、交接和过多的在制工作。

• 内建的 AI/ML 能够识别潜在的变更失败并减少相关事件的平均修复时间（MTTR）。此外，它还可以回溯并调查跨越人员、流程和技术的技术变更问题的系统根本原因。

• 应用 AI/ML 模型，发现、预测并解决整个价值流中的问题，支持数据驱动的决策。

• 将开发成果与业务结果相连接，以理解技术投资对开发新功能和产品的影响。

Digital.ai 价值流平台提供跨团队、工具和流程的可视化。因此，组织能够有效地衡量价值和质量，如客户满意度和保持率、应用使用情况和安全性、执行效率、收入和增长。

除了支持所有主要的敏捷框架（Scrum、Kanban）和扩展框架（SAFe、DA、LeSS），Digital.ai 还提倡 VSM 方法论，优化人员、流程和技术，以持续改进从创意到客户交付的业务价值流。

在 Digital.ai 看来，衡量输出指标（如创建的功能数量、周期时间、开发速度和部署数量）只是 VSM 故事的一部分。

“我们还必须捕捉和衡量支持更好商业成果和用户体验的数据。因此，必须理解客户旅程中存在摩擦的地方，消除浪费和延误，增加客户的愉悦感。理解这一点可以帮助您的组织快速适应，并积极改善您的底线（成本、收入、客户生命周期价值、最终用户满意度等）。”

Mike O'Rourke，Digital.ai 副总裁兼首席研发官

Digital.ai 提供了一整套 DevOps 产品，帮助组织显著提高 IT 组织的精益产出，并将其与客户体验和业务成果连接起来。这种方法为潜在改进提供了前所未有的视角，能够推动业务成果的提升。

Digital.ai 为本书提供了两个案例。第一个使用案例来自一家大型美国保险公司，该公司使用 Digital.ai 的软件工具来支持其数字化转型活动：

图 12.5 – 第一个使用案例

以下是 Digital.ai 使用案例，突出了全球零售商使用 Digital.ai 软件产品提供跨不同工具的端到端可见性的经验，以及评估其价值流的效果：

图 12.6 – Digital.ai 使用案例

Digital.ai 官方网站: digital.ai/

GitLab

GitLab 被多家行业分析机构（如 Forrester Research 和 GigaOM）认可为价值流管理（VSM）领域的领导者。GitLab 本质上是一个 DevOps 平台提供商。GitLab DevOps 平台通过单一应用程序集成了计划、开发、运营和安全团队。GitLab 还强调其平台能帮助“团队将软件交付从几周缩短到几分钟，同时降低开发成本和安全风险。”

借助其端到端的 DevOps 平台，GitLab 实现了整个软件交付生命周期的端到端可见性。但由于 GitLab 在一个应用程序中提供了所需的工具，软件开发团队避免了所谓的 DevOps 工具链附加成本，即当团队还必须支持 DevOps 工具链集成和自动化能力的开发与维护时产生的成本。

换句话说，DevOps 工具链的附加成本是开发团队必须支持两项同时进行的软件交付活动的额外成本。一项活动支持客户产品的开发——从我们客户的角度看，这是增值工作。另一项活动支持开发 DevOps 管道环境——这不是增值工作。

GitLab 的价值流分析是一个开箱即用的功能，帮助团队可视化并管理从构思到客户交付的整体 DevOps 流程周期时间。GitLab 的价值流分析提供了一个统一数据模型中常见工作流程和指标的报告。

尽管可定制，GitLab 的价值流分析提供了默认的阶段来表示 GitLab 流程，包括以下内容：

• 问题 (追踪器): 安排问题的时间（按里程碑或通过将其添加到问题看板）

• 计划 (看板): 首次提交的时间

• 代码 (IDE): 创建合并请求的时间

• 测试 (CI): GitLab CI/CD 测试代码所需的时间

• 审查（合并请求/MR）：用于代码审查的时间

• 暂存（持续部署）：合并和部署到生产之间的时间

GitLab 还为八种类型的问题提供了默认标签：缺陷、已确认、严重、讨论、文档、增强、建议和支持。此外，GitLab 推广了其单击钻取功能，可以深入到工作项的层面，使团队能够在发现问题时立即消除阻碍。GitLab 还提供了范围标签和互斥标签（例如 workflow::edit 和 workflow::design），可以用于建模自定义工作流，之后可以通过看板风格的板块或洞察仪表盘进行可视化：docs.gitlab.com/ee/user/project/insights/#insights。

从软件交付团队的角度来看，GitLab 提供了一个单一工具，消除了管理分散工具链所需的工具集成和自动化头痛，从而维持一个成熟的 DevOps 流水线。最重要的是，GitLab 的 DevOps/VSM 平台策略使开发人员能够有时间交付价值，并且意味着他们不必花时间解决与管理 DevOps 环境相关的技术债务问题。

GitLab 的 VSM 页面可以在 about.gitlab.com/solutions/value-stream-management/ 找到。

HCL 软件

HCL 软件是HCL 科技公司的一个部门，开发并交付超过 50 款围绕 DevOps、数字化、物联网、云计算、自动化、网络安全和基础设施管理构建的创新软件产品。它是本次评审中最大的软体提供商之一，年收入超过 10 亿美元，拥有 4200 名员工，业务遍及 50 多个国家，并服务于超过 20,000 个企业客户。

HCL 软件 DevOps，如图 12.5所示，是该产品组合的关键支柱，提供一个完整且智能的企业软件价值流平台，涵盖从规划到生产、从大型主机到微服务：

图 12.7 – HCL 软件 DevOps

HCL 软件 DevOps 是一套最佳产品组合，产品之间松散耦合但高度集成，跨产品组合和 DevOps 工具生态系统。此外，一个开放的插件框架使企业客户能够快速将一个或多个解决方案连接到现有环境中。寻找全面 DevOps 解决方案的客户可以采用整个平台。图 12.5展示了这一产品集，其中包括以下内容：

• HCL Accelerate：一个智能的VSM 平台，通过与 DevOps 环境中的许多工具集成，促进持续改进，能够可视化价值流动、捕捉可执行的洞察，并自动化发布过程。

• HCL OneTest：一套集成的 软件自动化测试 工具，包括 UI、性能和 API 测试，贯穿整个项目生命周期。它提供一个无脚本、向导驱动的测试编写环境，支持 100 多种技术和协议。

• HCL AppScan：一套全面的 应用程序安全测试 和管理解决方案，涵盖 SAST、DAST、IAST 和 SCA，适用于 Web、移动和桌面应用，能够直接与您的软件开发生命周期工具和流程集成。

• HCL Launch：一个持续交付（CD）引擎，自动化应用程序部署、中间件配置和数据库变更，支持本地和云端的开发、测试和生产环境。

• HCL Compass：HCL Compass 是一个强大的低代码 DevOps 工作流引擎，使企业能够快速建立定制的流程，用于敏捷管理、质量管理、IT 服务管理等。

• HCL VersionVault：HCL VersionVault 是一个安全的企业级 版本控制和配置管理 解决方案。它提供对软资产的受控访问，包括代码、需求、设计文档、模型、原理图、测试计划和测试结果。

• HCL RTist：HCL RTist 是一个基于 Eclipse 的建模与开发环境，用于创建复杂的事件驱动和实时应用程序。它专门为软件工程师设计，提供功能丰富的工具，帮助进行嵌入式实时系统和物联网应用的设计、分析、构建和部署。

  HCL 软件 DevOps 解决方案旨在帮助最复杂的组织，特别是那些需要减少风险、管理成本和推动收入的受监管行业。许多改进可以通过 DevOps 第一天 解决方案来实现，这些解决方案主要聚焦于持续交付（CD）管道中的自动化。这些解决方案包括建立一个自动化的、受控的生产路径，通常通过 CI、CD、测试和安全工具来实现。使用 HCL 软件 DevOps 解决方案的这些做法的投资回报率（ROI）已经得到了充分的文献记录，总结为更好的质量、更快的市场响应、较低的成本和更高的员工士气。

随着 DevOps 进入第二个十年，HCL 发现其前瞻性客户通常专注于解决 DevOps 第二天 的挑战，主要包括以下内容：

• 将 IT 价值与业务价值连接

• 适应组织文化和对齐

• 在整个企业范围内推广最佳实践

• 优化端到端价值流的流动

• 在多种工具和多年的技术平台之间进行管理

• 减少安全和质量暴露带来的风险

• 将安全、质量和治理转移到左侧

• 提高生产发布频率

通过 HCL Accelerate 统一价值流，企业能够应对这些第二天的挑战。软件交付可以作为核心企业能力来建立，使 IT 活动与商业成果对齐，从而在这个数字时代获得成功。组织能够主动并有效地利用 HCL 软件 DevOps 创建商业敏捷性、安全产品和具有韧性的运营，如 图 12.6 所示：

图 12.8 – HCL 软件 DevOps 智能价值流

除了产品功能，HCL 还通过提供高质量的服务和支持体验来帮助客户成功，这种体验在大型企业软件供应商中是罕见的。这种方法源于 HCL 在 IT 服务业务中的根基，并且从首次接触到试点再到企业级运营都能切实感受到。早期阶段，技术顾问将主办免费的价值流研讨会，以识别改进机会并定义实现业务目标的路径。接着，客户可以利用 HCL SoFy（hclsofy.com）云原生环境，启动 HCL 软件 DevOps 产品实例，进行实际演示和试用。最后，当客户推进实施时，HCL 将为客户指派专门的客户支持人员，以便定期协作，确保实现最大化的业务成果。这种方法使得 HCL 在行业中获得了最高的 净推荐值（NPS）（NPS 60+）和深厚的客户成功。

想了解更多关于 HCL 软件及其 VSM 平台的信息，请访问 www.hcltechsw.com/DevOps/。

Kovair

Kovair 软件 是一家硅谷的软件产品公司，提供支持全球产品开发和管理的集成软件工具。历史上，Kovair 以其 Omnibus 集成平台 享有盛誉——这是一种 企业服务总线（ESB）平台，通过现成的集成适配器和插件，集成了 110 多种第三方（最佳实践）软件工具和其他应用程序。此外，Kovair 的集成平台还支持 DevOps、应用生命周期管理（ALM）和 项目投资组合管理（PPM）的需求。

然而，Kovair 还推动其平台支持数字化转型，并安装 VSM 解决方案，提供跨组织业务的可视化。在这种背景下，Kovair 正在对公司的产品进行品牌重塑，包括 Kovair VSMP（价值流管理平台）、Kovair VSDP（价值流交付平台）、Kovair PPM（项目和投资组合管理）用于 DevSecOps，以及将 Omnibus 作为其 集成平台即服务（iPaaS）的集成平台。

Kovair 的 VSMP/VSDP 解决方案已经能够将组织的数据、流程和来自传统 ALM 的应用合并到云端，支持 DevSecOps。例如，Kovair 的项目组合管理和基于 iPaaS 的 Omnibus 支持 VSMP 框架。同时，Kovair 将其 ALM 和 DevOps 平台推广为 VSDP 解决方案。

Kovair 通过工作流和政策引擎自动化工具链，帮助建立一个自动化的治理和可视化系统，涵盖所有商业沟通和最佳的第三方解决方案，包括新的解决方案，如智慧城市 5G 服务启用和数字化转型。最后，Kovair 还可以帮助 IT 从成本中心转变为价值中心，集成和管理业务成果。

尽管目前未被 Forrester Research 或 GigaOM 认可，但 Kovair Software 在 Gartner 的2020 年 DevOps 价值流管理平台市场指南中获得了认可，SD Times 也在其文章 价值流管理解决方案指南（SD Times，2021 年 1 月 6 日）中报道了 Kovair 的 VSM 能力。

Kovair 的 VSMP 解决方案作为捕捉收入机会的销售漏斗 CRM，提供与业务成果相关的 KPI 仪表板，这一点非常独特。换句话说，Kovair 的度量跟踪所有组织价值流和产品的生命周期成本，而不仅仅是软件。同时，他们将其价值流指标与预期和实现的收入联系起来，而不仅仅是成本节省。

Kovair 还推广其 VSMP，声称在以下领域提供独特的能力：

• 有针对性且系统化的减少浪费：Kovair 提供统一视图，帮助高级管理层通过中层管理到达运营、行政、销售和物流团队。这一能力使得可以在交付的每个环节及早发现瓶颈并消除浪费。

• 确保流程治理：Kovair 提供任务驱动的工作流，涵盖宏观和微观层面，以确保交付中每个团队的治理。

• 改善跨职能协作：Kovair 使得工具、流程和团队能够在混合基础设施环境中进行协作。

• 提升生产力：Kovair 提供跨越时间、资源和成本三重约束的完整可视性，通过高效利用资源来提高生产力。

• 提高流程效率：Kovair 提供通过其屡获殊荣的 Omnibus 多云 iPaaS 解决方案与最佳应用无缝集成，确保安全和高效。

• 持续的产品生命周期管理：Kovair 提供完整的项目和组合管理能力。

• 无缝的 iPaaS 集成：Kovair 提供与最佳应用的第三方集成。

• 并行的多模 IT：Kovair 提供多种 IT 方法论，包括瀑布式、迭代式、V 模型和敏捷（Scrum 和 Kanban），全部基于以流程为驱动的平台。

Kovair 的软件产品提供基于任务的工作流实施和可视化功能，涵盖关键的软件开发活动及相关数据，帮助产品团队发现改进领域，以优化价值流动。

Kovair 不会强制执行或推广特定的 VSM 方法论。相反，Kovair 允许现有或新的项目管理流程和方法通过 Kovair 的工作流引擎进行构思和部署，同时提供流程自动化、治理以及项目和投资组合管理。

读者可以在Kovair 软件官网找到更多有关 Kovair 平台的信息：www.kovair.com/。

Micro Focus

Micro Focus是全球最大的企业软件提供商之一。其产品提供可信赖且经过验证的关键任务软件，保障数字世界的正常运行。通过务实、严谨、以客户为中心的方法，企业可以在当今快速变化的市场中成功运营和转型。Micro Focus 的产品组合涵盖了 IT 运维、网络安全、信息治理、大型机、大数据和应用交付等多个领域。

Micro Focus 需要通过 DevOps 进行公司转型，赋能客户实现数字化转型，并推动自身业务增长。为推动这一变化，Micro Focus 创建了一个软件工厂，将其战略规划与一整套工具、服务、数据和流程整合，使公司能够规划、构建、测试、发布、运营和管理交付给客户的软件。

公司的转型之旅始于对如何交付和启用端到端价值流的差距分析。他们将这些活动分类为四个初步组成部分：计划（战略到投资组合）、构建（需求到部署生命周期）、请求到完成（R2F）和检测到修正生命周期（D2C）。随着产品通过链条中的各个活动，它们在每一步都获得了价值。价值链框架帮助 Micro Focus 识别出那些对战略推进和目标达成尤其重要的活动。

Micro Focus 的应用交付解决方案是软件工厂的关键组成部分。它们使团队能够快速行动，同时具备一个中央可视化点和符合业务目标的治理层。通过开放框架，团队可以整合广泛的工具生态系统，优化工作流，减少管理复杂工具链的开销，并提供持续改进的洞察。

Micro Focus 的集成解决方案方法使价值流参与者能够可视化并上下文化产品价值流中的活动，并跟踪跨多个阶段的流动和价值。在这些解决方案中嵌入了跨多个来源摄取并智能分析数据的能力，帮助观察趋势、识别瓶颈、发现相关性和检测异常，从而促进持续改进。

该方法解决了企业组织面临的常见挑战，如未能优先处理高价值的客户需求、无法追踪产品价值流的流动、以及对过程摩擦和执行约束的理解不足。关键产品包括以下内容：

• 项目与组合管理作为业务的支柱，确立战略愿景和目标，并与史诗、功能、产品待办事项和用户故事对齐。

• ALM Octane 作为中央神经系统，管理从规划到发布的工作、风险和质量。

• PulseUno 提供一个统一的、受保护的基于 Git 的开发者平台，跟踪代码、构建、审查和工件捕获中的变更价值。

• 功能（UFT）、性能（LoadRunner）和应用安全（Fortify）等连续测试解决方案，将自动化测试纳入软件交付管道，在每次提交、每个步骤或关卡，直到生产过程中。

• 部署自动化无缝实现了部署管道自动化，减少了周期时间，并在所有环境中提供关于部署和发布的快速反馈。

Micro Focus 采用软件工厂视角来安装 DevOps 能力。有关此主题的更多背景信息，请点击此处：

• 大规模 DevOps：如何构建你的软件工厂： techbeacon.com/devops/devops-scale-how-build-your-software-factory

• 创建软件工厂以发展 DevOps 并加速转型： www.microfocus.com/en-us/digital-transformation/our-perspective/software-factory

有关公司及其产品的更多信息，请访问Micro Focus 官网：www.microfocus.com/en-us/solutions/accelerate-application-delivery。

Plandek

Plandek 提供一个完整的敏捷和交付度量商业智能（BI）平台，提供客户软件交付周期的端到端视图。虽然它不是一个完整的 VSM 平台解决方案，但 Gartner 在其新的DevOps 价值流管理平台市场指南中将其平台列为全球前 10 大供应商。

他们的愿景是将数据科学应用于软件交付过程，提供智能洞察力，以更好地交付软件产品。团队使用 Plandek 的预测数据分析能力，揭示隐藏的风险，提升端到端交付性能，并解决他们在软件交付过程中最棘手的问题，诸如以下问题：

• 我们是否达到了敏捷、DevOps 和业务转型的目标？

• 我们如何帮助我们的敏捷团队更快、更可预测地交付价值？

• 我们如何客观地比较我们的软件交付团队的表现？

• 我们如何缩短市场时间并提高交付速度？

• 我们与行业内其他公司相比，表现如何？

• 我们如何为团队提供他们需要的度量，以便作为持续改进的过程？

SD Times 声称 Plandek 具有独特的集成和数据挖掘能力，能够与多个价值流交付工具集（例如Jira、Git、Jenkins、Azure 和 DevOps）集成，获取管道度量。此外，Plandek 的数据挖掘能力提供了从端到端管道的交付度量，揭示了模式，以便其客户可以做出明智的决策，提升软件交付的效率、质量、速度和可预测性。

Plandek 还提供可自定义的仪表板，展示关键度量和 KPI，使产品交付团队能够执行以下操作：

• 授权团队更快、更可预测和更频繁地交付有价值的软件。

• 降低交付和信息安全风险，并在大规模上改善治理。

• 将价值流度量和分析置于 VSM 计划的核心。

Plandek 在以下领域获得了高度评价：

• 技术栈和流程无关

• 一个无需协调层的分析解决方案

• 企业规模和安全性

• 提供软件交付管道的完整端到端视图

• 支持团队协作、持续改进以及产品可见性和报告

Plandek 提供了两个案例研究，以展示其度量和分析平台作为 DevOps VSM 解决方案的有效性。

图 12.7 总结了 Plandek 提供的第一个案例研究：

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/drv-dop-val-st-mgt/img/B17087_Figure_12.9.jpg)

图 12.9 – Plandek 客户案例 #1

而图 12.9总结了第二个 Plandek 客户案例的使用情况和结果：

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/drv-dop-val-st-mgt/img/B17087_Figure_12.10.jpg)

图 12.10 – Plandek 客户案例 #2

Plandek 提供了强大的 BI 功能，支持从工具链中收集的数据，以支持端到端 CI/CD 和 DevOps 管道活动的决策制定。

Plandek 的网站： plandek.com/

Plutora

Plutora 提供一个高度评价的 VSM 平台，已被 企业管理协会（EMA）、福雷斯特研究（Forrester Research） 和 GigaOM 评为行业领导者。它们也是 VSM 联盟 的创始成员之一。

Plutora 推广其 VSM 平台作为一个完整的软件交付管理解决方案，旨在提高时间到价值。在这种背景下，Plutora 平台为软件交付管理支持提供以下能力：

• 价值流管理：无缝地将产品负责人、发布和开发经理、风险与合规团队、工程与部署团队汇聚在一起，以交付价值并支持在整个软件开发生命周期（SDLC）中持续的端到端改进。

• 发布管理：定义并安排分层发布，追踪依赖关系，管理审批，并保持合规性，同时加速整个企业组合中的变更。

• 测试环境管理：集中管理预订，解决冲突，追踪系统依赖。消除易出错的手动配置管理和变更控制过程。

• 部署管理：帮助简化跨团队的部署过程，以最小化风险并加速切换事件。管理跨多个团队的生产切换活动的规划、审批、协调和执行。利用分析能力简化审计并为实施后的评审提供信息。

• 预测分析：通过定制化仪表盘展示的端到端集成和标准化数据，用户可以在企业规模上，从构思到生产的整个软件交付过程中，拥有唯一的真实数据源。

需要特别注意的是，Plutora 将其 VSM 平台定位为一个软件开发数据平台，提供必要的基础设施，以整合、自动化和编排软件交付管道。最重要的是，其以数据为中心的 VSM 平台、强大的分析引擎和通用数据模型，提供实时访问关键数据的能力，以便做出决策。正如他们所说，"这一切都体现在我们丰富的指标和仪表盘的分析和展示中，为组织提供了他们所需的洞察力，以便通过开发工作将最大的价值交付给客户。"

Plutora 认识到，许多项目管理工具内嵌了有用的 VSM 数据和分析能力。然而，决策者面临的挑战是如何在多个价值流仪表盘中导航，并理解端到端管道流程。因此，Plutora 推动了建立一个专门的分析平台的必要性，该平台能够从多个平台提取数据。

监督你的软件交付过程

Plutora VSM 平台提供了一整套工具，用于监督整个软件交付中的人员、流程和工具。无论管理方法论、自动化支持，还是组织使用的第三方工具，Plutora 的 VSM 平台都能正常工作。其目的是帮助企业扩大敏捷和 DevOps 战略的应用。

图 12.9以图形方式展示了 Plutora VSM 平台中的三大工具类别，分别是决策与分析、管理与协调，以及集成与通用数据模型：

图 12.11– Plutora 的 VSM 平台

Plutora 的平台在最顶层实施了决策与分析层，该层捕获、管理并提供与您的 KPI 相关的 SDLC 数据访问权限。此层还提供对流水线度量和预测分析能力的访问，以支持数字业务中的软件交付。

Plutora 的开箱即用的度量和报告功能（包括监控DORA 四个指标）提供了关于流水线流动的准确且接近实时的信息。此外，Plutora 的仪表盘展示了度量标准，涵盖了对比发布规划过程与面向业务的结果和优先事项的表现。

Plutora 最近发布了一个扩展的数据驱动 VSM 平台，提供了增强的 VSM 流动度量标准。这些流动度量帮助组织监控和管理价值流动，持续衡量软件交付流水线中的效率，精确识别瓶颈。凭借其数据驱动平台和通用数据模型，Plutora 的客户可以管理任何流水线、开发方式或工具的度量标准，通过数据驱动决策实现更大的业务成果。

Plutora 的管理与协调层在中间层提供了 DevOps 流水线流动的控制、可见性和自动化。此层的一个重要且近期的改进是 Plutora 的规划管理与价值交付功能，这得益于与规划工具的更深层集成以及跨不同工具的通用数据模型。Plutora 的通用数据模型一直存在，但新版本通过规划管理集成进行了增强；此外，公司还在平台中增加了更多的扩展性，以反映其作为成熟数据平台的变化使用情况。

丰富的数据提供了完整的时间序列和产品生命周期及软件交付流的变更历史。产品领导者可以利用企业级分析和报告工具，实现对整个投资组合的完全可见性，并生成可以识别软件开发过程中趋势和模式的基于时间的分析数据。

Plutora 的 VSM 平台提供了在不同的 CI/CD 和 DevOps 工具链中协调工作的手段。发布和部署管理是显而易见的协调应用。然而，同样重要的需求是，在混合环境中协调管道工作。例如，可能需要集成本地的应用程序，这些应用程序需要与云环境中的其他应用程序一起持久化。

集成和共同数据模型层提供了连接组织的 CI/CD 和 DevOps 工具、敏捷规划工具、项目投资组合管理（PPM）工具以及生产和后生产工具的能力，消除了使用集成中介来编写点对点工具链集成的需求。相反，平台的连接器整合来自不同工具的数据，并提供标准化的数据模型，支持跨 IT 价值流的端到端分析。这种集成和分析覆盖整个价值流，从构思到现金，包括面向敏捷和 DevOps 的人员、流程和工具。

作为价值流改进和投资组合管理工具，团队可以建模其价值流，存储和管理指标数据，并在管道活动中单独引用这些指标，或将其汇总到投资组合视图中。产品团队可以实施控制措施，如自动化或手动审核门，来管理构建、发布和部署活动。提供标准数据模型和集成分析工具，有助于可视化瓶颈和等待区域，支持决策制定，并为规划和资源配置活动提供输入。

使软件开发与业务目标对齐

Plutora 将其 VSM 平台推广为帮助填补业务目标和软件开发之间空白的工具，从而减少时间到价值的周期。他们进一步将此视为五个步骤的活动：

1. 管理您的远程软件工厂，通过智能仪表板使工作可视化，并自动化治理以提高组织绩效。

2. 创建单一事实来源，通过将不同的数据源整合为一个共同且标准化的数据模型，提供软件开发生命周期活动的端到端和实时视图。

3. 全面控制、可视化和自动化测试、部署规划和发布管理活动，协调多个管道从构思到生产，提高生产力，消除浪费，并管理风险。

4. 通过采用先进的 KPIs、指标和预测分析，全面提升您的软件交付过程，从而赋能您的数字业务。这里的核心理念是，您无法持续改进那些没有持续衡量和分析的活动。同时，通过自动化治理和合规要求，利用标准门槛和审计历史来管理风险。

5. 通过识别瓶颈、消除浪费、提高效率并缩短时间价值来实现竞争优势。

改善软件交付过程

Plutora 确定了 VSM 在改善软件交付过程中的许多潜在应用：

图 12.12 – VSM 的潜在应用

作为 VSM 解决方案，Plutora 提供了一个强大的集成、自动化和编排平台。其目标是通过使用 Plutora 的 VSM 平台能力，通过识别瓶颈、消除浪费、提高效率并缩短时间价值，来获得竞争优势。

Plutora 网站: www.plutora.com/

Quali

Quali 是另一家软件公司，虽然没有明确解决全面的 VSM 平台需求，但在任何 CI/CD 或 DevOps 流水线中提供必要的组件。Quali 的 CloudShell Colony 是一款用于实现 大规模基础设施自动化 的 SaaS 平台。更精确地说，CloudShell Colony 提供自助服务自动化和治理能力，旨在简化应用开发、测试和生产发布。此外，它的软件支持在云技术上部署和治理复杂的软件应用，包括 AWS、Azure 和 Kubernetes。

Quali 出现在这份名单中，是因为它支持自动化治理政策，这是 Gartner 在定义 VSM 工具时列出的三大类别之一：持续合规自动化（CCA）工具。然而，它必须作为附加组件购买，以支持企业内更广泛的 VSM 平台需求。

Quali 推广的主要产品以支持 VSM 计划是 CloudShell Colony，该产品于 2021 年 6 月 22 日正式更名为 Torque。我们的主要优势来自于持续关注将 应用中心化环境 作为主要组织结构来实际、甚至轻松地加以利用。

Quali 的应用中心化环境结合了应用、基础设施和数据资源。综合来看，凭借其所有系统性依赖关系和复杂性，作为一个完整的逻辑单元，它为持续设计、交付、操作、优化和治理开发及 DevOps 价值流所需的云基础设施资源提供了更好的方式。

表面上看，这似乎不是一个大问题，因为你肯定可以使用任何数量的工具和方法来单独或以某种组合自动化这些单独资源的配置和部署。然而，不幸的是，大多数工具都是围绕执行个别动作设计的，留下更大的背景、系统逻辑和依赖关系往往需要手动、单独地定义，并且往往不一致。

Quali 的 Torque 采用了相反的方式，基于开发人员和 DevOps 产品团队需要开发和部署的由多个资源类型和配置组成的完整系统的预期。最终，IT 运维团队负责交付、运行和管理产品所有者优先级的价值。

之前的陈述并不意味着仅有完整的环境才能由 Torque 按需设计和交付；恰恰相反。定义单一的资源类型并不限制未来自动化按需组合不同资源类型的能力，即将它们拼接在一起以便按需协作。用户还可以在初始部署后更换云服务提供商，而不会影响以应用为中心的环境。

另一个核心优势来源于 Quali 的产品 Torque 所设计的假设组合：

• 管理云成本和政策合规性对于成为业务的良好管理者至关重要，并且是识别低效并推动优化工作的重要数据源。

• 获取准确、及时且有用的成本和政策合规性数据很难做到，而且如果不引入会影响流程速度的摩擦，这个任务会变得更加困难。

• 环境及其支持资源很少从生命周期的角度进行部署，更不用说从生命周期的角度管理它们。产品本身以及它们支持的产品和价值流有一个有用的生命周期，之后它们应该被重构或退役。

Torque 通过自动标记资源使用情况，包括成本、政策和角色信息，来帮助满足成本和治理需求，这些信息与技术属性一起，通过 Torque 的报告和仪表盘进行分析，或可供其他工具进行分析。

Torque 也是从产品生命周期的角度构建的。以应用为中心的环境有一个预期的生命周期，按照定义，这有助于推动产品（在此案例中是环境）改进，并通过自动化退役未使用的资源来减少云资源浪费。

Torque 的另一个关键能力是其与 DevOps 工具链的利用和集成，使开发人员、DevOps 产品团队和 IT 运维团队能够更轻松地利用其自动化和编排功能。在这种背景下，Torque 成为了客户工作流程中的自然组成部分。例如，环境可以基于代码提交（触发 CI/CD 流水线运行）通过命令行、API 调用或 GUI 进行请求和交付。

Quali 认为，这些能力的总和积极影响并提供了额外的洞察力，帮助优化交付时间、周期时间、产出、在制品、流程效率和工作特征。

目前，Quali 并未推广或采用特定的 VSM 方法论。也就是说，他们指出，在与客户的互动中，他们最常遇到的两种框架或价值流概念是 SAFe 和 Gartner 的 DevOps 价值流。

Quali 提供了一个来自 Resident 的相关客户案例研究（图 12.10），他们认为这个案例展示了他们的产品即使在表面上看似现代的数字化企业中也能产生积极的影响：

图 12.13 – Quali 客户案例

Quali 在 IT/CI/CD 或 DevOps 以外的改进倡议中的主要价值在于其通过自动化蓝绿部署来促进更快速、更具体的应用发布和更新实验。例如，市场营销部门希望在一定时间内尝试一组新消息，而业务运营则希望在进一步推出新版本之前提供新的支付处理选项。Quali 的 Torque 产品帮助简化并加快反馈循环。

你可以通过访问他们的网站 www.quali.com/ 了解更多关于 Quali 及其产品的信息。

ServiceNow

ServiceNow 提供了一个统一的平台，Now Platform®，它集成、自动化、编排软件交付流水线流程。ServiceNow 将其 Now Platform 推广为提供“交付跨企业数字化工作流，连接人员、职能和系统，以加速创新、提高敏捷性并增强生产力”的能力。

该平台包含一个统一的数据架构，支持端到端流水线可视化和分析。因此，ServiceNow 用户可以通过其数据模型追踪从客户到开发者的流水线活动流。

ServiceNow 认识到，组织需要交付业务价值，而 VSM 提供了最佳的方法来管理和改善跨企业的价值流动。因此，ServiceNow 在这种背景下采用了 VSM。

ServiceNow 的许多客户仍在从项目型管理过渡到产品导向型管理策略。因此，DevOps 平台必须在短期内支持这些过渡，作为混合软件开发和交付环境的一部分。

ServiceNow 提供了广泛的功能，超越了 VSM，凭借其行业内工具密集的平台，提供了全面的产品范围。从概念上讲，ServiceNow 将其产品推广为支持数字工作流，以优化任何业务的工作方式：

• IT 工作流 用于优化 IT 服务运营，使投资与优先事项保持一致，并管理风险、安全和成本。

• 员工工作流 使员工能够在需要时更容易获得所需信息，通过支持基于价值的交付流打破壁垒，并提高生产力。

• 客户工作流通过定制的自助服务模型，创造无缝的客户体验并提高客户保持率，实现高效的服务交付。

• 创建者工作流帮助公民开发者和专业开发者通过低代码软件功能和连接的数字工作流，快速安全地构建跨企业应用程序。

ServiceNow 提供了软件行业中最全面的产品线之一，在其产品目录中列出了 47 款产品。然而，如果没有实施工作流功能，这些产品将仅作为点解决方案——与 VSM 一起作为实现精益导向改进的手段，广泛应用于整个企业。

VSM 解决方案产品

ServiceNow 工作流战略的关键是使用信息技术支持价值流交付流程的实施、可视化和改进，无论组织结构如何。或者，从实施精益改进的角度看，ServiceNow 工具帮助组织集成、自动化并协调其价值流流程。这种方法是组织打破阻碍高效价值交付的组织壁垒的唯一途径。

VSM 是客户可以利用 ServiceNow 平台采用的一种方法。根据客户希望采纳的用例和方法论，Now 平台上运行的各个 ServiceNow 产品开始发挥作用。

Now 平台提供了基本功能，如集成技术、名为 Service Graph 的标准数据模型、先进的分析和报告、行动工作流、人工智能和机器学习。图 12.11 提供了一个示例，展示了 Service Graph 数据如何帮助组织可视化流水线执行过程中的交互和结果：

图 12.14 – 可视化流水线执行过程中的交互和结果

一个用例的示例可能是软件产品价值流，在该价值流中，Now 平台提供了对计划、构建、运营和服务生命周期的连接性和洞察力。软件产品价值流中的基本 ServiceNow 产品包括 IT 业务管理、DevOps 和 IT 服务管理。

关键差异化因素和优势

ServiceNow 的关键差异化因素是其所支持的工作流和连接性在广度和范围上的表现。例如，在软件价值流领域，许多供应商专注于代码提交到部署之间的交付环节，而 ServiceNow 的方法覆盖了从客户需求到产品使用的整个价值流。

Now 平台还通过相同的单一数据模型连接到组织内的其他管理领域。例如，包括员工（HR）和客户服务工作流。

1. 流水线集成平台：

   a. 抽象化和关联的数据模型（涵盖多种来源类型）。

   b. 集成中心作为中央平台工具，提供与广泛目标（包括并超越 DevOps 工具和平台）的一系列现成集成的 API 和工具包，同时允许合作伙伴和客户轻松添加他们使用 ServiceNow 工作流和数据模型的集成。

2. 指标和分析：

   a. 从创意到生产过程中发生的情况，尤其是如果你已经在 ServiceNow IT 运营管理（可用性和性能）和 IT 服务管理（管理与治理）中管理生产，使用一个连接的数据模型。例如，显示变更失败率（一个常用的加速指标）非常简单，因为 ServiceNow 运行的系统知道何时发生变更以及何时失败。

   b. 现成的洞察仪表板，来自所有数据源的规范化数据使得跨团队使用不同 DevOps 工具的报告变得更简便。

   c. 完整的 BI 平台，支持深度分析、实时指标、时间序列分析、易于定制和个性化的功能，提供低代码/无代码的指标创建方法。

3. 连接或策略支持其他组织价值流的改进：

   a. 可以处理任何可以导入到 ServiceNow 的数据，并与组织中许多其他业务系统和基础设施监控器连接。

4. 工具支持 Dev 与 Ops 之间的集成、协作和编排：

   a. 一个信息和管理层通过量身定制的仪表板支持协作，针对每个角色或职位提供流量指标和基于 Dora/Accelerate 推广的现成 DevOps 指标。

到目前为止，我们已经讨论了 Now 平台的众多工具和功能。但同样重要的是我们如何运用这些工具来支持组织的 VSM 计划。

VSM 方法论

客户可以利用该平台和产品实施最符合其需求的方法论和用例。此外，ServiceNow 预计将聚焦于业务成果（包括捕获和管理财务数据、收集效率指标、识别改进领域）。

许多 ServiceNow 客户正在通过保持混合方式来实现从项目到产品的转变，这种方式在他们过渡期间发挥作用，意味着项目和程序管理职能可以在公司或程序层面运作，同时与规模化敏捷和基于团队的方法无缝协作。

支持超越 IT 组织的精益改进

ServiceNow 客户可以使用该平台从创意到生产，获取终端用户反馈，捕捉产品创意和需求，并通过 IT 业务管理为产品待办事项提供战略输入。他们还可以通过 ServiceNow DevOps 追踪交付过程，并通过 IT 服务管理或客户服务管理服务终端用户。

ServiceNow 应用程序中的可见性不仅限于流水线流动和其他精益改进指标的测量。例如，用户可以使用DevOps Pipeline UI视图显示每个应用程序的流水线阶段进展和详细信息，如图 12.15 所示：

图 12.15 – 设置用户创建的集成，用于额外的规划、编码和测试工具

这种端到端的工作流在单一平台上使用单一数据模型，为客户提供了对过程的卓越可见性，以及优化技术团队之外的价值链的机会。除了跟踪提供的价值之外，我们的平台还帮助捕捉价值流的成本，以便客户能够做出明智的投资决策。

客户使用案例

ServiceNow 提供了以下客户使用案例，作为他们平台应用实施端到端 DevOps 流水线解决方案的示例：

图 12.16 – 客户使用案例

DNB 使用案例的详细描述可在以下 URL 找到：www.servicenow.com/customers/dnb.html.

DNB 强调管理和利用其产品交付价值流以提升性能和效率并促进特定期望行为的重要性。因此，他们在以下条件存在时通过提供完全自动化的变更治理来鼓励开发者行为：

• 您实施了经批准的 CI/CD 流水线工具链，并且部署过程至少部分自动化。

• 您的流水线工具中需要的变更票据至少具有必填的最小数据集，以便自动批准。

• 您有一个设置好的流水线，分离用于生产、用户验收测试 (UAT)、系统测试和开发的环境。

• 您总是在专用环境中运行不同的测试。

• 所有测试均顺利通过。

• 您必须找到允许您部署到生产环境的时间表。

• 您的服务上没有重大或显著的事件。

DNB 的使用案例强调了本书中讨论的一个关键点，即需要实施基础设施即代码 (IaC)，以支持按需自动化测试和测试环境的供应。我们将在第十五章中重新讨论此主题，定义适当的 DevOps 平台策略，以及第十六章，通过 VSM 和 DevOps 转变业务。

读者可以通过访问他们的 DevOps 网站 www.servicenow.com/products/devops.html 了解更多关于 ServiceNow、Now 平台以及 VSM 方法的信息。

Tasktop

Tasktop是另一家行业领先的 VSM 平台供应商，获得了行业分析师的高度评价，如Forrester Research和GigaOM。该公司的核心信息是将企业转型为高性能的科技公司。

此外，其首席执行官兼创始人，Mik Kersten 博士，撰写了亚马逊畅销书《从项目到产品》(Project to Product)，帮助软件行业理解为什么我们必须从传统的基于项目的管理理念转向基于产品的管理结构和战略。Kersten 博士的书还介绍了Flow Framework®，该框架提供了一个管理框架和基础设施模型，帮助弥合商业与技术之间的鸿沟。此外，它还提供了从项目导向转向产品导向的过渡指南。

Flow Framework 帮助组织通过可视化和衡量价值流，将技术投资与商业价值对齐，涵盖了将软件或 SaaS 推向市场的完整活动集。它还提供了一个共同的语言，帮助商业和技术相关方设定优先级并衡量结果。

Tasktop VSM 平台，实施了 Flow Framework，旨在提供语言、度量标准和模型，以在任何工具链和任何组织结构中实践 VSM。它有两个主要应用，分别是Tasktop Viz™和Tasktop Hub，如图 12.13所示：

图 12.17 – Tasktop VSM 平台

Tasktop 的 VSM 平台实现了三个关键功能，这些功能通常在内部不存在：

• 掌握大规模软件开发的蓝图

• 一个强大的数据捕获和存储层

• 一个可扩展和自适应的商业视角，基于原始的事实数据

虽然该平台提供了广泛且复杂的双向集成功能，但这些连接也为数据和分析提供了可见性。与 60 多个敏捷和 DevOps 工具的连接器提供了管道数据，供可视化、决策和根据用户定义的规则触发事件。

Flow Framework 建立在一个集成模型之上，提供了构思、创建、发布和运营生命周期任务之间的连接。基于集成模型的是一个活动模型，该模型提供了由组织的价值流产生的工件的可追溯性。最后，一个产品模型将价值流活动与以客户为中心的交付对齐。

基于精益（Lean）的基础，Flow Framework 旨在改善流程以促进商业成果。但与传统精益改进实践中的标准工作和信息流程不同，Flow Framework 评估了软件交付中的四种 Flow Items（图 12.14）及其相对分布：

图 12.18 – Flow Items

流量分布模型代表了在功能、缺陷、债务和风险流动中可能出现的调整。这些调整是根据产品生命周期阶段情况而定，旨在最大化业务价值。

流量分布在帮助企业（产品/业务线所有者）和技术专家在调整流动时评估因果关系方面至关重要。例如，优化功能的流速以捕获新市场机会可能会牺牲其他关键项目的工作，例如修复错误和减少技术债务。错误会导致客户的负面评价，影响未来的交付和销售，而不断积累的技术债务会使未来增强功能的交付变得越来越困难和昂贵。找到正确的平衡对产品的长期成功至关重要。

与任何精益倡议一样，Tasktop 的流量框架中的指标和业务结果至关重要，如图 12.15所示：

图 12.19 – 流量框架：流量指标和业务结果

Tasktop 认识到许多大型组织出于对可见性和成本效益的紧迫需求，围绕 2-3 个核心工作管理工具来整合其 DevOps 工具链。

不幸的是，这些是以执行为中心的工具，旨在支持采用 Scrum、Kanban 或 Squad 方法论的小型敏捷团队。当高级领导监督数百万或数千万美元预算的技术从业者时，面向团队的工具过于分立，无法支持有效的决策制定。

此外，这些工具的端到端管道支持能力有限，不支持 PPM、UX 设计、合规性、信息安全、测试及其他参与软件价值交付链的 IT 从业者。最终，这些针对特定目的构建的工具和记录系统的需求变得明显，导致越来越多的分立工具和管道数据。

在这种环境下，组织无法叠加和抽象化端到端的价值流数据，包括所有其组成但分立的工具领域。因此，他们的高管可能会基于部分信息做出错误的决策。

Tasktop 指出来自 Forrester 报告的数据，指出业务线高管做出了 65%的技术购买决策。因此，IT 必须更加专注于创造业务价值和投资回报率（Craig Galbraith, Forrester, 2020）。

Tasktop 强调其能够提供专注于业务的可视性，以支持数据驱动的 IT 投资，帮助技术和产品领导者实施适合软件时代的管理框架。

此外，Tasktop 的产品替代了传统的纸笔价值流映射练习，将 VSM 的实践带入数字经济。Tasktop 工具支持的端到端视图生成了一个实时、共享且可操作的视图，帮助加速软件产品组合中的价值创造。

Tasktop 推广以下由其客户体验到的好处：

• 将上市时间缩短平均 75%

• 可以识别如何花费下一个资金

• 可以查看实时的价值流图，并标出其中的瓶颈

• 可以将工作重心从项目转向透明且可衡量的产品价值流

Tasktop 的 VSM 平台提供跨单个产品和整个产品组合的可视化。决策者可以利用这些信息来确定优先级，并解决导致延迟和瓶颈的问题。此外，假设分析可以帮助可视化流改进的潜在效益和成本节约。Tasktop 在其网站上列出了许多客户参考资料，您可以在www.tasktop.com/customers. 找到这些信息。Tasktop 的一些客户包括：

Figure 12.20 – Tasktop customers

更多信息请访问 Tasktop 的网站：www.tasktop.com/.

Apptio/Targetprocess

Targetprocess，在 2021 年 2 月被 Apptio 收购，基本上是一个帮助采用和扩展所有形式敏捷的软硬件平台。具体来说，该平台提供了一个视觉平台，帮助 IT 组织在其企业内采纳和扩展敏捷方法。此外，它还是一个全面的工具链集成平台。

在这种背景下，Targetprocess 支持诸如 Disciplined Agile、Large Scale Scrum（LeSS）、Nexus、SAFe、Scrum、XP 或定制构建的混合型敏捷框架等规模化敏捷方法，以实现业务敏捷性并改善整个组织的价值流。此外，Targetprocess 还支持在程序、产品和团队层面实施敏捷实践。

Targetprocess 支持通过原生集成 CI/CD 和 DevOps 流水线工具（如Jira、Azure DevOps、BitBucket、GitLab、GitHub、Jenkins 和 Phabricator）实现持续的软件交付。Targetprocess 还通过与产品管理、ITSM、销售和营销等职能所使用的工具（如MIRO、SalesForce、Zendesk 和 ServiceNow）的集成，帮助对齐这些职能的活动和目标。

Forrester Research 在其 Forrester Wave™: Value Stream Management Solutions Report（2020 年第三季度）中将 Targetprocess 排为强劲表现者，并在 Gartner 2021 年和 2020 年企业敏捷规划工具魔力象限中被评为领导者。

Targetprocess 通过实施目标与关键结果（OKRs）、财务控制和集成的分析引擎，帮助对齐业务利益。OKRs 的支持帮助组织观察到业务目标与相关开发努力之间的脱节。将业务职能与开发连接的能力是 Targetprocess 的优势之一。

Targetprocess 支持在其标准化数据模型中进行人力资源管理，覆盖管道活动，使计划者能够考虑资源成本、时间表和分配。Targetprocess 还提供了广泛的现成度量标准，这些度量标准是可扩展、可定制的，并且可以通过其工具集成在工具链中使用。

Targetprocess 网站: www.apptio.com/products/targetprocess/

ZenHub

ZenHub是另一个不是 VSM 平台的工具，但它提供了项目管理和项目数据展示功能，类似于 Atlassian 的 Jira 软件产品。然而，ZenHub 的方法不同，它们的一套团队协作和项目管理工具直接扩展了 GitHub 基于云的版本控制功能。

ZenHub 的软件产品在 GitHub 源代码管理仓库之上提供了一层抽象，提供项目管理、规划、工作流自动化和报告功能。此外，ZenHub 工具利用 GitHub 中已有的数据，为软件开发管道中的活动提供可见性、报告和自动化功能。

ZenHub 方法的好处是，软件开发人员和其他利益相关者不需要在外部系统（如 Jira 或 Asana 的产品）中维护记录。相反，ZenHub 的产品基于 GitHub 的提交记录直接自动拉取信息。因此，尽管其他项目管理软件供应商将 GitHub 集成到他们的产品中，ZenHub 的方法是直接扩展 GitHub。

ZenHub 方法减少了在多个不同工具中手动重新输入数据的需求，这些工具本来需要管理源代码和文档，并规划和管理软件开发活动。ZenHub 用户不再需要在多个第三方应用之间切换，而是在 GitHub 的 UI 内切换标签，使用已经共享并可用的项目数据。

ZenHub 支持通过连接、汇总和分发跨越史诗、故事、特性、变更请求、错误列表和技术债务工作需求的工作项信息来进行冲刺规划和估算。此外，ZenHub 还支持 VSM 需求，提供可视化和报告功能，显示工作进度和管道效率，并通过累积流图帮助识别瓶颈。

在撰写本文时，ZenHub 提供了七种工具，如图 12.17所示：

图 12.21 – ZenHub 软件产品

ZenHub 产品非常适合那些已经决定使用 GitHub 进行分布式版本控制和源代码管理（SCM）的组织。

本节结束了对领先 VSM 供应商的介绍。当你继续自行探索这个话题时，你会发现还有其他一些有着坚实资质的 VSM 供应商没有出现在本书中。主要原因是某些供应商没有回复我的查询，或者决定不参与采访。

概要

本章简要介绍了 19 家行业领先的 VSM 工具供应商及其软件产品。这些供应商进入我们的列表，是因为一个或多个 IT 行业分析师，如 Forrester Research、Gartner、GigaOM 和 SD Times，已对其进行评审并指定其在 VSM 工具和平台类别中有相关的产品。我们的评审重点是每个供应商的应用程序和优势。你还阅读了几个用例，展示了这些产品如何被用于改进 CI/CD 或 DevOps 流程。

在下一章中，你将了解四个领先的 VSM 方法论提供商，Disciplined Agile（DA）、Scaled-Agile、精益企业研究所（LEI）和 LeanFITT™。每个提供商都提供了实施 VSM 实践的方法。

问题

1. 判断正误：VSM 完全是一种基于工具的方法，用于在你的 CI/CD 和 DevOps 流水线中实施改进。

2. 判断正误：VSM 是一种面向精益的价值流改进方法。

3. 快速提醒一下，精益生产中常见的浪费类型有哪些？

4. 两位最初贡献于在软件开发中应用精益概念和价值流的思想的贡献者是谁？

5. Davenport 和 Martin 是从哪个角度或视角看待 IT 在价值流改进中的作用的？

6. 人工智能（AI）和机器学习（ML）在价值流管理（VSM）中的潜在应用是什么？

7. 在 CI/CD 或 DevOps 流水线中应用的三个关键能力是什么？

8. 从根本上讲，什么是 VSM？

9. 价值流管理（VSM）的根源是什么？

10. 难题：DORA 四个指标是 VSM 中唯一有用的指标吗？

推荐阅读

1. Martin, James. (1995) 伟大的转型。使用企业工程的七大纪律来协调人、技术与战略。Amacon。纽约，纽约

2. Davenport, Thomas. (1992). 过程创新：通过信息技术重新设计工作。安永 – 信息技术与战略中心。哈佛商学院出版社，马萨诸塞州波士顿。 www.researchgate.net/publication/216300521_Process_Innovation_Reengineering_Work_through_Information_Technology

3. Kersten, Mik. (2020 年 7 月 15 日) 价值流管理（VSM）的崛起。Tasktop 创始人兼首席执行官。 最初发表于 2020 年 7 月 15 日的 Tasktop 博客，也发布在 LinkedIn 上。www.linkedin.com/pulse/rise-value-stream-management-vsm-mik-kersten/

第十三章：介绍 VSM-DevOps 实践领导者

在本章中，你将了解当前领先的价值流管理（VSM）实践领导者。我们将从 VSM 联盟的介绍开始，VSM 联盟是一个非营利性贸易协会，由成员（供应商和企业）资助，向所有人开放，旨在通过研究、学习、网络交流和开源项目，支持价值流管理市场的崛起。

接下来，你将了解项目管理协会（PMI）通过其 DA-FLEX 服务实施 VSM 战略和方法的方式。PMI 收购了纪律化敏捷（DA）和企业转型流（FLEX），这两者在各自领域中都是成熟且公认的领导者，旨在建立其精益敏捷实践、培训和认证项目。DA 为 PMI 提供了软件开发中的敏捷实践。相对而言，互为补充的是，你将了解 FLEX 作为一个基于系统思维的框架，提供一套全面的组合管理、敏捷产品管理、执行/管理层、项目和团队成功模式，基于精益敏捷原则和实践。

接下来，我们将了解 Scaled Agile 的价值流管理方法，作为其Scaled Agile Framework™（SAFe™）的一部分。具体来说，Scaled Agile 将价值流管理作为其 SAFe DevOps 课程和培训的一部分。

在本章中，我们将讨论以下主题：

• VSM 联盟

• PMI 的 DA FLEX

• Scaled Agile Framework（SAFe）

到本章结束时，你将掌握三大领先的数字 VSM 实践领导者实施有效的价值流管理实践的方法的基础知识。

VSM 联盟

价值流管理联盟（VSMC）是一个新成立的组织，成立于 2021 年 3 月 3 日，旨在通过采用和推动价值流管理工具和实践，帮助全球组织交付客户价值。VSMC 的目标是通过领导力和社区支持，推动价值流管理标准和创新，为整个 VSM 社区服务。

定义 VSMC 的目标、使命和宗旨

VSMC 的目标是推动以价值流为中心的工作方式，在技术团队中领导更高绩效的组织。VSMC 作为一个非营利性贸易协会运作，其使命是培养并推动数字价值流管理的新兴市场，帮助社区学习、制定实践和标准，并通过其应用促进发展。

VSM 联盟对所有有兴趣将价值流管理作为业务转型和客户价值交付改进策略的个人和组织开放。VSMC 的资金主要通过会员费用筹集，但计划还将包括转售与 VSM 相关的学习产品。

从结构上看，VSMC 将精益实践和价值流作为其运营模式，其资金支持 VSMC 的研究、学习和外展价值流。

尽管由几家领先的 VSM 工具提供商成立，但其目标是让 VSMC 成员推动未来 VSM 方法和工具的增强方向。VSMC 成员还将在建立 VSM 实践知识库方面发挥关键作用。

通过协作建设 VSM 行业

VSMC 由五家技术领导者Digital.ai、HCL Software、Plutora、ServiceNow和Tasktop成立。其创始人为 VSMC 制定的章程是通过采纳价值流管理（VSM）帮助全球组织提升绩效并改善客户价值交付。

尽管在开放市场上是竞争对手，但这些创始公司认识到，要使 VSM 行业实现真正和可持续的增长，需要全球和行业范围的协作研究，以指导通过早期采用阶段开发的 VSM 工具、平台和服务。没有任何一家公司可以单独承担这项工作的范围。此外，研究必须是公正的，且不偏向任何供应商。

创始人从一开始就认识到将合作关系扩展到全球的组织和个人实践者的重要性。因此，创始人将 VSMC 建立为一个会员协会，面向与价值流管理实践和平台相关的企业和个人，以实现这一目标。

VSMC 主席 Helen Beal 提出了以下价值主张，以建立 VSMC 作为一个技术专家和实践者的专业社区：

“通过创建这个社区，我们将增加并加速 VSM 的使用，同时发展并灌输最佳实践和标准。最终，正如 VSM 本身的实践一样，我们将帮助行业从业者提供最大的价值。”

通过软件交付客户价值

VSMC 仍处于初创阶段，但旨在成为推动 VSM 实践、创新和采纳的首要专业组织。VSMC 的目的是帮助软件行业交付 VSM 产品和服务，帮助组织实现数字经济中具有价值的业务转型。

VSM 通过一个全面的软件生命周期编排过程实现这一目标，该过程为价值流经理、发布经理、DevOps 经理、产品经理和领导提供改进软件交付流水线所需的数据、可见性和分析工具。

引领 VSM 行业

VSMC 将作为一个关于价值流管理实践和采纳的中央信息和教育中心。持续的研究将帮助组织了解如何衡量价值，并因此成为更高效的组织。此外，培训和认证项目将支持全球会员的协作，帮助将 VSM 作为行业标准工作方式。

VSMC 与领先的分析师合作，运用科学可靠的原则进行信息收集和分析活动。目标是发现能够为采用价值流管理原则以提高价值交付绩效的团队和组织提供坚实指导的洞见。

正在进行中的产品

联盟的初步研究成果将是价值流管理现状报告，该报告将衡量团队如何应用价值流管理原则、实践和度量标准，进而影响其价值流管理的成果。VSMC 董事会已启动首份调查，初步结果将于 2021 年 6 月公布。

2021 年晚些时候，VSMC 将调查价值流映射的原则和实践，并与其会员社区合作，解决他们的具体需求和优先事项。第一门 VSMC 在线课程是价值流管理基础课程，计划于 2021 年 8 月发布。

尽管 VSMC 还处于初期阶段，价值流管理现状报告本身将成为帮助全球组织了解其他组织如何从 VSM 方法、工具和服务中受益，并根据情境提供最佳实践指导的有力工具。价值流管理基础课程将帮助实践者建立必要的技能，以帮助他们的组织有效地采用 VSM。随着实践的演进，VSMC 将制定新的指导意见，告知其会员。

来自初步 VSMC 报告的发现

截至本书写作之时，第一份 VSMC 报告尚未发布。然而，我已经看过初稿，摘要中的发现非常有趣。VSMC 主席海伦·比尔（Helen Beal）非常慷慨，允许我在本书中分享这些摘要发现。

"尽管在采纳 VSM 方面仍然存在重大挑战，但以下三个关键实践是更广泛采纳的证据：

• 组织正在识别价值流并围绕它们进行组织：

  随着组织需要不断创新，理解关键价值流、获取对其的可见性，并围绕它们进行组织以改善价值交付是至关重要的。

• 以产品为导向的团队比以项目为导向的团队更受欢迎：

  产品聚焦使团队更加紧密地与生产者-消费者关系绑定。价值是通过产品的消费者使用情况来确定的，而不是由项目或程序定义的抽象输出。

• 人们有专门聚焦于价值流中心化工作方式的角色：

  通过定义基于价值流的组织角色，个人了解自己的职责范围。拥有专门定义的角色，负责采纳并思考如何改变价值管理的方式，这是采纳这一概念的重要一步。"

  完整披露

  VSMC 董事会于 2021 年 4 月选举我担任顾问角色，帮助他们在以下三个领域：

  – 关于价值流角色和学习路径的指导

  – 将 VSM 与其他数字交付框架连接

  – 通过企业和咨询社区进行网络交流

这些初步发现令人兴奋，我期待帮助 VSMC 实现其学习目标，并参与这一探索之旅。

PMI 的 DA FLEX

项目管理协会（PMI）最著名的是其围绕传统项目管理实践的培训和认证项目。然而，PMI 于 2019 年收购了两家公司，规范化敏捷（DA）和 Net Objectives，以为其成员建立一个专业的培训和认证路径，帮助他们学习并应用精益敏捷实践。DA 专注于在软件开发中实施精益和敏捷实践。与此同时，Net Objectives 开发了企业转型流程（FLEX），这是一个基于系统思维的框架，提供了一个全面的产品组合、敏捷产品管理、高管/管理、项目和团队成功模式，基于精益敏捷原则和实践。

与其从零开始构建这些方法论，PMI 明智地选择了收购成熟的公司和方法论，以加速其精益敏捷认证项目和产品的开发。PMI 面前的工作是将这两种实践整合为无缝的产品。PMI 将其结合的精益敏捷方法称为DA，其企业级产品为基于 FLEX 的 DA 价值流顾问。

PMI 提供了五个培训和认证项目来支持其 DA FLEX 收购，具体如下：

• 规范化敏捷 Scrum 大师（DASM）认证

• PMI 敏捷认证从业者（PMI-ACP）® 认证

• 规范化敏捷高级 Scrum 大师（DASSM）认证

• 规范化敏捷价值流顾问（DAVSC）认证

• 规范化敏捷教练（DAC）认证

DASM 操作于单一和小型团队层面，而 DASSM 则指导如何让多个团队协作。此外，PMI 很快将发布一个多团队教练认证。最后，规范化敏捷价值流顾问（DAVSC）是 DA FLEX 在企业级的实施。

尽管许多 DA FLEX 认证对于学习基于敏捷的角色和实践有帮助，但与 DevOps 和 VSM 的主题无关。因此，本节大部分信息集中在 DAVSC 培训和认证项目上。DAVSC 结合了精益、流动、约束理论和组织发展理论与实践，作为 PMI 在价值流管理中方法论的基础性学习内容。

DAVSC 与 FLEX 之间的关系如下：

• DAVSC 基于对那些尝试提高组织创造价值能力的人员的工作任务分析。

• 支持这一点的系统是 FLEX。

• DAVSC 研讨会教授这些职责以及如何实现它们。

现在你已经了解了 DA FLEX 中精益敏捷（Lean-Agile）内容的范围，我们可以开始深入探讨 DA 工具包，看看框架是如何构建的，以及它是如何支持精益敏捷实践的。让我们从对 Disciplined Agile 核心理念的介绍开始，选择你自己的工作方式（WoW）！

将精益敏捷实践与支持你的工作方式相适应

PMI 并不将 DA FLEX 作为一个框架来推广。相反，PMI 将 DA FLEX 推广为一个工具包，包含了能够协同工作的实践。框架和工具包之间的区别很微妙，接下来我们花几分钟了解一下它们的不同之处。

从定义上看，框架提供了支持一个系统的基本结构，例如软件开发和交付。在概念层面上，软件开发框架提供了一种结构化的方法来应用精益和敏捷实践。例如，SAFe™和基于 Scrum 的扩展框架提供了一整套组织结构、事件和流程，以实施它们的精益敏捷实践。它们在实施精益和敏捷实践时采取的是非常规定化的方式，通过小团队角色、结构、事件和时间框架的开发周期来实施。Scrum 和 SAFe 的实践者在他们的框架内应用各种流程、技术和方法。然而，基本的结构和事件依然保持不变。

相比之下，DA FLEX 不同意“单一的精益敏捷实践实施方法适用于所有组织”的观点。相反，DA FLEX 提倡组织必须审视不同的策略和工具，评估哪些最适合其需求和文化。因此，PMI 将 DA FLEX 作为一个工具包来推广。基本思想是，价值流团队根据实际工作需要选择合适的工具。同时，作为一个工具包，PMI 将其 DA FLEX 工具包作为独立的精益敏捷方法，旨在改善价值流并将这一理念扩展到其他框架。

从哲学角度来看，DA FLEX 融合了基于价值流的连续流、精益改进、约束理论、组织发展和人类行为等概念。关键问题在于，围绕业务职能构建的层级化组织结构，与支持基于价值交付的精益流动是对立的。

在讨论 DA FLEX 如何支持价值流管理之前，我们需要花一些时间分别回顾一下每个方法：规范化敏捷和FLEX，以理解它们对现代精益敏捷实践的贡献。

选择 DA 的工作方式

DA 是由 Scott Ambler 和 Mark Lines 于 2012 年共同创建的一个过程决策工具包，帮助个人、团队和企业在特定情境下优化其工作方式（WoW）。Scott Ambler 和 Mark Lines 在软件开发领域非常有名，因为没有一种单一的软件开发策略能够在所有客户场景中取得良好效果。因此，DA 工具包的用户可以在六种不同的软件开发生命周期方法之间做选择，并根据情境指导选择数百种方法和工具及其潜在应用。

DA 工具包融入了过程刀片的概念，帮助团队和组织根据其独特的软件开发需求选择适合的过程刀片。进而，过程刀片引导用户如何应用所选技巧，提升关键的组织能力。

每个过程刀片提供了其哲学基础或思维方式，应用技巧的人员角色和职责，简化的业务流程描述作为改进业务敏捷性的流动，以及为应对情境需求而提供的选择。整体而言，思维方式、人员、流动和选择代表了 DA 工具包的四个视角。

除了四个视角，DA 工具包还提供了四个过程刀片级别，涵盖了基础、规范化 DevOps、价值流和DA 企业。如图 13.1所示，DA 工具包目前为 24 个定义明确的过程刀片提供了基于情境的指导：

图 13.1 – DA 工具包

如你在图 13.1中看到的，DA 工具包包括四个层次：基础层、规范化 DevOps、价值流和规范化敏捷企业。我们将在接下来的子节中更详细地探讨这四个层次。

在企业规模上实施精益敏捷实践

基础层是 DA 工具包的核心，指导着形成 DA 思维方式的基本原则和概念。该层还介绍了敏捷、精益和传统（串行）软件开发方法、角色和团队结构之间的基本概念和区别，以及选择 WoW（工作方式）背后的理念。

严谨 DevOps层提供了用于简化软件开发和 IT 运维活动的指导和技术。一个重要的区分点是 DA 的系统思维方法，帮助可视化和理解 DevOps 工作流背后的复杂性，如图 13.2所示：

图 13.2 – 严谨 DevOps 的工作流

如图 13.2所示的系统导向图，比价值流图或工作流图更为复杂。但你可以运用在第三章《分析复杂系统交互》中获得的知识，逐步理解该图。

价值流层结合了从 FLEX 获得的精益敏捷原则，你将在下一部分学习到。目前，理解 FLEX 是一种以精益为导向的方法，旨在提高价值实现。此层中的流程刀片提供了一个视觉地图和指南，以帮助在组织的互联价值流中进行基于价值的改进。

严谨敏捷企业（DAE）层提供了支持构建和维持精益敏捷企业的业务管理指导。DAE 的流程刀片帮助组织发展感知和快速响应市场变化的能力。

注意

想了解更多关于严谨敏捷的读者，可以阅读我之前的书籍，《在现代企业中扩展 Scrum》。

现在你已经对严谨敏捷有了基本的了解，接下来我们来理解 FLEX 如何通过生命周期方法，在 DA 工具包中实现精益导向的价值交付改进。

在我们讨论 FLEX 作为价值流管理工具的应用之前，我们首先需要了解 DA 工具包中的 DevOps 层。

使用 DA FLEX 实施 DevOps

DA 工具包为 DevOps 专门设立了一个完整的流程刀片层。DevOps 流程刀片包括以下内容：

• 严谨敏捷交付（DAD）：一种以人为本、学习导向的混合敏捷 IT 解决方案交付方法

• 安全性：描述保护组织免受信息、网络、虚拟和物理威胁的各种方法

• 数据管理：提倡一种务实、精简的方式，将数据视为关键资产，必须支持组织中的其他流程

• 发布管理：包括规划、协调和验证 IT 解决方案的部署到生产环境

• 支持：基于结果的技术，用于实施帮助台或最终用户支持，帮助客户使用你的交付团队所提供的解决方案

• IT 运维：基于结果的技术，用于管理和治理你的 IT 生态系统

Scott Ambler 和 Mark Lines 适当地得出结论，DevOps 现在是允许一个组织在数字经济中有效竞争的最低门槛。简化组织的 CI/CD 和 DevOps 管道流程所带来的竞争优势是无法通过传统的，甚至是基于敏捷的软件交付方法复制的。

PMI 对 DevOps 的贡献不在于工具链集成、自动化或编排能力。相反，它的 DA 工具包提供了关于实施和维护端到端 DevOps 基础设施和管道流的全面指导。

由于本书的这一部分主要聚焦于价值流管理，接下来我们将看看 DA FLEX 如何通过 DA 工具包中的价值流层，帮助组织完成以精益为导向的业务转型和改进。

使用 FLEX 实现业务敏捷

FLEX 为 PMI 提供了一种基于精益思维和系统思维模式的行业领先的业务敏捷实现方法。FLEX 的开发者 Al Shalloway 定义了组织的业务敏捷性为快速、可预测、可持续并高质量的价值实现。

通过 FLEX，组织使用精益原则来发现系统层面上哪些地方不起作用以及原因。但同样重要的是要注意，FLEX 是 PMI 用于实施价值流的全新方法，旨在利用价值流管理技术改进价值交付。

企业转型是 FLEX 的一个关键目标，它构成了FLEX（企业转型流）缩写的基础。换句话说，FLEX 通过有效实施价值流来推动企业转型。

DA FLEX 将组织的战略与价值交付层面活动的执行相连接。DA FLEX 方法帮助组织简化其复杂的业务系统，以暴露出更有效的价值流，从而使你能够在整个业务系统的背景下做出改进组织各个部分的决策。

虽然企业需要创新以提高竞争力，但它们也需要改善价值交付。在这种背景下，DA 工具包中的价值流层中的过程刀片建立了支持组织产品和服务的端到端价值实现活动。

就像我在早期职业生涯中一样，Al Shalloway 也深受 Eliyahu M. Goldratt 的《目标：持续改进的过程》一书的影响，该书向我们介绍了约束理论（Goldratt，1984，2014）。尽管像 VSM 这样的精益改进计划强调识别瓶颈作为引入延迟的关键点，Goldratt 的研究则帮助我们更深入地评估导致生产延迟的约束因素。

例如，我们可能有一个较慢的流程，或者多个工作项通过我们的流程管道流动。我们可能面临系统设计无法承载过多工作量，或者缺乏足够的可视化以便在问题发生时及时察觉。或者，我们可能有过于繁琐的流程和审批，限制了流程流动。

FLEX 方法帮助价值流团队识别瓶颈、导致瓶颈的浪费，并评估消除或减少这些浪费、改善工作流的方法。FLEX 方法是一种 VSM 方法论，包含以下步骤：

1. 定义基于价值的工作流和组织结构。

2. 识别实现期望流动和结构的障碍。

3. 确定消除障碍的潜在解决方案。

4. 应用系统思维和精益思维来定义在组织文化中工作的改进优先级。

5. 按照优先级实施建议的解决方案，并根据预定目标和指标评估其效果。

6. 持续分析、重新规划并重复 FLEX 过程。

在阅读这一部分时，重要的是要注意，FLEX 明确设计为支持以知识为导向的工作。此外，Al 对于价值流管理角色的当前思考，涵盖了一个全面的组织视角，这一视角来源于他多年精益敏捷咨询经验所获得的洞察。以下部分将详细介绍这些洞察。

在 DA FLEX 中定义价值流

DA FLEX 以与其他精益学科一致的方式定义了价值流，正如在维基百科中所描述的那样：en.wikipedia.org/wiki?curid=55610257。

价值流

一系列从最初请求到客户价值实现的过程中添加价值的行动。价值流始于初步概念，通过不同的开发阶段，最终到达交付和支持阶段。

正如你在第七章《绘制当前状态（VSM 步骤 4）》和第九章《绘制未来状态（VSM 步骤 6）》中所学到的那样，DA FLEX 指出，价值流总是以客户为起点并以客户为终点。他们还区分了价值流中的工作与执行这些工作的人员。他们的关注点是，将二者混淆会对组织造成不利影响，因为价值流有着单一的关注点，而人员可能支持多个价值流的工作。

另一个关键点是，组织必须从关注人员的利用率转向关注价值流的产出。虽然职能型组织结构可以提高在开发关键技能和能力方面的局部效率，但从执行精益价值流的角度来看，它们同时也会带来等待、瓶颈以及其他形式的浪费。

图 13.3 显示了工作在价值流中流动的图示（绿色箭头），以及传统层级管理的叠加（红色箭头）：

图 13.3 – 工作在价值流中流动，带有层级管理叠加

因此，在传统的管理结构中，工作流程通常是单向流动的，水平方向上作为跨职能的流动，而决策和批准则在职能层级内部垂直流动。所以，DA FLEX 首先提出的问题是，谁在管理价值交付的端到端流程？

这是一个值得提问的好问题，因为在传统模型中，并没有单个人负责管理产品流动。相反，它是通过委员会进行管理，委员会内部有着冲突的议程和目标。因此，首先我们必须解决这个问题——一个组织结构对齐的问题。然后，我们需要确保已经定义了高效且简化的流程，最小化浪费。

最终，改善组织价值流的目标是提高业务敏捷性。由于 FLEX 在 DA 工具包中实施了价值流层，让我们来回顾一下 FLEX 如何帮助组织发展其价值流，从而提升业务敏捷性。

使用 DA FLEX 提升业务敏捷性

DA FLEX 将业务敏捷性定义为：在最短的时间内、持续一致地、以高质量的方式实现最高的业务价值。通过在所有价值流中交付增量价值，组织可以在需要时灵活调整，并以最低的成本改变方向。

这种灵活性使得那些在组织的价值流中传递价值的人员面临的风险和压力更低。在这种背景下，DA FLEX 教导我们，改善价值流的主要目标是建立业务敏捷性。

使用 DA FLEX 应用系统思维

DA FLEX 采用整体视角来改善组织，使用你在 第三章《分析复杂系统交互》中学到的相同系统思维概念。回想一下上一章，系统思维是通过分析参与系统的所有元素之间的交互来评估复杂性的。随着元素的增多，由于潜在关系和后果性影响的数量呈指数级增长，系统的复杂性也随之增加。

DA 工具包中的 FLEX 方法在价值流上应用了相同的系统思维原则。我们需要优化整个业务系统。局部优化几乎总是无法达到预期效果，除非我们在前期工作中确保变革解决了影响整个系统表现的浪费领域。

在他的讨论中，Al Shalloway 指出，我们不能运用还原主义思维来解决系统中的复杂问题。例如，Al 指出，如果我们尝试用所有最好的零件来组装一辆汽车，我们将无法制造出一个正常运转的汽车。你甚至不会得到一辆汽车，因为这些零件根本无法一起工作。

Al 使用的情景源自 Russ Lincoln Ackoff 教授 1994 年在由 Clare Crawford-Mason 和 Lloyd Dobyns 主持的活动上的演讲，旨在捕捉 W. Edwards Deming 博士的学习和遗产。当时，Ackoff 博士是宾夕法尼亚大学沃顿商学院安海斯-布希管理科学荣誉教授。

演讲题目是如果 Russ Ackoff 进行 TED 演讲：www.youtube.com/watch?v=OqEeIG8aPPk。花几分钟观看这个演讲是值得的，因为他阐述了为什么局部优化永远行不通的观点。

在 Ackoff 博士的讨论中有很多值得深入探讨的地方。例如，他谈到了持续改进和非连续改进的区别。他的观点是，持续改进适合追随者，而这些追随者永远不可能领先。相反，领导者通过非连续改进来领先竞争对手。换句话说，领导地位是通过创新而来的。

Ackoff 博士提出的另一个关键观点是，他同意日本对整个汽车工业质量改进的积极影响是不可否认的。但他也指出，尽管日本做对了事情，但他们正在做错误的事情。他在 1991 年发表了这一声明，对我们城市中的污染和拥堵问题提出了异议。Ackoff 的讨论早在气候变化成为前沿关注的问题之前就已经进行了。

Ackoff 博士指出，效率与有效性之间存在差异，质量需从后者角度来看待。他将效率比作知识，而将有效性比作智慧。因此，从系统角度来看，质量必须在提供价值的同时同时解决效率和有效性。换句话说，我们需要在知识之外应用智慧。

简而言之，如果在驾驶更高质量的汽车的同时，它们却在破坏我们的环境和整体生活质量，那又有什么好处呢？因此，我们需要从全面的角度看待质量及其对提供客户最有价值产品的贡献。

将人们融入我们的框架中

在精益和敏捷实践中，框架提供了完成工作的系统或模式。然而，DA FLEX 对框架背后的概念提出了异议，因为它们未考虑到使用这些框架的人。例如，似乎过于限制或与组织文化和运营系统相悖的框架，往往会导致摩擦和抗拒。

DA FLEX 方法通过其 WoW（工作方式）概念，正是为了应对过于规范化的框架未能从系统思维的角度处理框架内部人员之间复杂的相互关系。换句话说，无论采用精益还是敏捷方法，我们都需要从系统角度处理人员、流程和事件之间的互动。因此，DA FLEX 方法通过组织化的过程“刀片”实现其工具包，每个刀片都包括相关的方法和工具集，组织根据具体情况在其价值交付系统中运用这些工具集。

协同价值流

精益思维通过协调信息、人员和物料的流动，围绕价值交付目标来管理系统的复杂性。换句话说，尽可能地，我们消除了让系统组件参与那些不支持我们价值交付目标的互动的可能性。

DA FLEX 在 DA 工具包中实现了其价值流层，以帮助组织识别跨组织的多个价值流。所有这些价值流都支持产品交付，并且必须以高效和有序的方式进行。

这意味着我们不能仅仅孤立地看待构成组织的各个组件。我们的价值流是系统，我们需要管理参与组件之间的关系。积极的一面是，价值流为我们的价值交付流动提供了可见性。它们还简化了价值交付过程。

关于这一点，Al Shalloway 提出了以下观点：

“尽管抵制变革的原因有很多，但它们通常表现为局部优化。鉴于许多组织中存在恐惧情绪，且很少有方法能够真正关注价值流，这一点并不令人意外。”

换句话说，组织围绕其商业运作方式发展文化，而这种运作方式受到其传统的层级化和职能化组织结构的高度影响。因此，业务流程往往支持职能领域内人员的本地化目标和任务。虽然这些流程可能已针对部门需求进行了优化，但可能并未在支持基于价值的横向业务流程方面得到优化。

但我们也需要理解的是，最上游的活动对下游活动有最显著的影响。这意味着，如果没有及时发现，价值流开始处的问题可能会扰乱整个价值流交付系统，而且可能很难隔离问题的根本原因。

组织通常有多个价值流来支持其整体的产品开发和交付能力，这些价值流是相互关联的。例如，产品管理为产品积压的接受过程提供信息，而该积压则属于一个面向开发的价值流。

虽然在价值流中添加、修改或删除活动相对简单，但由于可能对多个价值流产生影响，增加新的价值流对组织来说却更加具有破坏性。此外，相互关联的价值流会形成一个更大、更复杂的系统，涉及相互联系的活动。因此，我们希望在启动 VSM（价值流管理）计划时，就开始考虑端到端的流动。

吸引高层管理人员和经理的参与

回顾我们对 FLEX 的介绍，它本质上是一项商业转型活动，通过精益敏捷的组织结构和实践来提高价值交付。因此，DA FLEX 在战略层面操作，因此需要高层管理人员的支持和赞助。

在这个话题上，Al Shalloway 提出了以下观察：

“高层管理人员常常误判价值流中的挑战所在——他们通常认为问题出在开发区域。正确的价值流管理——特别是工作和延迟的可视化——可以帮助让系统的真正瓶颈显现出来，而高层管理人员通常只是看到他们所做的事情的后果，而非原因——而这个原因往往是他们所做决定的结果。”

DA-VSC（敏捷项目管理及价值流优化）毕业生学会如何为高层管理人员和经理们举办工作坊，讨论他们的客户，以支持组织的战略商业转型目标。理想情况下，所有人会聚集在一个房间里，房间内至少有一块大型白板，因为这些会议有时涉及 30 到 40 人。

组建的团队将白板分为两个部分：一侧是面向业务的价值流，另一侧是面向实施和支持的价值流。在两者之间是一个接受队列，其中列出了组织需要关注的、以实现预期商业转型的业务改进工作项。

Al Shalloway 将接受队列称为最小商业增量（MBIs）的列表。MBI 代表的是以产品、服务或结果的形式交付的最小增量价值。团队从业务角度评估每个 MBI，其中每个交付项都满足目标客户的需求，并符合企业批准的战略。

如你在图 13.4中所见，业务部分进一步划分为投资组合和产品管理职能。同时，板上的实施和支持部分有展示开发输入、开发、集成以及部署与支持活动信息的区域。

图 13.4 – 按阶段划分的规范化敏捷过程目标

投资组合管理价值流引导支持实体任务和战略的投资。目标和指标描述了高管希望通过战略达成的成果，以及用于衡量目标达成的量化指标。每项投资都衍生出一个倡议，在其生命周期内根据既定目标和指标进行跟踪。倡议在业务积压中进行管理。

产品管理价值流涉及一个发现工作流，用以评估价值流交付需求，以满足组织的战略、目标和指标。这些已发现的业务需求定义了在更细粒度层面上实现业务转型所需的交付项。这些业务改进工作项在作为任务进入输入队列之前，会进行评估和优先级排序。

输入队列形成了业务与实施和支持职能之间的边界线。从这一点开始，工作项遵循基于精益敏捷的开发和交付流水线流程。

我们的数字经济中的几乎每个价值流都依赖于软件、硬件、安全性和其他基础设施组件，以提高业务敏捷性。因此，当数字化增强能够促进价值流动时，DevOps 是首选的开发和交付流水线策略，因为它是最有效的 IT 价值交付系统。

尽管 IT 组织的参与程度各不相同，但价值流的实施和改进活动遵循一种精益敏捷流程，涉及跨越开发输入、开发、集成和部署与支持的流水线流动。

聚焦解决方案团队

FLEX 方法实现 MBI 的方式是围绕聚焦解决方案团队结构组织人员。解决方案团队以产品为中心，采用敏捷方式运作。换句话说，聚焦解决方案团队的任务是定义满足 MBI 需求的解决方案。

通常，MBI 的规模过大，无法由单个小型敏捷团队开发。在这种情况下，FLEX 将解决方案团队拆分为特性团队和核心团队。特性团队具备完整的技术技能和资源，能够开发所识别的产品特性。相比之下，核心团队通常包含专家，负责支持特性团队。例如，核心团队可能会处理平台配置、集成以及工具链自动化，并在必要时增强特性团队的能力。

在某些情况下，可能需要借调资源，甚至临时聘用资源。在这种情况下，借调的成员会按照分配继续留在解决方案团队中的特性或核心团队，并参加借调团队的每日站会。然而，与核心团队不同，借调成员还可以继续支持他们通常分配的职责，并参加原团队的每日站会。

特性团队和核心团队都使用基于看板的生产控制系统，从产品待办事项中拉取工作项。他们还通过协作来交付 MBI 的产品。

在解决方案团队中的成员 100%致力于该团队的工作。请记住，任务切换/多任务处理是浪费的形式，它会妨碍生产力，因为人们必须花费非增值时间从中断的地方重新进入状态，从一个任务转移到另一个任务。

现在我们已经了解了规范化敏捷和 FLEX 如何在 DA 工具包中运作，让我们继续了解 DA 如何支持多个产品团队的协作工作。

将多个团队与精益敏捷思维对齐

本节解释了 DA FLEX 如何支持精益思维的三个关键原则——系统思维、管理为团队创造工作背景和消除延迟——在软件开发中的应用。在阅读本节时，请回想一下，精益价值流是组织的增值工作流，从概念到消费。另外，我们快速浏览一下 DA FLEX 中精益的三个原则：

• 系统思维：将业务视为一个复杂且高度集成的系统，要求参与的各个元素以协调的方式共同工作以实现其目标。

• 管理监督：管理层必须创建并传达指导团队工作的背景，使其能够以支持业务战略和目标的方式自我组织。

• 消除延迟：消除等待的浪费。在软件开发中，这意味着我们在准备好处理时才创建需求，不会在没有定义需求、确定接受标准以及没有具备快速集成和测试的基础设施的情况下编写代码。我们还必须消除从犯错到发现并修复错误的延迟。

DA 将其原则作为指导，而非强制性规定。事实上，DA 的核心思想是为人们和组织提供更多的选择，以支持他们特定的情况。我们将在下面的小节中探讨 DA 如何鼓励选择。

建立一种新的纪律性

重要的是要理解，纪律化敏捷这一术语并不意味着要推行一种过于强硬的敏捷改进方法。相反，DA FLEX 认识到，过多的管理、过度的计划、过度的设计和过于庞大的项目都是无效的，注定会导致软件项目失败。然而，Al Shalloway 也指出，不守纪律的团队将敏捷作为借口来逃避做必要的事情，也是无效的……顺便说一下，这样的团队根本不算敏捷。

敏捷的起源可以追溯到所谓的轻量级软件开发方法，并且发展到协调小团队的工作，以提高软件交付表现。但我们也需要方法来提高企业规模的敏捷性，以增强我们的端到端价值交付能力，通常涉及多个价值流。

跨团队的依赖关系需要更高的纪律性，以解决整个企业范围内的集成、自动化和编排问题，涉及价值流的各个方面。不幸的是，团队中的团队模型在扩展敏捷时存在问题，因为它形成了一个新的职能模型。结果，每个团队都无法理解自己在价值流中的贡献。换句话说，团队往往专注于孤立地解决跨团队问题，而不是从整体上看待自己在价值交付系统中的参与。

从这个角度来看，我们或许可以简单地推断，Agile 的小团队概念可以在大型或多团队环境中工作。但这种观点忽视了一个事实，即团队成员之间的动态与团队之间的动态是截然不同的。

因此，我们需要将敏捷的小团队模型扩展到解决本地开发和运维问题，同时实施以精益为导向的流程，以协调和提高整个组织各个价值流的交付速度。这一战略正是精益敏捷学科的核心。

精益敏捷方法改进了组织工作流，以消除接收反馈、检测错误、使用信息的延迟，并最终交付价值。在这种背景下，软件开发工作必须支持更广泛业务系统及其价值流的集成、自动化和编排需求。

聚焦于价值流的流动

DA FLEX 是一种面向企业全局的敏捷扩展方法，应用精益敏捷（Lean-Agile）概念来提升多个团队之间的价值交付。DA FLEX 在团队之间实施精益敏捷流程。通过聚焦工作和信息流，确保每个人都同意在价值流中的特定节点做出决策，便可以实现多产品、多团队的敏捷性。

尽管我们可能仍然在纵向管理人员，但我们需要横向管理价值交付流。回想一下我们关于图 13.3的讨论。

价值流始终是横向的。纵向衡量资源的利用情况，在职能部门内，甚至在分散的团队之间，都会与价值流产生脱节，从而导致局部优化，几乎没有机会提升组织的整体生产力。因此，我们最核心的衡量指标是评估市场响应时间，以辨识导致延误和增加成本的瓶颈。

理解 DA FLEX 背后的纪律

在前面的建立一种新型纪律一节中，我们提到过，DA FLEX 建立了一种新的纪律，使多个团队能够有效协作，从而改善流程。我们当时没有说明这些纪律是什么，但现在会说明。DA FLEX 推广了三种纪律，旨在提升多团队的表现，如果你仔细阅读了本书，这些纪律应该对你非常熟悉：

• 纪律 #1：利益相关者不能启动比开发组织能够承担的更多项目。确保这一点的最佳方法是采用面向拉动的生产控制系统，例如看板（Kanban）。

• 纪律 #2：交付所选价值的团队必须协同工作。大型软件组织中可能会将工作分配到不同的产品、组件、功能或大规模需求上。分拆的团队总是存在依赖问题。

  如果每个团队维护自己的产品待办事项，并以对他们高效的方式拉取工作项，这些依赖关系变得更加难以解决，这本质上是一种局部优化。我们需要一个统一的产品待办事项，并确保所有团队根据该待办事项的优先级拉取任务。

  此外，每个团队的工作必须集成到一个共享的源代码控制库中，新的单元级代码需要定期进行测试，通常是每天多次测试，与主干代码进行对比，以确保新代码不会引入 bug。随着代码的增长，发现和修复这些 bug 变得越来越具有挑战性。

  最后，我们需要频繁地向客户发布增量，供他们进行审查和测试。如果我们等到客户不喜欢我们所做的东西，那时进行更改会变得更加困难。

  精益思维方法实现了最短的可行周期时间（从构想到消费），并在我们的价值流管道中具有最少的延迟。理想情况下，我们希望整个价值流系统中都能内建快速的客户和产品测试反馈循环。

• 纪律#3：团队必须让看到大局的人来决定他们应该做什么工作。这句话可能看起来像一个显而易见的评论。但在这里犯错比很多人认为的要容易得多。高层管理者必须向价值交付链上下传达业务战略、优先事项和目标。他们必须实践 Gemba，亲自去了解战术层面的情况。并且，他们必须征求从事工作的人员的意见。

  同时，价值流操作员无法决定他们应该专注于哪些工作或他们的产品待办事项优先级应该是什么。只有产品负责人拥有这一权力，并且在做出产品待办事项优先级决策之前，他们会明智地寻求团队及其成员的建议。具体来说，他们必须向价值流团队寻求建议，以获取有关已识别的缺陷和可能导致未来状态或下游问题的技术债务的实时信息。

赋予选择权是一件好事

在这一部分，我们讨论了使用有纪律的多团队方法来提高敏捷性的问题。事实证明，赋予选择权是构建和维持精益敏捷业务系统的有纪律方法的一个关键组成部分。

赋予选择权并不是看起来的那样自由放任。要实现组织一致的目标，团队之间必须有纪律性，以便能够协作。但规定预定义的流程和任务的方法则由执行工作的人员决定。不幸的是，传统的瀑布式项目管理实践倾向于规定什么做和如何做。

规划者过于频繁地几乎完全依赖于他们公司 SDLC 中定义的所有实践——或许认为更多的实践就是更好。但事实并非如此。组织的 SDLC 流程、分类法和推荐的活动依赖关系往往使项目计划过于臃肿，加入了不必要且没有价值的任务。

DA FLEX 提供了数百种技术，但很少会有超过几种适用于任何特定的软件迭代。因此，团队仅选择那些最能支持当前需求的模式和技术。而且，只有评估这些技术的团队才能了解哪些技术对他们的特定需求有帮助并能应用。但同时，拥有一个预定义且具有情境价值的实践库也是有帮助的，这些实践可以重复使用并根据每个新应用的情况进行调整。

本节完成了我们关于通过 DA FLEX 方法实现多个团队对精益思维对齐的讨论。现在我们来回顾一种经过验证的方法，成功推动整个企业范围内采纳 DA FLEX。

采用 DA FLEX 模型

成功采用 DA FLEX 通常围绕着几个核心概念，具体如下：

• 从一开始就专注于定义和建立价值流：

  – 你必须摒弃基于项目的或其他推动型的生产控制方法。

  – 相反，采用以产品为导向的关注点，使用拉动型生产流程，并提高整个组织的价值交付。

  – 假设你跳过了本书中的一些章节。那么，这意味着我们通过消除浪费、围绕稳定的节奏精简工作流，并且仅在下游产能可用时按需拉动产品，从而寻求更高效的物料和信息流。

• 根据组织的文化和采用的原因来评估适当的采用节奏：

  – 例如，将 DA FLEX 应用作为潜在的竞争优势是一个动机层次，但与那些已经面临迫切平台情况的人有着很大的不同。

  前者是一种可有可无的情况，而后者则是必须具备的情况。

• 为你的采用创建一个量身定制的方法：

  – 记住，DA FLEX 是一个工具包，提供了在具体情境中使用信息的指导；它不是一个框架。

  使用那些对提高采用成功有意义的工具。

• 指导性的持续改进始于 MBI 计划的初期，并在价值流的整个生命周期中持续进行，而不会改变改进过程。

• 专注于工作流本身，而不是 DA FLEX：

  – 再次强调，DA 工具包提供了应对特定情境需求的工具，你可以用来解决独特的情况。

现在你已经理解了采用 DA FLEX 背后的核心要素，我们将一同查看指导采用的手册。

实施 DA FLEX 手册

从概念的角度来看，DA FLEX 提倡一个观点，即来自不同公司——甚至不同行业的价值流——出奇地相似。这与 James Martin 在其著作《大转型》（Martin, 1995）中提出的观点类似。但另一方面，正是这些差异带来了价值和竞争优势。因此，要确定组织所需的内容，并认识到没有普遍适用的解决方案。

企业有需要开发、改进或更改的产品或服务，因此它们进行工作，并期望获得回报的价值。那些有附加约束的组织，例如专用硬件的监管，也有类似理想化的价值流，但需要关注额外的因素。

在这些概念的指导下，DA FLEX 从适用性描述和持续改进的方法开始。其目标是避免过于简化，同时又不复杂。因此，它的起始分析方法为组织的持续改进提供了基础。

DA FLEX 手册包括以下步骤：

1. 了解理想化的价值流：从当前状态过渡到期望的未来状态。了解理想化的价值流是什么样子。

2. 看清挑战：需要克服的因素，如预算、执行批准、对流程和设备的新改进、新技能以及其他潜在的变革项目。评估以了解你的挑战。

3. 识别行动：根据优先级解决问题，优先选择那些为可用的财务资源、时间和人力提供最大客户价值的变革方案。

4. 改进积压：用于跟踪已识别并优先排序的改进目标。记住你组织的文化，指定一个负责领导变革的人，并识别变革机会。

   延迟或避免优先考虑那些超出范围或利益相关者不支持的变更项目，以及那些会导致认知负担过重的工作项。

5. 持续改进：不断将改进内容添加到积压列表中，精炼工作项目，并重新优先排序，以与客户需求和市场机会对齐。

   当你的组织通过这一迭代和增量改进过程时，不断地想象理想化的价值流是什么样子。现在让我们看看如何规划 DA FLEX 的参与。

   规划 DA FLEX 计划

   在这一点上，组织已经决定采纳 DA FLEX。他们已经获得了管理层的支持和赞助。采纳团队和其他相关利益相关者理解 DA FLEX 的操作手册。所以现在是时候规划该计划了。

   就像基于敏捷的学科有产品积压一样，DA FLEX 采纳团队创建了一个改进积压，指导改进客户价值实现的活动。但同样，DA FLEX 认为规范性方法是无效的，因此认识到定制是必要的。定制是通过遵循DA FLEX 参与前规划过程来实现的，如图 13.5所示：

   

   图 13.5 – DA FLEX 参与前规划

   DA FLEX 参与前规划过程非常直接，如图 13.5所示。首先，团队进行评估，确定产品流的当前状态。接下来，他们评估症状，即他们在从当前状态过渡到期望的未来状态时面临的挑战，目的是减少浪费并改善流程。

   由于 DA FLEX 本质上是一个面向精益的改进工具包；因此，参与前的规划过程也采用 拉动 导向的控制策略，按优先级顺序从手册中处理期望的目标。优先级总是建立在确保参与团队始终专注于改善那些对端到端流程有最大积极影响的价值流活动上。然后，在团队参与 DA FLEX 采用过程中，他们从 DA 工具包中选择适合的 WOW。

   在选择了 DA FLEX 游戏手册的目标并从 DA 工具包中选择了期望的 WOW 选项后，团队现在确定工作任务，以便将其从当前状态迁移到期望的未来状态。接下来，这些工作项将被管理在 改进积压清单 中，优先级再次基于对改善端到端流程的最大影响。

   通过阶段管理变革

   DA FLEX 实施了一个三阶段的方法来促进变革，包括跨企业的业务转型。这三个 DA 阶段如下：

   • 启动：项目启动阶段、起始阶段或迭代/冲刺零阶段。

   • 建设：构建或配置具有足够功能的可消费解决方案，以满足当前利益相关者的需求。

   • 过渡：执行计划以过渡到期望的未来状态。

每个阶段包括 DA 流程目标，帮助用户指导在定制和扩展敏捷策略时所需的流程相关决策。此外，流程指南提供选项以支持每个组织独特的运营环境、情况和期望结果。

我们不会进一步深入讨论 DA 工具包中可用的流程目标、结果和技术，因为这里列举不完。然而，想了解更多的读者可以在 PMI 的网站 www.pmi.org/disciplined-agile/start-here 上找到更多的详细信息。

跨越所有价值流

FLEX 的根源在于精益、看板、产品组合管理和敏捷设计在信息技术中的应用。然而，作为一种通用的精益-敏捷方法，FLEX 还帮助公司在全企业范围内过渡到精益和敏捷方法。

在我们的数字经济中，无法避免将 IT 作为推动业务发展的工具。然而，面向精益的价值流跨越所有职能层级，包括 IT 部门。FLEX 使用的所有方法都基于底层的抽象——IT 基础架构，包括流程、精益和约束理论。因此，FLEX 的实践可以应用于所有价值流。

既然我们已经讨论了 DA FLEX 在价值流中的应用，我们需要快速了解 DA FLEX 如何对其价值流进行分类。

分类价值流

许多精益实践者谈到两种基本类型的价值流——开发导向和运营导向。例如，Scaled Agile 和精益企业研究所都识别了这两类。但请记得，James Martin 在描述中更加细致，确定了 17 种常见的价值流类型。所以，区别在于粒度的不同。最终，所有组织的价值流种类都超过了 2 种，而且大多数组织的价值流数量会多于或少于 17 种。

DA FLEX 引入了其以精益为导向的概念，涵盖了四种类型的通用价值流——开发、运营、支持和赋能。他们定义这四种价值流类型如下：

• 开发：创建一个为客户提供价值的产品/服务。

• 运营：客户如何创造价值。

• 赋能：一种使开发价值流的输出能够在运营价值流中使用的价值流；例如，内部 IT 部门构建一个软件应用程序或基于 Web 的系统，用于实施产品目录和产品订单处理。

• 支持：支持运营价值流的价值流。例如，我们可以以一个分销商或合作伙伴计划为例，它增强了组织的销售和交付能力。

DA FLEX 是一种旨在实施精益敏捷实践、推动业务转型以提高业务敏捷性的方式。在这种背景下，DA FLEX 利用软件交付价值流作为关键推动力。但也应明确，DA FLEX 的视角不仅局限于 IT 职能，它旨在改善跨所有组织价值流的业务敏捷性。我们现在将从这个角度来审视 DA FLEX。

从整体角度看 VSM

本书的核心观点是，VSM（价值流管理）不能仅仅是应用现代 VSM 工具来改善 CI/CD 和 DevOps 管道流动以及软件价值交付。在我们现代的数字经济中，我们使用计算系统、高速网络和软件来改善一切——人们的生活方式、商业流程、信息访问和分析、产品功能以及控制系统。因此，我们的现代 VSM 工具必须帮助 IT 组织在所有这些用例中提升价值交付。

当 Al Shalloway 与他的客户合作时，他意识到，组织必须在整个企业范围内应用精益敏捷实践，而不仅仅是在软件交付领域。简而言之，Al 意识到，组织必须从整体上看待组织作为一个复杂的互动系统，才能成功地实施精益敏捷实践，在数字经济中交付价值。

以下七个小节记录了他在数字经济中应用精益敏捷实践支持业务敏捷性的见解。此外，在 Al 的许可和审阅下，我也对他最初的观察做了一些扩展。

在我们开始之前，让我们先理解这一部分内容的意图。用 Al 的话说，以下列出的活动和策略代表了大多数公司需要学习如何做的 80%内容。

投资组合管理

本小节重点介绍了投资组合管理中的活动和目标，这些活动和目标对支持精益敏捷企业具有最大的影响。

• 实施敏捷预算和精益资金管理：精益敏捷预算支持创新策略，这些策略至少每季度进行一次评审。产品资金是持续的，贯穿整个产品线的生命周期，并根据适时原则进行分配。

  换句话说，基于精益的改进需要对持续的价值流活动进行资助，这与为时间和范围有限的项目分配资金的方式相反。主要问题在于，基于项目的会计方法由于担心错过计划的范围、进度和交付约束，往往阻碍了创新。但当然，项目计划通常会过时——即使在墨水未干之前。

  相反，价值流持续存在，负责开发和交付产品。随着时间的推移，产品和价值流活动通过不断的创新得以改进。因此，精益敏捷预算是长期投资，需要频繁的评估、调整和微调。

• 为整个事业提供资金：公司往往专注于价值主张，而忽视了使价值主张能够被预期客户消费所需的附加或辅助因素。

• 协调资本支出（CAPEX）和运营支出（OPEX）：同时制定资本支出（CAPEX）（可折旧资产）和运营支出（OPEX）的资金计划，以避免建设那些在财务上不可行的项目。资本支出还促进了开发与运营之间的协调，这通常是必需的。

• 定义具有衡量标准的策略：衡量标准可以清晰地指示计划中的投资领域及其量化方式。这些衡量标准实际上是接受标准，确保实现那些为投资提供依据的业务价值命题。

• 实施投资组合管理以推动商业战略：投资组合管理是一门跨产品和服务的学科，它能够明确哪些投资能够为支持业务使命和战略提供最大价值。

投资组合管理活动决定了为实现公司使命、战略和目标所需的投资和优先事项，其中许多投资直接与产品相关。在以下小节中，您将学习如何管理产品开发和交付活动。

产品管理

本小节重点介绍了产品管理中的活动和目标，这些活动和目标对支持精益敏捷企业具有最大的影响。

• 实施发现接收工作流程：实施策略以将高层次的产品需求从计划转化为待办事项，并最终形成最小可行产品（MVP）和最小商业增量（MBI）是至关重要的。

• 提升客户体验质量：客户体验的质量与您对客户运营价值流及其所提供的价值的关注程度成正比。同样，用户故事和验收标准度量从客户的角度或客户角色的角度定义了质量。客户角色，或买家角色，是一个虚构的原型，代表我们大量客户群体的关键特征。

• 使用 MBI 和 MVP：MVP 是对新产品的投资，其回报无法保证。相比之下，MBI 是对现有产品的投资，回报是预期的。所有的开发和服务扩展应通过使用 MBI 或 MVP 以小步增量的方式进行。

  换句话说，在每个构建迭代中，仅构建足够的功能以便客户能够使用，然后利用他们的反馈来推动未来产品开发增强的需求。

  MVP 和 MBI 之间的区别至关重要。MVP 指导新产品的创建，在这种情况下，营销基础设施可能尚未建立。相比之下，MBI 则指导针对现有客户群体的产品增强，工作可能涉及多个开发团队和其他价值流。在整个产品生命周期中，两个方面的资金都需要得到支持。

• 定义服务类别的“准备定义”：同意看板服务类别（CoS），然后为每个类别定义准备定义。例如，定义验收标准或完成标准。

  看板采用 CoS 概念，帮助团队优化待办事项的执行。实际上，CoS 实施了治理开发接收规则的政策，始终考虑客户的利益。

• 序列 MBI 和 MVP：MBI 或 MVP 是根据优先级在接收队列中进行排序的。最高优先级的面向功能的工作项为客户提供最高价值，这通常涉及分析开发和交付成本与产品交付的整体盈利性或可承受性之间的关系。

现在我们已经了解了管理产品开发和交付活动的内容，接下来我们需要了解如何将新订单注入到我们的开发和交付系统中。

开发接收

本小节强调了开发接收中对支持精益敏捷企业最有影响的活动和目标：

• 定义开发引入过程：开发引入过程是一个明确定义的协议，用于启动计划工作。该过程遵循正式化的治理政策，并可以通过机器可读格式进行自动化。如果没有明确的引入工作流程，组织将无法看到实际进行的工作。因此，它们往往会处理过多的任务。

• 计划价值流：就工作项的顺序和如何管理已识别的依赖关系达成一致。在以精益为导向的工作流程中，VSM（价值流映射）计划旨在最小化依赖关系，集成并自动化价值流活动，同时协调跨依赖关系的工作和信息流。

• 实施项目级待办事项：项目待办事项包括 MBI、MVP、功能、缺陷修复和技术债务发布，供在下一个价值交付流或投资组合规划周期中进行开发。

引入到我们系统中的新产品遵循特定的产品开发流程。因此，我们需要构建支持这些产品的管道流，如以下小节所述。

产品开发

本小节突出介绍了产品开发中对支持精益-敏捷企业影响最大的活动和目标：

• 定义 MBI/MVP 验收标准。我们构建的任何产品都必须有可量化的指标，表明产品客户所期望的能力和性能水平。通过其 VSM 计划，组织必须评估每种交付物的验收标准的有效性。

• 实施小团队以提高工作效率：小团队的实施支持协作工作环境，旨在减少价值流参与者之间的交接和反交接。团队成员有共同的目标和使命。通过基于精益的流动和生产控制策略，例如看板，他们在 MBI、功能和故事层面实现了更高的产出。

  注：

  Disciplined Agile 提供了众多精益-敏捷模型，用于部署和管理小团队。此外，我的上一部书籍，《在现代企业中扩展 Scrum》，专注于在多个产品团队和企业规模上扩展 Scrum 和精益-敏捷实践。

• 自包含领域技能：最佳团队的成员拥有重叠且全面的领域技能，确保他们拥有构建高质量和可维护的产品与服务所需的所有资源和技能。

• 围绕价值创造组织：组织开发团队以创建有效的价值流。涉及多个活动、分布式工作站或地理位置，以及多个知识领域的大型价值流，必须采用团队协作、依赖关系和同步策略。

• 创建跨职能团队：跨职能团队具备完成分配给他们工作的所有技能、能力和资源。建立团队时，还必须考虑不同的工作经验和文化背景，以便为问题解决带来更广泛的经验和知识。虽然小团队理想，但往往不实际，或无法为更大、更复杂的产品交付提供足够的能力。FLEX 引入了额外的团队结构，以适应这些现实。

• 通过持续质量验证进行左移：开发团队必须在每个步骤后验证质量，并尽可能自动化这一过程。在传统的瀑布模型中，测试通常是在后期进行的，这带来了各种缺陷和 bug 识别及解决问题，常常导致产品发布延迟。现代的迭代和增量开发实践使得缺陷和 bug 可以更早、更轻松地被发现和解决，对计划中的生产发布影响最小。

• 产品的可维护性、韧性和稳健性设计：产品或服务的架构和设计必须支持其在低成本下的维护和增强。在 Lean-Agile 开发环境中，利用架构和设计的关键是在不确定性面前保持选择。两种术语常用于描述基于 Agile 的架构和设计策略。一种是 进化架构，另一种是 Emergent design：

  – Evolutionary architecture 概念旨在将可变性纳入产品的架构中，使其更容易在以后进行更改，以支持之前未识别的功能性和非功能性需求。Nel Ford、Rebecca Parsons 和 Patrick Kua 在他们的著作 Building Evolutionary Architecture: Support Constant Change（Ford 等，2017）中概述了进化架构的概念。

  – Emergent design 是一种策略，旨在让开发团队根据需求构建功能，并让设计作为结果自然呈现出来。这个策略要求对软件进行持续的重构，以合并已发布增量中的冗余功能，形成一个精简、更简单且性能更高的代码库。Emergent design 应当由模式思维来引导。

  PMI 的 Scott Bain 在他的著作 Emergent Design: The Evolutionary Nature of Professional Software Development（Bain，2008）中，融合了设计模式、模式思维和高质量设计所需的纪律。

• 变更向量跟踪 是一种迭代和反思的软件工程实践，支持 Emergent design。首先，开发人员根据定义为 可修改性 的功能需求评估不同的设计选项。然后，随着业务需求的变化，变更被跟踪为一个潜在的 向量，可能需要软件重构。

产品开发活动在人员、技能、流程和活动的整合下，能够高效、顺畅地利用组织资源，形成面向精益的生产流。

集成

本小节重点介绍了通过整合人员、技能、流程和活动来支持影响精益-敏捷企业的活动和目标：

• 利用 DevOps：这里的关键概念是让 IT 开发和支持团队共同工作。最重要的是，DevOps 是一种合作策略，旨在使 IT 职能之间的工作协调一致。拥有这种合作的好处是，通过让 IT 的两方共同工作，最小化失败发布的可能性，并在发布之前识别潜在问题和改进机会。

  当然，在现代形式中，DevOps 也是一种基于软件工具的集成、自动化和编排策略，它有效地将精益生产实践带入软件开发和交付管道中。

  值得注意的是，尽管 DevOps 得到了应有的关注，但归根结底，它仅仅是将基于精益的价值流管理原则应用于以 IT 为导向的价值流。同样的概念也适用于 CI/CD 管道。两者都是将精益生产流程应用于一系列 IT 活动的示例。

• 实现持续集成能力：在软件工程中，CI 是将所有开发人员的工作副本合并到一个共享的主干代码库中（如 Git 或 GitHub），并且一天多次进行合并的实践。

  然而，CI 概念在实施精益实践时同样有效。在这种情况下，多个团队频繁地将他们的工作整合到整个产品或服务中。例如，团队的工作可能涉及将工作项整合到单一的价值流中，或在多个相互关联的价值流之间协调工作项。

• 共享服务池：大多数基于敏捷的方法论都提倡创建自主且完全自给自足的团队，以便开发产品或提供服务。所谓自给自足，意味着团队拥有开发产品或服务所需的所有技能和资源。

  然而，有时新的需求可能需要超出团队现有技能的能力。在这种情况下，组织必须能够按需提供专业服务，以增强团队的技能。此外，如果新需求是长期需求，团队预计会有一名或多名成员来开发这些新技能。

• 提供系统演示：在敏捷的迭代式和增量式开发策略以及精益的持续流中，共同的目标是交付客户价值。然而，需求和验收标准的定义并不是一个无懈可击的过程。如果没有其他原因，很多时候客户在没有手握工作原型的情况下，无法想象自己需要的是什么。

  与所有敏捷实践一样，DA FLEX 实施了频繁展示端到端产品功能的做法，通常是在每个开发迭代和增量价值发布时进行。即便在一个完全自动化的 DevOps 环境中，业务服务频繁地直接发布到生产环境，仍然是一种好实践，即将每个新功能增量发布给一部分用户，以便他们根据接受标准评估其功能。如果出现问题，这些已发布的服务将产生有限的影响，并且可以在允许全面发布之前撤回并修复。

• 开发与客户支持协调：这个概念是 DevOps 的前提。开发团队关注他们对客户支持的影响，以提供即将推出的内容的可见性。开发人员还会在发布后（根据需要）与客户支持人员合作。

  目标是解决可能在进入生产之前出现的问题，并快速解决已经进入生产的问题。联合团队应回顾经验教训，以防止未来出现类似问题。两个团队将讨论并解决软件缺陷、可维护性、可持续性、性能、故障转移、安全性以及支持人员识别的潜在增强功能。

• 开发与营销协调：在许多精益敏捷实践中，如 Scrum、SAFe 和 Disciplined Agile，产品所有者管理产品待办事项活动，以识别需求、工作项细化，并设定开发优先级。虽然产品所有者最终对所有产品交付负责，但他们必须与开发团队、客户和其他利益相关者直接合作，做出明智的决策。

  尽管如此，几乎所有精益敏捷方法论中对于产品所有者功能的描述都极为简化。他们的角色直接与产品管理和营销组织的更广泛责任相关。回顾我们在《第六章》中整合价值流部分讨论的适应性营销过程和活动，启动 VSM 倡议（VSM 步骤 1-3）。

• 底线：开发团队必须告知营销和产品管理部门即将发布的内容，并确保他们有足够的知识来构建客户所需的产品、功能和特性，且这些内容的价格是客户能够承受的，或愿意支付的。

请注意，使用 MBI（最小可交付项）如何促进不同部分的价值流协调，MBI 包括参与创建它们的必要角色，并确保它们能够被轻松消费。最后，采用精益敏捷实践的组织将始终比不采用这些实践的组织具有明显的竞争优势。那么，接下来我们来看看如何跨价值流管理活动和目标。

跨价值流

本小节重点介绍了在价值流中对支持精益-敏捷企业产生最大影响的活动和目标：

• 确保所有工作在所有工作流中可见：围绕价值流组织的核心目的是协调围绕价值交付的工作，以通过消除工作流中的延迟和获得快速反馈来改善流程并消除浪费。如果我们无法看到工作或工作如何执行，那么实现这一目标将非常困难。我们需要价值流图、流程指南和度量标准来开始。但借助现代的价值流管理（VSM）工具，我们还可以实时访问和查看工作流的流动情况，以及我们在交付目标方面的表现如何。

• 建立安全的工作环境：这一人文因素对于在敏捷和精益实践中建立可持续的工作环境至关重要。人们必须感到安全，才能：1）公开沟通与工作相关的问题和担忧，2）展示他们的工作成果，3）不因无法控制的工作结果或结局而受到责难。

  敏捷和精益实践者明白，我们生活在一个充满超出我们控制的变量的随机世界中，这些变量会影响我们的工作。因此，精益和敏捷实践都实施了识别计划偏差、评估新机会并探索改进工作结果的方法。

  当安全感缺失时，人们往往会集中精力在自己的任务上进行局部优化。不幸的是，这只会加强价值流管理所试图打破的障碍。通过关注我们价值流之间的端到端关系，我们可以避免过度关注无效的局部优化。

• 人力资源和教育部门必须发展以支持业务敏捷性：人力资源和教育政策需要增强敏捷性，而不是与之对立。这些部门必须鼓励建立学习型企业，并确保员工的日程安排中有时间进行学习。我们的员工还需要获取支持其在企业中工作的领域的继续学习资源。

  组织人员围绕价值交付组成团队，而不是把他们固定在职能部门中。同样，管理结构也需要与价值交付对齐。最后，我们必须创建促进持续改进的协作工作环境。

  我们需要让员工在表达他们的担忧或识别改进机会时感到安全。因此，我们需要创造尊重和包容多样性的文化（包括种族、性别、技能、经验），即使在要求团队内部和跨团队的卓越时也要如此。

  薪酬计划需要支持相关技能和经验的增长，而不仅仅是服务年限。与服务年限相关的薪酬更应与减少通货膨胀的负面影响挂钩。同时，最好将晋升加薪与支持企业业务需求的技能和认证增长挂钩。

  最后，组织还需要通过奖金计划来推动团队表现，而非个人表现。在现代数字经济中，精益敏捷团队而非个人提供了竞争优势。

与任何精益敏捷方法一样，角色必须明确，以便理解各自的责任。因此，我们将在下一个小节中讨论 DA FLEX 中的角色。

角色

本小节强调了支持精益敏捷企业所需的必要角色和责任：

• 精益敏捷领导与管理：精益敏捷的领导者和管理者专注于改善人们的工作环境，提供足够的指导，并避免微观管理。

  执行工作的人员通常最能理解妨碍其工作的难题。实践 GEMBA 的管理者亲自看到问题，并能与那些日复一日处理这些问题的员工进行交流，共同合作制定有效的解决方案。此外，管理者和领导者处于更有利的位置，可以就所需投资做出明智决策。

• 价值流经理：每个价值流必须有一个负责从头到尾交付客户价值的人。专职的价值流经理帮助精益敏捷组织摆脱在职能或局部层面的局部优化，实施有效且高效的端到端生产流程，从而交付客户价值。

• 业务架构师：组织必须拥有一位称职且具有影响力的业务架构师。业务架构师专注于定义能够将实施策略与业务战略对齐的业务结构。业务架构的根基在于业务流程再造。

  对象管理集团将业务架构定义如下：业务架构是企业的蓝图，提供对组织的共同理解，并用于对齐战略目标和战术需求。业务架构师负责监督组织在业务治理、流程和信息等领域的结构。此外，他们评估组织当前实施战略的能力，确定理想的未来状态，并定义实施未来运营模式的路线图。

• 企业架构师：与专注于业务与战略过程对齐的业务架构师不同，企业架构师从信息中心的角度来审视企业。

  企业架构（EA）起源于 John Zachman 在 1987 年撰写的论文信息系统架构框架。近年来，EA 框架包括开放组架构框架（TOGAF）、联邦企业架构框架（FEAF）和高德纳企业架构框架（Gartner's EA Framework）。

  注释

  在题为商业架构师与企业架构师：这场斗争必须结束的文章中，John Maynen 做出了以下陈述：

  “简而言之，商业架构关乎企业做什么，而企业架构则关乎企业知道什么。而这两个学科都关注‘为什么？’以确保企业做它需要做的事情，并知道它需要知道的事情。” (www.linkedin.com/pulse/business-architects-vs-enterprise-battle-must-end-john-maynen/)。

• 产品经理：每个产品或服务都有一个人担任产品经理的角色。与价值流经理不同，产品经理独立负责发现、阐明并实现产品所带给客户的价值。

  产品经理确立产品的愿景并制定开发路线图。他们捕捉、分析并记录客户需求、产品能力要求和细分市场机会。关键的是，他们必须具备在客户意识到这些需求之前，就能看到新的或新兴的产品需求的能力。

  产品经理分析并考虑其行业和产品线内的竞争情况。他们的评估有助于为新产品线的投资或现有产品的增强制定商业案例。最后，他们将自己的商业案例和投资回报率（ROI）向组织的高层管理人员和投资组合管理团队展示。

  最后，他们作为公司内部的产品倡导者，并向客户、媒体及行业分析师进行推广。

• 项目经理：产品经理负责将每个产品或服务线所需的所有部分整合在一起，通常会指导作为战略投资组合层次的活动。

  产品交付很少只涉及一个价值流，而且许多价值流之间有交互点。就像我们需要在一个价值流中整合、自动化和编排工作一样，项目管理将相同的策略应用于跨价值流的操作。

• 产品负责人：产品经理必须确保有足够的产品负责人来有效实施其产品战略。在基于敏捷的方法中，产品负责人对开发成果和优先事项负有唯一责任。

  这并不是说他们不从开发团队、客户和其他利益相关者那里获得输入。他们必须清楚地了解客户的需求，并需要理解与功能性与非功能性需求相关的开发权衡，修复缺陷，和减少技术债务的工作。他们还必须评估产品待办事项中的工作项的成本效益关系。但最终，只有一个人能够成为开发优先级的最终决策者，这个人就是产品负责人。

现在你已经理解了在 DA FLEX 中支持精益-敏捷实践的所有角色。DA FLEX 不是一次性的活动。与任何精益或敏捷方法一样，DA FLEX 实施了一种持续改进的策略。我们将在下一节中探讨这种策略如何运作。

实施生命周期变更策略

在 选择与 DA 一起工作的方式 这一节中，你已经看到 DA 工具包如何将 FLEX 定位为支持价值流实施的层级。价值流层级在 图 13.1 中以一组过程模块的形式呈现，这些模块引导着由紫色六边形标识的 10 个价值流。

图 13.6 提供了这八个价值流与 DA FLEX DevOps 层的六个关注领域协同工作的不同视角。本节可能是展示 DA FLEX 如何将精益价值流与 DevOps 结合，作为一个改进的价值流管理周期的最重要部分：

图 13.6 – DA FLEX 生命周期

如你从 图 13.6 中所见，DA FLEX 生命周期是一个持续改进的过程，也作为一个流动的过程。在精益方法中，我们总是以客户为中心开始并结束，这对于 DA FLEX 方法同样有效。

从我们的客户开始，我们逆时针跟随以下大纲：

• 战略：制定支持我们目标客户需求的业务战略，同时也支持企业的使命

• 投资组合管理：评估支持战略的投资策略

• 产品管理：定义维持业务所需的 MBI (最小可交付业务)

• 项目管理与严谨敏捷：定义一套可行的产品提供，针对客户需求提供解决方案，从而创造价值

• 发布管理与 IT 运维：为了妥善支持我们开发的产品

• 业务运营：实现价值，从我们的经验中学习，并调整以改善我们的工作方式

• 支持：确保我们的客户在产品生命周期内获得最大价值

使用五个为什么找到根本原因

DA FLEX 引用了一个案例，其中使用了精益的 5 Why 方法来查明一个看似与 IT 相关的问题的根本原因，结果发现问题的根源其实是另一个完全不同的价值流中的过程失败。让我们来看一下，使用 5 Why 问题技术如何帮助团队找到根本原因。

在阅读这个案例时，请记住，5 Why 策略涉及询问某个事件发生的原因，并不断地继续询问“为什么”，反复探究特定问题背后的因果关系，直到找到问题的根本原因：

图 13.7 – 五个为什么案例

这个过程执行起来所需时间超过了其解释所需的时间。但你是否注意到，问题是如何开始关注到影响 IT 部门的一个问题，并精确指出他们为何需要重新开发其中一款软件产品？然而，经过深究，真正的问题最终被发现是销售部门的一个价值流过程故障，导致他们的责任被过早结束，而没有妥善地交接服务器配置要求。

本节结束了我们对 PMI 的 DA FLEX 收购及其在实施 DevOps 和价值流管理能力中的应用的介绍。它是本书中介绍的两种现代精益敏捷方法之一。另一种是 SAFe，将在下一节中进行讲解。

大规模敏捷框架（SAFe）

SAFe 是跨企业推广敏捷方法的领先框架。它提供了四种配置，用以在大型企业中实施精益敏捷实践，这些企业传统的敏捷方法的小团队结构不足以应对大规模经济中的工作管理。全球已有超过 20,000 家企业在实践 SAFe，超过 80 万人接受过培训，SAFe是全球领先的框架，用于在企业中推广精益敏捷实践。

与本书主题相关，价值流是 SAFe 投资组合的核心构件，它们贯穿于框架的各个层面，为组织中的所有人员和层级提供执行指导。在这一部分，你将了解 SAFe 如何运用精益敏捷概念，包括围绕交付价值进行的人才和业务资源的对齐，并学习 SAFe 如何将价值流管理纳入其 SAFe DevOps 战略中。让我们从介绍 SAFe 如何实施价值流开始这一部分内容。

围绕价值流进行组织

在 SAFe 中，价值流是理解、组织和交付价值的核心构件。SAFe 于 2013 年将价值流引入框架，提出了运营价值流和开发价值流，并为企业用户社区提供了价值流映射。理解并持续优化价值流是有效实践 SAFe 的关键。

开发价值流是一系列长久存在的步骤，用于创造价值——从概念到为客户交付可触及的结果——是 SAFe 中价值流管理的核心。开发价值流识别出活动的时间顺序流，如图 13.8所示：

图 13.8显示了一个初始请求，后面是一个传输流，交付增量价值，并且与交付期望的实现存在交付时间。作为一个过程，交付流在产品的生命周期中反复进行。图 13.1中定义的关键要素在下列列表中进行了定义：

• 触发：一个重要事件启动了价值流，例如特性请求或新解决方案想法。它在某个价值单元——一个产品、服务或规范——交付后结束。

• 步骤：中间的箭头表示跨职能活动，要求定义、构建、验证并发布该价值单元。

• 价值：客户在所有步骤完成后收到价值，且交付的解决方案满足他们的期望。组织可能通过收入、成本节约、客户满意度或这些因素的组合来获得回报。

• 人员和系统：开发价值流还包括执行工作的人员、他们操作的系统或设备，以及从一个步骤流向下一个步骤的信息和材料。

• 交付时间：从触发到价值交付的时间就是交付时间。缩短交付时间加速了市场上市的时间。缩短交付时间最简单的方法是识别并减少（或消除）非增值活动和浪费性延迟。这是精益思维的主要焦点。

精益中的价值流横向跨越职能部门。正如我们在本书中所学到的，真正的客户价值来自于将活动与概念到交付的高效、精简流对齐，这意味着我们需要打破产生浪费、等待、延迟交付和增加成本的职能孤岛。SAFe 通过其敏捷发布列车（ARTs）支持精益生产过程的横向流动。

这个概念在图 13.9中显示为一个长期存在的 ART。注意，列车下方较大的箭头表示价值流的横向流动，通常跨越软件开发、产品管理、信息安全、合规性和运营等职能。不过，还要注意，较小的返回箭头表示该过程是迭代应用的，以持续提供增量价值交付：

图 13.9 – 跨职能敏捷发布列车

图 13.9 直观显示 ARTs 实现了产品交付流程；在这种情况下，定义、构建、验证和发布活动。换句话说，ART 支持价值流交付，并围绕增加价值进行对齐。我们将在接下来的小节中更详细地探讨 ART 的基于价值的交付。

围绕价值对齐 ARTs

SAFe 认识到基本的团队拓扑结构（如 Skelton 和 Pais, 2019 所定义），以帮助团队和 ART 设计，具体定义如下：

• 流对齐团队：围绕工作流组织，具备直接向客户或最终用户交付价值的能力

• 复杂子系统团队：围绕需要专业技能和专业知识的特定子系统组织

• 平台团队：围绕开发和支持为其他团队提供服务的平台组织

• 支持团队：组织起来以帮助其他团队提供专业能力，并帮助他们在新技术中变得熟练

ARTs (www.scaledagileframework.com/identify-value-streams-and-arts/) 引导价值流动，但其规模有限，通常由 50-125 人组成。限制 ART 的规模有助于最小化在大型组织中，随着人员网络扩展所带来的复杂性。图 13.10 展示了 ART 设计的三种可能情景：

图 13.10 – ART 设计的三种可能情景

图 13.10 直观展示了 SAFe 支持的三种价值流交付情景，具体内容如下：

• 单个 ART 支持多个价值流

• 单个 ART 支持一个价值流

• 多个 ART 参与大型解决方案的开发和交付

ART 支持以整体解决方案或相关产品或服务的形式交付价值流。ART 是一个长期存在的、跨职能的敏捷团队，能够持续交付价值。SAFe 的目标之一是最小化 ART 之间的依赖关系，以减少系统性的沟通、集成和交付问题。因此，任何给定的 ART 都可以独立于其他 ART 发布其解决方案，保持持续的价值流向客户。

在某些情况下，解决方案需要多个 ART 紧密协作。例如，交付新的卫星系统、复杂的医疗设备或飞机可能涉及跨越许多企业和供应商职能的成千上万的人员。SAFe 实施了其 解决方案列车 和 大型解决方案 配置，如 图 13.10 底部所示，以管理这种复杂性。

SAFe 还实施了一种精益敏捷模型，以提高企业规模的业务敏捷性，从而在数字经济中有效竞争，接下来的小节中我们将更详细地探讨这一点。

在数字经济中与 SAFe 竞争

Scaled Agile 强调其优势，提供企业和合作伙伴在数字时代成功所需的价值流指导、工具和资源。这包括识别和映射价值流活动，并管理和优化它们。SAFe 融合了精益、敏捷和 DevOps 实践，能够促进价值流的实现。凭借其全球 450+合作伙伴和 12,000+SAFe 项目顾问（SPC）的社区，Scaled Agile 在将所有这些概念结合应用以支持数字化转型计划方面积累了丰富的经验。

然而，不同于詹姆斯·马丁（James Martin）提出的 17 种常见价值流，SAFe 将价值流聚合为运营和开发两种类型，尽管它确实提供了每种类型的价值流示例，如下所定义和识别：

• 运营价值流：为客户交付产品或服务所需的活动顺序。示例包括制造产品、履行电子商务订单、接收并治疗病人、提供贷款和交付专业服务。

• 开发价值流：将业务假设转化为提供客户价值的技术解决方案所需的活动顺序。示例包括设计和开发医疗设备、开发并部署 CRM 系统以及电子商务网站。

SAFe 是另一个认识到 DevOps 能力对于在数字时代竞争至关重要的组织。因此，他们迅速将 DevOps 纳入了他们的框架中。

利用 DevOps 支持数字企业

2018 年，Scaled Agile 发布了其 SAFe DevOps 课程，旨在为整个组织提供 DevOps 教育和价值流思维，而不仅仅是为技术从业者提供 CI/CD 指导。SAFe DevOps 课程涉及跨职能的技术和非技术从业者及领导者，进行价值流映射、瓶颈分析和价值流优化。与软件行业当前的 VSM 工具概念一致，SAFe 将价值流管理作为核心 DevOps 实践，定义如下：

价值流管理

VSM是一种商业实践，专注于增加从客户请求到客户交付的业务价值流动（Kirsten，2020）。VSM 提供轻量级的、端到端的持续交付管道治理，并将其优化以最大化价值交付，而不是最大程度地遵循固定的交付计划。

VSM 包括一些具体的实践，如价值流映射、分析端到端交付管道的流动效率，以及设定交付速度、质量和价值的目标。VSM 还涉及与管道中的其他工具集成的专业软件平台，用于收集和揭示关于价值流健康状况的实时数据：www.scaledagileframework.com/devops-practice-domains/。

SAFe 在价值流映射和管理的背景下采用了特定的 VSM 方法。SAFe 的 VSM 方法涵盖了整个价值流——从客户需求到交付有价值的、数字化支持的技术解决方案，这些解决方案超越了CI/CD或DevOps管道应用程序。换句话说，SAFe 的 VSM 方法支持跨所有组织团队和职能的精益导向改进，而不仅仅是开发和运维。

在这个更广泛的企业背景下，Scaled Agile 对 VSM 的定义如下：

“价值流管理（VSM）是一种领导和技术学科，旨在通过端到端的解决方案交付生命周期，最大化业务价值流。VSM 在价值流的持续运营、度量和优化过程中实施精益、敏捷和 DevOps 的价值观、原则和实践，从客户需求到解决方案交付。”

正如你从本书中了解到的，价值流管理从根本上来说是一个机制，用于在整个组织内进行精益导向的改进。那么，让我们来看一下 Scaled Agile 如何在其框架内采用精益实践，同时从将工作分配给多个小型敏捷团队中获得好处。

使用 SAFe 进行精益敏捷改进

请回忆一下，敏捷，正如《敏捷软件开发宣言》所表达的，基本上是一套价值观和原则，旨在引导小型团队在交付以客户为中心的价值的过程中。敏捷宣言背后的价值观重视个人和互动、可工作的软件、客户协作以及对变化的响应。《敏捷宣言》的 12 项原则客观地列出了敏捷组织的运作方式：agilemanifesto.org/。

然而，敏捷宣言的创始人们当时是在解决传统瀑布模型所带来的问题，该模型无法响应客户需求或高效地构建软件。因此，创始人的关注点主要限于赋予相对较小的软件开发团队的权力范围。因此，SAFe 适当地在小团队层面实施敏捷实践。

然而，组织还必须在所有组织的价值流中交付价值，作为跨部门和职能的横向和高效运营的过程。这正是精益生产理念的核心，SAFe 也在其中得以实施。

为了实现业务敏捷性，SAFe 价值流需要采用所有必要的技能来交付产品和解决方案。这必然包括财务、合同、质量、人力资源、安全、产品管理和营销等其他业务职能。对于 SAFe 的网络物理系统建设者客户来说，这还包括硬件团队、零部件供应商和物流合作伙伴。

换句话说，价值流管理支持跨整个组织的精益改进，而不仅仅是 IT。然而，信息技术，特别是 DevOps，是价值流改进的关键推动力。诀窍在于使 DevOps 团队的努力与整个企业的价值流改进保持一致，并以协调且有效优先的方式进行支持。

注意

Scaled Agile 正在扩大其在此领域的 超越 IT 指导。目前，它包括面向硬件、营销、人力资源和合规（质量、安全等）的研讨会和文章，每一篇都解释了它们在精益敏捷、价值流导向的组织中的作用。

SAFe 对 VSM 的方法平衡了敏捷和 DevOps 实践的深思熟虑应用、支持工具和度量，同时也支持 Womack 和 Jones 的五项精益思维原则，涵盖整个企业。本书将在下一章中介绍 五项精益原则，第十四章， 介绍企业精益 VSM 实践领导者，在 精益企业研究所 (LEI) 章节中详细讲解。

鉴于 SAFe 强调实施精益实践，价值流识别对于实施 SAFe 至关重要，并且是 SAFe 实施路线图中的一项早期活动。此外，Scaled Agile 采用了 Karen Martin 和 Mike Osterling 的价值流映射方法。

在本节关于 SAFe 的内容中，我们了解到 Scaled Agile 推广精益敏捷理念，以应对现代数字经济中的竞争。我们了解到 SAFe 指导企业围绕开发和运营价值流进行组织。我们还了解到 SAFe 在框架中嵌入了价值流管理的概念，既包括 DevOps 指导，也涵盖了更广泛的内容。SAFe 的内容远不止这些，但在进一步讨论之前，我们需要了解 SAFe 的四种配置。

选择正确的 SAFe 配置

在本节中，参见 图 13.4。乍一看，SAFe for Lean Enterprises 图表似乎相当复杂，但我们可以通过将其分解为 SAFe 的四种组成配置来简化图中的信息：

• Essential SAFe：基本配置，采用迭代节奏和增量发布，利用一个长期存在的敏捷团队（Scrum、XP 和 Kanban）围绕敏捷发布列车（ARTs）组织。

• Large Solution SAFe：多个 ARTs 可以协同工作，作为一个解决方案列车来进行非常大的产品开发工作。

• Portfolio SAFe：建立了精益组合管理学科，以在多个规划周期中对产品和基础设施投资进行对齐，并与精益会计实践一致。

1. Full SAFe：安装所有四个配置，以在企业规模上实现业务敏捷：

图 13.11 – Lean 企业的完整 SAFe（SAFe™ 5.1）

看一下完整 SAFe 图表的左列（图 13.11），可以看到 SAFe 实现了比其他敏捷框架中更常见的角色更多的角色。但与 Scrum 中的角色也有一定的一致性，敏捷团队、ARTs 和解决方案列车都有三个关键角色：

• Scrum Master / RTE / STE：分别是敏捷、ARTs 和解决方案列车的服务型领导

• 产品负责人 / 产品经理 / 解决方案管理：分别负责敏捷团队、ARTs 和解决方案列车的产品待办事项优先级

• 开发团队 / 系统架构师/工程师 / 解决方案架构师/工程师：在敏捷团队层面开发产品，在 ART 和大型解决方案层面设计或工程化产品和解决方案。

SAFe 还确保业务负责人保持参与，引导产品开发和交付活动。业务负责人通常在其价值流中有投资回报率（ROI）的责任。

在组合配置层，SAFe 通过 Epic 负责人和企业架构师来引导产品和基础设施的战略投资，并在企业层面解决技术债务。在其他角色通常在相对较短的程序增量上工作，通常为 8 到 12 周，而组合层的高管则会规划 1 到 3 年以上的规划周期。

还有很多关于 SAFe 的内容需要学习，但超出了本书的覆盖范围。想了解更多 SAFe 的读者可以阅读我之前的书《Scaling Scrum Across Modern Enterprises》（Rupp, 2020）。不过，让我们回到通过 SAFe 的 DevOps 概念来提升价值的话题。

实现持续的价值交付

我们现在将深入探讨 SAFe 方法在支持组织持续交付管道中的 DevOps 方法。如图 13.12所示，Scaled Agile 将管道流分为四个部分——持续探索（CE）、持续集成（CI）、持续部署（CD）和按需发布（RoD）：

图 13.12 – 持续交付管道（CDP）

这个图表涉及的内容很多，所以我将通过以下的项目列表来进行分解：

• 持续探索（CE）专注于确保对需要构建的内容达成一致。在这里，重点是理解市场机会和客户需求。目标是确定最小可行产品（MVP）和最小市场化功能（MMF）的需求。此项工作还包括对架构和现有产品修改的评估，以便深入了解满足客户和市场需求所需的能力和特性，这些需求随后会在产品组合、项目和团队积压中进行优先级排序和管理。

• 持续集成（CI）专注于从项目积压中提取功能并实施。在这里，工作重点是产品设计（例如，设计用户故事地图），并可能包括开发用户反馈的原型。当具体功能被清晰理解和完善后，敏捷团队根据典型的敏捷方法（如 XP、Scrum 或看板）实施这些功能。所有产品和相关工件必须在版本控制下进行维护，构建并集成到完整的系统或解决方案中，在生产环境的预发布环境中进行端到端的测试，然后进行用户验证和性能验证。

• 持续部署（CD）将来自预发布环境的更改部署到生产环境中。尽管产品已经经过持续的测试，但生产部署仍需监控和验证，以确保满足所有的接受标准。这个步骤将新功能迁移到生产环境，但发布的时机由业务决定，适合的时机才能发布给客户。控制发布也使得组织能够应对问题，并在必要时回滚或前进修复。所有与特定发布相关的工件必须在配置管理控制下维护，以确保产品和解决方案的可维护性。

• 按需发布（RoD）是指根据市场和业务需求，以一次性或分阶段的方式向客户提供价值的能力。这一策略使得业务能够在市场时机最优时发布新产品，同时最大程度地减少与每次发布相关的风险。例如，企业软件应用的更改通常会影响业务流程，我们需要确保与受影响的员工和其他利益相关者进行沟通，并对即将发生的变化进行培训。RoD 还包括关键的管道活动，能够在发布后很长一段时间内保持解决方案的稳定性和持续价值，例如IT 服务管理（ITSM）和IT 运维管理（ITOPs）过程。最后，RoD 还包含关键的衡量和学习活动，这些活动为基于假设的开发过程闭环，并推动持续学习和实验。

CDP 代表了指导新功能或能力从构思到按需发布价值给最终用户所需的工作流、活动和自动化。CDP 的目标是优化流水线流。所以，接下来我们来详细看看 CDP 过程如何运作。

在 SAFe 中改进流水线流

SAFe 实施了流水线流改进的流程，这些流程在阅读完本书的 第六章，启动 VSM 计划（VSM 步骤 1-3） 到 第十章，改进精益-敏捷价值交付周期（VSM 步骤 7 和 8） 后会显得非常熟悉，其中我们应用了通用的 VSM 方法来改进 CI/CD 流水线流。SAFe 中的改进步骤包括：

• 映射当前流。

• 捕捉相关指标：

  – 过程时间、交付时间、延迟时间，以及完成百分比和准确度（%C&A）

• 将当前工作流与持续交付流水线对齐：

  – 与探索相关的活动

  – 与集成相关的活动

  – 与部署相关的活动

  – 发布及发布后的相关活动

• 识别改进机会。

• 通过 投资组合、解决方案 和 项目看板 构建持续交付能力。它们流转的工作项类型分别为 Epic、Capability 和 Features。

  注意

  请注意，SAFe 在投资组合、解决方案和项目层级上采用相同的流水线流改进和持续交付策略。

  此外，SAFe 实施了 架构跑道 的概念，以识别和管理提升交付能力的技术投资，例如，投资 DevOps 工具链。

• 通过持续测量、反思和学习，不断改进。

在线的 SAFe 指导手册中没有明确讨论未来状态映射。然而，Scaled Agile 强调将未来状态映射作为一项重要练习，并将其包含在 SAFe DevOps 课程中的价值流映射练习中。Scaled Agile 还在开发一个广泛可用（不仅仅是为 DevOps 客户）的价值流映射工作坊，其中将包括关于未来状态映射的详细指导。

Scaled Agile 理解到，我们不能忽视映射期望的未来状态的多个原因。那么，接下来我们来看看，当我们在识别改进机会时未能映射未来状态，会出现的一些问题。

映射当前状态和未来状态

尽管我们通常从高层次的当前和未来状态图开始，但最终我们必须深入到更详细的层级，识别涉及工作和信息流、工具和工具配置、决策制定以及手动干预的低层级活动。

通过详细和准确的当前状态图，我们可以识别出可以通过新工具和配置进行聚合和改进的不必要活动。我们可以识别出可以通过自动化改进的活动，并且可以探索更好的方法和工具来协调工作和信息流。简而言之，未来状态图可能与当前状态图大不相同，VSM 团队在评估选项时，可能会有多个未来状态图。

未来状态图提供了理想状态的可视性，使得所有价值流成员、管理层及其他利益相关者对目标愿景有共同的理解。一些变化可以在较小的成本和努力下完成，但其他变化可能需要跨多个规划周期的投资。我们不想失去这个愿景，而当前状态图无法展示这一点。

最后，表明我们浪费和不平衡流动的指标，这些浪费导致排队、等待和额外成本的指标，并不能告诉我们如何解决问题。我们必须进行实际的工作，评估替代方案，并创建显示改进选项的未来状态图，包括时间、资源和实施每个提议的替代方案的成本估算。在这种情况下，未来状态图非常重要，它们是改进识别和评估过程的一部分。

你现在应该对 SAFe 如何在所有 SAFe 配置中实现持续交付流水线有了大致了解。接下来，让我们深入了解 SAFe DevOps 如何改善持续交付流水线。

启用 DevOps 的 CDP

这正是 SAFe 与传统的 VSM 概念不同之处，它将 DevOps 定位为成功的关键推动力，并将其应用扩展到整个价值流。你现在知道，DevOps 是在数字经济中竞争的关键推动力；Scaled Agile 也持有相同观点。在这种背景下，SAFe DevOps 遵循我们在第十一章中讨论的 VSM 工具倡议，识别 VSM 工具类型和能力。

在这一小节中，我们将深入探讨SAFe DevOps如何支持持续交付的改进。这个话题还将让我们回到在 SAFe 中应用价值流管理的讨论。正如你将发现的，SAFe DevOps 涵盖了一些我们只会简要讨论的概念。

对于这一部分，请参考下图：

图 13.13 – DevOps 启用 CDP

在图 13.13中，你应该首先注意到的是外圈环形图，它展示了之前识别出的 CDP 的四个组件，包括持续探索、持续集成、持续部署和按需发布。但是现在我们看到，SAFe DevOps 为每个 CDP 阶段都包括了流水线活动。

在 SAFe 的 DevOps 元模型的中心是 SAFe 的 CALMR 方法，这是一个持续交付的思维方式，指导 CDP 中的所有决策和行动。CALMR缩写代表文化、自动化、精益流、衡量和恢复。让我们更详细地了解 CALMR 的每个元素：

• 共享责任的文化

• 自动化CDP

• 精益流加速交付

• 衡量流动、质量和价值

• 恢复降低风险并保持价值

SAFe DevOps 及其 CALMR 方法的重点是将 ARTs 集中在实现卓越的业务成果上。这些成果并非仅仅通过在管道中自动化任务就能产生。真正的好处来自于以一种建立繁荣的持续交付文化的方式应用自动化、精益、衡量和恢复技术。

SAFe DevOps 图表的内部环路突出显示了建立成熟 DevOps 环境所需的组件能力。这些能力从中心向外扩展：

• 价值流管理：用于在价值流动中进行精益导向改进的方法。在 SAFe DevOps 中，目标是从客户需求到解决方案交付，增加业务价值的流动。

• 持续质量：确保我们交付的产品和服务符合要求及其定义的验收标准。在 SAFe 下，质量在管道的早期就已建立，并在整个解决方案生命周期中持续管理。质量实践包括假设驱动开发、行为驱动开发（BDD）、测试驱动开发（TDD）、A/B 测试和探索性测试等具体实践。自动化用于提高测试的速度和准确性，贯穿整个价值流。

• 持续安全：帮助确保我们信息、产品和服务的安全性，不仅是为了我们自己的组织，也是为了我们的合作伙伴、利益相关者和客户。安全实践包括设计中的安全性、威胁建模、安全即代码以及在漏洞扫描、渗透测试和入侵检测中的自动化。

• 版本控制：确保制定适当的流程，严格识别我们在价值流动中创建的所有工件。工件包括应用程序代码、服务器、网络和防火墙配置、数据库脚本、需求和测试脚本。所有版本需要存储在一个公共仓库中，以确保可以按需构建、部署、修复和退役解决方案和环境。

• 配置管理：确保有适当的流程，严格识别与每个产品发布相关的所有工件。版本控制强调如何管理不同版本的工件，而配置管理强调什么要管理每个发布的内容。在现代 DevOps 环境中，配置通常作为代码化来管理——基础设施即代码、安全即代码、合规性即代码。

• 基础设施管理：确保我们拥有一个健壮、可持续、安全且可支持的基础设施，以开发和交付我们的产品和服务。基础设施管理的目标是确保已部署解决方案的稳定性和弹性，从而实现最大价值。配置管理安装了一套设计时实践，而基础设施管理则安装了一套运行时实践。

• 敏捷产品管理：关注持续学习，但也包括以客户为中心、假设驱动开发、设计思维、精益创业和市场研究实践。该领域的目标是确保 CDP 始终被校准以交付特定、可衡量的业务成果。

内圆中的外环表示四个关键实践领域，代表解决方案通过系统的路径。三个实践领域包括以下内容：

• 敏捷规划与设计：为开发提供输入，包括期望的业务结果、解决方案范围、架构和设计，以改进持续交付。

• 部署管道：这是软件管道交付模型中的 CI/CD 部分。

• 持续监控：包括全栈遥测、可观察性、主动问题检测、可视化、AIOps 和分析，以高精度衡量和维持业务价值。

SAFe 客户用例

Scaled Agile 指出，没有价值流就无法真正实施 SAFe，他们认为许多案例直接证明了这一点。所有 SAFe 客户故事可以在以下网址找到：www.scaledagile.com/customer-stories/。

更具体地说，位于此网址的用例，youtu.be/02IPXgYlNkY?t=2331（第 39 分钟），直接说明了价值流的力量。

Scaled Agile 展示了以下用例，描述了 PCCW Global/香港电信如何实施 ARTs 来支持多个新实施的价值流的启动：

图 13.14 – PCCW Global/香港电信用例

本节结束了我们对规模化敏捷框架（SAFe）的讨论以及整章内容。在本节中，您了解了 SAFe 如何通过其敏捷和面向解决方案的发布列车支持实施价值流。SAFe 提供了直接的指导，帮助企业利用其资源，发挥规模经济优势，同时通过精益敏捷改进支持数字化转型。像纪律化敏捷一样，SAFe 也将 DevOps 视为关键推动因素，旨在通过支持组织的数字化改进目标来提升软件价值交付。

接下来，我们将以总结结束本章，之后是问题环节，和以往一样。

总结

在本章中，您了解了三个支持在现代精益环境中实施 VSM 概念的组织，具体通过改进 DevOps 管道流来精简组织的软件价值交付能力。首先，您了解了 VSMC，一个由成员（供应商和企业）资助的非营利性行业协会，致力于与价值流管理方法和工具相关的研究、学习、网络建设和开源项目，旨在推动软件交付改进。

接下来，您学习了 PMI 的新 DA FLEX 收购，这是 PMI 帮助组织在企业规模上实施精益敏捷实践的方法。在本节中，您了解到 DA 工具包帮助您、您的团队和您的组织根据各自独特的情况选择最适合的 WOW（最佳实践）。您还了解了 FLEX 如何作为 PMI 实施价值流流动并使用价值流管理技术改善价值交付的方式。

您了解到的第三种精益敏捷/VSM 实施方法是 SAFe™——当前领先的企业级敏捷实践扩展框架。您了解了 SAFe DevOps 是规模化敏捷在 DevOps 中实施 VSM 概念的方法，旨在通过端到端的解决方案交付生命周期最大化业务价值流动。您还了解了 SAFe DevOps 如何在跨职能团队中实施 VSM、精益、敏捷和 DevOps 的价值、原则和实践，以实现价值流从客户需求到解决方案交付的持续运营、衡量和优化。

现在我们已经覆盖了支持基于 DevOps 改进的领先 VSM 方法论提供商，接下来将进入第十四章，介绍企业级精益 VSM 实践领导者。在该章中，您将了解两个领先的精益方法论和培训组织，精益企业研究所和LeanFITT。这两个组织分别定义了价值流和价值流管理背后的原始概念。

问题

1. VSMC 的目的和目标是什么？

2. 在结构上，VSMC 通过围绕三个价值流组织其工作来践行其理念。这三个价值流是什么？

3. VSMC 提供的初步研究成果是什么？

4. PMI 收购了两家公司以启动其精益敏捷实践。这两家公司是什么，它们提供了什么服务？

5. Disciplined Agile 的方式如何帮助精益敏捷团队？

6. DA 工具包中的过程模块有什么目的？

7. DA 工具包的四个层次是什么？

8. FLEX 在 DA 工具包中扮演什么角色？

9. 说明在可扩展敏捷框架®（SAFe®）中，价值流的重要性。

10. SAFe 中的精益价值流的关键元素是什么？

11. 在更广泛的企业背景下，SAFe 如何定义价值流管理？

12. 贡献 SAFe 的持续交付管道（CDP）的流程有哪些？

13. DevOps 与 SAFe 的持续交付管道（CDP）的关联是什么？

14. CALMR 这个首字母缩略词代表什么，它的目的是什么？

15. 价值流管理在 SAFe DevOps 中扮演什么角色？

进一步阅读

• Ward, Allen (2004), 精益产品和过程开发（视频）。精益企业研究所，2004 年。

• Kirsten, M. (2020 年 7 月), 价值流管理（VSM）的崛起: www.linkedin.com/pulse/rise-value-stream-management-vsm-mik-kersten/。

• Skelton, Matthew 和 Manuel Pais, 团队拓扑：为快速流动组织业务和技术团队。IT 革命出版社，2019 年。

第十四章：介绍企业精益-VSM 实践领导者

本章提供了关于领先的精益导向实践和方法论的领导者的说明，包括精益企业研究所（LEI）和LeanFITT™。这两家组织被提及是因为精益实践从敏捷方法中独立演变出来，而这两家组织是精益运动背后运营最久的思想领导者之一。

LEI 成立于 1997 年，由管理专家詹姆斯·P·沃马克博士和他的同事丹尼尔·T·琼斯共同创立。沃马克和琼斯在《哈佛商业评论》杂志上发表的文章《从精益生产到精益企业》中创造了价值流这一术语（沃马克和琼斯，1994 年 3-4 月；hbr.org/1994/03/from-lean-production-to-the-lean-enterprise）。LEI 在其网站上宣传该组织“进行研究，举办教育工作坊，出版书籍和电子书，举办会议，并分享关于精益思维和实践的实际信息。”

第二家组织，LeanFITT™，开发了本书中使用的价值流管理（VSM）方法论（ 第六章**，启动 VSM 倡议（VSM 步骤 1-3） 通过 第十章**，改进精益-敏捷价值交付周期（VSM 步骤 7 和 8）），作为参考模型，用于在持续集成/持续交付（CI/CD）管道流程中进行精益导向的改进。LeanFITT 更加关注 VSM，改进所有组织的价值流，而不仅仅是信息技术（IT）中的价值流。自 2001 年以来，LeanFITT 团队合作编写了超过 50 本书籍和学习工具及资料，致力于将 VSM 作为一种实践方法，推动全企业范围内的精益改进，并适用于任何类型的价值流。LeanFITT 的创始人是 VSM 概念和方法论早期发展的最初思想领导者。

在本章中，我们将介绍以下部分中这两家公司与 VSM 的相关性：

• 全力投入精益实践

• 介绍 LEI

• 开始实施精益方法

• 实施基于阶段的精益改进方法

全力投入精益实践

到现在为止，你应该完全理解这本书的前提：

理解更广泛的 VSM 图景

如果组织不能从根本上理解 VSM 不仅仅是为了改善 CI/CD 和 DevOps 流水线的流动性，现代 VSM 工具导向的行业将会有一个非常短暂的生命周期。这些目标至关重要，然而，更大的机会是将我们改进的 IT 流水线流和资源部署到跨组织的产品和价值流改进中。否则，企业将花费大量资金、时间和精力安装集成、自动化和协调的工具链，最终发现这些对组织的底线和价值交付能力几乎没有影响。

问题在于，从系统思维的角度来看，若我们没有关注其对整个系统的贡献，改善组织的某一价值流实际上是一种局部优化。因此，我们需要利用我们改进的 IT 价值流交付能力，推动组织其他价值流的改进。我们通过使用本书中教授的相同 VSM 方法，但将其应用于所有组织价值流，来实现这一目标。

在这个过程中，我们会发现许多潜在的价值流改进涉及信息、集成、自动化和协调等方面，而 IT 可以解决这些问题。因此，我们在改善 IT CI/CD 和开发-运维（DevOps）流水线的投资理由并不是来自于软件交付的加速，至少不是在一个真空环境中。相反，更大的理由来自于通过软件加速跨所有组织价值流的精益导向改进。

在第七章，当前状态映射（VSM 步骤 4）中，VSM 团队选择了对 CI/CD 流水线的改进作为其高优先级的精益改进举措。选择这一项的目的是强调 IT 可以成为 VSM 改进举措的独立主题。然而，VSM 团队本可以轻松选择另一个组织价值流，在该价值流中，CI/CD 流水线的改进是为了改善目标价值流内的工作和信息流所需的 Kaizen 突发（改进）之一。

因此，我们需要采用通用的价值流图（VSM）方法论，并让组织的战略目标、投资组合优先级和当前状态-未来状态分析引导我们识别并选择精益改进目标。由于精益生产改进是 VSM 背后的操作概念，我们不应该为不同的价值流采取不同的 VSM 方法。

因此，应该显而易见，LEI 和 LeanFITT 组织的重要性并不在于利用现代 VSM 工具的力量。相反，它们为使用 VSM 作为一种方法来改进所有组织价值流奠定了基础，包括 IT 部门，以高效地交付价值，支持企业的使命和优先事项。

在奠定了基础后，我们继续学习 LEI 和 LeanFITT。首先，我们从 LEI 的介绍开始。

介绍 LEI

在本节中，您将了解 LEI，可能是最著名的精益培训组织，因为其创始人深入研究了最初由丰田开发并在全球广泛采用的精益实践原理。

培训和认证项目

LEI 是一个位于 马萨诸塞州（MA）波士顿的 501(c)(3) 非营利组织。其明确的使命是通过精益思维和实践来改善事物。

LEI 成立于 1997 年，由管理专家詹姆斯·P·沃马克博士创办，他是《改变世界的机器》一书的作者。今天，LEI 推动其研究工作，开展教育研讨会，出版书籍和电子书，举办会议，并分享有关精益思维和实践的实际信息。

与传统的“智库”相比，LEI 将其组织视为一个 实干 的机构。正如您将在后续部分中发现的，LEI 采用相同的精益原则来指导其研究活动。具体来说，它会提出关于精益思维的假设并进行实验，看看哪种方法在现实世界中最有效。然后，它会写下并教授自己发现的内容，提供组织转型的新方法。

LEI 力求回答每个经理应该问的简单问题：我周一早晨可以做些什么，来为我的组织带来不同？ 通过其网站和公开活动创建一个强大的精益社区，LEI 的目标是给予经理们勇气，成为精益变革的推动者。

LEI 的使命声明

"通过精益思维和实践，改善事物。"

LEI 通过以下价值流来执行其使命：

• 精益教育

• 精益学习材料

• 共同学习伙伴关系

• 精益峰会会议

• LEI 的官网：www.lean.org/

此外，LEI 的实践者们通过精益全球网络（leanglobal.org/）在全球范围内交换信息，该网络由十多个类似于 LEI 的非营利组织组成，所有组织在不同国家共同承担相同的使命。

LEI 是为公司、企业高管、经理、团队领导和团队成员提供的专业资源。任何希望加入精益价值创造转型的人都可以加入 LEI 的精益社区（www.lean.org/WhoWeAre/why_join.cfm）。LEI 组织的存在是为了支持那些正在开始或继续精益之旅的人们。

阐述 VSM 概念

LEI 并没有明确地定义 VSM。然而，读者可以在 LEI 的官网上找到与此主题相关的几篇文章。

例如，James Womack 在 2002 年写了一篇题为用钱替代价值流管理的文章。这篇文章的前提是，他经常发现公司的一线经理和高管“被赋予了一组关键指标——每个指标都有本年度的挑战目标——并通过奖金激励去实现这些目标。”

问题在于，这些经理和高管管理着跨多个职能部门的多个价值流，但衡量标准和财务激励措施推动的是部门或设施级别的改进。正如 Womack 所说：“在以产品为核心的价值流从开始到结束经过多个部门和设施的过程中，部门或设施最佳利益和产品最佳利益之间出现了自然冲突。”

Womack 指出，其他问题的出现使得负责解决这些问题的人感到疲惫。他将这些问题归结为以下三个根本原因：

• 缺乏政策部署流程，无法优先考虑改进举措，并缩小选择范围，只留下那些每年可以合理完成并稳定下来的项目。

• 没有指定价值流经理，没有人负责从整体上审视每个产品系列的整个价值流，优化整体而非部分。

• 多重且冲突的衡量标准，没有优先级排序或培训，可能导致疲惫和不断的失败感。

2009 年，Dan Jones（当时是精益企业学院的主席）写了一篇题为价值流管理的文章。在这篇文章中，正值所谓的“大衰退”结束时，Jones 讨论了“网络在打开将顾客从陌生人转变为合作伙伴的可能性上的日益影响”。文章的前提是，网络建立了与顾客之间更紧密的联系，将他们转变为要求更高的合作伙伴。具体来说，这些顾客要求我们“按照他们所需的时间、地点和方式，提供他们想要的精确产品，并显著改善使用这些产品和服务的体验，同时最小化对环境的影响”。

然而，当他写这篇文章时，许多公司有着 200 到 300 天的供应链，而零售商可以响应顾客的需求。Jones 发现供应商强调 98%的服务交付水平，但实际上他们只接受约 70%的零售商订单。弥合这一差距的唯一办法是应用价值流管理（VSM）概念，将供应链的交付周期从几个月缩短到几天。

然而，Jones 指出，VSM 成功应用的最大障碍在于“职能、部门和业务单元变得过于强大，并按照自身利益行事。”换句话说，组织忽视了顾客的声音，支持职能性、官僚性和自利性利益。

Jones 的观察与 Womack 在七年前的文章中提出的并没有太大不同。将价值交付的控制权交给等级化和职能部门，会使组织从客户的角度忽视价值流的重点。Jones 指出，前进的最佳途径是通过引入价值流分析和 VSM 来重新平衡职能组织的权力。我们还需要应用科学的实验方法来解决问题，并找到更好的方法来设计必要的管理系统，以创建并维持新的系统性解决方案，从而解决我们的开发、运营和供应链交付问题。

实施精益背后的核心概念

精益的核心思想是最大化客户价值，同时最小化浪费。简单来说，精益意味着用更少的资源为客户创造更多的价值。

精益组织理解客户价值，并将其关键流程聚焦于持续增加这一价值。最终目标是通过完美的价值创造过程，在没有浪费的情况下为客户提供完美的价值。

精益思维将管理的重点从优化单独的技术、资产和垂直部门，转变为优化跨技术、资产和部门流向客户的整个价值流。消除整个价值流中的浪费可以创建出需要更少人力、更少空间、更少资本和更少时间来生产产品和服务的流程，且成本远低于传统的商业系统，缺陷也少得多。公司还可以以高多样性、高质量、低成本和更短的生产周期响应客户需求的变化。同时，信息管理变得更加简单和准确。

有关此主题的更多详情，请访问 LEI 网站：www.lean.org/WhatsLean/。

开始实施精益

LEI 并不把精益推广为一种宏大的理论，认为“一刀切”的方法适用于所有情况。相反，LEI 将精益视为一种基于实验，为你的组织开发一套标准实践的方法。精益过程从定义一个创造价值的过程开始，以价值流或模型线的形式呈现。接下来，组织识别它们的价值流，并使用价值流映射技术描述当前和未来的流程状态。

LEI 对价值流的定义包含在以下的框框中。

价值流

所有的行动，不论是创造价值的还是非创造价值的，都是为了将产品从概念带到发布（也称为开发价值流）以及从订单到交付（也称为运营价值流）。这些行动包括处理来自客户的信息以及将产品转化到达客户的过程。

不可避免地，精益转型工作将识别出问题、难题和浪费领域，这些问题妨碍了信息和产品的高效流动。精益转型团队将每个问题作为独立的问题解决活动来处理。

LEI 提出使用A3 技巧作为形成关于如何改进事物的假设的最佳方法。具体来说，A3 是一种解决每天不可避免出现的大大小小问题的技术。

与风险分析和改进背后的过程类似，A3 关注的不仅仅是我们能轻易看到的表面症状，而是去发现并解决根本原因。只有解决根本原因，我们才有希望解决问题并将其遏制。

A3 是作为丰田生产方式（TPS）的一部分开发的。A3 内容通常以一页报告的形式发布。事实上，A3 这个缩写来自于欧洲标准的 A3 纸张尺寸（11 英寸 x 17 英寸或 29.7 厘米 x 42 厘米）。

A3 包含三个角色，如下所示：

• 问题负责人：他们负责管理 A3 过程以及创建和维护文档。

• 响应者/利益相关者：这些是价值流中的上下游人员，以及最关注和受 A3 项目结果影响的高层管理人员。

• 导师/教练：这是一位精益实践专家，负责指导并促使问题负责人找到解决方案，而不是给出答案或提供解决方案。

A3 报告包含与解决问题相关的信息，如下方截图所示：

图 14.1 – 典型的 A3 报告内容和格式

现在你已经看到 A3 格式的简要示例，接下来我们将详细讨论如何使用该报告。

通过实验改进

你应该意识到，A3 报告在内容和格式上有许多变体。只要它们能帮助你的团队找到问题的根本原因，这些变体都是可以接受的。

基本策略是识别你当前的状况，然后识别商业问题或机会及其根本原因。使用度量指标来衡量绩效差距，并确定潜在的对策。问题解决团队使用传统的计划-执行-检查-行动或计划-执行-检查-调整（PDCA）循环来对可用选项进行实验，以识别和选择最佳方法。

通过无数的参与，LEI 已经了解到，精益转型工作必须由一线经理主导，而不是由实践社区或 CI 团队主导。一线经理包括首席执行官（CEO）、首席运营官（COO）、首席财务官（CFO）、执行/业务单元（BU）负责人、部门负责人、设施经理、区域领导者或生产线经理。换句话说，问题解决工作发生在组织的各个层级，但始终由最接近执行层的高管或经理主导。

相比之下，实践社区（CoPs）、CI 团队或 VSM 团队在担任导师和教练的角色。

反思、分享与改进

LEI 的精益改进方法不是一次性的解决问题活动。相反，每次解决问题时，团队都会反思他们学到了什么。但如果这些学习停留在评估团队内，整个组织就无法进化。

因此，精益转型依赖于在组织及其价值流之间垂直和水平地分享经验教训。日语中对此的术语是Yokoten，本质上是好的想法的传播。最后，我们需要不断实验，寻找改进的新方法。这就是实现 CI 背后的本质——将问题识别和解决作为一个永无止境的工作循环。

让我们花点时间总结一下到目前为止所学到的内容。

总结来说，LEI 的精益转型方法包括以下内容：

• 识别和绘制价值流

• 使用 A3 问题解决模型解决问题

• 通过实验不断改进

• 反思所学的内容

• 与组织内其他人分享我们的发现

• 保持持续改进（CI）

现在我们了解了 LEI 的精益转型方法，让我们快速了解一下 LEI 在精益实践中的指导原则。

定义精益原则

LEI 定义了其精益实践背后的五项原则，详见 Lean.org 网站：www.lean.org/WhatsLean/Principles.cfm。这些原则定义了引导精益实施的流程。

“引导精益技术实施的五步思维过程容易记住，但并不总是容易实现：

1. 从最终客户的角度，通过产品系列指定价值。

2. 为每个产品系列识别价值流中的所有步骤，尽可能去除那些不创造价值的步骤。

3. 使价值创造步骤紧密地按顺序进行，以便产品能够顺利地流向客户。

4. 随着流动的引入，让客户从下游活动中拉取价值。

5. 随着价值的指定，价值流被识别，浪费的步骤被去除，流动和拉动被引入，过程再次开始，并持续进行，直到达到完美的状态，在这个状态下，创造了完美的价值且没有浪费。”

LEI 将其五项精益原则呈现为一个循环过程，如下图所示：

图 14.2 – LEI 的精益原则

现在我们了解了 LEI 的精益原则，让我们快速看一下精益应用的潜在广度。

在组织中推广精益方法

LEI 明确指出，精益不仅仅用于改善制造生产过程。精益导向的方法改进了企业内的每个业务和每个流程。精益还作为战略倡议运作，而不是作为单一使用或战术计划。精益也不是成本削减计划；相反，精益是一种改进价值传递的思维和行为方式。

LEI 在以下网页提供了有关此主题的更多信息：www.lean.org/WhatsLean/

LEI 指出，转型或精益转型经常用来描述公司从旧的思维方式向精益思维转变的过程。精益要求公司彻底改变其业务的进行方式。

精益不是一夜之间发生的。相反，组织必须采取长远的视角并坚持不懈。因此，让我们花点时间了解为什么有业务问题需要进行精益转型。

实施精益以推动业务转型

LEI 创始人沃马克和琼斯概述了应指导整个组织转型的三个基本业务问题（www.lean.org/WhatsLean/）。这些在此列出：

• 目的：企业将解决哪些客户问题以实现繁荣的自身目标？

• 流程：组织将如何评估每个主要价值流，以确保每个步骤都是有价值的、能力强的、可用的、足够的和灵活的，并且所有步骤都通过流动、拉动和平衡相连？

• 人员：组织如何确保每个重要流程都有负责不断评估价值流的人员，以业务目的和精益流程为评估标准？如何确保每个接触价值流的人员都积极参与正确操作和持续改进？

现在我们知道是什么促使一个组织采纳精益实践，让我们来看看制定精益行动计划的方法。

制定精益行动计划

尽管每个踏上精益之旅的个人或公司都会根据他们特定的情况面临不同的挑战，但是有几个关键步骤可以帮助减少阻力，传播正确的学习目标，并培养精益企业所需的承诺。LEI 在以下网页提供了有关此主题的更多详细信息：www.lean.org/WhatsLean/GettingStarted.cfm。

开始

LEI 提倡以下行动导向的步骤来启动组织并采纳精益作为新的运营模式：

• 找到变革的推动者，一位愿意个人承担精益转型责任的领导者。

• 获取精益知识，通过一位老师或顾问获取精益技术，并将其作为系统的一部分来实施，而不是作为孤立的程序。

• 通过抓住危机或制造一个危机来找到杠杆点，开始转型。如果你的公司没有危机，可以将注意力集中到精益的竞争对手上，或者寻找一个精益的客户或供应商，他们将提出对更高效表现的要求。

• 暂时忘掉宏大战略。

• 绘制价值流图，首先描绘出物料和信息流动的当前状态，然后绘制出更精益的未来状态，并制定实施计划及时间表。

• 尽快开始，从一项必要且可见的活动开始。

• 要求立即见效，不要让事情因为缺乏领导力、支持或足够的优先级而停滞不前。

• 扩大你的视野，将价值流中的改进联系起来，一旦你取得进展，就不仅仅局限于车间流程，还要扩展到办公室流程。

既然我们知道如何开始，我们也需要理解支撑精益转型的组织结构。

创建一个组织来引导你的价值流。

精益生产流程将改变你组织的运作方式。虽然组织可以选择维持等级制和职能部门来建立和维持技能，但价值交付领导力必须支持跨职能的价值流交付，哪怕以前从未存在过。换句话说，价值流是横向的，即使你的管理结构是纵向的。

LEI 为实施精益转型战略的组织提供以下指导：

• 按照产品家庭和价值流重组你的公司。

• 创建精益推广职能。

• 在开始时处理过剩人员问题，然后承诺未来因引入精益技术而导致的裁员不会发生。

• 制定增长战略。

• 移除那些拖后腿的人。

• 一旦你修复了某件事情，再次修复它。

• 两步前进，一步后退是可以的；完全没有进步则不行。

采用精益作为新运营模式的组织，也必须安装业务系统来鼓励和支持精益实践，相关内容将在下节讨论。

安装业务系统以鼓励精益思维。

创建行动计划并重新调整资源是支持精益转型的关键任务。然而，除非组织的高层管理人员安装必要的业务系统来支持和鼓励精益导向的转型，否则这些实践将无法长久维持。为此，LEI 建议安装以下业务系统：

• 利用政策部署。

• 创建精益会计系统。

• 根据公司业绩支付员工薪酬。

• 使绩效衡量标准透明。

• 教授每个人精益思维和技能。

• 根据实际需求调整工具的规模，例如生产设备和信息系统。

在这一点上，我们已经有了行动计划，一个支持精益转型目标的组织结构，以及鼓励精益思维长期采用的业务系统。现在我们需要采取步骤来完成精益转型。

完成转型

组织精益行动计划中的最终活动帮助解决 Womack 和 Jones 在其关于 VSM 的文章中提出的问题。这些行动聚焦于使你的供应链合作伙伴与价值交付对齐，并在全球范围内进行。我们还需要确保领导力和决策流程与我们的精益采用保持一致。

LEI 推荐以下活动，以完善或补充你的精益转型行动计划：

• 说服你的供应商和客户采取刚才提到的步骤。

• 制定精益全球战略。

• 从自上而下的领导转变为基于提问、辅导和教学的领导，并扎根于 PDCA 的科学方法。

LEI 提供了一个框架来支持精益转型，这是下一节的主题。

应用 LEI 的精益转型框架

LEI 发现，有效的企业转型涉及五个维度的变化。LEI 使用“房屋”这个隐喻来解释五个变化维度。精益之屋的组成部分包括以下内容：

• 屋顶——保护我们免受外部环境影响的目标、目标和愿景，例子包括：

  a. 我们的价值驱动目的是什么？

  b. 每种情况都不同，我们的对策也不同，因此我们的 approach 必须不同。

• 墙壁——支撑我们屋顶的支柱，包括以下内容：

  a. 过程——需要完成的工作是什么？

  b. 能力——我们需要什么能力来完成工作，解决问题，实现目标？

• 基础——包括我们的基本思维方式、心态和潜在假设：

  a. 明确的假设——我们知道的并且指导我们所有活动的假设

  b. 隐藏的假设——我们不知道的假设

  c. 精益转型差距——从我们当前的文化到理想文化的过渡

精益之屋通过提出以下问题，帮助我们改善对因果关系的基本思维：

• 我们需要解决哪些问题？

• 我们试图实现的目的或目标是什么？

• 需要完成的工作是什么？

• 改善我们现状所需的工作流程是什么？

• 我们需要哪些能力，以及我将如何培养这些能力？

• 我们需要定义哪些管理系统？

• 为了构建执行工作所需的能力，我们需要哪些行为？

以下截图提供了 LEI 精益之屋的图示展示：

图 14.3 – LEI 精益之屋

LEI 与其他公司合作，运用其科学方法寻求 CI 到精益转型的流程。这些合作关系是在 LEI 的共同学习伙伴计划下成立的，后续小节将对此进行介绍。

共同学习伙伴关系

多年来，LEI 与一组选定的公司建立了合作伙伴关系，帮助他们进行精益之旅，并共同开展有关精益转型最佳方法的实验。合格的合作伙伴公司可以接触到 LEI 的思想领袖，例如 John Shook、Jim Womack 和 Mark Reich，以及 LEI 的教练和主题专家（SMEs）。

合作伙伴包括将精益方法应用于整个企业的传统制造商。与此同时，LEI 还与一些开创精益应用的公司合作，涵盖了零售、医疗保健和金融服务等多个服务行业。

通过这些合作关系，LEI 保持了来自这些活动的最新和现实世界的知识，为未来 LEI 的出版物、培训和研究提供了基础。

共同学习伙伴在他们的时间和资源上进行投资，他们必须从中获得一些好处。LEI 列举了其合作伙伴公司获得的以下利益：

• 高层领导的辅导和指导

• 精益转型项目支持

• 战略规划与部署（又名 Hoshin）

• 定制的学习机会

• 基于现场的改进活动

• 行动研究和共同学习实验

• 记录的学习内容共享给伙伴之间以及更广泛的精益社区（需经批准）

• 与伙伴社区的互动

• 独家的伙伴间学习活动

• 在 LEI 举办的实用性公开工作坊上的席位

• 在富有启发性且具有信息量的精益峰会会议上的席位

• 书籍和其他产品的折扣

你可以在以下网页上找到更多关于共同学习伙伴计划的信息：www.lean.org/WhoWeAre/CoLearningPartners.cfm

本节完成了我们对 LEI 的介绍。在接下来的章节中，你将了解 LeanFITT™及其对 VSM 发展的贡献。

来自 LeanFITT™的培训和工具

LeanFITT™由 Don Tapping、Rob Ptacek、Todd Sperl 和 Abhishek Paul 创立。从你阅读第六章**，启动 VSM 倡议（VSM 步骤 1 - 3）到第十章**，改进精益-敏捷价值交付周期（VSM 步骤 7 和 8）时，你可能会记得 Don Tapping 及其合作者定义了本书前面章节中使用的八步 VSM 方法论，我们将其作为用例来评估和改进从精益角度出发的 CI/CD 管道流。

作为一次集体努力，LeanFITT™ 团队自 2001 年以来一直合作编写超过 50 本关于精益和 VSM 实践的书籍、学习工具和资料。通过他们合作中获得的知识，LeanFITT 公司提供一套精益工具来支持您的精益改进计划。LeanFITT 中的FITT代表功能性、集成、技术和培训。

LeanFITT 起初是一个咨询公司，但逐步发展为开发并提供支持精益生产过程的方法和工具。例如，自 2014 年起开发的 LeanFITT 工具将团队的学习经验整合，并通过增强的软件工具提供。与精益的手动选项相比，这些工具通过更简单的方式促进精益团队合作。因此，LeanFITT 的工具体系帮助组织更快速、可持续地部署精益理念。

LeanFITT 的工具为 VSM 团队、精益实践者、企业高层及其他参与价值流改进的利益相关者提供基于知识的指导。每个 LeanFITT 工具提供以下功能：

• 详细内容，解释其目的和实际应用

• 来自行业精益六西格玛专家的导师建议

• 为各级领导者提供的领导力技巧，以更好地激发员工的参与感

• 可追踪的行动项，带有通知功能，并允许附加备注和图片/照片

LeanFITT 工具的目标是利用持续改进、员工参与、标准化知识和工具使用的力量，激发能够带来重大影响的过程变化。基于这一理解，让我们来回顾这些工具。

LeanFITT™的服务内容

LeanFITT 体系提供方法、工具和技术，以改善组织过程、员工和利润。作为一个完整的体系，LeanFITT 包括以下 12 个工具，支持各自的方法和技术：

图 14.4 – LeanFITT™ 精益工具

客户可以根据需求灵活使用 LeanFITT 工具。然而，公司提倡采用四阶段实施方法，您将在接下来的内容中了解这一点。

实施基于阶段的精益改进方法

LeanFITT 体系采用四阶段方法对组织过程进行精益改进。LeanFITT 实施方法的目标是实现积极的行为变化，朝着持续改进的思维模式发展，使高水平的纪律性和标准化变得简单易行，并创造组织文化和盈利能力的积极转变。

让我们快速了解 LeanFITT 的四阶段方法，如何创建一个精益企业。

第一阶段 – 培训并激发员工参与

正如我们在第六章中讨论的，启动 VSM 计划（VSM 步骤 1-3），组织需要确保参与 VSM 计划的人员理解精益原则。我们还需要确保已识别价值流，并且高管和利益相关者支持并参与精益改进工作。最后，我们利用在第七章中学到的价值流图绘制活动，绘制当前状态（VSM 步骤 4）和第九章中的内容，绘制未来状态（VSM 步骤 6）来识别浪费，并通过改善突击（识别的精益改进计划）消除这些浪费。

在这一阶段使用的 LeanFITT 工具包括浪费巡视、5S、PDCA、改善项目、价值流图绘制以及其他适当的工具。主要活动包括以下内容：

• 确定关键用户

• 制定和实施个人、团队或小组的发展和培训计划

• 理解商业案例，识别浪费和改进机会

• 测试你的知识，获得反馈并获得奖励

这一阶段的重点是寻找和评估消除浪费的方法。随着这一阶段的结束，组织将开始标准化和改进其精益实施过程。

阶段 2 – 标准化改进过程

在这一阶段，VSM 团队致力于标准化其精益改进过程，利用 LeanFITT 工具并添加 DMAIC。DMAIC 是基于六西格玛的改进过程。

六西格玛过程是指一个过程中 99.99966%的实例或产品没有缺陷。六西格玛策略设定并监控过程和产品缺陷度量的上下界限，以在偏差造成灾难性后果之前发现趋势。当观察到偏离统计常规时，团队会迅速分析并解决偏差的原因。

在这一阶段使用的 LeanFITT 工具包括标准巡视、A3、Gemba 巡视、5S、PDCA、DMAIC以及其他适当的工具。主要活动包括以下内容：

• 实施有针对性且结果导向的改进项目

• 应用 LeanFITT™工具进行改进

• 测量和追踪改进进度

• 与他人共享结果

本阶段的活动专注于消除第一阶段中识别的浪费。成功消除浪费将提升组织为客户创造价值的能力。

精益改进在战略层面和全组织范围内运作。但与任何商业转型计划一样，变革是困难的。变革不能强制执行——它必须由领导推动，并且变革的原因必须得到有效传达，否则组织内其他人将感到威胁并抵制变革。

此外，人们通常希望加入成功的努力和组织。因此，赞助 LeanFITT 的高管需要促进其初步成功，以在整个组织中获得更多的认可。高管还需要在整个组织中提供机会，培训其他价值流中的人员应用 Lean 实践、方法和工具。这是下一阶段的目标。

第三阶段 – 通过积极参与和透明化激发团队

在这第三阶段，之前 Lean 改进工作的成功得到社会化，并且在内部和领导最初努力的个人因其成就而受到认可。LeanFITT 提倡使用度量和工作可见性来促进组织支持和接受新的工作方式，就像任何 Lean 倡议一样。这些目标是 第三阶段 活动的重点。

本阶段使用的 LeanFITT 工具包括 标准步行，A3，现场步行，5S，PDCA，DMAIC 和其他适当的工具。主要活动包括以下内容：

• 推广和展示 LeanFITT™ 工具应用和项目的结果

• 跟踪和分享团队改进项目的进展和行动项目

• 在整个组织中标准化和扩展培训

• 分享成功故事

到目前为止，领导 Lean 改进的团队可以因他们的成功而受到表彰。庆祝成功是一件好事。然而，组织不能止步于此。Lean 是关于在产品生命周期和组织生命周期中实现持续改进。

第四阶段 – 使 Lean 成为日常和可持续的做法

停止改进的组织会变得陈旧，并将其业务置于风险之中。其他竞争对手将看到通过数字增强产品和组织价值流驱动的新产品的市场份额机会。这第四阶段旨在维持甚至增强您 Lean 取向的竞争优势。

本阶段使用的 LeanFITT 工具包括 标准步行，现场步行，PDCA，防错 和其他适当的工具。主要活动包括以下内容：

• 持续监控和调整进展和活动，以应对当前需求

• 实施行动项目以推动持续改进

• 测量和分享明显的货币节约和诸如改善沟通和团队合作等无形节约

• 使持续改进和 LeanFITT™ 成为您组织的文化！

Lean 和 Six Sigma 通常解决质量问题，其中有许多支持质量改进目标的方法和工具。正如您可以想象的那样，LeanFITT 在其产品提供中提供质量改进工具。

通过 LeanFITT 改善质量

LeanFITT 包括九种用于改进质量的方法和工具，如下图所示：

图 14.5 – LeanFITT™改进质量的九种方法和工具

本部分结束了我们关于 LeanFITT 的讨论，也结束了本章关于 VSM 领先实践的内容。在下一章中，作为本书的第三部分的开始，我们将再次深入讨论 DevOps。在我们开始之前，我们将以总结和一系列问题结束本章，以帮助您验证和提高对讨论内容的记忆。

总结

在本章中，您了解了两个在精益实践和 VSM 发展中起到关键作用的组织。我们从介绍 LEI 开始。LEI 进行研究，举办教育研讨会，出版书籍和电子书，举办会议，并分享有关精益思维和实践的实用信息。

您还了解了 LeanFITT。LeanFITT 的创始伙伴们为 50 多本关于精益实践的书籍做出了贡献。他们还写了关于 VSM 的最早书籍之一，并且在 VSM 实践和方法论的早期发展中起到了积极作用。

我们现在准备进入本书的第三部分，该部分描述了安装现代 DevOps 管道和工具链的复杂性和方法。第一章，第十五章，定义适当的 DevOps 平台策略，讨论了两个关键问题。第一个问题是避免所有组织在尝试实施成熟的 DevOps 管道和工具链策略时所面临的实施陷阱。第二个问题是确定最适合您组织的 DevOps 平台实施策略。具体来说，您将了解四种实施 DevOps 管道的方法。

最后一章，第十六章，通过 VSM 和 DevOps 转型企业，讨论了一个潜在的未来状态，其中现代 VSM 工具不仅帮助改善基于 IT 的价值流，而且帮助改进整个组织的价值流。

问题

1. 谁创造了价值流这一术语？

2. LeanFITT 在我们对 VSM 的讨论中有什么相关性？

3. James Womack 描述了哪些与组织使用资金作为功能经理和高管激励措施相关的关注点？

4. LEI 如何定义价值流？

5. 在 LEI 中，精益行动计划的目的是什么？

6. LeanFITT 的产品的明确目标是什么？

7. LeanFITT 在创建精益企业时采用的四个阶段是什么？

8. 什么是 A3 项目？

9. 什么是六西格玛过程？

10. LeanFITT 有两组工具——它们分别是什么？

进一步阅读

1. Martin, James (1995). The Great Transition. Using the Seven Disciplines of Enterprise Engineering to Align People, Technology, And Strategy. Amazon. New York, New York.

2. Davenport, Thomas (1992 年). 流程创新：通过信息技术重新设计工作. 安永 – 信息技术与战略中心. 哈佛商学院出版社, 波士顿, 马萨诸塞州。 来源：www.researchgate.net/publication/216300521_Process_Innovation_Reengineering_Work_through_Information_Technology。

3. Kirsten, M. (2018 年). 从项目到产品. 如何在数字颠覆时代通过 Flow 框架生存并繁荣. IT 革命. 波特兰, OR。

4. Cardoza, C. (2021 年 1 月 6 日). 价值流管理解决方案指南. 采购指南. 来源：sdtimes.com/value-stream/a-guide-to-value-stream-management-solutions-2/。访问日期：2021 年 5 月 20 日。

5. Collins, J. (2020 年 9 月 29 日). GigaOm Radar for Value Stream Management v1.0. 来源：gigaom.com/report/gigaom-radar-for-value-stream-management/。访问日期：2021 年 5 月 20 日。

6. Condo, C., Mines, C. (2020 年 7 月 15 日). Forrester Wave™: 价值流管理解决方案, 2020 年第三季度。 11 家最重要的供应商及其竞争力分析。来源：www.forrester.com/report/The+Forrester+Wave+Value+Stream+Management+Solutions+Q3+2020/-/E-RES159825。

7. Rupp, C. G. (2020 年). 在现代企业中推广 Scrum：在大型组织中的复杂产品、投资组合和项目中实施 Scrum 和精益敏捷技术. Packt 出版社. 英国伯明翰。

8. Ford, N., Parsons, R., Kua, P. (2017 年). 构建进化架构：支持持续变化. O'Reilly Media, Inc. 塞巴斯托波尔, CA。

9. Zachman, J. (1987 年 2 月). 信息系统架构框架. IBM 系统杂志 26, 276-292。

10. Kersten, Mik (2020 年 7 月 15 日). 价值流管理（VSM）的崛起. Tasktop 创始人兼 CEO。原文发布于 2020 年 7 月 15 日的 Tasktop 博客。也发布于 LinkedIn。来源：www.linkedin.com/pulse/rise-value-stream-management-vsm-mik-kersten/。

11. Ennaciri, H., Bhat, M., Betts, D., Saunderson, C., Herschman, J., Murphy, T. (2020 年 9 月 29 日). DevOps 价值流管理平台市场指南. ID: G00730782。来源：www.gartner.com/en/documents/3991130/market-guide-for-devops-value-stream-management-platform。

12. Ackoff, R. L. (1994 年). 如果 Russ Ackoff 做了 TED 演讲. YouTube. 由 Steven Brant 发布。发布于 2010 年 10 月 23 日。由 Clare Crawford-Mason 和 Lloyd Dobyns 主持，旨在捕捉 W. Edwards Deming 博士的学习和遗产。(www.youtube.com/watch?v=OqEeIG8aPPk)

13. Robinson, F. (2001 年). MVP：最大化风险回报的有效方法论. 访问日期：2001 年 5 月 29 日。 来源：www.syncdev.com/minimum-viable-product/

14. Ries, E. (2009 年). 最小可行产品：指南. 启动公司经验教训. 访问日期：2001 年 5 月 29 日。 来源：www.startuplessonslearned.com/2009/08/minimum-viable-product-guide.html.

15. Womack, J. (2002 年 11 月). 用金钱替代价值流管理. 精益企业研究所. 波士顿, MA. 来源：www.lean.org/womack/DisplayObject.cfm?o=686. 访问日期：2021 年 5 月 30 日。

16. Jones, D. (2009 年 12 月). 价值流管理. 精益企业研究所. 波士顿, MA. 来源：www.lean.org/common/display/?o=1284. 访问日期：2021 年 5 月 30 日。

17. Goldratt, E. M., Cox, J. (1984, 2014 年). 《目标：持续改进的过程》. 第四版. North River Press. Great Barrington, MA.

18. Bain, S. L. (2008 年). 新兴设计：专业软件开发的演化特性. Addison-Wesley，Pearson 教育公司. Upper Saddle River, NJ.

19. Ward, Allen (2004 年). 精益产品与过程开发（视频）。 精益企业研究所，2004 年。

20. Kirsten, M. (2020 年 7 月). 价值流管理（VSM）的崛起. (www.linkedin.com/pulse/rise-value-stream-management-vsm-mik-kersten/)

21. Skelton, Matthew, 和 Manuel Pais. 《团队拓扑学：为快速流动组织商业与技术团队》。IT Revolution Press, 2019 年.

引用 LEI 使用案例研究

LEI 引用了四个客户使用案例来展示其共同学习项目的成功。以下是这些使用案例的名称，所有案例目前均可在 LEI 网站上找到 (www.lean.org/common/display/?o=3342)：

• Thrustmaster 的转变

• 用直线加速器和加速过程抗击癌症

• 精益+循环原则 = 制造商的新北极星

• 将计划-执行-检查-行动（Plan-Do-Check-Act）作为帮助供应商改进的战略和战术

第四部分：与 DevOps 一起应用 VSM

本书的最后一部分讨论了与 DevOps 平台实施相关的三个关键问题：

• 避免 DevOps 实施陷阱

• 决定合适的 DevOps 平台策略

• 使用 VSM 和 DevOps 平台支持数字化业务转型

本章面向非技术读者和初学者，第十五章， 定义合适的 DevOps 平台策略，讨论了实施 DevOps 工具链和管道的复杂性。本章从与五位 DevOps 实施专家的对话开始，他们分享了关于 DevOps 平台实施问题的看法及应对策略。接着，你将了解四种潜在的 DevOps 平台实施策略及其优缺点。最后，你将学习应对实施 DevOps 平台时可能遇到的 18 个陷阱的策略。

最后，第十六章， 通过 VSM 和 DevOps 转型企业，总结了你在本书中学到的内容，同时强调了如何利用 VSM 在数字经济中引领精益业务转型。具体来说，你将学习如何将组织的 VSM 倡议整合起来，最大化利用你改进的软件交付管道。

在本书的第二部分，你学习了支持所有价值流改进的通用 VSM 方法论。在本书的最后一章，你将了解 VSM 联盟的 VSM 实施路线图，该路线图结合精益和敏捷改进概念，应用 VSM 工具来提升软件交付能力，以支持数字化业务转型。我们将通过与 VSM 工具结合使用 OKRs 的策略来总结本书，协同企业战略与 VSM 和 DevOps 工具的投资组合，识别潜在的失败点，并扩展现代 VSM 工具的视野。

本部分包括本书的最后两章：

• 第十五章， 定义合适的 DevOps 平台策略

• 第十六章， 通过 VSM 和 DevOps 转型企业

第十五章：定义适当的 DevOps 平台战略

恭喜！如果您已经走到了这一步，也就是本书的 第四部分 的开始，您将要进入本书将要涵盖的最后一组主题。具体来说，我们现在将关注理解我们可以用来实施 DevOps 能力的方法，以及如何利用这些能力来支持数字业务转型。

在本节关于应用 DevOps 推动数字业务转型的最后一部分中，将涵盖四个主要主题，如下所示：

• 避免 DevOps 实施中的陷阱

• 决定适当的 DevOps 平台战略

• 解决 DevOps 实施的陷阱

• 采访专家

• 处理公司实施指令

• 处理创造性与可重复性流水线活动的差异

在 第十六章，利用 VSM 和 DevOps 转型业务 中，我们将讨论前三个主题，然后讨论如何使用 VSM 和 DevOps 工具来帮助影响数字业务转型。在这一章中，您将了解四种基本的 DevOps 实施策略，以及每种策略的利弊。然后，我们将继续讨论可能损害 DevOps 实施倡议的一些陷阱。最后，我们将回顾 18 个可以帮助改善您的 DevOps 工具链实施的策略。

本章中大部分信息来自于 DevOps 专家以及为本书进行访谈的 VSM 和 DevOps 工具公司。然而，我们等待推荐这些策略，因为它们与您的组织选择部署的 DevOps 工具和工具链无关。

在我们进入下一章之前，我们必须解决实施选项和问题，因为如果我们未能部署它们，那么从 VSM 和 DevOps 工具中获益如何就不重要了。成功部署我们的 VSM 和 DevOps 方法和工具对支持我们的数字转型至关重要。

在下一章中，您将发现现代 VSM 工具和实践支持将基于 DevOps 的软件交付与其他组织价值流改进对齐。从这个意义上说，我们将全面展示如何改进软件交付能力以支持组织的价值流改进，这对于在现代数字经济中竞争至关重要。

考虑到这些目标，让我们首先探讨 DevOps 实施的潜在问题。

避免 DevOps 实施中的陷阱

在准备撰写本章时，我采访了几位我非常看重的专家，他们是部署 DevOps 工具和工具链的实际操作者。他们分别是斯科特·安布勒（项目管理协会 Disciplined Agile 的副总裁兼首席科学家），阿尔·瓦格纳（HCL 软件 VSM 和 DevOps 倡导者），海伦·比尔（DevOps Institute 的首席大使和 VSMC 的主席），普拉莫德·马尔霍特拉（DevOps 服务执行官），和乔尔·克鲁格（专注于开发可重用软件工厂的高级 DevOps 工程师）。

海伦·比尔在 DevOps 及其社区中的资历非常深厚。她解释了 DevOps 实施通常是如何发展成包括多种工具，并且需要 VSM 工具来改进和协调软件交付流程的。斯科特·安布勒从精益敏捷的角度看待 DevOps，并强调在实施 DevOps 平台时选择自己的工作方式（WoW）。

普拉莫德·马尔霍特拉讨论了他作为联邦总承包商和商业系统集成商的 DevOps 实施经验。阿尔·瓦格纳将代表 VSM/DevOps 平台供应商的观点。最后，乔尔·克鲁格将讨论创建可下载的 CI/CD 和 DevOps 配置作为可重用的软件工厂的好处。

在做了这些初步介绍后，让我们开始吧。

采访专家

在这一部分，我们将了解五位行业专家的观点，以及他们对 DevOps 的看法和想法。

与海伦·比尔的访谈

海伦·比尔是 DevOps 和工作方式教练，DevOps Institute的首席大使，持续交付基金会的大使，以及价值流管理联盟（VSMC）的主席。她为 DevOps 行业领导者提供战略咨询服务，并在加速战略集团担任分析师。

我很荣幸海伦同意担任本书的技术审稿人，并希望为这一章贡献她的想法。我也有机会与海伦一起工作，她是 VSMC 的顾问之一。那么，在做了这个介绍后，让我们来听听海伦怎么说。

培养 DevOps 思维方式

海伦首先指出，她不认为组织应该创建 DevOps 团队。相反，她认为 DevOps 是一种思维方式，而不仅仅是一种组织结构。正如她所说，"灌输这种思维方式：DevOps 是整个组织的文化运动，并设计实践 DevOps 的价值流团队。"

价值流是精益企业中交付价值的基本组织结构。DevOps 是一种支持 IT 中价值流的协作与技术实施策略。所以，在这种背景下，海伦的说法是完全合理的。

DevOps 最初是一种协作策略，旨在协调软件开发和运维团队的努力，以提高基于价值的软件交付能力。你现在也知道，成熟的 DevOps 流水线通过集成工具、自动化活动以及工作和信息的编排，共同推动价值流的改善。DevOps 需要改变思维和文化，以便将软件交付与价值流对接。

授权员工

DevOps 改变了人们在组织内部和跨部门之间的工作方式。因此，DevOps 影响着组织的人力和文化。Helen 进一步指出，我们必须赋予人们参与的权利——"人们不喜欢变革被强加给他们——他们必须被赋予自主权来找到自己的前进道路。"Helen 还提到，如果长期没有获得授权，想要变得有权力就非常困难。

引领前行

Helen 指出，领导者是领导者。因此，他们不能在监督 DevOps 工具和工具链的部署以及必须采取的组织变革中采取旁观者的角色，以便有效地利用这种新的工作方式。

为了在他们的角色中有效，组织内的高管必须首先学习 DevOps 的技能和原则，然后才能出台任何关于使用 DevOps 的指令。否则，他们不可能就工具、相关预算、资源对接和培训需求做出明智的决策。

Helen 观察到，许多领导者认为他们是高高在上的。然而，领导者需要从自己做起，重新培训组织。DevOps 使组织远离传统的等级制和指挥控制结构。因此，其领导者——包括组织的高管、经理和教练——必须具备鼓励团队自我发现改进方法的能力和知识，并帮助消除团队识别的障碍。

演变而非转型

目前许多分析师的趋势是讨论使用精益敏捷实践来支持业务转型。在这本书中，你已经听我描述了我们如何使用 VSM 和 DevOps 方法和工具来支持业务转型，以便在现代数字经济中竞争。

然而，Helen 担心进行业务转型的概念过于轰动性，许多人由于之前的转型失败而感到变革疲劳。相反，Helen 认为我们最好通过持续的渐进式改进来追求演变。在这个背景下，Helen 认为，组织更应该将其努力方向引导向实现持续演变的文化，而不是追求一次性和相对短期的业务转型目标。

抽出时间学习

Helen 之前提到过，组织的领导者必须获得支持有效 DevOps 转型的知识。但是，这种学习要求不仅仅局限于领导层，而是要在整个组织范围内实施，并且必须为员工的持续教育提供时间和资源。

这些培训要求意味着组织的高层管理者必须为学习腾出时间。换句话说，持续学习必须被视为一项持续的工作要求，而不仅仅是一个可有可无的选项。

DevOps 的演进要求组织中的所有人放弃长期以来坚持的信念和做法（例如 PRINCE、项目管理等），并学习新的思维方式和工作方法。Helen 指出，人类的认知负荷是有限的，学习和实践新行为需要时间。因此，必须为学习分配时间，超越日常业务（BAU）和新的功能开发与解决。

解决技术债务

尽管技术上不属于培训的一部分，Helen 也强调了解决技术债务的重要性。换句话说，组织需要在繁忙的日程中腾出时间来重构软件代码，因为这有助于解决在团队专注于便捷地交付新特性时积累的性能问题。同样，开发和支持团队也需要不时地改进产品的架构和设计，并实施新的技术改进。

构建 DevOps 平台

Helen 指出，新的 DevOps 工具不断涌现，而且它们的需求也在不断变化。因此，软件交付团队需要构建一个可适应的 DevOps 框架——从 API 优先的角度进行思考。采用 DevOps 框架策略有助于确保平台在时间的推移中保持可扩展性，从而允许集成新的功能和未来的技术，以支持组织不断发展的软件交付需求。

另一个重要的考虑因素是，要在工具链中实现可追溯性。Helen 认为，你应该接受你的 DevOps 平台将成为一个异构工具链的事实，即使你一开始使用的是商业DevOps 即服务（DaaS）平台。支持持续改进 DevOps 工具链的进化性方法将推动这一最终结果。好的一面是，你的 VSM 平台将把这一切联系在一起。

此外，Helen 认为，你应该将 DevOps 工具链/VSM 平台作为服务提供给你的价值流团队。尽管团队可能有不同的需求和工具，但你可以将工具链的架构或类别与实际的工具链分开，并更换工具（例如，.NET 单元测试使用 NUnit，Java 单元测试使用 JUnit）。我们将在采纳软件工厂策略和构建可重用的软件工厂章节中进一步讨论这个话题，这两部分讨论了可下载和自助配置如何作为可重用的软件工厂。

克服 DevOps 实施挑战

海伦认为，在组织中建立关于 DevOps 的共同看法是困难的。有些人可能认为它只是自动化的一部分，比如实施 CI/CD 流水线。其他人则认识到 DevOps 的广度包括整个价值流，连接业务的所有部分，并融合敏捷、精益、站点可靠性工程（SRE）、DevSecOps、DataOps 或 AIOps。

无论您的组织如何定义 DevOps，都必须确保有倡导者和实践社区来定义并传播 DevOps 如何支持您的业务。

海伦指出，实施 DevOps 时最常见的挑战是文化问题。工具和工具链是最容易看到和实施的部分。但改变人们的思维方式和工作方式，在实践中要做到这一点要困难得多。

为了推动文化变革以实现积极的成果，海伦认为组织必须积极建立心理安全感，培训领导者分配权力，重视持续学习，并教人们讨论自己的情感、感受和行为。此外，她建议组织在帮助创造真正且持久的变革时，采用神经科学的最新研究成果。

最后，海伦讨论了 KPI 和 OKR 在定义 DevOps 实施活动的目标和宗旨中的相关性。但她也指出，这些不应强加给团队。相反，应该让 DevOps 团队定义并衡量他们的目标和指标。并确保您的团队拥有（即 VSMPs）实时监控结果的工具。

斯科特·安布尔访谈

斯科特与马克·莱恩斯共同创建了项目管理协会（PMI）的严谨敏捷（DA）工具包。斯科特还与阿尔·沙洛威合作，后者是 DA FLEX 的思想领袖。严谨 DevOps是 DA 工具包的一个层面，斯科特正是从这个角度讨论 DevOps 实施的陷阱和平台策略。

斯科特拥有丰富的 IT 经验，多年来一直分享他的知识。他在 IT 和流程领域已经著作或共同著作了超过 20 本书，并与全球各地的组织合作，帮助他们改进工作方式。斯科特目前是 PMI DA 部门的副总裁兼首席科学家。

你不能买到 DevOps

斯科特认为，谈到 DevOps 时，最大的实施陷阱就是决策者不了解挑战的范围。许多组织希望安装 DevOps，认为他们可以通过购买解决当前的困境。或者，他们认为他们可以在几个月内转型为 DevOps。实际上，情况远非如此。

成功的 DevOps 实施需要在人员、流程和技术方面进行大量的长期投资。首先，这是一个重大的人员问题。斯科特与每一个他合作的公司都需要开发新的技能，实施培训项目，并寻找或培养导师和教练来支持学习过程。DevOps 显然需要新的工作方式（WoW），正如你在本书中看到的那样，还需要在支持这种新兴工作方式的工具和技术上进行投资。

DevOps 不仅仅是开发和运维

斯科特对 DevOps 的最重要观察，与 Pramod 和 Al 的观点一致，强调 DevOps 不仅仅是将 开发 和 运维 合并。在纪律化的 DevOps 中，DA 工具包的四个层次之一，PMI 将企业级 DevOps 的六个关键方面融合在一起：

• 解决方案交付：这是一个适应目的、战术可扩展的软件解决方案交付方法。被称为 纪律化敏捷交付（DAD），它将解决方案交付的各个方面编织在一起，从头到尾生成可消耗的解决方案。可消耗意味着某个东西是功能性（它能工作）、可用的（它运作良好）和令人期望的（人们愿意使用它）。一个解决方案可能包括软件、硬件、文档、业务流程改进以及组织结构改进。敏捷团队通常专注于生产工作中的软件，而 DA 团队则专注于生产可消耗的解决方案——这是一个巨大的区别。

• DevSecOps：纪律化的 DevOps 将信息/网络安全和物理安全实践直接融入工具包中，正如 Pramod 和 Al 所分享的原因。安全性绝不应成为事后考虑的事情。

  在本章中，我们将看到 DevSecOps 这个缩写常常被用来替代更传统的 DevOps 缩写。DevOps 作为一种协作策略，旨在打破开发和运维之间的壁垒，而 DevSecOps 将安全性纳入到协作中。换句话说，安全性作为团队的一部分，参与软件开发生命周期的每个阶段，而不是作为一个孤立的职能。

  DevSecOps 的目标是避免在已部署的软件解决方案中出现安全问题。为了实现这一目标，DevSecOps 流水线包括集成、自动化和协调的威胁建模和安全测试活动。自动化能力确保每次新的代码更改都会经过彻底测试，并生成相关报告和警报，详细说明任何潜在的漏洞。

  在 DevSecOps 流水线中，安全性不仅限于软件编码和测试活动。发布后，监控工具会持续扫描潜在威胁和漏洞，并在发现时生成事件报告。

• 数据 DevOps：数据是你组织的命脉，但它常常被忽视，或者至少在大多数 DevOps 实施中被视为低优先级。如果你无法以同样的速度部署数据更改，那么一天内多次部署软件更改又有什么价值呢？

• 多解决方案支持：DevOps 的哲学是 你构建它，你运行它，你支持它，这是一个非常有价值的激励因素，能够促进更好的协作和流程改进。但是它无法扩展。当你的组织有数百个，甚至数千个运行中的系统时，终端用户需要一个共同且连贯的策略来获得支持。

• 常见的 IT 操作：如果你在生产环境中运行多个解决方案，或者支持许多 DevOps 流水线，或者两者兼有，你需要支持一些共同的操作基础设施来简化工作。在多个组织中，Scott 帮助他们识别出共享的基础设施和支持各个团队需求的独特部分。你对待、支持和发展共享基础设施的方式与对待特定应用功能的方式是不同的。Scott 的目标是帮助客户学会如何根据需要协作并发展这两种基础设施。

• 业务运营：Scott 一再发现，你不应将运营限制在 IT 操作上。这当然很重要，但如果你的业务运营相对不够灵活，那么你最好先投入精力改善这一价值流的方面。

Scott 认为，DevOps 实施中的一个关键危险是忽视了 DevOps 不仅仅是让开发团队和运维团队开始合作。规范化的 DevOps 展示了这些关键方面如何以流畅且可发展的方式相互配合。它还展示了如何在这些领域并行改进，但仍然作为一种协作的努力进行。

在接下来的六个小节中，Scott 将解释如何在 DA 工具包中运用 DevOps。

我们将从第一个 DevOps 概念开始，以思维方式为起点。

从思维方式开始

Scott 提到，大多数人所称的 Agile 思维方式的描述——《敏捷宣言》——是在 20 多年前写的，目的是解决当时的问题。但是，时代已经变了，我们在过程中也学到了一些东西。Scott 强调，虽然《敏捷宣言》中表达的思维方式是一个很好的起点，但本书中你学到的 DevOps 思维方式也有许多伟大的理念，真正需要的是一种面向业务敏捷性的思维方式。虽然 DevOps 是价值流和业务敏捷性的推动者，但它并不是孤立存在的。要成功，你需要看清除 DevOps 之外的更大图景。

这种方法正是 PMI 在 DA 工具包中所采用的，包括其 DA 心态，其中捕捉了关于业务敏捷性的原则、承诺和指南。统一的业务敏捷性心态为团队成员提供了一个基础，从中他们可以进行协作，支持在不同团队之间创建共享文化。

出乎意料的是，DA 社区发现这仍然不够。从不同领域的人带着自己独特的经验、技能、优先级和观点来到桌前。例如，安全专业人员有他们独特的理念，数据专业人员、市场营销专业人员、产品经理和其他关键利益相关者也是如此。所以，我们不仅需要 DA 心态的基础原则、承诺和指南，还必须为组织内每个团队或“部落”扩展这些理念，加入各自独特的哲学。

DA 中的每个过程模块，DA 称之为过程领域——例如安全性、数据管理、企业架构、IT 运维等——都通过多个与该领域相关的理念扩展了 DA 心态。这种方法使人们能够专注于这些过程领域，以适应他们特定背景下的挑战，同时与组织中的其他人分享共同的文化。

总结来说，DA 提倡我们需要一个共同的心态，以便与他人良好互动。并且我们还必须尊重每个人带来的差异，包括他们的观点。DevOps 的成功要求每个人都要发展自己看待世界的方式，并以新的方式运用他们独特的优势。

你的技术债务已经到期

如果 Scott 必须选出一个导致 DevOps 在组织内实施缓慢的原因，那一定是技术债务。多年来，糟糕的源代码质量和缺乏自动化回归测试一直是将 DevOps 引入组织的人的痛苦根源。但数据相关的技术债务和数据源质量问题多年来一直是许多组织的盲点。尽管高层领导通常认识到存在问题，但他们往往已放弃尝试解决它。但除非你的组织解决了所有技术债务的问题，否则你将很难成功实施 DevOps。

与名称相反，技术债务的主要原因并非技术性问题，而是与人相关。事实上，Scott 的经验是，大多数技术债务源自项目管理的思维和行为。特别是，追求按时按预算完成任务的愿望往往迫使团队生产比他们期望的更低质量的解决方案，从而增加了技术债务。我们以后再修复的说法很少兑现。而且，设计和架构概念及技术的培训水平差，也是技术债务的原因之一。

多年来，Scott 所合作的每个组织——涵盖了软件公司、金融机构、制造商和超市链——都需要投资来减少技术债务。然而，投资软件质量、自动化测试和提升数据质量始终是 DevOps 基础设施投资的主要部分，解决这些问题需要多年的艰苦努力。

发展成一个适合目的的 DevOps 战略

DA 工具包采用了与提供过程建议非常不同的方法。像 SAFe 或 LeSS 这样的框架提供了一系列的最佳实践，规定了该做什么，这可以是一个很好的起点。但这仅仅是一个起点。Scott 认为你的组织是独特的，并且面临着一个独特且不断变化的情况，因此你需要超越敏捷框架。

相反，DA 工具包告诉你应该考虑什么，提供应对你面临的挑战的选项，并描述这些选项的权衡。它使你能够决定尝试哪些技术，以发展适合你的方法。它通过帮助你做出更好的决策，从而加速“快速失败”的改进策略，减少失败次数，进而加速改进。

再次强调，Scott 指出一个常见的实施误区是认为你可以快速安装或转型为一个 DevOps 组织。其实你做不到。相反，你需要付出艰苦的努力，逐步演进成 DevOps。你想要一个适合目的的 DevOps 战略，能够反映你的组织、你的人员和你的目标，最终实现你期望的结果。你需要对你的 WoW 负责，而 DA 工具包正是帮助你做到这一点。

你可以购买一些你的 DevOps 基础设施

我们已经谈过了 DevOps 平台。是的，你可以购买 DevOps 工具或采用基于云的DevOps 即服务（DASS）选项及其组合。因此，情况并非完全悲观，但你仍然需要安装和配置这些工具。你仍然需要培训人员，使他们知道如何使用。你仍然需要有效地使用新的基础设施。正如 Scott 之前提到的，你还需要投资来减少技术债务。技术债务的一个关键方面是基础设施方面——例如开发自动化测试。因此，简而言之，你可以购买一些基础设施，但你仍然需要自己构建很多基础设施。

有纪律的 DevOps 是敏捷企业的基础条件

你可以通过努力弄清楚开发、运维、安全、数据和支持如何相互配合。你还可以考虑这些如何支持你的价值流，并适应整个组织的需求。或者，你可以查看 DA 工具包，它已经做了所有这些繁重的工作，并以此作为起点。

DA 工具包展示了这一切如何协同工作，远远超出了 DevOps 的范围，解决了如何有效实施价值流并在企业层面支持它们的问题。它是基于选择的，而非强制性的，教会团队如何演进一个合适的 WoW，使其尽可能高效，同时又能融入它所在的整体价值流。当然，精益治理策略贯穿于整个工具包；否则，混乱将会发生。

与时俱进

有两个至关重要且不幸的观察，您必须接受它们，才能在 DevOps 上取得成功：

• 您的组织是独一无二的：我们之前说过这一点；其含义是您需要选择合适的 WoW，以确保有一个符合目的的工作方式。

• 您的环境是流动的：您的 WoW 不能是静态的；它必须随着您的情况发展而演进。您必须成为一个能够不断改进的学习型组织。

DA 教您如何更好地提高自己。它明确地告诉您，您有多个选择，并且如何根据当前情况选择最佳选项。它在团队和组织层面嵌入了改进策略，并且采纳了一种引导式的实验方法，超越了主流敏捷的 快速失败 理念。

并没有简单的答案

Scott 总是说，不能强调这一点太多——没有捷径可走。您不能购买 DevOps 解决方案，不能安装一个，也不能快速地将其转变为 DevOps。相反，您需要付出努力，逐步演进您的文化，演进您的 WoW，并改善您的基础设施。他的经验是，DevOps 涉及人、过程和技术。他最后的警告是 忽视这些问题将自食其果。

与 Pramod Malhotra 的访谈

拥有直接且广泛的运营经验，Pramod 是 Salient CRGT 的一名高管，担任公司 DevSecOps 和应用现代化的思想领袖。此外，他还监督了许多大型商业企业和联邦政府机构的 DevOps 实施。过去五年直接与 Pramod 合作，让我见证了他的观点如何随着行业的发展而演变。以下是他的一些见解。

获得高管支持

首先，Pramod 认为，在没有高管级别支持的情况下，任何关于 DevOps 工具和工具链的实施都将失败。这一问题在本书中反复提到。但 Pramod 亲眼见证了没有高管领导支持，在大规模实施 DevOps 时的困难。

首先，DevOps 需要一种文化变革，而这种变革不能仅仅通过自下而上的策略来推动。人们抗拒变化，继续做他们习惯做的事情是很自然的。因此，DevOps 也不能被强制执行。相反，企业高管需要发挥领导作用，建立相关的 目标与关键结果 (OKRs)，并帮助推动组织实现预期的成果。

另一方面，作为一种软件交付改进策略，DevOps 的好处是值得付出努力的。DevOps 改善了软件开发能力，企业中的每个人都在工作方式上受到影响。换句话说，在数字经济中，软件作为独立产品交付价值，能够在物理产品中启用数字增强功能，并支持整个企业价值流过程的改进。

直截了当的说，Pramod 会建议组织不应浪费时间尝试实施 DevOps 工具和工具链，除非他们有首席执行官和业务线高管的支持、能够为这些项目提供资金、能够分配足够的资源，并且能够让人们对实现可识别和可衡量的成果负责，包括时间框架、预算和 ROI，这些成果足以证明努力的价值。

实施有效的培训计划

接下来，企业范围内的培训至关重要。DevOps 的工具和工具链不能简单地扔给开发和运维团队，并期望他们能够有效使用它们。此外，能够从基于 DevOps 的软件交付能力中受益的价值流，需要了解什么是可能的，如何与 IT 组织进行有效的合作。这个说法同样适用于那些依赖竞争性软件交付能力来实现企业战略、目标和任务的业务负责人。

这种培训可以超出组织的员工范围，涵盖第三方顾问和供应商。例如，大多数政府机构和大型商业企业都会借助外部软件开发组织来构建支持业务的应用程序。如果高管决定采用 DevOps，那么他们的顾问也必须做出类似的承诺。

最后，利益相关者也需要接受 DevOps 培训。我个人定义“利益相关者”一词，意味着它包括任何有重要意见的人。任何在一定时间内管理过软件交付项目的人，都会经历外部利益相关者影响项目结果的情况。

有时，这可能是因为那些外部利益相关者正在争夺已分配给你项目的预算和资源。但有时，利益相关者可能看不到软件交付团队所执行工作的价值，可能觉得自己在决策过程中被排除在外。虽然敏捷实践有助于解决一些沟通和协作问题，但我们不能忘记，一旦组织转向基于 DevOps 的软件交付，利益相关者的关切和需求同样至关重要。

全力以赴

在本书中，你已经了解了使用价值流映射来评估当前运营状态并识别改进机会的重要性，这些改进帮助实现期望的未来状态。因此，与敏捷回顾——其评估的是有限范围内的即时改进领域——不同，VSM 倡议通常采取更广泛和长期的视角，以确保整个价值流作为一个系统，能够以更高的效率和更少的浪费运行。

DevOps 非常符合精益策略，旨在简化软件开发、交付和支持功能，作为一个集成的、自动化的、协调的价值流。从概念上讲，DevOps 工具链作为一个简化的软件交付管道运行。

VSM 提供了一种评估一系列改进机会的方法，以增加软件交付管道中的价值流动。由于财务和资源的限制，我们可能需要在较长的时间内优先投资。但这并不意味着我们可以以临时的方式进行评估和实施。正是这些改进的结合，使得 DevOps 管道能够高效且快速地交付软件价值。

因此，组织的高管不能允许其 IT 部门以零散的方式实施 DevOps 工具和工具链。实施 DevOps 工具和工具链是一个战略性举措。组织需要规划并引导其 DevOps 投资，就像他们对待任何其他由 OKR 驱动的产品和投资组合投资一样。

我们将在第十六章，通过 VSM 和 DevOps 转型业务中更详细地探讨 OKR 的主题。但目前，请知道 OKR 确立了关于期望结果和可衡量结果的高层次期望。换句话说，高管应当设立 OKR 作为指导，明确 DevOps 实施中相关人员的期望和衡量成功结果的指标。

建立 DevSecOps 卓越中心（COE）

到目前为止，我们讨论了拥有高层领导、有效的培训计划和端到端 DevOps 实施策略的重要性。但组织还需要一个卓越中心，以建立治理政策，确保可重用工具链配置的建设，并为培训、辅导和指导提供资源。

在监督多个企业规模的 DevOps 实施之后，Pramod 得出了这样的观点：组织需要选择一个供应商或专家组（COE）来建立组织的整体 DevSecOps 和 CI/CD 平台解决方案。这并不是说多个团队不能参与 DevOps 平台和工具的选择和治理政策。但是，让不同的团队或组独立工作是不明智的。否则，组织将以零散的工具进行许可、跟踪、集成、支持和维护其 DevOps 平台的生命周期。

COE 应帮助建立和指导初始的 DevSecOps 平台原型开发。当原型平台准备就绪时，COE 应帮助指导一个或多个产品团队过渡到新平台。当软件产品团队使用原型 DevSecOps 平台时，COE 和软件团队应合作改进和完善平台，以支持更广泛的使用。

一系列的滚动部署将有助于验证和构建其在更大规模组织中广泛部署的能力。 COE 必须准备好根据每个新部署识别的新需求进行必要的平台调整。此调整将包括支持额外的 DevSecOps 活动、工具和工具链的集成、自动化和配置。

持续学习和增强不断改进主要平台，将其推向下一个级别。然而，如果你没有正确建立基础平台，组织将起步不良，这可能会减少高管支持，从而减少未来投资和部署的机会。相比之下，构建正确的基本 DevSecOps 平台允许组织使用 VSM 来证明进一步的投资。但更重要的是，VSM 倡议指导扩展使用改进的 DevSecOps 平台，以支持跨企业的数字化价值流改进。

通过一个供应商或 COE 领导 DevSecOps 实践，并应用 VSM 原则，我们避免每个团队或每个供应商都需要成为 DevSecOps 和 VSM 实践的专家。可以这样想：我们聘请软件开发人员来构建软件产品，而不是建立他们的基于 DevOps 的软件工厂。

在大多数情况下，我们不会让制造企业中建造产品的员工去建造他们工作的工厂 - 也不应该期望我们的软件开发人员创建他们的软件工厂。是的，许多人可以学习成为 DevOps 工程师的技能 - 只要有足够的时间和实践。但这些时间和精力会从他们正常工作中交付新的和增强的软件产品的价值中抽取出来。因此，不要这样做 - 这是对他们时间的非增值浪费！

鼓励一个非常开放和协作的反馈文化是适当的，包括 COE、软件交付团队成员和相关供应商。正是这些协作提高了问题的可见性，并有助于改善 DevSecOps 平台。

定义 COE 的角色和职责

COE 包括 DevSecOps 工具和平台领域的专家。但它还必须包括或与组织的 IT 架构团队保持一致。DevSecOps 平台 COE 和 IT 架构团队的职责包括以下内容：

• COE 不制造任何东西——它们负责治理和政策：

  a. 以 DevSecOps 治理政策的形式建立一份做与不做的清单。

• 与高层管理人员和投资组合管理部门合作，建立 DevSecOps 平台改进计划和预算。

  评估软件即服务（SaaS）和 DevSecOps 供应商的产品：

  a. 单一 DevOps 平台，如 AWS、Azure、GitLab 或 HCL Software。

  B. 多工具平台，如 ConnectALL、Digital.ai、Plutora、ServiceNow 或 Tasktop。

  c. 定义启动 VSM 和 DevSecOps 工具及平台请求与审批的工作流程。

  d. 进行替代方案分析（AoA）。

  e. 与法律、IT 和财务部门合作，协商许可、条款和条件，以及服务水平协议（SLAs）。

  f. 建立并维护组织内已批准使用的 DevSecOps 工具列表。

• 指导任何相关的 VSM 团队和需要软件交付的 VSM 项目：

  a. 进行 IT 预算审查委员会或支持投资组合管理职能，确定软件价值流/产品开发支持优先级。

决定合适的 DevOps 平台策略

在 Pramod 看来，他认为最佳策略是选择DevSecOps 即服务（DaaS）供应商，而不是开源工具策略。DaaS 的例子包括Azure DevOps Services、GitLab和AWS CodeDeploy。他列举了几个支持这一观点的理由，如下所示：

• 它有助于避免与在联邦政府机构内使用开源工具时需要获得安全批准所涉及的 FISMA 和 FedRamp 合规性问题。

• 组织无需实施、集成和维护不同的工具。

• IT 组织无需编写基础设施即代码（IaC）配置。

  例如，开发定制的 DevSecOps 平台需要聘请 IaC 工具（如 Ansible、Terraform 等）领域的专家。

• 他已经成为 Azure Kubernetes Service 的忠实粉丝。

  组织无需安装 Kubernetes、维护 Kubernetes，也无需处理 Kubernetes 的复杂性。

Pramod 认为，大多数组织可以很好地使用基于 DaaS 的解决方案。然而，像 Netflix、Amazon、Google、Walmart 以及一些非常大的联邦机构这样的数字和高科技组织，对性能和大规模软件交付有着特殊的需求，这使得构建定制的 DevSecOps 和 CI/CD 管道成为必要。

但 Pramod 也意识到，一些 IT 人员认为，当他们能够集成特定的工具而不是服务时，他们对运营的控制会更好。而且，坦率来说，对于许多开发人员来说，DevSecOps 工具的选择是情感化的问题，因为他们的技能和能力是围绕一组特定的工具培养出来的。

与 Yaniv Sayers 的访谈

Yaniv Sayers 是 Micro Focus 的研究员和 CTO，负责其应用交付管理和软件工厂项目。Yaniv 在 IT 和软件行业已有超过 20 年的经验，经历并领导过多次转型。他和我通过虚拟方式会面，并讨论了我们在 DevOps 和 VSM 方面的经验。在我对他的访谈中，他为本节贡献了内容。我们从讨论 DevOps 实施中的主要陷阱开始，例如忽视组织 DNA、面临大数据的挑战，并探讨如何通过应用软件工厂方法克服这些陷阱。

认识到你组织的 DNA

Yaniv 强调，忽视一个组织的 DNA 是许多组织常犯的一个错误。在数字时代，想要保持相关性的组织会关注如何像 Facebook、Google、Amazon、Spotify 和 Netflix 这样的领先高科技公司，利用 DevOps 以子弹般的速度前进。

这些成功案例激励了高管和其他关键利益相关者。他们可能会感受到压力，想要变得更像这些其他组织，并认为通过实施这些组织使用的实践和工具，他们也能获得类似的成功。

然而，关于 DevOps 转型的这些流行案例，主要适用于数字时代诞生的组织。它们的员工是数字原住民，流程从一开始就很敏捷，技术也是云原生的。

这与金融服务、制药或政府部门的 IT 组织有很大的不同。许多企业仍然使用传统的软件开发方法论，如瀑布式或 Water-Scrum-Fall 流程。它们包含了从主机、大型客户端/服务器到云的一系列技术，而且他们的员工很多是在之前的时代培养的。许多人尚未能够适应或在我们的现代数字经济中竞争。

对于传统企业而言，"更快"的挑战甚至其含义可能与数字原生企业的体验有所不同。这些组织有不同的 DNA，Yaniv 认为这一点必须得到承认。他们可以从数字原生企业取得的成就和运营方式中汲取灵感，但不能简单地照搬数字原生企业的实施方式，也不能忽视他们的过去和当前环境。相反，他们需要在继续运营当前环境的同时，制定适合其 DNA 的转型计划。

以成果为导向

大多数组织采取以技术为中心的方法。他们从工具和设备入手，向外扩展到用户或消费者——然而，大多数未能实现预期的成果。例如，仅仅实施一个敏捷规划工具并不能让一个项目变得敏捷。项目仍然可能运行于长周期交付、没有快速反馈或团队成员发现很难转变为敏捷思维的状态。正如 Grady Booch 著名地说过，"有工具的傻瓜仍然是傻瓜。"

相反，最好从外向内的视角开始，与客户和消费者合作，达成对他们来说重要的成果和推动这些成果的价值流的一致意见。然后，基于期望的成果，你可以识别并确定所需的人员、流程和技术变革。例如，可能需要你为员工培训新的工作方式、定义新的角色和职责、改进现有流程，并实施新工具——所有这些都需要作为协作努力同步进行，以实现预期成果。

掌握平衡的艺术

速度、质量、成本和幸福感并不是相互竞争的，它们并非各自为政，也不应被视为权衡关系——它们是相互交织的。例如，假设你只关注速度而忽视质量，那么低质量最终会导致用户和员工的不满。低质量还会增加返工，进而导致更高的成本和技术债务，这些共同作用会导致交付速度变慢。

另一方面，更高的质量能够减少失败和返工的需求。因此，提高质量不仅能降低成本，还能加快交付速度，并促进幸福感（员工、客户和最终用户）。

利益相关者应该意识到，短期内感知到的权衡最终会导致长期的反向结果。相反，应当意识到这些权衡是相互依存且相互交织的。在这种背景下，IT 组织需要持续平衡速度、质量、成本和幸福感。

通过大数据做出更好的决策

Yaniv 经常遇到利益相关者根据直觉和猜测做出关键决策，结果导致一些人幸运地获得次优成果，而另一些人则遭遇重大失败——例如，在没有获得客户反馈的情况下，根据他们对用户和客户需求的猜测来优先考虑投资，在没有明确了解发布质量和安全风险的情况下决定是否将发布推向生产环境，或者在未意识到对其他服务影响的情况下更改接口和数据模型。

当决策者无法访问所需数据时，通常是由于一系列原因，如组织和政治壁垒阻止了数据共享，不同领域之间的“语言”差异使得共享上下文变得困难，系统之间缺乏集成导致无法访问和无法追溯数据点之间的关系。

在 DevOps 中，数据挑战变得更加严峻。随着持续交付周期的增加和自动化的转变，数据量呈指数级增长，决策者需要做出更加迅速且持续的意识决策。在实践中，这就变成了一个大数据挑战。

想要在大规模 DevOps 中取得成功的组织，必须解决大数据挑战，而让决策者能够追溯数据访问是第一步。此外，旨在实现价值驱动交付、意识清晰和持续决策、分析和机器学习的目标，应该将大数据转化为可操作的洞察力。

采用软件工厂模式

Yaniv 表示，企业组织在实施 DevOps 转型时，应考虑采取软件工厂模式。软件工厂将组织的战略规划与一整套集成的服务、流程、工具和数据对齐，使组织能够规划、构建、测试、发布、运营和管理交付给客户的软件。

首先通过外部视角创建基准，并与利益相关者合作，统一对能够赋能这些成果的结果和价值流的理解。然后，绘制主要活动、角色、系统和数据及其相互作用的图谱。

Yaniv 还指出，可以利用像 IT4IT 这样的框架，提供常见价值流的参考。例如，在 IT 中，面向 DevOps 的价值流包括从接收需求到交付给用户，或者用户遇到问题直至解决或偿还技术债务的活动。

接下来，分析问题，例如缺乏供利益相关者决策的信息、重复的系统、容易出错的手工操作、浪费的时间。针对每个问题，映射可能的改进领域，例如合并到标准的敏捷规划服务中以实现依赖关系管理和透明度、集成服务提供数据可视性、性能测试服务以支持左移和更早的故障检测。

在绘制价值流并分析问题后，你将拥有一个共同的语言和对重要结果、当前问题和机会的理解——换句话说，就是有价值的服务。然后，尽可能地采用共享服务，并在业务需求的情况下进行差异化。

那么，交付一个服务的机制是什么呢？Yaniv 指出，它们与交付数字产品的方式完全相同——通过采用基于敏捷的方法和持续改进。

Yaniv 表示，IT 组织应该采用迭代的、持续改进的方式来交付服务，从小处着手，并随着进展不断演变。他简要描述了使这一过程实践化的生命周期：

• 选择你的关键价值流：在分析价值流后，识别出需要改进的 2-3 项服务。一个价值流可以是知识库服务、质量管理服务、安全测试服务或任何其他关键 IT 服务。

• 创建最小可行产品（MVP）：MVP 的目的是验证服务的价值，减少未知因素，并通过少数几个消费团队进行孵化，以便快速获得反馈。然后，根据反馈在短周期内学习和改进服务。

• 创建标准模型：该模型作为蓝图，描绘了创建标准服务系统所需的技术、人员（角色和责任）和流程。然后，围绕技术和自动化进行实例化，确保你能够使其可用、可完成并在足够好的水平上运行。

• 上线：通过将改进后的服务发布给用户并部署所需的基础设施来使其在全球范围内可用，以便按需扩展。然后，测量和监控关键性能指标并进行优化。最后，积累经验教训，为下一个迭代做准备。

• 反复循环：完成第一次改进循环后，识别下一个 2-3 个服务，并再次通过这个迭代的持续改进过程进行循环。每个循环都会改善人员、流程和技术。

对于需要通过实施 DevOps 进行转型的企业组织，软件工厂方法有助于制定适合其企业 DNA 的转型计划，从小处着手，避免过度工程化，并允许持续改进。

你可以通过以下链接了解 Micro Focus 推荐的软件工厂方法：https://www.microfocus.com/en-us/digital-transformation/our-perspective/software-factory。

与 Allan Wagner 的采访

Allan "Al" Wagner是 HCL Software DevOps 咨询和采用团队的转型顾问/DevOps 爱好者。我和他在虚拟平台上见过几次面，并且在 VSM 和 DevOps 方面的看法产生了共鸣。他很友好地参与了我对他的采访，为本节内容提供了帮助。我们从讨论 DevOps 实施中的主要陷阱开始，重点是花钱在 IT 上却没有看到量化的商业价值回报。让我们看看他怎么说。

花钱却没有可验证的结果

当我问 Al 他认为 DevOps 实施中的陷阱时，他立刻想到了一个具体而常见的用例。具体来说，作为 HCL 的 VSM 和 DevOps 布道者，他经常听到潜在客户提到他们的 IT 经理和高管厌倦了花钱在 IT 上，却没有在整个组织中展现出价值。

我认为这个问题是我在本书中多次提到的。没有适当的对齐，组织可能会花费大量的资金、资源和时间来实施成熟的软件交付流水线。此外，正如 Pramod 在他的采访中所指出的，DevOps 既不容易学习，也不容易实施。如果任凭其发展，许多（如果不是大多数的话）软件开发团队缺乏集成、自动化和编排软件开发流水线的支持、资金，甚至技能。

坦率地说，这种工作甚至不是他们的责任。软件开发人员通过交付软件产品创造价值，而不是构建软件交付平台和流水线。

安全地失败

Al 指出，实施 DevOps 能力的一个主要陷阱是需要进行重大文化和组织变革。他提倡组织应逐步进行变革，以便能够安全地失败。IT 组织及其依赖的服务必须理解，并不是所有事情都会按计划进行。但是，为了提高成功的几率，我们也应该花些时间和精力进行规划！

通过命令进行管理

Al 和我讨论了 DevOps 项目通常是如何作为命令下达的。这样的命令存在多方面的问题。首先，高层的预期可能与现实不符。结果，往往没有进行事前规划，也没有足够的资金来购买工具、平台和培训。如果没有规划来确定组织的需求和要求，就很难正确识别预算。

此外，如果没有规划和构建原型 DevSecOps 平台，我们就把工作留给每个软件开发团队去解决——不管他们是否有时间和技能来处理这些问题。与此同时，他们的软件交付工作会受到影响。

即使软件开发团队克服了平台开发问题，仍然很可能没有足够的预算来执行实施工作——尤其是在大型企业规模下更是如此。所需的工具可能甚至未被批准在组织内使用，这对所有关注安全和风险的组织来说尤为重要，特别是合规性和治理问题是关键。未计划的成本也是一个因素。没有执行计划、预算预测，以及将投资与价值交付连接起来的手段，任何指令都是无效的。所有相关人员都会被置于失败的境地，这导致挫败感、更多的工作、错失的期望，最终甚至导致不信任。

在我之前的书《在现代企业中扩展 Scrum》中，我讲述了美国海军学院的田径教练阿尔·坎特洛的故事。在四年的日常训练中，我每天都听他一遍又一遍地说：“你们这些年轻人啊！你们只想要即时的满足感！”他的意思是，任何值得追求的事物都不会来得轻松或迅速。作为一名两次获得全美奖的标枪学生运动员和一名曾经打破过所有国内外标枪记录的奥运选手——他完全有权在我们需要重新集中精力时指出我们的问题。

我提到这个故事的目的在于，商业领域也同样适用这些原则。我们需要理解我们的目标，定义并设定可衡量的目标，规划如何实现这些目标，然后每天努力工作来实现它们。如果没有与特定目标和关键结果相联系的规划、原型（实验）、预算和资源，任何指令都是无效的。而且，OKRs（目标与关键成果）应该优先指导我们的计划、实验、预算、资源分配和工作。

错误的结果

这是阿尔·瓦格纳所引用的常见情境。多年来，组织们一直在制定并资助为期一年的或多年期的软件开发计划，结果却因为开发团队未能在项目的约束条件下交付而感到失望。在财政年度开始时，工程团队可能会提交每个季度的预算估算，或者是他们的全年度开发计划。经过协商，业务部门会批准一定的资金。然而，更糟糕的情况是，当高管和经理们仅凭 ROI（投资回报率）考虑，而没有考虑工作的实际情况来决定进度、预算和资源的限制时。

尽管如此，工程部门可能会欣然接受这些限制，并努力开发所请求的新特性或功能，可能每季度交付一次更新，或者每年根据项目预算交付一次更新。最终，利益相关者将有机会审查并检查工程部门构建的内容，但他们会发现自己并没有得到想要的结果。或者，业务需求发生了变化，但这些变化没有传达给开发部门。无论结果如何，情况总是一样——缺乏业务价值和投资回报。

敏捷实践的出现旨在使开发工作与业务及其客户不断变化的需求和优先事项保持一致。具体而言，敏捷解决了与传统项目驱动的开发模型相关的问题。随后，CI/CD 和 DevOps 流水线策略逐步发展，旨在更迅速高效地交付软件产品。

敏捷开发通过让团队更早交付、持续交付、拥抱变化以及与业务更加紧密地对接，修正了基于项目的软件交付模型。直到今天，这些因素仍然至关重要。改变和改进的是，更多的焦点放在交付业务价值上，团队致力于提高效率，并且通过数据做出决策，从创意到实施，乃至更远的地方。这就是基于 CI/CD 和 DevOps 的软件交付流水线所承诺的。

在早期，当组织开始进行 DevOps 之旅时，他们可能赋予了单独的软件开发团队选择自动化解决方案来构建和部署其各自交付流水线的权限。尽管单个团队可能喜欢这种自主性——这也是敏捷的精神——但这种做法创造了一些混乱，原因如前所述。

但还有另一个问题也在发挥作用。当工程和产品数据存储在多个不同的仓库中并采用不同格式时，商业领导者在基于数据做出业务决策时面临着挑战。

Al 指出，强制要求每个产品或项目团队在交付流水线中使用相同的工具集可能不切实际，因为有许多因素会决定哪种工具或解决方案最适合完成任务。如本章之前所述，我们不能忽视软件开发人员和运维人员在推动他们偏好的方法和工具方面的影响。

但组织可能能够通过允许团队选择最适合当前任务的解决方案来找到折衷办法——前提是这些解决方案能与提供整体视图或仪表板的方案（或多个方案）进行集成。这就是现代 VSM 与 DevOps 平台所提供的功能——通过在 DevOps 工具链中集成工具并采用统一的标准化数据模型，从而提供端到端、实时的软件交付流水线流程可视化。

寻找你的真相来源

无论一个组织是选择构建自己的仪表板，还是购买基于 COTS 的 VSM 解决方案，我们在托管用于填充仪表板并做出准确业务决策所需的数据时，需要访问几个事实来源。Al 列出了这些事实来源如下：

• 企业规划：一个共享的企业规划工具，提供组织内所有开发活动的视图。

• 版本控制：在组织内实现一个单一的版本控制系统，用于存储所有开发、构建、测试和部署软件时使用的资源。

• 制品库：所有可部署制品的单一位置。

• 发布协调：一个单一的数据来源，用于协调软件发布的自动化部署。它还提供了已发布版本的清单视图和已部署软件的位置。

• 质量管理：一个单一的数据来源，提供质量水平的详细信息。此外，这项功能支持可追溯性，将需求与测试用例、执行的测试以及相关的测试结果关联起来。

• 事件管理：一个单一的仓库，用于全面管理和协调企业内部事件的解决方案。

Al 提到，这种整合不同事实来源的方法，仍然为各个软件交付团队提供了关于工具选择的灵活性。但这一策略只有在有集成平台来链接业务领导依赖的共享数据仓库，以便做出明智的业务决策时才有效。

制定接受策略

这些缺乏信任的问题并不是一夜之间出现的——它们已经积累了很长时间。我们不能把打破随着时间推移形成的组织障碍的过程简化或缩短。而且，组织管理软件产品交付的时间也过长，因为项目通常受限于信息不足的预算、时间表和资源。这同样让 IT 部门面临失败的风险。

提供持续和可预测流的精益生产过程是改善我们交付软件价值方式的最佳途径。但精益方法也会极大地改变我们的工作方式。它改变了我们如何做出决策和衡量进展。它还改变了我们的工具并要求新的技能。

正如 Pramod 在前一部分所指出的，我们需要我们的高层领导提供资源，帮助引导组织度过这些变革。例如，组织的领导必须找到资源和预算，以便安装以下内容：

• COE

• 教练和导师

• 思想领袖

• 变革倡导者与创新者

• 原型合作

• VSM 和 DevOps 工具链采购

没有这些资源和坚定的努力，任何企业级的 VSM 和 DevOps 平台实施都注定会失败。而正如 Al 所说，"当好人遭遇不幸时，他们会回到他们熟悉的方式。"

向前推进

Al 提出了几个常识性步骤，帮助我们迈向一个更理想的未来状态，这个状态可以通过 VSM 和 DevOps 方法及工具实现，具体见下列清单：

• 在每周的时间表中安排学习时间。

• 爬行/行走/奔跑，逐步迈向成功。

  Al 表示：“你可能需要放慢速度才能走得更快。”例如，你必须分配时间、精力和资源来解决与技术债务相关的问题。

• 不要在没有高层支持的情况下启动 VSM 或 DevOps 平台实施计划。

• 与项目和程序管理驱动的发布计划脱钩：

  a. 基于 PM 的时间表由货币和 ROI 考虑驱动，这与支持不断变化的市场变化、客户需求和客户优先事项的日常现实脱节。

  b. 不应指望 PMO 理解开发团队的能力和约束。

  c. 团队负责人需要在制定时间表时提前参与，并与产品管理协商他们应该如何推进；例如：

  A. 我们需要更多的人吗？

  B. 每件事都需要成为优先事项吗？

  C. 我们在管道中应该设定哪些 WIP（工作进行中的任务）限制？

  D. 评估吞吐量作为流动来建立燃尽率。

  E. 建立机制，更好地在团队内以及与内部或外部客户之间进行协作。

这个清单为成功实施 VSM 和 DevOps 工具提供了一个起点。但如果我们没有认识到这些投资必须创造价值，那么这些都没有意义。

增加价值

在商业中一个基本的现实是，几乎总有比组织能投入时间、金钱和资源处理的事务更多。因此，最根本的更重要的是理解我们的优先事项，决定哪些东西能为我们的客户和组织的 OKRs 带来最大的价值。所以，专注于那些能为投资带来最大价值的事项，然后通过流动逐步交付这些价值。

Al 这样说：“专注于产品，并不断交付能为业务创造价值的增量变化。”他还指出：“更快乐的人能更频繁地向最终用户交付更高质量的软件。”Al 还表示，更愉快的工作环境能够消除员工流失问题，因为人们更愿意在高效的开发组织中工作。

我们将在第十六章中回到增加价值的话题，用 VSM 和 DevOps 转型企业。事实上，使用 VSM 推动整个组织价值流中的软件交付价值是本书的核心主题。现在，让我们继续前进，看看四种潜在的 DevOps 平台实施策略。

跳上云原生的快车道

最后，Al Wagner 提出了一个重要的观察，许多组织似乎正在纷纷加入云原生的潮流。云原生环境为利用基础设施即服务（IaaS）提供商的资源提供了巨大的灵活性，这些服务是按需付费和按使用量计费的，能够提供持续集成、容器引擎和云编排能力。

然而，Al 也提出了这一关键观点：“大型企业公司所使用的传统系统——这些系统经过多年独特功能的构建——在短期内不会消失。主机系统不会消失；它不会死亡。原因是，现代化这些传统系统和应用程序的功能有相当大的成本。[组织必须问]是否有足够的投资回报率来证明重写和迁移的合理性？”

我们将在后面的决定适当的 DevOps 平台策略小节中再次讨论这个问题。具体来说，长期运营一个混合云环境可能是有意义的。

与 Joel Kruger 的访谈

Joel Kruger 是一名 DevSecOps 工程师和 AWS 解决方案架构师，拥有 10 年的经验，在商业和政府部门建立 CI/CD 流水线。他也是使用容器编排系统自动化计算机应用程序大规模部署的专家。在他目前的角色中，他正在为一个拥有数百个软件产品团队的大型联邦机构构建可重复使用的 CI/CD 流水线配置。Joel 提倡将 CI/CD 流水线配置构建为可下载和自助服务的软件工厂。正是从这个角度，他讨论了潜在的 DevSecOps 实施陷阱和平台实施策略。

利用可重用的配置

Joel 提到，配置管理（CM）并不是一个新概念，而是一个必要的实践、政策和存储库集合，用于在产品生命周期内跨版本保持产品的一致性。

Joel 提到，CM 的理念来源于其他机构，如军队，软件社区借鉴了这些理念并加以改造，以保护我们组织的 IT 资产。Joel 还指出，CM 传统上是一项完全手动的任务，通常由系统管理员或初级开发人员完成。但是，在较小的项目中，CM 任务可能会落到更资深的开发人员身上。

无论如何，CM 角色曾涉及大量手动工作，需要仔细记录系统状态。但这些日子正在迅速消失，因为行业正在推动实现配置即代码。并不是说 CM 会消失；而是我们可以减少捕捉、维护和使用某些信息所涉及的非增值工作量。这些变化源于加速跨 CI/CD 和 DevOps 流水线的配置任务、支持基于云的计算环境以及实施新的基于 API 的自动化工具的需求。

然而，有时，配置管理会与版本控制混淆。两者有一些相似之处，都是跟踪产品、产品组件和信息工件在演变过程中的版本。主要的区别在于版本控制识别单个组件的变化，无论它们是否包含在生产版本中。相比之下，配置管理过程会跟踪所有软件和基础设施组件的版本，以及与每个产品版本相关的其他信息工件，贯穿整个生命周期。

我们已经讨论过，IaC 是确保所有已配置的基础设施通过代码进行自动化的实践。但 IaC 的一个补充目的，是建立一份书面记录，记录现有服务的位置、部署情况以及部署的条件。

配置管理（CM）可能看起来像是一个过于官僚化且没有增值的任务。然而，事实并非如此，因为组织必须在其生命周期内保护其 IT 资产。因此，并不是配置管理本身没有增值；而是我们为了记录、保存和将代码及其他工件与软件发布关联所必须采用的手动流程是繁重的。因此，组织可能会发现通过基础设施即代码（IaC）来记录代码和其他工件的使用更加容易，从而维护公司所拥有和部署的所有技术资产的完整记录。

Joel 指出，随着软件产品的成熟，并非所有组件和信息工件在每次发布时都会发生变化。然而，从版本控制的角度来看，问题可能会迅速失去同步。因此，配置管理对于维护产品的性能、功能以及与每个版本的独特要求、设计和操作信息相关的物理属性是必要的。

虽然配置管理不是一个新概念，但相对较新的做法是通过作为代码实现的配置自动化新版本的部署，具体表现为基础设施即代码（IaC）和配置即代码（CaC）。IaC 和 CaC 都属于现代配置管理实践，且两者都使用脚本语言在不同环境之间自动化配置。但这两个术语在具体语境中的使用意义不同。

让我们来看一下：

• IaC：这一方法用于定义您的 IT 基础设施，如网络、服务器、负载均衡和安全性等，形式为文本文件（脚本或定义文件），并进行版本控制。文本文件作为创建或更新指定环境的基准源。IaC 提供了一种可执行的规范，采用机器可读的语法，并包括能够生成虚拟化基础设施的步骤，能够作为发布进行版本控制，并在软件配置管理（SCM）库中进行跟踪。

• CaC：这定义了您的软件组件如何相互交互——通过指定应用程序、服务器处理和操作系统的参数和设置——这些设置也作为配置文件托管在仓库中。因此，CaC 使得能够在流水线的早期阶段构建和测试软件代码更改，从而更早发现和解决问题，并提高每次发布的质量。与 IaC 一样，CaC 实现了机器可读语法中的可执行规范，并包括将应用程序基础设施配置对齐为版本发布的步骤，该版本在 SCM 仓库中进行跟踪。

现在你已经理解了 IaC 和 CaC 背后的基本概念，让我们看看 Joel 是如何解释它们的使用方法和原因的。

实现 IaC 和 CaC 资源

Joel 首先指出，组织应通过基础设施功能模块化地架构其业务的 IaC 和 CaC 资源。例如，一个经典的基于 Web 的应用程序包括前端用户界面、后端业务逻辑和数据库。与其将所有配置代码放在一个文件中，不如将代码拆分成每个应用层的单独文件。这种模块化结构和解耦策略使得随着时间的推移更容易更换组件和系统。

这将帮助他们更好地定位工程师，迅速执行新的软件和基础设施部署，尤其是在以下事件发生时：

• 客户对特定工具和功能的需求发生变化。

• 需要将现有代码片段重新用于其他产品或产品组合。

• 之前实施的工具或第三方服务提供商的成本不可持续地增加。

• 替换业务需求。

在实践中，IT 架构远比之前提到的简单三层架构模型复杂。包含数百个应用程序的大型组织必须支持可能会随着时间变化的成百上千个配置选项。

到此为止，Joel 继续谈论如何利用 IaC 和 CaC 概念来改善互操作性。

维护互操作性

关于 IaC 和 CaC，Joel 指出，您必须在构建计划、手册、流水线和脚本时考虑互操作性。这种策略减少了采用新工具链时所需的代码重构和时间。它还将显著中断其他操作基础设施的机会降到最低。

Joel 建议最佳方法是鼓励开发人员使用输入参数，表示为环境变量和模板代码配置。这样，您解决方案的每个组件都可以像软件函数一样运行，并且可以在任何工具链堆栈的组合中被调用。

从代码中移除“秘密”

应用程序和系统安全是所有组织中的关键问题，或者至少应该是。 然而，Joel 提到，他看到太多开发人员在这些问题上走捷径，通过将密码和系统访问输入硬编码到他们的配置文件中。 他的底线告诫是“不要在源代码控制中硬编码秘密！”

相反，更好的选择是将它们作为加密数据存储在特权访问管理（PAM）工具中，例如 HashiCorp Vault、Akeyless Vault、Thycotic Secret Server、BeyondTrust 或 AWS Secrets Manager。Secrets Manager（或 PAM）通常会将敏感信息作为环境变量注入到容器运行时，或将其挂载为卷。归根结底，开发人员绝不能轻易让黑客看到应用程序的入口点、访问码和其他敏感信息。

大多数 Secrets Manager 都包含一个客户端进程，该进程旨在在微服务容器（Docker、Kubernetes）中运行，通过 Secrets Manager 服务器颁发的 API 密钥解锁秘密。在许多情况下，授权可以根据组或个人、每个秘密，甚至动态配置，以生成具有时效性的单次使用密码。Joel 提到，除了更安全之外，参数化秘密是确保软件配置可重用、可扩展和可扩展的关键步骤。

IT 组织应该指定为秘密的项包括用户名、密码、令牌、API 密钥、SSH 密钥、PGP 密钥、TLS 密钥、TLS 证书、IP 地址、端口号、域名、安全字符串和敏感文件。此外，IT 组织还应确定任何其他被视为秘密或受组织保护的数字信息，并将其包含在此列表中。

避免配置锁定

通过代码定义可重用的配置，减少了组织必须找到和维护的专家数量，以支持其 CI/CD 和 DevOps 平台。 IaC 和 CaC 还减少了每个软件开发团队在设置环境、运行测试和部署代码时所需的时间和精力。但如果配置变得无法使用，那么所有这些好处都将丧失。

考虑到这一问题，Joel 强烈建议开发人员不要硬编码那些会导致 IaC、CaC 或内部代码无法重用的键值对。相反，在可能的情况下，使用命令行输入、API 调用或实现可以提交到源代码控制并被自动化流使用的环境文件。

和参数化秘密一样，在代码中参数化关键的键值对项是确保软件配置可重用、可扩展和可扩展的关键步骤。

以下列表包含你应该参数化的键值对项：

• 资源值：CPU、内存、磁盘大小、虚拟机名称

• 云服务提供商属性：区域、可用区、AMI、VPC

• 网络配置：子网、IP 地址、域名、DNS 解析器

• 应用程序配置：应用名称、端口号、版本、依赖关系

• 容器编排：容器注册表、镜像名称、镜像标签

现在我们已经讲解了如何在避免配置锁定的同时对秘密进行硬编码，接下来我们来看 Joel 关于频繁发布的观点。

鼓励频繁发布

Joel 引用了 CI/CD 和 DevOpsOps 管道构建中经常提到的一个目标：“如果产品的主代码分支在 20 分钟内无法成功部署到生产环境，你就没有正确实施 DevOps。只有经过彻底测试并符合客户规范的稳定部署才算有效。”

换句话说，Joel 鼓励开发团队频繁地向应用程序推出较小的改进单元。Joel 建议产品发布过程应完全自动化，通过一键式实现或尽可能接近的方式来实现这一目标。他还指出，借助现代 CI/CD 工具，即使在许多仍有主机的旧版环境中，也能构建这种能力。

遵循快速构建和发布的理念，确保客户会体验到不断符合需求的改进流。这一策略即使在你的产品或服务尚未包含客户所希望的所有功能时，也能改善客户体验。

目标是确保每次新版本发布都能够逐步更紧密地与客户的期望对齐，而不是更少。同样重要的是，这种策略可以极大地减轻你所在组织或业务单元在功能尚未准备好之前就部署新特性的压力。没有任何 IT 组织希望因为发布的版本不适合生产环境而不得不回滚。

相反，安装了快速构建和部署能力后，客户可以看到具体的证据，证明他们的需求在失去对你产品的兴趣之前一直被考虑。

在频繁发布、且通常跨越不同生产环境的情况下，我们需要确保在每次发布时构建并部署正确的配置。

配置正确的 DevOps 平台

Joel 声称，没有办法避免创建和维护利用基于 API 的基础设施部署的脚本或配置。无论你的组织是实施 SaaS，还是在本地或云 DevOps 平台上运作，这一声明始终适用。

Joel 进一步指出，DevOps 平台策略可以分为以下三大类：

• 声明式配置

• 程序化的自助式 SaaS/PaaS 工具

• 两者的结合

使用声明式配置策略的好处是，所有的 IaC、CaC 和参数都可以存储并在源代码管理中进行审计。该策略便于变更管理，并且在进行安全审计时，能够为组织提供稳固的立场。

这一策略在政府和金融行业中非常流行，通常在企业组建一个集中式 BizDevOps 团队，来编写所有开发团队必须围绕的批准的 IaC、CaC 和自动化模板时使用。这一方法的好处是，个别团队可以拥有更多的自由度来创建和管理自己的运营基础设施。

缺点是，自动化流水线无法像自服务 PaaS/SaaS 方法那样良好扩展。很可能会创建多个庞大的代码库，每一个都需要追踪和维护，还需要维护它们相关的 CI/CD 流水线和其他工件。

另一方面，Joel 指出，如果你的组织更倾向于围绕软件终端、API 驱动的 Web 服务、临时部署和第三方供应商来标准化业务流程，那么程序化自服务 SaaS/PaaS 策略是最优选择。通过这种方法，基础设施可以按需通过程序化方式组装、配置并提供，适应不同的工作负载。一旦每个服务的工作负载执行完毕，任何生成的工件和元数据都会被推送到持久化存储，并且之前使用的基础设施会被重新配置，以供其他人使用。

这种方法的好处在于，业务流程可以根据需求扩展，并且减少了管理开销。缺点是，将活动集中到标准化流程中，可能会让开发团队感觉不灵活或受限。另一挑战是追踪治理和问责制的变化。

当然，Joel 指出，从 DevOps 平台决策的角度来看，这个问题从来不会那么简单明了。有些情况下，治理和问责制可能优先于可扩展性。在某些其他情况下，事务的速度和流畅度比维护广泛的审计配置更为关键。因此，大型组织应做好准备，维护不同的 DevOps 平台解决方案和配置，以支持它们多样化的业务需求。

采用软件工厂策略

当有效地进行联邦化时，企业可以通过允许各个 CI/CD 和 DevOps 流水线开发团队构建和维护可扩展服务，从而在一定程度上实现去中心化，这些服务可以供企业其他团队使用。这一策略经济高效，有助于培养跨职能协作、共享责任以及价值流生产力提升的文化。Joel 指出，落实这些原则的一种非常有效的方法是开发软件工厂。

软件工厂是一个结构化的相关软件资产集合，旨在根据特定的、外部定义的最终用户需求，通过组装过程来帮助生产计算机软件应用程序或软件组件。借助 IaC 和 CaC 能力，软件工厂概念使得基础设施和应用程序基础设施的快速自动化部署成为可能。

Joel 认为，组织可以将这些概念扩展到包括业务开发和安全操作应用程序。实质上，软件工厂将传统的制造技术和原则应用于软件开发、基础设施部署和业务运营。

对于那些有兴趣深入探索实施软件工厂和自动化技术的细节的人，Joel 在其网站dynamicVSM.com提供了更多细节。该网站是 DevOps 和 VSM 技术技巧的汇聚点，包含代码片段、可克隆的演示、教育练习、相关信息以及行业新闻。

Joel 认为，采用软件工厂提供了实施精益价值流基础的最有效解决方案，能够帮助组织的 DevOps 平台实现这一目标。当 DevOps 的快速软件交付能力与业务战略和目标对齐时，有助于简化所有组织价值流活动，从而显著提高用户生产力。此外，采用具有可重用配置的软件工厂，可以帮助以 IT 开发为导向的价值流在所有业务应用程序中建立标准化和一致的用户界面，减少最终用户培训的需求。

Joel 指出，企业需要不断演变，以支持不断变化的业务、市场和客户需求。同样，组织的业务应用程序也必须同步演变，以实施新的流程变更。通过可重用和可扩展的软件工厂提供的新功能的部署简便性，以及灵活的用户界面，使得组织的业务应用程序能够演变以支持新兴需求，并帮助最终用户执行任务，实施新的业务工作流。

我们已经完成了与 DevOps 实施专家的访谈。在这些访谈中，您了解了专家们对于 DevOps 实施陷阱和平台部署策略的看法。在接下来的部分，您将学习到四种常见的 DevOps 平台实施策略。

决定一个合适的 DevOps 平台策略

现在，您已经了解了一些潜在的 DevOps 实施陷阱，我们将开始学习四种可选的 DevOps 实施策略。随着时间的推移，用于部署 DevOps 能力的平台发生了变化，其中一些平台今天比其他平台更为常见。

在本部分中，您将了解四种常见的 DevOps 实施策略，以及它们的潜在应用。

这四种实施策略包括以下内容：

• 构建自定义 DevOps 工具链

• 购买 DevOps 即服务/DevSecOps 即服务（DaaS）

• 基于 VSM 工具的 DevOps 平台集成与编排解决方案

• 开发 DevOps 管道配置作为可重用的软件工厂

每个选项都有自己的一套优缺点，我们将在本章中探讨这些内容。我们将从构建自定义 DevOps 平台解决方案选项开始讨论。

构建自定义 DevOps 平台

正如本小节标题所示，这种方法涉及内部 DevOps 工程团队进行集成、自动化和编排工具，以构建自定义的 DevOps 平台。这是 DevOps 早期唯一可用的方法。你可以将这一策略比作建造一辆定制的赛车，并且还要配备建造它的工具。或者，换个比喻，像是购买并建立你的制造设施，并进行安装。因此，你将面临两类问题——为你的软件交付平台构建工具以及构建该平台。

今天没有实际的理由去这么做。没有任何技术要求能使这种策略有效。相反，今天选择这条路的唯一动机是建立帝国和确保工作安全。此外，当独立的软件开发团队无法获得企业的支持和资金时，可能会自己选择这条路。

Al Wagner 喜欢将这一策略称为 源源不断地索取的礼物。走这条路的组织未能正视定制集成、许可、支持和维护问题的负面影响。过了一段时间，DevOps 工程团队花费越来越多的时间在维护配置上，而在构建软件产品上所花的时间越来越少。而且，如果你的 DevOps 工程专家离职，公司将陷入巨大的麻烦！

现在，让我们讨论一下另一端的情况，即使用采购 DevOps 平台即服务的方式，在这种方式下，所有安装软件交付管道所需的工具都可以获得并集成。

购买 DaaS

这一策略涉及购买一个已经集成的平台，其中包括一个端到端的工具链，以支持软件交付。例子包括 Amazon Web Services（AWS）、GitLab、Microsoft Azure DevOps，以及许多独立公司，它们集成了第三方 DevOps 工具，并作为 DaaS 产品提供云端服务。

供应商锁定是这一方法的最大缺点，而且他们的平台可能不支持你组织所需的工具。另一方面，几乎所有 DaaS 供应商都允许你集成其他工具来创建定制解决方案。但如果你的组织全力投入定制呢？在这种情况下，他们将承担集成、自动化和编排这些不同工具所带来的问题，这些工具用于开发支撑业务运行的 DevOps 能力。

此外，你的数据存储在别人的环境中。我们都需要问自己，如果他们或你的系统出现故障会发生什么？软件支撑着我们的数字世界。我们在商业中所做的每一件事都依赖于软件。因此，如果没有控制你的数据和应用开发管道，一旦它们遭到黑客攻击或发生故障，可能会带来灾难性的后果。

此外，如果你的 DaaS 供应商的工具和平台产品变得过于昂贵怎么办？你是否被锁定在一项协议中，想要退出时会面临巨大的财务压力？迁移到云端是一个非常昂贵且需要多年时间的项目。你是否有足够的投资回报率来证明进行 DaaS 推广的合理性？如果必须更换 DaaS 供应商，你是否能够承受失去或需要弥补 DevOps 实施投资的风险？

还有另一个问题。假设你有一个组织，已经在 DevOps 工具和平台上进行了投资。如果你的公司考虑强制迁移到 DaaS 解决方案提供商，那么领导层和 COE 需要评估公司是否有能力顺利完成迁移。

如果你现在的做法并没有出现问题怎么办？组织的高层需要深入审视他们希望修复的内容。高层通常希望避免 DevOps 工具投资和工具链集成的成本。而且，他们可能会对长期的维护成本和可支持性问题有所担忧。他们对此类担忧并不错误。但在进行如此重大的变革之前，组织必须对替代方案进行彻底的调查和分析。另外，不要强行在一夜之间执行强制性措施。要花时间规划迁移，包括在大规模迁移之前进行多次原型测试和小范围推广。

顺便说一下，采用基于云的 DaaS 解决方案并不是错误的决定。但在许多情况下，向基于平台的工具套件进行大规模或企业级的迁移可能会耗费时间且资源有限。我们还需要考虑 DevOps 迁移对客户的影响。在迁移过程中，我们是否能够在不丧失服务的情况下维持交付？如果迁移失败，我们如何确保能快速回滚？

DevOps 通常并不是解决难以处理的技术问题——而是解决业务问题。因此，我们需要将迁移到基于 DaaS 的解决方案视为一个业务决策。

Al Wagner 提出了一个重要的观察，值得我们关注：“主机并没有消失，它们并不会消失。那些经过多年独特能力构建的遗留系统并不会消失。复制它们的能力是巨大的成本。（组织必须问自己）是否有投资回报率来证明重写和迁移的合理性？”

所以，我们已经看到了两个极端的选择：一个是自己构建 DevOps 平台解决方案，另一个是购买一个完全启用的 DaaS 基础解决方案。现在，让我们看几个处于中间的备选方案：使用 VSM 工具和构建可复用的软件交付工厂。首先，我们从基于 VSM 的 DevOps 平台解决方案选项开始。

使用 VSM 工具

我们可以使用 VSM 工具来帮助集成、自动化和编排各种工具的能力。这又回到了集成不同工具链以及将数据作为决策的真实数据源问题；也就是说，商业决策应基于六个真实数据源中的数据：企业规划、版本控制、工件仓库、发布编排、质量管理和事件管理。无论你部署了什么工具，都需要将数据集成到你的数据仓库中。

使用端到端数据来做决策。我们并不关心你在特定任务中使用什么 DevOps 工具，但你需要访问那些工具中维护的数据。因此，最好能让这些工具与一个真实数据源进行通信，并使用一个通用且标准化的数据模型进行分析和决策。正是通过集成回主要数据源，完成了所有的艰苦工作。缺点是，VSM 工具可能没有所有必要的集成适配器和连接器。因此，你可能需要通过自定义 API 来解决集成问题，或者利用 DevOps 工具供应商的插件框架。

构建可复用的软件工厂

创建内部团队或使用外部软件集成团队，开发能够通过 Git 或其他 SCM 工具下载的自服务 CAC 的软工厂。以下是这三类定义：

• 基础设施即代码（IaC）：比如 terraform 部署。

• 代码即管道（PaC）：整个无缝的端到端集成、自动化和编排，通过提交时执行的脚本完成。这会触发 Jenkins 或 Ansible 中的一组完整的 API 命令。整个过程都由代码实现。

• 自愈管道：任何执行中的错误（Jenkins 或其他自动化工具）都会触发机器可读的错误，并使用工具和自动化运行手册来修正并重新运行失败的步骤。

换句话说，如果 DevOps 团队发现自动化失败并进行修复，然后团队会对问题进行分类诊断，找出根本原因并构建修复方案。接下来，他们将修复方案编码为一个自动化的运行手册，作为 Jenkins 文件的一部分来处理这类错误，以防未来再次发生。（这就是我们所说的自愈）。

本小节完成了我们关于如何决定哪种 DevOps 平台实施策略最适合贵组织需求的讨论。你已经了解了四种基本策略。现在，我们将讨论如果贵组织的高层管理人员在没有充分规划、准备和预算的情况下强制实施 DevOps 能力，你可以采取的措施。

处理公司实施命令

DevOps 是一个至关重要的业务推动者，以至于公司高层和业务主管可能会通过公司命令推动这一过渡，而没有足够的时间来规划、准备和预算，以支持企业级的部署。当这种情况发生时，最佳的 DevOps 实施策略是选择DevSecOps 即服务（DaaS）。IT 部门不需要实施 DevOps 工具并维护集成工具链即可开始。而且，当由公司命令推动时，决策者可能并不清楚技术实施选项、工具和工具链的替代方案、配置和集成要求、成本以及其他问题。

DaaS 是一种多租户实施概念。软件多租户指的是一种软件架构，其中软件至少在一台服务器上运行，但更常见的是在多台虚拟化服务器上运行，并为多个租户（客户）提供服务。DaaS 的例子包括Azure DevOps Services、GitLab和AWS CodeDeploy。此外，需要在多个环境中部署基于微服务的应用程序的大型组织可能会考虑使用Azure Kubernetes Service。

关键的是，基于 DaaS 的开发人员不需要编写 IaC，因为 DaaS 平台已经包括了一个集成的工具链。大多数 DaaS 解决方案是可扩展的，允许软件团队将其他工具作为定制服务添加到其基本平台服务中。如果交付团队想要创建一个自定义的 DevOps 平台，他们将需要具备或雇佣如 Ansible 和 Terraform 等 IaC 工具的专家。

当被要求快速部署 DevOps 时，还有其他需要考虑的因素可以提供支持。例如，使用以用户为中心的设计（UCD）过程，专注于能够帮助业务的功能和能力。这些工具让客户和用户在你开发代码之前就能看到他们想要的功能。因此，UCD 过程发生在你编写第一行代码之前！

开发人员可以使用如 Adobe InDesign、AXURE 和 Balsamic 等线框图工具进行 UCD，创建用于业务工作流的可视化展示。这是一项非常棒的功能，因为它有助于简化开发过程中的模糊前端。UCD 概念还大大减少了设计时间和由于代码缺陷而产生的返工。缺陷是误解或先前未识别的需求，客户觉得你应该早已知道并实现这些需求。

自动化测试是 CI/CD 流水线中的关键能力。团队可以使用诸如 Leapwork（www.leapwork.com/）等工具来实现低代码/无代码的自动化测试解决方案。

当高层要求实施 DevOps 能力时，VSM 工具变得更加重要。在这种情况下，一切似乎都急于进行。毕竟，这一任务的下达可能是因为组织未能向客户交付足够的价值。

如果组织未能履行其 DevOps 任务，情况会变得更糟吗？现代 VSM 工具提供了软件交付团队需要的指标，以改善基于价值的交付并展示他们所取得的改进。简而言之，VSM 工具有助于识别瓶颈、协调工作并提高流水线效率。

但是，软件交付流水线中仍然有一些领域难以整合、自动化和协调。这是下一节的主题。

处理创意活动与可重复流水线活动

提升价值流交付的一个挑战是与自动化或甚至估算概念构思、需求定义和分析所涉及的工作范围相关的挑战。在软件开发中，我们将这个阶段称为模糊前端。

这一术语最初由史蒂文斯理工学院的教授彼得·科恩提出。它指的是与创造新产品创意和概念相关的价值流活动，这些活动需要经过分析，以确定其是否符合客户需求和商业可行性。

其中一些活动由产品管理或产品负责人控制。这是因为他们单独负责决定产品中包含什么内容以及不包含什么内容。但开发团队也会参与其中，因为他们必须评估实现每个新需求所需的难度和时间。在敏捷中，我们将评估需求称为产品待办事项清单优化。

HCL 软件的同事们很友好地允许我展示他们关于模糊前端创意方面如何融入整体软件交付流水线的观点，如图 15.1所示。

这个软件交付流水线图的重要特点是突出软件开发中创意与可重复的方面，二者被划分为敏捷和 DevOps 实践。

垂直线左侧的部分是模糊前端，创意是决定性努力，难以估算。然而，右侧的部分是承诺并且可以自动化。因此，左侧的部分需要创意、思考、设计思维等，而右侧的部分则成为自动化软件交付工厂的一部分！

图 15.1 – 处理创意活动与可重复 DevOps 流水线活动的区别

Al Wagner 阐述了一个 DevOps 实施场景，涉及三个阶段，他称之为零天、第一天和第二天。让我们来理解它们的每个阶段：

• 零天（在代码提交之前）：敏捷实践的敏捷实施，涵盖冲刺计划、冲刺执行、发布、提交等内容。这是开发过程中的创意阶段和模糊前端，难以估算和自动化。然而，这些活动帮助我们保持对客户的关注。

• 第一天（在代码提交之后）：这包括集成、自动化和编排 DevOps 流水线活动。在这里，IID 模型通过集成和自动化工具链的能力变得更加精简。

• 第二天：这是我们希望达到的状态。即 VSM 的应用——专注于满足业务需求——这意味着我们需要对模糊的前端（敏捷）和 CI/CD 自动化流程有一个全面的视角。它包括不断地监控、跨团队协调并不断改进。通过实验寻找更好的方法，可能通过 AI 来评估需要改进的领域和方法。始终使用交付周期时间和周期时间作为改进的实际指标。

我们还可以利用 VSM 技术跨越所有组织的价值流，确定那些能从 DevOps 快速高效的软件交付能力中受益的高优先级/最高价值的改进活动。这个想法是，我们可以花费大量的时间、金钱和资源来构建我们的 DevOps 流水线，但如果这些新能力没有应用到组织最具影响力的价值流改进计划上，那么就看不到任何真正的业务影响。例如，我们可以使用 OKRs 和加权最短作业优先（WSJF）（一种在精益敏捷框架（SAFe）中使用的方法）来帮助团队优先排序一系列的改进举措。

此时，你已经听到了关于 DevOps 实施潜在陷阱的不同观点，以及如何应对可能面临的挑战的建议。你还了解了四种不同的 DevOps 平台实施策略及其优缺点。接下来，你了解了当组织高层要求使用 DevOps 时应采取的最佳方法，同时也了解了为什么自动化软件交付流水线的后端比自动化模糊前端要容易。现在，我们将深入探讨如何解决一系列潜在的 DevOps 平台实施问题。

解决 DevOps 实施的陷阱

在本节中，您将学习应对 18 种可能对您的 DevOps 实施计划构成挑战的情景的策略。这份清单并非旨在涵盖您可能面临的所有情况，但它相对全面。在阅读这些子章节时，开始思考如何应用您所学的 VSM 概念、方法和工具，来发现问题及其根本原因，以及如何加以改进。

让我们从识别并避免 Conway 定律的后果开始。

避免 Conway 定律的陷阱

1968 年，梅尔文·E·Conway 为哈佛商业评论（HBR）写了一篇题为委员会如何创新的文章。不幸的是，HBR 因为他未能证明其论点而拒绝了这篇文章 (www.melconway.com/Home/Conways_Law.html)。然而，Conway 坚持不懈，并将论文提交给Datamation，该期刊于 1968 年 4 月发表了这篇文章。他的坚持最终得到了回报，因为他在文章中的一个观察是，组织倾向于创建那些镜像组织内部沟通结构的系统（Conway 将系统定义得较为宽泛）。

这是原话，逐字逐句：

Conway 定律 (www.melconway.com/Home/Conways_Law.html)：

"任何设计系统的组织（广义上定义）都会产生一个其结构是该组织沟通结构的复制品的设计。"

——梅尔文·E·Conway

虽然 Conway 在多年前就做出了他的观察，但今天这一观察依然非常相关，包括其在交付软件的系统中的应用；甚至在现代基于 DevOps 的软件交付系统中也是如此。所以，让我们利用我们所学到的精益生产系统的知识，来理解 Conway 观察的后果。

价值流管理方法和工具帮助组织通过消除浪费并改善工作和信息流来优化其价值流。然而，如果 DevOps 团队被要求创建一个支持关键业务流程的应用程序，那么根据当前的运作方式来构建其逻辑是没有意义的。相反，业务应用程序需要支持通过 VSM（价值流管理）计划所识别的工作和信息流的改进。

Conway 定律同样直接适用于软件交付团队作为一个系统。事实上，这些是描述 Conway 定律影响时最典型的使用案例。简而言之，任何构建的软件应用程序将拥有与参与其构建的不同组织一样多的层级或模块。实际上，软件将镜像团队如何分配活动和沟通的方式。

Alan MacCormack、Carliss Baldwin 和 John Rusnak 在 2012 年的《哈佛商业评论》文章中讨论了与 Conway 法则相关的研究成果，文章题为 探索产品与组织架构之间的二重性：'镜像'假设的测试。他们在文中指出了以下相关性：“镜像假设预测这些不同的组织形式将会生产出具有明显不同架构的产品。具体来说，松耦合的组织将会开发出比紧耦合的组织更具模块化的设计。”

现代的 CI/CD 和基于 DevOps 的软件交付团队采用微服务、容器和 API，这些都支持松耦合的应用程序。松耦合的服务是可重用和可互换的，并且在实现时不会破坏现有的互联关系。

Conway 法则描述了组织结构对软件开发的影响。例如，作为一个松散集合体的庞大产品团队将会在工作流程、沟通和信息流动中造成瓶颈。将软件交付视为一个价值流时，我们知道需要通过围绕端到端的价值交付流程水平对齐团队来消除这些人为障碍。我们还必须消除阻碍持续和同步流动的浪费。

实施 CALMS 框架

Damon Edwards 和 John Willis 最初提出了缩写 CAMS，代表 文化（Culture）、自动化（Automation）、衡量（Measurement）和 共享（Sharing）。后来，Jez Humble 增加了一个字母 L，将精益（Lean）纳入缩写中，形成了 CALMS。CALMS 框架是一个用于整合 DevOps 团队、其活动以及它们所使用的系统、工具和工具链的概念模型。CALMS 缩写中的各个元素定义如下：

• 文化：要求从指令和控制、层级化的组织商业结构转变为具有共享责任的协作工作环境，并围绕横向流动进行组织，以支持基于价值的交付。

  DevOps 文化欢迎变化，利用反馈和信息（度量指标）进行持续改进，并对团队的工作承担责任。与精益（Lean）类似，DevOps 文化将决策尽可能地下放给那些执行或负责工作的人员。

• 自动化：在 DevOps 中，转型包括尽可能地自动化手工任务。例如，回想一下右侧 自动化交付流水线 中的 CI 和测试自动化活动，如 图 15.1 所示。

  基于 DevOps 的软件交付流水线消除了重复的、非增值的手动工作。基础设施即代码（IaC）和配置即代码（CaC）功能产生可重复和高质量的流程及可靠的系统。事实上，无论你使用什么工具，"一切皆代码"的思维方式都是 DevOps 自动化的核心。测试自动化（通过自动化部署打包构建并将其推进测试环境）实现了持续交付（CD）能力。

• 精益：这涉及通过消除创造延迟、等待和过多工作进程（WIP）的浪费，来实现流程的持续改进。精益旨在实现“流动”（FLOW）——将工作从一个工作中心平稳过渡到下一个工作中心——在最短时间内，理想情况下尽可能减少排队和缓冲。这正是本书的核心内容。

• 衡量：如果我们不知道问题所在、问题的根本原因以及哪些因素最能影响我们快速、频繁且高质量地交付价值，我们就无法解决问题。为此，我们需要度量和分析。首先确定你最关键的精益度量指标，从 DORA 四大指标开始：交付周期（变更的交付时间）、变更频率、变更失败率和 平均修复时间 (MTTR）。

• 共享：DevOps 本质上是一种协作策略，旨在对齐开发（Dev）和运维（Ops）活动。要想成功，开发和运维不能是相互隔离的“信息孤岛”。相反，它们必须找到共同的目标，而这个共同目标围绕着交付和维持客户会重视的软件产品而形成。但仅有协作是不够的；他们还必须共同承担产品在整个生命周期中的成功责任。

决定合适的 DevOps 平台战略

本章前面，你了解了四种 DevOps 实施选项：构建你自己的 DevOps 平台、购买 DaaS 许可证、使用 VSM 工具和构建软件工厂。我们不需要再次讨论这四种选项的优缺点。然而，我们需要解决一些其他问题，例如使用容器和混合云环境。

容器是一种软件，它将代码及其所有依赖项打包在一起，以便无论目标计算环境如何，都能快速且可靠地部署应用程序。然而，如果你的组织没有达到非常大的规模，使用容器编排工具（如 Kubernetes、Mesos 等）可能会显得过于复杂。所谓非常大的规模，指的是像 Google、Amazon、Netflix 等公司，以及大多数政府部门和其他拥有大量不断发展的基于互联网服务的企业。

如果你的员工对容器编排工具不熟悉，实际上它可能会成为一个损失价值的选择。例如，即使是熟练的开发人员，也觉得 Kubernetes 很难学习。因此，弹性容器服务（ECS）或自托管的 Docker Swarm 模式对于大多数组织来说更为合适。甚至使用传统的 虚拟机（VM）环境也可能足以支持你的扩展需求。顺便提一下，即使是 Kubernetes（也叫 K8s）也必须运行在虚拟机上。

如果你致力于使用容器，并且你的公司有一小部分开发人员，恰好能够招聘到几位超级 K8s 忍者，他们是可以让这一切运作的。但是，在小型开发公司中拥有这种人才是非常罕见的，而且对于组织的应用部署需求来说，可能并不具备成本效益。

如果你的团队计划在某个云服务提供商（如 AWS、Azure、GCP 等）中运营，但又没有相关经验，最初采取 混合云 方法可能更为合适。换句话说，利用你在本地的网络和计算资源，逐步迁移到云端。这种渐进式策略使得迁移更加安全，直到你的团队正式决定准备好切换到 100% 云架构。

混合云方法仍然需要投资新的技能。例如，你的开发人员需要学习所选云提供商的 API 和一些独特的特性（即 JSON 或 REST API 语法，Bash 或 Python 脚本用于 IaC 应用程序，Jenkins 和 Bamboo 等自动化服务器，这些都需要专门的脚本编写知识）。

无论你选择哪种 DevOps 平台实施方案，如果没有配备好足够的专家团队来维护，最有效或最先进的工具可能都太难以维护。而且，在 400 多个被分类为 DevOps 组件解决方案的工具中，你将使用哪些工具，为什么？最后，你需要实施什么样的治理方案来评估这些工具、处理许可问题，并做出明智的预算决策？

最后，如果你的工作场所面临人才短缺的情况，那么你的选择将受到团队整体技能和经验的限制。那么，你如何使用 VSM 技术帮助你的组织解决这些问题？一旦选择了 DevOps 实施策略，你如何使用指标来持续改进你的软件交付流程？

避免强制执行

我们之前谈到过，当实施基于 DevOps 的软件交付能力的过渡是通过高层指令强制进行时，DaaS 是一个可行的选择。这类指令的业务驱动因素可能包括一个迫切的情境，或者意识到组织错失了在数字经济中有效竞争的机会。

无论动机如何，在支持数字化转型时，架构您的 DevSecOps 解决方案时，VSM 路线图应从客户当前的工作流程和方法开始。迅速剥离开发团队当前的做法并强制要求实施根本不同的方法，会带来意想不到的成本，降低产出，并打击团队士气。

最终的关键是，人们需要接受变革；变革不能强制实施。然而，假如您鼓励您的 Dev 和 Ops 团队成员参与 VSM 价值流图谱，并采用基于 Kaizen 的方法进行精益改进，那么这些团队成员更有可能接受任何已识别的变革场景，并协助过渡过程。

避免浪费时间

精益本质上是消除浪费，包括那些占用我们交付以客户为中心的价值的时间的活动。最大的时间浪费之一就是开会，而不是工作。是的，我们必须保持信息畅通，但贵组织的领导者必须不断问自己，某些会议是否真有必要。是否有更好的方式让人们保持信息更新？如果必须开会，领导者还需要问谁真的是必须参加的。

保持每日站立会议简洁明了，专注于识别已完成的工作、具体的问题或障碍，并确定行动项。会议之所以叫站立会议是有原因的。它把问题拉到线下，只有相关人员参与。换句话说，您应该为问题解决单独召开会议。

避免长时间的 DevOps 规划和实施会议。大规模的会议已经变得非常流行，尤其是在 SAFe 框架下，拥有大型培训班和程序增量（PIs）。大型会议在内容相关、有信息量且能引人入胜时有效。但是，除非您能将大团队划分为小团队并在会后将各组分享发现，否则大型会议永远无法用于解决问题。

无论做什么，我们都必须问自己，这个会议是否让我们的团队更精益、更敏捷？如果无法为会议清晰地定义一个以客户为导向的可交付成果，那么会议很可能是不必要的。一个常见的问题是，您的客户是否愿意为这场会议付费——因为这就是您举办每场会议的最终结果。换句话说，您的客户最终通过购买您的产品和服务来为这些会议买单。

始终从增值的角度看待会议，就像您现在能够在任何其他价值流活动中做到的那样。最终，您的会议只有一个目的——改善组织的价值流交付。否则，从精益视角来看，它们就成了一种浪费。

消除信息孤岛，增加跨职能团队的协作

我们在本书中已经多次讨论过这个主题。但从根本上讲，这就是 DevOps 的核心理念。我们不再让开发和运维团队各自独立工作，而是将它们汇聚在一起，进行协作，提升软件价值交付。

然而，从增值的角度来看，“DevOps”这个术语实际上是有局限的。本书提到了 DevSecOps，它包括与安全部门的协作，确保我们的网络和应用程序安全。然而，在数字经济中，越来越难以将其他组织和开发价值流中的工作与软件交付价值流分开。因此，我建议在提到 VSM（价值流管理）倡议时使用BusDevSecOps这一术语，它代表着作为战略转型的一部分，以在数字经济中竞争。

BusDevSecOps 方法鼓励跨职能团队协作，打破功能型组织模式中的层级隔阂。BusDevSecOps 的目标是促进横向工作、物资和信息流的开发，从而提升商业价值交付。

假设在敏捷方法中有一个重要的经验教训：人员的数量并不是未来成功的主要指标，反而可能因为规模带来的日益增多的相互联系成为失败的根源。相反，人员在小团队中工作时最为高效。

扩展是通过各种团队间协作的概念来实现的，但当团队将价值流整合以支持工作流时，效果最好。最终，技能的多样性、相关经验和跨团队的协作是推动组织成功的关键因素。

提升技能变得至关重要

VSM 通过方法、工具和指标持续改进组织的价值交付能力。我们在前一小节中提到过，成功完成所有分配的工作需要小团队拥有多样化的技能。敏捷和精益方法都采用了将所有必要技能汇聚到小型自主管理团队的理念。

理想情况下，团队成员拥有多项技能，从而提供更多的灵活性和容错性。然而，除非这些团队也在持续学习，否则它们无法不断改进自己的工作方式。因此，必须为此提供时间和资源，且高层管理者需要将持续学习的理念融入组织文化中。

实施预生产测试

从根本上讲，CI/CD 是一个顺序的工作活动流，从创意到交付给客户。现代软件工程实践，如 CaC、IaC 和测试自动化，使得通过最少的人工干预（如果有的话）来简化这些活动变得切实可行。

结果是，通过将持续集成（CI）和持续交付（CD）实践直接应用于生产环境，可以加速软件交付周期。然而，通常最好是构建 CI/CD 自动化流程，但在发布之前实施一个预生产阶段。这种方法使得应用程序发布能够在类似生产的环境中进行监控，然后再允许产品发布给客户。原因在于，在预生产环境中发现配置问题要比让客户发现并回滚发布要好。

在这里，现代价值流管理（VSM）工具的数据捕获和分析能力使得在将应用程序发布到生产环境之前，能够在预生产环境中更轻松地分析和改进应用程序性能。

将 DevOps 工程与 DevOps 实践分开

DevOps 工程师负责帮助安装 CI/CD 和 DevOps 管道中的集成、自动化和编排能力。然而，在这些管道中，开发人员和运维人员的角色仍然存在。

现在，我们知道不能让各部门以孤立的方式运作。因此，我们需要 Dev 和 Ops 团队协作，打破那些会降低组织快速和频繁交付高质量产品能力的障碍，并尽量减少生产发布失败或不理想的风险。

在这种背景下，DevOps 工程有助于构建自动化管道能力。然而，作为一种实践的 DevOps 是将开发和运维功能结合起来，解决产品交付问题的战略，既包括每次产品发布之前，也包括发布之后。这两种能力都对加速和改进价值交付至关重要。

允许 DevOps 政策和流程的灵活性

大型企业通常有许多价值流，并且有多个具有独特价值主张的产品。因此，IT 必须提供灵活性，以应对客户需求，并确保与为每条产品线带来竞争优势的交付能力保持一致。此外，需求、实践和技术随着时间的推移而变化。今天有效的做法，明天可能不再适用。我们总是可以进行改进。

在上一章中，我们讨论了建立 COE（卓越中心）以制定围绕工具和实践的治理政策的重要性，监督组织 DevOps 实践的成熟度，并为新团队和现有的 DevOps 团队提供指导。掌握这些 DevOps 技能和能力的学习曲线相当陡峭，而 COE 可以减少组织过渡的影响。

然而，卓越中心（CoE）不能具有指令性。它们履行指导、辅导和服务型领导的角色。当标准实践在满足内部和外部客户需求时无法奏效时，它们可以帮助 DevOps 团队从情境分析中权衡替代方案。它们还在 CALMS 框架内运营，协助 DevOps 团队进行转型和持续改进工作。CoE 的角色不是实施一种命令和控制的监督机制，以免阻碍做出基于经验和信息的改进。CoE 的目的是提供领导力、指导和支持，但不是通过指令来实现。它们是服务型领导者。

现在，让我们继续讨论如何在提高交付速度的同时提升质量。

在提高速度的同时提升质量

在 DevOps 导向的敏捷实践者中，一个常用术语是加速。这个术语背后的意思是，精益流动的 DevOps 帮助我们加速软件价值的交付。但在这个表述中，价值这一术语与加速同样重要。没有质量改进的加速软件交付只意味着更快速、更高效地交付错误的产品。尽管如此，它依然是错误的产品——这意味着我们可能正朝着破产的方向加速。

这个概念适用于整个软件交付价值流。当我们决定加速流动而没有平衡地考虑提升交付质量时，就会为增加浪费和失败创造机会。

集成持续（CI）与自动化测试是提高软件质量的关键因素。但与之相关的模糊前端活动，如收集需求、编写相关的验收标准、定义测试以确认每个构建工作项的完整性或完成定义，也是同样重要的。如果我们开始时没有做好，结果就不可能正确。缺陷来自前端没有做对，这会扼杀任何可能拥有的交付速度。

从内部构建 DevOps 团队

我们已经注意到，DevOps 是一种技能，不可能一蹴而就。然而，雇佣专门的资源来创建一个独立的 DevOps 团队并不是最佳的前进方式。从零开始构建专门的 DevOps 团队只会在你的水平价值流中创建新的孤岛。

回顾我们在第十三章中讨论的横向价值流跨越垂直功能孤岛的实现问题，介绍 VSM-DevOps 实践领导者部分，在定义 DA FLEX 中的价值流一节中。参见图 13.3。更好的方法是围绕价值流开发团队。这包括你的 DevOps 工程师，以及现有的质量保证（QA）、运维和开发团队成员。这种方法将现有的人员和流程带入围绕价值组织的工作中。无需替换他们。相反，我们需要带领他们一起前进。

从那些喜欢成为创新者和早期采用者的人开始。帮助他们取得成功，并基于他们的成功建立企业级 DevOps 工具、政策和流程的核心基础。然后，利用这些团队的经验和成功，吸引早期大多数人，最终吸引滞后者。

这个过程不必花费太长时间。然而，拥有多个产品线和多个开发与运维团队的大型组织可能需要经历一个多年的过程。因此，实施这种规模的组织转型的三年时间表并不不切实际。

自动化数据库构建

说什么！？在构建 CI/CD 管道时，我们习惯于考虑自动化软件构建的执行、测试基础设施的搭建和配置，然后执行测试。然而，我们往往没有考虑到我们的应用数据库如何融入这些场景。

在持续集成（CI）中，我们从源代码仓库的特定分支拉取一批文件，然后允许配置脚本执行构建和集成测试过程。问题是，数据库代码（有状态的、顺序特定的、累加的数据库结构）不适合跨分支合并代码。理想情况下，数据库更改应该在处理前合并到批次中。此外，数据库更改必须按顺序处理，顺序非常重要。

在不同的开发环境中创建的数据快照会随着时间的推移而发生漂移，这使得同步每次构建的数据变得具有挑战性。因此，需要有人负责与应用自动化配置一起自动化数据库。

维护事件处理程序

无论我们投入多少时间和精力来构建自动化脚本，总会有一些问题不可避免地发生。我们进行敏捷回顾的目的是无责备地回顾发生的问题，并找出避免这些失败的方法。而当失败是不可完全避免时，我们需要确保改进并记录我们的恢复流程。

DevOps 团队需要保持严格的事件处理程序，记录如何处理配置、测试和部署失败。最好的地方是将这些信息放在运行手册文档中，文档可以保存在像 Git 或 GitHub 这样的源代码仓库中。

将安全与 DevOps 集成

将安全与 DevOps 集成是如此重要，以至于许多组织将其自动化软件交付管道称为 DevSecOps。不幸的是，安全往往成为 IT 组织内的另一个潜在孤岛。而且，正如运营团队一样，安全人员往往具有规避风险的倾向，因此可能被视为加速软件交付的瓶颈。

然而，更大的错误是忽视或绕过安全职能以避免延迟。在过去的一年里，当这本书正在撰写时，我们亲眼目睹了忽视安全所带来的负面后果。例如，Colonial Pipeline 公司遭遇勒索病毒攻击，导致美国东海岸 45%的石油供应中断，持续了近一周。另一个备受关注且可能造成灾难性后果的事件是黑客通过 SolarWinds 的一个软件更新附加的恶意软件。该恶意软件使得黑客能够在四个月内监控近 18,000 个 SolarWinds 客户的计算机网络，包括政府和私营部门的客户。

获得 DevOps 的知识

看起来很显然，在启动 DevOps 项目之前，拥有 DevOps 的知识是必需的。但不幸的是，理解 DevOps 的潜在好处要比理解在企业规模上实施 DevOps 所涉及的问题要容易得多。

这回到了我以前海军田径教练 Al Cantello 所说的关于我们渴望即时满足的那句话。现在，你应该完全理解，在支持数字化业务转型的过程中建立大规模 DevOps 的困难。但梦想一个更好的未来状态很容易，然而为了实现这些目标，做出努力则是另一回事。所以我们必须付出努力。

这些努力必须从组织的高层开始，因为只有他们有权力推动和资助企业级转型的工作。

在实施 DevOps 过程中感到疲惫

IT 行业不断发展。即使是 IT 专家也很难跟上变化，更不用说那些受其活动影响的组织其他利益相关者了。此外，DevOps 的复杂性使得在企业规模上实施它尤其令人沮丧。

看一个基于 DaaS 的 DevOps 平台解决方案，可能会认为我们可以几乎瞬间搭建一个新的 DevOps 平台。在一个有限的规模上，这确实是对的——只要你有经过培训的员工，可以立刻投入工作。

但在更大规模上，一系列问题会迅速浮现，包括预算、培训、辅导、教练、首选及新兴工具集成、支持遗留应用程序的独特配置、安全性、合规性、许可、长期可支持性与可持续性，以及价值流性能改进等。有时，可能会觉得组织前进了两步，却又因高管和其他利益相关者重新评估之前的决策而倒退了一两步。

这时，价值流管理就显得尤为重要。如果你没有一个游戏计划，根本无法执行。是的，即使是足球教练也会在中场时做出调整。但这些调整只是对原计划的微调，目标和任务保持不变。

DevOps 实施疲劳是执行支持对成功结果至关重要的另一个原因。组织的首席执行官和业务线高管必须在困难时期保持动力。来自预期 OKR 的明确和持续的沟通是他们推动实施的一种方式。其他时候，他们可能需要充当啦啦队员和教练。但是，无论如何，他们需要保持知情、参与和承诺。

在源代码控制中编码机密

Joel Kruger 在他的访谈中提到过这个话题。安全性必须是所有软件交付组织的关键关注点。例如，基于 DevOps 的软件交付系统使用 IaC 和 CaC 来自动化创建或更新指定环境和应用程序基础设施配置的执行。但是，当访问信息被硬编码到指令中时，这些配置可能会成为安全漏洞。正如 Joel 所指出的，"就像将你的姓名、地址和银行账户信息发布到网上。"

硬编码机密的另一个问题是，每个变化都需要构建一个新的独特配置文件。然而，开发人员可以使用参数化的、可重复使用的脚本与环境变量一起，以减少重复配置文件的维护，而不是维护多个执行相同功能的配置文件。

例如，开发人员可能会编写 Ansible 脚本来配置服务器，但随后需要处理 50 个独立实例，以应对独特但细微的变量。将其做成一个配置并参数化会更好，这样开发团队只需更改影响配置的参数即可。

参数化代码的概念适用于配置、人为输入、机器对机器的交互、Web 应用等各个方面。一切都需要模块化（开放式），包括 IP 地址、主机名、应用程序名称、资源配置（CPU 和内存）、默认配置文件、证书和令牌等。

注意

需要审计配置，例如在政府和高安全性应用程序中的需求，可能导致在源代码和工具脚本中硬编码参数和集成。然而，例如 AWS Secrets Manager 等工具可以让你参数化你的变量输入，但安全地管理它们，并仍然允许授权人员进行审计。

本节总结了我们关于定义合适 DevOps 平台策略的章节。下一章是本书的最后一章，在这一章中，我们将运用所学的 VSM 和 DevOps 方法与工具来帮助推动数字业务转型。但在继续之前，让我们总结一下你在这一章中学到的内容，并检查你对所学概念的理解。

总结

在这一章中，你有机会听取五位行业专家对潜在 DevOps 实施陷阱和各种 DevOps 平台实施策略的看法。这五位专家被选中，以提供尽可能广泛的实践经验。

接下来，你学习了实施 DevOps 平台的四种基本方法。这些方法包括构建定制的 DevOps 平台，购买基于云的DevOps 即服务（DaaS）解决方案，利用 VSM 工具集成和编排你的 DevOps 工具链，以及通过构建自助式 CaC，使用 Git 或其他 SCM 工具下载来构建软件工厂。

最后，你回顾了 18 种实施场景，这些场景可能会在你的 DevOps 平台实施程序中引发问题。当你阅读这些场景时，你被鼓励思考如何利用你对 VSM 和 DevOps 方法的了解，以及如何通过工具来克服这些问题。

有了这些信息，你现在准备好学习如何运用你所学的知识，使用 VSM 和 DevOps 方法与工具来实现业务的数字化转型，这也是本书最后一章的主题。

问题

1. Helen Beal 指导我们不要创建 DevOps 团队。她认为我们应该做什么？

2. Scott Ambler 建议我们不能仅限于 Dev 和 Ops 思维。PMI 的 DA 工具包中定义的企业级 DevOps 的六个关键方面是什么？

3. Pramod Malhotra 建议我们不应该考虑启动 DevOps 项目，除非我们具备什么？

4. Al Wagner 听到他客户们常常抱怨的一个问题。这个问题是什么？

5. Joel Kruger 将配置管理（CM）确定为保护组织 IT 资产的手段。虽然他指出配置管理并不是一个新概念，但在 CI/CD 和 DevOps 流水线的背景下，配置管理实践中相对较新的是什么？

6. 一个组织可能采取的四种基本 DevOps 实施方法是什么？

7. 当企业高层要求快速转型以实施 DevOps 时，通常最好的策略是什么？

8. Jez Humble 创建了 CALMS 框架，作为整合 DevOps 团队、其活动，并运用其系统、工具和工具链的概念模型。CALMS 这个首字母缩略词代表什么？

9. 本书建议最好从内部组建你的 DevOps 团队，以支持你组织的价值流。为什么这么说呢？

10. 谁最终负责解决 DevOps 实施疲劳的问题？

进一步阅读

MacCormack, Alan, Carliss Baldwin, 和 John Rusnak. 2012. 探索产品与组织架构之间的二元性：对“镜像”假设的测试. 《研究政策》 41 (8) (10 月): 1309–1324. doi:10.1016/j.respol.2012.04.011. dash.harvard.edu/bitstream/handle/1/34403525/maccormack%2Cbaldwin%2Crusnak_exploring-the-duality.pdf. 访问时间：2021 年 7 月 12 日。

第十六章：通过 VSM 和 DevOps 转型企业

在这最后一章，您将学习如何使用价值流管理（VSM）和 DevOps 工具以及相关实施倡议，将企业转变为在数字经济中竞争的可行实体。但是数字转型有两个部分。在第一部分中，我们需要转变我们的软件交付能力，以支持组织整体的业务转型。在第二部分中，我们利用转型后的软件交付能力来改进我们跨价值流构建和交付产品的方式。

换句话说，我们必须通过 DevOps 相关的 VSM 倡议连接所实现的软件交付改进，以支持更广泛的企业 VSM 倡议的需求。但这种连接并不是自动的。从系统思维的角度来看，单独改进软件开发能力，而不考虑业务价值交付需求的交叉点，是一种局部优化。组织能够从其 VSM 和 DevOps 工具投资中获得足够的投资回报的唯一途径是利用其增强的软件交付能力来改进其跨组织的价值交付能力。

在本章中，您将学习如何将 VSM 和 DevOps 工具投资与公司战略和投资组合进行对齐。我们将逐步解决这个问题。考虑到这一目标，本章涵盖的主题包括以下内容：

• 统一 VSM 倡议

• 使用 VSM 改进 DevOps

• 连接企业 VSM 倡议

• 使用 OKR 推动业务转型

• 将 VSM 倡议与战略和投资组合对齐

• 扩展 VSM 工具行业的愿景

请注意，最后一个主题将为 VSM 工具行业引入未来愿景。读取当前 VSM 工具供应商的文档和新闻稿可能会让人相信，他们的工具能够提供跨所有价值流的端到端可见性的即插即用解决方案。但今天实际情况并非如此。现代 VSM 工具提供支持软件交付管道的活动的端到端可见性。VSM 工具的愿景可以在长远内扩展，以整合所有组织的开发和运营价值流。我将此主题包含在内，呼吁 VSM 工具供应商将这一愿景变为现实。

让我们开始理解如何通过 VSM 将我们的企业转变为具有竞争力的数字企业。我们将从讨论统一 VSM 倡议的意义及其重要性开始。

统一 VSM 倡议

精益概念并不新鲜。例如，可以认为亨利·福特的 T 型生产线体现了现代精益实践中应用的几个概念。例如，福特在汽车装配线上创造了连续流和流水线作业，并安排零部件在装配之前到达。但是，正是丰田的创始人和未来的领导人，主要是这三位个人：

• 豊田佐吉 – 丰田公司创始人

  开发和实施了背后的概念自动化与人类触摸 – 作为实现源头质量的手段。

• 丰田喜一郎 – 佐吉豊田的儿子

  成立了丰田汽车公司，并开发了制造业的即时制（JIT）概念。

• 大野耐一 – 车间监督、工业工程师和丰田公司高管

  将丰田的 JIT 系统与自动刹车系统相结合，定义了看板系统，并建立了持续改进背后的原则。大野还被认为定义了丰田生产方式（TPS）中的许多元素，如拉动式生产系统、消除浪费、快速换模（SMED）、非增值工作、U 型工作单元和单件流。

最终被称为丰田方式的理念对全球制造业竞争产生了深远影响，因此被广泛研究和复制，作为在日益竞争激烈的全球市场中生存的手段。精益这个术语源于由麻省理工学院（MIT）的国际汽车项目（IMVP）在詹姆斯·P·沃马克指导下进行的研究。IMVP 的研究人员约翰·克拉夫奇克创造了精益生产这个术语，这是 VSM 的核心。除了这些先驱之外，还有许多从业者和专家进一步扩展了精益生产实践的应用。

关键是，了解精益的人们已经了解价值流映射和 VSM，并将其扩展到其他组织发展和运营价值流的更广泛背景中。此外，他们已经应用这些方法数十年！

发展不同的客户为中心的发展战略

然而，在软件开发和 VSM 中，精益实践作为主流软件开发概念相对较新。而其他领域和行业则专注于精益生产实践，以提高其客户为中心的价值交付能力，软件社区则专注于实施基于敏捷的策略。尽管精益和敏捷实践都专注于改善客户导向的价值交付和持续改进，但敏捷的早期倡导者致力于解决不同的问题集。

例如，丰田在大萧条和第二次世界大战后，面临资源有限且昂贵的岛屿国家环境，致力于提高质量和效率。丰田在全球市场上的竞争力来源于用更少的资源制造更高质量的产品，并同时确保只生产客户在需要时才会购买的产品。他们在这方面的卓越表现使得世界其他制造行业不得不作出相应反应，以确保生存。其他行业也迅速跟随精益趋势。

相比之下，敏捷方法起源于软件开发社区，其倡导者解决的是一组不同的问题。具体来说，传统的项目管理模式未能充分响应企业及其客户不断变化的需求和优先事项。因此，敏捷方法作为一套价值观和原则开始，旨在支持小型软件开发团队更加敏捷和适应变化。在这个过程中，敏捷逐渐发展为一种实施迭代和增量开发的实践，利用原型设计和经验主义，以便快速创建具有客户导向输入的可工作解决方案。

但现在，我们看到精益和敏捷背后的概念开始融合，通常表现为实施精益-敏捷实践。这个话题至关重要，因为精益-敏捷是 VSM 联盟在实现 VSM 工具作为提升基于 DevOps 的软件交付能力的手段时所依据的方法论。我们将在接下来的章节《使用 VSM 进行 DevOps 改进》中讨论这个问题。然而，在我们进入这一话题之前，先来回顾一下现代 VSM 工具行业在使用“VSM”一词时的含义。

将 VSM 定义为现代软件工具类别

在现代语境下使用时，VSM 是一种工具驱动的策略，旨在支持 VSM 实践，实现跨 CI/CD 和 DevOps 管道活动的精益改进。在互联网上进行简单搜索可能会让我们认为这就是 VSM 的唯一含义，因为有关 VSM 的最新信息主要来自 VSM 和 DevOps 工具行业。

例如，Forrester 在其《New Wave™》文章《价值流管理工具 Q3 2018》中，定义了 VSM 如下：

VSM 是一种新兴的工具类别，它将一个组织的业务与其软件交付能力连接起来。VSM 工具为多个角色——产品经理、开发人员、质量保证（QA）人员和发布经理——提供了规划、健康指标和分析视图，帮助他们更有效地协作，减少浪费，专注于为客户和企业创造价值的工作。

然而，请回想本书的第一部分，价值交付，和第二部分，VSM 方法论，介绍了 VSM 作为通用精益改进策略和方法论的原始概念。区分传统 VSM 和现代 VSM 概念至关重要，因为这两种 VSM 方法的融合是将我们组织资源对齐以在数字经济中竞争的最佳方式。牢记这一理解后，我们现在可以学习如何以及为什么必须融合传统和现代 VSM 概念。

使用 VSM 改进 DevOps

在第五章，通过 DevOps 管道推动商业价值，你学习了如何将通用的八步 VSM 方法应用于任何 VSM 改进计划。我们在第六章，启动 VSM 计划（VSM 步骤 1-3），到第十章，改进精益-敏捷价值交付周期（VSM 步骤 7 和 8）的 CI/CD 管道改进用例中使用了相同的八步方法。没有理由我们不能使用相同的八步方法来指导 DevOps 管道改进。

然而，VSM 联盟建议对与 DevOps 活动和工具链相关的 VSM 实施采取略有不同的路线图，如下图所示：

图 16.1 – VSM 联盟 – VSM 实施路线图

在 VSM 实施路线图中，你可以看到与精益和敏捷改进概念的相似之处。事实上，它是这两种实践的结合。

实施 VSM 路线图中的精益部分

VSM 联盟的 VSM 实施路线图首先通过识别价值流、定位并组织负责各个价值流活动的人员，绘制当前状态和理想未来状态，并将 DevOps 工具链与价值流中的活动连接起来。然后，根据所使用的价值流管理平台（VSMP），DevOps 工具链集成可以承担多个角色，包括集成、自动化和编排跨软件开发、安全和合规的价值流活动。

然而，较大的目标是使用 VSMP 及其与 DevOps 工具的集成，捕获跨已识别软件交付价值流的实时端到端数据。通过使用统一且标准化的数据模型，价值流经理、团队成员、组织高管以及其他相关人员能够实时查看软件生产流，进而观察并确定瓶颈和等待的原因。

因此，VSM 联盟的 VSM 实施路线图与通用的八步 VSM 方法论之间的主要区别在于，集成软件工具以捕捉价值流中的端到端数据，而无需人工干预或手动数据收集。另一个关键的区别在于使用分析工具，我们将在接下来的子章节中讨论这一点。

实施 VSM 路线图中的敏捷方面

VSM 联盟的 VSM 实施路线图中的接下来的两个步骤涉及检查（inspection）和适应（adaption）。Scrum 倡导者会立刻识别出这两个步骤，源自 Scrum 的三大经验性支柱：透明性（transparency）、检查（inspection）和适应（adaptation）。

在前面的子章节中，你已经了解了 VSMP 产品如何支持价值流活动的集成、自动化和协调。但这些工具也为我们提供了在 DevOps 管道中工作和信息流的可视性。因此，虽然这个术语没有明确提到，VSM 联盟并没有忽视 Scrum 的透明性（Transparency）支柱。VSM 工具行业的独特之处在于，它通过其平台和工具取代了手动收集和报告数据的方式，这在 VSMP-DevOps 工具链集成的连接（Connect）步骤中得以实现。

既然我们可以实时看到 DevOps 管道流的可视性，DevOps 团队可以检查（Inspect）管道，以便通过准确和当前的信息来指导他们的回顾会议。我们可以利用从检查和回顾中获得的见解，提出一个或多个潜在解决方案的假设，并进行实验，评估所识别的替代方案对我们目标的有效性。最后，我们可以根据我们的经验性发现来适应（Adapt）我们的 DevOps 系统。

因此，从启动（Start）到适应（Adapt）步骤，VSM 实施路线图将精益（Lean）和敏捷（Agile）的最佳实践结合成一个无缝的框架。这将我们带到最后一步——愿景（Vision）。事实证明，这是精益-敏捷实践中的一个关键步骤。

建立业务转型愿景

回想一下，敏捷是由软件工程师和顾问们发展而来的一套价值观和原则，目的是更快速地响应客户需求和优先事项的变化。但敏捷的演变主要是作为一种面向小团队的开发哲学，在每次开发迭代中评估增量变化——基于团队从上一轮 Sprint 中获得的经验。换句话说，基于敏捷的改进往往局限于非常短期的计划周期——一般在 1 到 4 周之间，并且仅限于开发团队所获得的预算和权限。

相较之下，精益改进通常会看到跨多个规划周期的变化，这些周期可能跨越多个财政年度，涉及需要高层支持和承诺授权的变更和预算。事实上，VSM 和 DevOps 工具的投资涉及组织投资、业务运营和文化变革，这些是小型软件开发团队无法授权的。因此，这种规模的投资必须支持业务战略，获得高层支持，并符合组织层次的投资和优先事项。

因此，作为 VSM 实施步骤的愿景变得至关重要，它有助于将 VSM 和 DevOps 实施目标与业务战略对齐，以获得高层支持并优先分配预算。而实现这一目标的唯一途径是高层看到软件交付的改进如何改善公司在所有组织价值流中的产品交付。

现在我们已经理解了精益和敏捷概念在作为工具和 DevOps 驱动的软件交付改进策略的VSM 实施路线图中的结合方式，让我们退一步，来看一下人员在这些工具的实施和使用中的重要性。

实施工具并不能替代人员

拥有实时数据访问权限来监控 DevOps 管道并不能取代高层管理人员和经理进行Gemba巡查的必要性，特别是在涉及多个团队的大型软件开发项目中。执行日常工作的人员对工作如何进行、为何如此以及哪些问题干扰他们的工作流程最为了解。在现代 VSM 工具的背景下，Gemba 巡查是探索性的活动，可以包括虚拟和面对面的数据收集与沟通活动。

类似于在第七章中的去现场看（Gemba）部分对 Gemba 的解释，VSM 成员、VSM 经理和高层可以与 DevOps 团队成员进行对话，提出以下问题：

• 让 DevOps 团队成员描述他们在当前软件开发工作中遇到的问题。

  • 注意，大多数人倾向于避免讨论困难的主题，或表达他们认为别人不想听的观点。

  • 经理需要深入挖掘，以超越表面显现的、容易看见的问题，找到影响团队表现和软件交付的真正问题。

• 接下来，询问团队成员他们认为问题的根本原因是什么，并提供证据来支持他们的推理（透明性）。

• 当根本原因被揭示出来后，接下来，询问 DevOps 团队成员应该采取什么措施来解决这些问题，以及原因是什么。

• 然后询问 DevOps 团队成员他们如何知道问题是否已经解决。

  • 什么证据可以清晰地表明问题已经解决？

  • 什么数据和指标可以作为成功结果和改进的指示器？

• 最后，通过实验和检查调查推荐的替代解决方案，并适应提供最大价值的方法。

你现在理解了管理者和高管们走出去看看实际情况的重要性，以及他们必须向 DevOps 团队成员提出的那些问题。但是，在许多情况下，问题可能需要专业技能和团队合作来解决。在这种情况下，组织应建立一个 VSM 团队来进行分析并管理 VSM 计划。

创建一个 DevOps 转型的 VSM 团队

创建一个 VSM 团队，就像我们为任何其他类型的 VSM 计划所做的那样，帮助引导 DevOps 导向的软件交付价值流改进投资和活动。此外，涉及多个开发和支持团队的大型软件产品，使得建立一个专门的 VSM 团队来指导整体计划变得至关重要。

也有可能，非 IT 的 VSM 团队——即指导组织的开发或运营价值流改进的团队——会识别出需要改进或调整软件开发交付能力，以支持其价值流的需求。在这种情况下，原始 VSM 团队可以指导其价值流的 DevOps 导向改进，但他们的团队也必须包括 DevOps 活动和工具方面的专家。

无论组织采取哪种方法，VSM 团队都负责引导软件交付能力的改进，以满足价值流的需求。当指定的 VSM 团队支持组织的一个开发和运营价值流作为其 VSM 计划时，这种对齐更容易实现。

相反，支持 DevOps 作为独立价值流的 VSM 团队必须认识到，他们最终必须将 DevOps 团队对准，以支持其他组织价值流中的高优先级改进。通过类比来说，如果你不知道自己要瞄准什么，那么很难命中目标。所以，面向 DevOps 的 VSM 团队可以承担这个责任，与组织的投资组合经理、产品负责人以及其他价值流经理合作，识别高优先级的软件开发需求。

本小节总结了我们关于使用 VSM 进行基于 DevOps 的软件交付能力改进的讨论。在下一节中，我们将探讨 DevOps VSM 计划如何支持组织的数字业务转型。

连接到企业 VSM 计划

在本节中，您将学习如何将传统 VSM 方法与现代 VSM 工具应用和 DevOps 结合起来，以支持数字化商业转型。您在本书中已学到，组织可以使用现代 VSM 工具来提升基于 DevOps 的软件价值交付能力。然而，组织也可以并且应该继续实施传统 VSM 计划，以识别所有其他组织价值流中的数字化改进机会。

让我们看一下图 16.2 – DevOps 管道为制造管道流程提供数字化改进，以展示这一策略是如何运作的。在这个场景中，传统的 VSM 计划已经在制造导向的管道中识别出了三种潜在的数字化改进（Kaizen Bursts）。对于这个例子而言，它们可能是什么并不重要，但它们可能包括以下任何类型的数字化改进：

• 改进制造管道活动中的产品订单和材料信息。

• 改进车间/制造过程信息的获取。

• 重新编程机器人和自动化制造系统，以提高性能或减少设定时间。

• 实施自动化质量检查系统。

• 在自动化喷漆过程中实施编程。

• 改进标签和运输指令与产品的一致性。

• 改进供应链管理系统，以支持准时交货（JIT）需求。

• 其他数字化增强。

VSM 团队与 DevOps 团队会面，解释他们的需求和优先级，并将这些信息纳入他们的产品待办事项列表。DevOps 管道在技术上可以处于任何成熟阶段。不管怎样，根据优先级，经过批准的数字化增强会通过管道进入生产，并且在制造产品线的生命周期中必须得到支持，并可能进行修改：

图 16.2 – DevOps 管道为制造管道流程提供数字化改进

在组织传统 VSM（价值流图）计划中，优先级的 Kaizen Burst（改进机会）跨越所有开发和运营价值流，提供了必要的信息，帮助理解数字化转型对企业运营产生最大正面影响的地方。在这个例子中，组织将 VSM 方法作为精益导向的改进技术，战略性地用于识别、评估和优先考虑通过数字化转型消除浪费、精简价值流活动的地方。

阅读完本书后，你应该完全意识到，战略性 VSM（价值流映射）举措识别了许多改善机会，用以消除浪费并简化价值流流程，其中一些可能并不需要基于软件的解决方案或增强功能。然而，软件及相关的计算和网络系统在我们的数字经济中，是大多数产品和价值流改进的核心。我们使用 VSM 工具来改善 DevOps 流水线，以支持在所有其他组织 VSM 举措中识别出的数字化改进需求。

我们可以将我们改进后的 DevOps 软件交付能力，应用于消除浪费并简化所有组织价值流的流程。然而，更常见的情况是，正是那些战略性 VSM 举措帮助组织识别战略性改进机会——无论是数字化的，还是其他形式的。这些建议最终需要执行层的支持，并考虑由精益投资组合管理功能对投资优先级的决策。

假设一个软件开发团队或价值流经理采取捷径，绕过组织的预算审批流程，在这种情况下，他们将无法获得成功所需的管理和财务支持。一个小型开发团队可能会找到为其 DevOps 实施提供独立资金的方式，但这不是一个可扩展的过程。而且他们可能无法提供足够的价值来证明其努力的意义或证明扩展其努力的合理性。

正如本章介绍中所讨论的，单独改善软件交付能力，而不考虑其他组织价值流需求，从系统思维的角度来看是一种局部优化。我们可能会花费大量的时间、精力和资金，却看不到合理的投资回报。

下面是一个说明为何会这样的问题的例子。一个完全集成、自动化并协调的 DevOps 流水线的测量周期时间可精确到微秒——这是你的连接 VSM 工具很快会指出的。大部分的整体交付时间延迟来自于与产品概念化、需求和设计相关的模糊前端活动。但一旦需求、验收标准和设计问题得到解决，且一个特性进入生产阶段，大多数周期时间事件可以在几分钟或更短的时间内测量出来。

因此，成熟的基于 DevOps 的软件开发流水线不会成为组织价值流中的瓶颈。当然，前提是 DevOps 流水线改进活动已经解决了工具的预算和审批问题，并为建立测试环境和执行 CI/CD 流水线活动创建了可重用的配置。

初始的 DevOps 管道改进活动没有任何快速或容易的步骤。组织的 IT 职能需要投入时间和资源。它们还需要获得高层支持和认可，以便在整个企业范围内扩展 DevOps 能力。

在以下列表中，展示了 DevOps 增强软件交付如何支持组织的商业目标的三种一般场景：

• 生产独立的软件产品——为外部客户提供

• 对物理产品的改进——例如现代汽车中的导航和控制系统

• 价值流改进——提升跨操作价值流的价值交付能力

上述列表的目标并不是将软件产品与价值流混为一谈。相反，目的是指出软件在所有类型的开发和操作价值流中的普遍存在。

我在本书中反复强调这一点，以使其明确：我认为组织必须始终进行两个平行的 VSM 努力：

• 改进软件交付能力的 VSM 举措

• 支持企业精益改进的 VSM 举措

企业资助的 VSM 举措贯穿所有开发和组织价值流，以支持持续的精益改进——其中一些/许多将需要数字化增强，以实现所需的增值变化。因此，虽然软件交付的 VSM 改进至关重要，但这些改进的真正价值来自于将软件交付与支持跨企业的数字化改进对齐。这些改进机会通过企业资助的 VSM 举措，在组织的价值流中被识别并优先排序。

此外，VSM 团队及其举措应重点识别 IT 可以改善产品价值、消除浪费和改进价值流流动的领域——分配的 DevOps 团队可以帮助进行这些评估。软件行业越来越意识到与产品团队和价值流对齐的重要性。例如，VSM 联盟的初步报告（预计于 2021 年 7 月发布）发现，近 40%（37.36%）的受访者报告称他们在一个产品、功能、组件或流对齐团队中工作：www.vsmconsortium.org/。

现在你已经知道如何将基于 DevOps 的 VSM（价值流管理）举措与组织的其他价值流对齐。在接下来的两个部分中，你将学习如何通过组织的战略目标与关键成果（OKRs）和投资组合管理，与这些其他价值流进行连接。我们将从 OKRs 的讨论开始。

使用 OKRs 推动业务转型

OKR 背后的概念由英特尔前首席执行官安迪·格罗夫（Andy Grove）创造，他将公司转变为世界上最大的半导体公司。OKR 的早期倡导者首先是在英特尔，随后是其他科技公司，包括谷歌。英特尔和谷歌使用 OKR 的过程被约翰·多尔（John Doerr）在《衡量重要事项》一书中记载（Doerr, 2017）。

约翰·多尔在离开英特尔成为 Kleiner Perkins 风险投资公司的合伙人之前，曾作为英特尔的员工了解并学习了 OKR 的使用。在 Kleiner Perkins 工作期间，他将 OKR 背后的原则教授给了他投资的公司，包括谷歌。

OKR 的概念相对简单。目标陈述了组织要实现的事项，而关键结果是我们设定并监控的成功结果的目标指标。OKR 不仅仅是一组目标和衡量标准，它们还是一种管理方法和框架，旨在集中公司的努力。

结果必须是可量化、可衡量且可验证的。换句话说，我们使用实际数字来阐述目标，而不是模糊的文字，无法衡量或证明。简而言之，通过明确的 OKR，组织内部对于是否达成目标没有任何疑问。

OKR 也有时间限制，通常是按季度设定目标，尽管一些组织可能会设置按月目标。也有可能设定长期目标，可能会跨越一年或更长时间。但关键结果通常是按季度进行监控和汇总的。

OKR 不是隐藏的，它们对所有员工和利益相关者都可见。如果人们不知道组织的目标是什么，他们怎么知道自己要去哪里，也不知道是否已经到达目标？OKR 指导每个人的努力方向。

OKR 的目标并不意味着容易达成。相反，它们应该是可以实现的，但也具有挑战性。正如前面所述，目标需要具体、明确、可量化且可见。理想的情况是设定具有挑战性的目标，通过激励组织中的每个人来实现伟大的成就。

到现在，你可能会想，为什么我们在一本关于应用 VSM 和 DevOps 方法与工具的书中讨论 OKR。答案是，OKR 有助于推动公司战略、投资组合优先级和投资决策，最终推动 VSM 指标的实现。

例如，一个公司目标可能是推出一个新的软件产品增强功能，以支持一个细分市场机会。我们的可衡量的关键结果（KRs）可能包括以下内容：

• KR #1：在下一个季度内开发三个必需的功能。

• KR #2：在相同时间内，进行一次有针对性的营销活动，将产品增强功能推广给 20,000 名合格潜在客户。

• KR #3：在发布后的第一个月内销售 100 个新软件许可证，并在第二季度末总共销售 400 个许可证。

你注意到只有KR #1与软件开发相关吗？另外两个涉及销售和市场支持，这是组织运营价值流的一部分。这种情况在任何战略 VSM 计划中都是典型的。

我们可能会包括其他关键成果来描述转售商或其他价值流改进目标和预期结果。通常，一个 OKR 会有 3 到 5 个关键成果。

组织使用的另一组重要指标是关键绩效指标（KPIs）。理解 KPI 和 OKR 之间的区别至关重要。例如，KPI 关注个人、团队或一组人在其目标上的表现衡量。因此，KPI 通常侧重于战术目标，而 OKR 则支持战略目标。

以之前的例子为例，我们战略性地推出了一款新产品变种，以开拓一个新的市场细分。关键成果帮助组织理解期望值。但它们也提供了哪些价值流受影响最大的一些线索。我们现在可以使用 VSM 计划来指导为实现目标所需的改进工作。

将 VSM 计划与战略和投资组合对齐

VSM 计划支持战略目标和任务。无论 VSM 团队是否在通过实施 DevOps 管道能力评估软件交付的改进，还是在进行其他组织价值流的改进，它们都是战略性的，因为许多识别出的改进机会将涉及超过小型价值流团队能够授权的投资和时间框架。

首席执行官不会支持与公司使命、愿景和战略不一致的大额投资。较大的企业（或应该）会比小型实体拥有更正式的预算程序。但无论大小，首席执行官都必须拥有评估和优先排序投资的机制。从这个角度看，VSM 和 DevOps 工具的投资与组织内其他潜在投资进行竞争应该是显而易见的。

由于这是一本关于 VSM 而非投资组合管理的书籍，我们将简要触及这一话题。然而，投资组合管理的主要目的是集中和控制预算及投资流程，以便组织能够在公司战略背景下评估所有改进机会及其优先级。

改进机会本质上倾向于以项目为导向。换句话说，它们的特点是具有相对较短的持续时间，并且有明确的开始和结束日期。工作通常是相对独特且独立的，作为一次性变革的努力。高层管理者根据投资回报标准做出预算和优先级决策，因此改进项目具有明确的时间表、资源和预算限制。

结果，组合管理实践通常会衍生出传统的项目和计划来管理已批准的工作。然而，随着精益-敏捷实践的推进，组织开始实施精益组合管理概念，例如由 Scaled Agile Framework®（SAFe®）实施的概念。具体来说，SAFe 的精益组合管理过程将精益和系统思维方法应用于战略和投资资金、敏捷组合操作和治理。

现在，你对如何通过组合管理方法来评估、优先排序和批准预算，以支持组织在 VSM 项目中识别的改进机会有了一个基本的理解。你也知道如何应用 VSM 方法和工具来改善整个组织的价值交付。现在，让我们继续了解无论我们 VSM 项目多么成功，如果没有持续的高层支持、培训以及精益导向的改进，如何随着时间的推移而失败。

了解 VSM 项目如何随着时间的推移而失败

在为这本书进行研究时，我与LeanFITT™的创始人之一 Todd Sperl 进行了对话，这次对话既有趣又令人不安。他指出了几个例子，其中一个组织对价值流图（VSM）项目进行了投资，并且取得了很大的、有时甚至是非常出色的成果，然而几年后，整个项目却分崩离析。此外，他还提到，当组织开始失败时，通常失败的速度和程度会比它们成为高效企业时的转型速度更快、更严重。事实上，它们往往最终表现得比刚开始实施精益之前还要差。这是怎么发生的呢？

我与 Todd 和后来与 PMI FLEX 开发者 Al Shalloway 讨论了这个话题。这是一个有趣的现象，可能需要专门的研究才能完全理解。但一个共同的因素似乎是新管理层进入后没有理解组织如何改变其实践、行为和文化，以支持更好的水平流动和价值交付。

有时，新管理层是通过收购进入的。换句话说，精益公司取得的成功使其成为收购目标。然而，新高管们未能意识到精益导向的操作和结构对其成功的贡献。

相反，新的高管往往更熟悉并且更愿意管理围绕传统业务职能和领域（如市场营销、销售、制造、人力资源、法律、会计、运输和仓储）形成的垂直孤岛。而且，跨领域的价值水平流动很难被看到；看起来也比管理与业务领域和职能对齐的资源更难管理。

图 16.3 将价值流图的水平流动与传统的垂直组织结构图叠加。再一次，很容易看到，这两种管理组织的方式并没有直接的关联：

图 16.3 – 垂直组织结构与水平工作流对比

结果，回归管理垂直孤岛而不是管理产品流动，对于组织的表现是一个立即致命的打击。首先，不同小组之间的壁垒迅速建立，这些小组必须协同工作，以维持水平价值交付流动。然后，支持水平活动流动的流程迅速瓦解并失败。此时，组织在隐喻上会发现自己回到不断扑灭无法熄灭的火源的状态。到那时，事情已经如此严重，以至于组织开始大规模地失败。

我们永远无法在垂直孤岛中解决价值交付问题。相反，我们必须建立水平协作并改善工作和信息流动，而这一过程需要时间和努力才能完成。但如果适当执行，除了继续沿着管理以产品为导向的水平流动的路径前进之外，没有合理的理由回到管理垂直领域。

通过类比，尽管建造一座建筑可能需要数月甚至数年的时间，但我们可以通过爆破和重型设备在几个小时内将其摧毁。那些回溯实施传统管理实践和垂直职能孤岛的管理者，带来了爆破和重型设备，迅速摧毁了我们的精益生产流程。

对新高管、股东和董事会成员来说，最重要的学习点是：在收购已经运作良好的精益导向公司时，要小心。他们必须花时间理解它为何以及如何运作，然后再强加新的管理结构。

本节完成了我们关于融合传统和现代 VSM 计划以支持业务转型的讨论。然而，在结束本书之前，让我们探讨一下 VSM 工具行业的潜在未来状态，以及所有组织从这种新的、扩展的视野中应用 VSM 工具所能获得的好处。

扩展 VSM 工具行业的视野

我对 VSM 的最终愿景是，传统的 VSM 方法和现代的基于 VSM 工具的概念能够结合起来。事实上，我认为这对 VSM 工具行业来说可能是一个巨大的推动力。我们可以不再将它们的使用局限于改善基于 DevOps 的软件交付价值流，而是利用相同的集成、自动化和协调能力，跨所有组织的价值流进行应用。

例如，将当前支持数据捕获和规范化软件交付流水线活动的数据的 VSM 工具视角，扩展到也能够提供跨所有价值流的端到端可视化和分析，这将有多难？这种策略意味着 VSM 工具供应商需要创建扩展功能，帮助他们的客户开发应用程序和集成，监控和捕获跨其他类型开发和运营价值流及其活动的数据。

大多数制造公司已经使用商业和定制软件应用程序来控制生产流程。过程控制系统在高度集成、自动化和大批量生产环境中尤为重要。

在第二部分，VSM 方法论中，我质疑是否需要为 IT 制定单独的 VSM 方法，并且这种方法与支持其他开发和运营价值流的 VSM 方法有所不同。我同样质疑是否需要一套不同的工具来捕获数据、进行规范化和分析跨不同价值流的数据。在我们的数字经济中，我们需要将 VSM 概念和工具能力应用于所有组织的价值流。工具的聚合将使得实时访问数据成为可能，并提供从概念到价值交付/现金的端到端可视化和分析。

摘要

在本章的最后，你已经学习了如何将传统的价值流图（VSM）方法与通过基于 DevOps 的 VSM 方法和工具所做的改进结合起来，以提高组织在现代数字世界中的竞争力。虽然许多 VSM 工具供应商让人觉得他们的 VSM 工具能够提供跨所有价值流的端到端可视化，但实际上它们主要关注 IT 导向的价值流。这并不是坏事，因为 DevOps 流水线复杂且昂贵，且在企业规模上构建需要耗费大量时间。

但你也已经了解到，在没有理解它们对整个系统的影响的情况下，单独对任何价值流进行改进实际上是一种局部优化。这意味着，我们可能会在提升基于 DevOps 的软件交付能力上花费大量时间和金钱，但却没有推动组织提升整体的价值交付能力和盈利能力。

我们必须调整我们改进的软件交付能力，以支持组织价值流的需求。这正是更大的投资回报所在。事实上，如果这种对齐不发生，IT 组织将难以获得执行层面的支持，无法在企业范围内大规模维持这一倡议。因此，在本章中，您学到了必须通过组合管理过程将 VSM 和 DevOps 工具投资与公司战略对齐。您还必须调整您改进的 DevOps 流水线，以支持组织其他价值流及其 VSM 倡议中确定的数字改进机会。

问题

1. VSM 和 DevOps 工具及其相关实施倡议的常见用途是什么？

2. 是或否：精益和 VSM 是新概念。

3. 丰田领导人在演变今天我们称之为精益生产的概念时，面临了什么问题？

4. 软件社区通过敏捷软件开发宣言背后的价值观和原则旨在解决的问题集是什么？

5. VSM 实施路线图的哪三个步骤与本书介绍的通用八步 VSM 方法最为密切相关？

6. VSM 实施路线图中的哪一步骤有助于在 DevOps 流水线中提供可见性？

7. 敏捷和精益的常见改进视野和管理层级是什么？

8. 将 VSM 或 DevOps 工具链的实施与评估其他价值流的改进隔离开来，这是什么的例子，我们为什么关心？

9. 为什么我们关心组合管理的目的是什么？

10. 为什么一些先前非常成功的精益导向组织随着时间的推移会失败？

进一步阅读

• Doerr, John (2017), 衡量重要的事情。OKRs – 推动 10 倍增长的简单理念，The Bennet Group, LLC，由 Portfolio Penguin, Random House LLC，伦敦，英国出版。

附录 A – VSM 宪章

附录 A

附录 B – VSM 故事板

附录 B

第十七章：评估

你可以在这里找到所有章节末尾问题的答案：

提供以客户为中心的价值

1. 数字增强技术现在使得组织能够通过互联网和移动技术进行商业活动，同时提供近乎实时的全球信息和基于知识的服务访问。此外，产品还通过物联网（IoT）进行通信并获取更新。

2. 问题在于人类有一个恼人的习惯，那就是在彼此之间使用相同的术语，但却对这些词的含义有着截然不同的理解。术语的不同语义使得人与人之间以及人与计算机之间的沟通变得非常具有挑战性。

3. 组织在给定时间范围内向一组预定客户交付的所有经验（包括价格）的组合，以换取客户购买/使用或以其他方式做出组织期望的行为，而不是选择某个竞争替代品。

4. 每个人。

5. 因为在竞争激烈的市场中，你会被那些关注市场并提供更具客户价值的竞争对手迅速超越。

6. 价值流是从头到尾的一系列活动，这些活动为客户创造结果。

7. 特性和功能是功能性和非功能性需求的实现，而价值流是促成这些交付的活动。

8. VSM 实施的方法和工具帮助组织通过优化其 IT 价值流中的工作流程，增加他们向客户交付的价值。

9. a. 战略到投资组合——推动 IT 投资组合实现业务创新。

   b. 部署要求——在业务需要时构建所需的内容。

   c. 请求到完成——目录、完成并管理服务使用。

   d. 发现并纠正——预测并解决生产问题。

10. a. 在数字经济中竞争的基本要求

    b. 加速 IT 价值交付

在精益敏捷基础上构建

1. Scrum

2. 扩展敏捷框架

3. 将企业战略与投资组合、产品和架构维护需求相结合，并确定在多个规划周期中的资金优先级。

4. 这四项中的任何两项：产品待办事项、逃逸缺陷、部署失败、发布净推荐值（NPS）

5. a. 可视化工作流

   b. 限制在制工作（WIP）

   c. 管理流程

   d. 明确政策

   e. 征求反馈

   f. 为持续改进生成创意

6. 理想的精益生产目标是将每项活动和整体生产速率与接收的客户订单或需求速率匹配。

   我们可以将其计算为生产工作项所花费的时间除以在该时间间隔内请求的项数，也就是 Takt 时间。

7. 一个线性顺序过程，没有反馈回路。

8. 我们可以通过实施精简、集成和自动化策略来加速价值交付。

9. a. 等待 – 处理过程中的延迟，包括产品在等待或排队时所花费的时间

   b. 过度生产 – 生产超出需求的数量，或生产客户当前不需要的产品

   c. 过度加工 – 过度处理或进行任何非增值活动

   d. 运输 – 将产品和材料从一个地点移动到另一个地点所浪费的时间、资源和成本

   e. 运动 – 不必要的移动，或者人的活动

   f. 库存 – 存储和携带任何未进行增值活动的材料和产品

   g. 缺陷 – 产品或服务中存在的故障

10. 敏捷方法论通常采用迭代和增量开发（IID）哲学。尽管最小化，但 IID 方法仍然是一种批量处理形式。相比之下，精益追求实现持续流动，理想情况下是单件流。

第三章: 分析复杂系统交互

1. 系统思维是一种评估大型系统复杂性的方法，不是将其视为独立部分的集合，而是通过评估参与系统的元素之间的相互作用来进行分析。

2. 故意和无意的。

3. 用于确定系统交互的因果关系及其影响。

4. 一种评估系统中元素之间复杂相互关系和交互的建模技术，以实现强化或平衡行为。

5. 一个线性顺序的过程，没有反馈回路。

6. 

第四章: 定义价值流管理

1. 价值流管理（VSM）本质上是将精益概念在组织内实施，并使精益开发和交付过程成为一种生活方式。

2. 材料和信息流映射。其意义在于，信息流的识别和管理与材料流同样重要，尤其在精益价值流中。

3. 精益价值始终流向下游客户，任何前置活动都属于上游。

4. 同样的概念适用于每个价值流。离客户最远的活动总是被视为上游活动，而那些离客户最近的活动则被视为下游活动。

5. 真实的。价值流包括组织在将产品从概念到推出过程中所涉及的所有创造价值和非创造价值的活动。

6. “一个端到端的活动集合，为‘客户’创造结果，客户可以是最终客户或价值流的内部‘终端用户’。”

7. 开发价值流 – 从概念到推出所需的所有行动，包括创造价值和非创造价值的活动

8. 运营价值流 – 从订单到交付的所有活动。

9. 价值流包括处理客户信息所需的活动，以及在产品到达客户的过程中转化产品的行动。

10. 它们是：

    i. 承诺精益

    ii. 选择价值流

    iii. 学习精益

    iv. 绘制当前状态

    v. 确定精益指标

    vi. 绘制未来状态

    vii. 绘制未来状态 – 客户需求

    viii. 绘制未来状态 – 持续流动

    ix. 绘制未来状态 – 平衡

    x. 制定 Kaizen（持续改进）计划

    xi. 实施 Kaizen 计划。

11. 沟通、管理、设定适当的起始条件、维持和工具。

12. 帕累托原则（也称为 80/20 法则和帕累托法则）是一种自然现象，指出在任何系统中，大约 20%的元素会产生 80%的影响。在 VSM 计划的背景下，一些价值流的改进对组织的即时成功比其他改进更为关键。为了做出这种评估，VSM 团队需要收集关键的精益指标，涵盖所有价值流活动中的生产率和浪费。

13. 确定并命名价值流的首尾活动。例如，常见的面向开发的价值流包括从概念到发布、从原材料到成品、从订单到现金。

通过 DevOps 管道推动商业价值

1. DevOps 起初是敏捷系统管理中的一种协作策略。最初的目标是改善开发和运营团队之间的沟通与协作，特别是在 IT 组织内部。最终，CI/CD 管道解决了开发和运营团队之间速度不匹配的问题。

2. 配置管理、任务管理/自动化、容器化

3. CI 强制执行将所有开发人员的工作副本几次合并到共享代码库中的纪律。

   其目的是通过软件构建和测试过程，验证每次增量代码集成的功能，当代码被开发时进行验证。

   目标是确保主软件代码始终有效，并处于潜在可部署状态。

4. 软件开发人员在变化的世界中茁壮成长，持续交付新功能和新能力。这是件好事，因为客户和用户希望获得能够带来价值的新功能。而系统管理员并不特别喜欢变化，因为他们的责任是确保所有的网络、系统和应用程序都能正常运行、保持稳定并且安全。这也是件好事，因为我们需要我们的网络和软件正常运作并保持安全。

5. 持续交付能力使得产品团队能够快速适应新环境并快速测试新的代码更新，最小化，甚至无需人工干预。

6. CD 的主要目标是将新更新转变为常规和高效的任务，开发团队可以按需执行。

7. IaC 允许开发人员使用编程或脚本语言生成可重复的代码或脚本指令来提供 IT 基础设施。安装在共享存储库中，IaC 允许开发人员通过自服务模型按需启动新服务器。

8. CaC 的目的是促进应用配置在不同环境之间的版本化迁移。

9. “工具链”一词指代支持 IT 价值流活动的一系列工具。但“工具链”一词本身并不一定意味着集成或自动化策略。

10. “管道”一词意味着流动。在精益导向的生产哲学中，我们希望工作和信息在 IT 价值流中的流动是精简且高效的。

11. SDLC 和 ITSM 价值流，或者 CI/CD 和 ITSM 价值流。

12. ITSM 关注的是 IT 团队如何提供服务。与此相反，ITOM 关注事件管理、性能监控以及 DevOps 管道中的操作部分所描绘的运营流程所使用的活动和工具（图 5.7）。

13. 基于项目的资金分配建立在对未来投资回报的预测之上。

14. 基于产品的资金模型评估当前的成本和收入，以评估应该在开发和运营支持中投资多少钱。

启动 VSM 倡议（VSM 步骤 1-3）

1. 在组织内部实施精益概念，并使精益开发和交付过程成为一种生活方式。

2. 精益公司比其他公司更具竞争力，因为它们不断改善业务运营。精益企业对员工更友好，因为它们尊重员工的工作，并将责任委派给实际从事工作的人员。它们还帮助最小化官僚主义和层级化的组织结构，这些结构会妨碍生产力，最终导致员工压力和倦怠。

3. 提出问题，以确定流动状态、订单处理、浪费大小、客户需求、清洁和整洁状态、库存管理、设备设置以及产品更换等情况。

4. 需求、流动和平衡

5. 当你刚开始你的 VSM 倡议时，可能还不知道精益表现和浪费指标的优秀标准是什么。

6. Heijunka 是一种负荷平衡工具，提供了一种更好、更稳健的方法来平衡生产计划，以应对生产过程中周期时间和批量大小的变动。

7. Heijunka 使用基于 Pitch 的生产平衡节拍法进行平衡。然而，它会根据生产产品的数量和种类，将其拆分成 Kanban 单元。

8. VSM 改善了我们组织中价值的流动。

9. 启动价值流的概念

10. 从原材料到成品的价值流

11. 从订单到现金的价值流

12. 成本减少原则

    精益的七种浪费

    精益的两大支柱——JIT 和 Jidoka

    5S 系统

    可视化工作场所

    精益应用的三个阶段：需求、流动和水平化

13. 过度生产

    等待（Q 时间）

    运输

    过度加工

    库存

    动作

    缺陷

映射当前状态（VSM 第 4 步）

1. 如果没有当前状态的价值流图，你可能不会意识到当前价值流活动对系统整体的影响。

2. 我们需要记录现有的活动流程、订单输入系统、生产控制系统、周期时间、设备设置和产品更换时间，以及我们的批次和批量大小、质量水平、缺陷以及不同步的物料和信息流。

3. 价值流映射有助于识别并消除阻碍生产力的浪费。

   商业流程模型通常用于支持业务流程重组和改进活动。它们还用于创建能够自动化这些改进的商业系统。

4. 我们需要知道业务流程是高效且增值的，因为自动化一个有缺陷的流程只会通过快速积累非增值成本来加剧其低效。

5. 不，不是时候停下来。开始工作吧！只管做！

6. 如果没有标准，VSM 团队成员和其他审阅地图的利益相关者之间的沟通和理解很快就会恶化。

7. 现场和当前状态映射活动提供了对阻碍物料和信息流动的浪费区域的洞察。

8. 去看看——亲自了解发生了什么。

   询问为什么——多次提问，找出问题的根本原因（使用 5 个 W 或 5 个为什么）

   尊重他人——你的工作是帮助解决问题，而不是找出过错。

9. 从最终客户交付开始，向上游（向后）推进，通过各个流程进行当前状态映射。

10. 它始终关注客户的需求。它引导我们的思维朝着基于拉动的流动方式转变。此外，通过设立多个组装分支，我们可以更好地在生产环境中处理复杂的流程。

11. VSM 团队必须根据最高价值影响来优先改进。

12. 它们是：

    绘制客户和供应商。

    绘制进入和退出活动。

    绘制进入和退出过程之间的所有活动。

    列出所有活动属性。

    绘制活动之间的排队和等待时间。

    绘制所有在价值流中发生的通信。

    绘制推式或拉式图标以识别工作流程类型。

    记录所有其他收集的数据。

识别精益指标（VSM 第 5 步）

1. 没有当前状态和期望未来状态的衡量标准，很难改进事物。

2. CT 是开始和结束一个价值流活动之间的时间跨度。CT 在这个衡量标准中不包括在制品（WIP）在价值流活动之间的等待时间。

3. 不一定。任何活动中都可能包含非增值工作的元素，表现为浪费。（例如，缺陷、库存、运动、过度处理、过度生产、运输和等待。）

4. 精益生产中的六西格玛提供了期望质量目标的衡量标准。六西格玛质量目标是每百万机会中有 3.4 个缺陷。

5. 交付领先时间、部署频率、恢复平均时间（MTTR）、变更失败百分比。

6. 它们如下：

   • 等待所花费的时间。

   • 步行所花费的时间。

   • 输入数据所花费的时间。

   • 检索文件所花费的时间。

   • 发送和审查电子邮件或其他消息所花费的时间。

   • 增值工作（处理时间）。

7. 变更失败率指定了代码更改导致失败的时间百分比，通常以缺陷或故障的形式被检测到。

8. 精益评估雷达图

9. 它们是：

   • 持续流动

   • 精益的五个 S

   • 订单平衡

   • 质量

   • 培训

   • 团队成员参与

   • 可视化控制

   • 工作单元移动

10. 管道流的集成、自动化和编排。

映射未来状态（VSM 步骤 6）

1. 阶段如下：

   第一阶段 – 客户需求

   第二阶段 – 持续流动

   第三阶段 – 平衡

2. 分析客户对贵组织产品或服务的需求，包括质量目标和交付时间。

3. 改善流动，使我们的客户能够在正确的时间、正确的数量下，获得正确的产品或服务，并且具备正确的特性。

4. 在产品线之间均匀分配工作，减少等待时间，消除批量处理（也称为朝着实现单件流的目标努力）。

5. 通过将净可用操作时间除以所需的产品数量来计算 Takt 时间。Takt 时间是衡量价值流需要多频繁地交付其产品或服务，以满足客户需求的指标。例如，Takt 时间为 0.5 分钟意味着价值流每 30 秒必须生产一个新项目，以跟上客户需求。

6. Pitch 等于 Takt 时间乘以打包数量。Pitch 是价值流制作一个产品容器所需的时间。

7. 消除在制品（WIP）会导致排队和等待的浪费。

8. 通过尽可能连续的方式，将一个工作项或至少最小的实际数量的工作项通过一系列价值流活动，进行生产和移动。

9. 生产平衡的目标是始终如一地在准确的 Takt 时间内生产相同数量的项目。

10. 敏捷开发团队从产品待办事项中汇总选定的工作项到冲刺待办事项中，然后以一个整体的方式在一个迭代冲刺周期内（通常为 1 到 4 周）处理这些工作项，从开始到结束。

    使用传统敏捷或 Scrum 基于 Sprint 的看板板帮助开发团队可视化和管理 WIP。看板实施了一个从 Sprint 积压和跨每个 Sprint 的拉动式生产控制策略。

    CI/CD 和 DevOps 管道能力允许敏捷团队直接从产品积压中拉取工作项，并在 IT 价值流中作为单一件流程处理。

改进 Lean-Agile 价值交付周期（VSM 步骤 7 和 8）

1. 当翻译成英语时，Kaizen是两个词的结合 – kai（打破）和 zen（改善）。换句话说，有时我们需要先打破复杂的事物，然后才能想出如何将它们作为更好的操作系统重新组合。

2. DevOps 是一项业务转型活动，需要对组织的业务流程进行重大变革，以及投资于新的工具和技术。

3. 为了在未来状态改进的三个阶段中每个 Kaizen 突发事件中可视化显示计划的改进倡议。

4. 该图表的目的是为 VSM 倡议的改进目标、目标和指标提供高度可见的展示。它还识别了与每个推荐改进目标相关的风险和问题。

5. 该计划的目的是审查所提出的 VSM 改进活动的详细信息。具体来说，该计划提供了空间，以识别所有改进倡议直至任务级别。

6. 应对客户需求。

   改善流程流动。

   工作平衡。

7. 利用这些初步的精益转型完成，并安装在基于敏捷的框架上，IT 导向的价值流改革为精益敏捷实践。

8. 技术和产品采用生命周期模型。

9. VSM 倡议涉及大规模的业务转型，可能需要几个月甚至几年的时间来完成。

   VSM 团队提出的改变可能需要重组组织和重大的财务投资。

   简言之，VSM 倡议具有战略影响，而基于敏捷的回顾往往在战术层面运作。

10. 产品积压和 Kaizen 板。

识别 VSM 工具类型和能力

1. 问题在于，除非我们首先了解 Lean 价值流改进背后的目标、指标和活动，否则 VSM 工具的数据和指标几乎没有实际用途。

2. DevOps 价值流管理平台（VSMPs）或更简单地说是价值流管理（VSM）工具

   价值流交付平台（VSDPs）或更简单地说是 DevOps 工具链和管道

   持续合规自动化（CCA）工具，也称为治理、风险和合规性（GRC）工具和平台

3. 提供开箱即用的连接器，集成不同的 DevOps 工具链，从而促进 IT 活动在计划、发布、构建和监控活动中的编排。

4. VSMPs 通过提供 IT 价值流的可见性和分析，帮助提高速度、质量和客户价值。

   他们提供数据和工具来监控和评估战略指标，如发布速度和 DevOps 操作效率。

5. 将信息技术与组织的业务目标对齐，同时管理风险并满足合规性要求。

6. VSDPs 提供集成的工具链，作为开箱即用的解决方案，通常以云基础的 CI/CD 或 DevOps 平台的形式提供。

   VSDPs 还包括支持可见性、可追溯性、可审计性和可观察性的工具，覆盖软件交付价值流中的活动，超越传统平台的能力。

7. VSDPs 将 DevOps 平台的能力与 VSM 工具的能力相结合。你会发现 DevOps 平台供应商和 VSM 工具供应商在这个共享领域融合在一起。

8. 测量价值交付率，包括部署频率、变更提前期、平均修复时间和变更失败率这四个关键的 DevOps 指标。

9. 通过协调和同步 DevOps 工具链中的数据流，消除 DevOps 价值流中的浪费。

10. 它们帮助 DevOps 或 VSM 团队评估在不影响实际系统或数据的情况下，进行变更对 DevOps 价值流的影响。

介绍领先的 VSM 工具供应商

1. 错误。作为一项学科，VSM 已经存在数十年，并被用来改善所有组织价值流的流程。

2. 正确。VSM 应用精益生产的原则，旨在对所有组织的价值流进行持续改进。

3. 缺陷、库存、运动、过度处理、过度生产、运输和等待。

4. 托马斯·达文波特（《流程创新：通过信息技术重新设计工作》）和詹姆斯·马丁（《伟大的转型》）。

5. 马丁和达文波特从价值导向或价值交付改进的角度，以及信息技术作为实施业务流程创新的关键推动力，评估了流程再造和流程改进计划。

6. 人工智能（AI）和机器学习（ML）帮助团队突破组织孤岛，聚合数据，形成信息的整体视图，进行分析并获得跨销售、市场营销、财务、开发、运营和技术团队的洞察。

7. 集成、自动化和编排。

8. VSM 是一种经过验证、有效且有纪律的逐步方法论，用于理解和应用精益思维的原则和实践。

9. VSM 的根源来自于丰田生产系统（TPS）中应用的精益生产理念。

10. 不，DORA 四个指标突出了 DevOps 团队中的最佳表现者。然而，VSM 是一种精益改进策略，它涉及更多的指标，以确定如何提升组织在所有价值流中的价值交付能力。

介绍 VSM-DevOps 实践领导者

1. 其目的是帮助全球组织通过采用和推动价值流管理工具和实践来交付客户价值。VSMC 的目标是通过领导力和社区连接推动价值流管理标准和创新，从而服务整个 VSM 社区。

2. 从结构上看，VSMC 实施精益实践和价值流作为其运营模型。此外，其资金支持 VSMC 研究、学习和外展价值流。

3. 联盟的初步研究成果将是价值流管理现状报告，该报告将衡量团队如何应用价值流管理原则、实践和指标，进而影响他们的价值流管理结果。

4. PMI 收购了Disciplined Agile，该方法专注于在软件开发中实施精益和敏捷实践。

   PMI 还收购了 NetObjects，这家公司开发了FLEX（企业转型流），一个基于系统思维的框架，提供了一套全面的投资组合、敏捷产品管理、执行/管理、项目和团队成功模式，基于精益敏捷原则和实践。

5. DA 提供了一个过程决策工具包，帮助个人、团队和企业在特定背景下优化他们的工作方式 (WoW)。

6. 过程刀片帮助团队和组织根据他们独特的软件开发需求，指导他们选择替代技术。反过来，过程刀片指导用户如何应用选定的技术，以增强关键的组织能力。

   每个过程刀片提供有关其哲学基础（或心态）的信息，这些心态包括应用这些技术的人员角色和职责，或简化业务流程作为流动，以提高业务敏捷性并提供应对情境需求的就业选项。综合来看，心态、人员、流动和选项代表了 DA 工具包的四个视角。

7. DA 工具包提供了四个级别的过程刀片，涵盖基础、纪律化 DevOps、价值流和 DA 企业。

8. FLEX 是 PMI 实施价值流流动的方法，旨在利用 VSM 技术提高价值交付。

9. 价值流是理解、组织和交付价值的主要构架。SAFe 引入了操作和开发价值流，并通过价值流映射将其带入了企业用户社区。理解并不断优化价值流是有效实践 SAFe 的关键。

10. 触发器、步骤、价值、人员与系统，以及交付时间。

11. 价值流管理（VSM）是一种领导力和技术学科，旨在通过端到端的解决方案交付生命周期最大化业务价值流动。VSM 在持续运营、衡量和优化价值流过程中，跨功能实施精益、敏捷和 DevOps 的价值观、原则和实践，从客户请求到解决方案交付。

12. 持续探索 (CE)、持续集成 (CI)、持续部署 (CD)、和 按需发布 (RoD)。

13. DevOps 支持持续交付流水线。

14. CALMR 首字母缩写代表 文化、自动化、精益流动、衡量 和 恢复。

    CALMR 是 SAFe DevOps 的核心思想，指导 ARTs 通过管理交付中的同步进展来实现持续的价值交付。

15. VSM 是一种用于在价值流中进行精益导向改进的方法。在 SAFe DevOps 中，目标是提高从客户请求到客户交付的业务价值流动。

第十四章: 引介企业精益-VSM 实践领导者

1. James P. Womack 博士，James Womack 及其同事 Daniel T. Jones 在《哈佛商业评论》杂志中发表的文章《从精益生产到精益企业》中创造了“价值流”一词（1994 年 3-4 月期）。

2. LeanFITT 的创始人是价值流管理概念和方法论早期发展的原始思想领袖。

3. 问题在于，这些经理和高管的职能部门中有多个价值流在运行，但度量指标和财务激励措施驱动的是部门或设施层面的改进。

4. 所有的行动，无论是创造价值还是非创造价值的，都需要将产品从概念推向发布（也称为开发价值流），并从订单到交付（也称为运营价值流）。这些包括处理客户信息的行动和在产品前往客户过程中对产品进行转化的行动。

5. 精益行动计划帮助减少阻力，传播正确的学习目标，并培养实现精益企业所需的承诺。

6. LeanFITT 系统提供了改进组织流程、人员和利润的方法、工具和技术。

7. 阶段包括：

   1. 培训和让人们参与其中。

   2. 标准化改进过程。

   3. 通过积极参与和透明度激励团队。

   4. 使精益成为常规并可持续。

8. 以逻辑和视觉化方式讲述持续改进故事的手段和方法。

9. 质量的一个信息性衡量标准，六西格玛过程是指 99.99966% 的所有机会生产的特性或部分预计在统计学上是无缺陷的。

10. 精益工具和质量工具

第十五章: 定义适当的 DevOps 平台战略

1. “灌输一种观念：DevOps 是一个全组织的文化运动，并设计出实践 DevOps 的价值流团队。”

2. 解决方案交付、DevSecOps、数据 DevOps、多解决方案支持、共同 IT 运营和业务运营。

3. 首席或业务线高管支持资助这些倡议，分配足够的资源，并要求人员在可识别的时间框架、预算和 ROI 下实现可衡量的结果，从而证明这些努力是值得的。

4. 他们的 IT 经理和高管们已经厌倦了在 IT 上花钱，却无法在组织的其他部分展现出价值。

5. 在 CI/CD 和 DevOps 流水线中，我们可以通过以基础设施即代码（IaC）和配置即代码（CaC）的形式实现的代码配置，自动化新版本的部署。

6. 构建定制的 DevOps 平台，购买基于云的 DevOps 即服务（DaaS）解决方案，使用 VSM 工具集成和协调你的 DevOps 工具链，并通过构建自助配置即代码的软件工厂，通过 GIT 或其他 SCM 工具进行下载。

7. 购买许可，使用商业DevSecOps 即服务（DaaS）。

8. 文化、自动化、精益、度量和共享。

9. 从零开始建立一个专门的 DevOps 团队只会在你的横向价值流中创造新的孤岛。

10. 组织的首席高管和业务高管。他们必须在困难时期保持动力。

第十六章: 利用 VSM 和 DevOps 转型业务

1. 将企业转型为能够在我们的数字经济中竞争的可行实体。

2. 错误。除了 IT 领域，这些概念相对较新，制造业和其他行业已经实践精益和价值流图（VSM）几十年了。

3. 丰田寻求在一个岛国中提高质量和效率，摆脱大萧条和第二次世界大战的影响，那时资源有限且昂贵。丰田的全球市场竞争策略是通过减少资源浪费，生产高质量的产品，同时确保他们只生产客户在需要时才购买的产品。

4. 敏捷最初是为了支持小型软件开发团队的需求，通过一套价值观和原则使其更具响应性和适应性。在这个过程中，敏捷逐渐演变为实现迭代和增量开发的实践，利用原型制作和经验主义，快速创造出能够响应客户需求的有效解决方案。

5. 识别、组织和映射

6. 连接

7. 敏捷 – 按照 1 到 4 周的周期进行度量，并且仅限于开发团队获得的预算和权限。

   精益 – 通常在多个规划周期中查看变化，这些周期可能跨越几个财年，并涉及需要高层支持和承诺权限的变更和预算。

8. 本地优化。

   因为我们可能会在这些计划上花费大量的时间、精力和资金，但未必能有效提升整个组织的价值交付能力。

9. 投资组合管理的主要目的是集中化和控制预算及投资过程，以便组织能够在公司战略的背景下评估所有改进机会及其优先级。

   VSM 和 DevOps 工具的投资与组织内部其他潜在投资之间存在竞争。

10. 因为新管理层进入后，无法轻易看到支撑横向价值交付的机制。他们更习惯于管理传统层级商业结构中的垂直孤岛。

Packt.com

订阅我们的在线数字图书馆，全面访问超过 7,000 本书籍和视频，以及行业领先的工具，帮助你规划个人发展并提升职业生涯。如需更多信息，请访问我们的网站。

第十八章：为什么要订阅？

• 用来自 4000 多位行业专家的实用电子书和视频，将更多时间用于编程，减少学习时间

• 通过特别为你定制的技能计划提高你的学习效果

• 每月获得免费的电子书或视频

• 完全可搜索，便于访问重要信息

• 复制、粘贴、打印和收藏内容

你知道 Packt 为每本出版的书籍都提供电子书版本，支持 PDF 和 ePub 文件格式吗？你可以在packt.com升级到电子书版本，并且作为印刷书籍的客户，你有权享受电子书的折扣。更多详情请通过customercare@packtpub.com联系我们。

在www.packt.com，你还可以阅读一系列免费的技术文章，注册各种免费的新闻通讯，并享受 Packt 书籍和电子书的独家折扣和优惠。

你可能感兴趣的其他书籍

如果你喜欢这本书，你可能对 Packt 出版的以下书籍感兴趣：

敏捷方式管理软件需求

弗雷德·希思

ISBN: 978-1-80020-6-465

• 学习如何与项目利益相关者沟通，以引导软件需求

• 用务实的方法和技巧处理需求生命周期的每个阶段

• 使用 Scrum 和 Kanban 管理软件开发过程并交付经过验证的需求

DevOps 采纳策略：原则、流程、工具和趋势

马丁·考普兰

ISBN: 978-1-80107-6-326

• 包含逐步解释和实际示例，帮助你快速入门 DevOps

• 培养你应对 DevOps 工具部署所需的技能和知识

• 了解 FinOps 和 DevSecOps 等技术趋势，以从 DevOps 中获得更多价值

Packt 正在寻找像你这样的作者

如果你有兴趣成为 Packt 的作者，请访问authors.packtpub.com并今天就申请。我们已经与成千上万的开发人员和技术专家合作，帮助他们与全球技术社区分享他们的见解。你可以提交通用申请，申请我们正在招聘作者的特定热门话题，或者提交自己的想法。

分享你的想法

现在你已经完成了《通过价值流管理驱动 DevOps》，我们非常期待听到你的想法！如果你是从 Amazon 购买的书籍，请点击这里直接进入 Amazon 评论页面

) 这本书的反馈和评论可以在您购买的站点上分享。

您的评论对我们以及技术社区非常重要，它将帮助我们确保提供优质的内容。

你可能会喜欢的其他书籍

你可能会喜欢的其他书籍