精益敏捷之道（二）

原文：annas-archive.org/md5/0b2addbef6e2afb0ce49d44d7300959a

译者：飞龙

协议：CC BY-NC-SA 4.0

第五章：介绍 VSM 实施路线图

采纳价值流管理不仅仅是一个步骤，而是向持续改进迈进的旅程，以创造一个不断发展的、洞察驱动的文化。

– 改编自 VSM 联盟

在 第四章 中，我们介绍了 VSM 作为一种使用精益方法优先排序机会的工具。本章探讨了 VSM 实施路线图，该路线图来自 价值流管理联盟（VSMC）1。VSMC 推广适用于精益敏捷企业的价值流方法和工具，特别是在数字技术深度应用的组织中。他们促进了战略投资和端到端运营的优化，避免了孤立决策的情况。这个路线图使得 VSM 方法能够广泛应用于组织中，同时结合精益和敏捷的概念，确保技术部门支持组织的价值流改进活动。

VSM 实施路线图包括以下步骤：启动、评估、愿景、识别、组织、映射、连接、检查和适应。它结合了精益和敏捷实践，与我们书中的基本原则——精益敏捷之道相一致。

VSM 实施路线图跨越行业边界，确保进行全面的端到端价值流评估，这对于实现显著的流动改进并避免常见的局部优化至关重要，而这种局部优化通常发生在忽视系统思维时。

掌握 VSM 实施路线图可以使您的组织系统性地优化价值流，理解其复杂性，并在企业内实施变革。

本章涉及以下主题：

• 介绍 VSM 实施路线图

• 探索 VSM 实施路线图的九个步骤

• 比较 VSM 方法论与 VSM 实施路线图

揭示 VSM 实施路线图

在解释 VSM 实施路线图的目的和关键步骤之前，了解 VSM 的历史是有帮助的，因为它为这一现代实施方法铺平了道路。

从历史中学习

价值流的概念有着深厚的历史背景，许多贡献者影响了其发展。虽然我们已经走了很长一段路，但这段历史依然具有相关性，因为它帮助我们理解当今 VSM 实施路线图的必要性。所以，在我们继续之前，让我们回顾一些精益思维和实践演变过程中最具影响力的历史事件。

• 丰田的早期****应用：丰田被认为是早期应用价值流概念的企业，使用了生产过程的视觉展示图，即物料和信息流图。然而，对于这些概念和工具首次在丰田应用的时间点存在争议（Baudin 2013）。2

• 沃马克和琼斯：詹姆斯·沃马克和丹尼尔·琼斯在《从精益生产到精益企业》一文中提出了“价值流”这一术语。3 他们强调，价值流定义了精益企业，并涵盖了交付最大客户价值所需的所有活动。

• 詹姆斯·马丁的见解：詹姆斯·马丁，计算机行业的杰出人物，在他所称的“企业工程”（Martin 1994）这一整体性实践中定义了价值流。4 马丁反对将自动化应用于设计不良的商业流程，这些流程通常与层级管理结构相对应，往往导致职能和组织工作流中的孤岛效应和低效。

• VSM 书籍的出现：在 2000 年代初，关于 VSM 的书籍开始出现，其中《价值流管理：供应链中的战略与卓越》（Hines 等人，2000）是最早之一。5 本书将 VSM 描述为提升客户体验的实践，并列出了七种价值流映射工具。

• 精炼 与 映射：随后的一些书籍，包括迈克·罗瑟和约翰·舒克的《学习看见》以及大卫·布伦特、吉姆·沃马克、丹·琼斯和马修·洛夫乔伊的《看见整个价值流》，在精炼价值流映射技术方面发挥了重要作用。6,7 这些出版物开始引入精益指标，以帮助发现影响组织端到端价值流的约束和浪费。

• VSM 作为 一种 方法论：唐·塔平及其合著者的书籍进一步将 VSM 作为一种使用精益原则和价值流映射进行持续改进的方法论。8

• 广泛 采纳：随着时间的推移，价值流改进理念的应用逐步扩展到各个行业。凯伦·马丁和迈克·奥斯特林的《价值流映射：如何可视化工作并使领导层实现组织转型》（Martin, Osterling 2013）一书显著地推广了这些思想。9

• 范围和内部价值流：马丁和奥斯特林进一步强调了在价值流映射中设置边界和限制，以帮助组织保持专注，并推广了面向支持的价值流理念，用于映射人力资源、IT、财务和销售等内部活动的过程。

还有一些其他重要的贡献者在持续推动现代 VSM 实践的发展。然而，这一历史视角提供了足够的背景，以便理解为什么现代 VSM 实践必须融合精益-敏捷概念，以及为何要创建 VSM 实施路线图的主要原因。此外，Scaled Agile Framework（SAFe）在推动价值流概念走出制造领域，并在敏捷框架中得到广泛应用方面发挥了重要作用。

检视 VSM 路线图的需求

到目前为止，我们所学到的是，价值流体现了精益理念，旨在解决与传统管理商业流程的孤立化操作模式相关的问题，这些模式通常适应层级化的组织结构。过多时候，这些层级结构导致了严重的低效，政治斗争争夺人员、资金和其他资源，缺乏以客户为中心的关注，无法全面评估投资，更不用说从客户中心的视角进行评估。

相比之下，价值流侧重于从客户的角度理解组织如何创造价值，超越组织边界和自我利益。实质上，价值流定义了一个无缝的工作、材料、信息和资源流动，有效地传递价值，而不受组织边界的限制。价值流的目标是消除浪费和瓶颈，这些通常导致产品延误、成本增加和质量下降。

在第四章中，我们探讨了价值流图（VSM）作为一种方法论的出现，旨在帮助组织评估其在价值流中的最关键改进点。作为一种方法论，VSM 遵循以下通用模式：

• 教授精益-敏捷概念

• 确定并优先排序价值流

• 定义理想化的价值状态以进行基准测试

• 通过 Gemba 走访，利用当前状态的价值流图揭示浪费和瓶颈

• 通过未来状态的价值流，直观地展示拟议的价值流改进

• 制定 Kaizen 改进计划，记录推荐的变更，包括对当前状态、期望未来状态的评估、差距分析、ROI 论证、优先级排序和替代建议。

• 执行 Kaizen 计划以实现既定目标和指标

• 建立持续改进和转型的文化

• 当产品或服务达到其经济可行的生命周期终点时，停止该产品或服务的持续改进过程

这一全面的方法确保组织识别改进机会，并作为其转型业务文化的一个组成部分，执行和维持这些改进。然而，随着敏捷方法论的出现，重新思考 VSM 方法论如何融入精益和敏捷实践变得至关重要。这是下一节的主题。

探索 VSM 实施路线图

拥抱精益-敏捷思维，VSMC 的 VSM 方法旨在通过持续改进和客户关注来增强价值交付。

图 5.1 展示了 VSM 实施路线图，这是一个指导组织采纳 VSM 工作方式的高层次步骤系列。每个步骤为下一个步骤奠定基础，推动采用 VSM 主导方法的组织不断优化客户体验，并展示了 VSMC 实施路线图，这对 VSM 方法论至关重要。在识别和优先考虑持续改进的同时，VSM 路线图整合了来自敏捷的检查和适应概念。检查和适应使得基于新的学习和市场变化进行持续进展回顾和调整策略成为可能。路线图的每一步都将我们引向卓越的客户价值交付和满意度。其包含以下步骤：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_05_1.jpg

图 5.1 – VSM 实施路线图

尽管路线图呈现了实施步骤的线性流向，但实际上，每个步骤可能会根据反馈和学习进行迭代。以下列表列出了每个步骤的目的。

1. 开始：通过设定变革和承诺的步骤，启动 VSM，并使使命与精益敏捷（Lean-Agile）原则对齐。

2. 评估：评估当前的运营环境（文化、能力和背景），基准现有表现，并建立改进的商业案例。

3. 愿景：一个令人信服的未来愿景能够激励和推动人们采取行动，为价值创造设定明确和战略的方向，并可视化将推动成功的成果。

4. 识别：选择一个需要改进的价值流。关注客户价值以识别组织的价值流。这对于以项目为中心的组织来说可能具有挑战性，因为长周期产品（与短期项目不同）揭示了价值流，任何交付产品或服务的过程都构成一个价值流。

   目标改进的第一个价值流通常是满足四个标准交集的价值流：强大的领导支持、高度可见的价值流、现有的敏捷团队以及一个重大的挑战或机会。

5. 组织：围绕产品或服务系统地组织人员、资源和工作流程，优化跨职能部门和整个系统的价值流动。

6. 映射：组建价值流图（VSM）团队，以识别并理解当前涉及为客户交付价值的步骤和活动。映射有助于识别瓶颈、延迟以及价值流中的改进领域。

7. 连接：整合并连接价值流中的人员、流程和工具，促进沟通与团队合作。当工作项可以在整个价值流中追踪时，延迟、返工和浪费将变得可见。这些见解推动改进，而反馈则为决策提供依据。

8. 检查：通过分析数据、设定改进目标、定义关键指标并利用自动化数据收集系统进行准确跟踪来监控绩效。只有通过从数字价值流中提供数据和洞察，才能持续地检查、管理和改进流动和价值实现。

9. 调整：一旦你拥有足够的数据和洞察来指导行动，就该实施变革了。鼓励持续的、迭代的改进，以适应变化，并积极追求卓越。

通过遵循其结构化方法，VSMC 路线图简化了运营，并不断将其与为客户提供卓越价值的总体目标对齐。每个步骤都承诺贯彻精益敏捷的思维模式，确保企业在追求运营卓越的过程中保持敏捷、响应迅速并以客户为中心。

我们将进一步探讨每个路线图步骤。

实施价值流管理

根据 VSMC，实施价值流管理（VSM）不仅仅是提升运营效率。它体现了效率、响应性和战略远见。因此，这一视角是理解他们 VSM 实施路线图细节的基础。以下部分将详细概述九个路线图步骤。

1. 开始——启动价值流管理

你的 VSM 实施之旅始于当前状态，无论你的数字化流程成熟度如何。每个企业的核心都是价值流和为满足客户需求或服务市民（在政府情境下）而设计的价值流网络。无论盈利导向如何，组织都在不断创新、开发和交付产品或服务。

每当有创新的火花或提出的变更时，它都要经过设计、开发和交付，客户才能体验到其价值。许多组织早已采用敏捷方法、DevOps 实践或精益原则。其他组织可能正在经历如重组、并购等结构性变化。这些因素不会阻止企业采用并推动 VSM 方法论和工具的使用，反而会加强变革的商业案例。然而，领导者必须警惕持续变革带来的疲劳感。要清晰地阐明 VSM 实施的目的和愿景，并帮助知识工作者理解他们的工作如何为组织的总体目标和任务做出贡献。一个明确的目的能为变革提供背后的“为什么”，并激励人们与组织共同走过这段旅程，积极参与其成功。

采纳 VSM 的典型障碍是缺乏高级领导的支持和资源有限。具有前瞻性的个人应该带着调整方向的意图行动，而不是等待许可，过程中应将领导者一同带入。积极的个人认识到，当低效被消除时，通常可以缓解资源的感知限制，从而释放系统内的容量。尽管如此，这种积极的姿态并不意味着高层管理人员可以回避其在组织转型中的职责。

跳到游行队伍前面并不意味着你是领导者。真正的领导力不仅仅是站在前面。它需要远见、同理心以及激励和引导他人朝着共同目标前进的能力。一个真正的领导者会倾听、合作并以身作则，而不是单纯寻求聚光灯。

领导者通过动手实践和对组织内部运作的深入了解，获得了引导公司前进的信誉和权威。这种参与不仅限于领导变革，而是成为转型的重要组成部分，确保 VSM 的实施是一个共同的旅程。

虽然强调领导层参与的重要性，但我们并不提倡领导者亲自指挥所有任务或单独做出每个决策的情景。这种集中化可能导致不利后果，包括决策瓶颈、缺乏信息的选择和与组织实际动态相矛盾的偏见。

有效的领导者理解授权的价值，并信任团队处理战术性、日常的决策。当组织制定出可见的活动和定义进展的关键指标时，委托决策变得更加容易。这种方式赋予了员工权力，培养了责任文化，并确保组织的方向由多样化的见解和专业知识塑造，从而促进了更强大、更有韧性的 VSM 实施。

VSM 实施路线图中的“开始”步骤涉及以下主要活动，如图 5.2所示：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_05_2.jpg

图 5.2 – VSM 启动活动

这些关键活动为有效实施 VSM 奠定基础并设定方向：

• 组建 核心团队：为 VSM 创建一个基础团队应该集合具备广泛专业知识的个人。推荐两种类型的团队：

  • VSM SME 团队 – 一个小型的、专门化的 VSM 领域 专家（SME）团队，他们在组织的各个 VSM 项目中提供支持、教育和指导。他们负责推动 VSM 方法论并监督 VSMC 路线图活动的实施。

  • 价值流改进团队（VSIT） – 该团队成员积极参与改进目标价值流。他们具备关键领域知识，并在实施后续章节中提出的概念时发挥重要作用，具体包括在第九章中定义企业业务敏捷系统（BASE），包括建立支持最小有价值增量（MVI）目标的节奏。VSIT 的组成是动态的，并且每个 MVI 可能有所不同。

• 评估 当前 情况：此步骤要求对当前情况进行初步评估。理想情况下，应该有高层的立即支持，但如果无法获得，目标是产生动力，并为 VSM 之旅争取支持和所需资源。

• 设定战略方向：此步骤的重点是概述 VSM 计划的战略目标和任务。这意味着考虑其如何支持公司更广泛的战略目标、提升客户价值、提高运营效率并增强整体业务表现。

这三项‘开始’活动为组织提供了多个好处。首先，通过组建专门的团队，它们为启动成功的 VSM（价值流管理）计划奠定了核心资源。其次，它们提供了对组织当前状况的快速评估，弥合了现有状态与实现更广泛业务战略所需的战略目标之间的差距。它的另一个好处是提供了实现去中心化决策和执行所需的对齐和方向，利用团队的集体智慧。

完成这三项关键活动后，VSM 和 VSIT 团队将进入 VSM 的第二步，‘评估’。

2. 评估 – 评估并确定当前的绩效基准

评估，VSM 实施路线图中的第二步，建立在‘开始’步骤的基础上，涉及对现有 VSM 能力的全面评估，以建立绩效基准，并识别改进领域。

VSMC 开发了与实施路线图步骤对齐的 VSM 评估。该评估旨在为当前状态设定基准，并在 VSM 实施过程中进行持续的再评估。这个评估阶段源于 VSMC 的合作努力，强调了在 VSM 之旅开始时对当前状态进行基准测量的重要性，并保持持续的进展监控。

VSMC 的评估工具采用了李克特量表问卷，如图 5.3所示，促使受访者根据从强烈同意到强烈不同意及不适用的范围，对其当前状态进行评分。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_05_3.jpg

图 5.3 – 李克特量表评估

该评估工具专为咨询师和企业实践者设计，帮助识别重点领域、为未来的衡量设定基准，并与行业基准进行绩效对比。

作为一种在线自助工具，评估邀请团队回答标准化问题 – VSM 评估 (vsmconsortium.org/vsm-assessment)。此工具有助于内部基准测试，并允许与其他团队和组织进行对比。评估从评估组织的愿景和领导力支持开始，这些是成功采用 VSM 的关键驱动因素。

通过利用此工具，团队可以系统地发现其方法中的优势与劣势，提供清晰且可量化的 VSM 旅程衡量标准，并找到前进的路径，将其价值流实践提升至世界级标准。

完成了全面的‘评估’阶段，在此阶段中，我们对当前流程进行了评估，现在我们将进入‘愿景’阶段。在这一阶段，我们的关注点从理解当前价值流状态转向定义我们期望的未来状态愿景。

3. 愿景 – 创建统一的愿景和目标

在愿景阶段，组织必须定义并阐明一个长期的愿景和目标，以引导其转型之旅。这个愿景必须被深入理解并广泛传播，在组织内部成为新的常态。简单来说，这就是我们在这里工作的方式。这不仅仅是应对现有系统，而是要转变组织思维方式，并培养新的习惯。图 5.4展示了愿景阶段的核心要素：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_05_4.jpg

图 5.4 – 制定共享愿景

愿景强化了组织对定义无缝流动的有价值的客户成果的承诺。这是一个组织设想未来、摒弃浪费和不必要约束的过程，深入了解客户体验，并迅速采取行动，每一个洞察都推动实际的改进。

与此愿景相关的目标与提升组织效能密切相关，尤其是在数字盈利领域中尤为重要。这些目标包括对客户需求的高度响应、工作过程的透明度、赋能价值流的自主性，以及在市场中获得竞争优势。通过衡量改进，这些目标为追踪和优化交付速度、客户影响、成本效率和市场领导力奠定了基础。

愿景步骤的目标旨在通过强调敏捷性、透明度和对市场动态的适应性，提高组织的效率。其目的是迅速响应客户需求，确保清晰有效的流程，并使价值流直接影响财务成功。目标必须具有雄心壮志，并能通过领先指标进行衡量。第四章中讨论的 SMART 标准为跟踪业务目标和指标提供了一个结构化的方法。

领先指标使得跟踪组织在迅速实施变革、有效满足客户需求、有效管理成本以及在市场中维持竞争优势的能力成为可能。

执行领导者必须承担设定战略方向的角色，并赋予团队战略洞察力，积极参与转型。这是一个合作努力，设定了如改善客户体验、减少流程浪费、缩短反馈周期和与财务模型对齐等目标。在第九章中，我们将讨论如何使用 OKRs（目标与关键结果）帮助高层设定清晰的期望。

每个目标都与可量化的结果相关联，如提高客户参与度、更快的价值交付、改善决策制定和正向财务回报。通过将愿景细化为可衡量的目标，团队可以追求渐进的进展，使愿景成为一个具体可达的现实。

拥有清晰的愿景为将愿望转化为可衡量的成果奠定了基础，推动组织在 VSM 旅程中朝着共同方向前进。

4. 识别——揭示价值流

识别步骤的目标是定义和描述组织内的价值流。在一个通常由层级化组织结构和基于项目的思维主导的环境中看到价值流可能会遇到挑战。与项目不同，项目是临时的且有限的，而价值流代表了从开始到交付及其之后的产品或服务生命周期。它们是将一个想法转化为对客户有价值的成果所需的一系列活动。

例如，在一个销售产品的电子商务系统中，核心价值流包括对组织使命至关重要的活动，而支持性价值流包括促进核心价值流活动的平台和 CI/CD 管道。我们将在第三部分中进一步探讨流的分类方法。

识别过程包括识别各种产品、服务、平台及其各自的内部或外部客户。每个价值流都有一个起点，从那里产生一个想法，并有一个终点，将价值交付给客户。绘制这些价值流图，理解它们如何交汇和相互支持，并识别依赖关系，是至关重要的。

目标是朝着改进的方向逐步迈进。组织可以通过从小规模实验开始并从中学习，系统地解开其价值流的复杂性。主要的关注点是识别和命名增值步骤，识别它们服务的客户，并绘制出从开始到结束的整个旅程。采用这种方法，即便是最复杂的系统也能够随着时间的推移有效地被导航和优化。

你可能会注意到，VSM（价值流管理）实施路线图包含了精益和敏捷元素。在这个背景下，我们利用迭代和增量开发过程来识别组织内的精益改进机会。在‘检查’和‘适应’阶段，我们将重新审视迭代和增量改进的概念。然而，随着我们进入下一步——‘组织’，仍然有许多内容需要覆盖。

5. 组织——简化跨职能协作

组织步骤承认从传统的孤立结构转向更加集成的方法，其中技术团队与业务紧密对齐。从 DevOps 到更广泛地包括财务、人力资源、销售、市场营销、产品管理和治理、风险与合规（GRC）的转变，突出了这一变化。

瓶颈带来的问题非常严重。团队之间的交接可能会导致错误、延误或失去机会。此外，组织层级和脱节可能导致与业务目标不一致，从而导致交付速度变慢和客户满意度下降。

因此，核心价值流必须视为涵盖从概念到客户实现的整个过程，而不是人为地将业务与技术分开。某些角色，如投资组合经理，可能不会专门负责单一的价值流，因为它们具有跨越性的特点。同样，像发布和云工程师这样的专业角色可能会跨多个流进行操作，可能存在于一个平台或支持团队中。

许多人，无论是组织内部还是外部的人，可能都关心我们提供的产品和服务。然而，最终的利益相关者是客户，价值流应当自主运作以服务客户。

尽管角色位于价值链中的特定点，但所有角色应该关注各自流中的价值流动和实现，而不仅仅是它们对流程的贡献。

‘组织’步骤的以下考虑因素至关重要：

• 识别 VSM 和跨职能团队：确认必要的角色并组建能够跨职能边界操作以改进价值流的团队。

• 角色和责任的定义：界定每个团队及其成员负责的内容，确保每个角色都致力于增强提供给客户的价值。

• 沟通：建立健全的沟通机制，促进所有团队之间的无缝互动和信息共享。

• 培训 和 支持：为团队提供全面的培训和资源，使其能够有效履行其 VSM 角色。

• 监控 和 调整：持续监控价值流的表现，随时调整团队组织和动态，确保最佳运行和价值交付。

通过拥抱这些原则，组织可以创建一个促进效率、对齐和以客户为中心的统一环境，摆脱孤立运营，向完全集成的数字价值流迈进。

我们已准备好与已经组建的 VSM 团队一起推动前进，以促进跨职能 VSIT 团队的培训、辅导和指导。第六步，“绘制”，将审视价值流映射过程，使团队能够精确定位改进的领域。

6. 绘图 - 可视化流程效率和机会

制作价值流地图是分析和改进价值流的关键步骤。该过程通常包括以下步骤：

• 组建您的绘图团队：此初始步骤涉及聚集一个跨职能团队，其成员在组织步骤中已经确定。该团队将协作创建价值流地图，汇集各自的多样化专业知识和观点。

• 定义 范围：必须清晰定义绘图练习的范围，确定要绘制的价值流的边界。这包括设置起始点和结束点，通常从最初的客户请求到最终产品交付。

• 创建当前状态地图：从价值交付向最初的客户请求逆向工作，团队以可视化方式呈现价值流的当前状态，包括流程中的每个独特过程。该地图作为识别浪费、瓶颈和潜在改进区域的基准。

• 收集 过程 数据：在这个阶段，团队为价值流中的每个过程收集相关数据。重要的指标包括周期时间、从最初客户请求到增值时间、在制品、等待时间以及其他指标，以了解流程和延迟。

• 分析地图：最后一步是彻底分析当前状态图。鼓励团队成员分享对潜在变化或优化的见解和观点。这种协作性回顾旨在生成对价值流的共同理解，并促进关于下一步改进的共识。

通过这些步骤，映射过程捕捉了价值流的当前状态，并为持续改进提供了跳板。通过引入跨职能团队，映射练习确保了各个角度的考虑，从而导致了更加全面和有效的改进方法。

VSMC 对价值流映射的方法与现代精益实践一致，如 图 5*.5* 所示：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_05_5.jpg

图 5.5 – 示例价值流图

在映射价值流后，我们将讨论下一个阶段——‘连接’。在这一阶段，我们将整合价值流中的人员、流程和工具，增强有效沟通，推动协作，并通过数据驱动的洞察支持决策。

7. 连接 – 协调人员、流程和工具

鉴于我们在数字时代竞争的迫切需求，连接对于将 DevOps 工具链整合进价值流至关重要。工具链涵盖了一个想法的整个生命周期，从组合管理开始，经过产品待办事项、持续集成/持续部署（CI/CD）、发布和环境管理，最终到服务台。这套全面的工具对于跟踪从想法到实现的价值至关重要，并能深度分析客户体验。

现代的 DevOps、CI/CD 和 VSM 工具及平台可能非常昂贵。然而，如 图 5*.6* 所示，可定义的好处可能非常可观：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_05_6.jpg

图 5.6 – 通过 VSM 工具和平台连接所提供的能力

‘连接’活动旨在通过整合沟通、技术和反馈，创建一个无缝且高效的工作流程。现代 VSM 工具和平台提供了支持连接阶段的集成、可视化和分析能力。

以下是连接活动的简要概述：

• 定义沟通协议：此活动涉及建立明确的指导方针，确保团队成员之间的信息交换方式一致且有效，确保沟通在所有价值流层级中保持一致。

• 整合技术和工具：此步骤将各种技术解决方案和工具结合成一个有机的系统，以支持价值流，提升团队协同工作和高效工作的能力。

• 自动化数据收集：这一活动旨在减少人工工作、最小化错误，并为分析和决策提供一致且可靠的数据流。

• 启用实时可视化：这包括设置能够提供即时洞察价值流性能的系统，便于迅速识别问题和改进机会。

• 建立反馈循环：创建反馈循环支持持续学习和改进，使价值流能够根据团队经验和收集的数据进行适应和演化。

这些活动中的每一项都在连接数字价值流的各个元素中发挥着至关重要的作用，确保流程尽可能高效和响应迅速。

跟踪整个价值流中的工作项是由图 5.6 中显示的工具提供的强大功能。它们揭示了延迟、返工以及沿途发生的任何浪费。收集到的洞察能够通过使这些元素可见来为改进提供信息，而反馈推动了基于数据的决策。

总结来说，连接人员、流程和工具创建了一个有凝聚力、透明的工作流，其中每个行动和结果都可以追溯到其源头。这确保了团队保持一致，从实时数据中学习，并不断调整以优化价值流。这个连接阶段不仅仅是一个步骤，更是支撑高效和持续改进文化的持续实践。

8. 检查——使用计划-执行-研究-行动（PDSA）循环来改进价值流

价值流源自精益，但 W. Edwards Deming 的计划-执行-研究-行动（PDSA）指导为其奠定了重要基础。因此，我们推荐使用他所推广的 PDSA 循环 来改善我们对价值流的理解，也就不足为奇了。

PDSA 不仅仅是简单的“检查与调整”。它采用基于证据的决策方法，避免推测，优先采用经验主义，并使用经过验证的理论。这一过程使我们超越了传统方法中固有的先入为主的观念。

• 计划：在我们做任何事情之前，我们需要一个假设和一个计划。规划的时间框架可以从几分钟到几天不等。计划设定了我们认为会发生的预期。这测试了我们对情况的理解以及它的有效性。它提供了一个基准，以查看我们对当前情况的理解有多好。

• 执行：这是我们执行计划活动的阶段。然而，如果证据表明事情并未按预期进行，我们会调整计划，以反映我们对当前情况的新理解。戴明的 PDSA 循环在计划的时间框架内应用持续学习。

• 研究：我们使用快速反馈来判断发生的事情（或“做”）是否符合我们预期的（我们的“计划”）。这个反馈循环可以是持续的，或者在计划的增量结束时进行。通过查看计划和执行之间的差距，我们可以调整方向并挑战我们的理解。换句话说，我们进行研究以确保我们以正确的方式构建正确的产品，同时确保我们的思考也是正确的。

  这个过程被称为双环学习。单环学习是指在你正在做的事情上变得更好。双环学习挑战“你正在做的事情”，看看是否有更好的工作方式，或者你正在做的事情是否正确。任何不能有效改变其实践的过程都会限制双环学习。

  三环学习是学习如何学习。三环学习教会我们如何挑战我们的假设。Chris Argyris 关于双环学习的文章可以在 infed.org/mobi/chris-argyris-theories-of-action-double-loop-learning-and-organizational-learning/ 中找到更多详细内容。

• 行动：在“研究”阶段之后，我们的重点转向按照我们的计划生产我们所构建的内容，同时提升我们对所使用模型的理解。

VSMC 主张沿着两个主要维度检查价值：

• 流动：确保工作从构想到交付的过程顺畅流动，代表着为客户持续交付价值

• 价值：实现期望的业务成果，使客户体验到预期的价值

这些维度帮助组织评估价值流的健康状况和客户体验，以评估效率和效果。

“检查”阶段使我们能够专注于分析和增强价值流的表现。这包括一系列战略性行动，旨在理解和改进价值流过程的各个方面。以下是推动此阶段的关键活动：

• 定义 相关 指标：定义价值流的核心绩效指标，如交付时间、周期时间、产量、正在进行的工作和缺陷率。

• 利用自动化数据收集：利用 DevOps 工具中的实时数据分析性能，了解工作的真实进展。例如，开发人员在看板系统中将工作标记为“完成”，但来自故事的完成工作可能会在其他团队的发布队列中停留数月。DevOps 工具和数据提供了更准确的视图，将度量基于端到端过程。

• 监控性能：通过分析来自 DevOps 工具的实时数据和洞察，持续关注你价值流的表现，以防止服务中断。团队必须不断监控系统的各项属性，如安全性、可靠性、性能、可扩展性等。

• 分析 数据：检查收集到的数据，以评估流程的有效性并找出需要改进的地方，包括产品和服务的业务成果。

• 设定 实验性 改进 目标：基于透彻的数据分析，制定针对性的实验性改进目标，以提升价值流表现。

维持工作流的顺畅并实现预期的业务成果需要一种警觉且积极主动的管理和精炼方法。数字价值流中丰富的数据和洞察提供了团队所需的机制，以维持一个持续检查和适应的循环。

9. 适应——沟通、界定范围并规划干预措施。

适应阶段代表着 VSMC 的 VSM 实施路线图的高潮，洞察和数据汇聚在一起，推动可操作的变革。在这一阶段，焦点转向实施和迭代来自检查阶段的变革。这个阶段的特点是七个关键行动，每个行动都旨在发展和精炼价值流：

• 拥抱持续改进：承诺不断改进，始终寻找增强价值流的方法。

• 消除 浪费：识别并去除低效环节，以简化流程并最大化价值。

• 衡量 结果并 迭代：评估变更的结果，并进行迭代调整，确保持续进展。

• 微调流程：调整和优化现有流程，以提高效果和效率。

• 自动化工作流：实施自动化，以减少人工努力并提高一致性和速度。

• 分享 最佳 实践：在企业的价值流中培养并应用成功的模式和技巧。

• 培养适应文化：培养一个在组织内广泛拥抱灵活性和变革的环境，推动改进。

这些适应活动不是孤立的努力。它们代表了一种协调一致的适应方法，这对于 VSM 生命周期至关重要。检查和适应步骤本质上是相互关联的，彼此相互作用，形成一个反映敏捷原则的持续循环，通过这种敏捷方法，协作团队确保价值流是优化的、具有韧性的，并且能够响应变化。

“适应”阶段还涉及利用你的价值流图作为沟通工具，以概述、界定和协调必要的变更。这是一个战略阶段，你在此阶段中制定并记录关于变更潜在影响的假设，并开发一个清晰、结构化的路线图，详细说明立即行动、下一步和未来考虑事项。

必须承认，价值链中的每一次变化都可能带来意外的后果。价值流并非孤立存在；系统思维方法对全面理解和有效管理至关重要。

图 5*.7* 展示了一种结构化的方法，用于制定和完善适应假设，确保与预期愿景的一致性，同时庆祝沿途所取得的里程碑：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_05_7.jpg

图 5.7 – VSM 适应阶段

随着变化的发生，价值流图成为一个活文档，突出改进并重新定义当前状态。这正是敏捷适应的迭代特性发挥作用的地方，提供了持续改进和一个永续的开发与改进循环。

在我们的数字时代，VSM 检查步骤帮助 VSIT 团队发现利用数字化进步改进挑战组织常规方法的领域。一旦收集到洞察和数据，实施变更至关重要，这正是 VSM 适应步骤的主要重点。

价值流映射能够引起对改进的关注，并重新定义当前状态。必须认识到，一旦采取了行动，图表应当随之演化，以避免未来的误解和不一致。

比较 VSM 方法论和 VSM 实施路线图

乍一看，E9 VSM 方法论和 VSMC 的实施路线图似乎有相似的流程、目标和目的。它们都包含九个步骤，有些步骤的名称也类似。但它们的关注领域不同。图 5*.8* 和 图 5*.9* 比较了这两者，并阐明了我们将在本节中探讨的关键差异：

VSM 方法论已有二十多年的历史，在我们的 E9 VSM 模型中，包含了一套结构化的九个步骤，如 图 5*.8* 中所示：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_05_8.jpg

图 5.8 – VSM 方法论

VSMC 的实施路线图已近三年，并巧合地由九个步骤组成，如本章所述并在 图 5*.9* 中展示：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_05_9.jpg

图 5.9 – VSMC 实施路线图

虽然两个路线图在流程、目标和宗旨上有相似之处，但也存在关键的区别。VSM 方法论是一种经过验证的精益导向方法，旨在推动任何类型价值流中的生产力、效率和质量改进。相反，VSMC 实施路线图则通过现代化 VSM 方法来支持竞争力，并在数字时代提供增值服务。此外，VSMC 的路线图融入了敏捷的迭代概念，用于检查和适应。

