点击围观!腾讯 TAPD 助力金融行业研发提效、敏捷转型最佳实践! 了解详情
写点什么

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

  • 2013-06-06
  • 本文字数:2664 字

    阅读完需:约 9 分钟

去年 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 )关注我们,并与我们的编辑和其他读者朋友交流。

2013-06-06 06:311790

评论

发布
暂无评论
发现更多内容

华为 HarmonyOS 正式发布!你还认为鸿蒙只是安卓套壳吗?

北游学Java

鸿蒙

蓝海战略 - 如何设计与众不同的价值曲线

石云升

战略思考 职场经验 6月日更

【干货篇】bilibili:基于 Flink 的机器学习工作流平台在 b 站的应用

Apache Flink

flink

拍乐云推出业内首个「线上美术教学音视频方案」,打造极致互动体验

拍乐云Pano

defi流动性系统开发案例详情丨defi流动性源码功能

系统开发咨询1357O98O718

龙蜥专场精彩回放来了!10位技术大咖、242位开发者相聚

阿里云基础软件团队

☕️【Java 技术之旅】知识盲点关于jar包的点点滴滴

洛神灬殇

Java jar Jar包扫描 6月日更

阿里P8熬了一个月肝出这份32W字Java面试手册,在Github标星68K+

Java 程序员 面试

你想进大厂吗?阿里Java面试“内幕”分享

Java架构师迁哥

反洗钱监管再度升级,看这家金融集团如何应对

索信达控股

大数据 银行 金融监管 风险管理 数据管理

Flink 在有赞的实践和应用

Apache Flink

flink

python使用命令行传入参数

卤蛋翔

6月日更

拍乐云受邀QCon大会 | 详解音视频技术架构实践,首发美术教学音视频方案

拍乐云Pano

2021金三银四面试经历:腾讯三面落马+拒网易、CVTE后,字节四面成功拿下offer

Java 程序员 架构 面试

defi流动性挖矿系统开发(案例版)丨defi流动性挖矿源码现成版

系统开发咨询1357O98O718

无刷电机与有刷电机的区别

不脱发的程序猿

无刷电机 有刷电机 电机

Consul场景用例:服务注册(Service discovery) & 服务网格(Service mesh)

awen

微服务 Consul Service Mesh 服务网格 服务注册与发现 服务网格

百度搜索与推荐引擎的云原生改造

百度开发者中心

云原生

最新!GigaOm 发布 API 网关评测报告:API7 和 Kong 企业版本性能对比

API7.ai 技术团队

负载均衡 架构 云原生 后端 网关

阿里直通车?阿里Java面试“内幕”:十万字内部面试题总结

Java架构追梦

Java 阿里巴巴 架构 面试

新大陆!阿里P9整理出:Java架构师“成长笔记”共计23版块

Java架构师迁哥

牛客网亲测有效!牛客下载量近百万的Java程序员复盘秘籍真滴强

小Q

Java 学习 编程 架构 面试

【LeetCode】连续的子数组和Java题解

Albert

算法 LeetCode 6月日更

iOS上的CSS样式协议 VKCssProtocol

iOSer

CSS ios 移动开发 ios开发 VKCssProtocol

从零开始学习3D可视化之控制对象(2)

ThingJS数字孪生引擎

可视化 数据化 3D 3D可视化

defi流动性挖矿系统开发案例分析,defi流动性挖矿现成源码

系统开发咨询1357O98O718

官宣!禅道与极狐(GitLab)达成深度合作,携手推进开源开放DevOps生态发展

禅道项目管理

项目管理 DevOps gitlab

OGA 联盟正式成立!禅道作为理事单位助力共建开源生态!

禅道项目管理

项目管理 DevOps gitlab

联邦计算在百度观星盘的实践

百度Geek说

大数据好书推荐

五分钟学大数据

23种设计模式,正确的解读方式原来是这样

Java架构师迁哥

Spotify的大规模敏捷:采访Henrik Kniberg_敏捷_Todd Charron_InfoQ精选文章