内容来源：DevOps案例深度研究第4期 – Spotify DevOps实践研究战队（本文只展示部分PPT及研究成果，全程视频请移步文末）转载请注明出处。
本案例内容贡献者：褚旭龙（Topic Leader）、李旭霞、潘玉武、尚君领、王英伟、王艳、熊小龙、杨伟权、朱明、张志华
IDCF指导老师：姚冬、王立杰、许舟平、徐磊
【拓展阅读】
Spotify为大家所熟知，不仅因为它是一家了不起的音乐公司，或者说是一家商业上很成功的公司，而是因为Spotify是一个规模化敏捷框架。Spotify遵循精益敏捷的思想，随着公司的发展壮大，逐渐进化，成为一个成熟的规模化敏捷模式。以一家公司的名称来命名一个可供参考和实施的敏捷模型，可以看出来人们对于Spotify的敏捷实践是多么认可。
Spotify是从精益敏捷这么一个简单的动机开始，不停变化发展到现在，它的敏捷框架到底是怎样的呢？如Spotify的敏捷教练所说，他们现在依然在路上，并没有到终点，不管是组织机构还是敏捷实践，都在不停地变化，所以我们将这个规模化敏捷框架称为“变奏曲”，曲中有真意，接下来我们尝试着跟大家一起来欣赏这首乐曲。
一、Spotify的组织结构
1.1 Spotify 组织结构
从上图可以很清楚地看到，整个Spotify公司都围绕着四种类型的单元来运行，在这四种单元的分工协作下为全球数以亿计的用户提供一个优质的音乐平台。
这样一种组织结构组成了Spotify最重要的特征。在这个组织结构图中我们可以分别看到：
- 小队为最小工作单元，类似Scrum Team的全功能团队，也就是一个特性团队，一般10个人左右。组成如图中示例所描述的，可以有测试、开发、架构和产品等不同技能的人构成。需要注意的是，除了PO，其他人并没有角色的区分，只是说明小队里的人具有这些技能，而不是必须有测试工程师来负责测试工作。
- 小队组成部落，一般不超过100人。设计原则参考邓巴数的原则：人类智力将允许人类拥有稳定社交网络的人数是148人。在实践中一般不超过100人。人数过多管理复杂度容易提升，沟通的成本也会迅速增加。部落一般按照业务领域划分，后面将详细介绍。设计原则为大部分需求部落内完成。
- 分会：类似于职能组织，只是原来的职能经理改变成为赋能角色。
- 行会：是一个跨部落的兴趣社区，类似于传统的CoP。
1.1.1 小队（Squads ）
小队是Spotify的基本开发单元，类似Scrum Team的全功能团队，也就是特性团队，一般10人左右。在实践中人数不拘泥于7+/-2, 因为公司的现状可能极少人是全栈工程师，小队是根据一个业务里面具体的功能来组建的，所以人数可能会比7+/-2更多或者更少。
小队的特点
- 坐在一起：敏捷宣言的第一条核心价值就是“个体和互动高于流程和工具”。坐在一起更有利于个体的互动。
- 自主管理：小队里的成员并没有角色的区分，所有的人承担所有的工作。但在实际工作中，即使是自组织的小队，也需要指定一个人或者有人主动站出来帮助小队，让日常工作更平滑，我们可以称之为小队长。小队长是一个虚拟角色，非行政title。
- 拥有设计、开发、测试和发布产品所需的所有技能和工具。
- 自行决定工作方式：Spotify没有约束小队使用何种敏捷实践，小队可使用Scrum Sprint, 看板...任何他们觉得适合的敏捷工程实践。
- 拥有长期的使命或任务：小队并不是临时为了一个具体的项目而成立的临时组织，而是有着长期使命的固定团队。比如搜索小队：创建一种精彩的体验，以使得人们能够更快更容易地搜索到自己喜欢的音乐！
- 专职PO, 敏捷教练(Optional)：这里的PO和其他敏捷实践中的PO并没有不同，只是这里的PO只对一个小队负责，而在Spotify中取消了Scrum Master，取而代之的是敏捷教练，来帮助小队日常工作的平滑和敏捷实践的赋能。
1.1.2 部落（Tribe ）
一个部落是在相关领域工作的小队集合——比如音乐播放器，或者后台基础设施。
部落的特点
- 同一办公地点：同一办公地点的原因也是有利于沟通，减少交流的成本。但是现在远程办公越来越成为一种常态，或者说是一个趋势，今年的疫情也成了远程办公的加速器。在这种情况下，同一个办公地点的物理限制也越来越弱。在Spotify的敏捷转型里我们可以看到有的公司已经组建了跨Site，甚至跨国家的部落。
- 每个部落一般不超过100人：部落的组建是和业务强对应的，所以部落的大小取决于业务的规模，有的特定领域可能人数为20+人也可以。
- 从事相关领域的工作、解决特定的业务问题：如我们一直强调的那样，部落是和业务对应的一个组织，不同部落间具有隔离性。
- 负责人：酋长。这是个虚拟角色。对于酋长的要求：协同能力和业务的切分。分是为了正确地根据业务分出来独立工作的小队，而合则是协同小队进行必要的合作，一分一合的平衡，考验酋长的能力，做到了二者的平衡，酋长就真正地给小队提供了一个舒适的栖息地。为小队提供交流、合作、分享、创新、改进的环境和支持。
1.1.3 分会（Chapter ）
同一个部落中相同能力领域内拥有相似技能的人员。
分会特点
- 每个分会定期开会讨论他们的专业领域和挑战：虽然如我们所说小队是迷你的创业小队，但是如果互相之间绝对独立，就没有公司这个概念了。比如每个小队都有测试，如果他们之间没有交流，那么可能会都遇到相同的问题，开发相同的工具，会有重复造轮子的事情，这不符合精益的思想。分会则解决了这个问题。
- 负责人：分会领导。分会领导是分会成员的直线经理，负责所有的传统职责，如开发人员激励、设定工资等。分会领导其实本质上还是会由现在的职能经理来担任，不同的是思维上的转变。
1.1.4 行会（Guild ）
一个行会是具有广泛影响的“兴趣社区”。
行会特点
- 跨部落，贯穿整个组织：行会解决了整个组织层面的知识分享和流通。行会会定期进行知识、工具、代码和实践的分享。
- 有兴趣的人可以随时加入，也可随时离开：分会的成员是固定的，行会则是自由的。
- 负责人：行会协调人。也是虚拟角色。
1.2 运维团队（Operations Squad ）
如我们前面介绍小队的时候所说，小队具有发布的技能和工具，也就是说小队是自运维的。那这里还可以看到有运维小队，专职运维团队负责赋能，也就是给其他的开发小队提供运维的技能培训和技术支持。
1.3 沟通
Spotify组织里的沟通和其他敏捷沟通并没有特别的区别。因为Spotify的组织设计是小队和部落尽可能独立的，所以并没有设计特别的沟通方式，而是按需进行跨小队、部落对齐会议。只是在有需要的时候，比如在某个周期里面需要跨小队或者跨部落的合作，那么可以使用白板进行跨小队跟踪，面对面沟通来解决问题。
1.4 划分原则
Spotify如何实践？从划分原则开始！如果你去和现有组织比较，都相对比较类似，但本质不同。
- 部落制落地的核心在于此，难点也在于此。部落与业务条线对齐，是一个强交付的组织形式。如何把一个网状的业务结构梳理分割为一个个独立的部落结构，就是部落制度成功落地的关键所在。比如：在银行，可能会有零售，对公部落等；在通信行业，可能会有操作维护部落，或者载频部落；在资讯类软件公司中，可能有新闻部落，小视频部落，或者直播部落等。
- 小队所负责系统模块保障端到端交付，划分的时候将小队间的依赖尽量减到最少。
- 分会按职能划分，组织结构上类似职能线，实践的时候基本上就是原来的职能部门转变过来的。
- 行会根据不同业务，技术领域等组建社区，比如测试行会、敏捷教练行会等。
1.5 组织结构调整
Spotify的规模化，在划分上降低了沟通成本，使规模化更容易。因为在同一个组织内部的沟通，成本总是要低于跨组织的沟通。如上面所说过的那样，部落制度的落地难点在于业务的划分，也就是部落的划分。所以经常关注、反思、审视小队和部落间的依赖就成了一个很必要的行为，并且要根据结果做出相应的组织结构调整。
值得注意的是，在实践过程中，形成之后，重新审视调整，会遇到挑战，需要领导支持渐渐形成一种文化。酋长、小队长等虚拟角色则给这种拆分整合带来很大的便利。
1.6 人员任命及绩效设计
此部分也是人员任命和绩效的一种实践建议：
- 小队长：一般为系统负责人，对系统及领域熟悉。具备基本管理知识。
- 酋长：把部落内比较有能力的人才放到此位置，如上面介绍部落时所说，酋长应该具有一分一合的能力。
- 分会领导：职能领域精通，具备支持团队的人员。一般为现有的职能经理。
- 行会协调人：具有组织相关领域的人员，在领域内精通能很好地帮助行会活跃及发展。比如敏捷教练行会，协调人应该在敏捷实践领域有很强大的背景和能力，并能组织行会活跃发展。
对于绩效设计：以部落的业绩为基础，酋长和分会领导共同打分，相互约束。比如某小队成员的考核，酋长给出A，分会领导给出C，那么这个互相约束指的是：不能A妥协成C或者相反，而是上下浮动一级，可能最后这个同学的绩效为B。
1.7 部落运作模式
从这张图可以看到整个组织中不同的角色是如何协作，来提供给客户价值的，以及在其中的工程实践。比如“think it”中Prod、Tech、Design的合作，“Build it”中小队的工作迭代，“Ship it”中的 MVP和A/B test等等。
对于部落的运作模式，通过这张图我们可以有一个high level的印象，至于每一部分的详细说明，将会在后面工程实践部分做进一步的解释。
二、规模化敏捷框架的比较
2.1 规模化敏捷的框架
SAFe提供了一个完整而详细的框架，它告诉你如何工作、如何协调、如何培训、如何导入。与Spotify模型不同，SAFe的所有内容均已定义，可以说是一个没有想象力的框架，虽然它一直在演进版本，但是在当前阶段可以说它已经完成了。比较而言，SAFe是一个比较重的框架。
与SAFe不同，Spotify模型并非旨在成为一个大型工具箱。Spotify模型提供了一个相对较轻的框架，在框架里，依托于敏捷精益原则，敏捷实践者可以自由发挥。
而LeSS则处于二者之间，是一个完整详细但也比较简洁的轻框架，但是LeSS忠于Scrum的约束。
Spotify也是由Scrum演进而来，只是因为随着公司的发展，Scrum不再使用，在持续改进的思想指导下，演进成了现在的Spotify体系。在其中除了部落、小队、分会、行会的组织结构，Scrum Master的角色还被敏捷教练所代替。背后的意义在于保留原来具有的Facility属性之外，加强了这个角色身上Coach的属性，来保证整个团队和组织持续的改进。正如他们的敏捷教练所说，他们现在正走在旅途之中，而不是终点。
2.1.1 Spotify 框架
如图所示，这是一张典型的Spotify的组织结构图，到这里我们对其中的每个组织形式和特点应该不再陌生。这是2012年两位Spotify的敏捷教练接受采访的时候给出的一个Spotify敏捷实践的总结。
2.1.2 SAFe 框架
这是SAFe 5.0的一张框图，如图可以看到，SAFe是有一个非常完成的组织级别的大规模敏捷框架，详细定义了每个层级的结构和运行方式、各个不同的角色以及层级间的沟通协调方式。
2.1.3 LeSS 框架
从LeSS的框图可以看到另外一个架构，跟SAFe比较相对简单，但是也结构清晰。一个比较重要的特点是唯一的一个PO负责一个Backlog，也就是在一个LeSS里面，所有的Team都工作在同一份Backlog上。
2.1.4 Scrum@Scale框架
Scrum@Scale是一个对Scrum进行扩展的框架。通过使用Scrum来扩展Scrum，彻底简化了规模扩展。它仅仅包含一些Scrum团队，这些团队通过Scrum of Scrums和MetaScrums进行整合。SoSoS是Scrum团队的一个有机模式，可以无限扩展，就如同神经网络一样。
2.2 组织结构--规模化敏捷的比较
2.2.1 Spotify
Spotify的组织结构围绕着四类团队：小队、部落、分会、行会，或者说像一个鸟群或者鱼塘一样，因为它的设计思想就是用社区组织来代替传统的层级式组织。在Spotify里，组织结构和其它的公司走在了不同的演化道路上，部落的首领给整个部落里的小队提供足够好的栖息地，而每个小队则独立奋斗。
2.2.2 SAFe
SAFe是一个4层的组织结构：Team级、Program级、Large solution,、Portfolio级。Team级采用Scrum或者Kanban来运行，Program级别则使用ART的形式来提交价值增量，在Portfolio级别做上层管理。
2.2.3 LeSS
LeSS在组织结构上来说是Scrum的Team级扩展。在敏捷实践上通过同一个PO和统一的Sprint Planning来进行团队间的协作。
2.3 小队间的依赖
2.3.1 松耦合紧一致
根据康威定律我们知道：组织沟通方式决定系统设计。Spotify中高度独立的Squad模式，决定了系统也是高度解耦的，从而大幅降低了小队间的依赖。如同一个交响乐团一样，里面每个人都是独立演奏的，但演奏都是为同一首乐曲服务的，最后才能是一首好听的曲子。这就是松耦合紧一致的原则。
2.3.2 跟其他框架的比较
SAFe中靠Scrum Master/RTE来协调/解决日常工作中的障碍，而Spotify工作相对独立，在必要的时候使用Scrum of Scrums来解决小队之间的依赖问题。比较而言，Spotify里的小队间依赖要远小于SAFe，SAFe需要团队间更高程度的合作和对齐。
而LeSS工作于同一个Product Backlog的原因，团队间的依赖也会高于Spotify，通过在团队级别复制Scrum的活动来解决Team间的依赖问题。例如，Sprint 1可能与每个团队的代表举行，而不是所有团队的所有成员。
2.3.3 Squad 间的依赖
如上面所说，Spotify里的小队/部落关系是要经常被审视的，如果发现依赖关系的变化，那么组织重构，架构调整就可能发生。
2.3.4 同步问题的解决
如图所示，小队间的同步问题则通过发布火车和特性开关解决。可以看到在第一周结束发布火车开走的时候，特性A、B、C的开关是打开的，而D的开关是关掉的。这就很好地解决了小队之间如何同步协作的问题。
2.4 知识分享
Spotify的模式中，非常重视知识的分享与传播，所以在它的组织结构中，4个类型的组织中有2个用来协助员工的成长和知识分享。
- 在分会（Chapter）里定期的聚会以便于拥有同一种技能的同事讨论专业知识以及遇到的挑战，并分享遇到的问题，减少重复劳动，提高效率。
- 而行会（Guild）则给跨部落的相同兴趣的人提供了另外一种交流社区。
在其他的规模化敏捷框架中，当然我们可以用各种方式进行知识分享。不过没有任何一个跟Spotify一样如此重视。这也符合Spotify从实践中演进的原则。
2.5 自由独立
2.5.1 异花授粉
对于Spotify来说，一个Squad就是一个迷你创业公司，他们享有很大的自由度，比如自己选择的工作方式，所使用的的工程实践，甚至自己可以决定设计和发布等。
不管是SAFe还是LeSS，都遵循一个被完整设计出来的框架和流程，但Spotify不是。
他们通过如图所示的异花授粉的方式来尽可能减少流程标准化。一旦一些Squad实施了很好的实践，就会被其它更多的Squad学习，从而取得一致性和灵活性的平衡。
2.5.2 解耦发布
对于产品来说，Spotify有100多个独立的系统，每个Sqaud都工作在平台的一个特定部分，并对自己的发布频率负责。但Squad之间也会互相帮助以对齐产品级的进度。
2.6 合作和对齐
2.6.1 规模化敏捷比较
SAFe设计了PI Planning，最多150人，由RTE来引导，通常是对一个ART关于5个Sprint中的4个正常的开发Sprint的范围作计划。
LeSS设计了Product Backlog Refinement ，最多50人，由PO来引导，1次计划一个团队的Backlog。
而Spotify则基本上保持每个Squad自己独立的Backlog，然后在必要的时候通过Scrum of Scrums来进行Team间的合作。
2.6.2 POTLAC
这三个角色分别关注同一个利益体的不同角度：
- 产品经理积极地推动一个重要的新功能。
- 团队领导则更关心这个团队在现存的代码库中已经欠下了堆积如山的技术债所带来的挫败感。
- 敏捷教练认为团队需要停下来更加频繁地去思考，去反思如何提高自己的价值。
他们一旦倾听彼此的心声，目标一致性的问题就会得到解决。每周同步（半小时），重要会议前快速交流并同步信息，定期一对一（不一定是正式沟通），模拟会议。这是4个POTLAC最重要的协作方式。
2.7 规模化敏捷的融合-- 法国Axa的敏捷转型
Axa是一个Spotify模型，不过添加了Spotify模型中不存在的“域”层，下面是它的组织结构：
组织结构是Spotify，但非常有趣的是敏捷实践更接近于SAFe。
从这里我们可以看到所有的规模化敏捷框架并没有高下之分，也并非非此即彼。在进行敏捷实践落地的时候，需要根据自己组织的实际情况出发，选择一个或者结合其中的不同的框架来设计符合自己公司的框架来进行实施。
无论选用哪种规模化敏捷框架，本质上是解决需求、版本对齐的问题，并建立各自特色的机制。
本文来源于DevOps案例深度研究第4期 – Spotify DevOps实践研究战队。
第4期DevOps案例深度研究交付包括《青春不老-B站持续交付案例分析》、《中国速度-火神山雷神山建设》、《“京”益敏捷-京东案例分析研究》、《自由的乐章-Spotify协奏曲》。
＋“CH050791”回“案例研究”，可获得全部视频~
閱讀更多 國際DevOps教練聯合會 的文章
