了解流对齐团队的优势，以及他们如何与平台团队、子系统团队合作，以及如何使团队能够为客户创造价值。
团队拓扑简介
工程团队需要比以往更快地行动起来，为客户创造价值。云、SaaS 和始终在线的服务的兴起意味着客户期望获得新功能、更少的缺陷以及 99.99％（或更高）的正常运行时间。
为了跟上这些需求的步伐，组织采用了敏捷开发实践，最近还采用了 DevOps 实践，这有助于缩短上市时间/提前期、改善部署频率、改善团队文化并增强团队/部门之间的协作。
虽然采用 DevOps 实践说起来容易做起来难，但《团队拓扑》一书提供了组织将 DevOps 构建到公司中的各种高见，包括哪种类型的团队可能最有效。该书为 Atlassian 如何看待团队提供了一个起点。我们不想重述他们的发现，而是想分享我们对团队类型的看法。
实现 DevOps 转型的第一步是确定现有的组织结构。但是，在当今任何一家公司，都有许多不同的团队类型。在某些情况下，单个团队承担着多种角色和职责。这种杂乱无章使得领导层很难看清整个组织格局，也难以回答类似以下问题的疑问：
我们是否有合适的团队？
我们是否在某些没有任何团队处理的领域缺乏能力？
团队在自主权和其他团队的支持之间是否已实现必要的平衡？
开发和运营主管可以通过团队拓扑的视角审视他们的组织，从而更好地了解是否已有合适的团队。我们建议将团队变化的数量减少到四大基本团队拓扑，这些拓扑对于高层管理层和实际团队成员自己来说都很容易理解：
流对齐团队
平台团队
复杂子系统团队
助力团队
请注意，这些团队类型会根据公司的规模和成熟度采取不同的形式。实际上，组合多种类型的团队，或者将一个团队转变为另一个团队，通常是最好的方法。
1. 流对齐团队
流对齐团队专注于单一、有影响力的工作流。它可以是单个产品或服务、单个功能集、单个用户过程或单个用户角色。该团队有能力尽可能快速、安全和独立地为客户或用户创造和交付价值，而无需将部分工作交给其他团队来完成。
由于流对齐团队的工作涉及全方位交付，因此他们必须更接近客户，而且通常已经实现敏捷。该团队会将客户反馈纳入开发周期，同时维护生产环节的软件。
虽然流对齐团队在很多软件公司中十分常见，但其他组织可能更熟悉按职能组织的团队结构（即独立的工程、设计、QA 团队），而不是交付流。
由于流对齐团队是组织中最常见的团队类型，因此其他团队的角色均是相对于流对齐团队来定义的。流对齐团队应定期联系以下支持团队（复杂子系统、助力和平台团队），以不断提高产品和服务的交付速度和质量。
2. 平台团队
平台团队使流对齐团队能够高度自主地交付工作。虽然流对齐团队仍对生产环节的构建、运行和修复应用具有完全所有权，但平台团队会提供流对齐团队可以使用的内部服务。
平台团队负责创建可供众多流对齐团队使用的功能，而且开销很小。通过优化产品，平台团队可以最大限度地减少流对齐团队的资源和认知负担。这也使最终用户受益，因为平台团队可以创建跨越不同用户体验或产品的一致体验。
在 Atlassian，平台团队负责构建我们所有产品（例如身份管理）使用的服务，并为流对齐团队提供相关文档、支持和咨询。
3. 复杂子系统团队
复杂子系统团队会根据特定技能和知识负责构建和维护系统的一部分。大多数团队成员必须是特定知识领域的专家才能理解和更改子系统。
该团队的目标是为那些在包含或使用子系统的系统中工作的流对齐团队减少负担。借助复杂子系统团队的专业知识和能力，流对齐团队不必在对于其日常工作来说过于复杂的领域培养能力。该团队的团队成员可能具有某些微服务（例如开票服务）、算法甚至人工智能方面的专业知识。
一个易犯的错误是在每个使用子系统的流对齐团队中安插专家。虽然这可能看起来很有效，但最终并不具有成本效益，而且也超出了流对齐团队范围。
4. 助力团队
流对齐团队不断承受着快速交付和响应更改的压力，因此很难有时间研究、学习和磨炼新技能。
由既定技术（或产品）领域的专家组成的助力团队可帮助弥合这一能力差距。这些团队专注于研究和实验，就影响工具堆栈的工具、框架和生态系统选择提出明智的建议。
此举可让流对齐团队有时间获取能力并就此提升，而无需将时间浪费在偏离其主要目标的事务上。助力团队主要致力于通过专注于问题而非解决方案来提升流对齐团队的能力，从而提高其自主性。
如果助力团队的工作完成出色，那么它所协助的团队应在大约几周后便不再需要其帮助。助力团队不必处理长久依赖性。
您的团队属于流对齐团队吗？
应询问以下问题，以确定您是否有一个流对齐团队：
您的团队是否致力于生成稳定的功能流？
成熟的团队每周发布多次，而某些情况下，还会每天发布多次。为了实现这一目标，成熟的团队应当使用持续集成和持续交付 (CI/CD) 来频繁发布功能。
您的团队是否会根据最新变更所产生的反馈（客户反馈或内部反馈）快速调整方向？
通常，最好能使用实验性方法进行产品演进。成熟的 DevOps 流程会包括自动化测试，从而确保高质量的代码交付。然而，实验不只是简单的单元测试或验收测试。您可以通过使用功能标记自动向部分用户推出 Alpha 和 Beta 版本，寻求和衡量用户反馈和行为，以及通过评论、支持工作单提供的定性连续反馈和社区论坛等方式，确保您的产品为客户创造最大价值。
您的团队是否将工作交接给其他团队的次数控制在最低水平？
这一点应体现在两个方面。您的团队应该具备自主运作能力，工作应该与直接的团队伙伴协作推进，以确保快速交付。超出工作范围之外，最少的交接还可以采取自动化流程的形式。实现开发周期的自动化，可确保推进过程无缝衔接，无论下一步是自动化测试、合并到主分支等操作，还是实际的人工操作。
加分条件……
您的团队是否有时间处理代码质量变更（又称“技术债务”），以确保变更安全、简单？
您的团队是否使用正确的指标进行评估？
除了关注团队的交付速度之外，衡量成功时还应纳入团队健康度与技术质量指标。
对于衡量的最后一个问题，DevOps 团队在定义“成功”时历来会考虑四大 DevOps 研究与评估 (DORA) 指标：
部署频率 — 组织成功发布到生产环节的频率
更改的提前期 — 将提交投入生产所需的时间
更改失败率 — 在生产环节导致失败的部署占比
恢复服务的时间 — 组织从生产故障中恢复所需的时长
除了 DORA 指定的这些指标之外，Atlassian 还发现高效能的流对齐团队还会监控以下属性：
平衡的团队 — 您的团队拥有各种各样的技能和观点
全职负责人 — 全职负责人可确保核心小组和跨职能参与者知道向谁提问，以及如何做出与团队负责的项目相关的决策
共识 — 就相关要求以及成功的价值和指标的定义达成共识
专注于价值和指标 — 您的团队拥有可指导要完成哪些任务的参考标准，从而推动项目发布
概念验证 — 拥有真正的工件来探讨和测试各种假设将有助于团队不断迭代和改进
了解所管理的依赖关系以保持速度 — 了解所管理的依赖关系可以阻止障碍，并帮助团队保持速度
总之...
DevOps 不是目标，而是不断改进工具、团队文化和实践的过程。如果您不熟悉 DevOps，请首先将目标定为：为客户创造价值。熟练后，将自动化注入到工具和流程中。最后，当您的团队成为高级从业人员时，还应纳入可观察性，以确保您对适当的事项进行监控、衡量和改进。
如果您刚刚开始 DevOps 之旅，请阅读我们的 DevOps 初学者指南，了解最佳实践。要将 DevOps 付诸实践，我们建议尝试 Open DevOps，它提供了团队开发和运营软件所需的一切。借助与领先供应商和市场应用的集成，团队可以构建他们想要的 DevOps 工具链。立即试用。