Team Topologies

1. Conway定律通过团队结构影响软件架构

如果系统的架构和组织的架构不一致，组织的架构将占上风。

沟通结构很重要。 Conway定律揭示了一个组织的沟通结构直接影响其创建的系统设计。这一原则对软件架构和团队组织有深远的影响。通过将团队结构与期望的系统架构对齐，组织可以利用Conway定律为其带来优势。

反向Conway操作。 与其让团队结构决定系统设计，组织可以有意地塑造团队以产生期望的架构。这种方法被称为“反向Conway操作”，包括：

• 确定目标系统架构
• 设计与此架构相匹配的团队结构
• 让Conway定律的自然力量引导开发

战略性团队设计。 通过有意识地设计团队结构，组织可以：

• 鼓励模块化、松耦合的系统
• 促进组件之间的清晰接口
• 提高系统的可维护性和可扩展性

2. 以团队为中心的方法优化认知负荷和流动性

减少团队的认知负荷并促进团队互动有助于优化流动性。

认知负荷很重要。 以团队为中心的方法认识到团队能够有效管理的复杂性是有限的。通过优先考虑团队的认知能力，组织可以：

• 提高生产力和创新能力
• 减少压力和倦怠
• 改善代码质量和系统可靠性

管理认知负荷的策略：

• 限制团队职责以匹配其认知能力
• 将大型系统分解为适合团队规模的组件
• 提供清晰、明确的团队间接口
• 投资于简化复杂任务的工具和平台

优化流动性。 通过减少不必要的认知负担，团队可以达到一种流动状态，其特点是：

• 高生产力和创造力
• 增加工作满意度
• 更快的问题解决和创新

3. 四种基本团队拓扑推动有效的软件交付

四种基本的团队拓扑是：流线型、支持型、复杂子系统型和平台型。

流线型团队构成了组织的骨干，直接为用户或客户提供价值。它们是：

• 跨职能的
• 与特定产品、服务或用户旅程对齐
• 有权提供端到端的价值

支持型团队通过以下方式支持和加速流线型团队：

• 提供专业知识
• 进行研究和原型设计
• 促进知识转移

复杂子系统团队管理需要深厚专业知识的复杂组件，使流线型团队能够专注于提供价值。

平台团队提供内部服务和工具，使流线型团队能够更高效和自主地工作。

通过采用这四种团队类型，组织可以：

• 明确团队职责和互动
• 减少依赖和瓶颈
• 提高整体交付速度和质量

4. 明确的团队互动模式增强协作和生产力

将团队互动限制在三种模式——协作、X即服务和促进——简化并明确了构建软件系统的团队之间的基本互动。

协作模式涉及密切的团队合作以进行发现和创新。它最适用于：

• 新系统开发的早期阶段
• 解决复杂的跨领域问题
• 当快速学习和适应至关重要时

X即服务模式在团队之间建立明确的提供者-消费者关系。它最适用于：

• 稳定、明确的服务或组件
• 最大化团队自主性
• 实现可预测、可扩展的互动

促进模式涉及一个团队帮助另一个团队开发新能力。它适用于：

• 知识转移和技能发展
• 过渡期间的临时支持
• 解决跨团队挑战

通过明确定义这些互动模式，组织可以：

• 减少团队关系中的模糊性
• 提高专注力和生产力
• 促进更顺畅的跨团队协作

5. 将软件边界与团队认知能力对齐

选择与团队认知负荷相匹配的软件边界。

团队规模的架构。 将软件边界与团队认知能力对齐，确保团队能够有效地拥有和发展其系统部分。这种方法导致：

• 增加所有权和责任感
• 更快的开发和问题解决
• 改善系统的可维护性

定义边界的策略：

• 使用领域驱动设计识别自然的系统边界
• 在定义组件范围时考虑团队规模和专业知识
• 利用微服务架构创建可管理的、适合团队规模的服务

适当边界对齐的好处：

• 减少团队的认知过载
• 更清晰的团队职责和接口
• 提高系统随时间演变和扩展的能力

6. 平台应“刚好足够大”以支持流线型团队

一个好的平台为开发团队提供标准、模板、API和经过验证的最佳实践，以便快速有效地进行创新。

最薄可行平台（TVP）。 理想的平台提供足够的支持以加速流线型团队，而不过于复杂或限制性。一个好的TVP的特点包括：

• 清晰、文档齐全的API
• 自助服务能力
• 抽象常见的复杂任务

平台演进。 随着组织的成长和技术的变化，平台应演变以：

• 满足流线型团队的新需求
• 结合新技术和最佳实践
• 简化或移除未充分利用的功能

设计良好的平台的好处：

• 减少流线型团队的认知负荷
• 更快的市场响应时间
• 提高系统的一致性和可靠性

7. 不断演变团队结构以适应变化的需求

不同的拓扑和不同的团队互动需要在不同时间根据他们的工作和目标进行演变。

组织感知。 持续监控和评估团队的有效性和互动，以识别改进机会。关键指标包括：

• 交付速度和质量
• 团队满意度和参与度
• 跨团队协作的有效性

适应性团队结构。 准备好根据需求变化调整团队拓扑和互动模式。这可能包括：

• 拆分或合并团队
• 在协作和X即服务模式之间转换
• 创建或解散支持型团队

持续演变的好处：

• 提高对市场和技术变化的响应能力
• 增强团队的有效性和满意度
• 优化组织结构以实现当前目标和挑战

8. 将运营视为开发的高保真感官输入

将运营视为开发的输入需要对这些通常分离的群体角色进行根本性重新思考。

DevOps集成。 模糊开发和运营之间的界限，创建一个反馈回路，以提高整体系统质量和可靠性。这种方法包括：

• 共同负责系统性能
• 从生产到开发的持续反馈
• 跨传统边界的协作问题解决

运营作为输入的好处：

• 更快地识别和解决问题
• 提高系统的可靠性和性能
• 增强开发和运营团队之间的同理心

实施策略：

• 实施健全的监控和警报系统
• 建立具有开发和运营专业知识的跨职能团队
• 创建基于运营见解的快速反馈和迭代流程

9. 设计团队规模的软件架构以增强所有权

一个处理认知负荷过高的软件系统的团队无法有效地拥有或安全地发展软件。

团队规模的组件。 将大型系统分解为可管理的、适合团队规模的组件，以符合团队的认知能力。这种方法：

• 增强团队的所有权和责任感
• 促进更快的开发和问题解决
• 改善整体系统的可维护性

实施策略：

• 使用领域驱动设计识别自然的系统边界
• 利用微服务架构创建可管理的服务
• 将团队职责与明确的系统组件对齐

团队规模架构的好处：

• 减少团队的认知过载
• 更清晰的团队职责和接口
• 提高系统随时间演变和扩展的能力
• 增强团队的满意度和参与度

最后更新日期: August 7, 2024