【VSM每周观点】在数字经济中通过软件驱动业务价值｜第14期

从系统思维的角度来看，我们将DevOps改进称为局部优化。因此，对DevOps工具的投资不能提高我们的软件价值交付能力，除非我们也解决了模糊前端来满足我们的软件交付流水线。

VSM Consortium在2022年2月25日发布了 “ Driving Business Value Through Software in Our Digital Economy ” 的文章 ，以下内容是对此篇文章的翻译。

翻译&配图：黄锦辉

如今，在市场上几乎没有企业不依赖通过软件获取竞争力。在这方面做得最好的组织具有竞争优势。此外，数字颠覆者（Airbnb、Amazon、Netflix、Spotify、Uber和WhatsApp）已经证明，无论公司的规模多大，有多少年的历史，没有一家公司能够不受颠覆者的影响。在本文中，我将讨论为什么改善软件交付流水线的质量和速度只是有竞争力的解决方案的一部分。

01 精益-敏捷运营模型

The Lean-Agile Operating Model

改善以客户为中心的价值交付并不是一个新奇的想法。敏捷和精益实践者早就明白，我们必须交付满足客户需求和偏好的价值。

在软件社区中，敏捷的一个特定目标是将客户和市场导向的变化视为无法避免的事实，并通过一系列有时间盒的迭代，不断增量地交付新的价值，以满足不断变化的需求。每一个迭代实现的是当下对我们客户具有最高优先级的内容，这些内容由产品所有者在产品待办事项列表中进行定义。作为一个重要的额外好处，敏捷的迭代增量式开发（Iterative and Incremental Development ，IID）模型还允许软件团队在bug积累并变得难以隔离和解决之前立即识别和修复它们。

精益软件开发理念同样专注于交付客户想要的价值。然而，精益方法还涉及对从想法到交付端到端的价值流活动的评估，以最大限度地减少非增值浪费，简化我们的流程，并确保我们的能力与客户需求匹配。精益的目标是以最有效和最快的方式交付我们的客户想要的东西。

总之，基于精益敏捷的实践允许软件开发团队更频繁地交付价值，为客户的建议提供更多机会，消除非增值活动，并通过在软件开发生命周期（SDLC）流水线中将测试左移，从而更频繁地消除错误和缺陷问题。

02 DevOps作为价值交付流水线

DevOps as a Value Delivery Pipeline

DevOps最初是一种以人为本的方法，让开发人员和运维人员一起协作来评估端到端软件交付过程。不管是否有意为之，DevOps借鉴了精益实践者使用的许多理念。例如，团队必须跨越他们的职能筒仓，以理解和改善从想法到交付的工作和信息流。

作为DevOps改进过程的一部分，工具链集成、活动自动化和工作同步都成为了通过软件加速价值流动的一部分。但我们发现我们可以做得更好。例如，价值流管理（VSM）工具和平台集成不同流水线工具之间的数据，提供实时洞察和分析能力，以改善决策。DevOps与VSM平台/工具一起帮助组织通过软件改善和加速价值的流动。

03 流水线和模糊前端

Pipelines and the Fuzzy Front End

我们真的很擅长提升在特定领域软件交付的效率。然而，我们仍然努力从我们的交付团队和流水线中获得最佳的利用率。此外，对DevOps、VSM工具和工具链实施的投资在企业规模上是令人生畏的，需要高管的支持，并包含在组织的投资计划组合中。

我们还有一个问题，交付过程中最大的瓶颈在软件交付流水线的上游，Smith & Reinertsen将其称为模糊前端（Fuzzy Front End，FFE）。

这意味着对下游CI/CD和DevOps流水线的任何改进对组织加速以客户为中心和基于价值的交付的能力几乎没有影响。也就是从识别一个想法或机会到团队充分理解需求，并正式开始工作的时间。不幸的是，这部分探索性的工作至今仍难以评估和自动化。

这个问题并不新鲜，但由于我们在下游软件开发活动中加速工作流的能力不断提升，它变得更加令人恼火。从系统思维的角度来看，我们将DevOps改进称为局部优化。因此，对DevOps工具的投资不能提高我们的软件价值交付能力，除非我们也解决了模糊前端来满足我们的软件交付流水线。

04 管理利益竞争带来的混乱

Managing the chaos of competing interests

