Spotify是成功的历史。 最初是斯德哥尔摩的一家初创公司，现在在音乐行业中扮演着重要角色。
小队：
- 王子，Spotify Streams和目录难题
- Kano x Spotify –运动控制音乐
- Hackeando o Spotify-以宣传为目的！
- 元数据-音乐家的新最佳伴侣
- 您在2017年应该选择哪种音乐流媒体服务？ 苹果音乐还是Spotify？
- 与拥有产品所有者的Scrum团队非常相似。 他们没有领导者，但是产品负责人可以为任务分配优先级。 必要时，他们还可以使用敏捷教练。 他们可以直接与利益相关者接触。
- 不同小组的产品负责人进行协作，以维护高级产品路线图并消除小组之间的依赖性。
- 他们在同一地点一起工作。 通常，他们个性化共同工作的共同空间。
- 他们拥有自己设计，开发，测试和部署数字产品所需的全部技能。 他们是完全自给自足的。
- 他们可以决定使用Scrum冲刺，看板或其他任何方式来组织工作。
- 他们都有特定的任务。
- 鼓励他们应用精益创业原则，例如MVP和经过验证的学习。
- 他们将大约10％的时间用于“黑客日”活动，以促进学习和创新。
部落
部落是在相关领域工作的小队的集合。
- 他们是独立的。
- 每个部落都有一个部落领导，他为这个部落的小队提供了最佳的栖息地。
- 同一部落的小队共享相同的位置。
- 部落的成员人数不能超过100。 根据Dunbar数字概念，人们与超过100人的社交关系不可以。 这就是为什么部落规模有限的原因。
- 他们不时设置聚会，以展示每个小队的表现。
- 小队之间的依存关系在部落级别被消除。 为此，重要的是首先确定这些依赖关系：
许多公司的依赖源是开发和运营之间的摩擦。 Spotify有一种有趣的方法可以解决此问题。 他们没有由一个团队来负责运营，而是有一个运营团队为每个班组提供指导和支持，以便他们可以以独立的方式开展工作。
本章
到目前为止，我们已经看到，Spotify在不同的团队和部落之间有相当多的自治权。 这可能会导致不希望的情况，例如班A中的测试人员处理已经由班B中的另一测试人员检测到并修复的问题。
在这种情况下，最好有一个公共区域在不同班级的人们之间共享知识。
本章是一群具有相似技能并在同一部落的同一一般能力领域内工作的人。 例如，我们可以在部落A中有一章测试人员。
- 他们定期开会讨论他们的具体挑战。
- 有一个章节负责人，可以将其视为该章节的线路管理员。 但是我们希望该章负责人成为小队的常规成员。
公会
行会类似于本章，但在这种情况下，它们跨越了不同的部落。 公会是一个有兴趣的社区，一个想要分享知识的团体。
公会通常包括在该领域工作的所有章节及其成员。 例如，测试行业协会在所有测试章节中都包括所有测试人员。
- 每个公会都有一个公会协调员。
Spotify的组织方式看起来像一个矩阵组织。 但这是一个矩阵，其中垂直维度是“ what”，水平维度是“ how”，我们可以在此处看到：
这里的重点是让每个人都容易知道该怎么做以及如何去做。 这是使这种组织有意义的关键。
Spotify有100多个不同的系统，每个系统都是完全独立的。 由于每个人基本上都可以自由地在想要的任何地方进行更改，因此不同团队之间存在很大的冲突风险。
为了避免这种情况，Spotify引入了系统所有者的角色。 每个系统都有一个系统所有者（甚至更好的是，同一系统有两个系统所有者）。
系统所有者是与该系统有关的任何技术或体系结构问题的“执行者”。 通常情况下，班组成员或分会负责其他日常工作，他们只花费一部分时间来完成这项工作。
还有一个首席架构师角色 ，一个负责协调影响多个系统的高层体系结构问题的人员。
那是一百万美元的问题，而且没有一个简单的答案。 如果要使用Spotify方式，我们需要解决许多障碍：
- 遵循近海-近海方法，在现代化的IT公司中，要建立一个团队（一个独立的团队，自我授权，在同一地点一起工作）并不容易。
- 我们很难让利益相关者获得这种模式以使其能够按要求工作的访问方式。
- 团队成员和系统所有者之间不应存在任何障碍。
- 如果我们希望模型能够按预期工作，那么我们就需要在架构问题上取得重大进展。
- 花费一部分时间用于创新目的有时是一件非常复杂的事情。
- 要使此模型正常工作，几乎必须删除依赖项，而这并非易事。
- 在高度分层的组织中，这种方法的实施可能会遇到一些阻力。
Spotify使用的敏捷缩放方法的好处是非常简单且易于实现。 实际上，这比当今许多人认为的其他缩放方法（如SAFE，DAD或LESS）要容易得多。
问题在于，我们公司需要以这种方式工作的结构并不总是容易实现的。
然后，我们将其作为一个很好的起点，但是在处理公司的敏捷扩展问题时，我们永远不要忘记考虑我们的具体情况。
