前面的章节分别铺陈了 Wardley Mapping（第 1 章）、领域驱动设计（第 2–4 章）以及 Team Topologies（第 5 章）的概念。本章将把这些概念结合起来并加以说明，所使用的例子是此前已经创建好的会议活动策划器（conference event planner）的 Wardley Map，以及在此基础上发现的子域类型和设计出的限界上下文。
本章首先关注的是：变化如何在系统中流动、依赖关系会带来什么影响，以及哪些约束会影响这种流动。随后，再通过应用 Team Topologies，把团队视角融合进来。
识别合适的变化流
围绕快速变化流进行优化，意味着要分析一个组织内部价值与变化的驱动因素。这意味着要识别系统中最重要的变化发生在哪里——也就是变化流。根据 Team Topologies [6.1]，不同组织中的流类型可能不同，可以是围绕任务、角色、活动、地理区域或客户细分等来组织的流类型。
Wardley Map 中已经识别出的用户需求，可以组合起来形成一条面向活动或面向任务的用户旅程，如图 6.1 所示。它们表明了很好的、由客户驱动的变化流候选项。在会议活动策划器的例子中，诸如提交议题提案、管理征文征稿（CfP） 、评审投稿、构建并发布日程、与讲者沟通，以及注册与登录等用户需求，都代表了面向活动的工作流。
图 6.1 用户需求作为合适的工作流
让团队与系统围绕这些由客户驱动的变化流来组织，能够使组织聚焦在最关键位置上的变化流。下一节将讨论如何评估当前变化流是否足以高效支撑价值交付。
评估变化流
“把事做对”（building the thing right）要求系统围绕快速变化流进行优化。在这样的系统中，一项工作或一次变更会以尽可能少的中断和瓶颈，从想法一路流经系统，最终为客户交付价值，如图 6.2 所示。理想情况下，团队应当能够对整个端到端流拥有完整所有权——从设计、开发、测试、发布，到运行它们所负责的那部分系统——而无需向其他团队进行交接。为了优化快速流动，就需要评估当前的变化流，以识别其中潜在的阻塞因素。
图 6.2 从想法到交付价值的端到端变化流，尽量减少中断与瓶颈
通过使用 Wardley Map，并分析价值链中的依赖关系，组织可以沿着价值链来评估变化流。图 6.3 突出展示了这样一点：沿着价值链追踪依赖关系，能够从高层次帮助理解变化可能如何在系统中传播——也就是识别一次变化会涉及哪些相互依赖的组件，以及为了让变化真正生效，相应哪些团队需要进行沟通与协调。
图 6.3 沿价值链中的依赖关系评估变化流
价值链这种高层次依赖视图，还可以通过进一步下钻到价值流中来补充。所谓价值流，是指为用户生产并交付价值的端到端过程，它包含一系列活动（例如规划、设计、构建、测试和发布某项产品或服务）。通常，不同的价值流之间还会彼此交互。因此，在一个组织的价值链中，可能会涉及多个彼此相连的价值流，如图 6.4 所示。在《Flow Engineering》[6.2] 一书中，Steve Pereira 和 Andrew Davis 将其描述为由核心流和支撑流构成的“价值流网络”。一个价值流可以通过某些过程步骤或活动（例如通过自服务能力）来支撑和赋能另一个价值流。
图 6.4 一个价值链中可能涉及多个相互连接的价值流
为了识别流动中的阻塞因素，价值流映射（value stream mapping）是一种强有力的工具；本章后面“管理约束”一节会讨论它。不过，在此之前，先有必要考察系统内部存在的各种依赖关系。
分析依赖关系
“系统并不是其各个部分行为的总和。它是这些部分相互作用的产物。 ”Russell Ackoff 博士的这句话 [6.3] 强调了：组织应当考虑各部分之间以及与其对应团队之间的交互与依赖。在《Making Work Visible》[6.4] 一书中，Dominica DeGrandis 和 Tonianne Demaria 建议，把团队之间的依赖关系可视化出来，以便让人们意识到：在某个团队完成其工作之前，究竟还有哪些事情必须先发生。她们将依赖分为以下三类：
- 架构依赖（Architecture） ：在一个紧耦合架构中，修改某一部分会显著影响其他部分及其团队。
- 专长依赖（Expertise） ：反映的是，一个团队要继续推进工作，需要依赖另一个人或另一个团队所拥有的特定知识。
- 活动依赖（Activity） ：要求在一个团队能够继续其工作之前，必须先完成某些特定活动。
为了围绕快速变化流进行优化，分析系统中的依赖关系非常重要，其中包括团队之间所需的协调成本与沟通带宽。是否存在紧耦合或阻塞型依赖？相关行为是否分散在整个系统中，以至于为了有效地实现和交付一次变更，必须触碰很多部分并与很多团队打交道？
从架构角度来看，在一个紧耦合架构中，对某一部分的变化会显著影响其他部分，而为了让这些变化真正生效，就需要团队之间进行大量沟通与协调，并且伴随着较高的破坏风险。相对而言，一个模块化、封装良好、松耦合的架构，能够使团队在高度自治和较低破坏风险的前提下，安全且快速地推进工作。限界上下文有助于把相关的业务行为聚合在一起，从而强化高内聚与模块化。正如第 3 章“使用战略性领域驱动设计设计解决方案空间”所描述的，上下文映射会展示限界上下文之间的集成关系及其团队之间的关系。它们基于模型传播和团队之间的沟通带宽来可视化变更耦合，并且还能揭示那些隐性的、不健康的依赖关系，这一点已在第 3 章“上下文映射”一节中讨论过。
从活动依赖和专长依赖的角度来看，重要的是分析团队为了完成工作，在哪些地方依赖于其他团队的活动和专长。团队是否需要反复地把工作交接给其他团队，由其在流动中的前一个阶段或后一个阶段接手，才能把工作做完？交接要求多个团队之间进行持续而频繁的大量沟通与协调，去共同实现并交付变化——这会带来动作浪费（motion waste）。第 9 章“为流动而设计遗留系统”中的“评估当前变化流”一节，会在演进一个遗留系统时考察这些依赖。
管理约束
如果一个团队所依赖的另一个团队，已经被自身的工作压得喘不过气来，跟不上它所接收到的请求，会怎么样？随着工作不断堆积在这个不堪重负的团队那里，依赖它的团队就只能等待，无法完成和交付自己的工作。于是，这个不堪重负的团队就成了变化过程中的一个约束或瓶颈。
更一般地说，在一个多步骤流程中，如果那些位于依赖关系背后的资源（例如团队、人员、机器）无法跟上施加于它们之上的需求，它们就可能成为约束。约束或瓶颈会显著限制整个系统的整体性能。相反，对系统中非约束区域的改进，并不一定会改善整个系统的整体性能。正如 Eliyahu M. Goldratt 所说：“除了瓶颈之外，在其他任何地方做的改进都只是幻觉。 ”[6.5] 如果在瓶颈之前改进系统，只会让更多工作堆积到瓶颈处；而如果在瓶颈之后改进系统，则不会带来任何效果，除了让下游部分继续处于“吃不饱”的状态。约束决定了整体的性能。 1
- 虽然约束理论经常使用“瓶颈”或“约束”这样的术语来描述系统中的限制点，但需要记住的是，当这些概念应用到人或团队身上时，它们指的是情境性的产能限制，而不是在责怪个人。
在其约束理论中，Goldratt 提出了管理约束的五个步骤：识别约束、利用约束、服从约束、提升约束，然后回到步骤 1 [6.6]。识别约束的一种强有力工具，就是价值流映射。
什么是价值流映射？2
- 价值流映射起源于精益制造，用于分析和优化生产系统中的物料与信息流。后来，它也被应用到了数字价值流与软件交付流程中。
价值流映射（Value Stream Mapping，VSM）会把流程流动中的各个步骤可视化，并帮助识别某条价值流中的约束。在图 6.5 中，周期时间（cycle time） 指的是完成价值流中单个步骤所花费的时间，也就是增值时间（VA） 。等待时间（wait time） 则反映步骤之间的非活动时间，例如排队等待、延迟或空闲期，也就是非增值时间（NVA） 。前置时间（lead time） 表示从工作项最初被接收到工作项最终被交付之间所经过的总时间。
图 6.5 一个基础的价值流图
测量每个流程步骤的速度（周期时间、等待时间、前置时间）和质量（交付完整且准确结果的时间占比），能够帮助识别潜在约束。前置时间与周期时间（VA）之间如果存在很大差距，就说明有大量时间被浪费掉了（例如花在等待上）；这些时间既不增加价值，也不向用户交付价值（NVA）。如果某些步骤中“完整且准确结果”的比例很低，则说明有大量时间被花在返工和修复缺陷上，而不是花在增值活动上。3
3. 《Flow Engineering》[6.2] 提供了一种轻量级的价值流映射方法，非常适合知识型工作与软件交付，并给出了优化价值流的可执行步骤。
识别约束的另一种方式，是像 Clark Ching 在《The Bottleneck Rules》[6.7] 一书中所建议的那样，去寻找某个流程、某个团队或整个组织中那些工作正在大量堆积的长队列。真正的约束点可能就在它的后一个步骤中。组织还可以寻找那些处于空闲状态的资源。这些空闲资源可能是在等待某些活动完成之后，才能开始或继续自己的工作；这时，瓶颈步骤就在它们之前。若所有资源都处于空闲状态，这可能表明没有足够的工作流入系统，而负责引入工作的那一部分组织可能才是真正的瓶颈。或者，在适用时，测量每个步骤或资源处理的项目数量，也可以指示约束所在——例如，当相同步骤类型或资源处理的项目数出现明显分歧时。
利用约束，意味着通过优化来确保约束能够聚焦在其最高优先级事项上，而不必再等待其他任何资源，从而避免因此浪费非增值时间。
服从约束，意味着把非约束区域的节奏调整到瓶颈的速度上来。如果这样做之后约束仍未消除，那么接下来就可以考虑提升约束。
提升约束，包括投资于升级和改进约束，以增加其产能或移除其限制。例如，组织可能会雇佣更多员工、改进流程、提供培训以增强技能等等。
如果这些努力解决了当前约束，那么 VSM 流程又会重新开始，回到步骤 1 去寻找下一个瓶颈。提升工作流动，要求我们持续不断地识别并管理约束。
等待时间、延迟、交接次数、缺乏所有权、返工、依赖、复杂性以及协调成本，只是那些可以被处理以提升价值流动的几个问题而已。优先从那些限制最显著的约束着手，有助于提升整个系统的整体性能。而在这方面，Wardley Mapping、DDD 和 Team Topologies 都能够帮助解锁流动中的阻塞因素与低效点。
寻找合适的团队所有权边界
第 5 章“使用 Team Topologies 优化变化流动”强调了：必须尊重康威定律，并避免职能烟囱团队，因为这种团队之间反复交接会阻碍变化流。限界上下文既是有效的领域边界，也是定义清晰的所有权边界，它们共同构成了一个关于目标、精通与自主性的单元。它们同样也非常适合作为流对齐团队的团队所有权边界。
图 6.6 展示了会议活动策划器示例中的限界上下文。这些限界上下文——包括投稿处理、CfP 管理、议题评审、日程管理、消息处理、身份与访问管理以及通知处理——都代表了流对齐团队合适的团队所有权边界。
图 6.6 限界上下文作为流对齐团队合适的团队所有权边界
除了面向活动的用户旅程（例如用户需求）和业务领域边界（例如限界上下文）之外，技术选型、用户画像、变化节奏、监管合规、团队所在地、风险特征等等，也都可以构成其他类型的断裂面（fracture planes），这一概念由 Team Topologies [6.1] 提出。4
4. Team Topologies 的作者还提出了一种轻量级方法，称为 Independent Service Heuristics（ISH） ，它通过一些简单的引导性问题，帮助识别并验证流边界与团队边界的候选项（https://teamtopologies.com/ish）。
寻找合适的团队所有权边界，并不仅仅适用于流对齐团队，而是适用于整个价值链；这一点会在后文“识别支持变化流的服务”一节中继续讨论。
面向小团队
在组织和团队中建立高信任，对于快速的变化流和创新非常重要（另见第 11 章“促进持续改进并推动未来变化”中的“组织文化与安全思维”一节）。然而，单个个体能够维持稳定且值得信任关系的人数是有限的。人类学家 Robin Dunbar 估计，一个人最多可以拥有大约 150 个普遍稳定的社会关系，并能够记住这些人——这一概念被称为 Dunbar number [6.8]。一个人通常可以与大约 5 个人建立亲密关系、与大约 15 个人建立深度信任关系、并与大约 50 个人建立相互信任关系 [6.9, 6.10]。
Dunbar 数也受到过批评，因为它在一定程度上是基于灵长类动物数据的外推，而这些外推未必能准确反映人类社会关系的复杂性 [6.11]。此外，试图用某一个固定数字来界定有意义且稳定的社会群体规模，这一做法本身也一直存在争议 [6.12]。
尽管 Dunbar 理论中的具体数字存在争议，但其背后的信任边界概念，仍然能够提示我们一个团队内部通常可以期待的信任水平。小团队往往比大团队拥有更高的信任水平。更高的信任水平会促进开放沟通、快速信息流动、组织效能、学习与改进 [6.13]。
此外，当新成员被加入一个团队时，团队成员之间的交互量与沟通带宽会显著增加（这也被称为 Brooks 定律 [6.14]）。会议可能会变得更长，决策也可能更困难、更缓慢。综合考虑信任边界与协调开销，瞄准大约 5 到 9 人的小团队（正如 Team Topologies [6.1] 所推荐的）有助于支撑那种深度信任的亲密关系，并保持团队成员之间较低的交互带宽，从而促进快速变化流。
围绕团队认知负荷进行优化
根据 Team Topologies [6.1]，如果团队的认知负荷被大幅超出，它就会变成交付瓶颈。为了围绕团队认知负荷进行优化，一种策略是建立清晰的责任边界，如图 6.7 所示。拥有清晰责任边界时，一个限界上下文不会被多个团队共享，否则团队所有权就会被稀释。5 相反，一个限界上下文只应由一个团队拥有；不过，一个团队可以拥有多个限界上下文。
图 6.7 为优化认知负荷而建立清晰责任边界
- 关于团队所有权边界，也有其他不同视角。例如，LeSS（Large-Scale Scrum）社区主张跨团队的共享代码所有权。虽然 LeSS 的方法强调共享所有权与知识的广泛分布，但本书聚焦的是清晰所有权边界和面向流动优化的系统，将其视为适应性的基础。
优化认知负荷的另一个方面，是限制一个团队必须处理的软件系统的数量、大小与复杂度。这意味着要让边界大小与团队的认知负荷相匹配，并限制每个团队所拥有的限界上下文的数量及其子域类型（或者它们对应的演进阶段）。
把 Wardley Map 演进阶段的特征融合进来，可以初步指示实现某个特定目标所需步骤的清晰程度（即行动路径，path to action），并突出其中所涉及实践层级的差异。位于 commodity（+ utility） 演进阶段的限界上下文，可以利用最佳实践解决方案，因此具有清晰的行动路径（见图 6.8）。根据演进阶段的特征（见第 1 章“用 Wardley Mapping 制定业务战略”），一个限界上下文——或者一般而言某个组件——在 Wardley Map 上越靠左，不确定性就越高，这就要求更多聚焦于探索与发现的实践。每个演进阶段都对应不同的行动路径实践：从最佳实践（commodity + utility），到良好实践（product + rental），再到涌现式实践（custom-built）和新颖实践（genesis）。作为一种经验法则，行动路径越不清晰，潜在认知负荷就越高。因此，从理论上讲，一个团队能够管理的 commodity（+ utility）阶段限界上下文（或一般组件）的数量或规模，会比 genesis 阶段更多。
图 6.8 处理 Wardley Map 左侧组件时，认知负荷的经验法则往往更高
需要注意的是，图 6.8 所展示的这种经验法则，仅仅是一种用于初始快速分类的近似。虽然它在某些时候很有用，但并不能保证它就是最优的。最好再结合其他技术或框架，例如 Cynefin。
什么是 Cynefin？
Cynefin 是 Dave Snowden 发明的一种决策框架 [6.15]。它帮助人们根据因果关系来对某种情境进行分类，并决定应对该情境的最合适方式。如图 6.9 所示，它由五个域构成。
图 6.9 Cynefin 框架
右侧的两个域（“clear”与“complicated”）是有序域，其因果关系是清晰可见的，或者至少是可被发现的。左侧的两个域（“complex”与“chaotic”）则是无序域，其因果关系只能在事后得出，甚至根本无法得出。
- Clear（清晰） ：因果关系清晰，属于已知的已知，可以应用最佳实践。最好的应对方式是 sense–categorize–respond：先感知事实，再分类，然后通过应用规则或最佳实践来响应。
- Complicated（繁杂） ：代表已知的未知，其中因果关系不那么清晰，需要分析与专业知识。推荐的应对方式是 sense–analyze–respond：收集数据，分析，然后通过应用良好实践来响应。
- Complex（复杂） ：由未知的未知构成，因果关系只能在事后才能得出结论。此时只存在涌现式实践。最佳应对方式是 probe–sense–respond：先实验，观察发生了什么，再据此调整。
- Chaotic（混沌） ：不存在因果关系，且混沌域中的事物变化极快。它代表一种紧急状态，不宜停留太久。应对方式是 act–sense–respond：先采取行动建立秩序，再观察发生了什么，并进行调整，以便把混沌状态转变为复杂状态，同时应用新颖实践。
- Disorder（失序） ：如果某种情境无法被清晰地归类，它就处于失序状态。此时的出路是收集更多信息，把情境拆分成若干离散部分，再把这些部分分别归入前述定义好的各个域。
这些域之间的边界是流动的，允许彼此转换。随着知识的增加，一个混沌域可以变成复杂域，一个复杂域可以变成繁杂域，一个繁杂域又可以变成清晰域。不过，clear 与 chaotic 之间的边界与其他边界不同（在图 6.9 中表现为悬崖）。如果你开始过度简化，并把 clear 域中的方法套用到一个实际上更接近 complicated 或 complex 的情境中，就有可能从悬崖边跌落，进入 chaotic 域中的危机状态，而从那里恢复的代价会非常高。
将限界上下文归类到 Cynefin 的 clear、complicated、complex 和 chaotic 这些原型情境之中，不仅有助于确定该采用什么样的应对方式，也提示了处理它所需的认知负荷水平。对于某个特定情境或限界上下文而言，因果关系越不清晰，所需的认知工作负荷就越高。
等等，这不就是图 6.8 所展示的那种经验法则在做的事情吗？某种程度上，确实是。Cynefin 的各个域及其对应实践，被隐式地一一映射到了 Wardley 的演进阶段上：
- Clear → commodity → 最佳实践
- Complicated → product → 良好实践
- Complex → custom-built → 涌现式实践
- Chaotic → genesis → 新颖实践
这种映射在某些情况下可能有用，但一个处于某个演进阶段的组件或限界上下文，也可能被归类到与这种一一映射不同的 Cynefin 域中。例如，从演进角度看，一个组件可能已经作为 commodity 存在，但从 Cynefin 的角度来看，它仍可能被视为 complex 或 complicated。
回想一下在讨论核心域时提到的云托管服务示例（见第 2 章“使用战略性领域驱动设计与 Wardley Mapping 探索问题空间”中的“结合子域类型与演进阶段做 Build-or-Buy 决策”一节）。云托管服务作为 utility 服务是可用的。从消费者视角来看，它们通常位于 commodity 演进阶段，并且已经存在用于消费和使用这些云服务的最佳实践。然而，对于云服务提供商而言，生产这些服务却可能属于 complicated，甚至 complex 域——因为要为大众提供安全、可扩展且可靠的云服务，需要极高水平的专业知识。甚至对于消费者而言，如果他们几乎没有或完全没有相关先验知识与经验，云服务也可能被视为 complicated 或 complex。这个问题会在下一节中更深入地讨论。
将组件的演进阶段与 Cynefin 域结合起来，有助于推导出：在生产或消费该组件时，团队所需承受的认知负荷水平。一个团队能够拥有的 clear/simple 域组件数量，会多于其能够拥有的 complicated 或 complex 域组件数量。在《Team Topologies》[6.1] 一书中，作者建议：一个单独的小团队可以处理 2 到 3 个 clear 域；而对于 complicated 和 complex 域，根据他们的建议，一个团队通常不应同时拥有超过 1 个。
为自适应团队考虑多元思维方式的组合
Wardley 的教义原则“兼顾能力与态度”说明了：并不存在一种能够适用于所有团队的单一文化或思维方式。根据这一教义，那些负责位于 genesis 或 custom-built 演进阶段组件的团队，应当主要由具备 Explorer 心态的人组成。负责 product + rental 阶段组件的团队成员，则应当更偏向 Villager 心态。而负责 commodity + utility 阶段组件的团队成员，则应当更具备 Town Planner 式的思维方式。为了能够践行这一教义原则，Wardley 建议：在为团队分配职责时，不要过度跨越并混合不同演进阶段。
那么，这一教义如何应用到 Team Topologies 上呢？如果一个组织真的建立纯粹由 Explorer 组成的团队、纯粹由 Villager 组成的团队以及纯粹由 Town Planner 组成的团队，难道不会再次引入瓶颈吗？此外，流对齐团队本来就被期望对某条工作流承担端到端责任，包括探索、规划、设计、构建、测试、部署、运行、支持以及退役。它们的目标是让自己的工作流（例如限界上下文）随着时间演进，并跨越多个演进阶段。那这是否与上述教义原则相矛盾？
首先，一个组件从一个演进阶段移动到下一个演进阶段，通常并不是几天内就完成的事；这往往需要若干年时间（取决于供需竞争的程度）。从理论上讲，因为演进而把某个组件交接给另一个团队，并不是一种反复发生的频繁交接。相反，这种交接是在较长时间之后才发生一次，因此它不会妨碍日常的变化流惯例。
其次，位于 product + rental 或 commodity + utility 阶段的组件，潜在地已经存在良好实践或最佳实践。然而，如果一个团队此前从未接触过这些组件，无法借助过往反复出现、可被认知的活动经验，那么在它们自己的具体语境下，处理这些组件就可能构成一个 复杂（complex）Cynefin 域，如图 6.10 所示。此时，推荐的做法依然是先采用实验与发现（例如通过敏捷方法）。例如，假设一个组织计划把当前的本地基础设施组件迁移到未来的云托管服务上，但它此前从未有过上云经验，而且组织内部也不存在云相关专业能力。那么，在这种情况下，对它而言，迁移去使用云服务就是该语境下的新事物，它属于一个复杂域，组织可能需要先进行探索与发现。
图 6.10 处于同一演进阶段的组件，可能会落入不同的 Cynefin 域
随着知识的增加，复杂域可以变成繁杂域，而繁杂域又可能变成清晰域。也就是说，在 Wardley Map 中，某个特定演进阶段的组件，在不同时间点上，完全可能落入不同的 Cynefin 域。这个情境是很流动的，取决于团队是否能够建立在既有经验之上。因此，团队必须能够根据具体情境以不同方式进行响应，而这就要求团队内部具备一种多元思维方式的组合。
从本质上讲，“兼顾能力与态度”这一教义原则，应当被理解为对某些偏好与心态的倾向性强调，而不是一种要求把个人组织成某种“纯 X 型团队”的硬规则。每个演进阶段都倾向于某种特定心态或偏好，但这并不排斥其他心态与偏好在团队中也同时存在。更准确地说，每个团队中都存在一组不同的心态，只不过其中某一种会比其他几种更占主导。如图 6.11 所示，拥有位于 genesis 或 custom-built 阶段组件的团队，可能会更偏向 Explorer 心态，更喜欢发现与试验；拥有位于 product（+ rental）阶段组件的团队，可能更偏向 Villager 心态，更关注改进与稳定；拥有 commodity（+ utility）阶段组件的团队，则可能更偏向 Town Planner 心态，更关注成熟化与优化。
图 6.11 每个演进阶段下团队偏好与心态的倾向性
从 Team Topologies 所偏好的团队类型来看，并不需要让流对齐团队一定是“纯 Explorer 团队”，也不需要让平台团队一定是“纯 Town Planner 团队”。真正关键的，是每个团队内部所具备的那组心态与偏好。根据它们所拥有组件的演进阶段，某一种特定心态与偏好可能会更占主导，从而在团队层面形成某种 T 型心态结构。此外，Explorer、Villager 与 Town Planner 这三种偏好之间并非彼此排斥。例如，一个拥有 commodity 组件的团队，也可能会在探索新技术时切换到探索模式，采用敏捷技术，并在一段有限时间内与其他团队进行紧密协作。这一点会在第 10 章“实施流动优化”中结合遗留系统演进与流动优化实施进行更详细的讨论。
在不同思维方式这一点上，还存在一个关于产品开发的补充模型：Explore–Expand–Extract（3X） 。
什么是 Explore–Expand–Extract（3X）？
3X 模型由 Kent Beck 发明 [6.16]。它提出了产品开发中的三个不同阶段，以寻找创新解决方案：
- Explore（探索） ：第一阶段通过探索，去发现一个可行的产品思路，以解决团队试图处理的问题。这意味着并行地发起多个低风险实验、提出问题、开展研究等，其目标是学习、获得洞察、识别约束并澄清目标。从 Cynefin 角度看，探索阶段可能跨越复杂域和混沌域。
- Expand（扩展） ：这一阶段聚焦于逐步构建并改进在 Explore 阶段中被证明有前景的初始实验。随着产品用户数不断增长，扩展中的瓶颈开始显现。Expand 阶段的目标，是识别并消除这些新出现的、意料之外的扩展瓶颈，以保持用户增长。
- Extract（提炼） ：这一阶段的目标是优化成本，并让产品在长期内具有可持续性。相较于更强调用户增长的 Expand 阶段，Extract 阶段更关注变现，也就是通过降低成本和提升利润来实现。用 Cynefin 的术语来说，Extract 阶段通常属于 complicated 域，在某些情况下也可能向 complex 或 clear 域倾斜。
3X 的不同阶段要求不同的思维方式——这也就把讨论又带回了 Wardley 的 Explorer、Villager 与 Town Planner 三种心态。Explorer 对试验与失败感到自在，非常适合 Explore 阶段。Villager 致力于改进与稳定，非常适合 Expand 阶段。Town Planner 则以成熟化与优化为导向，因此非常适合 Extract 阶段。
识别支持变化流的服务
流对齐团队依赖其他团队来支持它们完成工作。这意味着，必须识别出那些支撑可靠变化流所需的服务，并把它们构造成容易被消费的平台，以 X-as-a-Service 的方式提供。Wardley Map 中由相互依赖组件构成的价值链，可以成为识别那些支持可靠变化流服务候选项的一个很好起点。
在会议活动策划解决方案的例子中，各个限界上下文依赖于一些基础设施组件，例如数据存储、计算平台等等。正如图 6.12 所展示的，在这个例子中，那些位于 Wardley Map 的 product（+ rental） 与 commodity（+ utility） 演进阶段的基础设施相关组件，就是非常适合由平台团队以 as-a-service 方式高效提供的平台候选项。需要注意的是，这张示例 Wardley Map 出于演示目的被保持得非常简单——它省略了其他更高抽象层次上的平台候选项，例如设计系统、数据平台等等。第 7 章“用 Wardley Map 可视化团队视角”会更详细地讨论平台团队视角下的价值链。
图 6.12 识别那些支撑可靠变化流的服务
平台可以从一个**最薄可行平台（TVP）**开始。这样的一个平台只需要“大到刚好够用”，能够满足其消费者的用户需求即可，不应当变得比实际需要更大。TVP 可以从文档、标准、检查清单、最佳实践或模板开始。之后，它可以逐步演进为一个带有自服务 API 和工具的数字平台。第 7 章会用另一张独立的 Wardley Map 来讨论与平台团队相关的价值链。
一种可能的团队编排
前面的这些考量，可能会导出如图 6.13 所示的团队编排方式。
图 6.13 一种可能的团队编排
在这种团队编排中，四个处于 custom-built 演进阶段的核心域相关限界上下文，被拆分给了两个流对齐团队。如果在某个时点，团队的认知负荷被超出了太多，那么就可能需要把一个核心域相关限界上下文仅仅分配给一个流对齐团队。组织也可以让团队自己决定，它们希望覆盖到什么程度。
在这个例子中，与支撑型和通用型子域相关的限界上下文，则会由另一个流对齐团队来处理。正如前面给出的经验法则所描述的，限界上下文在 Wardley Map 上越靠左，不确定性、复杂性与变化速率就越高（要注意，这种经验法则只是一个粗略的方向指引，而不是严格规则）。粗略来说，一个单独团队能够拥有的、位于 Wardley Map 更左侧的核心域限界上下文数量，会少于它能够拥有的那些位于 Wardley Map 更右侧、处于 product（+ rental）或 commodity（+ utility）阶段的支撑型与通用型子域限界上下文。
基础设施组件则会由一个或多个平台团队来负责。接下来很快会详细讨论平台团队视角。
识别能力缺口
跨职能自治团队需要覆盖一系列能力，例如软件设计与架构、应用安全、用户体验（UX）、测试、基础设施、可观测性、软件开发等等。但除了这些技术相关能力之外，团队成员还需要一些与有效沟通和实践改进相关的技能，例如团队教练、辅导、编写高质量文档、流程改进等等。识别这些能力缺口，并帮助团队获得缺失能力，是赋能团队的职责。根据具体语境，有时可以先从兼职赋能团队开始，之后再转变为全职、专职的赋能团队。
小结
本章聚焦于把这些拼图碎片拼接起来，如图 6.14 所示。它说明了：Wardley Map 中的用户需求，如何构成面向活动的变化流的良好候选项。
图 6.14 将 Wardley Mapping、战略性 DDD 与 Team Topologies 串联起来
用户与用户需求，不仅构成了 Wardley Map 的锚点，也在 DDD 语境下勾勒出了问题领域。DDD 中的限界上下文，则是流对齐团队很好的团队所有权边界候选项。在 Wardley Map 上位置越靠左的限界上下文（或者更一般地说，越靠左的价值链组件），往往会带来更高的潜在认知负荷。当围绕团队认知负荷进行优化时，一个团队能够拥有的、处于 commodity 演进阶段的限界上下文，在数量或规模上会多于它能够拥有的、处于 genesis 演进阶段的限界上下文。不过，为了实现清晰的责任边界，一个限界上下文应当只由一个团队拥有，而不应跨团队共享。
为了能够聚焦于持续不断的变化流，流对齐团队依赖平台团队来提供支持其软件交付的内部服务。例如，对于那些屏蔽底层基础设施、网络与横切能力的平台，平台团队可以为那些主要位于 Wardley Map 的 product（+ rental） 和 commodity（+ utility） 演进阶段的组件，提供一种 platform-as-a-service。识别并弥补能力缺口，则是赋能团队的职责。这些考量共同帮助塑造出可能的团队编排方式。此外，应用 DDD 与 Team Topologies，也有助于组织落实 Wardley 的教义原则。
在本章中，我们使用了会议活动策划器示例的 Wardley Map，以及此前已经设计好的限界上下文，来识别合适的变化流、团队所有权边界，以及那些支撑可靠变化流的内部服务。在此基础上，又推导出了流对齐团队与平台团队的一版初始团队编排方案。
下一章将从平台团队和赋能团队的视角，展示价值链与 Wardley Map。
