从组件团队到Spotify模型
遗留系统中的团队结构
首先，按照技术或职能（functional）来划分团队或部门，无形中增加了组织壁垒，造成了不必要的沟通成本。
因为一个围绕用户构建的需求，必然是跨越多个技术组件的。一个本来完整的端到端的需求，因为团队按技术分组，不得不被分为前端部分、后端部分、数据库部分，一个小需求的联调和验收就要涉及到三个部门、五个不同团队的人。
其次，随意的团队划分看似合理，但你仔细琢磨一下，不难发现实际是目的合理，手段存疑。因为我们的目的是解决研发痛点问题（比如前面说的数据库问题），这个目标成立，但组建 DBA 团队这个手段会造成额外的沟通成本，在我们看似解决了一个问题的同时，又带来了新问题。
第三，频繁地变换团队成员，知识就得不到沉淀，对系统和人都是如此。系统频繁变换维护者，所以没有人对这个系统熟悉，也没有人愿意为它付出更多的努力，因为所有人都知道过不了多久就会离开这个项目；人频繁变换系统，导致团队成员对每个系统都是浅尝辄止，没法深入研究，更不要说偿还技术债了。
像测试人员频繁变换所测试的系统这种事情，在拥有独立测试团队的组织中是十分常见的，因为需要为不同的项目调配测试资源。但实际上测试人员应该是最了解系统的那个人，频繁变化系统会使他们丧失这种能力。
改进的团队结构
为了解决人员频繁变动和知识流失问题，可以组织组件团队（Component Team）。即一个固定的团队负责维护一个组件，在团队内部可以形成关于该组件的知识闭环。
因为组件团队是长期存在的，这就可以解决知识沉淀的问题，团队成员也更容易形成默契，减少沟通成本。组件团队也是跨职能的，而不是单一职能。
跨职能是指，业务分析人员、前端开发人员、后端开发人员、DBA、架构师和测试人员等不同职能角色都在同一团队中（有些角色可以兼任）。这进一步解决了沟通问题，同时跨职能的人组成的单个团队，不同身份的团队成员之间不再对立，而是共同为该组件负责。
不过即使我们已经按业务组件划分了，遇到一个稍微大一点的需求，也可能横跨多个业务组件，还是会导致多组件团队的沟通协作。有时候业务分析师会把这样的需求按业务组件拆分，但最终的集成和联调仍然是比较头疼的问题。
为了解决这一问题，Jeff De Luca 等人提出了特性团队（Feature Team）的概念。特性团队是指一个长期存在的、跨职能的团队，团队成员一起完成多个端到端的用户特性。
特性团队和组件团队一样，也是长期存在且跨职能的，因此容易形成知识沉淀，也不会出现组织壁垒。而由于一个特性（即需求）会横跨多个业务模块，他们也不像组件团队那样需要横向沟通，自己在组内就能完成这个需求。
康威定律
一个组织所设计的软件系统的结构，与组织的沟通结构是完全一致的。也就是说，如果按技术组件来划分团队边界，完成沟通协作，就会出现 UI 层、业务逻辑层和数据库层这样的技术分层结构。如果按业务领域划分，那么就会出现按业务来划分的模块或服务，比如订单服务、库存服务、用户中心等。
多年以来，康威定律一直在默默起着作用，如果团队按技术分组，却希望设计一个微服务架构，最终都会走向无尽的深渊。遗留系统中的那种团队结构，必然会导致大泥球架构。
Spotify模型
Spotify 模型中的基本开发单元是小队（Squad），它类似于特性团队，也是跨职能、自治的开发小组，由 6~12 人组成。当小队越来越多时，负责同一个业务模块的小队就组成了一个部落（Tribe），人数通常不超过邓巴数。部落首领（Tribe Lead）负责协调各个小队以保持一致。
虽然小队和部落是自治的，但不同小队和部落之间保持技术的一致性也很重要，这可以在公司内部就某一技术达成规范。这时，专注于不同技术的人可以跨小队来组成分会（Chapter），如测试分会、架构分会、前端分会等。分会成员会定期凑在一起，讨论专业领域的知识和近期遇到的挑战。
除了分会，Spotify 模型中还有一个更松散的组织，即协会（Guild）。它更像是一个兴趣小组，聚集了一些热爱分享的人，可能讨论的内容与当前工作并没有直接关系。
分会和协会有助于团队成为一个技术氛围浓厚的学习型组织。因为有了分会和协会，小队成员在技术上就不会觉得孤立无援了。而且一个优秀的小队成员，既可以在小队内部起作用，也有机会通过分会、协会建立跨团队的影响力。
团队拓扑学
尽管组件团队、特性团队和 Spotify 模型，都为团队的组成提供了不错的建议，但团队的类型应该是什么样并没有一致的标准。如果所有团队都是特性团队，专注在某一个业务领域，那么业务领域开始变得复杂时，仍然僵化地专注于功能特性就会导致一些问题。
比如一个支付平台，它除了有源源不断的业务需求外，还有很多技术相关的事情要做，如数据的同步、分布式事务，或业务的回滚、对冲等。
假设按照系统的复杂度来判断，需要三十个人来维护这个平台，要是按照特性团队的思路来进行组织，就会分为三个特性团队，它们做着完全类似的业务开发。而对于复杂的技术问题，就可能无人问津了。尽管有了分会和协会可以一定程度上缓解，但这种自组织社区的执行力显然还不够。
这时，我们应该从团队优先（Team First）的角度去思考，将任务按照不同的复杂度来进行分解，并据此来创建团队。比如对于高复杂度的任务，应该建立一个以解决这些问题为 KPI 的专门团队，只有这样的团队才能真正解决这些复杂的问题。
团队拓扑学的四种团队拓扑类型和三种交互模式
业务流团队（Stream-aligned Team），这里的“流”是指与业务、领域或组织能力对齐的工作流程，业务流团队的工作有可能是一个产品或服务，也可能是一组特性、一个用户旅程或一个用户画像。他们有能力快速、安全、独立地构建和交付用户价值，而不用将部分工作交给其他团队。
赋能团队（Enabling Team），由特定技术领域或产品领域的专家组成。赋能团队里的这些专家可以开展调研，尝试不同的方案，寻找最佳实践。然后对业务流团队进行赋能，使他们不需要太多的努力，就能具备拆分微服务的能力，大大降低了认知负载。赋能团队并不会亲力亲为地解决具体技术问题，这些问题还是由业务流团队来处理。赋能团队主要关注的是，对组织中的所有业务流团队能力的提升。
复杂子系统团队（Complicated-Subsystem Team），由该领域的专家组成一个固定的团队，来维护这个复杂的模块。这种团队拓扑类型，就叫做复杂子系统团队（Complicated-Subsystem Team）。在遗留系统中，如果有些复杂的计算位于存储过程，转换成 Java 十分困难，而且效率也不一定高。这时候可以考虑把它整体隔离出去，构建一个复杂子系统，再相应去组建一个复杂子系统团队，专门来维护它。团队自己可以决定是保持不变，还是将存储过程慢慢演进成代码。业务流团队在和复杂子系统交互时，只需要使用复杂子系统团队提供的 API，而不用费力地去理解这个复杂模块，同样可以降低认知负载。
平台团队（Platform Team），负责解决底层问题，让业务流团队可以更专注于业务开发。
团队拓扑的出发点是团队的认知负载，它所倡导的团队结构是认知负载最低的。它并没有尝试从不同的技术层面去解决团队的认知负载问题，这个角度仍然是在跨职能的业务流团队内部，通过不同的技术角色来解决的。因为业务流团队的成员虽然技术栈不同，但解决的都是价值流交付的问题。
三种团队交互模式分别是协作（Collaboration）、服务（X-as-a-Service）、促进（Facilitating）。
协作（Collaboration）是指一个团队与另一个团队紧密合作。比如前面提到的，业务流团队通过 API 来访问复杂子系统，当新的需求需要复杂子系统提供新的功能时，业务流团队就需要和复杂子系统团队通力合作，来完成这个需求；再比如一个用户登录功能，也需要业务流团队和平台团队的协作，业务流团队负责开发面向用户的界面和相应的后台，平台团队负责开发认证与鉴权功能，或者与其他单点登录系统集成。协作也会增加沟通成本，但这种成本是系统的复杂性所导致的，并不是像按技术分组那样，是人为因素导致的。
服务（X-as-a-Service）是指使用或提供某种服务，而尽量减少协作。比如如果复杂子系统已经提供了完成需求所用的 API，业务流团队就无需与复杂子系统团队协作；如果平台团队已经封装好了用户认证和鉴权的所有功能，业务流团队也只需要“拿来主义”即可。由于 API 或服务开箱即用，业务流团队无需关注底层的实现细节，就可以快速地实现功能。
促进（Facilitating）是指帮助其他团队清除障碍。这是赋能团队主要的交互模式，他们对外部团队提供支持和赋能，来提升他们的生产力和效率。
逆康威定律
我们前面提到了康威定律，即团队的结构会影响到系统的架构。假如你的系统包含四个团队，每个团队都包含前端和后端开发，而仅有一个 DBA 负责数据库变更。那么根据康威定律，你得到的软件架构一定是，拥有四个独立的应用，包含各自独立的用户界面和服务端，而它们共享一个单体数据库。
如果你在保持团队结构不变的情况下，企图拆分数据库，一定是办不到的。即使勉强拆分出来，也会很快腐化。正确的做法应该是，顺应康威定律，为每个团队配备一名 DBA，然后再拆分数据库。每个应用的数据库由单独的 DBA 去维护，才能保证它不会腐化。
这种为得到理想的架构而改变团队结构的做法，叫做逆康威定律（Inverse Conway Maneuver）。也就是说，你想得到什么样的架构，就先把组织结构调整成那个样子，以此来推动组织变革。
小结
标签：复杂,现代化,业务,Team,组件,团队,子系统,结构 From： https://www.cnblogs.com/rickybelment/p/16792114.html