团队自主权是指团队在无需获得其他团队批准的情况下进行决策和采取行动的能力。让我们首先看看为什么团队自主权对于快速、频繁和可靠的软件交付很重要。然后看看如何实现它。
1 为什么团队自主权很重要?
Accelerate 一书的作者发现,它是高性能软件交付的一个重要方面。一个团队应该能够独立于其他团队开发、测试和部署他们的软件(即子域)。
因为与其他团队协调是延迟和瓶颈的来源。你需要安排一个会议,确定需要做什么,然后等待其他团队完成工作。在许多组织中,会议室供应都很紧张。此外,研究发现,在团队内部做决策(例如在每日站会上)比跨团队做决策快得多。
开发大型应用程序的挑战在于,如果有 N 个团队,那么根据 人月神话,每个团队潜在地需要与 N-1 个团队协调。协调工作的努力与 O(N^2) 成正比 - 一个无向图中 N 个顶点的边数。因此,随着团队数量的增加,协调工作的努力会迅速增长。设计一种最小化团队之间协调努力的架构是至关重要的。
2 为团队自主权设计
有三种不同的设计技术可以提高团队自主权：
- 设计松散耦合的子域
- 使用模块化的单体应用程序来分离子域
- 使用微服务架构来物理上分离子域
2.1 设计松散耦合的子域
团队自主权要求由不同团队拥有的子域在设计时是松散耦合的。设计时的松散耦合最小化了团队之间需要协调的频率。通常是通过设计稳定的 API 来封装子域的实现细节来实现的。最小化每个子域的入站和出站依赖也是有益的,因为每一个都是变化的潜在原因,从而需要协作。一旦你设计了松散耦合的子域,你就可以使用模块化的单体应用程序或微服务架构来物理上分离它们。
2.2 使用模块化单体应用程序
在单体应用程序中,可以通过使用围绕子域而不是技术层次组织的模块化单体应用程序来在一定程度上实现这一点。每个团队拥有并开发自己的子域模块,而不是每个团队都在每个层次上工作。他们大多只需要不时与拥有他们子域入站和出站依赖的团队协调。
然而,模块化单体应用程序的一个限制是,所有团队都在为同一个代码库做贡献。多个团队将需要协调某些类型的更改,例如依赖项(如框架和库)的升级。例如,假设 Order Management 团队想要使用一个依赖于某个库的新主要版本的库,而该库已被许多其他子域使用。他们将需要花时间与拥有每个子域的团队协调升级。因此,协调工作的努力仍然与 O(N^2) 成正比。
2.3 使用微服务架构
在开发大型应用程序时,物理上分离子域的一个更好的方法是使用微服务架构。每个团队拥有一个服务,他们可以独立于其他团队开发、测试和部署。他们只需要定期与拥有他们服务入站和出站依赖的团队协调。此外,该团队可以独立于其他团队自由做出许多技术选择。例如,与开发模块化单体应用程序不同,如果 Order Management 团队拥有自己的服务,他们可以使用任何他们想要的库,而无需与其他团队协调。
应用程序范围内变更的主要来源是应用程序的基础设施,例如消息代理和部署平台。对基础设施的任何更改可能都需要与所有团队协调。不过,这种变更相对较少,而且据推测只有出于正当理由才会进行。