这并不是选择一种方法而放弃另一种方法的问题。两者的目的都是为了提升价值流，但它们有着不同的角色：

• VSM 方法论帮助组织识别和优先考虑跨组织边界的价值流改进。具体来说，它使协作团队能够评估和评估跨职能和跨部门的变革机会，确保改进能够以现有资源提供最具影响力的以客户为中心的价值。

• VSM 实施路线图结合了敏捷的检查和适应步骤，以提高敏捷性。这个路线图还使 IT 组织的活动保持一致，推动组织各个产品和流程的数字化提升。它专注于创建 IT 基础设施，以支持数字化改进并增强竞争力。

这些方法相辅相成，确保价值流改进团队能够有效地解决更广泛的组织改进和 IT 特定的数字化提升问题。

尽管 IT 组织可以独立改进其开发和交付服务，但它们必须与更广泛的组织改进需求保持一致。VSM 路线图帮助识别数字化改进至关重要的领域，确保 IT 有效支持组织的端到端价值流，涵盖核心产品和服务。

摘要

在本章中，你已经深入了解了 VSMC 实施路线图，这是一种 VSMC 提供的全面方法，用于有效实施 VSM 原则和实践。本章为你启动组织的业务转型之旅提供了实用的路径，无论你是一个正在发展未来技能的年轻专业人士，还是一个追求竞争优势的高管。

你在这里学到的经验教训非常重要，因为它们为你提供了实现变革所需的知识和工具。VSM 实施路线图有助于系统地优化价值流，确保全面的评估，从而实现无与伦比的改进。它超越了行业界限，避免了“局部优化”的陷阱。

在下一章中，我们将探讨如何在利用数字化提升的同时，从管理项目转向管理产品。

问题

本节内容供希望评估本章提供信息理解和记忆的读者使用，共有 10 个问题。答案在接下来的子章节中给出。回忆原文内容的准确措辞并非必要，重要的是回忆概念及其应用。

1. 在 VSMC 实施路线图的“开始”步骤中，有哪些三项关键行动，它们如何促进 VSM 举措的成功？

2. VSM 评估工具如何在 VSM 实施路线图中的“评估”阶段提供帮助？

3. VSM Step 3中的“愿景”阶段的主要目标是什么，它如何影响组织转型？

4. 在VSM Step 4“识别”的背景下，“核心价值流”和“支持性价值流”有何区别？

5. 在有效实施VSM Step 5“组织”时，有哪些关键考虑因素有助于简化跨职能协作？

6. 根据《VSM 实施路线图》，价值流图绘制过程涉及的五个步骤是什么？

7. 在VSM Step 7“连接”中，涉及哪些主要活动，以协调人员、流程和工具的整合？

8. 在VSM Step 8“检查”中支撑的三大经验主义支柱是什么，它们如何帮助提升价值流绩效？

9. VSM“适应”阶段的七项关键行动是什么，它们旨在完善价值流？

10. 传统 VSM 方法论与 VSM 实施路线图之间的主要区别是什么？

答案

1. 第 1 步“开始”中涉及的三项关键行动是组建核心团队、评估当前局势、设定战略方向，这三者共同奠定基础资源，提供快速的组织评估，并将 VSM 举措与更广泛的战略目标对齐。

2. 在第 2 步“评估”中使用的比较敏捷 VSM 评估工具，有助于全面评估组织当前的 VSM 能力，进行基准对比，识别改进领域，并引导团队优化价值流实践。

3. 第 3 步“愿景”的主要目标是定义一个长期愿景和目标，改变组织的思维方式，培养新习惯，并与可衡量的目标对齐，以提高效率和竞争力，尤其是在数字化和盈利领域。

4. 在第 4 步“识别”的背景下，核心价值流直接交付组织的核心产品和服务，而支持性价值流则使这些核心职能得以支持，例如开发平台或客户关系管理系统。

5. 有效实施 VSM 第 5 步“组织”要求识别 VSM 和跨职能团队，定义角色和责任，建立沟通渠道，提供培训和支持，并持续监控和调整，以确保价值流的最佳运行和交付。

6. 在第 6 步“映射”中，价值流映射过程的五个步骤是组建映射团队、定义范围、收集流程数据、创建当前状态图并分析图表以识别改进机会。

7. 第 7 步“连接”的主要活动包括定义沟通协议、整合技术与工具、自动化数据采集、启用实时可视化并建立反馈循环，以创建无缝、高效且响应迅速的数字价值流工作流程。

8. 实证主义的三个支柱在第 8 步“检查”中分别是透明性、检查和适应，通过促进信任、鼓励持续反馈并基于事实和证据做出决策，帮助提升价值流表现，指导基于事实和证据的决策，推动持续改进。

9. 第 9 步“适应”的七个关键行动是衡量结果并迭代、接受持续改进、消除浪费、优化流程、自动化工作流程、分享最佳实践，并培育适应文化以不断发展和完善价值流。

10. VSM 方法与 VSMC 实施路线图的主要区别在于后者采用了现代化的方法来提升在数字时代的竞争力。VSMC 的路线图融合了精益和敏捷理念，关注 IT 基础设施和数字化增强。而 VSM 方法依然对广泛的组织改进和跨部门变革具有重要价值。

进一步阅读

1. www.vsmconsortium.org/

2. Baudin, Michel. “‘价值流图’从哪里来？” Michel Baudin’s Blog. 2013 年 10 月 25 日. michelbaudin.com/2013/10/25/where-do-value-stream-maps-come-from/.

3. Womack, James P., 和 Daniel T. Jones. “从精益生产到精益企业。” 《哈佛商业评论》 72 (1994): 93-103.

4. Martin, James. 1995. 《伟大的转型：利用企业工程的七个学科对齐人员、技术和战略》. 纽约: Amacom.

5. Hines, Peter, Rich, N., Bicheno, J., Brunt, D., Taylor, D., Butterworth, C. 和 Sullivan, J. (2000). 《价值流管理：供应链中的战略与卓越》. Financial Times/Prentice Hall.

6. Rother, Mike, 和 John Shook. 1999. 《学习看见：价值流映射以创造价值并消除浪费》. Lean Enterprise Institute.

7. Brunt, David, Matthew Lovejoy, Dan Jones, 和 Jim Womack. 2003. 《看见整个价值流》. Lean Enterprise Institute.

8. 塔平、唐、汤姆·卢伊斯特和汤姆·舒克. 2002 年. 《价值流管理：规划、图示和维持精益改进的八个步骤》. 纽约：生产力出版社。

9. 马丁、卡伦和迈克·奥斯特林. 2013 年. 《价值流图示：如何可视化工作并使领导力与组织转型对齐》. 纽约：麦格劳-希尔出版公司。

第六章：导航价值流优化

悲观主义者抱怨风向；乐观主义者期待风向改变；现实主义者调整帆。

• 威廉·亚瑟·沃德

在快速发展的商业管理世界中，一个关键因素常常决定成功的领导者与其他人的区别：那就是导航和优化工作流的能力，并在组织内交付价值。例如，假设你的组织就像一艘设计精良的船，拥有一支积极的船员，并且有一个明确的目的地——为客户交付价值。一切看似完美，但正如我们所知，商业的水流和风向并非总是可预测的。

本章将探讨如何从管理项目转向管理产品，同时利用数字化增强。借用之前的航海隐喻，我们将说明如何在价值流的道路上航行，就像在不断变化的风和水流中航行一样。

价值流不断变化；没有什么是静止不变的。然而，在今天的环境中，有两种转变保持不变，成为精益企业的关键：

1. 从项目转向产品：为了保持竞争力并以客户为中心，我们必须将焦点从管理短期项目转向在其经济可行的生命周期内持续发展我们的业务流程、产品和服务。

2. 利用数字化增强：采用数字化增强是有效改善流程、产品和服务的关键

引入价值流运营模型至关重要，这为适应性提供了坚实的基础，并提供了跨组织的价值创造与交付的整体视角。这些新型运营模型将人员、流程、信息和技术整合，以优化工作流。从项目转向产品并拥抱客户至上，可以实现可持续的价值创造与交付。

通过理解优化价值流如何推动组织转型，你可以改善满足客户需求的解决方案，促进敏捷性，并获得竞争优势。你将掌握提升生产力、效率、适应性和价值交付的策略。

本章涵盖以下主题：

• 从项目转向产品

• 理解价值流运营模型

• 识别并克服精简工作流的障碍

• 在价值流中平衡创新与效率

• 优化价值流以提升绩效

从项目转向产品

在数字知识工作的演变过程中，从基于项目的模型到以产品为中心的模型发生了一个关键的转变，这一转变改变了组织如何交付价值以及如何响应市场需求。Mik Kersten 的著作《从项目到产品》引起了人们对这一变化的广泛关注，提供了一个结构化的框架和实践指导，巩固了这一概念。基于敏捷和 DevOps 社区的讨论，Kersten 的工作加强了产品为中心的思维方式的重要性，这一点已经被敏捷方法论和 DevOps 运动所阐明。

传统上，以项目为中心的范式通常与瀑布式 开发 模型相关，强调的是具有特定范围、预算和时间表的离散性、临时性努力。然而，这一模型被证明效率低下，不必要地拖延项目进度，导致编码错误和缺陷的积累，最终使得这些问题越来越难以解决。此外，它往往导致孤立的工作，只关注预定的交付成果和项目里程碑，而非解决最终用户需求或促进持续改进。

向以产品为中心的现代转型代表了数字领域战略和执行上的根本变化。与项目不同，产品被视为具有生命的实体，随着客户需求和市场趋势不断演变。这一转变与精益、敏捷和 DevOps 实践相一致，强调长期价值创造、跨职能协作以及对客户体验和反馈循环的持续关注。

这一转型促进了一个更具适应性和反应能力的组织文化，在这种文化中，团队能够迅速进行迭代和创新。以产品为中心的模型培养了团队的所有权感和责任感，因为团队在整个产品生命周期中都持续参与其中，从而带来更高的质量成果，并与业务目标更好地对齐。

引入以产品为导向的方法需要组织内部思维方式、流程和管理结构的根本转变。它与数字知识工作的需求更为契合，其中敏捷性、反应能力和持续改进是维持竞争优势的关键，尤其是在快速发展的数字市场中。

图 6.1对比了项目模型与产品模型在各个维度上的差异，突出了从传统的以交付为中心的方法向现代的以客户为中心的方法的转变。产品运营模型强调持续改进、适应性和客户满意度，代表了组织在数字知识工作方法上的重要转变：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_06_01.jpg

图 6.1 – 项目与产品运营模型比较

在实际操作中，从项目到产品的转变很少是一个二元切换，它可以在不同的时间、不同的方式和程度上发生。为了更好地与以产品为中心的运营模式和原则对接，考虑行为和运营模式在一个谱系上的差异是很有帮助的，如图 6.2所示。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_06_02.jpg

图 6.2 – 从项目到产品的谱系

在谱系的一端，行为与传统的项目管理范式对接；在另一端，行为则反映了现代的以产品为中心的理念。这个谱系最好呈现为一个渐变，因为组织可能处于不同的阶段，在采用新的实践和心态的过程中，从以项目为导向的行为转变为以产品为导向的行为。

评估项目中心行为

在以项目为中心的环境中，团队展现出一些独特的行为，塑造了他们的工作和协作方式：

• 固定范围强调：团队优先交付在预定约束下的具体输出，极为关注遵守原计划、预算和时间表。

• 临时团队：人员分配到项目中，项目完成后即解散。团队的组成在每个项目之间经常变化，可能导致知识延续性和团队动态的中断。

• 变革抗拒：变革常常被视为对项目范围、预算和时间表的威胁，从而导致僵化的变更控制流程，可能减缓适应的速度。

• 成功指标：成功是通过项目对预定规格、截止日期和预算的遵守情况来衡量的，而不是长期价值或客户满意度。

• 孤岛式工作流程：工作往往在部门或职能孤岛中进行，跨职能协作有限，通常会导致交接延迟并降低效率。

现在我们已经建立了对项目中心行为的共同理解，接下来我们将探讨这些行为如何在组织向以产品为中心的开发战略过渡时演变。

过渡行为

当组织向以产品为中心的开发战略过渡时，它们会表现出过渡性的行为，特点是优先级平衡、灵活的团队结构、对变化的开放态度、不断演化的成功指标和集成化的工作流程。让我们更详细地探讨这些行为。

• 平衡优先级：组织开始平衡交付特定项目产出的需求与理解对客户价值和战略目标的更广泛影响。

• 灵活的团队结构：更加注重稳定的跨职能团队，尽管它们仍然可能是项目驱动的。团队开始围绕能力和产品进行组建。

• 对 变化的开放性：变化的管理更加灵活，越来越多的理解表明，适应变化可以带来更好的结果。迭代方法，如敏捷，可能有助于此。

• 发展中的成功度量：虽然传统的项目度量仍然很重要，但越来越多地关注如客户反馈和市场影响等度量。

• 集成的 工作流程：开始打破壁垒，增加跨职能和工作阶段协作的重视。

在我们从以项目为中心向以产品为中心的行为过渡过程中，接下来我们将探讨向产品为中心的方法的变革性转变。在这里，团队优先考虑持续的价值交付，拥抱变化，并促进无缝的协作。

对比以产品为中心的行为

随着组织向以产品为中心的行为过渡，它们优先考虑持续的价值交付，拥抱变化，并促进无缝协作。例如，它们专注于实现由持续的、全面的产品焦点所要求的流程，如下所述。

• 客户和市场聚焦：团队主要专注于为客户持续交付价值，并响应市场变化。范围灵活，并根据反馈和洞察不断演变。

• 持久的 跨职能 团队：团队是稳定的、长期的，并围绕产品或服务进行组织。他们具备交付端到端价值所需的所有技能。

• 拥抱变化：变化被视为学习和改进的机会。团队基于现实世界的反馈迅速适应，采用如持续交付和部署等方法。

• 基于价值的成功度量：成功通过产品对市场的影响、客户满意度以及长期交付业务成果的能力来衡量。

• 无缝 协作：工作流程高度集成，强调在组织内各级和各职能之间的透明度、沟通和协作。

以产品为基础的组织处于不断发展的状态，从刚性的项目结构和行为转向更加动态、以产品为导向的模型，这些模型优先考虑敏捷性、客户价值和可持续增长。

让我们从宏观和微观两个层面来考察流程，以便更好地强调持续的、全面的产品焦点所要求的流程。

理解组织和个人层面的流程

在这一小节中，我们探讨如何通过识别流程中的制约因素，并采用约束理论、精益流动和度量等原则，系统性地解决这些挑战，从而实现更加高效和有效的工作流程与价值创造。解决这些挑战帮助我们以更少的资源取得更多成果，保持高质量标准，提供更高的客户价值，促进员工满意度，并加快交付。

在我们探索简化价值流的过程中，我们必须审视两个不同层次的流动：宏观 层面，涵盖组织的集体工作流程，以及微观 层面，侧重于个人员工的工作体验。

让我们仔细看看这些层面，以全面了解如何优化流动能够提升效率和满意度：

• 宏观 层面 (集体流动)：这个视角包括整个组织的工作流程，确保凝聚力和高效性。就像接力赛一样，这些流动涉及一个同步的跨组织流动，使工作能够在规划、开发、测试和部署的常规阶段迅速且高效地推进。这种宏观方法反映了精益流动原则如何在利用敏捷的迭代和增量规划过程的同时，提高生产力和效率，并促进价值流动中的适应性和演化。宏观层面有效地代表了我们价值流动的一个视角。

• 微观层面（个人流动）：在个人层面，流动与员工的工作体验相关。它涉及不间断的时间、深度专注的工作而不至于过度疲劳、对自己专业领域的专注，以及对认可的需求。个人流动通过挑战与技能之间的平衡来体现，这对在工作中获得快乐和满足至关重要，如图 6.3所示。

无论是宏观层面还是微观层面，流动都在关键的相互依赖中。提升组织内的流动应包括以下努力：

• 减少延迟

• 降低摩擦

• 增强参与度

• 提升绩效

在寻求改进时，人们常常倾向于关注宏观或微观方面。然而，必须同时考虑这两个方面，才能建立高效能的系统。在处理宏观层面时，必须衡量其对个体的影响，反之亦然。

在进一步探索优化价值流时，我们的下一步是识别流动中的障碍。这些挑战会阻碍工作，造成混乱，并降低生产力。通过识别最常见的流动中断类型，我们可以了解为何无意中形成了价值流。识别并消除这些障碍是必要的，因为它们会在流动未经过专门设计来避免时持续存在。

识别简化工作流程的障碍

使价值流动不受干扰是优化流动的第一步，因为当工作流程缺乏专门设计以解决这些问题时，障碍会持续存在。图 6.3描绘了典型的挑战，突出了它们如何阻碍产品和服务的高效交付：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_06_03.jpg

图 6.3 – 价值路径常常穿越一片充满挑战的迷宫

以下是流动中典型的障碍清单：

• 缺乏明确性：这会导致混乱和误导，浪费努力和资源，因为团队成员可能不理解目标或流程。

• 不明确的审批：不明确的审批会导致价值流中的延误和瓶颈，打乱了流程的顺畅流动。

• 频繁的交接：这会通过增加误沟通、延误和错误的可能性来打乱流程，导致低效并延长整体流程时间。

• 瓶颈 和 排队：任务排队等待先前活动完成，减缓了进度，降低了整体效率并增加了交付时间。

• 依赖关系：你可能会遇到一个情况，其中一个团队的工作被阻塞，而另一个团队的相关工作已完成。这些交接通常发生在责任、知识、协作和快速反馈存在空白时。

• 过多的 在制品 （WIP）：过多的 WIP 导致优先级和资源被重新调整，任务频繁切换，运营费用增加。它降低了生产力和吞吐量，并增加了新功能的等待时间。

• 返工：这是一种时间和资源的浪费，因为已完成的工作由于错误或需求变化需要重新做。

• 技术债务：推迟修复或解决已识别问题的成本，随着时间的推移，累计的捷径或不完整的解决方案需要后期修正，导致维护成本增加，敏捷性降低。

• 升级 和 中断：这些干扰了计划中的工作，常常需要立即处理，打乱了工作流程，导致项目延迟。

在下一个小节中，我们将探讨如何将工作与价值流对齐以克服这些障碍。

从流程的角度看待组织

消除传统层级结构带来的约束，提高了生产力和效率，使得跨职能部门的工作流程更加顺畅。梅尔文·康威博士在《Datamation》上的文章《委员会如何发明？》讨论了组织和技术设计之间的关系。他的结论是：“设计系统的组织（在这里使用的广义上）被限制在生产出与这些组织的沟通结构相似的设计。” 简而言之，一个系统的架构反映了设计它的组织的沟通结构。

康威定律在实践中是什么意思？“假设 ABC 保险公司的技术部门有三个主要工作组：一个专注于保险索赔，一个负责承保，第三个负责精算分析。康威定律预测你的系统设计将反映你的组织结构和沟通路径。反过来，这将为这三种能力提供独立的软件模块。每个模块可能有独特的架构、设计、基础设施和系统集成协议。团队结构对架构的影响通常被忽视。团队的组织设计应该与期望的技术架构保持一致，而不是反过来。”3

在传统的层级和基于领域的结构中，工作往往与这些孤立的团队和部门对齐。这妨碍了对价值在组织内部流动的可见性，使得识别瓶颈和低效成为挑战。此外，克服这些孤岛所需的额外跨部门和跨职能的流程会产生额外的处理浪费，意味着做更多的工作或增加更多的组件，以满足客户需求。图 6.4 展示了传统的层级组织结构：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_06_04.jpg

图 6.4 – 孤立的组织结构

传统的组织结构通常基于职能或领域，这导致了孤立的流程，阻碍了工作流，并在职能和部门操作中增加了复杂性。因此，组织通常需要额外的流程和系统来促进跨部门的工作流。

为了打破这些传统结构并采纳价值流的视角，组织可以简化流程、增强协作并提高效率。然而，这意味着忽视传统层级模型的教条，将其作为唯一的工作组织方式。在许多情况下，根据组织的产品和服务流对资源进行对齐会更加合理，逆向思考，从你希望实现的客户成果出发。我们将在客户旅程的背景下展示一个例子。

组织必须摒弃传统结构，明确朝着价值创造的方向前进。这需要审视跨越部门界限的价值流动。组织的结构刚性通常会阻碍价值顺畅传递所需的流动性，因为工作流常常被隔离和孤立的实践所阻碍。为了解决这个问题，首先要概念化你的价值流，然后将其叠加到传统的层级模型上。

在图 6.5中，突出显示的线条显示了价值如何在传统层级中流动。如你所见，单一的职能或部门无法独立交付产品或服务：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_06_05.jpg

图 6.5 – 重叠的价值流动

该图展示了跨职能部门（如产品管理、架构、专业团队、开发、客户成功、市场营销、法律等）的实际工作流程。

当你在组织中绘制工作流程时，会发现显著的浪费和低效。然而，当我们扁平化这种层级并将流动可视化为从概念到价值交付的路径时，价值流将顺畅无阻。

图 6.6强调了简化跨业务功能流动的重要性。毕竟，直线始终是通往目标的最短路径：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_06_06.jpg

图 6.6 – 有限的可见性使得约束保持隐藏

在第八章，《实施基础精益-敏捷解决方案团队（BLAST）》中，我们深入探讨了解决模糊前端的策略，在信息不足的情况下，我们必须主动构建产品积压。同时，许多下游问题源于上游未解决的看不见的问题。价值流的效率不仅由其下游的自动化、集成和同步决定。它的有效性还依赖于新工作持续涌入并得到充分细化。如果没有这一点，我们的精简价值流可能会变得未充分利用。

价值流 – 在软件交付中拥抱持续改进

在软件开发中，采用价值流思维和组织结构有助于持续改进。图 6.7展示了一个简化的软件交付价值流，从概念到支持：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/Figure_6.7_-_Software_development_life_cycle.jpg

图 6.7 – 软件开发生命周期

如图 6.7所示的软件开发生命周期是单一价值流中工作流动的简化表示。利用价值流的总体目标是实现对交付客户价值的离散工作流程的全面理解和最终设计。这种视角有助于识别系统级别的潜在流程瓶颈，促进更明智的决策，优化资源，并避免局部优化。在第七章中，我们将进一步定义组织层级中相互关联的价值流网络。

通过识别和优化价值流，团队可以解决低效问题并优先考虑客户满意度。这突显了价值流在提升软件交付实践中的重要性，为深入探讨优化软件开发工作流程以获得更好结果奠定基础。

一旦超越了将贡献者聚集在一起进行有限工作努力的传统项目模型，提升绩效就成为一种常规且至关重要的追求。产品和服务交付的价值流为运用精益敏捷实践来改善绩效提供了有效的结构。此外，产品和服务的组合通过一个价值流网络进行交付，这些价值流可以被有效地映射、衡量并有意设计以实现最佳绩效。

对于长期存在且不断发展的产品和服务的投资，需要通过这些价值流持续地衡量和完善其绩效。它提倡使用衡量效率、质量和客户满足度的指标，以推动持续改进。这一策略在从传统项目方法转向精益产品软件开发方法的过程中尤为重要，后者更加注重持续向客户交付价值，而非仅仅完成单一项目。

创建价值路径——理解和识别价值流

在一个组织内部，存在着一个复杂的价值流网络，每一个都充当着向内部和外部客户传递价值的重要渠道。识别这些价值流至关重要，但对于那些对这一概念不熟悉或正在向价值导向框架转型的组织来说，这可能是一个复杂的任务。

为了揭示这些价值流，从客户成果入手，理解哪些成果代表了组织的成功。客户成果不仅仅是客户满意度的概念，它识别了所提供的具体价值，例如某个功能的使用、获取新客户或完成销售。

考虑销售过程，这是一个内部价值流，反映了客户在评估其业务或用户需求、审视竞争对手的产品，并做出明智购买决策时的旅程。这个过程经历了可变的交付时间，受到客户产品评价、竞争性价值分析和购买流程等因素的影响。尽管本质上是操作性的，面向销售的价值流依然具有适应性，并且通过将敏捷方法应用于组织的 CRM 工具、销售流程、售前角色、竞争和客户信息的可获取性以及产品功能等方面，保持开放和持续改进。

在前一小节中，我们强调了将价值流叠加到组织结构中的重要性，这有助于更好地理解工作流。但我们如何定义价值流呢？发现价值流的过程是从客户成果出发，逆向追溯到实现该成果的过程和决策。这一逆向过程通常会揭示出流程的源头，可能是客户需求、利益相关者的需求，或是来自其他价值流的输出。

通过首先定义客户需求来启动我们的价值流设计，确保我们在整个过程中始终与客户的需求保持一致。当我们逆向绘制客户交付的旅程，沿着价值流向上回溯到最初的订单时，我们不断询问每个价值流阶段必须交付的信息以及其他产品或服务组件。这种迭代的方法一步一步引导我们，最终带领我们回到最初的客户订单或请求的起点。它为我们触发价值流动提供了一个以客户为中心的基础。

在优化我们的软件交付流程时，我们通过软件开发生命周期（SDLC）的每个阶段逆向操作。我们的目标是确保每个阶段都与以客户为中心的价值流设计原则无缝集成和对齐。为此，我们结合了价值流的关键要素：人员、流程、信息和技术。当我们从支持部门逆向回溯到概念或最初的订单/请求时——我们将定义那些有助于构建强大且高效的软件开发过程的关键组件。

这种逆向探索价值流的流程并不仅限于软件交付流程。所有价值流都需要以这种方式进行评估，以便做出明智的改进。理想情况下，软件交付团队应参与这些评估，评估软件增强功能如何改进目标价值流。

一旦识别出价值流，它们就成为组织可以优化的具体元素，从而改进价值交付。它们是可操作的途径，企业可以通过这些途径控制客户互动，将其转化为可靠且令人满意的体验，从而推动组织的成功。

通过绘制这些价值流，组织不仅能够洞察其运营现状，还为有针对性的改进奠定了基础，从而优化价值流动。拥抱这种方法可以促进持续改进，增强每个流并放大客户价值。

绘制通往价值的路径——识别价值流

在一个组织中识别价值流就像是在复杂的景观中绘制一条路线。它从确定目的地开始——我们称之为目标成果。这是价值被客户感知和实现的高峰。为了到达这一高峰，必须考虑所提供的产品或服务以及客户与这些产品或服务互动的旅程。

图 6.8 显示了三个潜在的起始点：目标成果、特定产品/服务或客户旅程：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_06_08.jpg

图 6.8 - 识别价值流

要真正映射出价值流，我们必须深入探讨那些剖析我们产品和服务交付机制的问题。提出一些关键问题是至关重要的：如何传递价值？我们如何衡量它？什么触发了新一轮交付的开始？关键的价值流指标是什么？交付后我们如何衡量成功？通过回答这些问题，价值流开始显现，揭示的不仅仅是价值的流动，还有那些可能妨碍其进展的障碍、摩擦点和挑战。

考虑你的目标、计划和目标框架为这次探索提供了背景。这个背景至关重要——它为价值流提供了视角，将其与单纯的流程区分开来，赋予了它朝向交付结果的有目的的方向。

产品和服务充当承载价值的载体，其选择可以作为理解相关价值流的切入点。无论是查看一个全面的产品目录，还是聚焦于一个特定的产品，目标始终是映射从客户到其创造源头的路径。

客户旅程涵盖了客户从初次意识到购买后的互动与体验。映射这一旅程揭示了组织与客户互动的触点，影响他们的体验，并提供增强价值交付的机会。通过追溯这些触点，我们揭示了潜在的价值流。

当这些元素——目标结果、产品与服务以及客户旅程——一同被考虑时，一个更加清晰的画面开始形成。流动变得可见，从创造源头到客户互动的点。正是在这些流中，我们可以进行导航、优化和创新，确保性能改进之旅尽可能顺畅且富有成效。

在接下来的子章节中，你将获得关于价值流映射中涉及的关键角色和职责的宝贵见解。我们将特别探讨在移动应用项目的背景下，每个关键参与者如何贡献于映射工作的成功，他们的集体专业知识如何被运用来优化价值流并提升运营效率。

流程映射

价值流 映射（VS 映射）是业务流程改进中的一项战略性练习，对于可视化物料和信息流动以及在产品或服务的创建与交付过程中起着至关重要的作用。角色与职责的清晰性对于 VSM 的成功至关重要，如 图 6.9 所示，图中概述了移动应用项目中 VSM 工作的关键参与者。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_06_09.jpg

图 6.9 – 价值流映射中的角色

在下面的价值流映射角色列表中，我们介绍了参与价值流映射的关键角色。每个角色在可视化和改善材料、信息及工作流动方面起着独特作用，尤其是在产品或服务的创建和交付过程中。这些角色是任何跨职能、端到端改进工作流和价值交付的关键贡献者：

• VSM 促进者：促进者是价值流映射（VSM）计划的核心，负责引导团队完成映射过程。此人确保映射活动按步骤进行，鼓励参与，并确保所有声音都被听到并记录。促进者可能是分配来支持价值流的价值流负责人，或者是精益导向的价值流映射实践的外部专家。

• 执行 赞助人：执行赞助人为 VSM 计划提供指示和授权。他们的角色是确保资源的提供、克服组织的抵抗，并授权团队获得执行映射和随后的改进计划所需的权力。

• 产品 负责人、 UI/UX 设计师、 开发者、 质量 保证 （QA）、 和 测试人员：这些职能角色提供他们的视角，作为贡献者来确认和量化工作流中发生的事情，它是如何表现的，在哪里存在问题和机会。

每个工作流的步骤，从最终结果开始，逆向回溯至起点，都被映射、分析并优化，以确保价值流尽可能精简高效，最小化浪费，最大化客户价值。

通过 VSM，充分发挥这些角色的集体专业知识，分析和理解端到端流程，识别低效之处，并改进价值流。这一协作努力在创造不仅能满足客户期望，同时又有助于提升组织竞争力和运营卓越性方面起着至关重要的作用。

检查效率和效果

在我们映射和检查价值流时，必须同时考虑价值流的效率和效果，如图 6.10所示。这些结果可能涉及多个方面，如简化的工作流、改善的客户体验、价值交付、财务绩效以及对组织结果的影响。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_06_10.jpg

图 6.10 – 工作流与价值实现对比

一方面，我们关注效率，即关注内部流程的表现。诸如流动速率、交付频率、价值流中的浪费以及正在进行的工作类型等输出，是衡量价值流健康状况的关键指标。这些指标对于评估内部流程的运行状况以及价值通过价值流的交付效率至关重要。

转向效能时，重点转向业务结果，特别是在客户体验方面。在这里，结果是最重要的。例如：客户积极使用平台功能、新客户的获取速度、客户对其体验的直接反馈，以及价值流的财务健康状况，都是衡量组织如何有效地为客户和利益相关者提供价值的重要指标。

重要的是保持简化工作流与加速业务结果之间的平衡。仅仅在内部效率上做得好是不够的；组织还必须确保这种效率转化为客户能感受到并欣赏的现实世界效能。这种平衡是一个蓬勃发展的价值流的基石，最终也是成功业务的基础。

在价值流中平衡创新与效率

图 6.11 展示了分类和影响组织价值流的一个关键维度：创新与运营效率之间的平衡。它强调了认识到每个价值流在这个光谱上的位置的重要性，从专注于颠覆性创新到承诺稳定和效率：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_06_11.jpg

图 6.11 – 绩效聚焦的光谱

对效能和创新的追求

在光谱的一端，如图 6.12左侧所示，我们有交付独特且新颖的产品和服务的价值流，这些产品和服务将组织的产品与竞争对手的产品区分开来。这里是创新和颠覆的诞生地：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_06_12.jpg

图 6.12 – 可以绘制流以将它们置于相对的背景中

这些是组织积极寻求开辟新天地的领域，通常具有新的能力、实验和探索新实践的特点。这里的重点是通过创新创造价值，并拥抱变化，以保持领先于市场趋势。

对效率和稳定性的追求

相反，在光谱的另一端，我们发现诸如账单、基础设施服务、薪资和人力资源等流程。这些是成熟的、高度商品化的实践，优先考虑效率、稳定性和可预测性。在这些领域，目标是精细化和优化，通过运营成本效率减少变异并提高利润率。这些价值流是成熟、发展良好的领域，其中一致性和安全性至关重要，重点是通过标准化最大化盈利能力。在极端情况下，它们可能已如此商品化和标准化，以至于作为外包能力最为有利。

价值流的动态特性

这里特别值得注意的是，价值流并非静态的。它们可能随着时间的推移在这个光谱上发生位置变化，可能是通过故意的战略重新定位，或者是响应不断变化的市场和内部条件。认识到价值流可以在关注创新和效率之间转换，为战略管理和有意识的变革开辟了新的可能性。

