工程团队需要比以往任何时候都更快地为客户提供价值。云、SaaS 和永远在线服务的兴起意味着客户期望新功能、更少的错误和 99.99%（或更高）的正常运行时间。
为了跟上这些需求，组织采用了敏捷实践和最近的 DevOps 实践，这有望加快上市时间/交付周期、改进部署频率、更好的团队文化，并加强跨团队/部门的协作。
虽然采用 DevOps 实践说起来容易做起来难，但《团队拓扑》一书提供了组织可以将 DevOps 构建到他们公司中的有见地的方法，包括什么样的团队可能最有效。本书为 Atlassian 如何看待团队提供了一个起点。我们不想重申他们的发现，而是想分享我们自己对团队类型的看法。
DevOps 转型的第一步是确定适当的组织结构。然而，在当今任何一家公司，都有许多不同的团队类型，在某些情况下，单个团队承担多个角色和职责。这种蔓延使领导者难以想象整个组织的格局，并回答以下问题：
- 我们有合适的团队吗？
- 我们是否缺乏任何团队都没有解决的某些领域的能力？
- 团队在自治和其他团队的支持之间是否有必要的平衡？
开发和运营领导者可以通过团队拓扑的视角观察他们的组织，从而更好地了解是否有合适的团队。我们建议将团队变体的数量减少到四种基本的团队拓扑结构，这些拓扑结构对于高层管理人员和实际团队成员本身都很容易理解：
- 流对齐的团队
- 平台团队
- 复杂子系统团队
- 赋能团队
请记住，这些团队类型根据公司的规模和成熟度采用不同的形式。实际上，将不止一种类型的团队组合在一起，或者将一个团队转变为另一种类型，通常是最好的方法。
流对齐的团队
流对齐的团队专注于单一的、有影响力的工作流。它可以是单个产品或服务、一组功能、单个用户旅程或单个用户角色。该团队有权尽可能快速、安全和独立地构建和交付客户或用户价值，而无需将工作交给其他团队来执行部分工作。
因为流对齐的团队致力于全方位的交付，所以他们必然更接近客户并且通常已经很敏捷。该团队将客户反馈纳入开发周期，同时在生产中维护软件。
虽然流对齐的团队在许多软件公司中很常见，但其他组织可能更熟悉按功能组织的团队结构（即独立的工程、设计、QA 团队），而不是交付流。
由于流对齐团队是组织中最常见的团队类型，因此其他团队的角色是相对于流对齐团队定义的。流对齐团队应定期联系以下支持团队（复杂的子系统、支持和平台），以不断提高其产品和服务的交付速度和质量。
平台团队
平台团队使流对齐的团队能够以极大的自主权交付工作。虽然流对齐团队拥有在生产中构建、运行和修复应用程序的全部所有权，但平台团队提供流对齐团队可以使用的内部服务。
平台团队创建的功能可供众多流对齐的团队使用，而且开销很小。通过优化产品，平台团队最大限度地减少了流对齐团队的资源和认知负载。这也有利于最终用户，因为平台团队可以创建跨越不同用户体验或产品的有凝聚力的体验。
在 Atlassian，平台团队构建我们所有产品（如身份管理）使用的服务，并有望为流对齐团队提供文档、支持和咨询。
复杂子系统团队
一个复杂的子系统团队负责构建和维护依赖于特定技能和知识的系统部分。大多数团队成员必须是特定知识领域的专家才能理解子系统并对其进行更改。
该团队的目标是减少在包含或使用子系统的系统上工作的流对齐团队的负载。凭借复杂子系统团队的专业知识和能力，流对齐团队不必在日常工作中过于复杂的领域构建能力。该团队的团队成员可能具有某些微服务（即计费服务）、算法甚至人工智能方面的专业知识。
一个常见的陷阱是在每个使用子系统的流对齐团队中嵌入专家。虽然这看起来很有效，但它最终不符合成本效益，并且超出了流对齐团队的范围。
赋能团队
流对齐的团队一直承受着快速交付和响应变化的压力，这使得寻找时间研究、学习和练习新技能变得具有挑战性。
由特定技术（或产品）领域的专家组成的支持团队有助于弥合这种能力差距。这些团队专注于研究和实验，以就影响工具堆栈的工具、框架和生态系统选择提出明智的建议。
这让流对齐的团队有时间获取和发展能力，而不会从他们的主要目标上花时间。赋能团队主要通过关注问题而不是解决方案来提高他们的能力，从而主要增加流对齐团队的自主权。
如果一个支持团队的工作做得很好，它所协助的团队在几周左右后就不再需要帮助了。支持团队永远不应该处理永久依赖项。
注：当心团队拓扑变为 SAFe