Team Topology
解决什么问题：把 Conway 定律落地为可操作的团队设计模板——避免"知道组织结构决定系统结构，但不知道怎么设计团队"，转而用 4 种团队类型 + 3 种交互模式直接设计可持续的团队拓扑。
它是什么
团队拓扑（Team Topologies） 是 Matthew Skelton 和 Manuel Pais 在《Team Topologies》（2019）中提出的团队设计框架——它把 Conway 定律工程化为 4 种团队类型 + 3 种交互模式：
4 种团队类型：
| 类型 | 职责 | 例子 |
|---|---|---|
| Stream-Aligned Team | 直接对业务流（一个 / 多个）端到端负责 | 订单团队、推荐团队 |
| Enabling Team | 帮助其他团队提升能力（不直接交付业务） | DevOps 教练、测试专家 |
| Complicated-Subsystem Team | 维护需要专业知识的复杂子系统 | ML 平台团队、搜索引擎团队 |
| Platform Team | 提供内部平台（XaaS）支撑业务团队 | K8s 平台、数据平台 |
3 种交互模式：
| 模式 | 含义 | 例 |
|---|---|---|
| Collaboration | 紧密协作（短期、密集） | 业务团队 + 平台团队共同开发 |
| X-as-a-Service | 通过服务接口消费 | 业务团队消费平台团队的 PaaS |
| Facilitating | Enabling 团队帮助其他团队 | DevOps 教练辅导业务团队 |
控制论 Ch 21 §21.3 多级分散控制是对位： "多级结构 = 顶层协调器 + 中层协调 + 底层执行" 软件工程对位：Platform Team = 顶层协调器；Stream-Aligned Team = 中层；具体服务 = 底层。
SE@G Ch 3 印证： "The team structure should match the codebase structure."——团队拓扑 = 代码库结构。
IDDD Ch 3 Bounded Context 与 Stream-Aligned Team 的对应： Vernon 反复强调：每个 BC 必须有一个明确的 team owner——这正是 Stream-Aligned Team 的定义。
V2 视角（V2.7 B7 段 5）：Team Topologies 是 B7 演化的团队设计模板——团队拓扑稳定了，演化才有组织基础。
关键属性
| 属性 | 含义 | 软件工程实例 |
|---|---|---|
| 4 种类型 | Stream / Enabling / Complicated / Platform | 业务 / 教练 / 专业 / 平台 |
| 3 种交互 | Collaboration / X-as-a-Service / Facilitating | 紧协作 / 服务消费 / 辅导 |
| 认知负载 | 每个团队的认知负载有上限 | 5-9 人 / 单一职责 |
| 流对齐 | Stream-Aligned Team 对齐业务流 | 一个团队 = 一个或多个 BC |
| 平台化 | Platform Team 提供内部 XaaS | 自服务化降低业务团队认知负载 |
| 最小化认知负载 | 让业务团队专注业务 | 把复杂抽象为服务 |
| 动态拓扑 | 拓扑可演化 | 团队重组 → 拓扑变化 |
| Conway 应用 | 是 Conway 定律的工程化 | 团队结构 = 服务结构 |
怎么用
场景 1：识别团队拓扑的健康度
5 个检查项：
1. 每个业务流（订单 / 推荐 / 搜索）有端到端负责的团队？
→ 是 = Stream-Aligned 健康；否 = 跨团队协调失控
2. Stream-Aligned Team 的认知负载是否过高？
→ 不过高 = 健康；过高 = 需要 Platform Team 减负
3. 平台团队是否提供真正的自服务？
→ 是 = 平台健康；否 = 平台团队变成瓶颈
4. Enabling Team 是否真的帮助其他团队？
→ 是 = 健康；否 = Enabling Team 变成"二级业务团队"
5. Complicated-Subsystem Team 是否有明确的专业边界？
→ 是 = 健康；否 = 边界模糊 → Conway 失配场景 2：用 Team Topologies 设计新组织的步骤
步骤 1：识别业务流（Streams）
业务流 = 一个端到端的价值交付单元
例：订单流（用户下单 → 支付 → 履约 → 售后）
每个业务流 → 至少一个 Stream-Aligned Team步骤 2：识别复杂子系统（Complicated-Subsystem）
复杂子系统 = 需要专业知识的子系统
例：ML 推理引擎、搜索引擎、风控引擎
每个复杂子系统 → Complicated-Subsystem Team步骤 3：识别平台需求（Platform）
平台 = 多个业务团队共用的基础设施
例：CI/CD 平台、K8s 平台、数据平台、监控平台
平台 → Platform Team（提供 XaaS）步骤 4：识别 Enabling 需求
Enabling = 跨团队能力提升
例：DevOps 教练、测试专家、安全专家
Enabling → Enabling Team（不直接交付业务）步骤 5：定义交互模式
- Stream-Aligned 与 Stream-Aligned：API / 事件（X-as-a-Service）
- Stream-Aligned 与 Platform：X-as-a-Service + 偶尔 Collaboration
- Stream-Aligned 与 Enabling：Facilitating（短期辅导）
- Stream-Aligned 与 Complicated-Subsystem：X-as-a-Service场景 3：用 Team Topologies 诊断现有组织
诊断 1：所有团队都是 Stream-Aligned
症状：没有 Platform Team / 没有 Enabling Team
问题：业务团队承担所有基础设施工作 → 认知负载过重
应对：把共性基础设施抽到 Platform Team诊断 2：太多 Enabling Team
症状：Enabling Team 多于 Stream-Aligned Team
问题：Enabling Team 变成"二级业务团队"
应对：Enabling Team 必须辅导具体团队，不能自己交付业务诊断 3：Platform Team 变成瓶颈
症状：业务团队等 Platform Team 的支持
问题：Platform Team 没提供自服务
应对：Platform 必须是 XaaS，不是 ticket queue诊断 4：Stream-Aligned Team 太大
症状：单个 Stream-Aligned Team > 9 人
问题：沟通成本失控
应对：拆分业务流（按子流），或增加团队成员到 9 人后拆分场景 4：团队拓扑的演化
演化模式 1：单团队 → 多 Stream-Aligned
起点：一个团队负责所有业务
演化：业务流识别 → 拆分为多个 Stream-Aligned Team
触发：业务规模扩大 / 单团队认知负载过重演化模式 2：业务团队自建基础设施 → 抽 Platform Team
起点：每个业务团队自建 CI/CD、监控、日志
演化：识别共性 → 抽 Platform Team → 业务团队消费 XaaS
触发：基础设施重复建设 / 业务团队认知负载过重演化模式 3：业务团队承担复杂子系统 → 抽 Complicated-Subsystem Team
起点：业务团队各自维护 ML 推理引擎
演化：识别需要专业知识的子系统 → 抽 Complicated-Subsystem Team
触发：业务团队无法维护专业子系统 / 系统质量下降演化模式 4：能力分散 → Enabling Team
起点：DevOps 能力分散在每个团队
演化：识别能力短板 → 建立 Enabling Team → 跨团队辅导
触发：某项能力（DevOps / 测试 / 安全）成为瓶颈常见误区
- "4 种类型必须全有" ——错。小组织可能只有 Stream-Aligned + Platform——4 种是参考，不是必备
- "Platform Team = 基础设施团队" ——错。Platform Team 必须提供自服务 XaaS，否则是 ticket queue = 瓶颈
- "Enabling Team = 二级业务团队" ——错。Enabling Team 不直接交付业务，只辅导其他团队
- "Team Topologies 是组织结构图" ——错。Team Topologies 是动态拓扑——团队类型和交互模式会演化
- "Conway 定律决定一切" ——错。Conway 定律是约束，Team Topologies 是工具——先设计团队拓扑，再让系统结构对齐（Inverse Conway）
关键洞察
Team Topologies = Conway 定律的工程化模板——4 种团队类型 + 3 种交互模式。不是组织结构图，是动态拓扑——团队类型和交互模式必须随业务演化。 控制论 Ch 21 多级分散控制 + SE@G Ch 3 团队 = 代码库 + IDDD Ch 3 BC 团队 owner——三源汇成 Team Topologies 的理论基础。 关键纪律：Stream-Aligned Team 端到端负责业务流 + Platform Team 提供自服务 XaaS + Enabling Team 跨团队辅导 + Complicated-Subsystem Team 维护专业子系统。 B7 演化在组织维度的具体实现：团队拓扑稳定了，业务演化才有组织基础。
相关链接
- Conway——Team Topologies 的理论基础
- Culture——Team Topologies 的文化维度
- Coordination——Team Topologies 的多级对位
- [V3 涌现之时] · 演化——Team Topologies 的演化视角
- [V3 涌现作为] · 分解——Team Topologies 的分解原则
- IDDD Ch 3 Context Map——BC 与 Stream-Aligned Team
- SE@G Ch 3 Programming over Time——团队 = 代码库
- 工程控制论 Ch 21 §21.3——多级分散控制