组织维度的影响

这个光谱具有深远的影响，涉及创造力、探索、运营管理和资源分配。它影响着领导力的方式、对技术的投资以及流程开发的方向。理解一个价值流在这一连续体上的位置对于将组织努力与更广泛的战略目标对齐至关重要。

情境化绩效焦点

从本质上讲，这种可视化是一种战略工具，帮助领导者理解并引导其组织内部价值流的演变。它为如何营造一个创新得以蓬勃发展的环境提供了洞察，同时不会牺牲长期成功所需的运营卓越。

使用 FinOps 和账单作为该光谱上的代表点，有助于情境化价值流的多样性。虽然 FinOps 可能位于创新端——持续适应和演变，而账单通常位于运营效率端——强调可靠性和成本效益。

利用这个光谱，你可以讨论将一个价值流推进到某个极端可能意味着什么，以及哪些目标和行为可能促成这一变化。在接下来的章节中，我们将讨论如何通过目标、指标和衡量标准推动这一变化。此外，在接下来的章节中，我们还将展示这种对学习的深度承诺。在这里，工作流程更加实验性，光谱构成了将组织作为网络进行映射的基础，并且有助于理解你的价值流网络图的战略性和战术性影响。

在价值流中取得平衡——从学习到结果

在探索组织内的战略动态时，可以考虑一个从**学习流（探索）到结果流（利用）**的连续体，如图 6.13所示：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_06_13.jpg

图 6.13 – 从学习流到结果流的光谱

在这一连续体的左端是创新和有效性的领域，其特点是对学习的深度承诺。在这里，工作流程更具实验性、探索性，且往往具有颠覆性。这是一个随着时间的推移培养和孵化想法的环境，获得突破性创新的接受被视为一个理想的结果。重点是创造长期价值，而非立即的回报。这种方法可能更耗时，并且不太注重即时效率，但其转型性成果的潜力足以证明在学习和实验上的投入是值得的。

在光谱的右侧，重点变成了效率和可持续交付——即成果的流动。在这里，强调的是交付速度、可预测性和一致性。在这个端点运作的价值流通常管理着一堆大部分是统一任务的积压，这些任务需要以高效和高效的方式处理。主要目标是降低成本并优化流程，以最大化输出。此外，提高利润的能力更为受限，因为在不引入新的创新或颠覆性方法的情况下，现有流程的优化有其极限。

精炼流程——进展问题

另一个需要考虑的关键点是，图 6.11到6.13强调了一个基本原则：流动在这个二维框架中所处的坐标直接取决于它所做的事情、优先级和衡量标准。然而，这些图并没有展示在考虑优先级和衡量标准结果后，流动可能会发生的变化。要改变一个流动，团队需要调整其优先级和衡量标准。因此，我们不仅能看到当前的活动流动，还能通过定义驱动行为变化的目标变更，看到未来状态的流动。

引用《目标》一书的作者、约束理论的创始人艾利亚胡·M·戈德拉特（Eliyahu M. Goldratt）的教义，可以说“一个组织选择衡量的元素必然与其成就对齐。”他常被引用的话是：“告诉我你如何衡量我，我就告诉你我如何表现。”换句话说，你的结果是你上游衡量的下游效应。这是因为衡量行为不仅仅是记录数据——它聚焦了注意力和资源，决定了组织将实际执行什么。

因此，有了这些信息，我们可以回答关于指标和衡量标准价值的问题：

• 为什么指标和衡量标准很重要？

  理解度量和衡量对组织定位的影响不仅仅是一个学术练习；它对任何业务领域的实际进展至关重要。之所以重要，是因为我们优先考虑的度量标准就是引领我们共同努力的舵，它们塑造了我们的决策过程，影响了资源分配，并最终定义了我们的成功标准。

• 我们如何更频繁地发布？

  为了提高发布的频率，我们应该关注发布机制的效率。通过衡量交付时间以及自动化过程与手动干预的比例，我们可以识别瓶颈。追踪约束的影响和团队之间的交接可以揭示低效之处，并为创新提供空间。

• 我们如何改变工作方式？

  有效改变工作方式需要改变衡量标准。通过设定新的绩效指标，我们影响行为并重塑运营模型。团队的关注点自然会转向这些新的度量标准，推动他们调整方法并创新实践。

• 如果我们想要改变[变量]怎么办？

  如果在特定领域希望进行更改，该领域在问题中标注为“[变量]”，首先要识别能够触发该领域变更的相关度量标准。衡量当前状态，为理想状态设定目标，并监控与这些度量标准的进展。这种结构化的变革方法可以催化行为、工作流，最终促使结果的变化。

通过重新审视我们衡量的内容，我们不仅仅是在仪表盘上更改数字；我们还激发了一种变革文化，这种文化渗透到我们组织实践的各个层面，改变了我们的运营、创新和增长方式。因此，衡量行为不仅仅是一个反思工具，而是一个塑造工具——它塑造了我们走向理想目标的路径。

现在让我们来介绍优化价值流的五个步骤。

优化价值流

在第四章中介绍的 E9 VSM 方法提供了一种稳健的方法来进行 VSM 参与。但是为了本章的目的，我们可以简化它。例如，图 6.14呈现了价值流管理的简化视图，概括了优化业务流程的基本步骤：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_06_14.jpg

图 6.14 – 价值流管理流程

五个关键步骤的目标是：

• 明确 你的 目标：建立一个清晰的目标，确保你的价值流努力旨在实现这一目标。这将为所有后续的行动和决策指明方向。

• 识别流和贡献者：确定与目标对齐的具体价值流，并识别影响价值流的贡献者。

• 评估 当前 状态：评估你当前价值流的状况，以了解你与目标之间的差距。

• 发现 并 衡量 关键 瓶颈：识别并量化制约你价值流的瓶颈。了解这些瓶颈对于优先改进工作至关重要。

• 利用 能力 解决 瓶颈：利用现有的能力来解决瓶颈，从而提升你的价值流的绩效和效率。

这种价值流管理方法有助于制定一个集中的、有效的流程改进策略，确保努力与预期结果保持一致。但我们仍然需要牢记，为什么要执行这五个步骤来精简价值交付。

精简价值交付

穿越价值流管理的复杂性需要聚焦于几个关键因素，这些因素确保价值能顺畅且动态地流向客户：

• 交付聚焦：核心重点在于可持续的价值交付。这不仅仅是规划或勾画价值流，而是将其高效地操作化和执行。

• 支持 价值 流的 拓扑结构：一个明确定义的团队拓扑结构是成功价值流的基础。多个团队在网络中的互动促成了一个全面的、互联的系统，推动了价值交付的前进。

• 设定新目标：转变绩效焦点需要设定新的目标和基准。通过改变衡量标准和期望，价值流中的行为和结果会朝着预期的变化方向转变。

• 可视化组织内的流动：理解并观察价值流动不仅在局部区域，而是跨越整个组织结构至关重要。这样广阔的视角对于价值流管理的整体方法至关重要，确保组织各个部分都对价值流的推进做出贡献。

现在我们已经探讨了检查、完善和优化价值流操作的各种策略，接下来要定义的最后一个维度是我们的价值流在组织中的位置——即演变。

管理价值流的演变

在本节中，我们展示了如何绘制价值流动的动态，并探讨了优化其性能的策略。通过绘制价值流，组织能够清晰地了解改进的机会。

具体来说，我们继续研究客户接近度和操作焦点这两个维度。通过这个二维的价值流网络，我们揭示了组织活动的复杂相互作用。这个网络视图使领导者能够确定每个价值流相对于其战略重要性和操作重点的位置。

我们还探讨了价值流在客户可见性和运营重点方面的变化，从以客户为中心、面向前端的元素（如移动银行）到高效但客户可见性较低的流程（如账单）。这种映射不仅仅是静态表示；它是一个动态模型，反映了价值流的流动性。

最后，我们将研究一个领域的变化如何通过网络传播，影响相邻的流。无论是创新的金融运营（FinOps）的引入，平台的自动化，还是故意战略性地重新定位价值流，每个连接点都代表着一个决策点，在这里必须平衡创新和效率之间的关系。理解这些相互联系的动态，对于战略灵活性、将内部流程与组织目标对齐，以及为客户和组织提供价值至关重要。

我们将从讨论价值流映射如何帮助组织将以客户为中心的创新与运营效率对齐开始，引导战略决策，确保运营的一致性和高效性。

同步核心和支持性工作流

在本小节中，我们继续使用移动应用案例，展示外部面向的核心价值流过程如何转化为支持内部客户的支持价值流。在这里，我们会发现，依据需要操作或开发支持的活动，可以创建许多支持价值流来协助核心流程。

图 6.15 展示了我们组织工作流中核心流与支持流之间的相互作用。它描绘了标准开发价值流过程中工作的流动。虚线提供了关于在哪些地方可以提高效率以及在哪些地方可能会有工作分散的可见性。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_06_15.jpg

图 6.15 – 核心流与支持流

核心流直接与外部客户互动，交付定义我们市场存在的最终产品或服务。这些流通过移动应用流程图展示，包括规划、设计、开发、测试、交付和启用阶段。核心流与最终用户的接近度是一个基本概念，它表明交付成果与客户的需求和期望密切对接。

相反，支持流主要在内部运作，提供支持核心流所需的关键能力。这些支持流，如设计平台和安全平台，经历类似的流程，确保它们开发的能力是强大的，并与核心流的总体目标对齐。这些平台经历规划到启用的各个阶段，确保对内部服务提供有结构化且彻底的处理。

例如，设计平台可能提供增强开发阶段的工具和框架，而安全平台则为移动应用的测试和交付阶段提供至关重要的安全协议和基础设施。这种共生关系对于内部客户满意度以及保持流畅的工作流程至关重要。

核心流和支持流之间的整合凸显了组织对内部协同的关注，最终目标是实现外部客户交付的高效性和有效性。通过将内部能力与外部需求对接，组织确保了满足内外部客户的需求，促进了一个强大、灵活且敏捷的运营模式。

在下一个小节中，我们将进入一个未来时代，在这个时代里，我们的工作日叙事将从反应转向创造。精益-敏捷团队发展成由自治、精通和目标驱动的生态系统，更加注重持续的、以客户为中心的交付。

从职能转向流对齐的协同效应

在这个数字时代，成功不仅仅是完成任务；它现在是通过交付的价值来衡量的。CI/CD 和 DevOps 平台使团队及其成员成为精益-敏捷的贡献者和创造者。随着我们向前迈进，我们的使命不仅仅是软件产品开发，而是为客户和团队创造体验，将敏捷性、创新性和以客户为中心的理念无缝地融入到我们的组织 DNA 中。

授权转型：与平台团队一起协调变革

在从传统 IT 职能到精简价值流的变革过程中，推动变革的关键因素之一是平台团队的出现。这些专业化的团队代表了组织如何看待软件开发的范式转变。他们充当效率的架构师，将工具、服务和能力编织在一起，帮助开发团队在依赖关系和低效的动荡海洋中航行。

在上述背景下，平台团队指的是组织内部专门负责开发和维护共享平台、工具和能力的团队，这些平台、工具和能力使其他开发团队能够更加高效和有效地工作。平台团队负责创建一系列服务和资源，从而简化和优化组织中其他价值流团队的开发过程。

平台团队：

软件交付组织中的专业化团队，负责开发和维护支持高效开发、部署和操作应用程序的基础设施、工具和服务。

平台团队的主要特点包括以下几点：

• 自服务：平台团队提供自服务访问其工具和资源，使其他团队能够在无需大量人工干预或支持的情况下使用它们。

• 工具 和 能力：他们提供一系列工具、库和基础设施组件，帮助开发团队自动化任务、遵循最佳实践并加速开发周期。

• 响应性：平台团队响应内部客户（其他开发团队）的需求，并与他们密切合作，理解他们的要求和痛点。

• 标准化：他们在组织内部建立并维护标准化的实践和模式，确保一致性并减少复杂性。

• 可扩展性：平台团队设计他们的服务交付解决方案，以支持可扩展性，适应各种开发团队和项目的需求。

• 持续改进：他们根据反馈和不断变化的技术环境，持续演化和改进他们的产品。

从本质上讲，平台团队充当使能者，提供基础设施和工具，使其他团队能够专注于其核心目标，如开发软件产品，同时最小化常见的运营挑战和依赖关系。这种方法促进了敏捷性，加速了开发，并提高了组织的整体效率。

随着精益敏捷团队和个人在变化的浪潮中航行，他们见证了一场深刻的变革。这一过程的特点是，从一个因依赖关系而沉重的结构，过渡到一个倡导流动性和自治的结构。让我们来看一下这种转型的进程。

通过精简努力来管理依赖关系

改进工作往往始于安装使用 Scrum 的敏捷软件开发团队，这些团队常常纠缠于复杂子系统的网络中。他们的工作日常被相互依赖的拉锯战打断，进步的追求与低效的惯性相对抗。

那是一个充满颠覆的时代，进步在层级约束的障碍面前踉跄而行。软件开发团队整合工具、系统和过程自动化，以解决企业内普遍存在的问题，并发现这些能力在其自己的 IT 领域中同样具有重要价值。

通过平台赋能提升团队能力

从比喻角度来看，变革的风带来了平台团队的概念，类似于架设桥梁的建筑师，跨越混乱的深渊。这些平台作为自服务的使能者，提供了将管道交付障碍转化为通道的工具和能力。曾经被依赖关系的不可预测潮汐所困扰的流水线对接团队，现在找到了节奏，一种与持续交付共鸣的和谐流动。

流水线对接团队：

软件开发中的跨职能团队围绕特定的价值流或客户旅程进行组织，负责某一特定方面的产品或服务的端到端交付和持续改进，确保与业务目标和客户需求的一致性。

图 6*.16* 展示了我们从孤立的、基于职能的操作转变为以客户为中心的价值流的过渡。它突出了从通常跨多个系统运作的敏捷团队结构，到流对齐团队的转型。这些流对齐团队在标准化的自助开发环境中工作，便于与价值流的无缝集成。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_06_16.jpg

图 6.16 – 从职能到流的转变

为了更好地理解图 6**.16中详细描述的结构演变，让我们来分析这一转型团队拓扑框架中的不同角色和关系：

• Scrum 团队：传统上，Scrum 团队专注于特定功能或产品，通常在孤岛式的环境中工作。它们管理复杂的子系统，如与复杂子系统团队的关联所示，突出它们在处理复杂系统细节方面的角色。

• 复杂 子系统 团队：这些团队是专注于复杂系统组件的专家，要求具备深入的知识和专业技能。由于它们与 Scrum 团队紧密相关，表明它们提供专业支持，强调了传统结构的分层性质。然而，通常它们会支持多个 Scrum 团队，并因此常常处于超负荷、被打断和分心的状态，这会导致工作流的延迟。

复杂子系统团队：

专注于复杂技术子系统的软件开发专业团队，要求具备深厚的专业知识，负责设计、维护和优化复杂的组件或服务，这些组件或服务与系统的其他部分进行集成。

• 流对齐团队：作为从职能到流演变的推动力，这些团队与端到端的价值流对齐，确保工作流直接贡献于客户价值。它们在由支持平台提供的自助能力推动的持续交付框架中运作。这样的松耦合和按需支持使得工作流能够更加连续地进行。

• 平台团队：负责平台的开发和维护，该团队为流对齐的团队提供自助工具。例如，为内部流对齐团队开发和提供平台，作为内部客户的供应商，旨在提供一致且不中断的工作流，弥补可能会破坏客户价值交付的空白。

本节突出了软件开发中的重大范式转变，从传统 Scrum 团队需要在紧密耦合的群体之间进行极度协调的孤立方式，转变为更加集成和流动的价值流导向。它阐明了平台团队和平台在帮助流对齐团队提供持续客户价值方面的关键作用，绕过了曾经阻碍进展的复杂子系统和依赖关系。这一演变标志着从早期框架的碎片化职能向统一的、以客户为中心的价值流模型的过渡。

延续流对齐范式，我们现在更深入地探讨软件组织如何培养一个以客户为中心的、持续交付的环境。

培养持续交付和以客户为中心的思维

在培养持续交付和以客户为中心的过程中，我们必须将日常任务从被动反应转变为主动创造。这种转变使我们的团队逐步成长为具有强大自主性、掌控力和目标感的动态生态系统。这一演变不仅提升了我们的软件交付过程，还重新塑造了我们的成功标准，使其与我们为客户创造的真正价值对齐。

在建立流对齐平台后，我们的工作日发生了深刻的变化，逐步从被动应对转向根植于主动创造的模式。团队不再仅仅是个人的集合，而是转变为由我们基本原则引导的蓬勃发展的生态系统。我们的焦点变得更加清晰，不仅仅关注交付的过程，更注重交付的艺术——持续性、一致性，以及对客户不断变化需求的深刻理解。

在这个新时代，成功的衡量标准不再仅仅是任务的完成，而是所交付的价值。支撑我们团队的平台不仅仅是工具；它们是愿景的推动者，在这个愿景中，每个团队成员都成为贡献者和创造者，每个产品都是组织在效率、稳定性和客户满意度方面承诺的见证。

随着我们不断重新调整、重新校准并重新构思我们的运营模式，我们不仅在构建产品——我们在打造体验，无论是为客户还是为我们的团队。这就是我们组织 DNA 的新蓝图，它将敏捷性的织物与创新和客户中心思想的线条编织在一起。

总结

本章深入探讨了在组织内定义和优化价值流的复杂性，这对在快速变化的商业环境中保持竞争力和客户关注至关重要。它强调了当今企业所需的两个重要转变：从项目导向转向产品导向，以及利用数字技术提升流程和产品。它介绍了价值流运营模型的概念，提供了一个全面的价值创造和交付视角，整合了组织中的人员、流程、信息和能力。

我们讨论了组织和个人流动性的追求，识别了优化工作流程的障碍，并强调了从流动的角度看待组织，以促进效率和生产力。我们提到传统的组织结构，通常是孤立的，可能会妨碍工作流程，并建议采用价值流视角来增强协作和效率。我们探讨了映射价值流在软件交付中的持续改进的重要性，识别和解决低效和瓶颈。我们还讨论了如何平衡创新与效率，强调组织在这两者之间战略性地导航的必要性。

此外，本章提出了优化价值流的策略，包括明确目标、识别贡献者、评估当前状态、发现并解决关键瓶颈，同时利用能力提升价值流绩效。在下一章中，我们将探讨在二维平面上绘制价值流网络的概念，这将帮助我们全面理解整个过程与客户旅程的关系。

问题

本节提供给那些希望评估本章所提供信息的理解和记忆的读者。有三个问题。回忆原文的准确措辞并不重要，重要的是回忆这些概念及其应用。

1. 在价值流映射和分析的背景下，如何将内部流程与客户旅程的各个阶段对齐，有助于更有效的客户互动和产品开发？

2. 在移动应用项目的价值流映射（VSM）中，关键角色是什么？它们如何推动项目整体成功？

3. 在价值流运营中，平衡效率与效能的重要性是什么？这种平衡如何影响组织的成功？

回答

1. 在价值流映射与分析的背景下，将内部流程与客户旅程对齐对于有效的客户参与和产品开发至关重要。这种对齐确保了客户体验的每一个环节，从最初的好奇心到购买后的评价，都能得到相应的内部价值流支持，如营销活动和产品开发。通过将这些价值流映射到客户旅程中，组织能够有效地引导客户完成每个步骤，确保无缝且富有吸引力的生命周期体验。

2. 在针对移动应用项目的价值流映射中，关键角色包括引导员、执行赞助人、设计团队、开发团队、质量保证团队和产品团队。引导员负责指导映射过程，确保各方参与。执行赞助人提供资源和支持。设计团队确保以用户为中心，并与客户需求对接，而开发团队则负责构建产品。质量保证团队在各个阶段评估质量。产品团队则确保项目与业务目标的一致性。

3. 在价值流操作中平衡效率与效果的意义对于将内部能力转化为客户利益至关重要。效率优化内部流程，通过工作流速率和交付频率来衡量，而效果则关注客户的结果，如平台使用情况、客户获取率和反馈。这种平衡确保了内部优化能够提升客户体验，推动持续的成功和竞争优势。

进一步阅读

1. Kersten, M. (2018). 《从项目到产品：如何在数字颠覆时代利用流动框架生存与发展》. IT Revolution Press.

2. Conway, M. E. (1968). 《委员会如何发明？》Datamation, 14(4), 28–31.

3. Knaster, Richard. 《数字时代的价值流管理》. 2021.

第七章：连接价值流网络

“今天的成功不仅仅是生存变化，而是引领变化。” – 彼得·德鲁克

想象一下你的组织是一个庞大的通信网络，协调从初步构想到最终成果的工作、信息和资源，从请求到交付。作为商业和 IT 专业人士，你的成功取决于如何高效地管理这些复杂的流程，以支持客户旅程并推动业务成果。你如何确保这些流程在整个组织中顺畅运行？

管理这些不同工作的部分需要的不仅仅是单一的价值流——它需要跨多个与客户需求对齐的价值流的协调努力。

价值流网络（VSNs）是你组织内部互联的路径，战略性地对齐以交付整体价值。VSNs 展示了工作项如何在多个价值流中流动，同时支持服务于我们的业务、利益相关者和客户需求的更广泛网络。

工作和信息在这个网络中的无缝流动，最大化了通过产品和服务交付的价值。然而，这些相互连接的部分可能带来复杂性、约束和潜在的浪费，需要有效管理。网络创造价值的能力取决于保持可靠、可扩展和高效的运营。

即使单个价值流经过优化，它们的相互连接和不断演变也会带来复杂性。本章将介绍管理这些复杂性的策略。

一个 VSN 在一定程度上可以在没有可视化和衡量的情况下运作。然而，若没有价值流网络的可视化表示，组织将难以改善工作流程，并可能冒着本地优化带来不良副作用的风险。

本章涵盖以下主题：

• 管理和优化价值流网络

• 可视化组织工作流程

• 指导价值流战略和投资

• 发展价值流网络

管理和优化价值流网络

价值流网络，正如米克·科斯顿在他的书《从项目到产品》中定义的那样，指的是一种全面的方法，捕捉并分析工作在组织内的流动。价值流网络通过展示人员、流程、信息和技术如何整合以优化客户价值交付，提供了组织的整体视图。这种方法帮助从基于项目的思维方式转变为以产品为中心、以客户为核心的视角。

价值流网络（VSNs）促进了团队和流程之间的协作，确保整个组织中高效的价值交付。它们的核心作用是促进从创意到交付的价值进程，包括各种团队之间的互动、交接和依赖关系。例如，当你在线订购一件产品时，从设计、开发到履行和市场营销的多个团队将协作，确保产品顺利交付。

价值流网络具有动态响应性，会根据软件更新、市场变化和预算调整不断演变，因此需要持续的适应性才能保持有效性。借鉴类似图论的原理，图论研究网络中点（节点）之间的连接（边），它们在团队之间穿行，提供超越传统层级组织图的见解。

理解价值流网络对于掌握推动组织效率和价值交付的复杂网络至关重要。它超越了组织结构图，提供了对想法如何转化为实际成果的更深刻理解。

在价值流网络中整合多个价值流服务于几个关键目标：

• 端到端可见性和协调：组织能够全面了解工作和信息如何在不同部门、职能和流程中流动，从而提高朝着共同商业目标的协调性

• 价值交付优化：通过识别和消除低效，组织优化了向客户交付价值的速度和效率

• 跨职能协作：价值流网络促进不同团队之间的协作，打破部门壁垒，改善问题解决能力和创新

• 持续改进：支持持续改进文化，组织分析流程、收集见解并实施变化，以提高绩效并适应市场需求

• 以客户为中心：整合价值流有助于组织将活动与客户需求对齐，从而提高客户满意度和忠诚度

虽然通常与软件开发中的精益敏捷方法学相关联，但价值流网络（VSN）原则广泛适用于采用精益价值流概念的各个行业：

• 制造业：优化物料流和生产过程

• 医疗保健：简化患者护理和支付方流程，以获得更好的结果

• 供应链管理：增强库存管理和响应能力

• 服务行业：改善客户服务流程和客户满意度

• 政府和非营利部门：提高服务交付和资源配置效率

本质上，价值流网络推动运营效率，促进协作，培养持续改进，并在软件开发以外的多个领域增强以客户为中心的文化。

组织价值流网络

在本小节中，我们将探讨价值流网络如何在组织内应用。我们将不再将网络视为一个无形的网络，而是将其锚定于一个或多个客户旅程，突出其与客户的紧密关系，并描绘其活动的重点是发展还是运营。此外，我们还可以模拟并假设每个流以及整个网络中测量、运营模式和战略变更的效果。

采用价值流网络模型进行软件交付包括所有生产软件所需的任务，以及将人员、流程、信息和技术作为支持软件开发生命周期及所有价值流流动的使能能力进行整合。该模型涵盖了从最初的想法或客户请求到开发、测试、部署和持续支持的整个端到端过程。

但价值流网络不仅仅是连接软件开发活动。当你浏览本章内容时，你会发现连接所有价值流以支持我们客户的旅程的重要性。反过来，我们将软件交付流对齐，以协助改善所有运营、开发和支持价值流。价值流管理为我们提供了识别和优先考虑改进活动的方法和工具。

在深入了解网络之前，让我们先回顾一下价值流模型，作为流动和价值交付的参考。我们将从图 7.1开始，它展示了价值流网络的可视化。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_07_01.jpg

图 7.1 – 价值流网络的可视化

价值流网络代表了一种超越传统组织结构的变革性范式。例如，这一整体模型整合了人员、流程、信息和技术，这些元素在一个互联的虚拟组织中产生能力，以优化整体流动，如图所示。

这些网络提供了组织工作流程的全景视图，促进了持续改进和无缝的价值交付给客户。通过定义它们，我们能更好地规划、讨论并诊断绩效改进的机会。在接下来的部分中，我们将进一步探讨价值流网络的基本原则及其在当代软件交付过程中的应用。

定义客户旅程

客户旅程已成为从客户的角度考虑价值交付的流行方法，并且在过去几十年中，成为产品管理的宝贵参考。客户旅程可以被绘制、衡量并用于推动以客户和结果为中心的对话。它们为技术领导者提供了与业务领导者在共同基础上进行互动的优秀参考点。与其将网络映射限制于严格的内部或孤立范围，这样的背景更具价值。

业务的存在是为了为客户创造价值，而客户旅程为团队和组织提供了一个共同的基础，让他们开始接受价值流的概念。它提供了一种外向的、以客户为中心的视角，以及一个理解从客户（或业务结果）反向到想法或请求的价值交付的可视化工具。

认识到客户旅程与价值流之间的区别至关重要。客户旅程，如图 7.2所示，通常超出了组织的控制范围。它发生在组织的边界处，客户与产品和服务互动的地方。其路径主要由客户决定，这可能限制了组织完全影响或优化它的能力。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_07_02.jpg

图 7.2 – 典型客户旅程的示意图

例如，考虑两个客户：一个客户通过朋友推荐产品并立即购买；另一个客户通过广告发现了我们公司的产品或服务，调查了其他选择，被其他需求分心，直到时机、需求和成本匹配时才会回来购买。如果通过价值流的视角来看这两种情况，它们的路径和特征将会有显著不同。这两种情形的交付时间也会大不相同。此外，对于客户互动，现有的机制不足以衡量在制品、增值时间、完成度或准确度等指标。客户旅程通常通过情感、购买概率、获取成本、转化率、订单规模等来衡量。

相比之下，组织对其价值流的运作有显著的控制权。虽然他们不能直接决定客户的行为，但可以通过实施标准化和自动化来促进流动的改进。关键指标如交付时间、增值时间、吞吐量、质量和在制品等都是必不可少的。组织能够比引导客户旅程更有效地指导工作流通过价值流。

客户旅程为理解价值流提供了基础，因为没有客户旅程，价值流就没有明确的方向或焦点，也无法与网络中的其他流连接。有了客户旅程作为流动的支点，我们可以将价值流与客户旅程的关键接触点连接起来，展示它们如何推动并支持客户旅程。

例如，营销活动价值流有助于客户的发现和知识积累，可能最终导致销售，而销售和购买过程——通过易于使用的系统（如结账或购物车）简化——则代表着独立的价值流，最终促成购买。这意味着，当我们在客户旅程中遇到问题时，可以直接追溯到相关的价值流。现在，让我们讨论如何可视化我们价值流与客户的接近程度。

可视化价值流与客户的接近度

图 7*.3* 展示了价值流分类的一个基本方面：各个流与客户的接近度。例如，在图表的顶部是移动应用程序，它们直接接触并使外部客户受益。在光谱的低端，账单被列为一个主要使组织受益的价值流，通过启用移动银行应用程序。你也可以将这个光谱视为从外部到内部的焦点，其中接近客户的程度定义了流在此维度上的位置。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_07_03.jpg

图 7.3 – 可视化价值流与客户的接近度

在光谱的低端是像账单这样的功能——一个对组织至关重要但对客户而言是不可见的内部过程。这些内部价值流同样重要，因为它们支持外部服务。然而，它们的目的更多地是内部聚焦，处理那些使组织运转顺畅的操作，如对账和采购流程。

将价值流展示为一个光谱，可以清楚地看到哪些环节最关注最终用户的互动和满意度，例如移动银行应用程序，而哪些则具有内部运营的焦点，如账单，它们确保了支持面向客户的服务所需的效率和稳定性。

图 7*.4* 展示了网络如何开始为客户旅程服务：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_07_04.jpg

图 7.4 – 将客户旅程作为锚点

产品使用阶段直接与产品开发价值流相联系。之后，审查和推荐阶段可以通过其他支持性价值流得到加强。主要的价值流，产品开发，可能会有如此大的影响力，以至于它推动客户完成整个旅程。然而，其他支持性价值流在帮助每个阶段之间的过渡方面也发挥着至关重要的作用，使客户更顺畅地从一个阶段过渡到下一个阶段。

在我们探索客户体验与价值流之间的关系时，下一部分将深入探讨客户旅程的概念。理解这一动态框架对于有效地利用价值流来引导和提升客户旅程至关重要。

在接下来的部分，我们将进一步探讨组织面临的紧迫挑战，强调需要采取战略性方法来简化价值流网络。

将价值流与客户旅程相连接

给定客户的旅程是一个个性化的路径，通常超出了组织的直接控制。它从一种内在的需求或欲望开始，激发好奇心，从而发现某个产品或服务。随着客户经历销售、购买、使用和评论等各个阶段，他们遵循的路径本质上是个人化的、由自己主导的。客户旅程可以被视为一系列相互关联的体验，每个体验都可能受到组织内不同价值流的影响。

图 7.5 描绘了一个企业 软件即服务 (SaaS) 客户旅程。它从营销活动中的曝光开始，让客户意识到一个产品，从而使他们在有限的使用范围内试用产品，选择购买，并继续他们的客户体验。该图展示了客户旅程的每个阶段如何通过包括规划、设计、构建、验证和发布活动的价值流来支持，从而确保无缝且引人入胜的客户体验。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_07_05.jpg

图 7.5 – 将价值流与客户旅程连接

这个旅程的可视化为理解价值流如何运作以及如何直接影响精益敏捷组织中的客户成果奠定了基础。通过跨价值流协调工作，我们为优化和改进创造了重要机会。通过标准化和自动化，组织可以塑造这些价值流，从而有效地支持客户旅程。

在旅程的开始，营销活动价值流在促使客户从最初的好奇心到产品使用、销售和支持过程中发挥着关键作用。通过让客户试用某个产品或服务，它为潜在的销售奠定了基础。旅程随后转向更具战术性的价值流，如销售流程，在这里，直观的结账系统或购物车等精简的系统促进了购买阶段的顺利进行。

产品开发价值流变得尤为关键，因为它与客户旅程的使用阶段相对应。在这个阶段，产品的质量和特性成为焦点，直接影响客户的体验和满意度。随后的阶段，如审查和推荐，可能通过其他支持性价值流进行增强，这些价值流专注于客户参与和忠诚度。

最终，尽管产品开发的主要价值流使客户能够完成他们的旅程，但支持性价值流的重要性不可低估。它们是穿插在客户体验中的纽带，确保每一次过渡都无缝，每一次互动都富有意义。这些价值流共同构成了一个范围，不仅定义了客户的旅程，还丰富了这一过程。

在价值流网络中利用流动

价值不仅仅是一个抽象概念；它通过我们的产品和服务以实际的利益形式呈现出来。一旦价值被量化或定性，它就可以被传递，而其创造和传递受到通过改善支持性价值流的影响。图 7.6 直观地揭示了支撑我们业务运作的价值流的互联特性，从运营层面一直到客户交付。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_07_06.jpg

