Spotify的大规模敏捷之路

　　多个团队一同从事产品开发真是一项挑战！

　　到目前为止，我们见过的最令人印象深刻的案例之一，就是 Spotify 公司：尽管 Spotify 拥有 30 多个团队，位于 3 个不同的城市，但他们仍然保持着敏捷开发的思维。

　　Spotify 是一家非常吸引人的公司，它改变了整个音乐产业。虽然这家公司从成立到现在只有 6 年，却已经拥有 1500 万活跃用户以及 400 万付费用户。该公司的产品可以被誉为是“一个神奇的音乐播放器，可以让你瞬间找到、播放世界上任何一首歌曲”。

　　Alistair Cockburn（敏捷软件开发创始人之一）在参观 Spotify 时曾说道：“太棒了！我从1992 年开始就一直希望有人能够实现这套矩阵式组织结构的设计（参考上图），很高兴今天我看到了”。

　　那么这一切是怎么做到的呢？

　　我们俩在会议演讲中、在各种讨论中多次提到我们在 Spotify 如何工作、这家公司如何在数百名开发人员中运用敏捷，很多人对这个话题很感兴趣，所以我们决定以此为题写一篇文章。

　　声明：

　　文中提到的模型不是我们发明的。 Spotify，和其他优秀的敏捷型公司一样，处于高速地发展中。这篇文章只是我们当前工作方式的缩影。我们的敏捷旅程仍在进行中，并未结束。我们估计，当您读到这篇文章的时候，很多事情已经发生变化了。

　　分队（Squads）

　　分队是 Spotify 的最小开发单位。

　　一个分队类似于一个 Scrum 团队，也很像一家迷你型创业公司。分队中的成员坐在一起，他们具备设计、开发、测试和产品发布所必需的全部技能和工具。一个分队是一个自组织团队、决定自己的工作方式——有的分队使用 Scrum 中的迭代（Sprint），有的分队使用看板（Kanban），还有的综合使用上述方法。

　　每个分队都会有一个长期的使命，比如：开发和优化 Android 客户端、打造 Spotify 广播功能的用户体验、扩展后台系统、提供支付解决方案，等等。如下图所示，不同分队负责用户体验的不同部分。

　　Spotify 鼓励每个分队都运用精益创业原则，比如 MVP（Minimum Viable Product，最小可行产品）和验证性学习（Validated Learning）等。MVP 意味着尽早地、频繁地发布； 验证性学习意味着使用度量（Metrics）和 A/B 测试（A/B tesing）来确认什么可行，什么不行。用一条标语来总结的话，就是：“思考、构建、交付、调整（Think it， Build it， Ship it， Tweak it）”。

　　由于一个分队长期持续地从事某一类任务以及开发产品的某一个部分，所以分队成员逐渐都成为了该领域的专家——比如，如何打造非常棒的广播体验。

　　大部分的分队都拥有非常棒的工作环境：办公区、休息区、个人杂物室、几乎所有的墙都是白板……，我们从未见过比这儿更好的工作空间！