Spotify 的大规模敏捷：采访 Henrik Kniberg

去年 11 月，Spotify 发布了一份题为“ Spotify 的部落、小队、分会和公会式的大规模敏捷”的论文。我最近有机会和 Henrik Kniberg 进行交流，他是 Spotify 的现场敏捷教练之一，我问了他一些问题，并了解到了他们目前的一些新情况。

InfoQ：关于你们曾经的做法无法实现大规模敏捷这一点，有没有什么初步征兆？能否列举一些痛点？

Henrik Kniberg：我们无法得到我们想要的生产率，而且组织中的成员普遍流露出沮丧的情绪。例如，分会会长因过多的直接报告而疲于奔命，所以很难抽出时间进行 1 对 1 的会议、积极的指导或教练辅导工作。

InfoQ：对于如何实现大规模敏捷，哪些人参与了早期的决策制定？他们在组织中的角色是什么？

Henrik Kniberg：基本上是技术和产品的高级领导们先一起理出头绪来。然后，我们去组织中寻求反馈和灵感。这并不是一个很大的改造重制，而更像是对我们的组织和过程进行源源不断的小迭代改进。我们已经连续 3 年增长，我们如今的工作方式也已经随着时间推移自然地进化。

InfoQ：是什么促使你采取这种方法，而不是使用现有的大规模敏捷方法比如 Scaled Agile Framework（大规模敏捷框架）或者 Disciplined Agile Delivery（守纪敏捷交付）等方法？

Henrik Kniberg：我们是敏捷和精益原则与原理的超级粉丝，但我们并没有紧密地依附于任何特定的一套做法或方法。我们只是想在一种能够很好地适应我们的文化和环境的方式下工作。

自治是我们的指导原则之一。我们的目标是独立的小队，每个小队都能创建和发布自己的产品，而且这些小队无需在一个大的敏捷框架下紧密协调。我们尽量避免共有的大型项目（当我们可以时），从而尽可能地降低跨多个小队进行协调工作的需要。

InfoQ：你曾提及你们在 3 个城市中有 30 个小队。所有小队的小队成员都处于同一地点吗？或者有的小队的成员是分布在不同的城市中的？

Henrik Kniberg：绝大多数的情况下，小队和部落的成员位于同一地点。也就是说，一个小队的所有成员通常都是在同一个房间，而且一个部落中的所有小队通常是在同一个办公室中彼此相邻。我们是有意地组织成了这样。我们尤其渴望能够确保 Product Owner 和小队在同一个位置和房间。此时此刻我只能想起来一只不在同一地点工作的小队。

InfoQ：我注意到被展示的工具仅有易贴纸和电子表格。Spotify 是否使用一些现有的敏捷工具以协调工作？如果没有，为什么不使用？

Henrik Kniberg：我们使用多种工具的组合，并不断就此试验。目前最常用的协调工具是墙壁上的易贴纸、谷歌电子表格和 Jira。我们也有用到一点点的 Trello 和 LeanKit 看板。

我们鼓励知识共享和传播最佳实践，但是每个小队和部落都可以自行选择任何能够使他们快乐高效地工作的工具软件。为了避免大型的项目，我们同样尽可能地降低了统一我们工具选择的需求。

InfoQ：您还展示了一些“小队”可能各自拥有某个产品的一部分（见下图），这个问题是如何处理的？产品整体风格的统一又是怎样处理的？（还有代码归属问题）。

Henrik Kniberg：对于我们被组织的方式而言，技术架构是非常重要的。组织结构必须和技术架构和谐地工作在一起。许多企业不能使用我们的工作方式正是因为他们的架构不允许。

我们花费了很大精力去寻求一种能够支持我们工作方式的技术架构（而不是根据一个确定的架构去调整我们的工作方式）；其结果是我们有了一个由众多组件和应用程序构成的紧密的生态系统，每一个组件或应用程序都可以独立运行和演进。而生态系统的整体演进是由强有力的架构愿景所指导的。

我们通过让高级产品经理和小队、产品负责人还有设计师们密切合作以保持产品设计的风格统一。这种协调有时是很棘手的，这也是我们面临的主要挑战之一。设计师们直接与小队一起工作，但是同时也需要花至少 20％的时间与其他设计师一起工作，以保持产品整体设计的一致性。

InfoQ：下图似乎表明了大量的依赖关系，包括将 UX 作为一支独立的团队。如何处理这些依赖关系？

Henrik Kniberg：依赖是我们所面临的挑战之一；依赖关系越多，我们的效率就变得越低。

例如， UX 过去主要是独立的小组，这就导致了依赖问题（正如上文提到的我们的依赖关系可视化电子表格所示）。目前开发和 UX 大多集成在一个小队里，从而降低了这种依赖关系问题。这是依赖关系降低策略的一个例子。

还有一些我们使用的其它降低依赖关系的策略:

1. 决定把依赖关系放在何处。例如，我们故意设置了一条从功能特性小队到基础架构小队的依赖关系。这是可管理的，因为基础架构小队的交付时间通常更具可预见的。我们试图变得善于管理依赖关系，而不是试图消除依赖关系。
2. 不要守株待兔，自己动手解决问题。我们采用开源模式，因此一个小队可以按照他们的需要对另一个小队的代码进行修改，这种修改通常和当面交流及代码审查结合在一起使用。
3. 分享知识。有时依赖关系问题是由于缺乏知识导致的。这可以通过内部技术讲座、去另一个小队“实习”并向他们学习、在合理的情况下轮换小队的职责来解决。
4. 持续性的依赖问题有时可以通过分割、组合、重整小队加以解决。

InfoQ：在论文发表后有任何重大变动或更新吗？

Henrik Kniberg：我们在持续增长，因此变化也是持续性的。

很重要的一步是我们已经开始变得对我们的产品开发过程更加清晰，请参阅 How Spotify builds products （Spotify 是如何构建产品的）和“思考 - 构建 - 发布 - 调整”框架。对于精益创业的原则，我们在应用时也变得更加有意识了，比如尽早提供 MVP（最低可行产品），以及采用可测量的假定条件推动产品开发。在发布 MVP 给少量用户并从实际使用指标中学习这一点上，我们现在做得好多了。因此在我们构建产品的同时，我们也得到了真实用户的反馈并能够在此基础上调整优先级。

InfoQ：在你看来，目前你最大的挑战是什么？

Henrik Kniberg：我们当前面临的挑战有：

• 小队依赖——如何最大限度地减少不必要的依赖关系，优化必要的依赖关系。随着公司的成长，这始终会是一个挑战。
• 如何平衡组织重点（所有小队都应朝同一方向前进）和小队自制 (小队可以选择自己的前进方向)。
• 如何使设计和开发集成得更紧密
• 如何在公司成长的同时避免运营瓶颈，并允许小队在大量生产中持续部署和试验。
• 如何应对涉及数十个小队间协同工作的“大型项目”
• 当有许多不同的小队各自为战却又是为了同一个产品时，如何保持产品的设计风格是统一的。

查看英文原文： Scaling Agile At Spotify: An Interview with Henrik Kniberg

感谢杨赛对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。