图 7.6 – 价值流网络示例

在这个图形中，客户成功专员扮演着至关重要的角色，确保客户能够通过公司的产品或服务实现他们期望的结果。他们提供入职支持、持续帮助和主动参与，建立牢固的关系，倡导客户需求，并提供培训以最大化产品价值。这个人帮助推动客户满意度、客户保持和长期成功。

这个可视化表示说明了每个价值流——无论其重点是运营还是开发——如何相互作用并为向客户交付的整体价值做出贡献。这是一个价值创造的网络，其中每一项工作、材料、信息和资源流动都被协调以支持和增强其他流。

在图 7.6中，我们可以看到每个互相依赖的价值流，根据它们与外部客户的接近度（纵轴）和它们的绩效重点（横轴）进行绘制。我们可以看到这些流之间的相互依赖关系，它们要么产生，要么消耗由其他流交付的能力和服务。通过放大每个流，我们可以看到执行的单个活动和参与交付特定产品、服务或能力的团队。为了固定这个价值创造和交付的整体可视化，我们可以看到每个组件与客户旅程的连接。

尽管可以用这种方式将整个组织可视化，但如果将与当前目标无关的方面也包括在内，其价值会逐渐减小，因此重要的是将网络映射与当前最重要的目标相关联。例如，如果目标是提高某一特定产品的销售，我们可以可视化客户旅程以增加销售，并理解该产品在旅程中的连接点。我们可以向上游查看促成此旅程的营销流，以及深入到网络中，了解支持产品开发和交付的内部流。

回到图 7.6，我们可以看到目前在推动建议方面的投资不足，而这可能对销售产生重大影响。这张图作为一个实际模型，帮助我们理解组织内部价值流的运作方式。在接下来的部分中，我们将深入探讨如何根据当前客户需求优化和调整这些价值流。随着我们将网络视图整合到 VSM 的组织战略中，我们为在更大规模和更广泛的影响下更深刻地应用流动原则铺平了道路。这不仅能提升组织绩效的具体方面，还能让我们保持对组织内整体流动的全面视角。

在接下来的子部分中，我们将探讨组织面临的紧迫挑战，强调采取战略方法来简化价值流网络的必要性。

解决组织挑战

大多数组织面临着在提高效率和质量的同时，还需要管理日益增长的改进机会待办事项。这些挑战是相互关联的，解决这些问题需要一种战略性的方法，核心在于优化运营流程。

在接下来的列表中，我们将探讨相关的工作内容：

• 利用现有资源实现更多：企业需要在扩大规模和竞争的过程中，用现有资源取得更好的成果。这意味着要简化流程、消除浪费，并利用技术提升交付最大价值的能力。通过从客户成果出发，绘制价值流网络，我们可以重新设计流程，强调对价值创造最为关键的环节，同时减少非增值活动、问题依赖和浪费。

• 提高质量标准：在追求效率的过程中，质量不能妥协。组织必须找到提升质量控制流程的方法，比如通过构建质量体系，确保交付的产品或服务能够达到或超越客户的期望。通过绘制依赖关系图，并将全流程活动映射到组织中的成果，我们可以深入了解哪些努力会对交付质量产生最大的影响。我们可以放大细节，也可以缩小视野，看到相互关联的影响。

• 提升价值传递：这里的目标是为客户提供更多的价值，这可以通过创新解决方案、更好的服务或更快速的支持来实现。企业必须不断发展，以满足并预见客户需求。通过将客户旅程融入我们的网络图中，我们可以更精准地将努力和投资与客户价值的最大影响关联起来，无论这些影响是上游的还是下游的，以及它们与客户的距离。

• 培养人才满意度：保持员工满意是维持创造性、创新性和高效工作的关键。这需要创造一个支持并鼓励员工成长与满足的工作环境。通过为组织提供一个全面的价值创造和交付的表现，我们可以确保贡献者能够看到他们的工作如何增值，将他们的努力与业务目标联系起来，并理解他们的工作在客户结果中的作用。

• 加速吞吐量：对速度的需求始终存在。组织必须优化其工作流，以更快地交付产品和服务，同时不牺牲质量。可视化相互依赖的工作流有助于理解为何某些流被低估或过度利用，以及瓶颈所在的约束。我们可以识别关键的集中能力，并确保它们在长期内保持最佳性能。

采用系统化的方法解决流动性问题至关重要。通过识别流程中的约束并采用如约束理论、精益流和精益指标等原则，企业可以系统地解决这些问题，创造更加高效和有效的工作流，推动价值创造和交付。将这种互联的工作置于价值、客户和业务结果的背景中，有助于企业更专注于对组织及其长期成功至关重要的事项。

可视化组织工作流

可视化并绘制不同层次的组织结构图使我们能够从不同角度考虑组织架构和工作流。在本节中，我们将更深入地探讨这些关系。

我们将从回顾图 7.7开始，在图中我们可以看到，价值流网络代表了顶部的宏观视角，中间是团队拓扑结构，底部是组织的价值链能力。团队拓扑是一个将软件交付团队分为四种类型的框架：与流对齐的团队、支持型团队、复杂子系统团队和平台团队。该方法帮助组织为实现最佳流动性、清晰性和协作，优化团队结构，以交付软件解决方案。

图 7.7展示了组织的交付结构，从整体的端到端流程到价值链能力和组件的具体互联。这种多层次的方法有助于澄清价值流网络中涉及的不同详细程度，让我们能够选择最适合目标和受众的细节层级：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_07_07.jpg

图 7.7 – 可视化组织流程

这个可视化图表强调了认识到组织工作流程中不同层级的重要性。这种多维度的方法对于领导者和团队有效地导航和优化组织的价值流网络至关重要。

我们将在接下来的子章节中深入探讨这个图表。

价值流网络（顶部层级）

在顶部层级，我们可以看到价值流网络的全景，概述了工作在组织内部如何交付的宏观视角。这是最广泛的视图，重点是价值流如何从始至终地整体连接，而不深入到单个组件或技术依赖的细节中。

团队拓扑（中间层级）

移动到可视化的中间层，我们遇到了团队拓扑，这是一个概述组织内部团队如何构建以及如何互动的模型。这个层级从端到端的流动中放大，展示了团队拓扑，例如流对齐团队与复杂子系统团队并肩工作，并由提供基础服务的平台团队支持。

团队拓扑，正如 Matthew Skelton 和 Manuel Pais 在他们 2019 年出版的《Team Topologies: Organizing Business and Technology Teams for Fast Flow》一书中所定义的，是组织设计和软件交付中的概念。这些拓扑描述了团队如何在组织内部进行结构化和互动，以优化工作流程、减少瓶颈，并增强协作。Skelton 和 Pais 提供了有关如何组织各种团队类型（例如，流对齐团队、复杂子系统团队和平台团队）以支持组织目标并促进高效价值交付的宝贵见解。

除了结构之外，他们还定义了三种互动模式——协作、X 即服务和促进——使团队之间的连接变得明确定义为操作模型。在 VSM（价值流管理）的背景下，操作模型可以被视为一个蓝图，概述了组织如何向客户交付价值、管理资源并实现其战略目标。

通过明确团队之间的互动方式，我们可以避免许多孤岛操作的陷阱，在这些操作中，价值流“接力赛”的交接（接力棒）可能会掉落、延迟或出错。

价值链能力（底层）

在底层（或微观）级别，图表深入探讨了构成并有助于交付价值的能力和组件的具体细节。这个层次的细节是识别和审查单个特性和功能的地方，目的是了解它们如何为客户旅程作出贡献，从最初的概念到最终的交付和支持。

指导价值流战略和投资

Wardley 地图中的图 7.8提供了一个视觉工具，帮助组织理解其商业环境并据此制定战略。它帮助我们回答“我们应该在哪里投资？”以及在较小程度上，“我们如何交付？”的问题。

这张地图由两个主要组成部分构成：

• 价值链（y 轴）：这展示了满足用户需求所需的组件，从面向用户的可见组件到隐藏的基础设施。组件是指任何一个系统（或价值链）中的元素或部分，它有助于将产品或服务交付给最终用户。

• 演进（x 轴）：这表示每个组件的演进阶段，从起源（新颖且不确定）到商品化（普及且明确）。价值链是包括产品或服务生命周期的一系列活动，从起源到生产，再到最终顾客的购买。

在我们的应用场景中，我们正在评估是否应该投资基于 AI 的图像处理工具，以改进我们的价值流。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_07_08.jpg

图 7.8 – Wardley 帮助回答应该投资在哪里以及如何交付

这张地图将帮助我们的组织回答战略性问题，例如：

• 我们应该集中精力开发或外包哪些组件？

• 哪些组件已经成熟，应该商品化？

• 我们应该在哪些方面进行创新投资？

• 我们如何预测竞争格局的变化？

通过可视化这些元素及其关系，组织可以更好地做出关于资源分配、创新和竞争定位的决策。这是一个非常有价值的战略规划工具，特别是在技术和商业环境中。

通过将组织的互联能力与客户需求进行映射，这一框架提供了一个全面的概览，平衡了创新的重要性与商品化的不可避免性。

在我们的 Wardley 地图的核心是支持客户需求的关键元素，如在线图像处理和照片存储，并根据价值链和演进轴进行标绘。价值链轴展示了价值是否对客户可见，而演进轴则显示了从独特的起源到标准化商品的演变过程。

战略投资决策

随着能力向商品化演进，组织必须决定在哪里分配资源，以推动创新并保持竞争力。我们的地图建议在人工智能（AI）图像处理方面进行战略性投资，红色矩形框突出显示了增强客户旅程或提升平台能力的效率和惯性的潜在点。

Wardley 图表通过将关键能力和活动沿着从创意到商品产品的演化轴进行映射，帮助识别潜在的投资机会。评估每个组件与行业标准的成熟度，征询利益相关者的意见，并定期更新位置，以反映行业、技术和客户需求的变化。这个过程提供了一个清晰的组织能力可视化，有助于战略规划，并识别创新和增长的领域。

协调战略架构

服务的组合，如计算或在线存储，不仅通过其与客户的关系来展示，而且通过它们与其他能力和组件的相互依赖来展示其架构背景。通过绘制这些服务的关系图，组织可以审视其投资策略，识别出优势和机会。

对齐战略和运营

尽管 Wardley 地图对于确定投资方向非常有价值，但它并未展示能力是如何被生产和消费的。价值流网络定义了每个能力如何在不同的价值流中被生产和消费，并识别它们的交汇点。

图 7*.9*展示了价值流和价值链可视化的整合，阐明了我们基于价值的投资的“什么”、“为什么”和“如何”。这些结合的可视化不仅展示了我们投资应该指向何处，还提供了关于投资的目的和执行的洞察。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_07_09.jpg

图 7.9 – 结合价值流和价值链可视化

在这个图形中，我们可以看到网络中各个价值流所使用的不同能力。为了与我们的目标对齐，我们可以从生产者和消费者的角度定义这些能力，并在能力和价值流之间建立直接的联系。

在了解了 Wardley 地图如何与价值流网络结合以提供战略方向后，接下来是深入探讨我们组织工作流程的细节，视觉化我们组织过程中宏观和微观视角的细节。

发展价值流网络

随着组织的发展，它们越来越寻求全面理解其运营动态以及如何影响这些动态。结合客户接近度和绩效关注度这两个维度，可以帮助领导者确定每个价值流相对于其对客户的可见度和其绩效的位置，如图 7**.10所示。

例如，像移动银行这样的价值流对客户是可见的，并且需要关注客户满意度的指标，如净推荐值（NPS）和客户参与度。这些是业务面向客户的元素，创新和对客户需求的响应至关重要。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_07_10.jpg

图 7.10 – 平衡效率和创新绩效关注

相反，像账单处理这样的后台流程对客户是不可见的，它们属于绩效关注的效率范围。这些活动的衡量标准是运营卓越，衡量指标包括成本、标准化、可预测性和一致性。这些流程的战略考虑因素可能包括外包给外部供应商的潜力、简化操作或通过自动化来降低成本。

这种动态模型提供了关于如何在一个领域的变化——例如引入 FinOps 或平台自动化——如何在网络中产生涟漪效应，影响相邻的流的见解。将新能力集成到一个价值流中，例如移动银行，会引发适应性的问题。例如，移动银行应如何适应引入自动化的 FinOps 平台？这对客户体验可能产生哪些影响，又会带来哪些新的效率或创新？

行为和战略的影响是深远的。每一个连接，每一个图中的节点，都是一个决策点——一个必须仔细管理创新与效率、面向客户的行动与后台流程之间平衡的地方，以保持有效的价值流网络。理解这些连接以及内部流程与整体组织目标的对接，对于战略敏捷性至关重要。

价值流网络是动态的；它体现了变动的潜力，反映了组织的战略灵活性。亚马逊网络服务（AWS）的演变就是这一动态的一个引人注目的例子。最初作为支持亚马逊运营的内部基础设施项目，AWS 从内部能力转变为外部价值流。这一变化强调了随着时间推移衡量和评估价值流各个方面的重要性，以及与机会对接并实现新价值的必要性。

组织必须了解它们的价值流处于什么位置，以及如何随着时间的推移进行改进。此类战略举措带来了许多好处，从为客户提供价值、优化内部流程到保持竞争优势。通过理解和管理这一演进路径，组织可以开启新的机会，并以以前不可能的方式创造价值。

这种类型的演变对我们的价值流网络有影响，因为它们也必须过渡。我们将在下一小节中探讨这个概念。

通过绩效关注改善价值流

选择通过持续创新来改进可能会导致现有价值流的重组，这应该是一个深思熟虑的演变过程，而非彻底的颠覆。这种方法可以减少浪费和政治风险，并能利用现有的专业知识和能力。

图 7.11 展示了通过性能聚焦适应价值流的过程，突出了从创新到效率聚焦的转变。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_07_11.jpg

图 7.11 – 通过性能聚焦适应价值流

对于许多组织而言，颠覆性创新—从零开始，摆脱旧有的限制—具有很强的吸引力。然而，这种方法通常需要大量投资，并伴随着一系列风险。相反，通过逐步调整现有流程（如账单流程）的运作，组织可以演变它们的价值流，达到不同的、通常更具创新性的成果，而不必放弃那些一直以来为其提供良好服务的基础系统和流程。

这种转变涉及到一个有意识的决定，即从既定的衡量标准和行为模式转向新的目标。例如，一个传统上侧重于效率的账单系统，可能开始融入更多创新的方法，如采用新技术或修改工作流程，以提升客户体验、自动化或性能。这些变化可以带来一个更加动态和响应迅速的账单流程，同时保留现有系统的核心优势，如可靠性和可预测性。

这一转型是关于适应新环境和挑战，同时保持那些已经证明成功的要素。需要明确的是，这是运营模式的演变，而非技术或能力的变化。因此，领导者需要专注于理解和定义衡量成功的新指标。通过重新定义这些指标，组织能够鼓励在既定价值流框架内推动创新的行为。

总结来说，通过有意地调整现有的价值流，组织可以找到一个折中的方法，既能实现持续创新，又能实现颠覆性创新。反过来，这使得服务和流程的演变既具有创新性，又扎根于过去经过验证的基础之上。

想象价值流的动态

图 7.12 再次展示了一个二维画布，让我们可以将各个流与它们的接触点活动进行对比。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_07_12.jpg

图 7.12 – 简化的互联价值流网络

具体而言，这张图描绘了一个简化的互联价值流网络，并阐明了这些连接的关键性。

这些网络的核心是面向客户的产品，如移动银行，它们可能会得到与之相关的流（如贷款资格服务）的支持。这些流距离客户的近远（外部焦点）取决于它们对客户体验的直接影响。

更深入地探讨，当考虑到现代技术（如人工智能）在客户关系管理（CRM）中的引入时，这一网络的动态特性变得显而易见。为了有效利用人工智能，CRM 流可能需要转向创新，优先考虑反映这一新焦点的指标。这样的转变自然会推动团队内的不同行为，将 CRM 流拉向创新端的谱系。

作为另一个例子，我们可能需要评估我们内部开发人员的体验，他们可以从使用平台或学习环境（如道场）中受益。道场是一种结构化且协作的学习方式，鼓励在实际环境中进行实验、技能发展和问题解决。为了在整个组织中有效地推广这一方法，我们可能会决定将我们的价值流朝着提高效率的方向发展，衡量标准化程度和为开发人员提供的一致体验的水平。

了解每个价值流可以涵盖多个团队和职能，突显了组织工作流程的复杂性。这些流动的变化不是任意的，而是为了推动进化、利用诸如人工智能（AI）等机会来增强客户接触，或在这种规模上创造效率的战略性选择。

从这个角度看，组织可以开始看到变革的杠杆以及战略决策的潜在影响。通过操控定义每个流成功的指标，领导者可以引导团队实现预期的结果，无论是创新、效率，还是两者的结合。这种方法使得组织的价值交付机制能够有意识地设计，确保它们在面对内部迫切需求和市场要求时仍保持敏捷和响应性。

这些流的演进是战略重新定位的舞蹈，每一个动作都有可能催生进一步的转型。正是这种流动性使得组织能够在一个既需要稳固可靠性又要求不断创新的环境中适应并繁荣。然而，过渡价值流的过程往往需要重新组织组织资源，以支持这些转型。因此，我们需要一种方式来比较我们网络中的价值流。我们将在下一小节中探讨这种方式。

评估价值流网络

我们可以在矩阵中评估我们的价值流网络，以定义关键特征，从而帮助我们确定价值流需求。图 7.13 展示了一个矩阵视图，简化了通过关键属性比较我们网络中价值流的过程，这些属性包括价值流需求、履行特征、网络位置（从前台到后台）及其主要功能（开发性或运营性）。

在你的图表和表格中，确保列出、排序并注释你的流。如果你有雄心壮志，你还可以为每个价值流添加具体的度量标准或目标，以提供有关性能能力和目标的更多细节。你还可以定义依赖关系，指示共同的杠杆点或挑战点。

现在，我们有了一个可视化我们的价值流网络属性的方法，让我们继续学习如何利用价值流映射来揭示和解决我们的瓶颈问题。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_07_13.jpg

图 7.13 – 比较价值流属性

价值流映射揭示隐藏的瓶颈

使用价值流映射时，我们的目标不仅仅是追踪工作流程和衡量绩效；我们还希望识别出导致低效的隐藏瓶颈。这些关键的瓶颈通常是依赖关系成为问题的地方，揭示了影响价值流动的过程中的关键区域。

图 7.14 总结了这一全面分析。它展示了一个从初始请求到部署的详细时间线，描绘了每个步骤的持续时间以及中间的延迟。这样的透明度对于识别我们可以提高效率的地方以及找出生产系统中的瓶颈至关重要。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_07_14.jpg

图 7.14 – 价值流映射

在这张价值流图中进一步分析，可以识别出显著的延迟：环境设置过程的活跃时间消耗了该价值流中约 71% 的总活跃时间。通过深入分析环境设置过程的活动，我们可以更好地理解所执行的工作。将这一过程拆解为具体活动，可以帮助我们找出延迟的根本原因，并制定有针对性的改进策略。

图 7.14 还揭示了依赖关系如何在我们的组织框架中形成错综复杂的网络。例如，环境设置过程是涉及数据和 DevOps 团队的一系列协作活动的一部分，同时也包括数据克隆和环境验证等关键活动。识别这些相互依赖关系能够揭示影响我们工作流程的复杂交互，这些交互可能是临时性的或由中断驱动的，而非流畅的价值流。

利用这张图，并深入挖掘活动中的流瓶颈，我们可以开始看到价值流之外的网络及其更深层的能力。

价值流图充当了一种透镜，通过它，跨部门工作流的相互关联性变得显而易见，网络结构逐渐显现。这些相互依赖性通常反映了优化的潜力。例如，手动流程可以被自动化，转化为更加简化的自助服务工作流，从而提升价值流的效率。

然而，并非所有通过价值流图识别出的工作流都代表着成熟的价值流。该图可能包括处于不同成熟度和自动化阶段的潜在价值流。识别这些阶段使得组织能够战略性地优先考虑开发工作，聚焦在那些具有最大潜力进行改进和自动化的领域，以提升效率和价值。

价值流图不仅仅是识别当前的工作流。它充当诊断工具，使我们能够剖析并理解组织流程的结构。这些图示工作帮助我们找到可以产生最大影响的地方，将问题和机会转化为可衡量的结果。因此，既然我们知道可以利用价值流图揭示我们的瓶颈，接下来我们来探讨如何消除这些瓶颈，以简化我们的价值流。

简化产品和平台价值流

图 7*.15*展示了一个战略性的组织框架，区分了产品开发与平台价值流，从而在以技术为核心的商业模型中实现高效的解耦和去中心化：

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_07_15.jpg

图 7.15 – 对齐网络视图的流

核心思想是引入共享平台，作为解耦团队依赖关系的一种方式，从而使团队能够更加独立地运作。

在这个例子中，产品价值流明确了服务于企业对企业（B2B）和企业对消费者（B2C）市场的线性顺序，突出了那些增加价值并推动产品向市场发布的关键阶段。平台价值流则是提供必要基础服务的支撑结构，支持产品开发。它们协同工作，推动自助服务模式，提高敏捷性，缩短市场时间。

现在，让我们从工作流和价值实现的总体概念转向具体内容，深入探讨这些概念如何在组织的产品和平台价值流中得以体现：

• 产品价值流：图 7*.15*展示了两条路径：B2B 应用程序 G 和 B2C 应用程序 R。这些价值流代表了将产品推向市场所需的步骤，分别面向商业客户和个人消费者。每个步骤都在增加价值并使产品更接近市场准备状态。

• 平台价值流：这些支持以产品为中心的流程。它们提供设计、计费、集成、数据管理和合规等基本服务，促进产品价值流的顺畅运作。

产品价值流无缝使用平台价值流的强大基础设施。这种关系使产品团队能够高效使用基本服务，加快开发速度并简化从概念到客户的路径。

到目前为止，你应该清楚，本书始终专注于为客户提供最大价值。在下一节中，我们将探讨如何在我们的价值流中建立一个以客户为中心的文化。

培养以客户为中心的方法

流程对齐团队作为共享平台提供的内部客户，而平台团队则提供自助服务能力，以增强操作流程和产品开发。因此，平台团队需要采用客户服务的心态，提升服务质量，促进卓越和持续改进的文化。

流程对齐团队与平台团队之间的关系对我们的共享服务模型至关重要。作为内部客户，流程对齐团队利用平台的能力来改进其运营和产品开发。

在许多组织中，有一种倾向是强制使用特定的内部软件开发工具和平台。然而，为了避免产生反效果，高管管理和平台团队必须致力于通过提供竞争力的服务和能力来支持与流程对齐的团队。

与其将平台采用视为义务，重要的是以客户服务的心态来对待。平台团队应该像为外部客户提供服务一样交付他们的能力，确保服务水平可以与或超过外部替代方案。或者，组织可以考虑将此服务外包给专门的平台支持公司。无论哪种情况，只要有客户存在，就存在客户旅程，必须注意支持。

通过像对待面向外部市场的产品一样用心对待内部可交付物，平台团队可以提升组织的服务质量。这激励流程对齐团队与平台的服务互动，有助于整体价值流网络的健康发展，并建立卓越和持续改进的文化。

总结

我们已经到达本章的结尾，在这里我们探讨了如何在二维画布上分析价值流网络。让我们快速回顾一下我们讨论过的内容。

我们了解到，通过详细描述和评估价值流，我们可以更好地设计它们并与领导者和贡献者进行更有效的沟通，帮助他们参与改进之旅。本章概述了价值流的复杂战略框架，展示了它们如何将人员、流程、信息和技术整合为能力，以交付客户价值。

本章强调了优化这些组件以提升生产力、效率和适应性的必要性。它强调了价值流网络中的敏捷性，确保组织能够应对客户需求并在变化的商业环境中保持竞争优势。

现在，我们转到第三部分，实现精益敏捷和价值流管理（VSM）精通。接下来的章节将深入探讨如何在团队与团队以及企业层面实际应用精益敏捷和价值流管理原则。第八章介绍了基础精益敏捷解决方案团队（BLASTs）的实施，提供了协调多个团队工作的见解。第九章讨论了定义企业业务敏捷系统（BASE），提出了将面向价值的敏捷性嵌入整个企业的蓝图。

BLAST 和 BASE 将展示如何将书中前两部分的概念付诸实践，弥合理论与实践之间的差距，以实现业务变革的实践。具体而言，你将学习如何让多个精益敏捷团队在企业级模型中协作，进行持续的业务转型，同时专注于通过我们的产品和服务提供以客户为中心的价值。

问题

本节内容提供给那些希望评估自己对本章提供的信息的理解和记忆的读者。共有四个问题，答案将在后续部分提供。回忆原文的确切措辞并不重要，关键在于你能回忆起概念及其应用：

1. 在软件开发生命周期中整合价值流网络原则的主要目标是什么？这种整合如何提高每个阶段的效率和效果？

2. 价值流网络如何帮助解决常见的组织挑战，例如在有限资源下做更多的事情、提高质量、交付更多价值、保持人才满意度和加快速度？

3. 使用二维网络模型（包括客户可见度和运营焦点轴）绘制价值流，如何帮助组织领导者在战略决策中以及保持有效的价值流网络方面提供帮助？

4. 如何在组织的战略框架中进行流对齐的概念，能够促进产品和服务的开发与交付？

答案

1. 将价值流网络原则融入软件开发生命周期的主要目标是优化从概念到交付的价值流动，同时支持客户旅程。这通过减少浪费、最大化资源利用率、提高效能来提升效率。通过关注人员、流程、信息和技术之间的相互作用，这种方法促进了无缝且适应性强的工作流程，推动持续改进的文化，帮助组织保持敏捷性和竞争优势。

2. 价值流网络通过创建一种结构化的方法来简化流程，从而帮助解决组织挑战，促进高效的价值交付。这种方法通过优化工作流程、通过持续反馈循环改善质量，并通过紧密对齐输出与客户期望来提升客户价值，从而实现“以更少做更多”的目标。

3. 使用二维网络模型绘制价值流图，其中轴表示客户可见度和运营焦点，为组织领导者提供了一种战略决策工具，以保持有效的价值流网络。

4. 流动对齐通过澄清产品和平台的价值流，增强了产品和服务的开发与交付。产品价值流专注于特定市场细分的活动，确保每一步都能增加价值。平台价值流则提供诸如设计、运营支持和数据集成等关键服务。

进一步阅读

1. Kersten, M. (2018). 《从项目到产品：如何在数字化颠覆时代通过流动框架生存并蓬勃发展》。IT Revolution Press。

2. Skelton, M., & Pais, M. (2019). 《团队拓扑：为快速流动组织商业和技术团队》。

3. itrevolution.com/articles/the-three-team-interaction-modes

4. learnwardleymapping.com/

第三部分：实现精益敏捷和价值流管理（VSM）精通：面向产品导向型业务转型

在本书的第三部分，我们深入探讨了两个框架，帮助组织应对在有效交付价值的同时，保持精益（Lean）和敏捷（Agile）实践的双重挑战。基于第八章和第九章的见解，您将学习如何在局部或解决方案层面、以及在企业层面整合精益敏捷工作实践，从而为我们的外部客户创造价值。

• 第八章，实施基础精益-敏捷解决方案团队（BLAST），介绍了 BLAST 框架，通过将精益高效性与敏捷适应性结合，促进多个小团队在协作解决特定问题时开发点解决方案。它强调了领域专家在提升各种流程、产品和系统中的关键作用，这些专家通常在精益导向和敏捷导向的团队之间协作工作。

• 第九章，为企业定义业务敏捷系统（BASE），介绍了 BASE 概念模型，该模型组织、同步并整合了企业内部的工作，以确保向外部客户成功交付基于价值的产品和服务。它使组织能够通过将投资与战略目标对齐，并建立一致的产品和服务交付节奏，从而应对不断变化的市场需求。

在第三部分中，我们将探讨组织如何实现精益-敏捷和价值流管理（VSM）精通，以推动以产品为驱动的业务变革。这些章节为如何利用 BLAST 框架将组织演变为企业的业务敏捷系统（BASE）提供了可操作的洞察和实用的指导。

第八章：实施基础精益-敏捷解决方案团队（BLAST）

今日的成功要求具备持续创新的敏捷性和速度，并且拥有高效和自律的能力，以持续交付价值。整合精益和敏捷方法论是实现这一平衡的关键。

——微软首席执行官 Satya Nadella

世界变化的速度比我们想象的要快，而且随着人工智能（AI）、机器学习（ML）和机器人技术的崛起，变化的步伐只会加快。自动化和数字化已成为常态，使得个人能够更加高效和快速地完成工作。

因此，在数字时代中，竞争和生存需要感知并回应市场变化和新兴机遇。认识到这一紧迫性，基础精益-敏捷解决方案团队（BLAST）框架是你将精益效率与敏捷适应性相结合的权威指南。

虽然精益和敏捷有着不同的基础，但将它们结合起来创造了无与伦比的优势。例如，基于敏捷的软件交付组织通过实施高度集成和自动化的 DevOps 管道，显著改善了其价值流。DevOps 转型滞后的公司面临着过时的风险，这突显了一个硬道理：仅仅依靠敏捷或精益是不够的。未来的领导者将是那些能够熟练整合这两种方法论的人，不仅在软件交付中，而是在整个组织中。精益通过帮助消除浪费，使你能够释放更多的能力来提升产品和服务，最终提高利润。

BLAST 通过协调多个小团队产生持续流动的工作，扩展了传统的敏捷方法（如 Scrum），同时无缝地融合了敏捷的迭代和增量方法，用于开发新产品和服务或解决复杂的商业和技术问题。

在本章中，我们通过使用 BLAST，详细介绍了结合精益和敏捷方法的机制。BLAST 的 17 个步骤（见图 8.1）展示了从概念到实现的全面方法，促进了未来准备型组织的敏捷性和精益效率。本章涉及的主题包括以下内容：

• 利用 BLAST

• 实施基础精益-敏捷解决方案团队（BLAST）

• 整合精益-敏捷开发理念

• 优化开发节奏和价值交付

• 接纳精益-敏捷管理实践

• 追溯 BLAST 的历史

技术要求

理解本章内容没有技术先决条件。然而，你可能会发现回顾第二章《用敏捷解决复杂商业问题》和第三章《建立精益流以提高生产力》中的概念会有帮助。

利用 BLAST

如果问题总是小而可控的，一个组织可以简单地雇佣一个或两个小型的敏捷团队，比如 Scrum，来解决其业务问题或开发需求。然而，情况并非总是如此，特别是在大型组织中。此外，许多支持业务流程、系统、产品或面向服务的解决方案所需的人员，其运营角色更适合于精益流动实践。

按照敏捷的迭代与增量开发（IID）模型，BLAST 中的其他团队协作，在时间盒内的多个迭代周期中实施解决方案，这些迭代周期持续时间不同，但始终遵循固定的节奏。

BLAST 团队的生命周期因工作范围而异。例如，旨在实现涉及跨业务系统数据集成的业务流程的 BLAST 可能是相对短期的，通常为数周至数月。相反，支持持续业务流程或商业产品和服务开发活动的 BLAST 团队通常会跨越其经济可行的生命周期，通常是以年为单位来衡量的。

在价值流的背景下，BLAST 实施了团队协作概念，以在单一价值流或多个价值流之间同步工作，后者更加常见。尽管 BLAST 中的一些团队和个人在日常工作中遵循精益流动原则和实践，但其他团队则遵循敏捷的迭代和增量模式，采用如Scrum、看板或极限编程（XP）等方法。

我们还必须考虑混合情况，其中一个团队同时采用精益和敏捷实践。这在现代软件交付组织中常见，特别是那些已实施持续集成/持续交付（CI/CD）和 DevOps 工具链来整合、简化和自动化其流程的组织。在现代软件交付管道中，BLAST 团队以双重模式运作，利用精益的流动来处理日常操作工作，同时使用敏捷的时间盒模型来进行规划、解决方案开发和交付。最后，某些来自精益导向运营团队的领域专家可能会根据需要或临时情况支持敏捷导向开发团队的工作。

尽管采用了不同的工作模式，BLAST 引导团队以协调的方式进行协作，确保他们在价值流之间的一致性。无论如何，精益敏捷方法强调客户体验（CX）的持续改进，并在参与规划和执行的人员中培养以价值为导向的思维模式。总之，BLAST 为跨多个团队的解决方案开发提供了清晰的战略和结构，确保他们的共同努力为组织目标做出贡献。

在下一节中，我们将深入探讨 BLAST 的机制，探索它在增强跨团队协作卓越性方面的作用。

实施基本精益敏捷解决方案团队（BLAST）

