我第一次读到《团队拓扑Team Topologie：简称TT模型》是在 2021 年（这是我遇到过的最好的经理之一送给我的礼物）。但自从我与Agile Yorkshire的 Matthew Skelton 进行了一次演讲后，这本书就一直在我的愿望清单上。
那天晚上，我们的谈话非常互补，但我发现 Matthew 和他的合著者 Manuel Pais 所做的工作远远超出了我的想法，他们创造了一套关于如何组织软件团队的全面模式。
然而，当时，我对康威定律以及如何有意识地构建人员系统以推动组织所需的架构感兴趣，因此我一直在开发一个类似但不同的模型——我的模型更具体，基于架构分层模型——TT 更通用，更具拓扑性。
我很想了解这两个模型之间的关系，所以我写信给马修，我们通过 Google 文档进行了讨论。我在这里将其转录，并附上了他的评论。你会发现我做了一些无意识的假设，马修很快就发现了。
我希望您觉得这是一个有趣的讨论！
希望你一切都好！抱歉我花了一段时间才写这篇文章。
问题背景
对于许多组织而言，网站和应用程序是与客户互动的主要渠道，并且通常将它们视为差异化产品，如果由内部软件工程团队来开发和拥有它们则会受益。
对于一些组织来说，他们还认识到让这些团队自主和独立运作意味着更快的创新速度（根据通用可扩展性定律减少争用和一致性成本）。
这意味着要将事情划分成拥有自己堆栈的“垂直团队”。
到目前为止，一切都很好。
但我们必须划一条界线。你的垂直切片可以切多深？
自治和独立必须有一个限度。
解释：在组织中，网站和应用程序作为与客户互动的主要渠道，可以通过内部软件工程团队的自主和独立运作来实现更快的创新。这种方法通常涉及将团队划分为拥有自己技术栈的“垂直团队”，以便他们能够并行工作并独立传递价值。
首先，你不能允许团队完全独立，因为这样会导致成本不断上升。
- 如果公司为了产品定价而从第三方获取数据，那么您只想为此支付一次费用。您不希望数十个团队各自支付自己的连接费用只是为了获取相同的数据。
- 您不希望每个团队都为客户身份验证和服务到服务身份验证构建自己的身份验证系统。这些事情需要专业知识，而且设计成本高昂——您只想承担一次这样的成本。
这不仅仅与成本有关：
- 在第一个例子中，您还关心一致性。您不希望数据提取和处理中的差异导致客户在通过购物篮/结账时看到同一商品的不同价格。
- 对于第二个例子，像 auth 这样的东西将成为各种审计（PCI、GDPR、SOX、ISO27001 等）的焦点，因此至少有一个单一的标准化方法是有益的。
当然，还有认知负荷：
- 你希望你的团队专注于解决差异化问题——在使公司具有竞争力的事情上进行创新——而不是所有人都在构建和维护自己的身份验证解决方案。
如何解决这些问题？
似乎每个例子都有一个明显的解决方案：
- 我们让一个团队从第三方获取数据，然后将其提供给其他团队使用。（如果每个人都需要做同样的处理，那么团队可能会对数据进行一些简单的处理）。
- 我们让一个团队建立并拥有单一身份验证系统，并使其可供其他团队使用。
我建议识别两组域是有帮助的：
- 体验域，取决于：
- 商业领域
体验领域
由主要向最终客户提供产品（即网站和应用程序）的团队组成。我们称他们为体验团队。
- 它们聚合并组合业务域提供的数据和功能，为客户创造丰富且引人注目的体验。
- 这些团队构建的堆栈完全针对特定用例，并且完全独立——其他团队不应依赖它们。
- 在这些领域，我们进行了优化以实现快速创新。
商业领域
业务域由向其他团队（内部客户）提供常用的自助数据和功能的团队组成。
- 对于我们的电子商务公司，我们可以想象业务域，如“产品”、“客户”、“促销”、“营销内容”等。
它们可能采用 RESTful 服务、Kafka 主题、Web 套接字或其他一些接口的形式，但它们都具有完整的产品化，并配有适当的文档、版本控制策略、功能请求、积压/路线图规划、已发布模式等。
它们提供的数据和功能应该是规范的，并且通常有用（而不是特定于用例）。这些领域和系统的整体设计和目的是其他团队可以并且应该从它们那里使用并依赖它们——解决重复成本、一致性（有时还有认知负荷）的问题。它们是大多数体验团队垂直堆栈的底线。
在这些业务领域中，我们针对重用性和稳定性进行了优化。
团队拓扑如何解决上述问题？
- 关于在何处让团队独立并允许重复，没有固定的规则——垂直深度可以随心所欲。这始终取决于组织环境上下文。希望标准化的地方是业务领域，而不希望标准化的地方是体验领域，即使这样也并非总是如此。同样，它始终取决于组织环境。
- 拥有单例系统或方法并非理所当然。我认为企业架构师经常直接跳到这个假设，因为它似乎简化了组织，并提供了规模经济。但这样做会产生您可能不希望在组织的某些领域产生的副作用，例如引入争用。
团队拓扑中的平台团队不一定在构建技术平台。这些可能是作为产品提供给流对齐团队的业务平台。例如：
- 提供权威 API 或数据流或业务事件的服务，
- 或执行流对齐团队无法自己完成的操作的服务，例如上面讨论的数据馈送和身份验证示例。
平台团队中平台概念：
- 不仅仅是“技术平台”。
- 可以构建所谓的“业务平台”
换句话说，如果一家公司需要一项权威服务来执行定价计算，并将其提供给其流程一致团队，那么这将由 TT 模型中的平台团队提供。
作为一名技术人员，“平台”这个词总是让技术人员首先想到技术平台，它实际是一种“流平台”或（更好的）“创新加速器”
- 任何能让流程一致的团队专注于其价值流的事情，
- 而不是试图做其他人可以专攻的繁重工作。
与流程一致的团队可能会选择承担一些非领域活动，以保持解耦和独立。
- 他们必须在独立与减少认知负荷之间做出权衡
那么，TT 中平台团队的定义特征之一是它被设计为共享（即有多个依赖者/消费者），而流程对齐团队绝对不是？
- 不能说TT 平台的设计是为了共享。共享更像是良好设计的一个不错的副作用
- “应该在内部消费的好东西”与“应该在外部消费的东西”是有区别的：关键在于以客户为中心。
“共享”这个词可能有点误导。TT 平台是设计用来供多个内部团队使用或消费的吗？
- 不：TT 平台旨在改善流程并减少至少一个（但可能只有一个）流程一致的团队的认知负荷。
- 不是为了 重用、共享（“重用”谬论）。
什么是“重复使用”谬论？
- 即使只有一支团队使用 TT 平台，它也能发挥价值。因此，没有必要让一个平台为多支团队服务。
- 但实际上，如果一个平台提供有用的服务，我们通常会期望它拥有多个客户。但这并不是必需的，也不是平台的驱动力或存在的理由。
那么平台是否应该设计成可供多个消费者使用？
这就像说“产品和服务是否应该被设计成可以被多个客户使用？”
- 大多数情况下，是的，
- 但如果是试点客户或特殊情况，那么我们不想过早地强迫多个客户使用。
平台团队TT模型目标是减少程序员认知负荷
我们真的可以用 X 来减少我们的认知负荷”
- 并且存在针对 X 的平台产品，
- 但尚未针对多个消费者进行设计
那么从该团队讨论消费是否是一种有效的方法？
- 回答是肯定的，是的！
banq注：
- 文章作者自身掉入技术人员的认知陷阱
- 原文标题：关于团队拓扑的问题，这个标题本身就很含糊，如果理解团队拓扑的目标是降低认知负荷，他就不会取这样一个增加认知负担的含糊名称。