反模式
两种特别有代表性的反模式：
- “临时起意”的团队设计：需要考虑交流成本；
- “频繁调动”团队成员：团队仅仅为了项目而组建，但是在项目完成之后就立即被打散。看起来这样体现了高度的灵活性，以及更快速地应对交付日期的响应能力，但是反复切换上下文的成本被低估；
DevOps 拓扑反映了两个核心理念：
- 没有一种通用的组织架构方法来让 DevOps 获得成功；
- 部分拓扑是阻碍 DevOps 成功的反模式，它们忽略了甚至同 DevOps 的核心理念背道而驰；
其中第二点也就是说：并不存在所谓“正确”的团队拓扑，但在组织中存在很多“错误”的团队拓扑。
成功的模式
特性团队依赖于高度工程能力成熟度和互信：
- 特性团队往往需要修改多个代码库，这些代码库由不同组件团队管理；多个团队在同一个代码库中叠加地工作，会导致代码缺乏负责人，除非团队间遵循高度协作的规则；
- 随着业务发展，我们逐渐需要一些人考虑和维护整个系统，确保子系统可以融入整个系统，满足期待的用户体验、性能和可靠性。于是“系统架构师”、“系统负责人”、“集成经理”等角色应运而生。
产品团队需要支持系统：
- 团队保持自主性的关键在于不被外部依赖所阻碍，也就是说新 feature 不能够因为某些团队掌控范围之外的事情发生而处于停滞状态；
- 产品团队通常承担了巨大的快速交付压力，如果它们所使用的系统无法提供必要的自主性支持，那么就会导致日益增长的摩擦；
云团队无需创建应用基础设施：
- “云团队”并不是换了一个名字的“基础设施团队”，他需要提供云服务带来的速度和扩展性；
SRE (Site Reliability Engineering) 让扩展性成为可能性：
- SRE 是 Google 创建的一种软件运维与改进方法，这个团队更加关注“错误预算（Error Budget）”和“服务等级目标（Service-Level Objectives, SLOs）”
- 它们有能力将低质量的软件回退给软件开发团队，团队成员需要优秀的软件编程能力；
选择团队拓扑需要考虑的因素
技术和文化成熟度。
组织大小、软件规模和工程能力成熟度：
- 组织大、能力成熟的团队：端对端和专职团队聚焦可用性；
- 组织大、能力不成熟的团队：端到端团队的常规协作；
- 组织小、能力成熟的团队：依赖于 PaaS 的专职团队；
- 组织小、能力不成熟的团队：专职团队间紧密合作；
拆分职能竖井：
有时我们可以将一些特定团队所承担的若干职能拆分和授权给其他团队来减少或消除对这种团队的依赖。比如：DBDev 从 DBA 中拆分出来。
在工作负荷增加时，不能一味地增加人手和团队，而是需要权衡利弊，认真考虑团队间哪些依赖应该减少，而哪些依赖应该保留。
团队间等待时间：
- 我们需要调研和跟踪团队间的依赖关系，以及因为等待而耗费的时间。
- Diane Strode 和 Sid Huff 将团队间依赖归位三类：“知识型依赖”、“任务型依赖”、“资源型依赖”，这样的分类有助于分析团队间的依赖，以及潜在的针对工作流的约束。