⚡

团队拓扑设计Skill team-topology-design

团队拓扑设计是一种组织设计方法论，用于优化团队结构以支持快速变更流，同时管理认知负荷。它涵盖四种基本团队类型、三种交互模式、认知负荷评估、逆向康威操作和团队演化模式，适用于设计对齐软件架构的团队结构。关键词包括团队拓扑、流对齐团队、平台团队、使能团队、复杂子系统、交互模式、认知负荷、逆向康威、康威定律。

架构设计 0 次安装 0 次浏览 更新于 3/11/2026

name: 团队拓扑设计 description: “用于组织设计的团队拓扑方法论。涵盖四种基本团队类型、三种交互模式、认知负荷评估、逆向康威操作和团队演化模式。适用于设计对齐架构的团队结构。” allowed-tools: 读取, 写入, 全局搜索, 文本搜索, 任务

团队拓扑设计

一种现代团队组织方法，优化快速变更流，同时管理认知负荷。

何时使用此技能

关键词: 团队拓扑, 流对齐, 平台, 使能, 复杂子系统, 交互模式, 协作, X即服务, 促进, 认知负荷, 逆向康威, 康威定律, 团队API, 团队边界, 快速流

在以下情况使用此技能:

  • 设计或重组团队结构
  • 对齐团队与软件架构
  • 减少团队的认知负荷
  • 改进变更交付流
  • 应用逆向康威操作
  • 定义团队交互和边界
  • 规划组织演化

康威定律

“任何设计系统的组织都将产生一个设计，其结构是该组织通信结构的副本。” — Melvin Conway, 1968

影响

康威定律:
  观察: "架构反映通信结构"

  影响:
    - "团队结构塑造系统架构"
    - "孤岛团队创建孤岛系统"
    - "跨职能团队创建集成系统"
    - "团队边界成为系统边界"

  逆向康威:
    原则: "设计组织以匹配期望的架构"
    方法: "如果您想要某种系统架构，就相应地构建团队"
    警告: "架构和团队结构会随时间重新对齐"

四种团队类型

1. 流对齐团队

流对齐团队:
  定义: "团队对齐于一个有价值的工流"

  特征:
    - "对价值流的端到端责任"
    - "跨职能（开发、运维、测试、用户体验等）"
    - "长期存在，产品导向"
    - "拥有一个或多个有限上下文"
    - "主要团队类型（多数团队）"

  规模: "5-9名成员"

  示例:
    - "客户入职团队"
    - "结账体验团队"
    - "移动应用团队"
    - "B2B集成团队"

  拥有:
    - "面向客户的功能"
    - "特定用户旅程"
    - "有限上下文"
    - "完整软件生命周期"

  不拥有:
    - "共享基础设施"
    - "复杂专业组件"
    - "跨领域能力"

  成功指标:
    - "变更前置时间"
    - "部署频率"
    - "客户满意度"
    - "服务恢复时间"

2. 平台团队

平台团队:
  定义: "团队提供内部服务以减少流对齐团队的认知负荷"

  特征:
    - "将内部团队视为客户"
    - "提供自服务能力"
    - "关注开发者体验"
    - "作为内部产品团队运营"
    - "减少团队间重复"

  规模: "5-9名成员（可随平台规模扩展）"

  示例:
    - "开发者平台团队"
    - "基础设施团队"
    - "数据平台团队"
    - "机器学习平台团队"

  提供:
    - "自服务基础设施"
    - "CI/CD流水线"
    - "监控和可观察性"
    - "通用库和框架"

  不做:
    - "为最终用户构建功能"
    - "规定团队工作方式"
    - "创建瓶颈"

  成功指标:
    - "资源供应时间"
    - "平台采用率"
    - "开发者满意度得分"
    - "支持票减少"

3. 使能团队

使能团队:
  定义: "团队帮助流对齐团队采用新能力"

  特征:
    - "与其他团队的临时合作"
    - "提升技能而非构建"
    - "识别模式和最佳实践"
    - "交叉传播知识"
    - "与每个团队有限的生命周期"

  规模: "3-6名成员（小型、专业化）"

  示例:
    - "DevOps使能团队"
    - "安全倡导团队"
    - "架构指导团队"
    - "敏捷教练团队"

  活动:
    - "培训和研讨会"
    - "结对编程/群体会话"
    - "创建指南和操作手册"
    - "识别障碍"

  不做:
    - "构建生产系统"
    - "永久嵌入"
    - "把关"

  合作模式:
    初始: "评估团队需求"
    活跃: "紧密合作（数周）"
    移交: "使团队自给自足"
    跟进: "定期检查"

  成功指标:
    - "能力采用率"
    - "团队独立时间"
    - "实践在组织内传播"