Scrum 框架的一个标志是其简单性，包含三个支柱、三个角色、五个事件和三个工件。这种简单性使得 Scrum 成为理想的敏捷框架，适合个体小型团队。

要在整个企业中正确地推广敏捷方法，我们需要增加团队的数量，而不是每个团队内人员的数量。虽然各个团队可以保留 Scrum 的简单性来支持他们的工作，但当跨多个团队整合和协调工作时，复杂性就会产生。这就是 BLAST 框架变得至关重要的地方——用于管理这些复杂性，如图 8.1所示。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_08_1.jpg

图 8.1 – BLAST 框架

在本章内容中，继续参考图 8.1，它描绘了在 BLAST 框架内多个精益敏捷团队进行工作的流程。

作者们在 BLAST 框架中努力保持简洁，但组织多个团队在精益和敏捷模式下的工作需要更多的努力。与使用“事件”术语的 Scrum 不同，BLAST 使用“步骤”这一术语，暗示着行动和进展。在本章中，您会发现 BLAST 框架帮助团队跨越十七个步骤，在四个核心工作领域内协调多个精益敏捷团队的工作，并辅以三个支持角色和三个交付工件。我们已经在第一章中阐述了精益敏捷房屋的目标、基础原则和三个支柱，因此在此不再赘述。

分类 BLAST 工作活动

如前所述，BLAST 的十七（17）个活动被分为四个主要类别：

• 解决方案发现

• MVI 规划

• 工作流协调

• 客户反馈

这种分组的目的是将 BLAST 开发周期拆分为逻辑工作组件，以便在多团队环境中便于我们迭代和增量地交付价值。同样重要的是，BLAST 实施了一个闭环且以客户为中心的流程，确保工作平稳、持续地进行，同时保持灵活性和适应性。

以客户为中心意味着将客户体验优先考虑在每个人的行动和态度中。这是一个全公司范围的战略，需要的不仅仅是考虑客户的需求。以客户为中心的企业提供完整的产品解决方案，这些解决方案是基于对客户需求的深刻理解而设计的。这种方法改善了员工的协同，使客户的满意度得以提升，最终推动商业企业的收入和盈利能力增长。非营利组织和政府则通过更好地为受益人和公民服务来履行其使命。

随后的子章节描述了这四个类别中的每个活动，划定了工作流程，以确保精益和敏捷原则的顺利整合。我们将从形成 BLAST 以客户为中心的基础的活动开始，这些活动涉及解决方案的发现。

定义 BLAST 增量

BLAST 的核心目标是创建最小可用增量（MVIs）。然而，MVIs 并不总是会在可用时立即发布。通常，多个 MVIs 会被捆绑在一起，形成 MVRs。这些 MVRs 可能来源于一个 BLAST，也可能来自多个 BLAST。当这种情况发生时，创建 MVIs 的顺序可能取决于它们是否与其他 MVIs 一起捆绑，以形成 MVR 或集成增量。从概念上讲，集成增量是将 MVIs 捆绑在一起，以组装一个完整的解决方案或产品发布的组件。MVRs 在 BASE 规划活动中被指定，因为它们是产品管理定义的发布的一部分。

解决方案发现（步骤 1 和 2）

以客户为中心的企业将客户的价值、需求和期望视为规划和执行中的最重要因素。这一理念应当指导每一个商业决策。

以下基础步骤启动了 BLAST 团队的价值流改进：

1. 客户旅程：我们方法的核心是深入了解客户的需求和价值。客户旅程涵盖了每一次互动和接触点，从最初的认知到购买、使用及更远的阶段，可能还会导致客户的推荐或复购。实现积极的用户体验和客户满意度需要通过直接的客户互动，持续评估和改进我们的价值主张。

2. 业务价值待办事项：业务价值是通过将客户需求转化为可执行的、优先级排序的工作项来创造的，这些工作项提供了全面的解决方案。业务价值待办事项的开始是识别潜在的工作项，作为原始的想法和概念。通过细化，这些想法会被审查，以充分了解涉及的工作范围，并根据在可用时间和资源内增加最具客户价值的工作项来优先排序。业务价值待办事项捕捉了这种理解。

BLAST 超越了理论，并支持使用有助于深入理解客户价值和需求的实践。产品不仅仅是其特性的总和；全产品方法考虑了客户旅程中的一切，从购买到使用和支持。

在建立以客户为中心的基础之后，BLAST 团队继续处理MVI 规划，为价值驱动的交付奠定基础并做出承诺。

MVI 规划（步骤 3 和 4）

本小节探讨了团队如何协作规划和细化目标，制定工作策略，并确保快速的价值交付与反馈。最终，我们需要就团队的短期目标达成一致，以便管理和消除依赖关系、整合需求并优化工作流：

1. MVI 细化：价值经理（产品负责人）与开发人员合作，细化需求、架构和设计，以创造合适的产品、服务或信息资产，为客户提供价值。这个细化过程聚焦于三个关键领域：将史诗拆解成故事级别的细节，解决架构和设计问题，确定实现所需特性和功能的低层次任务。

   史诗（Epics）只是尚未细化成可执行的用户故事和技术故事的大型故事。相较之下，故事（Stories）足够详细，可以构建实现需求所需的特性和功能。

2. BLAST 规划：交付客户价值需要将工作拆解成可用、可操作的增量，通常需要多个跨职能团队的协作。这一关键活动涉及团队协调每个任务的责任人和完成时间，并确保他们的努力能够同步与整合。团队致力于持续和频繁的按节奏交付，与价值经理/产品负责人以及其他利益相关者协作，发布产品和服务。

掌握 BLAST 规划的细微差别，确保团队的工作直接与客户需求对接，并推动可见的商业成果。通过将战术计划与战略目标对齐，并作出明确承诺，团队能够实现高质量的商业成果，提升在组织中的信誉和影响力。

随着 BLAST 团队从规划转向行动，他们进入了 BLAST 运作模式的核心。在下一小节的 工作流协调 中，我们将学习团队如何将计划付诸实践，如何无缝整合工作流，并确保他们能够有效适应执行中的挑战。

工作流协调（步骤 5 至 11）

BLAST 强调，强有力的执行必须与 MVI 规划目标保持一致。对于 BLAST 团队来说，理解并执行执行、集成和协调的步骤，确保在规定的时间框架内有效实现规划的工作。

现代集成的 DevOps 工具链实现了自动化配置、构建、测试和部署，将产品开发过程提前到交付周期的前端。敏捷的迭代和增量节奏与精益流程无缝结合，促进了规划和发布周期的顺利进行。自动化确保每个产品开发步骤都得到简化，减少了人为错误并提升了价值流。

以下部分介绍了七个步骤，涵盖两种流动操作模型，用于执行和整合精益-敏捷工作流，具体描述如下：

1. 承诺积压：在回顾了需求、设计和验收标准之后，团队承诺完成他们已审阅并接受的下一阶段工作的范围。需要特别注意的是，这些承诺应由客户需求驱动，而非外部影响或团队及其他利益相关者的偏好。灵活性至关重要；承诺不应由孤立或传统的项目管理行为所驱动。

注意

在没有足够的细化和提前规划的情况下，不能做出承诺。开发团队必须确信他们已经充分定义了需求和验收标准，以理解他们需要构建的内容。在理解这一点并清楚了解他们的能力后，团队可以做出明智的交付承诺。

1. 精益团队：这些团队执行重复性工作，其中生产力、质量和效率是关键关注点，或者他们希望最小化工作流中的延迟，通常选择流动轨道。换句话说，他们主要采用精益导向的实践，专注于确保工作、人员、信息和物资在业务环境中的顺畅流动。

2. Kaizen：在精益团队中，Kaizen 活动是集中于改进流程、工作流程和成果的活动。这些活动汇集跨职能团队成员，分析需要改进的具体领域，识别低效或瓶颈，并共同集思广益，提出解决方案。

   通过定期参与 Kaizen 活动，BLAST 团队培养了持续改进的文化，使他们能够迭代地优化实践、简化工作流程并提高绩效。这种迭代方法使团队能够快速适应不断变化的需求和市场条件，从而提高开发过程中的效率、质量和客户满意度。

3. 敏捷团队：这些团队致力于解决复杂的业务问题、规划新增量或开发或改进流程、产品和服务，通常选择时限开发轨道。例如，敏捷实践的时限开发方法（如 Scrum）允许团队迭代地试验不同的概念，并逐步部署新特性和能力。

4. 回顾会议：基于敏捷的团队必须在遇到问题或障碍阻碍已承诺工作的完成时迅速调整。如果问题出现，团队应有行动偏向，尽快解决问题，以避免问题的积累变得更加复杂和具有挑战性。根据所采用的敏捷方法，Scrum Master、价值经理或类似角色可以帮助团队解决障碍。

5. BLAST 迭代：当一些团队采用时间限制的方法，而其他团队则遵循持续流动的方法时，协调和整合多个团队的工作是具有挑战性的。BLAST 通过共享待办事项、BLAST 规划讨论以及将工作分解为可操作的工作项，促进跨团队的整合。此外，定期实施跨团队评审和回顾有助于团队对齐活动，发现改进合作和工作的方式。

6. MVI 输出：在成熟的软件交付组织中，适当的团队结构和跨团队的工作协议可以减少协调工作的需求。然而，作为 MVI 部署的完整产品发布可能涉及来自不同业务领域的团队共同协作，以协调整个价值链的交付。例如，研发、法律、产品与市场管理、销售、架构、财务、开发、支持和合作伙伴管理等组织都为成功的 MVR 发布作出贡献。

客户反馈（步骤 12 到 17）

该阶段包含了旨在以价值导向的方式对齐我们未来努力的关键客户反馈环路。该部分将深入探讨 BLAST 框架中的第 12 到第 17 步，它们使我们能够不断发展和改进，以满足客户需求：

1. 集成增量：此步骤是 MVI 的阶段性活动。继工作流协调阶段之后，该阶段输出一系列与当前业务增量计划中的 MVR 相关的 MVI，这些 MVI 构成了更大版本的一部分，尽管它们通常是相互关联的。这些跨业务职能生成的 MVI 输出按需到达，并可能在不同的时间间隔发布。例如，营销促销通常会在产品发布之前很久就开始。MVI 在 MVR 内的协调和同步发布遵循增量发布流程。

2. 评审：在没有适当的评审来验证输出是否满足在业务价值待办事项中指定的要求之前，不应将 MVI 发布给预期客户。例如，客户和用户是评判您产品和服务价值的最终裁决者。然而，管理层和其他利益相关者需要确认过程和系统更新能够实现那些证明其投资合理性的业务和合规要求。

3. 反馈与调整：如果所提供的价值未能达成目标，且我们未能捕获反馈并采取适当的行动，那么集成增量评审将无效。这项活动确保了在交付的产品和服务中，错误（开发中的缺陷）和缺陷（对需求的理解错误）被妥善记录，并反馈给 MVI 精炼过程，重新进入业务价值待办事项列表，进行优先级调整。如果跳过此步骤，直接发布产品或将其立即重新投入开发流程，肯定会给组织带来更多问题。

4. 需求分析：这项活动是 BLAST 等同于 Scrum 团队级回顾的活动。各个团队会在每个 BLAST 迭代结束时召开会议，评估他们的表现并确定未来 BLAST 循环中可以改进的方面。由于 BLAST 是团队间的概念，每个团队应指派一名代表，最好由其具有资格的人员将他们的发现带到与其他团队的联合会议。在这些会议中，代表们共同解决集成、同步和依赖问题，以提升未来的 BLAST 循环。团队代表随后将他们的 ToT 评估建议分享给团队，以实施改进。对于复杂问题，可能需要多个迭代才能实现预期结果。

5. 已部署的集成增量：这是我们发布的 MVI 在集成增量评审中表明其价值符合客户期望时的路径。MVI 和 MVR 通常由多个面向客户的解决方案组件组成，组织必须确保每个组件都已完全部署。

   例如，我们不能通过我们的增值经销商（VARs）发布供转售的产品，除非完全部署所需的通讯、推广、培训、产品信息和支持材料，以确保合作伙伴的成功。从所提供的示例中，可以清楚地看出，集成增量可能由来自多个 BLAST 的组件组成，经过协调以提供一个连贯且全面的解决方案。

6. 客户体验：在将新产品或服务部署到客户后，CX 项目对于确保客户持续的满意度和忠诚度至关重要。这些项目应涵盖各种举措，以收集反馈，及时解决问题，并不断提升客户体验。

   相关 CX 方法的示例如下：

   • 调查和反馈表

   • 净推荐值（NPS）

   • 客户旅程映射

   • 用户测试

   • 社交媒体监测

   • 客户支持分析

   • 焦点小组

有效的客户体验（CX）计划的关键组成部分包括客户访谈和情感分析，以深入了解客户满意度和偏好。此外，积极的客户支持和互动策略对于解决问题和提供个性化帮助至关重要。定期监控客户互动有助于发现改进的领域，促进长期关系，推动忠诚度，并最大化我们的产品或服务在市场上的成功。

这就是我们对 BLAST 框架的讲解。你可能会发现它与其他敏捷框架，特别是 Scrum，有相似之处。但 BLAST 的目标是将两种基本管理哲学——精益和敏捷原则及实践——有机整合在一起。正如往常一样，细节至关重要。因此，让我们在本章剩余的部分了解 BLAST 实施的具体细节，从如何将精益和敏捷实践融入多团队环境的讨论开始。

集成精益-敏捷开发概念

BLAST 集成了精益和敏捷方法，这是一种旨在赋能多个团队在复杂的业务挑战中有效协作的策略。BLAST 的一个基本特征是其双重性质：精益用于日常操作效率，敏捷用于促进创新产品的变化。

在许多组织中，团队成员主要被期望在精益框架内运作，正如在第三章《建立精益流程以提高生产力》中讨论的那样，这与组织专注于价值交付的目标相一致。对精益原则的重视构成了 BLAST 框架的基础元素。然而，BLAST 还包含敏捷元素，能够推动基于节奏的业务和产品规划，促进新产品、服务或其他业务支撑性文档的开发。

BLAST 是一种变革性的方法，旨在克服可能阻碍组织充分实现精益-敏捷潜力的限制性信念和实践。尽管 BLAST 有明确定义的流程和活动，旨在提升团队协作和效率，但其方法应不断调整，以最适合您的独特环境。

在接下来的小节中，我们将探讨如何对齐多个团队共同开发特定解决方案的工作。

为协作卓越对齐团队

BLAST 基于一个关键原则： 当团队围绕共同目标对齐，以支持组织的价值流时，他们能够高效且具有成本效益地协作交付最大价值。

当团队对齐时，可以赋予更多的自主权，超越简单的协调，并且以更少的努力 consistently 得到更好的结果。团队有着共同的目标，即提升交付能力，并且参与的团队天然地理解不断改进产品、服务、业务系统和流程的重要性。他们意识到，实质性的改进来自于优化流动、消除浪费，并专注于关键的提升机会。

BLAST 的一个关键方面是无缝集成工作，确保快速反馈。相比之下，缺乏和谐与目标对齐会导致操作碎片化、增加开销和浪费资源。对齐的核心是致力于以客户为中心，强调通过创新的产品和服务交付无与伦比的价值。

结合 Lean 和 Agile 实践

虽然 BLAST 根植于 Lean 流程的原则，但它并没有忽视 Agile IID 方法所提供的优势。它突出了小型、可适应的团队在持续交付价值中的作用。支持组织的价值流，BLAST 团队秉承 Lean 价值观，专注于保持价值的持续流动、最小化低效，并迅速适应变化。

虽然 Lean 支持持续提高质量、生产力和效率，但加入 Agile 方法确保团队在当今全球化经济中保持灵活性。通过整合迭代周期和响应性，BLAST 确保团队能够快速响应不断变化的客户需求和市场条件。Lean 的高效性和 Agile 的适应性共同使组织能够满足客户需求，同时不断改进和创新。此外，BLAST 的 Lean 定向提供了有助于组织整体 VSM（价值流映射）计划的改进洞察。

简而言之，BLAST 通过运用 Lean 的流动导向理念，使团队能够实现最大效率和生产力，而其他人则选择 Agile 的迭代和增量方法来解决问题、进行业务规划和开发。此外，某些团队成员，尤其是领域和技术专家，可能需要在协助多个团队工作时支持这两种方法。

然而，尽管我们认识到这些结合方法的优势，我们也必须解决决策权应该归属哪里的问题。下一小节讨论了如何通过对齐价值观来帮助融合传统与现代管理方法。

定义 BLAST 角色

请注意，BLAST 不包括正式的 事件 概念。我们接近的概念是 BLAST 中定义的 17 个 步骤。然而，由于 BLAST 是一种 Lean-Agile 方法论，更合适的做法是将每个步骤视为 BLAST 定向价值流中的一个定义活动。理解这一点后，让我们看看 BLAST 如何定义其角色。

在 BLAST 中，我们明确了角色和责任，目标不是替代其他敏捷或精益敏捷领域的术语，而是提供更高的精确度。一个这样的角色是价值经理，功能上等同于 Scrum 中的产品负责人。另一个是价值教练，取代了Scrum 大师。但更重要的是，我们不想改变你所在行业或业务领域中使用的常见术语。因此，这些角色旨在作为抽象概念，定义在精益敏捷企业中赋予个人的责任。重命名这些角色不是强制性的，但它带来更大的清晰度。理解这一点后，我们来探讨价值经理的角色。

定义价值经理的角色

在 BLAST 中，为了支持精益敏捷实践在企业中的持续性，替代传统的产品负责人角色，我们引入了价值经理。这种重命名不是为了取代 Scrum 术语，而是为了从精益敏捷的背景中澄清这一点。价值经理强调以各种形式交付价值，最小化与 Scrum 产品负责人相关的任何误解。例如，在大型组织中，我们有时观察到软件被开发出来却没有得到适当的支持，因为创造潜在客户价值的预算与运营和支持交付的软件产品的预算是分开的。

价值经理平衡利益相关者和客户的需求，清晰地阐明待办事项，以引导团队朝着高优先级任务迈进。这个名称准确地捕捉了该角色的本质，同时避免了 Scrum 相关的仅关注产品导向待办事项的陷阱。相比之下，价值经理的角色是从增值的角度评估和优先处理所有工作。

在 BLAST 中，执行价值经理角色的方式多种多样，组织可以自由使用独特的术语来表达该角色的责任。理想情况下，价值经理是公司内的高层职位，为首席执行官和股东提供支持和指导，确保决策与公司最佳利益保持一致，并提供最大的客户价值。他们参与合规工作、财务报告、风险管理以及他们所支持产品线中的利益相关者关系，推动道德领导力和公司治理。

现在，让我们继续了解开发者在 BLAST 框架中的角色。

定义开发者的角色

在 BLAST 中，开发者是创造价值的核心人物，他们在交付的流程、系统、产品和服务中创造价值。但他们不仅是孤立的人才——他们是一个有共同使命的紧密团队。换句话说，他们是精益敏捷环境中的价值流团队成员。

因此，在 BLAST 中，适用于商业、政府或非营利性部门，“开发人员”一词并不限于特定角色；它指的是支持组织精益敏捷价值流的任何人。让我们看看他们的一些定义特征：

• 统一的愿景

• 自给自足

• 采用 ToT 结构

• 明确 定义的角色

• 跨职能

• 避免依赖

• 以价值为导向

无论是解决复杂的商业挑战，设计技术解决方案，制作业务文档，还是为各种客户（内部或外部）交付产品和服务，这些活动都属于开发人员的范畴。认识到并重视这种多样性，对于最大化团队潜力和产出至关重要。

现在，让我们继续定义 BLAST 中价值教练的角色。

定义价值教练的角色

价值教练是 BLAST 中的关键人物，主要负责引导团队朝着目标前进，促进有效沟通，并确保遵循最佳实践。

通常，开发团队可能会专注于个别任务而忽视更大的目标。持续改进可能会被搁置，个体承诺可能会被忽视。价值教练确保团队始终与其核心目标保持一致，并不断发展。

BLAST 框架中的价值教练角色涵盖了一系列对团队动态和整体进展至关重要的职责，包括以下内容：

• 促进团队成长

• 支持改进

• 促进外部沟通

• 鼓励精益敏捷思维

• 服务型领导风格

这完成了我们对 BLAST 团队角色和职责的讨论。我们的目标不是强制执行不符合你们行业、领域实践或组织偏好的术语、角色和职责。BLAST 是一个帮助协调多个精益敏捷团队工作的框架，用以创造解决方案。它并非旨在建立僵化的规则和程序。相反，其目的是提供有关角色和职责的清晰指导，改善精益敏捷工作环境的运作，并给予你在独特业务背景下发挥作用的自由。

在下一部分，我们将探讨 BLAST 框架中的团队间协作。

促进团队间的协作

在各种规模化的敏捷框架中，团队大使或联络人作为团队之间的沟通点，促进协调与对齐。1 例如，Scrum of Scrums、Scrum at Scale、Nexus 和 SAFe® 都有角色或其他机制来履行联络人角色。

在 BLAST 框架中，我们支持协作团队的概念；然而，我们避免为这些角色指定具体的名称。我们认为每种情况都是独特的，需要量身定制的解决方案。此外，这些职位通常是动态的，个人会根据需求临时被召唤。

例如，来自会计部门的一名或多名员工可能被召集到软件开发团队，作为领域专家，帮助确保金融应用程序符合财务法规。在这种情况下，任务是临时且兼职的。

我们之前谈到过精益敏捷组织中管理的相关性，那么让我们回到这个话题，再花点时间审视其角色。

平衡决策方式

传统的管理理念往往倾向于自上而下的方法，通过集中的决策制定来引导组织。换句话说，老板告诉我们该做什么。然而，这种方法容易被视为专制，管理层可能忽视了只有团队才能获得的信息。

相比之下，敏捷实践采取更具参与性、从下至上的方法，在这种方法中，团队成员的见解和贡献更为重要。然而，组织内去中心化的决策制定需要更多的协作，团队可能会遇到协调挑战，尤其是当多个团队的观点、目标和任务不同的时候。如果我们将视野局限于这两种管理极端，有人可能会认为，自上而下的战略可以提供更清晰的战略意图，而去中心化的方式则能提高员工在工作中的参与度和一致性。

精益通过考虑高层管理和中层管理在支持多个团队之间互动的过程中所扮演的角色，提供了一种更加平衡的方法。例如，在精益组织中，高层管理人员是组织战略的架构师，协调愿景并提供统一的力量，使公司各级保持一致。中层管理者在精益组织中也扮演着关键角色，因为他们直接支持价值流。在 BLAST 中，这些人是我们的价值经理和价值教练。他们通常被称为“粘合剂”，将公司各个层级连接起来，弥合高层管理与基层员工之间的鸿沟。

因此，精益组织通常结合了自上而下和自下而上的范式优势，提供了一种平衡的方式，从而带来更好的商业成果。这种平衡的方式，我们称之为中上而下管理策略，能够提供所需的高层次视角，同时赋能团队在这一背景下决定如何工作。

在下一个小节中，我们将深入探讨基于敏捷的小团队环境下的去中心化决策制定。

促进去中心化

敏捷实践的广泛接受推动了采用更简化的组织结构的运动。敏捷组织结构促进了自我组织的跨职能团队，这些团队不再需要传统的项目经理来推动跨部门的工作。因此，敏捷团队需要的每日任务指引较少，更依赖于自我管理，并通过 Scrum Master、产品负责人和敏捷教练等角色提供支持。

以下列表定义了去中心化的关键特征：

• 更扁平的结构：敏捷组织通常倾向于更扁平的结构，采用自我管理的团队，这些团队不需要每日的任务指引。

• 分散决策：唐·雷恩特森（Don Reinertsen）在他的著作《产品开发流原则：第二代精益产品开发》中强调了“平衡集中化和去中心化”这一点。2，3 每一个必须升级处理的决策，都可能导致价值流延迟，并且当决策者距离信息源过远时，决策质量可能较差。BLAST 与雷恩特森及规模化敏捷框架®（SAFe®）4，5 一致认为，领导者应当做出并传达战略决策——那些不频繁、长期且具有显著规模经济效益的决策；所有其他决策应当去中心化。6，7

• 服务型领导：敏捷强调的是促进和教练，而非传统的层级权威。服务型领导通过培养责任感和自主性文化，赋予个人和团队卓越的能力。让我们来看一下两种常见角色：敏捷教练和 Scrum Master。

  • 敏捷教练规划和执行，促进活动，建立最佳实践，向领导层提供建议，并打破团队之间的障碍。

  • Scrum Master确保团队理解 Scrum，促进 Scrum 活动，支持产品负责人提出的目标，消除团队的障碍，并保护团队免受干扰。

• 持续反馈循环：计划-执行-研究-行动（PDSA）循环最初由谢沃特（Shewhart）定义，并由德明（Deming）普及，是一种有效的获取快速反馈并在解决方案开发过程中控制不必要变异的方法。8 9，这个循环通过持续和一致的反馈流促进改进和发展。更频繁且较短的 PDSA 循环可以带来更快的学习。

敏捷的去中心化决策模型在小团队环境中表现良好，因为工作范围有限。然而，随着工作范围的扩大，涉及多个团队，或敏捷成为整个企业的目标时，去中心化模型就显得力不从心。幸运的是，正是在这一点上，精益管理实践提供了一个更具说服力的管理模型。在我们讨论这一主题之前，先仔细看看为什么大型组织在实施扁平化结构和去中心化决策时遇到困难。

管理跨团队互动

在规模化 Scrum 方法论中，协调多个团队工作的一种常见方法是实施团队-团队结构，通过代表们促进团队成员与其他利益相关者之间的大部分沟通。然而，即使是这种方法也可能变得令人不堪重负。这也是精益组织保留中层和高层管理职位的原因之一，确保沟通保持有效且可管理。

拥抱精益领导

拥有扁平化和去中心化的组织结构在一定程度上是有益的。然而，正如前一小节所解释的，团队成员与利益相关者之间的潜在接口数量可能会变得难以管理。简而言之，需要更多的人来促进沟通和协调。

在精益方法的动态环境中，组织努力将已建立的等级结构与进步的领导实践相融合。丰田生产方式（TPS）是精益管理原则的一个典型例子。

在 TPS 中，传统的管理等级制度依然保持完好，确保从前线主管到高层管理者有清晰的指挥链。然而，这种方法并不是僵化的“命令与控制”。相反，精益领导强调以身作则，采纳服务型领导，并将操作结构扁平化以支持价值流。重点从权威转向合作、持续改进和员工授权。10、11、12

采用带有变化的传统等级制度

在精益组织中，管理等级制度仍然存在，作为支持高效运营的框架。TPS 模型就是这一点的典型例子，具有明确的管理层级，确保无缝协调。TPS 将等级管理与去中心化的权力和授权实践结合起来，创造出一种平衡而有效的组织结构。这种方法将清晰的指挥结构与前线员工授权结合在一起，培养了持续改进和合作的文化。

实施关键管理结构和原则

为成功地将层级管理与去中心化和授权实践相结合，像 TPS 那样的精益组织发展了一个全面的方法。该方法包括保持清晰的指挥结构，同时授权一线工人并促进持续改进。以下关键结构和原则概述了 TPS 如何实现这一平衡，确保效率和创新在组织内和谐共存。

• 层级管理：

  • 明确的指挥链：TPS 保持传统的层级结构，以确保决策过程中的秩序和清晰，从一线主管到高层管理人员

  • 高管的角色：高管制定战略方向，并促进持续改进和创新的文化

• 去中心化 与授权：

  • 现场走访：领导者进行现场走访，亲自观察操作，保持与实时挑战的连接，并促进持续改进

  • 授权一线工人：管理层鼓励员工识别并解决问题，通过如jidoka（带有人性化的自动化）等原则确保质量

• 中层管理作为促进者：

  • 桥梁角色：中层管理者将战略目标转化为具体的操作活动，支持团队提供资源和指导

  • 仆人式领导：中层管理者作为仆人式领导，消除障碍，支持团队向运营卓越努力。

• 团队结构：

  • 跨职能团队：小型的跨职能团队，跨越各个职能部门和价值流，协作解决问题并实施改进

  • 持续改进（Kaizen）：团队定期参与 Kaizen 评估活动，以提高流程并消除浪费

• 以身作则：

  • 到工作现场去：在精益管理中，领导力通过在问题解决和持续改进过程中积极参与，以身作则。诸如“现场走访”（Gemba walks）等实践，领导者亲自到工作现场观察操作并与员工直接互动，通过这种方式促进了对工作的第一手理解与合作。

• 聚焦决策：

  • 战略对齐：尽管各个层级的反馈至关重要，但战略决策通常会与层级结构对齐，以确保与组织的广泛目标、预算和时间表的一致性。这个过程也是协作性的。

• 中上而下管理：

  • 角色：在精益方法中，中层管理者扮演着至关重要的角色。他们向上看，理解组织的战略愿景，同时向下和横向关注价值流，识别如何实现这一愿景。

  • 责任：他们的主要责任是创造一个能够有效实现战略愿景的环境。

通过结合这些管理结构和原则，我们可以实施一个平衡的管理框架，既支持效率，又支持创新。这种框架创造了一个动态环境，其中层级结构与基于价值的交付流和小团队并存，促进了敏捷性和持续改进。

现在我们已经对精益管理有了基础了解，接下来我们将探讨如何管理 BLAST 团队。

为精益领导力进行现场管理

BLAST 采用了精益导向的中上而下管理方法。虽然精益组织保留了层级管理结构，但经理们不会将自己隔离在办公室里，而是会到工作现场去理解工作环境的实际情况。他们不是为了找错，而是为了更好地理解问题以及如何帮助解决问题。这一做法被称为现场管理，即经理和领导亲自到实际工作场所观察流程，直接与执行工作的人员互动。

在虚拟或远程工作环境中，领导者可以通过数字化工作场所巡查和在线协作讨论来实现现场管理的精髓，确保他们与工作中的实时挑战和细节保持联系。

通过鼓励领导者融入工作环境，组织促进了管理层与一线团队之间的直接双向理解。这种亲身参与确保了领导者能够了解并深刻连接到日常的挑战和改进价值交付的机会。同时，这也培养了一种互相尊重的文化，让团队感受到他们的贡献得到了真正的认可和重视。在 BLAST 环境中，执行人员、经理和团队领导优先关注价值交付，并致力于消除由孤岛式组织结构造成的障碍。

管理多层次评审和沟通

对于精益敏捷型组织，产品负责人——在 BLAST 中被称为价值经理——负责领导规划工作。在精益敏捷型组织中，价值通过改进流程、基础设施、工具和设备、系统、产品以及服务来获得。因此，价值经理的角色在范围和复杂性上都是多方面的。

这个角色还需要战略眼光，以确保工作项目在组织的开发管道中保持持续且相关的流动。这不仅仅是响应客户的即时需求，而是与公司战略、目标以及投资组合管理的深度对齐，特别是在新情况需要技能、软件、工具和设备变化时。

在这种情况下，采用多层次的规划方法至关重要。这包括将年度战略规划周期与频繁的季度产品组合和产品管理规划会议结合起来。此外，还需要通过定期的产品设计和规划活动来补充，从而形成一个统一且响应迅速的团队规划方法，能够适应软件和产品开发团队面临的动态需求。

对于希望利用精益敏捷实践来获取竞争优势的组织来说，理解并有效实施多层次的规划节奏确保了开发工作始终与战略目标保持一致，最大化效率并推动创新。有效的精益敏捷规划增强了组织的敏捷性，支持持续的竞争成功。

现在，让我们讨论一下 Lean-Agile 组织中团队层级的规划如何发生变化。

改进每日会议

你是否曾经发现自己在一次每日 Scrum 会议中，能感觉到能量明显低落，人们的眼睛在重复的信息中变得迷离？你是否观察到团队成员在做多任务处理，甚至更糟的是，不关注同事的更新，陷入了脱节？如果是这样，你并不孤单。这种情况比你想象的更常见，并且有多种原因。

例如，团队成员通常会通过其他沟通渠道和会议获得足够的更新，因此不需要再次在每日 Scrum 中讨论。讨论可能会过于详细，焦点从快速更新转向更适合后续讨论的问题解决会议。或者，会议中是否有太多与会人员？根据我们的经验，任何超过七到九人的 Scrum 会议都会变得笨拙，导致与会者失去参与感和满意度。

认识到这些挑战是改善每日会议的第一步，确保会议能够达到预期目的——检查 sprint 目标的进展，协调当天的工作，调整即将进行的工作，并解决障碍。团队可以使用任何结构或技术来进行每日 Scrum。然而，团队不应等到这些每日会议才进行调整。团队应当在需要时共同适应或重新规划工作。让我们来看看如何改进：

