DevOps VSM 价值流管理——交付以客户为中心的价值｜云加速

DevOps 已经通过开发和运维的一体化协同，改善了 IT 部门之间的沟通和效率，同时开始集成和自动化 IT 流程，以实现业务价值在所有组织价值流中的持续流动。因此，与传统的软件开发生命周期流程和敏捷实践相比，现代 DevOps 团队可以更高效、更快速且可靠地交付价值。

当今的数字化转型，正在以高效、快速、低成本地交付以客户为中心的价值作为目标。这样的战略包括将 IT 纳入整个企业中发生的价值流转换，并将其与整个企业的价值流转换保持一致。VSM 价值流管理是一种精益生产改进策略，在 IT 中找到了新的应用场景。

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

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

VSM 是一种有条不紊地消除浪费、提高生产力和效率同时降低成本的方法。更准确地说，VSM 包含了以精益为导向的方法来改善跨价值流的工作和信息流。现代 VSM 工具支持最初由 Toyota（丰田）开发的 VSM 方法，作为一种绘制材料和信息流的方法，然后在 2000 年代初引入世界其他地区。

在数字经济中创造价值

数字经济的其他名称还包括互联网经济、新经济或网络经济。数字经济的发展迫使传统实体公司重新考虑其业务战略，否则将面临被互联网行业的激烈竞争者赶出业务的境地。

由于互联网竞争者对实体基础设施的传统投资，传统企业需要迅速找到创造性的方法来利用其传统的规模经济在数字经济中进行竞争。在某些情况下，这意味着找到与客户互动的不同方式。在其他情况下，整合传统和数字基础设施的混合方法可能会提供竞争优势。

在任何情况下，公司都必须定义并执行其具有竞争力的价值主张。他们必须评估所有投资和活动，以确保最大限度地创造价值。

定义客户价值

客户价值是最终客户从产品或服务中获得的价值。前面已经了解到精益发展战略强调评估活动以增加价值，并消除那些不增加价值的活动。

精益发展战略是有意义的，因为最终，客户是价值的唯一仲裁者。客户在有效性或可用性、质量和收益方面能够感知到价值。我们提供他们想要的东西的能力，是客户满意度的决定因素。

精益制造，也称为精益生产，是生产方法的现代实例，最初源自丰田的运营模式，即丰田方式和丰田生产系统 (TPS)。精益企业研究院（LeanEnterpriseInstitute,LEI）将“精益生产”定义为“组织和管理产品开发、作业、供应商和客户关系的业务系统，与过去的大批量生产系统相比，精益生产消耗较少的人力、空间、设备、资金和时间制造最少缺陷的产品以准确地满足客户的需要”。换句话说，精益生产是一种识别和消除浪费（非增值活动）的系统方法。

沃马克（Womack）和琼斯（Jones）在他们的书《改变世界的机器（The Machine That Changed the World）》中定义了精益制造的五项原则，概述如下：

• 精确指定特定产品的价值
• 确定每个产品的价值流
• 让价值无间断流动
• 让客户从生产者那里获取价值
• 追求完美

回顾精益和敏捷的发展

让我们简单回顾一下从精益到软件敏捷宣言，DevOps，BizOps 的发展历程，可以看到从开发到运维，再到业务的精益思想发展。

敏捷软件宣言（2001年）

强调的敏捷软件开发的四个核心价值是：

• 个体和互动 高于流程和工具
• 工作的软件 高于详尽的文档
• 客户合作 高于合同谈判
• 响应变化 高于遵循计划

也就是说，尽管右项有其价值，我们更重视左项的价值。

DevOps（2009年）

DevOps 孕育于敏捷运动，是一组结合了软件开发（Dev）和 IT运维（Ops）的实践，旨在缩短系统开发生命周期并提供具有高软件质量的持续交付。

DevOps 的引入能对产品交付、测试、功能开发和维护起到意义深远的影响。在缺乏 DevOps 能力的组织中，开发与运营之间存在着信息“鸿沟”──例如运营人员要求更好的可靠性和安全性，开发人员则希望基础设施响应更快，而业务用户的需求则是更快地将更多的特性发布给最终用户使用。这种信息鸿沟就是最常出问题的地方。

BizOps宣言（2020年）

2020年，BizOps 联盟发布了 BizOps 宣言，倡导从根本上改变 IT 团队和业务用户在软件开发过程中的协作方式。目标是通过鼓励 IT 团队与业务领导者更密切地合作，缩小 IT 与业务其他部门之间的历史鸿沟，业务领导者需要根据实时数据分析做出明智的技术投资决策，以推动业务增长、改善客户经验和提高盈利能力。