4. 复杂子系统团队

复杂子系统团队:
  定义: "团队负责需要深度专业知识的组件"

  特征:
    - "需要重专业专长"
    - "复杂性会压倒流团队"
    - "与其他团队的清晰接口"
    - "稀有团队类型（多数组织有0-2个）"

  规模: "3-9名成员（专业导向）"

  示例:
    - "视频编码团队"
    - "金融建模团队"
    - "机器学习算法团队"
    - "实时数据处理团队"

  何时适用:
    - "数学/科学密集型组件"
    - "监管复杂性"
    - "深度领域专长"
    - "需要多年专业学习"

  何时不适用:
    - "任何团队都能学习的通用复杂性"
    - "应成为平台的组件"
    - "历史知识囤积"

  成功指标:
    - "接口稳定性"
    - "子系统的准确性/性能"
    - "消费者的支持负担"

三种交互模式

协作

协作模式:
  定义: "两个团队紧密合作以实现共享目标"

  特征:
    - "高带宽通信"
    - "共享发现和创新"
    - "临时边界模糊"
    - "密集但时间限制"

  适用情况:
    - "快速发现阶段"
    - "新集成"
    - "新颖问题"
    - "建立共享理解"

  持续时间: "时间限制（数周至数月）"

  警告信号:
    - "协作持续超过6个月"
    - "永久依赖"
    - "团队无法独立工作"

  过渡至: "发现后转为X即服务"

X即服务

X即服务模式:
  定义: "一个团队向另一个团队提供具有清晰接口的服务"

  特征:
    - "清晰的API/合约"
    - "最小化协调需求"
    - "提供团队拥有服务演化"
    - "消费团队无需深度参与"

  适用情况:
    - "成熟、稳定的接口"
    - "平台到流对齐"
    - "减少认知负荷"
    - "扩展交互"

  成功因素:
    - "良好文档化的API"
    - "自服务供应"
    - "SLA协议"
    - "清晰的支持渠道"

  反模式:
    - "简单请求过多会议"
    - "所有事情都需要票队列"
    - "隐藏复杂性"

促进

促进模式:
  定义: "一个团队帮助另一个团队学习或采用能力"

  特征:
    - "教学而非执行"
    - "临时，有移交"
    - "目标是独立性"
    - "使能团队主要模式"

  适用情况:
    - "能力建设"
    - "新实践采用"
    - "障碍移除"
    - "交叉传播"

  合作周期:
    评估: "理解团队需求"
    教学: "主动指导/培训"
    支持: "可用解答问题"
    退出: "团队自给自足"

  反模式:
    - "永久依赖"
    - "为他们做工作"
    - "把关知识"

认知负荷

认知负荷类型

认知负荷类型:
  内在:
    定义: "来自问题空间本身的负荷"
    示例:
      - "业务领域复杂性"
      - "任务的技术复杂性"
      - "监管要求"
    策略: "无法消除，但可训练应对"

  外在:
    定义: "来自环境/过程的负荷"
    示例:
      - "遗留系统怪癖"
      - "差工具"
      - "不明确需求"
    策略: "通过平台、自动化最小化"

  相关:
    定义: "来自学习和成长的负荷"
    示例:
      - "学习新技术"
      - "探索新领域"
      - "构建心理模型"
    策略: "投资于此——构建能力"

认知负荷评估

认知负荷评估:
  问题:
    领域复杂性:
      - "团队拥有多少领域？"
      - "所需领域知识的深度如何？"
      - "领域规则变更频率如何？"

    技术复杂性:
      - "团队维护多少系统？"
      - "技术多样性如何？"
      - "存在多少遗留代码？"

    环境摩擦:
      - "多少时间花在非价值工作上？"
      - "需要与多少其他团队协调？"
      - "部署过程有多痛苦？"

  评分:
    1_3: "可管理——团队可专注价值"
    4_6: "升高——一些开销影响流"
    7_9: "过载——需要减少范围"
    10: "关键——团队无法有效运行"

  红旗:
    - "团队拥有超过3个有限上下文"
    - "超过50%时间花在协调上"
    - "上下文切换导致高缺陷率"
    - "倦怠指标"