• 优化每日 Scrum 过程：考虑将每日 Scrum 的频率减少到每周两到三次。这一改变可以防止会议变得单调乏味，并使其更加动态和有价值。随着团队对敏捷实践的熟悉，他们通常会通过频繁的沟通和协作来保持项目进展，从而使得每日会议变得不那么重要。

• 使用看板板：将看板板融入每日站会流程中，能够有效地展示团队的工作流程、工作状态以及价值流动。看板板高效地解答了每日会议中的三个关键问题，使团队能够更多地专注于协调当天的工作和解决阻碍。该方法与精益原则高度契合，强调去除浪费（在此案例中为不必要的讨论）并保持流畅的工作流。

• 使用通用语言：由于不同组织对最佳实践、术语以及与培训和认证相关的成本的看法不同，一些组织可能会抵制在大规模上采用特定的方法论和术语。例如，通常所称的每日站会，可能会被称为同步会议，或根据团队的需要调整名称。即便没有使用具体的术语，你仍然可以实施敏捷实践——如果使用特定术语会妨碍采纳及其支持的价值流，我们鼓励并支持这种灵活性。

使用精益敏捷原则来根据你的环境调整每日站会，从而提高其效果及其他敏捷事件的效果。实践的演变需要对敏捷方法有成熟的理解，强调适应性和持续改进。

在精益敏捷环境中进行迭代回顾

在精益敏捷开发环境中，冲刺回顾的概念经历了转变。在 BLAST 方法中，我们更倾向使用迭代而非冲刺一词，尽管在本书中我们常常交替使用这两个术语。一个原因是，迭代这一术语不依赖于团队的开发方法。此外，冲刺这一术语往往带有一种短跑但快速比赛的意味，而这并非我们的意图。相反，我们在每次迭代中的目标是以可持续的节奏交付新的增量价值。我们还使用集成增量而非增量一词，以强调增量是从功能角度跨团队全面集成的，旨在充分支持新版本的发布。

时间盒（Timeboxes）确定了我们约定的交付新增值的节奏。节拍器是一个更合适的类比，因为迭代设定了我们的工作节奏和交付节奏。因此，集成增量这一术语更准确地传达了时间盒的目的：通过新的产品或价值流增强，产生一个以客户为中心的新增值。

在每个解决方案开发周期结束时，BLAST 集成增量的审查是一项结构化活动，客户、用户和其他相关方评估集成增量的完整性，准备发布。例如，集成增量可能聚焦于两个不同信息系统的开发工作，这些系统同时支持对现有业务流程的变更。集成增量还可能包括转换和迁移的数据、SQL 查询、定制报告、工作帮助工具、培训材料以及相关的沟通内容。

图 8.2 说明了集成增量的概念。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_08_2.jpg

图 8.2 – 集成增量组件

增量发布的数量和完成系统集成工作的总体时间表是次要问题。相反，MVR 规划和 BLAST 规划的主要关注点是在完成一个或多个 MVI 的过程中实现增量目标。增量目标提供了一个清晰的描述，说明从客户的角度来看应该实现的最低业务价值，详细列出发布所需的所有组件，以及定义完成标准的接受标准。换句话说，MVI 方法优先考虑在每个开发周期中交付切实可行、有用并可部署的价值。

此外，MVR 可能包括多个 MVI，并遵循相同的 BLAST 发布节奏。我们将在本章后续内容中探讨 MVI 和 MVR 的相关性，并在第九章中再次讨论，为企业定义业务敏捷系统（BASE）。

现在，我们将继续讨论在精益敏捷环境中使用团队回顾的方式。

通过价值流管理增强回顾

在精益敏捷组织中，Sprint 回顾的方式发生了重大转变。在非增值活动上投入时间、金钱和资源可能会产生不利影响。虽然是出于良好意图，但导致局部优化的回顾可能会损害 BLAST 的表现，造成内部纷争、指责、应急处理和员工疲劳。这种情况通常发生在未考虑其系统性影响的情况下，强行要求变更或交付目标。因此，在 BLAST 中，我们将回顾与基于 VSM 的改进策略对齐，以关注最具影响力的改进。

Scrum 回顾会议关注开发团队可以在即将到来的冲刺中直接影响的内容，旨在团队的本地权限和范围内进行即时的、迭代的改进。这种方法在团队规模较小、范围仅限于团队可控的情况下非常有效。然而，在大型的、多团队的环境中，单个团队的改进可能会导致局部优化，忽视了更广泛系统需求。因此，总结一下，基于团队的回顾会议有助于提高团队的效能和适应性，但由于缺乏对整个价值流的可视性和控制权，它们在进行更广泛的系统性变化时能力有限。

相比之下，精益的 VSM 实践要求更广泛的视角，审视从概念或需求到客户交付的整个价值流。这有助于识别和优先考虑对整体流动、生产力、效率和吞吐量产生重大影响的改进。这些改进直接促进了收入的增加、成本的减少和质量的提升。

如果没有系统思维，优化可能会改善特定团队或流程，但却忽略了能够惠及整个价值流的更具影响力的变化。如果改动没有解决当前的瓶颈，那么大量的时间、精力和资源可能会被浪费，却对客户或组织几乎没有可见的好处。因此，VSM 从业者总是寻找那些阻碍流程的约束。

让我们回顾一下在第三章中最初介绍的一个图例，作为约束理论的例子（见图 8.3）。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_08_3.jpg

图 8.3 - 约束理论示例

如前所述，图 8.3 展示了一个价值流，包含七个活动，每个活动耗时 5 分钟，唯一的例外是一个核心活动（A4），需要 10 分钟。这一较长时间的活动造成了瓶颈，导致前面步骤的工作积压。同时，后续活动缺少工作，等待来自瓶颈步骤的输入。关键问题是，解决 A4 活动中的瓶颈是主要任务。如果另一个团队花费时间、金钱和精力将其周期时间缩短到 30 秒，这将毫无意义，因为 A4 仍然是瓶颈。即使他们进行了改进，其他六个活动也无法支持修订后的价值流活动的流量。

因此，精益敏捷组织中的回顾会议必须进行调整，以纳入更广泛的 VSM 视角。这种整体视角有助于更全面地理解如何将价值交付给客户。通过将 VSM 思维整合到回顾会议中，团队能够在短期内进行改进，并为更广泛的系统性变化做出贡献，从而提高组织价值交付的整体效能和效率。

在这一部分中，我们解释了在多团队环境中，回顾和沟通如何以不同的方式运作。

BLAST 成果中的价值交付优先级

BLAST 通过其三个标志性成果：最小可行产品（MVP，由 Eric Ries 定义）、最小有价值增量（MVI）和最小有价值发布（MVR）突出其专注于通过提供实际价值来实现显著区别。这些成果是开发过程中的战略性里程碑，确保向顾客交付实际价值，同时与更广泛的组织目标保持一致。让我们逐一了解这些概念。

最小可行产品（MVP）

BLAST 中的 MVP 是一种经过验证的方法，强调整合价值流团队之间的协作，以创建新产品或服务的早期版本，使团队能够验证提议的概念或市场机会。这个 MVP 是可以随时间建立和交付的最小和有形的表示。MVP 使用迭代过程，使团队能够评估产品的可行性，并根据快速反馈进行调整。在他的开创性著作《精益创业》中，Eric Ries 描述了 MVP 作为验证是否存在顾客需要的产品以及如果有的话需要哪些特性的方法。在他的后续著作《创业方式》中，Ries 澄清了 MVP 不仅仅是探索产品，而是关于整个产品的所有假设，包括其营销、交付和支持。13, 14

最小有价值增量（MVI）

这涉及在产品生命周期内交付新的价值增量，从概念到生命周期结束。它们经常整合多个价值流团队的努力，以推出以顾客为中心的产品或服务。这包括对策略的调整、融资的获得、市场需求的确定、设计、开发和测试，以及部署、推广、销售和支持。MVI 确保每个步骤都增加了价值并与顾客需求保持一致。

MVP 和 MVI 的关键原则是专注于快速交付高价值功能。然而，MVI 的定义要素是它们代表了顾客期望满足其需求的最小价值，以非常细粒度的切片交付。这种粒度确保每个增量足够小，可以快速开发和部署，从而实现频繁反馈和持续改进。这个概念与 Lean 理念一致，旨在消除顾客不重视的活动中的浪费和限制。

MVI 在业务价值待办事项列表中被识别、优先排序和精炼。参与的 BLAST 团队按优先级从待办事项列表中拉取工作。优先级的设定基于客户需求，并确保为支持未来基于价值的交付所需的必要元素按正确的顺序排列。拉取低优先级 MVI 的团队会进行某种形式的局部优化，这可能是由于偏好或技能所致，从而妨碍了组织高效交付整个增量价值的能力。另一方面，我们不能指望营销团队去处理软件开发任务。在 BLAST 中，团队从单一的业务价值待办事项列表中拉取工作项。但在待办事项列表中进行分段是必要的，以便协调跨价值流的不同工作，以支持每个发布周期的工作。

最小有价值发布（MVR）

虽然 MVI 可能为客户提供功能，但在某些情况下，将多个 MVI 捆绑在一起可能更具优势。这种捆绑可以服务于多个目的：降低发布的整体交易成本，从市场营销角度创造更显著的功能影响，或者使客户更容易吸收新功能，而不会因不断出现的新特性和功能而感到不堪重负。

当交易成本，无论是对于客户还是发布公司来说，都很高时，将多个 MVI 捆绑在一起可能是必要的。此外，如果需要更大的影响力，可能需要将多个 MVI 捆绑成一个集成解决方案。因此，BLAST 实施了 MVR 概念，以协调新功能、特性和流程的发布，并确保按照计划的节奏进行发布。关于这一点如何运作的更多细节将在下一章中探讨，第九章，为企业定义业务敏捷系统（BASE）。

BLAST 的一个显著优势，无论是在 MVP、MVI 还是 MVR 的工作中，都是它所创建的对齐，使得快速反馈循环成为可能且成本低廉。简而言之，BLAST 的 MVP 和 MVI 确保了价值交付始终处于最前沿，弥合了开发愿景与实际客户利益之间的鸿沟。

这部分结束了我们对 BLAST 三个构件：MVP、MVI 和 MVR 的讨论。同时也结束了对 BLAST 框架基础概念和基本要素的回顾，简而言之，它包括在四个核心工作领域中的十七个步骤中，协调多个精益敏捷团队的工作，涉及三种支持角色和三个交付构件。这些构件是 BLAST 团队通过 BASE 框架为企业向客户增量交付价值所产生的交付物，我们将在下一章中讨论第九章，为企业定义业务敏捷系统（BASE）。但本章还有更多内容需要讨论，我们将继续探讨支持基于价值的交付所需的节奏和步调。

优化开发节奏与价值交付

精益和敏捷环境中的节奏并不是新概念。敏捷使用迭代增量开发（IID）模型来建立快速开发和交付节奏，以 Scrum 中的 Sprint 为例。而精益则专注于价值流动，生产目标是建立与 takt 时间相匹配的节奏。德语中的 takt 意为脉搏或节拍，旨在将生产能力与客户需求对齐。

这时，我们开始看到 Scrum 与精益理念中的节奏之间的差异。例如，Scrum 指南建议 Sprint 长度固定为一个月或更短，强调在选择的周期长度上保持一致性。相反，精益流程可能会有显著变化，根据开发工作的规模和复杂性，可能会更短或更长。例如，现代 CI/CD 流程中的任务可能会以秒、分钟或小时为单位，而精益生产线上的大型飞机或船只的生产周期则可能以月到年为单位测量。此外，在精益环境中，takt 时间会根据客户需求动态变化。

在精益敏捷环境中同步节奏的概念成为一个关键问题，本节将向你展示如何解决这一问题。作为初步提示，精益敏捷组织会在规划层面建立跨周期的节奏。

强调在精益敏捷节奏中以客户为中心

Scrum 和 BLAST 都强调客户至上的重要性。正如 Scrum 从一个按优先级排列的产品待办列表开始，包含用户故事和功能，BLAST 则融入了一个强调客户旅程的业务价值待办列表，将客户需求和感知置于核心位置。

《Scrum 指南》和 SAFe® 精要

《Scrum 指南》可以在 scrumguides.org/scrum-guide.html 查阅更多关于 Sprint 及其事件的信息，因此我们无需在这里重复。此外，你可能会发现 SAFe Distilled 5.0: Achieving Business Agility with the Scaled Agile Framework（由 Richard Knaster 和 Dean Leffingwell 编写）是一个极具价值的资源，适用于在多团队、规模化环境中应用 Scrum。它还包括了 Scrum 事件与精益理念的详细概述。

虽然 Scrum 通过独立的 Sprint 周期运作，并通过演示和回顾反馈每个周期的成果，但 BLAST 采用了更为连续的方法。作为一个闭环系统，BLAST 持续评估客户需求，指导产品待办事项和优先级的迭代更新，贯穿产品经济可行的生命周期，确保持续与价值交付保持一致。这种共同的关注点强调了一个共享的信念：理解客户需求至关重要。

敏捷的迭代方法体现在 BLAST 对持续交付周期的坚持上。尽管 BLAST 的时间限制团队（Timeboxed Teams）在类似 Scrum 的迭代周期中工作，但存在一个关键区别。尽管 Scrum 引入了精益原则以减少浪费，但它并未完全涵盖精益流的概念。事实上，可以轻易地认为 Scrum 实施的是批量处理，因为冲刺待办事项在每次冲刺的开始和结束时以批量方式进出。

相比之下，精益流概念强调的是平稳、连续的价值交付，力求减少延迟和摩擦。BLAST 确保价值的高效交付，并缓解传统开发中的常见瓶颈。这种对流的坚持加强了 BLAST 在整合精益和敏捷实践方面的全面方法。

在下一节中，我们将更仔细地探讨开发和生产周期作为各自独立但同样重要的节奏，如何在精益-敏捷工作环境中发挥作用。

在现代软件开发中采纳精益流程

正如本小节引言所述，Scrum 指南明确规定冲刺是一个固定时长的事件，最长为一个月。15 这一推荐的时长没有变化。变化的是软件开发的速度，得益于 CI/CD 和 DevOps 管道支持的集成工具链与自动化能力，以及基于微服务的架构。

例如，Google DORA 加速 DevOps 状态报告 2023突显了不同性能层次之间在部署能力上的巨大差距。DevOps 领域的顶级表现者实现了按需部署频率，保持变更交付时间少于一天，变更失败率为 5%，且能够在一小时内恢复服务。相比之下，低绩效者的部署周期为每周到每月一次，面临令人惊讶的 64%的失败率，并且部署恢复时间可能长达六个月。16 这一差距突显了顶级开发者和低层开发者之间的差异，前者熟悉最新的软件开发方法、测试自动化以及集成工具链，而后者可能尚未完全采纳这些进展。

尽管软件开发的速度和效率发生了深刻的变革，但我们仍需重新校准对敏捷中冲刺目的的理解。最初设想时，Scrum 的冲刺并没有直接映射到精益导向的产品交付流程中的端到端开发周期。相反，它们在为团队提供一个一致的节奏方面起到了基础性作用，使团队能够优先安排、规划、执行和反思他们的工作。这种节奏确保团队能够定期将工作与业务需求对齐，根据反馈进行必要的调整，并交付增量价值。

因此，尽管精益强调高效的流程，特别是通过集成系统、工具和工作流自动化得到增强，敏捷则强调迭代和增量规划与执行周期的价值。因此，在 BLAST 框架中，冲刺作为规划和执行周期的固有性质保持不变，即使整体交付速度和流程效率有所提升。

正如我们探讨软件开发不断变化的动态一样，很明显，节奏和流程是现代精益-敏捷实践的核心。有了这个基础，我们现在可以充分探讨拥抱这些节奏和韵律的重要性，以利用精益-敏捷企业的力量。

寻求一种新的价值交付模型

在精益-敏捷企业中，价值交付依赖于跨越从总体战略工作到日常运营的多个韵律。下一小节将更深入地探讨规划和执行周期，突出它们在成功的精益-敏捷企业中的重要性。

为了全面理解精益-敏捷的产品交付方法，我们需要一个模型，来展示从想法的起始到其作为过程、产品或服务的实际化的进展。稍后我们将在本节中介绍这个模型。在介绍该模型之前，让我们先介绍一些基本概念。

一个集成的精益-敏捷交付过程根植于企业战略，并受到市场需求和客户洞察的塑造。最初，我们可能会被商业和产品想法所淹没，但许多想法可能永远无法实现。同时，现代 DevOps 流水线通过集成工具链和自动化增强了软件开发和交付能力。因此，定义需求和交付它们之间的差距只会扩大。好消息是，BLAST 方法阐明了实现高效软件交付生态系统的机制。

从概念上讲，我们可以用漏斗的隐喻来说明产品、服务或支持业务的过程、系统和工件的起始阶段可能充满了多种潜在的探索方向。然而，时间、资源、风险和市场动态等因素将逐渐缩小这些选择。最初，我们并不知道需要交付哪些产品和服务，也不清楚所需的能力、功能和特点。这个阶段一切仍然模糊不清。认识到这种不确定性对于确保我们 DevOps 流水线的持续、有效供应至关重要。

为了有效管理需求的流动，我们利用不同的规划视野。这些视野帮助我们构建需求评估和细化的方式。长期规划视野侧重于与公司战略和市场需求对齐，确立高层次的目标和任务。中期规划视野将这些目标转化为具体的工作项，并在待办事项中进行优先排序。短期规划视野确保团队有明确的、可操作的任务，准备好进行开发。这种结构化的方法确保了随着想法通过筛选器的推进，它们会不断被细化，并与战略目标对齐，从而提高我们的交付效率。

然而，通过一系列规划视野来定义价值，并不仅仅是支持现代软件交付能力。高层管理者常常面临各种投资建议来支持业务，但通常缺乏足够的财务和人力资源来满足所有需求。因此，组织需要一个规划过程来恰当地审核、优先排序并资助那些能带来最大价值的项目。本节的重点是定义支持这些审核和细化活动的规划流程。在这里，您将学习如何实施推动企业全面发展的多维节奏。在精益敏捷的背景下，我们称这些节奏为节奏。

我们已经注意到，在规划的初期阶段，业务和产品需求是模糊的。这个问题非常重要，以至于我们给它起了个名字：模糊的前端。

驯服模糊的前端

模糊的前端（FFE），是 Smith 和 Reinertsen 在他们的著作《半时间开发产品》中提出的一个术语，描述了需求发现和细化的初始阶段，这一阶段通常不透明，且对软件开发提出了独特的挑战。17 这一阶段可能充满不确定性，需要持续的探索，而且无法轻易自动化。需求的识别、分析和优先级排序与 1998 年 Smith 和 Reinertsen 出版书籍时一样具有挑战性。

我们将在本章的其余部分频繁回顾这一概念。现在，让我们把注意力重新集中到节奏这一话题上。我们已经简要提及过这个问题，但我们将探讨这些节奏如何在各个规划视野中延伸，影响业务领域的方方面面。

精通精益敏捷的规划与交付节奏

本小节阐述了在精益敏捷企业中规划节奏的战略重要性。尽管迭代规划在今天这个以持续流动和快速交付为特点的精益敏捷环境中似乎已经过时，但这些节奏对于寻求建立和保持竞争优势的组织依然至关重要。

频繁的基于节奏的规划确保组织能够迅速响应市场需求，通过不断补充开发管道，提供面向客户的产品、服务提升以及业务流程和系统改进。此外，这种规划促进了多个团队之间的同步，推动对齐和跨职能协调，包括团队之间的依赖关系和集成的管理。

在你阅读本小节时，参考 图 8.4 获取更多关于迭代规划增量的细节，这些增量支持现代 Lean-Agile 软件交付管道，采用高度集成和自动化的 CI/CD 和 DevOps 工具链。这些规划过程和时间框架概念同样适用于评估所有商业投资机会。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_08_4.jpg

图 8.4 – 现代软件产品生命周期模型

精简待办事项精炼

我们之前介绍了 模糊前端 概念，它是成功进行产品需求分析的关键因素。这个启动阶段代表了初步需求捕获过程，这一过程抵制通过自动化或系统工程进行简化。在软件开发组织中，如果这个阶段没有得到有效解决，可能导致待办事项中缺乏支持高效和加速的 DevOps 软件开发管道所需的工作，从而使这些工作线无法得到支持。

组织通过 企业战略 和 产品组合管理 活动来解决模糊的前端问题，以制定高层次的目标和任务。然而，战略不仅限于高层管理。产品管理的职责是具有战略层面的责任，将高层管理人员的产品愿景转化为具体的工作项，通常以史诗的形式呈现。他们的工作启动了 待办事项 精炼 过程。

如在 MVI 规划（第 3 和第 4 步） 部分所述，史诗（Epic）是一个大型工作项，可以被拆解为多个较小的需求集合，通常以用户故事和技术故事的形式呈现。史诗可能跨越多个迭代或冲刺，包含一个重要的特性或需求，一旦完成，能够为业务带来显著的价值。

价值经理和产品负责人支持 BLAST 增量规划 过程，确保史诗被拆解为故事、精炼并优先排序以进行交付。他们还与 BLAST 团队合作，在集成增量过程中进行规划并提供指导。

开发人员负责协助精炼过程，并定义构建和交付解决方案组件所需的任务。故意的设计和架构活动必须在待办事项精炼和 BLAST 增量规划阶段的早期开始。

在 BLAST 中，待办事项列表的完善概念超越了 Scrum 实践，因为在高效的 Lean-Agile 组织中，提前启动这一过程更加重要。此外，在大型企业或复杂解决方案中，管理需求通常在实际开发之前很久就开始了。

管理创意和创新

使用之前在图 8.4中说明的漏斗概念，我们将完善过程设想为从一组广泛的潜在价值流过程、产品想法和基础设施开发选项开始，然后通过连续的规划增量逐步缩小范围。

然而，漏斗中的许多想法由于成本和优先级的考虑将被舍弃或推迟。这并不一定意味着它们是糟糕的想法；相反，它们可能在当前的时间框架内不相关。我们可以将我们的漏斗想象成有泄漏的地方，某些想法和概念会逃脱我们的即时注意。为了确保这些想法不会丢失，我们还可以想象漏斗下面有一个排水盘，捕捉这些想法以便在以后参考。

管理这些创新想法以供未来参考需要一个结构化的方法。这就是InnovationOps 数据库概念的作用，它作为构建和管理一个集中系统的基础，旨在跟踪组织内与创新相关的项目、活动和数据。虽然 InnovationOps 是创新管理中的一个关键方面，但其实施的详细讨论超出了本书的范围。

促进 BLAST 增量期间的协作与规划

在 BLAST 集成增量的规划和执行阶段，关键参与者如价值经理（产品负责人）、UI/UX 开发人员和首席开发人员会进行深入的合作。他们处理包括可用性、设计、基础设施和架构等方面的关键任务。这种合作还扩展到定义用户故事和验收标准，并开发 UI 原型供评审人员在开发开始前进行评估。这个准备阶段至关重要，因为这些完善工作对于为即将到来的团队规划会议奠定坚实的基础至关重要。

当开发团队接管时，他们的规划活动通常是简洁的，通常仅持续几个小时。这种精简的规划只有在初步的产品规划增量工作充分完成的情况下才是可行的。在已经掌握了详细的完善信息后，开发团队可以专注于确定即将到来的 BLAST 增量的具体任务和工作量，分配任务，并明确构建要求和验收标准。这是一个简单的原则：来自业务价值待办事项列表的项目，如果尚未完善，就不能安排进入即将到来的 BLAST 增量的待办事项列表。

这一系统化方法确保了我们的开发管道始终保持充足的、定义明确、可立即工作的条目，从而防止了在持续流动的客户价值中出现延误。通过在集成增量之前精炼待办事项清单，我们赋能团队保持精益敏捷成功的动力，推动满足并超越竞争市场需求的可持续交付周期。

在图 8.4中，有一条注释指出，模糊前端是难以预测、估算和自动化的。自从唐·赖恩特森在 1985 年发表的文章《闪电战产品开发：将开发时间缩短一半》中提出这一术语以来，情况并没有太大变化。然而，借助人工智能，一些进展正在解决这些问题。

拥抱人工智能进行发现

需求发现过程正在借助人工智能和机器学习不断演变。虽然基于人工智能的决策引入了不确定性，但利用算法分析数据并预测结果能够提高效率。找到利用人工智能力量与保持人类监督之间的平衡至关重要。

以下是一些人工智能如何被用来解决软件开发中需求分析挑战的例子：

• 自然语言处理（NLP）

• 自动化需求提取

• 一致性和冲突检查

• 优先级排序和影响分析

• 预测分析

• 需求验证

这些人工智能应用提升了软件开发中需求分析的准确性、效率和有效性。然而，某些人工智能模型的“黑箱”特性引发了关于透明度、可解释性和责任归属的问题。组织必须小心应对这一局面，在拥抱人工智能潜力的同时，降低风险。最终，人类直觉与人工智能驱动的洞察力的协同作用将塑造需求收集和创新的未来。

我们已经覆盖了有效将战略和创意转化为可操作工作项所需的规划节奏。现在，让我们更清晰地了解涉及的时间和精力。

探索规划视野

在产品开发和持续改进过程中，组织始终面临着如何应对需求分析中模糊的前期阶段这一挑战。当创意浮现并逐渐成型时，它们自然从抽象概念转变为具体计划。如果没有结构化的方法，这一过渡可能变得混乱，导致努力方向不一致和错失机会。

重要提示

为规划视野加入敏捷视角至关重要。对于成熟的流程、系统、产品和服务，新客户和业务需求可能迅速出现，并具有较高的优先级。如果这些变更符合已批准的战略和投资组合，产品管理职能可以通过将它们纳入商业价值待办事项清单来加速处理。

为了应对这一挑战，必须采用一种利用规划节奏的方法，如图 8.5所示。该方法不仅简化了开发过程，还确保了价值流改进举措始终关注最终用户真正关心的事项，且团队在正确的时间构建正确的产品。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_08_5.jpg

图 8.5 – 企业规划视野

图 8.5 展示了一个扩展的、时间框定的视图，基于图 8.4中介绍的漏斗概念。此图表明了一个清晰的规划顺序，增强了组织交付产品和服务的能力。

解决了这一问题后，让我们来看看图 8.5中展示的规划视野：

• 产品路线图与投资组合投资（长期，1-3 年及以上）：高层管理人员维护产品路线图，概述实现组织战略目标所需的未来投资（产品和服务）。同时，投资组合管理确定支持这些产品和服务所需的投资。

• 商业价值评估（中期规划，当前财政年度内）：将战略转化为可操作的计划，产品和营销经理进行研究，并与行业专家、客户及开发团队合作。他们的目标是识别、定义并优先排序商业价值待办事项中的产品和服务。

注意事项

商业和技术架构师通过提供流程、系统、基础设施和架构需求的初步评估来支持这一阶段。

• 增量计划（短期规划，8-12 周内）：进入战术实施阶段，价值经理（产品负责人）在设计和开发团队的输入下，与利益相关者和客户一起完善待办事项中的工作项。

• 团队计划（1-4 周内）：随着需求在待办事项中得到精炼和优先排序，开发团队需要时间评估需求并定义任务以构建工作项。

• 每日计划：在 BLAST 解决方案构建期间，根据需要安排频繁的会议，以检查与目标的进展，并解决任何阻碍进展的挑战。将这些会议的时间限制为不超过 15 分钟，避免将其变成工作会议。工作会议应单独举行。

回顾图 8.5，我们可以看到这些节奏的相互关联性。每个节奏在产品和服务开发中都扮演着至关重要的角色。

以下小节讨论了集成增量及其在同步多个精益敏捷团队和跨不同业务领域的多个 BLAST 中的重要性。在深入下一章 第九章 —— 为企业定义商业敏捷系统（BASE） 之前，这些概念是需要理解的关键内容。

促进规模化协作——团队之团队方法

在 Lean-Agile 企业中，业务运作的规模和复杂性可能会带来确保团队间无缝协作和对齐的挑战。团队之团队的概念旨在通过创建一个结构化的 ToT 协作机制来解决这个问题。

这种方法的核心是来自各个团队的代表。之前我们提到过几种实施类似角色的规模化 Scrum 方法，例如 Scrum of Scrums™中的大使（Ambassador）和 Nexus™框架中的 NITs。不管你选择称呼它们为什么，这些代表会定期聚集在一起，连接不同的团队，形成一个确保全企业协作的合作实体。这个 ToT（团队之团队）沟通结构有助于管理依赖关系、无缝集成，并保持所有相关团队的同步。这个结构的好处包括：

• 解决依赖关系：随着团队在相互关联的任务上工作，涉及依赖关系、集成和同步的问题不可避免地会出现。团队之团队结构中的代表确保这些问题能早期被识别并有效管理，从而避免瓶颈并确保顺利交付。

• 确保 ToTs 的集成：集成点在大规模项目中至关重要。BLAST 的 ToT 规划和回顾会议应该安排有资格的代表参与，以解决业务和技术集成问题。

• 对齐/协调努力：当多个团队朝着共同目标努力时，协调变得至关重要。团队之团队方法确保同步的努力，各团队了解彼此的进展、挑战和即将到来的里程碑。协调通常是昂贵且容易出错的。BLAST 框架实施了一个共享的业务价值积压，以改进跨 BLAST 工作项对齐和优先级排序。

• 共享学习和最佳实践：代表们可以分享他们团队的学习成果、遇到的挑战以及采用的最佳实践。这种集体智慧提高了效率，并促进了持续改进的文化。

• 风险缓解：在团队之团队层面讨论挑战和潜在风险，可以主动解决问题，确保各个团队不会面临意外的障碍。

• 频繁沟通：团队成员和利益相关者之间的定期且清晰的沟通对于目标对齐、进展共享和及时解决问题至关重要。

• 持续改进：团队应定期审视他们的流程和结果，以识别改进机会并实施必要的变更，以提高效率和效果。

BLAST 并未为这些代表定义精确的角色或责任集。这是因为代表的数量和技能会根据所涉及的领域、技能以及讨论的业务背景在精益敏捷组织中不断变化。

为了澄清它们的角色，你可以选择称这些 BLAST 代表为 BLAST 协调员，或者简单地称其为 协调员；它们的协作工作会议为 BLAST 会议；它们的社交网络为 BLAST 中心。然而，选择权在于你。可以根据你的喜好自由地称呼这些代表和他们的会议。简而言之，BLAST 实现了 协调员、会议 和 中心。

在下一小节中，我们将更详细地讨论 BLAST 协调员解决的几种常见问题类型。

确保项目的无缝交付

在本章以及后续章节中，我们频繁提到在团队合作环境中，团队和个人必须解决由跨团队任务管理所带来的依赖关系、集成和同步问题。让我们花点时间来定义这些问题在 BLAST 或多 BLAST 工作环境中的表现形式：

• 跨团队任务：以某种方式相互关联或依赖的任务

• 依赖关系：一种任务依赖于另一个任务完成的情况

• 集成问题：将不同组件或系统结合以协同工作时出现的挑战

• 同步问题：协调任务的时间安排和顺序以确保它们无缝协作时出现的问题

通过专注于这些关键领域，BLAST 团队可以提升协作，减少障碍，并推动成功的项目结果，最终实现他们的战略目标。BLAST 协调员方法作为一个桥梁，确保各个团队虽然保持独立性和专注，但更高层次的协作机制使整个企业保持一致、集成，并协调前进。

我们将在后续章节讨论 BLAST 角色。但首先，我们需要理解 BLAST 中增量的概念及其如何支持流程、业务系统、产品或服务的生命周期。

理解生命周期管理中的增量

在 图 8.1 中，增量 这个术语，更准确地说是 增量规划，作为产品生命周期管理的基石凸显出来。通常持续 8-12 周，这一时期涉及价值经理（或产品负责人）与利益相关者积极合作，优化需求，以便在近期提升业务流程、系统、产品和服务。

然而，价值经理的角色不仅仅是确保交付客户所需的内容。他们还通过精益的视角评估价值，旨在消除浪费、去除制约因素并提升流程。

正如我们在下一节中将要学习的，产品所有者的角色不仅仅是嵌入所需的特性；快速而高效地交付这些特性同样至关重要。这需要对组织的价值流进行改进。在这种情况下，我们更倾向于将该角色视为价值交付经理或价值经理，而不仅仅是产品所有者。

在精益方法中，增量的意义不仅限于产品开发导向的价值流。新的业务和客户价值的发布通常需要跨多个领域和价值流的协调努力，这凸显了这一概念的综合性。

这部分结束了我们对精益敏捷节奏实施的讨论。接下来，我们将讨论精益敏捷管理实践。

拥抱精益敏捷管理实践