BizOps 宣言概述如下。

通过 BizOps，我们开始重视：

• 业务成果 高于单个项目和执行度量。
• 信任和合作 高于个人主义和层级制度。
• 数据驱动的决策 高于意见、判断和说服。
• 学习和转变 高于遵守严格的计划。

VSM贯穿于价值流整个过程

价值流是从最初的需求到客户实现价值的过程中，为客户增加价值而采取的一系列行动。下图展示了价值流从最初的客户需求进入开始，一直到交付价值给客户的整个过程。价值流代表价值流向客户的持续流动，价值流管理帮助组织跟踪和管理从构思阶段一直到客户交付的这一流动。通过价值流管理，将端到端软件开发的各个方面联系起来并进行衡量，以确保产品的全部价值有效地到达客户手中。VSM 价值流管理结合思路就是在端到端的整个价值流过程中，识别发现堵塞、漏洞和浪费，持续改进提高效率和质量，降低风险和成本。

通过市场和业务分析，制定产品业务目标，同时进行成本分析和资源规划，确定产品发布计划和特性价值，这部分过程我们称作“做正确的事”，重点在于确定真正的面向客户的价值。根据产品需求进行技术需求分析和需求分解，并将分解后的需求进行开发计划，安排开发任务，进行持续开发和测试，最终交付产品，这部分过程我们称作“正确地做事”，重点在于通过分工协作正确地实现并交付价值。

通过管理需求价值缩短产品发布周期的例子

一家全球通信设备供应商，开发和生产通信系统。对于通信产品，产品上市时间对于其是否成功十分关键。如果新产品特性（如一项新智能业务）的推出能够早于竞争对手几个月就会取得很大的竞争优势，否则比竞争对手哪怕只晚一个月，也可能会丧失很大的市场机会。

因此，对于市场更急迫需要的产品特性，必须尽可能尽快发布，而不是在一段较长的时间后一起发布大部分产品特性，也即其面临的挑战是如何缩短产品发布间隔时间。

我们来看其中一个产品，该产品有近8000条功能需求，它们逐步通过产品管理团队和产品开发团队的讨论和评审，而不断确定下来，实施到各发布版本中。批准所有这些功能需求一共花费了26周时间。然而，事实上大部分产品功能需求在早期就已经被提出来了，为什么会需要这么多时间来批准需求呢？在一个拥有众多功能需求的产品中，功能需求之间往往存在着许多直接或间接的关联关系，除了功能依赖关系之外，还要考虑到有依赖关系的功能需求需要在同一个版本中开发完成，同一个产品特性下的功能需求只有一起发布才能完成此产品特性。因此，当加入、修改或删除一条功能需求，或者调整一条功能需求的发布版本和优先级时，往往会影响到其它多条功能需求，导致这些功能需求的内容以及发布版本和优先级进行相应的调整。而当调整这些受到影响的功能需求时，又会引起更大范围的需求变更，这就是“需求振荡”。解决每一次“需求振荡”都要花费产品管理团队和开发团队大量的时间。因此，要缩短产品发布间隔时间必须要减少需求振荡。

进一步分析“需求振荡”之后，发现振荡的根源在于一个功能需求包含了多个产品特性。产品管理团队从市场角度，分析出市场需要的产品特性，从而要求相应的产品功能，并确定功能需求的发布版本和优先级；产品开发团队则从需求开发角度，根据产品架构、开发技术以及开发资源等来确定要实现的功能需求内容以及何时完成开发。

当产品管理团队和产品开发团队都工作在这些功能需求集上时，两个团队的目标不同，再加上一个功能需求可能属于多个产品特性，在一个功能需求上达成一致（确定它的发布版本和优先级），确实需要这两个团队进行大量的协商交流。

在确定了问题的根源之后，最终采纳了如下解决方案：

• 在产品开发过程中引入”产品特性”；
• 将产品特性置于功能需求的上层；
• 在产品特性和功能需求之间进行多对多的关联关系管理。

首先，由产品管理团队定义产品特性文档，确定每个产品特性的发布版本和优先级。接着，由产品开发团队定义功能需求文档，并建立功能需求与产品特性之间的关联关系，即哪些功能需求是满足哪些产品特性的。功能需求的发布版本和优先级继承于产品特性的发布版本和优先级。