团队规模启发式

团队规模:
  邓巴数:
    5: "核心工作组"
    15: "扩展团队带协调"
    50: "部门边界"
    150: "组织边界"

  两披萨规则:
    描述: "团队应由两披萨喂养"
    实际规模: "5-9名成员"
    理由: "通信开销呈指数增长"

  布鲁克斯定律:
    陈述: "向延迟项目添加人员使其更延迟"
    影响: "团队应从开始就正确规模"

逆向康威操作

原则

逆向康威:
  定义: "设计组织以实现期望架构"

  过程:
    1: "定义期望目标架构"
    2: "识别有限上下文及其关系"
    3: "设计团队结构以反映期望架构"
    4: "允许团队演化其拥有的架构"

  示例:
    期望架构: "具有清晰边界的独立微服务"
    团队设计: "流对齐团队各拥有1-2个服务"
    平台: "共享基础设施作为平台团队"
    结果: "架构自然演化以匹配团队结构"

实施步骤

逆向康威实施:
  步骤1_架构愿景:
    活动:
      - "定义目标有限上下文"
      - "映射上下文间集成模式"
      - "识别共享能力（平台）"
      - "文档化接口和依赖"
    输出: "带边界的目標架構圖"

  步骤2_团队映射:
    活动:
      - "映射有限上下文到潜在团队"
      - "识别平台团队需求"
      - "评估使能团队要求"
      - "标记复杂子系统候选"
    输出: "初始团队结构提案"

  步骤3_认知负荷验证:
    活动:
      - "评估每个提议团队的负荷"
      - "如过载则调整范围"
      - "验证技能可用性"
      - "计划使能支持"
    输出: "验证团队结构"

  步骤4_交互设计:
    活动:
      - "定义初始交互模式"
      - "识别协作需求"
      - "设计平台接口"
      - "计划团队API"
    输出: "团队交互图"

  步骤5_演化计划:
    活动:
      - "定义过渡时间线"
      - "计划技能发展"
      - "设计反馈机制"
      - "建立审查节奏"
    输出: "组织过渡路线图"

团队API

定义

团队API:
  定义: "团队如何与其他团队交互的显式接口"

  组件:
    服务提供:
      - "团队提供什么"
      - "如何消费服务"
      - "SLA和承诺"

    通信:
      - "主要联系渠道"
      - "响应时间期望"
      - "升级路径"

    工作方式:
      - "协作偏好"
      - "会议可用性"
      - "决策过程"

    代码和制品:
      - "仓库位置"
      - "文档"
      - "API规范"

  好处:
    - "减少模糊性"
    - "扩展交互"
    - "支持异步工作"
    - "支持团队自治"

团队API模板

# 团队API: {团队名称}

## 使命
{团队目的的1-2句话}

## 我们提供的服务
| 服务 | 描述 | 如何请求 | SLA |
|------|------|----------|-----|
| {服务} | {做什么} | {渠道} | {响应时间} |

## 我们拥有什么
- {有限上下文}
- {系统/仓库}
- {文档位置}

## 交互偏好
- **首选联系:** {Slack频道、电子邮件等}
- **办公时间:** {何时可用于同步讨论}
- **请求过程:** {如何提出请求}

## 当前交互模式
| 团队 | 模式 | 持续时间 | 备注 |
|------|------|----------|------|
| {团队} | {协作/X即服务/促进} | {时间框架} | {上下文} |

## 依赖
### 我们依赖
- {团队/服务}: {我们需要什么}

### 谁依赖我们
- {团队}: {他们从我们这里需要什么}

## 我们跟踪的指标
- {指标1}
- {指标2}

## 反馈渠道
- {如何提供反馈}

团队演化模式

演化触发

演化触发:
  增长负荷:
    信号: "团队认知负荷增加"
    选项:
      - "沿有限上下文拆分团队"
      - "为共享关注创建平台团队"
      - "剥离复杂子系统"

  成熟协作:
    信号: "协作模式持续太久"
    行动: "过渡到X即服务"

  重复使能:
    信号: "多团队需要相同能力"
    行动: "移至平台团队"

  专家瓶颈:
    信号: "专家知识创建瓶颈"
    选项:
      - "创建复杂子系统团队"
      - "使团队构建能力"

拆分团队