管理，在敏捷环境中常被误解，在精益敏捷工作环境中扮演着多重角色，具体包括以下内容：

• 改善工作环境：为团队创造有利的成长环境

• 资源分配：确保团队拥有必要的人员、资源和信息

• 人员发展：提供职业指导和自我提升

• 协作：与同事协调以确保跨职能效率

• 对股东的受托责任：管理层还负有对公司股东履行受托责任的义务，确保决策和行动与长期价值创造和可持续增长一致。

在精益敏捷工作环境中，管理的主要视角是认同团队成员在任务中积极参与的知识与专业技能。信任团队和个人至关重要，但也需要保持一定的监督，以防止潜在问题的发生。

支持精益敏捷管理

W. 爱德华兹·戴明恰当地说过：“系统必须被管理，它不会自我管理。”在一个组织中，管理是背骨，连接战略愿景与现场的实际执行。管理在将组织目标与实际执行对齐方面扮演着核心角色，这一概念被称为中上行管理。

中层管理通常被视为精益敏捷转型的障碍，但它们可以成为积极变革的催化剂。中层管理的独特位置使他们能够将总体战略转化为可操作的活动，这使他们在转型和精益敏捷方法的持续成功中发挥着至关重要的作用。他们传达战略愿景，同时也融合来自前线操作的见解。

在 BLAST 的转型模型中，中层管理不仅仅是监督变革，还积极参与其中，成为领导力动态演变的先驱。

所有管理者必须接受并支持精益敏捷实践。管理层必须花时间了解员工面临的问题，并确保采取尊重、包容和合作为核心的方式。

利用中层管理推动组织敏捷性

Scrum 由 Jeff Sutherland、John Scumniotales 和 Jeff McKenna 于 1993 年首次在 Easel Corporation 提出，灵感来自 Takeuchi 和 Nonaka 于 1986 年发布的 HBR 文章《新新产品开发游戏》，该文将新的开发策略与橄榄球比赛做了对比。18

Middle-Up-Down Management（中上到下管理）的基础原则在 Nonaka 1988 年的著作《迈向中上到下管理：加速信息创造》中进行了详细阐述。19 这一管理方法将信息的系统处理——这是已建立组织的特点——与敏捷实体中的动态信息创造相结合。其核心是中层管理在指导与业务目标对齐的组织转型中的作用。

明确地说，BLAST 中的精益敏捷（Lean-Agile）方面承认并拥抱了精益管理的核心思想。在精益哲学中，管理被视为一种重要的积极力量，而不是进步的阻碍者。这就结束了关于拥抱精益敏捷管理实践的部分。在我们结束本章之前，让我们了解一下 BLAST 的历史。

BLAST 的历史追溯

BLAST 于 2008 年在 Al Shalloway 与一位有效使用 Scrum 但无法快速交付的客户合作时构思出来。虽然各团队在同一产品上工作，但他们是独立运作的，并且每两周才进行一次集成。这导致了较长的最终集成时间。

通过将工作视为一个单一的价值流，而不是分散的基于敏捷的团队，迅速发现，采用一个共同的待办事项清单能够实现团队之间的对齐，并促进每个冲刺后的全面集成。BLAST 方法消除了大量协调的需求，加快了集成过程，并为团队提供了快速反馈。

这个现实世界的例子展示了 BLAST 如何改变团队运作，并显著提高效率和交付速度。今天，这种方法也更好地适应了通过 CI/CD 和 DevOps 工具链实现的高效软件交付。

注意：

BLAST 和 BASE 这两个术语由作者 Al Shalloway 和 Gary Rupp 于 2022 年 5 月的联合工作会议中创造。

本章到此结束。在继续之前，让我们总结一下你所学到的内容。

概述

本章介绍了 BLAST 作为一个框架，并指导如何将精益的高效性与敏捷的适应性相结合。我们讨论了随着业务需求不断变化的必要性，并探讨了 BLAST 如何增强敏捷方法论，提供了一种从概念到实现的可操作方法。我们回顾了如何利用 BLAST 的复杂性，以及它与 Scrum 模型的异同，同时也了解了其角色和工件。

理解和实施 BLAST 对那些希望保持竞争力的组织至关重要。它确保了及时的价值交付，并将成本降至最低。

展望未来，在第九章《为企业定义业务敏捷系统（BASE）》中，我们将过渡到精益-敏捷实践中的产品生命周期。重点将放在 MVP、MVI 和 MVR 的开发上。BASE 框架定义了一个系统化的事件周期，确保通过持续的过程改进和产品增强实现迭代和增量的价值交付。你还将学习到 BASE 如何促进跨价值流的团队合作。

问题

本节适用于那些希望评估自己对本章内容理解和记忆的人。这里有 10 个问题，答案将在后续章节中提供。回忆原文的具体用语并非关键，更重要的是回忆概念及其应用。

1. 精益管理的三个方面是什么？

2. 精益管理中的管理概念在敏捷实践中有哪些典型表现？

3. 定义 BLAST 框架以客户为中心的基础的两个步骤是什么？

4. 在 BLAST 框架中，定义规划、完善和承诺活动的三个步骤是什么？

5. 包括六个步骤的三个 BLAST 概念，涉及 BLAST 框架中精益-敏捷工作流整合的内容是什么？

6. 包含六个步骤的三个 BLAST 概念，用于评估和增强产品交付成果的是哪些？

7. 什么是模糊前端，为什么你需要关注它？

8. BLAST 框架中定义的三种主要角色是什么？

9. BLAST 框架中的三个工件是什么？

10. 对错：BLAST 框架有 17 个事件。

答案

1. 精益管理的三个方面是：传统层级结构可能仍然存在、以身作则和专注决策。

2. 在敏捷实践中，典型的管理概念包括扁平化结构、分散决策、服务型领导和持续反馈循环。

3. 定义 BLAST 框架以客户为中心的基础的步骤是：客户中心化（第 1 步）和业务价值待办事项（第 2 步）。

4. 定义规划、完善和承诺活动的 BLAST 框架步骤包括 MVR 完善（第 3 步）、BLAST 规划（第 4 步）和承诺待办事项（第 5 步）。

5. BLAST 框架中的精益-敏捷工作流整合概念包括流动团队和时间限定团队（第 6 和第 7 步）、每日回顾和工作流轨迹的回顾与完善（第 9 和第 10 步），以及 BLAST 整合（第 10 和第 11 步）。

6. 用于评估和增强产品交付成果的三个 BLAST 框架概念步骤包括集成增量和集成增量回顾（第 12 和第 13 步）、反馈与调整（第 14 步）以及 BLAST 对 CX 的改进（第 15 到第 17 步）。

7. 模糊前端之所以重要，原因如下：

   由 Preston Smith 和 Donald Reinertsen 于 1991 年推广的模糊前端，指的是在确定需要构建的内容时的模糊阶段。除了比我们可能希望的更多时间，随着想法的出现和形成，从抽象概念到具体计划的自然演变。在没有结构化方法的情况下，这一过渡可能会变得混乱，导致工作方向不一致和错失机会。

8. 三个 BLAST 框架角色分别是价值经理、开发者和教练。

9. 三个 BLAST 框架工件是最小可行产品（MVP）、最小有价值增量（MVI）和最小有价值发布（MVR）。

10. 错误。然而，这个问题有点难度。BLAST 并不包括事件的概念。相反，BLAST 有 17 个步骤。与使用“事件”一词的 Scrum 不同，BLAST 使用“步骤”一词来表示行动和进展。

进一步阅读

1. 1Knaster, R., & Leffingwell, D.（2020）。《SAFe Distilled 5.0：通过精益敏捷框架实现业务敏捷性》。Addison-Wesley Professional。

2. 2Reinertsen, Donald G.《产品开发流程原则：第二代精益产品开发》。Celeritas Publishing，2009 年。

3. 3Reinertsen, Donald G.《产品开发流程原则：第二代精益产品开发》。Celeritas Publishing，2009 年。

4. 4https://scaledagileframework.com/decentralize-decision-making/。2024 年 4 月。。2024 年 4 月。

5. 5 SAFe® 和 Scaled Agile Framework 是 Scaled Agile, Inc. 的注册商标。

6. 6https://scaledagileframework.com/decentralize-decision-making/。2024 年 4 月。。2024 年 4 月。

7. 7SAFe® 和 Scaled Agile Framework 是 Scaled Agile, Inc. 的注册商标。

8. Shewhart, W. A.（1931）。《制造产品质量的经济控制》。纽约：D. Van Nostrand 公司。

9. 9Deming, W. E.（1986）。《走出危机》。剑桥，MA：MIT Press

10. 10Liker, J. K., & Morgan, J. M.（2006）。《服务中的丰田方式：精益产品开发的案例》。管理学会视角，20（2），5-20

11. 11Liker, Jeffrey K.（2004）。《丰田方式：世界上最伟大的制造商的 14 条管理原则》。纽约：麦格劳-希尔。

12. 12 丰田生产系统：“丰田方式”和劳资关系。（2006）

13. 13Ries, E.（2009 年 9 月 8 日）。《最小可行产品：指南》。Startuplessonslearned.com。2023 年 10 月 31 日检索，自 https://www.startuplessonslearned.com/2009/08/ minimum-viable-product-guide.html

14. [14Ries, E.（2010）。精益创业：当今企业家如何利用持续创新创造出极为成功的企业（第 1 版）。Crown Business，Crown Publishing Group 的一个印记，Rando House 公司，纽约。]

    注意：如果你想了解更多关于 Scrum 和精益思维的内容，可以在以下注释中找到 Cecil Rupp 的书籍链接。此外，Al Shalloway 的 AMPLIO 在线书籍提供了关于 BLAST 的详细信息，网址为successengineering.works/books/.

15. [15Schwaber, K., & Sutherland, J.（无日期）。2020 年 Scrum 指南™。SCRUM 指南。从 2023 年 10 月 10 日获得，网址为www.scrum.org/resources/scrum-guide。 ]

