摘要

根据文中提到,团队拓扑定义的四种团队类型和三种协作模式如下:

四种团队形式:

• 面向流团队(Stream-aligned team):负责单一业务能力的软件开发团队。
• 平台团队(Platform team):构建内部平台以集成各种服务的团队。
• 使能团队(Enabling team):由专家组成的团队,通过培训和指导帮助其他团队。
• 复杂子系统团队(Complicated-subsystem team):专注于复杂子系统的团队。

三种团队交互模式:

• X即服务模式(X-as-a-Service mode):平台团队向面向流团队提供平台服务的模式。
• 协作模式(Collaboration mode):团队之间进行密集合作的模式。
• 促进模式(Facilitating mode):使能团队通过培训和指导帮助其他团队的模式。

原文翻译（by Claude)

任何大型软件项目,例如大公司的软件系统,都需要大量人员参与,在有大量人员参与时,你必须要考虑如何将他们划分成高效的团队。基于业务能力的团队划分有助于软件项目对客户需求作出响应,但是所需技能范围的广泛会让这样的团队不堪重负。团队拓扑是 Matthew Skelton 和 Manuel Pais 开发的用于描述软件开发团队组织的模型。它定义了四种形式的团队和三种团队交互模式。该模型鼓励健康的交互,使基于业务能力的团队得以在持续提供有价值软件的任务中蓬勃发展。

在该框架中主要的团队形式是面向流的团队,这是负责单一业务能力软件的基于业务能力的团队。这些是长期存在的团队,将他们的工作视为为增强业务能力提供软件产品。

每个面向流的团队都是全栈(front-end、back-end、数据库)和全生命周期(业务分析、功能优先级确定、用户体验、测试、部署、监控等软件开发环节),他们注重业务成果(结果导向）而不是以功能导向(如业务分析、测试或数据库，原文是Activity Oriented)。但他们也不应该过于庞大,理想情况下每个团队都是一个能用两份比萨饱腹的小团队。大型组织会有许多这样的团队,尽管他们支持不同的业务能力,但都有一些共同需求,如数据存储、网络通信和可观察性。

像这样小的团队需要方法来减少他们的认知负荷,因此他们可以专注于支持业务需求,而不是(例如)数据存储问题。实现这一点的重要方法是在一个可处理这些非关键关注点的平台之上进行构建。对许多团队来说,广泛可用的第三方平台(如面向数据库 Web 应用程序的 Ruby on Rails)可以作为一个平台。但是对于许多产品来说,没有现成的平台可供使用,团队需要找到并集成多个平台。在较大的组织中,他们需要访问一系列内部服务并遵循企业标准。

这个问题可以通过为组织构建内部平台来解决。这样的平台可以将第三方服务、近乎完整的平台和内部服务进行集成。团队拓扑将构建这一平台的团队(不够生动但明智的)归类为平台团队。

较小的组织可以使用单个平台团队,它在一个外部提供的产品集之上制造一个薄层。然而,较大的平台需要的人数超过两份比萨可以喂饱的人数。因此作者进一步描述了由多个平台团队组成的平台分组。

平台的一个重要特性是它被设计成可以主要以自助的方式使用。面向流的团队仍然负责他们产品的运营,并直接指导他们对平台的使用,而不期望与平台团队进行精心协作。在团队拓扑框架中,这种交互模式被称为 X 即服务模式,平台充当面向流团队的服务。

然而,平台团队需要将他们的服务构建为产品,并深入理解客户的需求。这通常需要他们使用不同的交互模式,即协作模式,同时构建该服务。协作模式是更密集的合作伙伴形式的交互模式,应被视为一种临时方法,直到平台足够成熟以转向 X 即服务模式。

到目前为止,该模型没有代表任何特别新颖的思想。企业软件存在以来,就有将组织分解为业务相关团队和技术支持团队的方法。近年来,许多作者强调让这些业务能力团队负责完整的技术栈和完整的生命周期的重要性。对我来说,团队拓扑的亮点是它关注这样的业务相关团队是完整的技术栈和全生命周期管理,这意味着它们往往面临过高的认知负荷,这与希望拥有小型、敏捷团队的愿望相矛盾。平台的关键优势在于它减少了这种认知负荷。

团队拓扑的关键洞察力在于平台的主要优势在于它减轻了面向流团队的认知负荷。

这一洞见具有深远的意义。首先,它改变了平台团队应如何考虑平台。减轻客户团队的认知负荷会导致不同于主要用于标准化或降低成本的平台的设计决策和产品路线图。再者,这个洞察引导团队拓扑通过识别另外两种团队类型来进一步发展他们的模型。

一些功能需要专家,他们可以投入大量时间和精力掌握许多面向流团队都重要的主题。安全专家可以花费比作为面向流团队成员更多的时间学习安全问题并与更广泛的安全社区进行互动。这些人聚集在使能团队中,其角色是在其他团队中培养相关技能,以使这些团队保持独立并更好地拥有和发展其服务。为了实现这一点,使能团队主要使用团队拓扑中的第三种最终交互模式。促进模式（这个翻译不错，点出了facilitating的目的）涉及指导角色,使能团队不会编写和确保遵循标准,而是教育和指导他们的同事,使面向流团队变得更具自主性。

面向流团队负责为其客户提供整个价值流,但我们偶尔会发现面向流团队的某些工作非常具有挑战性,以至于需要一个专门的团队来关注它,这导致第四种也是最后一种团队类型:复杂子系统团队。复杂子系统团队的目标是减轻使用该复杂子系统的面向流团队的认知负荷。即使只有一个客户团队,这也是一个值得的划分。复杂子系统团队主要努力与客户使用 X 即服务模式进行交互,但会需要在短时间内使用协作模式。

团队拓扑包括一组图形符号来说明团队及其关系。这里显示的图标来自当前标准,与书中使用的不同。最近的一篇文章详细阐述了如何使用这些图表。

团队拓扑是明确认识到康威定律的影响而设计的。它鼓励的团队组织方式考虑到人员和软件组织之间的相互影响。团队拓扑的拥护者希望其团队结构可以塑造软件架构的未来发展,使其成为响应业务需求的解耦组件。

乔治·博克斯巧妙地指出:“所有模型都是错误的,有些是有用的”。因此团队拓扑是错误的:复杂的组织不能简单地分解成仅四种团队和三种互动。但是这种约束使模型变得有用。团队拓扑是一个工具,促使人们将组织发展为一种更高效的运作方式,这种方式能够通过减轻认知负荷最大限度地提高面向流团队的效率。

思考

• 我们公司中有Enabling Team吗？或者说本应承担这些角色的团队是这样和其他团队交互的吗？
• 复杂子系统团队是否应该是短期的？随着项目的结束也结束？那么以后这些复杂子系统如何维护？
• 平台团队需要面向客户吗？或者说，我们需要真正面向内部的平台团队，而不是面向客户、提供基础服务的功能团队？
• 同时面向内部和外部客户的平台团队合理吗？