团队拆分:
  何时拆分:
    - "团队拥有太多有限上下文（>3）"
    - "认知负荷持续高"
    - "团队规模超过9"
    - "存在清晰领域边界"

  如何拆分:
    识别边界: "找到领域/代码中的自然接缝"
    确保可行性: "每个新团队必须独立可行"
    计划过渡: "逐步移交，非大爆炸"
    维护接口: "与旧团队保持X即服务"

  反模式:
    - "按技术层拆分（UI团队、API团队）"
    - "拆分无清晰所有权"
    - "创建太多小团队"

团队合并

团队合并:
  何时合并:
    - "协作开销太多"
    - "团队太小无效"
    - "有限上下文密切相关"
    - "人工边界导致摩擦"

  如何合并:
    评估合适: "合并负荷可管理吗？"
    计划集成: "技能如何结合？"
    重新定义范围: "新团队的有限上下文"
    更新交互: "修订团队API"

.NET/C# 上下文

团队到架构对齐

namespace Organization.TeamDesign;

// 团队拓扑设计模型
public record Team
{
    public required string Name { get; init; }
    public required TeamType Type { get; init; }
    public required string Mission { get; init; }
    public required int Size { get; init; }
    public List<string> BoundedContexts { get; init; } = [];
    public CognitiveLoadAssessment? CognitiveLoad { get; init; }
    public TeamApi? Api { get; init; }
}

public enum TeamType
{
    StreamAligned,
    Platform,
    Enabling,
    ComplicatedSubsystem
}

public record TeamInteraction
{
    public required string FromTeam { get; init; }
    public required string ToTeam { get; init; }
    public required InteractionMode Mode { get; init; }
    public string? Purpose { get; init; }
    public DateOnly? StartDate { get; init; }
    public DateOnly? PlannedEndDate { get; init; }
}

public enum InteractionMode
{
    Collaboration,
    XAsAService,
    Facilitating
}

public record CognitiveLoadAssessment
{
    public required DateOnly AssessmentDate { get; init; }
    public required int DomainComplexityScore { get; init; } // 1-10
    public required int TechnicalComplexityScore { get; init; } // 1-10
    public required int EnvironmentalFrictionScore { get; init; } // 1-10
    public int TotalScore => DomainComplexityScore +
                             TechnicalComplexityScore +
                             EnvironmentalFrictionScore;
    public LoadLevel Level => TotalScore switch
    {
        <= 9 => LoadLevel.Manageable,
        <= 18 => LoadLevel.Elevated,
        <= 24 => LoadLevel.High,
        _ => LoadLevel.Critical
    };
    public string? Notes { get; init; }
    public List<string> Recommendations { get; init; } = [];
}

public enum LoadLevel
{
    Manageable,
    Elevated,
    High,
    Critical
}

public record TeamApi
{
    public required string TeamName { get; init; }
    public required string Mission { get; init; }
    public List<ServiceOffering> Services { get; init; } = [];
    public CommunicationPreferences? Communication { get; init; }
    public List<string> OwnedSystems { get; init; } = [];
    public List<Dependency> DependsOn { get; init; } = [];
    public List<Dependency> DependedOnBy { get; init; } = [];
}

public record ServiceOffering(
    string Name,
    string Description,
    string RequestChannel,
    string Sla
);

public record CommunicationPreferences(
    string PreferredChannel,
    string OfficeHours,
    string RequestProcess
);

public record Dependency(
    string TeamName,
    string Description
);

团队拓扑分析器

public class TeamTopologyAnalyzer
{
    public TeamTopologyAssessment Analyze(IEnumerable<Team> teams, IEnumerable<TeamInteraction> interactions)
    {
        var teamList = teams.ToList();
        var interactionList = interactions.ToList();

        return new TeamTopologyAssessment
        {
            TotalTeams = teamList.Count,
            TeamsByType = teamList.GroupBy(t => t.Type)
                .ToDictionary(g => g.Key, g => g.Count()),
            StreamAlignedRatio = CalculateStreamAlignedRatio(teamList),
            CognitiveLoadWarnings = IdentifyCognitiveLoadWarnings(teamList),
            InteractionConcerns = IdentifyInteractionConcerns(interactionList),
            Recommendations = GenerateRecommendations(teamList, interactionList)
        };
    }

    private decimal CalculateStreamAlignedRatio(List<Team> teams)
    {
        if (teams.Count == 0) return 0;
        var streamAligned = teams.Count(t => t.Type == TeamType.StreamAligned);
        return (decimal)streamAligned / teams.Count;
    }