随着产品特性与功能需求之间关联关系的不断建立，会出现一条功能需求关联多个产品特性的情况。这时，让此功能需求继承所关联多个特性的最早发布版本和最高优先级。

当所有产品特性以及产品特性与功能需求的关联关系确立起来后，发现一共定义了200多个产品特性。最重要的是，产品管理团队不再直接决定功能需求，只是确定产品特性及其发布版本和优先级，而由产品开发团队来决定产品特性的解决方案——功能需求，并通过产品特性和功能需求间的关联关系来确保功能需求的开发进度能够符合产品特性上市时间的要求。产品特性和功能需求的关联关系通过需求管理工具自动化地进行管理，更进一步提高了工作效率。

在采取了这一新的解决方案之后，需求振荡大为减少，某些情形下，需求振荡减少了96%，原来8000多条需求的批准时间缩短为6周，版本发布时间间隔降低4倍。

DevOps价值流管理的端到端软件交付度量正在兴起

软件敏捷方法到现在已经有20年的历史了，已经发展的非常成熟，积累了很多实践经验和数据。大型企业现在开始认识到，数据分析可以在有效的大规模敏捷软件交付中发挥关键作用。因此，目前对软件交付度量的兴趣大增。

对端到端度量在有效的敏捷软件交付中的重要性的认识，与DevOps价值流管理概念的发展相吻合。价值流管理（VSM）鼓励技术团队将敏捷交付视为一个端到端的价值交付过程，需要精心的协调和管理。端到端的度量和分析对有效的价值流管理至关重要——以衡量价值的实际交付效果。

"组织缺乏对产品交付的端到端可视性，并努力改善其价值流。领导者......必须实施DevOps价值流管理平台并分析价值流度量，以优化产品交付的整体健康状况。" （来源：Gartner DevOps价值流管理平台市场指南 2020年9月。）

DevOps价值流度量

业务成果的衡量是 VSM 价值流管理的最终目标，业务成果通过业务指标可以反映出来，如收入提高、成本降低、客户留存、净推荐值。研发工程度量通常是技术侧的效率、质量、成本进行的，价值流的度量可以作为超越工程技术度量的起点，并延展到业务成果的衡量。

价值流框架和大规模敏捷框架 SAFe 都提到了流的度量，主要包括以下指标：

• 流速

流速度量在给定时间内交付的工作项数量，即我们交付了多少价值，用以衡量价值传递是否在加速。

流速度量的是在给定时间范围内完成的积压项目（故事、功能、能力、史诗）的数量，这也称为系统的吞吐量，如下图所示。

最简单的速度度量是计算一段时间内完成的工作项的数量，例如敏捷项目的迭代。这些工作项可以是故事、功能、能力，甚至是史诗。但是，由于工作项的大小并不完全相同，因此更常见的衡量标准是在单位时间内某类型工作项的已完成故事点的总数。

在所有其他条件相同的情况下，更高的速度意味着更高的输出，并且是一个很好的指标，表明正在使用价值流改进来识别和消除系统中的延迟。然而，系统的速度不会永远增加，随着时间的推移，系统的稳定性很重要。如果流速出现显著下降，则说明这是一个值得进一步调查的问题。

• 流时间

流时间度量流工作项从“工作开始”到“工作完成”所用的时间，包括活动时间和等待时间。

流时间衡量价值流中所有步骤的总时间，因此是衡量整个系统效率的指标。流时间通常是从构思到生产的整个过程进行度量的，但度量价值流中特定环节的流时间也很有用，例如从代码提交到部署完成的流时间，以确定是否需要改进CI/CD的效率。

流时间通常通过完成特定类型的工作项（故事、特性、能力、史诗）所需的平均时间长度来衡量。直方图是流动时间的非常有用的可视化方式（如下图），因为它有助于识别可能需要注意的异常值，同时支持减少总体平均流时间的目标。

流时间确保组织和团队专注于重要的事情——在尽可能短的时间内为业务和客户提供价值。流时间越短，我们的客户花在等待新功能上的时间就越少，组织产生的延迟成本就越低。

• 流效率

流效率衡量价值流的总活动时间占总的流时间的比率，用以识别价值流中的等待和浪费。

为了正确衡量流效率，必须清楚地了解交付流程是什么，以及经过了哪些步骤。这种理解是在价值流映射的帮助下实现的，价值流映射是一个识别系统中工作流步骤和延迟的过程方法。一旦映射了所有步骤，就可以通过将总活动时间除以流时间来计算流效率，并以百分比表示，如下图所示。

