特性团队和组件团队

比较示例

特性团队是长期存在的，跨功能的，跨组件的团队，该团队可以一个接一个的完成许多端到端的客户特性。

（该定义和图片来自LeSS官网）

而组件团队则不同于特性团队，是一个聚焦于一个产品的特定组件或者领域的团队，组件团队是分工协作的产物。比如前端团队、后端团队；比如开发团队、测试团队、运维团队等类似的划分。如泰勒的科学管理中指出：“管理要解决的就是，如何在有限的时间里获取最大程度的产出，也就是如何使劳动生产率最大化的问题。”泰勒给出的其中一个方法就是劳动分工，所以这里的劳动生产率最大化本质上是指的资源利用率最大化，组件团队就可以实现这种资源利用率的最大化。后来特性团队的出现则是精益敏捷所追求的价值流动最大化而言的，两者追求的目的并不矛盾，但是重点不同。

下图是一个典型的特性团队和组件团队的对比示例：

特性团队：聚焦于端到端交付，按照一个个的功能来实现客户价值，Scrum team就是一个典型的特性团队，team从product backlog中承诺需求，将其实现为可工作的软件，也就是价值增量。对于特性团队来说，组与组直接是松耦合的，如果在大规模的系统开发中做不到团队间完全解耦合，那么使用类似Scrum over Scrums或者LeSS这样的模式来扩展，宗旨是尽量减少团队之间的依赖，减少团队间工作的切换，比如从一个团队到另外一个团队的任务移交，否则会增加沟通的成本，增加信息的流失。减少重复的交流，比如使用Scrum里不同形式的会议，如每日站会、计划会等做充分的及时的沟通。按照特性团队来划分组织的目的在于更早的交付，更早的获得反馈，更快的适应。但其依然有自己的缺点：比如技术上重复造轮子，代码重复，架构容易不一致。

组件团队：聚焦组件的实施，无法直接交付功能，团队之间有比较强的依赖。依赖的增加则需要集成工作，集成带来的风险减少了可预测性。从问题域（需求）到实现域（任务）的分解，特性团队可以直接映射过来，但是组件团队还需要多一层架构上的分解，也就是从需求先到组件才能再到任务，团队成员很容易缺失业务视野，只是完成任务。对于业务的不聚焦，可能会导致开发了业务不需要的功能出来，而这是最大的浪费。当然也有其优势，就是增强了架构设计和代码的一致性。

规模化下两个团队的比较和示例

这里的规模化并不是仅仅指的团队的数量很多，而是互相依赖的团队数量很多，也就是一起工作在一个产品上的团队是规模化的情况。在这种规模化的时候如何考虑特性团队和组件团队呢？在规模化的情况下，如果都是特性团队，可能存在的一种情况就是一个单一特性需要跨的组件太多了，该怎么处理？LeSS中对此有所说明。一个选择是团队是一个整体，但并不是每个人都要熟知整个系统，团队里面的人依然有所分工和聚焦；二是feature也不会随机分给随便一个团队，而是考虑团队所拥有的知识和能力来分feature。这两个方法可以部分缓解这个问题。如果还是会出现瓶颈，那么就去学习。LeSS这个思想的出发点就是特性团队可以平衡专业性和灵活性，并促进学习型组织的进化。

SAFe里认可组件团队也是敏捷团队的一种，在这种组织划分方式下，对于组件内容的修改主要是来自于组件团队，集体代码所有制在该团队中实施，其他团队如果需要修改该组件，则需要提前跟owner沟通。当然SAFe并不否认feature team，而是feature team和component team的混合，并且是倾向于feature team的。

一个具体实践的例子：诺基亚的移动网络事业部中的探索。因为是电信级产品，一个特性往往会跨的组件比较多，所以诺基亚内部，有一个domain owner的概念，每个domain可以理解为一个组件，给这个组件会制定一个domain owner，虽然owner的帽子会放到一个人头上，但是本质上意味着这个domain的owner是这个人所在的scrum team（或者多个team），这个domain的架构设计来自于这个owner team，其他团队的改动一开始不被允许，需要提交给这个团队；后来因为效率很差，而且这跟敏捷的原则也不一致，遭到比较强的反对，改成其他团队的改动可以由自己来做，但是必须要经过owner team的review，只有得到owner的approve，代码才可以提交；组件的一致性、责任感和质量都相对有比较好的保证，但是效率有所牺牲。需要指出的是这些在诺基亚的实践都是在LeSS框架下进行的，但是跟SAFe下的描述很相似。也有过不需要owner approve就可以提交代码的时候，但是domain owner的概念一直都在，这是一个通过回顾不停探索找到适合组织的模式的过程，跟框架无关，好用就行。

混合模式

混合模式：某些产品中或者组织里，有的情况下需要专门的团队负责搭建基础设施，LeSS里的说法是没有这样的必要，可以把传统组件团队需要完成的任务放到backlog里，然后feature team领走完成即可。但这个就跟企业是不是需要IT部门的讨论一样。自己的观点是没必要这么绝对，要看组织和系统的情况。在国家的十四五规划里面，对于国企央企提出了更高的数字化要求，在这样的企业中，最起码目前看到是对于基础设施的建设，专门的组件团队感觉还是效率更高一些，比如基础平台建设，统一工具建设，统一运维，主数据建设。随着基础设施的成熟，或许可以走到更多特性团队的情况。康威定律告诉我们，产品（技术架构）是组织结构的缩影，在传统企业里面，组织的划分和层级制相对固定，改变组织结构的难度可能相对比较大，相应的，组件团队就成了不得不的选择（可能没那么好）。

上图是Spotify中的一个组织结构图，Squad是一个feature team，而chapter就是一个组件team。这是一个虚实结合，组件和特性团队混合使用的比较好的一个例子。

（图来自“Adapt框架如何解决金融组织研发交付七大痛点”）

Adapt 的核心之一是虚拟部落制，其脱胎于 Spotify 的部落制。虚拟部落化组织打造对齐业务领域的纵向交付单元，打破原有部门墙的鸿沟，同时保留了专业职能的横向实体线，侧重提升组织人才专业化能力。从上图可以看出来跟Spotify类似，Adapt也保留了特性和组件混合的使用。

最后：如何选择团队类型

上图是SAFe中的一个图，说明在越多团队公用，技术的专业性越强的场景下，或许越应该选择组件团队，反之则应该选择特性团队。比如涉及到通用的算法或者其他非常深的理论基础的组件，选择特性团队未必不是一个好的决定。spotify里有个专门的运维团队也有像这样的组件团队，这个运维团队并不是负责具体哪个团的运维工作，而是负责各个团队运维工作的赋能。

在开发新的产品、业务迅速增长，进入新的市场、用户数快速增长、创业（包括内部创业）这些场景之下，更适合特性团队，因为能更好的应对不确定性。

但是在产品稳定、进入成熟期的时候或许组件团队是一个好的选择。因为可以减少成本，比如维护团队。

同时Feature team也有一定的门槛或者说是要求，比如集体代码所有制，因为不同的团队都会修改同一个组件的任意代码。对于成员的开放性、学习能力和意愿、代码质量、重构技能等都有所要求。

所以，是feature team还是component team，安于当下还是着眼未来，丰俭由人吧，不过我选feature team！

参考文件：

https://www.scaledagileframework.com/features-and-components/

https://less.works/less/structure/feature-teams