    private List<string> IdentifyCognitiveLoadWarnings(List<Team> teams)
    {
        var warnings = new List<string>();

        foreach (var team in teams)
        {
            if (team.CognitiveLoad?.Level >= LoadLevel.High)
            {
                warnings.Add($"团队 '{team.Name}' 具有 {team.CognitiveLoad.Level} 认知负荷");
            }

            if (team.BoundedContexts.Count > 3)
            {
                warnings.Add($"团队 '{team.Name}' 拥有 {team.BoundedContexts.Count} 个有限上下文（推荐最大：3）");
            }

            if (team.Size > 9)
            {
                warnings.Add($"团队 '{team.Name}' 有 {team.Size} 名成员（超过两披萨规模）");
            }
        }

        return warnings;
    }

    private List<string> IdentifyInteractionConcerns(List<TeamInteraction> interactions)
    {
        var concerns = new List<string>();

        // 检查长期运行协作
        var longCollaborations = interactions
            .Where(i => i.Mode == InteractionMode.Collaboration)
            .Where(i => i.StartDate.HasValue &&
                        i.StartDate.Value.AddMonths(6) < DateOnly.FromDateTime(DateTime.Today));

        foreach (var collab in longCollaborations)
        {
            concerns.Add($"'{collab.FromTeam}' 和 '{collab.ToTeam}' 之间的协作可能持续太久——考虑过渡到X即服务");
        }

        return concerns;
    }

    private List<string> GenerateRecommendations(List<Team> teams, List<TeamInteraction> interactions)
    {
        var recommendations = new List<string>();

        // 检查流对齐比率
        var ratio = CalculateStreamAlignedRatio(teams);
        if (ratio < 0.6m)
        {
            recommendations.Add("考虑增加流对齐团队比率（当前 " +
                              $"{ratio:P0}，推荐60-80%）");
        }

        // 检查缺失平台团队
        var hasInfraOverhead = teams
            .Where(t => t.Type == TeamType.StreamAligned)
            .Any(t => t.CognitiveLoad?.EnvironmentalFrictionScore > 5);

        if (hasInfraOverhead && !teams.Any(t => t.Type == TeamType.Platform))
        {
            recommendations.Add("考虑创建平台团队以减少流对齐团队的基础设施认知负荷");
        }

        return recommendations;
    }
}

public record TeamTopologyAssessment
{
    public int TotalTeams { get; init; }
    public Dictionary<TeamType, int> TeamsByType { get; init; } = new();
    public decimal StreamAlignedRatio { get; init; }
    public List<string> CognitiveLoadWarnings { get; init; } = [];
    public List<string> InteractionConcerns { get; init; } = [];
    public List<string> Recommendations { get; init; } = [];
}

输出格式

团队拓扑文档

团队拓扑:
  元数据:
    组织: "{组织名称}"
    日期: "{ISO-8601}"
    版本: "1.0"

  团队:
    流对齐团队:
      - 名称: "{团队名称}"
        使命: "{使命}"
        有限上下文:
          - "{上下文1}"
        规模: {N}
        认知负荷: "{可管理/升高/高}"

    平台团队:
      - 名称: "{平台团队}"
        使命: "{使命}"
        服务:
          - "{服务1}"
        规模: {N}

    使能团队:
      - 名称: "{使能团队}"
        焦点: "{当前焦点领域}"
        合作中:
          - "{团队1}"
        规模: {N}

    复杂子系统团队:
      - 名称: "{子系统团队}"
        领域: "{专业领域}"
        接口至:
          - "{消费团队1}"
        规模: {N}

  交互:
    - 从: "{团队A}"
      至: "{团队B}"
      模式: "{协作/X即服务/促进}"
      目的: "{为何此交互}"
      状态: "{活跃/计划中/结束中}"

  演化计划:
    - 触发: "{什么触发变更}"
      行动: "{将变更什么}"
      时间线: "{何时}"

与其他技能集成

上游

  • 上下文映射 - 有限上下文 → 团队映射
  • 沃德利映射 - 演化阶段 → 团队类型对齐
  • TOGAF指导 - 企业架构上下文

下游

  • 模块化架构 - 代码组织匹配团队
  • 适应度函数 - 团队边界执行
  • ADR管理 - 文档化团队结构决策

参考资料

如需额外指导：

版本历史

  • v1.0.0 (2025-12-26): 初始发布 - 团队拓扑设计技能

最后更新: 2025-12-26