通常，在没有进行价值流优化的系统中，流效率可能非常低，通常为个位数。较低的流效率显示出系统中的大量浪费，以及应该解决的瓶颈和延迟。相反，流效率越高，系统就越能快速交付价值。

• 流负载

测量价值流中当前正在进行（活动或等待）的流工作项的数量，用以监控价值流的过度利用和利用不足，这会导致生产力下降。

流负载表示系统中当前有多少工作项，保持健康的、有限数量的活动工作项（限制在制品）对于使工作项快速通过系统至关重要。

累积流图 (CFD) 是一种常用工具，用于有效地可视化随时间变化的流量负载（如下图）。CFD 显示特定状态下的工作数量、工作项被接受到工作队列中的速率（到达曲线）以及它们完成的速率（离开曲线）。在给定时间点，流负载是该点曲线之间的垂直距离。

流负载的增加是在制品过剩的领先指标。随着开始在系统中建立队列，可能的结果将是未来流时间的增加。因此，度量和减少流负载至关重要。除此之外，很容易看出更频繁的输送如何降低流负载，同时改善流时间和流速。

• 流分布

衡量价值流交付中四种流工作项（特性、缺陷、风险和技术债）的分布。

流分布度量系统中每种类型的工作量随时间的变化。这可能包括新业务功能（或故事、能力或史诗）相对于技术债工作的权衡，以及解决缺陷和降低风险的工作。

一个简单的比较就是在任何时间点统计每种工作项的数量，或者通过使用故事点来计算每个工作项的大小。敏捷团队可以选择度量每次迭代的流分布，但通常使用产品增量在更高级别进行此计算，如下图所示。

为了平衡当前和未来的速度，重要的是能够跟踪在系统中移动的每种类型的工作数量。过多地关注新的业务功能，可能将导致架构/基础设施工作无法解决各种形式的技术债务，并实现未来业务价值。过多的技术债务投入可能会导致向客户提供新价值和当前价值的能力不足。可以确定每种工作类型的目标容量分配，以帮助平衡这些问题。

价值流度量案例--将企业软件交付周期缩短25%

一家高知名度的跨国数据企业使用价值流管理作为驱动软件交付改进的关键因素，在其全球软件交付团队中，有超过2000名工程师分布在多个地点。通过价值流度量和报告，支持他们在全球交付组织内的OKR（目标和关键结果）流程。例如，周期时间被确定为需要改进的关键机会领域，并制定了具体的OKR，在6个月内将周期时间减少25%。

周期时间被认为是至关重要的，因为在一个以快速上市为关键差异化因素的行业，快速交付新功能的压力越来越大。

利用价值流管理平台上的价值流度量和工程度量，包括 "解决拉取请求的平均时间 "和 "流效率"，团队推动了一些流程改进措施，并看到周期时间逐月减少，在6个月后，软件交付的周期时间平均减少25%。

5个关键收获

1. 以一套简单的北极星度量为基础的持续改进措施，让团队理解并信任，可以在软件交付结果方面实现快速、可持续和大规模的改进。
2. 在大规模的交付环境中，OKR提供了一个有效的框架，优先考虑一组简单的改进目标（如周期时间改进25%）。
3. 使用价值流管理平台，发现有四个度量直接影响到多个团队的周期时间：流效率，解决拉取请求的平均时间（小时），首次通过率，和准备开发的故事点。
4. 价值流管理平台被嵌入到团队的管理流程中（例如站会，冲刺回顾），跟踪和管理这四个决定性的度量，结果是在6个月内，整个价值流的平均周期时间减少了25%。
5. 团队信任度量和分析的质量，价值流管理平台使他们能够看到度量的来源以及是如何计算的，并且可以个性化配置度量以符合他们的实际团队情况。

价值流管理是DevOps能力持续左移的必然发展

在企业数字化转型的过程中，IT的数字化创新和交付能力至关重要。蕴含精益和敏捷思想的 DevOps 建设必须能够有效地帮助企业加快 IT 和业务的融合，实现 IT 的左移，加速将产品更快地推向市场，通过业务创新和极致用户体验增加产品的创新价值，并降低数字化转型过程风险。

因此，VSM 价值流管理是 DevOps 能力持续左移的必然发展，相信必将会不断找到新的应用场景，在使能企业数字化转型中发挥关键作用，始终聚焦于交付以客户为中心的价值，做正确的事。