16. [16DevOps 研究与评估（DORA）。(2023)。加速 DevOps 状态报告。Google Cloud。从cloud.google.com/devops/state-of-devops获取。](B21818_08.xhtml#endnote-016-backlink)

17. 17P. Smith 和 D. Reinertsen，《在一半时间内开发产品》，纽约，NY：约翰·威立与儿子出版社，1998 年。

18. 18 竹内弘高（H. Takeuchi）与野中郁次郎（I. Nonaka）。(1986)。全新的产品开发游戏。《哈佛商业评论》，64(1)，1–10。

19. 19 野中郁次郎（I. Nonaka）。(1988)。面向中上管理：加速信息创造。《斯隆管理评论》，29(3)，9-18。

第九章：定义企业敏捷系统（BASE）

“敏捷性是适应和响应变化的能力……敏捷的组织将变化视为机会，而非威胁。”

–吉姆·海史密斯

无论你是在商业企业、非营利组织还是政府机构工作，保持竞争力和相关性都需要具备快速适应和创新的能力，以满足并超越客户的期望。那么，组织如何才能在不断变化的环境中不仅生存下来，还能蓬勃发展呢？本章介绍了企业敏捷系统（BASE），这是一个旨在将不确定性转化为机会的模型。BASE 通过协调公司各方面的资源，推动持续改进，从而提升业务流程、系统、产品和服务。

根据企业敏捷研究所的定义，商业敏捷性是“一组赋予企业自由、灵活性和韧性以实现其目标的组织能力、行为和工作方式。”同样，SAFe®定义商业敏捷性为“通过迅速响应市场变化和新兴机会，利用创新的、数字化的业务解决方案在数字时代中竞争并蓬勃发展。”

我们的世界正在迅速变化，这要求企业采用创新的方法进行产品开发。在 BASE 模型中，Lean 的流动导向实践提高了生产力、效率和质量，而 Agile 的时间框架实践则帮助组织实施以假设为驱动的创新、价值交付和数字化转型方法。BASE 通过协调多个基本精益敏捷解决方案团队（BLASTs）的活动，按节奏交付新的价值增量。这一方法涉及信息收集、决策制定和实验的持续循环，旨在以现有资源优化结果。

本章将介绍如何通过 BASE 概念模型促进企业范围的协作，并优先进行以客户为中心的价值交付。BASE 还实施了一种整体方法来交付集成增量，协调跨业务职能和价值流的努力。它具有一个良性循环，模型中的每个积极事件都会加强下一个事件，推动持续改进。本章描述了 BASE 如何塑造企业以客户为中心的价值交付方法，并包括以下主题：

• 理解 BASE 概念模型

• 建立以客户为中心的基础

• 在产品生命周期中交付价值

技术要求

理解本章内容不需要技术要求。然而，读者应该理解在第八章中提出的概念，实施基础精益敏捷解决方案团队（BLASTs），因为这些团队为增量实施新价值提供了结构和资源。Al Shalloway 的在线书籍（可在successengineering.works/books/中找到）也提供了有关 BASE 开发的详细信息，包括对 BLAST 框架的描述。

理解 BASE 概念模型

BASE 提供了一种精心设计的精益敏捷操作模型，旨在促进企业业务敏捷性。操作模型是一个全面的框架，定义了组织如何运作以为其客户提供价值并实现战略目标。它包括组织的结构、流程、系统和文化，详细说明了资源、技术和工作流程的协调，以支持其目标。

BASE 模型支持产品生命周期的动态特性——产品从概念到市场发布再到生命周期结束的各个阶段是不断变化且常常不可预测的。这种动态性可能由许多因素引起，如不断变化的客户需求、技术进步、市场竞争、监管变化以及在开发过程中收到的客户反馈。BASE 的目标是持续不断地提供新的客户价值，前提是继续支持该产品或服务在经济上是可行的。

一个 BASE 解决方案通常从最小可行产品（MVP）开始。组织应通过开发 MVP 来探索新的产品或服务概念，设计、构建并测试一组有限的预定功能、特性和能力，然后与客户和市场进行测试。MVP 有助于评估产品的潜力，并通过来自一个或多个目标市场的客户群体的快速反馈来评估其可行性。

BASE 实施了价值流，传递新的业务价值增量，从初始的 MVP 开始，接着是系列的最小可行增量（MVIs），如图 9.1所示。每个 MVI 都通过迭代和增量的方式改善业务流程、信息系统、产品或服务，随着时间的推移，为客户提供更多的利益。这将导致更高的感知价值，并且通常能在市场中提供竞争优势。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_09_1.jpg

图 9.1 – BASE 价值流中的产品开发

正如前段所述，MVI 也可以专注于实施业务流程、系统或其他业务支持工件的变更，这些变更竞争机构有限的资源；因此，业务优先事项必须与产品和服务增强一起作为业务价值积压的一部分进行评估。这就是为什么我们更倾向于将负责管理业务价值积压的人称为“价值经理”而不是“产品负责人”。

如第八章所述，实施基本精益敏捷解决方案团队（BLASTs），MVIs 经常不能提供完整解决方案，或者由于成本考虑不值得单独部署。此外，引入部分特性、功能或不完整流程可能会对客户满意度产生负面影响。因此，BASE 概念模型还包括最小可行发布（MVR）的概念，以便定期同步推出新的功能、特性和流程。

Figure 9*.2*展示了 BASE 概念模型，作为企业改进的良性循环，以客户为核心。客户及其购买旅程支持并资助我们的业务，确立了指导我们决策和业务运营的要求。我们业务的成功取决于我们迅速满足他们的需求或愿望的能力，同时有效控制成本。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_09_2.jpg

图 9.2 – BASE 的企业改进良性循环

当我们逐步深入这一部分时，我们将从描述 BASE 框架的外环开始，代表 BASE 四大原则，然后更详细地讨论每个原则。接下来，我们将描述从组合管理到企业战略的八大 BASE 核心流程，并总结 BASE 核心内部（价值流管理、价值流改进、产品负责人和价值经理以及客户旅程）。

但在我们开始审视 BASE 概念模型内定义的原则和流程之前，让我们首先了解为什么我们将这个模型称为持续企业改进的良性循环的原因。

定义持续改进的良性循环

持续企业改进的良性循环是一个自我强化的循环，其中每一个积极的行动都会导致进一步的增强和利益。在这种情况下，它意味着业务的一个领域的改进推动了整个企业的进一步改进，从而创造持续增强和价值创造的循环。

例如，一个组织投资分析其目标市场中的客户体验，并在营销方面吸引更多能够重视其产品和服务的客户。随着客户群体的增长，产品开发预算也增加，从而进一步投入到以客户为中心的产品改进以及相关的促销和销售策略，最终实现更高的收入和增长。这个循环过程在我们产品和服务的生命周期内不断进行。在这个例子中，请注意我们如何始终将客户放在中心，以确保我们的投资方向始终符合客户需求。

这个永无止境的循环带来了不断增加的益处，从而增强了下一个环节的正向效果。每个核心的良性循环活动都会影响价值流交付以客户为中心的价值的能力。因此，跳过任何一个良性循环活动都会影响组织通过创造产品和服务的价值流交付价值的能力。BASE 企业确保其战略和治理应用精益和敏捷的思维方式、原则和实践，以实现业务敏捷性。这使得企业能够快速且安全地应对变化。BASE 同样建立在两个核心原则之上。

基本核心原则

在进一步探讨良性循环之前，必须掌握两个核心且互为支撑的原则，这些原则为 BASE 模型提供指导：第一性原理和系统思维。它们为组织中的决策和问题解决提供了实践性的洞见：

• 第一性原理：这些是世界的基本机制，构成了逻辑推理和决策的基础。它们通过仔细观察和严格评估被发现。

  在精益敏捷实践中，第一性原理涉及专注于通过消除浪费和持续改进流程来为客户提供最大价值。忽视第一性原理可能会导致负面后果，例如效率低下和机会被忽视。秉承科学的思维方式，第一性原理要求我们质疑假设，基于证据发展理论，并通过验证来测试假设。

• 系统思维：这促使我们在考虑变革时，全面考虑整个系统，因为问题往往源自系统各组件之间的互动和接口，而非单一行为。因此，仅仅关注系统中的个别组件或问题通常是无效的。

  跨团队挑战通常源自外部因素、人员以及我们业务中的解决方案开发环境中的流程。至关重要的是，在这些元素之间培养协作，以便共同解决这些问题，而不是孤立地处理。此外，当管理层优先改善系统而非归咎于个人时，创造一个心理安全的环境将变得更加可行。

以下是支撑 BASE 概念模型并指导其实施的基本原理：

1. 满足客户需求并与组织目标对齐：成功通过为双方交付价值来实现。BASE 确保在整个企业中交付的各项计划优先考虑客户定义的价值。如果忽视这一核心原则，成功将受到威胁。此外，BASE 中的每个良性循环活动都整合了客户反馈，以指导决策并推动增量改进。

2. 将工作分配给小型、协作的团队，任务是交付以客户为中心的有价值增量：多个 BLAST 团队通过协调努力开发 MVP 和一系列 MVI，为 BASE 的价值创造活动做出贡献。关于 BLAST 的信息在上一章中已有涉及。

3. 利用数字技术扩展我们的流程、产品和服务：数字优化为提升运营效率、效果和竞争力提供了前所未有的机会。通过优先考虑数字优化，组织承诺探索、采用和创新数字解决方案。这一承诺提升了表现，为客户交付了更高的价值，并帮助企业保持可持续的竞争优势。

了解这些背景后，让我们对 BASE 良性循环及其重要流程进行高层次的概述。我们将从 BASE 的四个基本原则开始。

理解 BASE 的四个基本原则

图 9.1中的 BASE 图表的外圈展示了支撑组织 Lean-Agile 环境的四个基本原则。它们包括战略与执行、Lean-Agile 文化、假设驱动开发和业务敏捷性：

• 将执行与战略对齐确保组织专注于实现其使命和愿景。

• 建立 Lean-Agile 文化使组织能够同时管理竞争的生产和开发目标，同时保持运营效率，提高产出和质量，以适应和发展于动态商业环境中。

• 使用 MVP、MVI 和 MVR 的假设驱动开发建立了产出新增值的节奏。

• 最后，企业的业务敏捷性指的是组织快速有效地适应商业环境变化的能力。

让我们仔细看看这四个基本原则。

对齐战略与执行

战略与执行对齐确保组织目标能够转化为可执行的计划，从而实现高效进展，并保持对使命和愿景的专注。它对于成功至关重要，确保员工的日常活动和决策与战略目标对齐，形成一致的方式以实现商业目标。

这种一致性弥合了战略规划与执行之间的差距，要求在所有层级清晰传达公司的愿景、使命和目标。适当的一致性有助于员工理解他们的角色如何为更广泛的目标做出贡献。然而，许多公司在这方面存在困难，导致资源浪费和优先级冲突。研究表明，只有少数高级管理人员和一线主管能够将举措与公司优先事项联系起来。

为实现一致性，组织应专注于清晰的沟通，以确保战略在所有组织层级都能被理解。通过实施支持战略目标的角色来对工作进行对齐。培养一种员工对战略贡献负责的文化。定期根据业务结果和市场变化审查并调整战略。利用绩效管理系统，如目标和关键结果（OKRs）和关键绩效 指标（KPIs），追踪目标的进展。

专注于这些领域加强了战略意图与日常运营之间的联系，改善了战略执行，并增强了员工参与度。这个持续的过程使组织能够适应市场变化，超越竞争对手，实现长期目标。

培养精益敏捷文化

精益敏捷文化培养了持续改进和适应能力的思维方式，使团队能够快速响应变化，并高效地交付高质量的价值。它代表了一种变革性的组织管理方法，根植于精益思维和敏捷方法论的原则。此外，它优先考虑客户价值交付、减少浪费，并培养协作性强、适应性强的工作环境。在其核心，精益敏捷文化通过去中心化决策赋能团队，促进创新和快速实验。

精益敏捷文化的特点是以客户为中心，持续对齐与客户需求和偏好的努力。通过持续反馈循环实施迭代改进，进行渐进式增强。

去中心化决策赋予团队自主权，以推动创新和快速解决问题。透明度和开放的沟通建立了组织内的信任和一致性。跨职能协作打破了孤岛，促进了信息和创意的流动。

精益敏捷文化倾向于渐进式变革，偏好小规模、频繁的更新，而非大规模、风险较高的彻底改革。精益敏捷文化中的领导者充当促进者和教练，而非传统的指挥与控制型经理。他们支持团队授权和资源供应，同时倡导持续学习和改进。这种领导风格促进了一种环境，在这种环境中，适应性和成长成为组织文化的核心组成部分。

精益敏捷文化增强了组织的韧性和响应能力，提高了在复杂商业环境中应对挑战的能力。它使得产品和服务的上市时间更短，通过持续创新增加竞争优势，并确保持续交付卓越的客户价值。

通过采纳精益敏捷文化，组织能够在快速变化的市场、不断演变的客户期望和激烈的竞争面前蓬勃发展。这种方法不仅简化了运营流程，还培养了一支积极参与、富有创新精神并与公司战略目标保持一致的员工队伍。总之，精益敏捷文化代表了组织思维和实践中的一种强大范式转变。它为公司提供了在当今动态商业环境中脱颖而出的工具和思维方式，确保了持续的增长和客户满意度。

实施假设驱动开发

假设驱动开发（HDD）是一种将科学方法与敏捷实践相结合的强大产品开发方法。在其核心，它强调在投入大量资源进行开发之前，先要制定并测试关于用户需求、行为和产品特征的假设。假设驱动开发是一个结构化的过程，其中关于产品特性或用户需求的假设会经过严格测试。这个过程从识别关键假设并将其转化为明确、可衡量的陈述开始。定义度量标准来衡量成功，并设计和执行原型或 A/B 测试等实验以收集数据。通过分析这些实验的结果，确认或推翻最初的假设。根据这些发现，做出是否扩展成功解决方案或改进并重新测试的决策。这种迭代方法确保了在产品开发过程中持续学习和基于数据的决策。这种方法使团队能够做出数据驱动的决策，降低风险，并创建真正满足用户需求的产品。

在 HDD 和 BASE 的背景下，三个关键概念在实施这种迭代和实验性方法中发挥着至关重要的作用：

• 最小可行产品（MVP）：MVP 是许多精益创业方法论的基石，并在假设驱动开发（HDD）中扮演重要角色。MVP 代表了一个产品的最小版本，足以有效地验证其价值主张的核心假设。它包含足够的功能，以便从早期采用者或潜在客户那里收集有意义的反馈。MVP 的主要目标是验证或否定关于产品市场契合度、用户需求和潜在成功的关键假设，同时最大限度地减少时间和资源的投入。通过发布 MVP，团队可以迅速从实际使用中学习，并相应调整他们的产品策略。

• 最小可用增量（MVI）：MVI 侧重于向用户交付增量价值，并支持所有业务开发需求，涵盖业务流程、系统、工件以及产品和服务的改进。MVI 代表一个小的、离散的功能或改进，能够为用户或业务提供实际的价值。

  与通常在产品开发初期使用的 MVP 不同，MVI 在整个产品开发生命周期中使用，持续交付价值并收集反馈。MVI 允许团队将较大的功能或改进拆解成较小的、可管理的部分，这些部分可以更快速地开发、测试，并有可能更快地发布。

  这种方法支持持续集成和交付实践，使团队能够更迅速地响应不断变化的需求或用户反馈。最后，MVI 可以单独发布，也可以作为 MVR 的一部分发布。

• 最小可行发布（MVR）：MVR 将迭代方法扩展到发布层面，使组织能够交付实际价值，同时最大限度地减少浪费。MVR 代表可以打包成发布版本的最小功能集或改进，同时仍能为用户或利益相关者提供有意义的价值。

  MVR 允许团队更频繁地发布版本，在定期的间隔内收集反馈并验证假设。这种方法有助于降低大规模、不频繁发布所带来的风险，并使组织能够更迅速地响应市场变化或用户需求。

通过将这三个概念——MVP、MVI 和 MVR——融入假设驱动的开发过程中，团队可以创建一个高度适应性强且高效的产品开发周期。这种方法通过 MVP 进行快速的假设测试和验证，通过 MVI 持续交付价值，通过 MVR 定期发布有意义的版本。

这种组合支持实验、学习和持续改进的文化。它使团队能够做出数据驱动的决策，降低开发不符合用户需求的功能或产品的风险，并通过专注于验证过的高价值开发来优化资源配置。此外，这种方法促进了开发工作和业务目标之间的更紧密对齐。通过持续以小的、可衡量的增量交付价值，团队可以更有效地向利益相关者展示进展，并在需要时快速调整方向。在快速变化的市场中或处理新兴技术时，这种敏捷性尤为重要，因为用户需求和市场条件可能会迅速变化。

图 9.3 比较了 MVP 和 MVI 在八个方面的差异，因为这些概念有时会被刚接触这些术语的人混淆。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_09_3.jpg

图 9.3 – 比较 MVP 和 MVI

总结来说，假设驱动的开发模式，在 MVP（最小可行产品）、MVI（最小可行创新）和 MVR（最小可行结果）的支持下，为现代产品开发提供了一个强有力的模型。它将科学探究的严谨性与敏捷方法论的灵活性相结合，使组织能够更有效地创新、减少风险，并持续为用户和利益相关者创造价值。

提升商业敏捷性

在当今快速变化的商业环境中，快速应对市场变化、客户需求和竞争压力的能力至关重要。这一能力，即商业敏捷性，是 BASE 中的关键原则，对于组织的成功至关重要。

简单来说，我们将商业敏捷性定义为组织在不确定性和波动中适应和蓬勃发展的能力。它强调在所有业务方面的灵活性、面对挑战时的韧性，以及在战略、运营和客户互动中的适应性。

为了培养商业敏捷性，组织应实施以下关键实践：

• 采用分散决策方式

• 利用快速实验和学习

• 专注于以客户为中心的决策

• 实践持续改进

• 使用价值流管理和映射

这些实践使组织能够预见并主动应对新兴的挑战和机遇，在不断变化的商业环境中始终保持领先。

在 BASE 中拥抱商业敏捷性还使组织能够实现以下目标：

• 快速抓住新机会

• 以自信应对不确定性

• 培养创新和适应性文化

• 增强战略对齐并改善迭代产品开发

这些好处使组织不仅能够生存下来，还能够在现代商业复杂性和挑战中茁壮成长。作为 BASE 的重要原则，商业敏捷性还使组织能够有效应对市场变化，实时调整战略和运营，更加动态地与客户互动，并推动持续创新。

总之，商业敏捷性作为 BASE 的基石，赋予组织所需的工具和思维方式，帮助它们在当今不断变化的商业环境中充满信心和韧性地前行。通过采纳精益敏捷实践并培养适应性文化，组织可以为在日益复杂和竞争激烈的世界中持续成功打下基础。

这部分内容完成了我们对第一原理、系统思维以及 BASE 四大核心原则的讨论。接下来，我们将探索 BASE 概念模型中的八个流程，用于协调整个企业的工作。

八大 BASE 商业流程

BASE 模型概述了八个主要过程，这些过程定义了企业交付新整合增量价值的产品交付战略，并且以可预测的节奏进行。这些过程适用于任何类型的组织，包括商业企业、非营利组织或政府机构。BASE 模型并未告诉你你的公司需要做什么样的工作来交付外部客户所需的产品和服务。它也没有给出如何一步步运用 Lean-Agile 方法打败竞争对手的指导。那些艰难的工作由你和你的组织来确定。然而，作者提供了以下示例，说明你的公司可能会采用哪些常见的业务流程和活动来在你的领域中超越其他竞争者：

1. 投资组合管理

2. 规划增量

3. 精炼增量

4. 整合增量

5. 整合评审

6. 客户关怀

7. 客户体验

8. 企业战略

在阅读接下来的章节时，请参阅附录 9.1 - 业务流程、活动和任务。在该附录中，您将找到与每个 BASE 业务流程相关的常见活动和任务的清单。

企业战略

在 BASE 模型中，企业战略包括定义和传达组织愿景、使命、目标、任务和优先级的过程。活动包括评估组织能够交付的产品和服务、目标客户以及组织如何独特且有利可图地交付价值。

首席执行官负责制定和完善企业战略及治理政策。首席执行官制定治理政策，以确保组织的问责制、道德行为和战略一致性，从而促进信任和可持续成功。此外，首席执行官还需要对业务单元的活动与企业目标和任务的一致性负责，并做出关键的商业决策。OKRs 的设立是实现这一对齐的关键工具。

理想情况下，执行团队应当根据每个 BASE 增量的节奏来传达新的 OKRs。目标与关键结果（OKRs）是一种用于组织设定和跟踪目标及其成果的框架。OKRs 通过设定清晰、可衡量的目标（目标）并明确关键结果（关键结果），来指示达成这些目标的进展。目标通常是具有挑战性和定性的，而关键结果则是具体的、量化的并有时间限制，为成功提供了明确的衡量标准。

对于 OKRs，典型的推荐是为每个组织层级（如公司、部门、科室）设定 3-5 个目标，每个目标有 3-5 个关键结果。这有助于保持重点的可管理性，并确保每个目标得到足够的关注。OKRs 通常每季度设定并审查一次，从而进行定期评估和调整，同时与长期的年度目标保持一致。

在 BASE 中，OKR 框架鼓励组织内的对齐、聚焦和参与，确保所有价值流和职能团队成员朝着共同的战略目标努力，并定期跟踪他们的进展。

投资组合管理

精益敏捷投资组合投资于六个基本的业务推动因素：人员、流程、信息、技术、产品和基础设施。在 BASE 中，投资组合管理职能负责监督这些投资以及其他重要举措，以实现组织的战略目标并最大化投资组合价值。首席执行官和业务线（LoB）高管确定每个投资组合的资金水平，并就通过高级投资组合领导者和企业高管之间的合作制定的投资主题达成一致。这些投资主题指导每个投资组合如何投资其价值流并推动整体企业战略。

高级投资组合领导者通过投资主题决定开发价值流的资金，优先排序战略性举措，分配资源，并监控投资组合绩效。与产品管理和其他业务负责人合作，投资组合识别出重要举措，以推动投资组合从当前状态向未来状态转型，并与投资主题对齐。

商业战略、OKRs、KPIs 以及来自 MVPs、MVIs 和 MVRs 的反馈，都是投资组合管理中数据驱动决策的工具。敏捷团队通过定量指标和定性信息提供反馈，使自上而下和自下而上的协作决策成为可能。

BASE 模型中的投资组合管理涵盖了一系列活动，旨在战略性地分配资源、优先排序举措，并最大化组织内投资所带来的价值。关键活动包括：

• 战略性投资优先级、资源分配和预算编制

• 制定与企业战略对齐的投资主题，并监控和管理投资组合绩效

• 与产品管理和业务负责人合作，识别并优先排序战略性举措，以选择项目

• 沟通投资组合战略、目标和关键结果（OKRs），并与本地团队合作，协调其价值流的关键绩效指标（KPIs）

• 促进自上而下和自下而上的决策协作，包括整合使用 BLAST 的团队反馈，支持 MVPs、MVIs 和 MVRs

在考虑了投资组合管理因素后，我们的良性循环的下一步是规划新的增量价值，以支持投资组合的发展。

规划增量

该阶段包括对各个领域的工作进行精心规划和优先级排序，涉及的领域包括组合管理、产品和营销管理、生产、销售、分销、服务和合作伙伴管理。价值经理促进此过程，收集来自客户、利益相关者、领域专家、管理层和团队成员的意见，共同评估优先级。

虽然共识是理想的，但并非总是可行。在这种情况下，价值经理会基于现有信息做出明智决策。BASE 模型通过建立一致的节奏来减少风险，使每个增量的不确定性得到降低。

在精益敏捷企业中，通过集成增量交付价值至关重要，这一过程通过 BLAST 框架和 BASE 概念模型来协调活动。具体来说，企业内的多个团队合作，组装必要的组件，形成集成增量，如 MVP、MVI 或 MVR，以交付成功的基于价值的发布。

无论是改善价值流、业务流程、系统、工件，还是产品和服务，业务价值积压在 BLAST 和 BASE 中都是至关重要的。该积压涉及多个职能和价值流，需要客户、利益相关者、专家和高管的输入，以进行优先级排序。

最佳的 BLAST 团队规模通常为三到九人，确保在解决跨团队依赖性和同步问题时能够有效协作。类似的考虑也适用于 BLAST 中参与团队的数量，应该限制在三到九个团队之间，以便促进高效的跨团队沟通和在 BLAST 代表子团队之间的同步管理。每个 BLAST 的具体目标是根据特定的业务需求和所需集成增量的复杂性量身定制的。

每个 BLAST 都有一位指定的价值经理，负责管理其业务价值积压（Business Value Backlog）和工作项优先级。在多 BLAST 场景中，主导价值经理负责监督跨 BLAST 的优先级，协调与产品或组合管理的合作，产生期望的集成增量。

BASE 模型在每个周期启动新的规划增量，价值经理负责组织周期前的规划会议。BLAST 团队定义任务和活动，并解决团队间的依赖关系。在每个 BASE 周期中，传统的精益和敏捷度量标准会被监控，以追踪进展、保持可见性，并确保及时解决问题。同时，主导价值经理与产品经理、营销经理和组合经理合作，规划即将到来的增量。

精细化增量

集成增量的细化是一个持续的活动，与规划增量过程并行进行。根据所需的粒度，集成增量可以包括 MVP（最小可行产品）、一个或多个 MVIs（最小可行解决方案）、产品特性和功能，以及用户和技术故事。集成增量的生产可能会得到多个价值流和不同业务领域的支持。

价值经理主导需求细化过程，并与 BLAST 团队及其代表合作，以更好地理解和记录需求与验收标准。我们建议 BLAST 团队使用传统的基于敏捷的用户和技术故事以及验收标准格式来记录需求。

在做出上述推荐后，让我们快速看一下传统的基于敏捷的格式，用于定义史诗、用户故事、技术故事和验收标准。

传统上，组织在非常高层次上开始定义需求，通常以史诗的形式进行定义。虽然史诗通常与基于敏捷的软件开发相关联，但史诗的概念也可以轻松应用于其他需求评估，例如流程、产品和服务的改进。

在如 Scrum 和 Kanban 等敏捷方法中，史诗、特性、功能、故事和验收标准的典型分解及其相互关系结构如下：

• 史诗：这些是大规模的倡议或需求，最初定义了广泛的业务目标或客户需求。史诗通常被称为大故事，但在组织信息时并没有试图对其进行格式化，只是为了保持逻辑的思路。

• 特性和功能：这些代表了从史诗中衍生出的独立组件或用户能力，侧重于特定的面向客户的功能（特性）或内部操作（功能）。

• 用户故事：用户故事将特性或功能拆解成更小、可操作的工作单元，从最终用户的角度出发，详细说明交付业务价值的具体任务。传统格式如下：

  作为[某种类型的用户]，我想要[采取行动/实现目标或获得结果]，以便[基于价值的利益或结果]。

  让我们来细分一下：

  • 作为[某种类型的用户]：这一部分明确了用户的身份。用户可能是客户、管理员、访客或其他相关角色。

  • 我想要[采取行动/实现目标或获得结果]：在这里，我们表达了用户想要做的事情。它可以是用户需要采取的特定行动，或者是他们希望实现的目标。

  • 以便[基于价值的利益或结果]：最后，我们解释实现这个用户需求的目的。用户通过这一行动将获得什么样的利益或结果？

• 技术故事：技术故事类似于用户故事，但它们专注于支持特性或功能实现所需的技术任务或活动。它们从技术角度出发，概述了系统或基础设施中需要进行的具体操作或改进。传统格式如下：

  作为一个[角色/人物/用户类型]，我想要[目标或行动]，以便[目标/行动的预期结果]。

  让我们分解一下：

  • 作为一个[角色/人物/用户类型]：就像在常规用户故事中一样，我们首先识别出用户是谁。然而，在技术故事中，这个用户可能是开发人员、系统管理员或任何其他技术相关人员。

  • 我想要[目标或行动]：接下来，我们表达技术用户想要实现的目标。这可能与编码、配置、基础设施、部署或其他任何技术任务相关。

  • 因此 [目标/行动的预期结果]：最后，我们解释满足此技术需求的目的。完成此技术任务后，能带来什么好处或结果？

• 验收标准：这些是用户故事必须满足的具体条件，才能被认为是完整的并准备接受利益相关者的验收，确保它们符合功能和非功能性要求。传统格式如下：

  给定：[背景或前提条件]，当：[动作或事件]，然后：[结果或结果]

  让我们分解一下：

  • 给定：这是 设定背景（例如，处于产品详情页且已选择商品）

  • 当：这是 *描述行动（例如，点击“*结账”按钮）。

  • 然后：这是 概述预期结果（例如，查看 订单摘要）

如果未定义验收标准，后果自负。两件事可以确定发生。首先，你将无法了解会影响工作项成功实施的完整使用标准。其次，你的客户可能会因为未交付完整或有效的解决方案而提出问题。是的，在敏捷开发中，我们总是可以将新的标准加入到我们的业务价值待办事项中。但从效率角度来看，为什么不提前捕捉这些需求呢？现在我们知道了如何完善需求，接下来让我们看看这些需求是如何从史诗进展到验收标准的。

史诗的进展

定义和完善需求的典型过程是从更广泛的史诗到更详细的特性/功能、故事和验收标准，格式如下：

1. 史诗最初被识别出来，以全面概述主要的业务目标或客户需求。

2. 特性和功能源自史诗，将更广泛的范围分解为可管理的组件，并与特定的业务目标或技术要求对齐。

3. 用户故事和技术故事分别基于功能或特性创建，详细说明用户需要执行的具体场景或任务，以实现预期的功能。

4. 验收标准与用户故事一起或在定义用户故事后制定，明确可衡量的条件，确保每个用户故事满足利益相关者的期望和功能需求。

有了这种进展思路，我们现在可以继续了解如何根据价值优先对待办事项进行排序的技术。

优先排序业务价值待办事项

在本小节中，我们将简要介绍两种常见的工作项优先级排序策略：加权最短作业优先（WSJF）和 MoSCoW。WSJF 方法根据经济价值和紧急程度对待办事项进行优先级排序，强调最大化回报并最小化延迟成本。相比之下，MoSCoW 方法将需求分为必须有、应该有、可以有和不会有，重点关注关键需求和项目限制条件下的优先排序。

我们将从 WSJF 开始。

加权最短作业优先（WSJF）优先级排序

在 第四章 中，我们探讨了加权最短作业优先（WSJF）如何作为一个强大的优先级排序工具，在敏捷和精益环境中发挥作用。通过基于延迟成本（CoD）和工作持续时间计算得分，WSJF 帮助团队确定应优先处理哪些待办事项，以实现最大经济效益。该方法确保优先处理高价值任务，这些任务能够迅速交付成果，并且如果延迟会产生显著成本。WSJF 与精益原则相符，关注最大化价值，忽略沉没成本，并持续优化经济决策。它是寻求高效待办事项管理和优先级排序策略的组织的重要指南。

MoSCoW 优先级法

MoSCoW 方法是一种广泛应用于敏捷和 Scrum 方法论的优先级排序技术，用于根据待办事项的重要性和紧急程度进行管理。MoSCoW 是 Must have、Should have、Could have 和 Won’t have (this time) 的缩写。该方法将待办事项分为四个 MoSCoW 类别，以指导团队确定哪些是需要立即交付的，哪些可以推迟：

• Must have：必须交付的关键需求，必须在当前迭代中完成，以满足项目目标或关键利益相关者的需求。

• Should have：重要需求，虽然当前迭代中并非关键，但如果可能，应该包括在内，以增强产品的价值。

• Could have：理想的需求，虽然对于当前交付并非必要，但如果时间和资源允许，可以考虑添加这些需求。

• 不会有：那些在当前阶段明确排除在范围之外的事项。如果这些事项是可取的，但并非优先事项，它们可以推迟到未来的版本或项目中。

通过使用 MoSCoW 方法，敏捷团队可以协作地对待办事项进行优先级排序，确保业务优先级与开发工作之间的一致性。这种方法有助于在保持灵活性的同时，最大化早期交付关键功能，并能够在项目生命周期中适应变化的需求。

集成增量

我们之前已经解释过，集成增量的概念帮助我们定义了个别团队和 BLAST 团队必须交付的工作，这些增量有三种形式：MVP、MVI 和 MVR。这个 BASE 过程是我们构建、测试和交付集成增量的地方。

这不是一个单一的过程描述。例如，市场营销团队交付集成增量的组成部分，以推广新产品或服务，这与软件开发团队在同一增量中为软件应用程序构建功能增强所产生的交付物是截然不同的。然而，这些开发和运营活动需要协调，以支持新的 MVR。此外，可能会有其他 MVI 正在通过类似的集成增量构建周期并行进行，以满足 MVR 的所有需求。

随着今天流程自动化和集成能力的发展——回顾我们之前关于 CI/CD 和 DevOps 工具链的讨论——许多开发活动将使用精益的流程原则进行操作。然而，敏捷的迭代和增量发布周期为增量计划、构建、评审和交付设定了节奏。

在我们离开本节之前，让我们看看一些常见的业务流程、活动和任务，这些内容可能会为单个 BASE 循环中产出的交付物做出贡献。

组建 BLAST 团队以交付集成增量

回顾我们之前讨论过的 BASE 模型如何为持续的业务改进建立一个良性循环，组织中的每个部分都在任何给定的 BASE 循环中发挥作用，正如附录 9.1、表 9.1: 业务流程、活动、和任务中所示。

在 BASE 概念模型中，组织利用 BLAST 团队有效执行各种关键的业务流程，这些流程对其运营和价值流至关重要。高管们可以建立多个量身定制的 BLAST 团队，以支持跨不同业务职能和价值流的各种业务流程。例如，在企业战略和投资组合管理领域，专门的 BLAST 团队可能专注于愿景发展、战略规划、绩效管理和风险缓解，这些都与特定的价值流相一致。同样，产品和市场管理职能也可以组建 BLAST 团队，管理市场情报、战略决策、产品开发、市场引入和销售支持等活动，这些活动推动了各自价值流中的价值创造。

在 BASE 模型中，这些 BLAST 团队的主要目标是在一个 BASE 周期内（即其良性循环的一个循环）交付整合后的价值增量，呈现为 MVP、MVI 和 MVR。有些 MVI 可能会独立发布，而其他则会贡献于更大的 MVR。BASE 模型的灵活性使组织能够根据其规模和复杂性调整每个周期内发布的整合增量数量。较大的组织通常需要多个 BLAST 团队来有效管理和协调这些流程，确保持续改进并与以客户为中心的目标保持一致。

最终，贵组织必须定义为支持交付新的价值增量而必要的业务流程、活动和任务。它将确定为支持这些交付而设置的 BLAST 团队的最佳配置，以整合增量的形式进行交付。最后，贵组织将决定如何以及何时通过其 MVP、MVI 和 MVR 发布每个价值组件，在每个 BASE 周期中。

随着每个整合增量的构建，它将 undergo 审查以确保质量和完整性。这些活动将在下一个核心流程“整合审查”中详细说明。

整合审查

来自各个 BLAST 团队的整合增量需要同步，以支持新的发布。此核心 BASE 过程阶段包括在发布前对整合增量的排序，例如，在产品销售和分发之前协调市场推广和销售培训。

SME、客户和利益相关者必须在此阶段审查这些增量。他们评估整合增量的目标、用户故事、技术要求和验收标准是否已达到。

任何识别出的 问题都通过 BLAST 框架中的反馈与调整分支进行处理。缺陷或错误将返回至业务价值积压进行完善和优先级排序。如果问题紧急并且在当前 BASE 周期内可行，它们将被立即解决；否则，它们将被安排在未来的 BASE 周期中处理。

在这一阶段，经过成功审查并确认可以发布的集成增量会与其他集成增量同步部署，或根据需要按需部署。一旦接受，内部和外部客户的部署产品和服务必须得到支持，这一主题将在下一部分的客户关怀中讨论。

客户关怀

有效的客户关怀是 BASE 模型中的关键过程组，确保企业能够在各种产品类型和行业中持续满足客户需求和期望。实施卓越的客户支持计划涉及多个关键实践：

1. 以客户为中心的方法： 优先理解和预测客户需求，提供主动支持和个性化体验。

2. 多渠道支持： 通过多种渠道（例如电话、电子邮件、聊天、社交媒体）提供支持，以适应不同客户的偏好并确保可访问性。

3. 及时响应服务： 实现快速响应客户咨询和问题的解决，目标是提高客户满意度和留存率。

4. 知识管理： 维护集中式知识库，帮助支持人员获取准确的信息和解决方案，确保服务交付的一致性。

5. 持续改进： 定期收集客户反馈，识别改进领域，优化支持流程，并提升整体服务质量。

6. 培训与发展： 投资培训项目，赋能支持团队，提升他们处理客户互动的能力与同理心。

7. 与产品开发的集成： 促进客户支持与产品开发团队之间的合作，解决反复出现的问题，优先处理功能需求，并提升产品的可用性。

8. 指标与分析： 利用客户满意度评分、响应时间和解决率等指标来衡量表现，并推动持续的服务改进。

通过将这些实践融入 BASE 模型的客户关怀过程中，企业可以建立强大的客户关系，提升客户留存率，并在竞争激烈的市场中脱颖而出。此外，每次产品或服务发布都会影响有效的客户关怀流程，因此需要持续的投资和流程改进，以保持高效的客户支持能力。接下来，我们的 BASE 过程组将讨论如何衡量客户体验（CX）并根据我们的发现采取行动。

客户体验

**客户体验（CX）**体现了以优先考虑和提升客户在与企业或品牌互动过程中满意度、愉悦感和忠诚度为核心的理念。这强调灵活性、快速迭代和客户反馈，以优化所有接触点的消费者体验。通过采纳精益敏捷原则，组织旨在更加回应客户需求和市场变化，从而提升客户满意度和忠诚度。

BASE 模型中的精益敏捷客户体验要求将大型复杂的客户体验项目拆解为可以融入 BASE 迭代的小块。在这些 BASE 节奏中，跨职能团队协作评估客户体验的变化。这些变化可以是从精细化网站用户界面到简化客户服务流程的任何内容。在每次迭代后，团队会审查结果并收集利益相关者的反馈，包括真实客户的意见，以便为下一轮产品或服务改进提供依据。这一迭代循环有助于确保组织不断适应并调整战略，以有效满足客户期望。

以下五项关键的客户体验（CX）活动在许多组织中是常见的：

1. 进行客户旅程映射，以理解并改善端到端的客户体验。

2. 实施用户界面（UI）/用户体验（UX）设计原则，以增强产品和服务的互动性、可用性和可及性。

3. 优化客户服务流程和渠道，以提供及时有效的支持。

4. 个性化营销和沟通策略，以更好地与个人客户需求和偏好产生共鸣。

5. 监测并分析与客户满意度、忠诚度和留存相关的关键指标。

一些组织可能会添加以下额外活动来提升其客户体验项目：

• 根据数据分析和客户反馈获取的洞察，持续迭代并改进客户体验（CX）项目。

• 跨部门协作，确保客户体验（CX）工作与组织目标和战略的一致性。

• 实施技术解决方案，如客户关系管理（CRM）系统和数据分析工具，以提升客户体验能力。

• 培训并赋能员工，在每一个接触点提供卓越的客户体验。

这些活动对于旨在为客户在各个接触点和互动中创造积极且难忘体验的组织至关重要。此外，精益敏捷客户体验有助于培养持续学习和适应的文化。通过不断测试新想法并通过 MVP、MVI 和 MVR 收集反馈，企业可以迅速了解什么有效，什么无效，大大降低风险。这种方法有助于优化产品供应，并提升整体服务交付，使公司更具竞争力，并更加以客户为中心。

这完成了我们关于八大核心 BASE 商业流程的讨论。现在，我们将进入 BASE 概念模型的核心，重点是将客户置于首位。

建立以客户为中心的基础

精益和敏捷的从业者都强调了交付以客户为中心的价值的重要性。因此，像 BASE 这样的精益敏捷概念模型必须同样将客户置于我们所做一切的中心。

图 9.4，BASE 的核心，提供了这些概念的图示视角。BASE 有意将对客户旅程的改善置于我们企业改进活动的中心。我们还展示了拥有价值经理和产品负责人协同推动这些努力的重要性。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_09_4.jpg

图 9.4 – BASE 概念模型的核心

为了进一步强调协调工作以支持客户对价值的看法的重要性，价值经理 代表了客户在 BASE 中的声音，标志着他们在监督价值流和产品改进方面的角色，并促进有效的团队沟通。

虽然 产品负责人 角色仍然可以在 BASE 中应用，但我们建议避免在这两个角色之间拆分职能，因为这样可能会产生利益冲突，例如价值流改善与产品提升之间的冲突。然而，如果你选择产品负责人这一职称，确保该角色的个人能够全面监督所有的价值创造方面。

价值流管理 活动是 BASE 模型的核心。在任何组织中，常常面临大量任务和相互冲突的优先事项，这可能使资源超负荷，导致管理无效。没有整体视角或优先级系统，往往会导致应急处理、冲突和未达成的期望。

VSM 方法和工具在这个背景下起着至关重要的作用，通过使得最具影响力的变革能够经过严格评估，从而提高组织的生产力和效率。通过系统性地看待产品交付活动，VSM 确保资源得到最优分配，并且每个 BASE 循环的迭代都能从提高效率、生产力和适应性的过程中受益。

现在，让我们进入本章的最后一部分，在这里我们讨论采取生命周期视角进行产品开发的重要性。

在产品生命周期中交付价值

BASE 模型体现了通过强调跨产品生命周期的价值交付，引导组织应对现代商业环境复杂性的本质。当我们深入探讨基础理论的实际应用时，我们将探索构成 BASE 良性循环的复杂过程。这一探索提供了一个全面的视角，展示了组织如何系统地创建、交付和提升整个产品生命周期中的价值。

BASE 模型的核心是培养创新文化、客户中心主义和持续改进。它为组织提供了一种结构化的方法，将运营和客户参与与商业战略对齐，最大化价值创造，并保持竞争优势。BASE 的特色在于它致力于利用常识和易于理解的商业实践，避免创造不必要的角色或强加违反直觉的商业活动。尽管精益和敏捷实践在许多组织中仍处于新兴阶段或尚未完全成熟，但其基本理念已被证明是有效和稳健的。

本节剖析了战略决策、客户洞察和运营卓越之间的相互作用。理解这些元素的融合，使组织能够制定稳健的、以客户为导向的战略，从而在产品生命周期的每个阶段推动价值创造。

从构思到交付及其后，每个产品生命周期阶段都面临独特的挑战和机遇。BASE 模型为组织提供了在这些复杂性中灵活且精准地导航的原则和实践。读者将获得可操作的见解和实用的战略，以优化产品生命周期中的价值创造，帮助自己在当今动态的商业环境中获得长期成功。

利用以客户为中心的战略增长

BASE 的以客户为中心的方法的核心在于认识到客户满意度和忠诚度对组织成功至关重要。虽然理论上任何核心流程都可以作为进入 BASE 模型的切入点，但在本讨论中，我们从客户关怀开始，作为成功客户参与的入口点。这个职能充当了组织与客户之间互动的前线。

提升在 BASE 中的客户参与度

在精益敏捷型组织中，对以客户为中心的承诺不仅是一种理念，更是指导每个业务层面的原则。客户关怀作为客户互动的前沿，远远超出了单纯的售后服务。它包括一整套活动，以确保持续的客户满意度和忠诚度。这些活动包括提供及时的支持和帮助，积极征求反馈，解决客户问题，以及发现产品或服务改进的机会。通过保持畅通的沟通渠道并展示真正致力于满足客户需求的承诺，组织可以培养牢固的关系并促进长期忠诚度。

支持在 BASE 中的客户参与

通过整个循环，客户关怀涵盖了一系列活动，包括交付、支持、维护和修复，所有这些都旨在超越客户的期望。通过在购买后积极与客户互动，组织可以获得有价值的反馈，识别痛点，并了解新兴趋势和客户期望。

在客户关怀基础上构建的是客户体验过程，它超越了基本的服务提供，主动与客户互动，并理解客户与组织的产品和服务的整体体验。这涉及诸如外展计划、奖励方案和旨在捕捉客户偏好、满意度和改进领域的对话式 AI 技术等各种举措。此外，客户旅程映射等活动提供了一种结构化的方法，帮助组织理解端到端的客户体验，使其能够识别令人愉悦的时刻、挫败感以及优化的机会。

企业战略整合了来自客户关怀和客户体验的洞察，塑造组织的未来方向。这个战略过程涉及关于产品扩展、服务提升和市场扩展举措的关键决策。通过将企业战略与客户需求和偏好对齐，组织可以确保其投资和举措在每个交付周期中都能最大化客户价值，并推动可持续增长。

除了客户体验（CX）、客户关怀和战略之外，BASE 模型中的其余核心过程侧重于构建和交付集成增量。工作的范围取决于许多必须解决的商业因素。随着改进机会的识别，价值经理与 BLAST 团队、利益相关者、领域专家（SMEs）和职能领域负责人合作，优先处理当前的举措。

在 BASE 中利用以客户为中心的战略增长，要求深入理解客户的需求、偏好和行为。通过优先考虑客户洞察并将其融入战略决策过程中，组织可以建立竞争优势，促进客户忠诚度，并在当今动态的商业环境中实现长期成功。

在接下来的小节中，我们将深入探讨 BASE 模型中客户参与的运营方面。从购买后的互动到主动外展举措，我们将探索组织如何与客户建立有意义的联系。

持续改进价值交付

价值流在 BASE 模型中起着关键作用，作为价值构思、创造和交付给客户的基本路径。这些流包括跨越整个产品开发生命周期的相互关联的活动和过程，从构想到交付和支持。

保持产品聚焦

在较大的组织中，运营、开发和支持的价值流可能会扩展到数百甚至数千个，每个都包含一系列的活动。然而，在 BASE 模型下，我们的目标是简化。因此，我们将每个 BASE 周期集中在提升一个面向产品的价值流，这一流将特定类型的产品或服务交付给我们的外部客户。

本质上，不要忽视大局。在初期规划时，保持对需要改进的产品或服务的专注。保持 BASE 流程的高层次定义，让 BLAST 团队深入探讨如何提升价值交付。如果你的组织涵盖多个产品线——不仅仅是通过型号或款式的不同，而是涉及真正不同的产品或服务——每一条产品线都应当经过一个独立的 BASE 周期，以推动流程、产品和相关服务的改进。

确实，较大的组织可能会按产品线同时运行多个 BASE 周期。这一策略简化了流程，并保持对各个产品线需求的专注。否则，考虑一下在多个产品间进行业务流程、系统、产品和服务改进所面临的挑战——这远非简单之事。

通过管理和优化这些面向产品的价值流，组织可以简化操作，加速上市时间，并在当今竞争激烈的商业环境中获得竞争优势。

按客户影响的优先顺序消除浪费

优化价值流的一个关键方面是识别并消除一切可能的浪费。此过程包括进行彻底的价值流映射，以找出工作流程中的低效、瓶颈和冗余之处。

有时，质量或成本问题可能会驱动改进优先级的决策。但通常，你的约束条件会引导你发现最有影响力的改进机会。回想一下我们讨论的局部优化。解决那些不影响吞吐量的浪费可能对流程流动没有什么影响，甚至没有影响。

图 9.5 提供了一个有用的类比：想象一下这辆高性能的绿色兰博基尼的车主。他们已经在这辆快车上投入了大量资金，但他们的速度却受到周围交通的限制。任何试图超越这个限制的举动，都有可能带来不良后果。换句话说，在瓶颈和延误被消除之前，他们的投资都在浪费。

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/B21818_09_5.jpg

图 9.5 – 堵在交通中

通过精简流程、减少不必要的交接和最小化等待时间，组织可以减少周期时间、提高生产力、并增强整体运营效率。这使得组织能够更快速地为客户交付价值，降低成本，并最大化资源利用率。

使用指标来指导决策

有效的价值流管理需要持续监控和衡量关键绩效指标，以跟踪进展并识别改进领域。通过建立明确的绩效基准和指标，组织可以评估其价值流的有效性，并根据数据做出决策，以优化绩效并增强价值交付。这种迭代的价值流管理方法使组织能够根据市场动态、客户需求和业务要求的变化进行调整和发展，确保在快速变化的商业环境中保持敏捷和响应能力。

此外，优化价值流需要一种跨职能的协作方法，涉及整个组织的利益相关者。通过打破部门之间的壁垒并促进不同部门和团队之间的协作，组织可以简化沟通、改善协调，并增强朝着共同目标的对齐。这种协作方法加速了价值交付，促进了持续改进和创新的文化，在这种文化中，员工有权识别和实施流程改进，从而推动组织成功。

优化价值流对于寻求推动可持续增长和竞争优势的组织至关重要。在当今充满活力的商业环境中，通过简化运营、减少浪费以及促进协作，组织可以提高向客户高效、有效地传递价值的能力，从而为长期的成功和市场中的韧性奠定基础。

接下来，我们将深入探讨关于实施持续改进的结尾部分。在这里，我们将重点关注价值经理的关键角色、BLAST 框架的采用以及持续反馈循环在推动 BASE 内部创新中的重要性。

实施持续改进

在 BASE 模型中，推动持续改进是支撑组织在快速变化的商业环境中适应、创新和繁荣的基本原则。其核心是价值经理，价值经理在协调工作以确保价值交付与组织目标和客户需求对齐方面起着至关重要的作用。

价值经理负责监督价值流活动，促进跨职能协作，并优化流程以提高效率和效果。他们与价值流团队密切合作，定义目标、建立绩效指标并识别改进机会。通过提供指导、支持和资源，价值经理赋能团队交付满足客户期望并推动业务成果的高质量 MVP 和 MVI。

组织内的精益-敏捷团队利用 BLAST 框架高效交付新的集成增量。该框架结合了精益的流程导向和敏捷的迭代增量开发模式，使团队能够简化工作流，加快价值交付，并保持专注于提升客户价值。

在 BASE 模型中，持续反馈和迭代学习同样至关重要。精益-敏捷团队定期从客户、利益相关者和最终用户那里获取反馈，收集洞见、发现改进机会并验证假设。这个反馈循环使团队能够在产品和流程上进行迭代，优化策略，并随着时间的推移更有效地交付价值。

通过拥抱实验、创新和持续学习的文化，组织能够营造一个动态和适应性强的环境，使持续改进成为组织 DNA 的一部分。

最终，在 BASE 模型中推动持续改进不仅仅是优化流程或交付更好的产品；它培养了一种持续学习、适应和创新的思维方式。赋能价值经理、利用 BLAST 框架，并拥抱持续反馈和学习，使组织具备了长期成功和可持续增长的能力。

本章内容至此结束，第九章的内容也告一段落。在第四部分，推动可持续转型中，我们将探讨可持续数字化转型的可行策略，简化复杂性、渐进式发展并实施切实的变革。但首先，让我们回顾一下。

总结

在第九章中，你深入探讨了企业商业敏捷系统（Business Agility System for the Enterprise），也就是 BASE 概念模型（或简称 BASE）。本章揭示了产品生命周期的关键概念，展示了在持续交付客户价值过程中固有的动态性。你已了解了“良性循环”这一中心要素，它代表着推动改进的持续自我强化循环。通过探索 BASE 模型，你学习了其以客户为中心的基础，投资组合与战略对齐的重要性，以及如何在产品生命周期中交付价值。

本章的洞见至关重要，因为它为你提供了企业如何具备敏捷性、响应能力并始终以客户为中心的全面理解。掌握 BASE 模型使你能够同步多个团队，确保产品开发和交付的顺利进行。通过内化协作、战略对齐和客户关注的原则，你可以引导组织朝着持续的成功发展，并确保它始终能够适应市场和客户需求的不断变化。

在第四部分，推动可持续转型中，我们介绍了精益-敏捷高层管理策略。

附录 9.1 - 商业流程、活动和任务

https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/Figure_Appendix_9.1_-1.jpghttps://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/Figure_Appendix_9.1-2.jpghttps://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/lean-agl-way/img/Figure_Appendix_9.1-3.jpg

问题

本节面向那些希望评估自己对本章提供信息的理解和记忆的读者。这里有三个问题，答案将在下一节提供。回忆原文的确切表述并不重要，重要的是能够回忆起概念及其应用。问题如下：

1. 组成 BASE 基础的四个原则是什么？如 图 9.1 – Base 产品开发 所示。

2. OKR 框架在 BASE 模型的企业战略方法中扮演什么角色？

3. BASE 模型如何通过强调持续价值交付，促进客户导向和产品生命周期的持续改进？

答案

1. BASE 模型的四个原则是战略与执行、精益敏捷文化、假设驱动开发和业务敏捷性。

2. OKR 框架在 BASE 模型中的作用是将业务单元的活动与公司目标和战略对齐。它帮助定义和跟踪明确的可衡量目标及其关键结果，确保全组织的焦点、对齐和参与。

3. BASE 模型通过强调持续价值交付，促进了以客户为中心的产品生命周期持续改进。它从客户关怀作为关键切入点开始，通过主动的客户互动、反馈整合和产品/服务的提升计划，确保持续的客户满意度。

延伸阅读

1. scaledagileframework.com/business-agility/

第四部分：推动可持续转型：实现精益敏捷精通的策略

欢迎来到本书的最后一部分。在前面的章节中，我们探讨了与精益敏捷方法和价值流管理相关的各种原则、实践和框架。如果你感到信息量有些庞大，不必担心。在本节中，我们将所有内容整合为可操作的策略。

在本节中，我们的目标是将你所获得的知识提炼为可操作的策略，帮助实施和维持数字化增强的精益敏捷转型。这些策略旨在促进更容易的采用，并培养支持持续改进的习惯。我们将强调渐进演变的重要性，而非突然变化，同时确保与业务目标、战略和客户需求保持一致。

将本书的最后一部分视为一个实用工具包，用于将理论知识转化为切实可行的实施方法。我们的重点是构建一个灵活的商业方法论，能够无缝适应现代企业的动态需求，涵盖商业行业、非营利组织和政府机构。我们的最终目标是建立可持续的实践，推动持续的商业转型。

第十章是这一部分的入门章节，介绍了提升精益敏捷组织决策能力的方法。你将会接触到 BRIA 和 QIDA 的概念，这些概念有助于定义关键的商业问题，从数据中提取可操作的洞察。这凸显了信息作为组织适应能力的生命线，强调了有效管理在推动各个运营领域改进中的重要作用。

接下来是 第十一章，我们从理论过渡到实践，为实施精益敏捷和价值流管理（VSM）策略提供了一个务实的路线图，帮助实现持续的组织转型。

最后， 第十二章在深入探讨五个跨领域主题之前，全面回顾了前面几章内容，提供了精益敏捷精通的连贯性和一致性。我们以三个真实案例故事结束，展示了本书中介绍的精益敏捷和 VSM 概念的成功应用。

第四部分不仅仅是吸收信息；它关乎采取果断的行动，推动演变，培养领导力来支持变革。本部分为领导者和团队提供精益敏捷的思维方式，确保他们的组织能够在数字时代产生持久且积极的影响。在这些页面中，包含了为那些准备创新、简化操作并领导变革的读者设计的路线图——你的旅程即将开始。

第四部分中的章节如下：

• 第十章，提升精益敏捷组织中的决策能力

• 第十一章，组织转型的实施策略

• 第十二章，构建精益敏捷与 VSM 的精通