2010 年代是软件工程史上的一个转折点。在本世纪初，Eric Ries 通过The Lean Startup(精益创新)颠覆了构建数字产品的传统方法。在这十年末，Matthew Skelton 和 Manuel Pais 通过Team Topologies（团队拓扑）为未来十年的数字化运营模式奠定了基础。
这两种方法都极大地影响了公司组织团队的方式的演变，以便更好地发现价值并通过改进的流程加速交付。授权的产品模式团队已成为主流，过时的以项目为中心的模式继续消失。
这个时代的两个标志性概念是由精益创业推广的MVP（最小可行产品）和团队拓扑中的核心概念价值流。
虽然 MVP 已经成为主流很长一段时间，但价值流和价值流架构的概念在 DevOps 世界中仍处于早期采用阶段。尽管价值流已有几十年的历史，但随着转向以产品为中心的运营模式，它们最近在 DevOps 中重新流行起来。
价值流
多年来，价值流的概念已被不同社区采纳。我相信它起源于 70 年代或 80 年代的精益制造。从那时起，它就被六西格码、企业/业务架构以及最近的敏捷和 DevOps 社区所采用。
由于价值流应用于不同的环境，它们有不同的风格和不同的服装。有时最好具体说明您所指的价值流类型。
在本文中，价值流被定义为端到端的业务流程以及组织为交付客户价值而采取的相关步骤。也可以将其理解为向客户提供价值（通常是产品或服务）的业务线。对于传统的以项目为中心的方式中，真正的价值往往被以项目为中心的指标（如按时和按预算）所掩盖。价值流由长期存在的跨职能团队组成，而不是围绕特定项目临时组织的临时团队；由于团队持续运作，因此他们能够进行持续改进。
价值流两种：
- 开发价值流：这些是将想法转化为新产品和能力增强的价值流。
- 还有运营价值流，它们是向客户提供产品或服务所需的一系列活动。
授权的产品模式团队
获得授权的产品模式团队负责在特定业务领域中发现和交付价值。他们可能负责产品面向用户的部分，例如移动应用程序或面向内部的 API。在任何情况下，团队都必须发现客户未满足的需求，并提供产品改进以满足这些需求。
一个团队负责的业务领域是一个域。团队为发现其领域中的潜在价值并以新/改进产品增强的形式交付价值所经历的步骤就是他们的价值流。
领域和价值流之间的关系是双向的。在理想的世界中，从空白画布开始，首先定义每个团队将负责的域是合乎逻辑的（DDD 可以提供帮助）。
即使建立了领域和价值流，也需要不断发展。领域和软件边界错误的最好迹象之一是价值流中的问题，例如高 WIP 或外部依赖性导致的高等待时间。团队中的高水平 WIP 表明认知负荷太高——领域可能太大，单个团队无法拥有并需要拆分。
定期的跨团队依赖表明不同领域的两个部分经常一起变化。也许应该更改域边界，使它们成为同一域的一部分并由单个团队拥有。