四种基本拓扑如何影响DevOps转换。
了解流对齐的团队的优势，以及他们如何与平台团队，子系统团队合作以及使团队能够为客户创造价值。
团队拓扑简介
工程团队需要比以往任何时候都更快地行动，以为其客户提供价值。云，SaaS和始终在线服务的兴起意味着客户期望新功能，更少的错误以及99.99％（或更高）的正常运行时间。
为了满足这些需求，组织采用了敏捷实践，最近又采用了DevOps实践，这有望缩短产品上市时间/交付周期，改善部署频率，改善团队文化，并增强团队/部门之间的协作。
尽管采用DevOps的做法说起来容易做起来难，但《团队拓扑》一书提供了组织可以在其公司中构建DevOps的有见地的方法，包括哪种团队可能最有效。本书为Atlassian如何思考团队提供了一个起点。我们不想重复他们的发现，而是要分享我们对团队类型的看法。
进行DevOps转换的第一步是确定适当的组织结构。但是，在当今任何给定的公司中，都有许多不同的团队类型，在某些情况下，单个团队承担着多种角色和职责。这种蔓延使领导层很难可视化整个组织环境，并难以回答以下问题：
- 我们有合适的团队吗？
- 我们是否在某些领域缺乏任何团队无法解决的能力？
- 团队在自治与其他团队的支持之间是否有必要的平衡？
通过团队拓扑的角度来看他们的组织，开发和运营主管可以更好地了解合适的团队是否成立。我们建议将团队变更的数量减少到四种基本的团队拓扑，这些拓扑对于高层管理人员和实际的团队成员本身都是易于理解的：
- 流团队
- 平台团队
- 复杂子系统团队
- 赋能团队
请记住，根据公司的规模和成熟程度，这些团队类型采用不同的形式。实际上，将一个以上类型的团队组合或将一个团队转换为另一种类型的团队通常是最好的方法。
流团队
与流程保持一致的团队专注于单一而有影响力的工作流程。它可以是单个产品或服务，单个功能集，单个用户旅程或单个用户角色。该团队有权尽快，安全和独立地建立和交付客户或用户价值，而无需交由其他团队来执行部分工作。
由于与流程保持一致的团队在整个交付范围内工作，因此，它们必须更接近客户，并且通常已经敏捷。该团队将客户反馈纳入开发周期，同时维护生产中的软件。
尽管按流对齐的团队在许多软件公司中很常见，但其他组织可能更熟悉按职能组织的团队结构（即，用于工程，设计，QA的独立团队），而不是交付流。
由于流对齐的团队是组织中最常见的团队类型，因此其他团队的角色是相对于流对齐的团队定义的。与流程保持一致的团队应定期与以下支持团队联系（复杂的子系统，功能和平台），以不断提高交付速度以及其产品和服务的质量。
平台团队
平台团队使与流程保持一致的团队能够以极大的自主权交付工作。流协作团队拥有在生产中构建，运行和修复应用程序的全部所有权，而平台团队则提供流协作团队可以使用的内部服务。
平台团队创建的功能可以由众多按流程排列的团队使用，而开销却很少。通过优化产品，平台团队可以最大程度地减少与流程保持一致的团队的资源和认知负担。这也使最终用户受益，因为平台团队可以创建跨越不同用户体验或产品的凝聚力体验。
复杂子系统团队
复杂的子系统团队负责构建和维护依赖于特定技能和知识的系统部分。大多数团队成员必须是特定知识领域的专家才能理解和更改子系统。
该团队的目标是减少在包含或使用子系统的系统上工作的流对齐团队的工作量。凭借复杂子系统团队的专业知识和能力，与流程保持一致的团队不必在过于复杂的区域中建立其日常工作能力。该团队的团队成员可能对某些微服务（即计费服务），算法甚至人工智能具有专门的知识。
一个常见的陷阱是在使用该子系统的每个与流程保持一致的团队中嵌入专家。尽管这看起来似乎很有效，但最终并没有达到成本效益，并且超出了按流程排列的团队的范围。
赋能团队
与团队保持一致的团队承受着不断施加压力，要求他们迅速交付并响应变化，这使得寻找时间来研究，学习和练习新技能变得充满挑战。
由给定技术（或产品）领域的专家组成的授权团队可帮助弥合这一能力差距。这些团队专注于研究和实验，以就影响工具堆栈的工具，框架和生态系统选择提出明智的建议。
这使与流程保持一致的团队有时间获取和发展功能，而又不会浪费时间来实现其主要目标。赋能团队力求主要通过提高针对问题而非解决方案的能力来增强与流程保持一致的团队的自治能力。
如果一个授权团队做好了工作，那么在几周左右的时间里，它所协助的团队就不再需要帮助。扶持团队永远不应致力于永久依赖。
您是一支精打细算的团队吗？
应该询问以下问题，以确定您是否有一支与团队保持一致的团队：
您的团队旨在产生稳定的功能流吗？
成熟的团队每周发布多次，有时甚至每天发布多次。为了实现此目标，成熟的团队应使用持续集成和持续交付（CI / CD）来频繁发布功能。
您的团队是否根据最新变化的反馈（客户或内部）迅速改变方向？
通常最好使用实验方法来进行产品开发。成熟的DevOps流程包括自动化测试，以确保交付高质量的代码。然而，实验超越了简单的单元测试或验收测试。您可以使用功能标记自动向部分用户推出产品，使用alpha和beta版本来征求和评估用户反馈和行为，以及通过评论，支持通知单，定性的定性连续反馈来确保产品为客户带来最大价值和社区论坛。
您的团队是否有将工作移交给其他团队的最小化？
这在两个方面都是正确的。您的团队应该是独立的，并且应该与直属团队进行合作以确保快速交付。除了工作范围之外，最少的交接也可以采用自动化流程的形式。使您的开发周期自动化可以确保顺畅地进行操作，而无论下一步是执行诸如自动测试或合并到母版，还是实际的人之类的操作。
奖励积分如果……。
您的团队是否有时间解决代码质量更改（又称“技术债务”），以确保更改安全且容易？
成熟的团队依靠基于主干的开发和CI / CD实践来维护其代码库。容量规划应包括专门时间来解决技术债务问题。另外，解决基础结构或平台问题的大型项目应与功能开发一样受到重视。
您的团队是否通过正确的指标进行了评估？
除了团队交付的速度有多快外，它还应该在成功衡量标准时考虑团队健康和技术质量指标。
关于围绕测量的最后一个问题，DevOps团队传统上在定义“成功”时考虑了四个关键的DevOps研究与评估（DORA）指标：
- 部署频率-组织成功发布到生产环境的频率
- 变更的前置时间-投入生产所需的时间
- 变更失败率-导致生产失败的部署百分比
- 恢复服务的时间-组织从生产故障中恢复需要多长时间
除了DORA规定的这些指标外，Atlassian还发现，高效，按流程调整的团队还监视以下属性：
- 团队平衡-您的团队具有多种技能和观点
- 全职所有者-全职所有者可确保核团队和跨职能参与者知道向谁提出问题以及如何做出与团队拥有的项目相关的决策
- 共同的理解-对需求有共同的理解，以及对成功的价值观和指标的定义
- 专注于价值和指标-您的团队具有北极星，可以指导要解决的任务，以便将项目发布
- 概念验证-拥有真实的工件来稀疏和测试假设，有助于团队不断迭代和改进
- 可管理的依赖关系可保持速度-了解可管理的依赖关系可阻止阻滞者并帮助团队保持速度
结论…
DevOps不是目标，而是不断改进工具，团队文化和实践的旅程。如果您不熟悉DevOps，请首先确定目标，为客户创造价值。随着您的成长，请为您的工具和流程添加自动化。最后，当您的团队成为高级从业者时，请结合可观察性以确保您正在监视，衡量和改进正确的事物。