具有现代DevOps能力的组织可能会遇到另一个似乎与模糊前端（FFE）截然不同的问题：在待办列表中有太多高优先级的工作项。当竞争派系都以相同的优先级推动他们的变更请求时，就会出现此问题。

Gene Kim、Jez Humble等人在他们的DevOps 实践指南（DevOps Handbook) 中提出了“三步工作法”理念，作为在这种情况下提高软件交付效率的一种手段。DevOps的三步工作法包括：

3）持续学习的原则

这些概念来自传统的精益生产理论，用于帮助软件组织识别和消除阻碍生产力的浪费。但是，这三种方法都没有直接解决工作优先级的问题。例如，任务切换是在精益软件开发中发现的浪费之一，这意味着如果我们在完成之前不断地从一个任务转移到另一个任务，就需要花费时间和精力重新启动。因此，我们需要有一种方法来持续地进行基于价值的优先级评估。

幸运的是，有一种经过验证的策略可以同时解决模糊前端（FFE）和工作任务优先级问题。我给你一个提示：它是作为在企业范围应用的价值流管理（VSM）。但在我们讨论这个话题之前，让我们花点时间更好地理解这个问题。

05 目标比速度更重要

Aiming is more important than speed

模糊前端（FFE）问题的核心是，我们花费大量的时间、金钱和资源来开发我们的CI/CD和DevOps流水线，并安装VSM平台，但却看不到合理的投资回报。当然，高管们不会容忍不能立即产生业务价值的投资。但是，更快地交付软件并不能保证我们能够更快地交付业务价值。

更关键的是我们如何对齐我们的软件交付流水线，以便在尽可能短的时间内交付最高的价值。如果你试图仅凭交付速度来证明你的DevOps和VSM投资是正确的，你可能不会给管理资金的高管留下深刻的印象。相反，如果你能够展示这些改进能够如何加速组织的最高优先级工作项的交付，那么你将获得更大的进展。但是要做到这一点，你需要能够根据对业务的经济影响识别最高价值的工作项。

06 VSM不仅仅用于软件交付

VSM: it's not just for software

VSM不仅仅是改善DevOps软件交付能力的工具策略。相反，VSM一开始是作为应用于组织级别的方法，作为持续改进所有组织价值流的可持续过程。在这种情况下，工作可以分为三种价值流类别：

3）支持价值流

精益思想最重要的方面之一是，无论是什么业务类型，我们的系统都可以持续改进。例如，Eliyahu Goldratt在一本名为《目标》（The Goal）的书中告诉我们他的约束理论（Theory of Constraints），该理论指出，所有业务系统都至少存在一个约束，而系统的最大吞吐量受限于其约束的速度。

假设我们试图以超出约束所能处理的速度引入工作。在这种情况下，随着瓶颈的形成，整个系统开始崩溃，增加在制品，延迟交付，隐藏缺陷。此外，花费时间和金钱来改善不受约束的工作活动只会加剧我们的交付问题，同时增加更多的成本。

VSM方法和工具允许我们识别限制组织价值流的浪费，并评估改进的替代方案。

07 VSM方法的6个步骤

Six step VSM methodology

在我的著作 Driving DevOps with Value Stream Management中，我介绍了一种传统的八步VSM方法。但以下6点是最关键的：

6）计划并实施已识别的价值流改进：专注于驱动竞争价值的数字创新

这六个VSM步骤可以帮助你的组织识别所有价值流中的关键改善机会并进行优先级排序。它们还可以帮助你识别驱动业务改进的数字创新，从而充实你的DevOps流水线。

08 总结

Conclusion

我们现在知道，组织可以花费大量的时间、精力和金钱来发展成熟的DevOps能力，但未必能创造足够的业务价值来证明投资的合理性。尽管如此，DevOps已经成为在现代数字经济中竞争所必需的筹码。

模糊前端问题事实上保证了你的加速流水线不会成为通过软件向客户交付价值的瓶颈。即使你的组织中的待办列表有大量的工作项需要完成，你仍然有一个问题，即哪些工作项产生的价值最大。

幸运的是，VSM作为一种方法论，为组织提供了可以洞察所有价值流的方法，识别和进行优先级排序，并驱动在客户视角的价值最大的数字改进，同时为你的基于软件的价值交付流水线提供支持。