Spotify敏捷模式详解三部曲第一篇：研发团队

 

本文转自：Scrum中文网

引言

2018年4月，来自北欧瑞典的音乐流媒体公司、百亿美圆独角兽Spotify创造了历史，它成为了当代上市公司当中，第一家经过“直接上市”的方式在美国纽交所成功挂牌的公司。这家公司改变的可能不只是人们听音乐的习惯，并且还有企业进入资本市场的方式。截至2018年初，Spotify拥有1.59亿的全球活跃用户数量、7000万的付费用户数和46%的付费用户增加率。Spotify是当之无愧的音乐流媒体领域的霸主，排名第二的苹果音乐，不管是付费用户仍是活跃用户，都只有Spotify的一半。

是什么成就了Spotify？他们是如何打造出这么一款深受用户喜好的产品的？幸运的是有Henrik Kniberg的存在。Henrik Kniberg是全球知名的敏捷和精益教练，也是一位多产的做家，他参与了Spotify公司的这一过程，并写下了多篇文章，向外界揭开了Spotify公司的神秘面纱。

笔者经过本身的收集和整理，梳理出了Spotify敏捷模式的整个过程，并经过一系列的文章呈现给你们。在本期的文章中，笔者将首先介绍Spotify的研发团队。

组织架构

Spotify采用的是一种很是独特的组织架构，以下图所示：

整个研发组织有多个称为“Tribe部落”的单元组成，每一个部落中包括多个“Squad小队”，从横向的维度把拥有相似技能的人放在一块儿造成“Chapter分会”和“Guild协会”。

Squad（小队）

组织定位：

• 相似于一个高度自治的、迷你的“创业公司”。

• 肩负一个长期的使命，长期从事某一类任务或者开发产品的某一个部分。例如：

1）功能特性小队：专一于某块功能特性，例如搜索功能。

2）客户端APP小队：专一于使特定的客户端平台更容易发布，例如：iOS、Android.（注意：他们不进行业务特性开发）。

3）基础设施小队，专一于让其余小队更有效率，提供工具和例行事物，例如：持续交付、A/B测试，监控和运维。

团队成员：

• 不存在官方任命的团队领导。

• 有一位产品负责人（Product Owner）。

1） 各小队的产品负责人紧密合做，共同维护一个宏观的产品路线图（Roadmap），指引整个 Spotify 公司的产品发展方向。

2） 每一个产品负责人也分别维护一个本身所在小队的产品待办列表（Product Backlog）。

• 可能会有一位敏捷教练（Agile Coach），帮助团队改进工做方式。

• 具有开发产品须要的全部知识和技能，例如设计、开发、测试、发布等。

• 一般少于8我的。

工做方式：

• 坐在一块儿工做。

• 自组织管理本身的工做。

• 定义和改进本身的工做流程。

办公环境

Tribe（部落）

组织定位：

• 在相关领域工做的多个小队的集合，例如音乐播放器、后台基础架构等等。

• 能够当作是迷你创业小队的“孵化器”。

团队成员：

• 每一个部落有一名酋长，他负责为部落内的各小队提供最好的栖息地（Habitat）。

• 部落规模大小基于“邓巴数（Dunbar Number）理论”而定（小于100人）。

工做方式：

• 一个部落中的全部小队在同一个办公地点工做，一般各小队的办公区是彼此相邻的，办公区附近的休息区能促进了小队间的交流与合做。

• 会按期在部落内开展非正式的聚会，在聚会上相互展现本身正在作什么、已交付了什么、其余人能从本身正在进行的事项中获得什么经验教训。展现内容包括能工做的软件、新工具与新技术、很是酷的黑客日/黑客周项目……

“邓巴数理论”：即150定律，由英国牛津大学的人类学家Robin Dunbar在1990s年代提出。

该定律认为：人类智力容许人类拥有稳定社交网络的人数是148人（四舍五入为150）。Spotify认为在超过 100 人的组织中，大部分人很难维持稳固的社会关系。当一个组织变得过大后，咱们就会开始看到限制性的规定、官僚主义、政治斗争、冗余的管理层级，以及其余各类浪费。

组织对小队的支持

每一个季度，组织会对每一个小队作一次调查，以肯定小队须要在哪些方面改善以及须要在组织层面提供哪些支持。

 

各个调查项的评判参考标准：

1. 产品负责人（Product Owner）——小队内是否有专职的产品负责人对任务的优先级进行排序？排序时，产品负责人是否可以综合考虑商业价值和技术因素？
2. 敏捷教练（Agile Coach）——小队是否有敏捷教练帮助团队识别障碍、指导团队进行持续地过程改进。
3. 支配本身的工做（Influencing Work）——小队内的每一个成员均可以支配本身的工做？能够积极参与制定工做计划？能够选择本身作什么任务？每一个成员是否均可以把本身 10%的工做时间投入到黑客时间？
4. 容易发布（Easy to Release）——小队是否能够（而且确实作到）轻松发布产品，而不须要不少的争论和同步？
5. 合适的流程（Process that fits the team）——小队拥有本身的工做流程而且持续对其进行改进？
6. 使命（Mission）——小队是否有一个小队全部人都知晓并关注的使命？产品待办项中的故事是否都与此使命息息相关？
7. 组织级支持（Organizational Support）——小队是否知晓该从何处寻求解决问题所需的支持，不管是技术问题，仍是“软”问题（“soft” issues）？

管理小队间依赖

核心思想：

• 依赖就意味着堵塞和等待。

• 要尽可能减小小队间的依赖项。

实践方法：

1. 常常对小队进行依赖调查：大家的工做依赖于哪些小队？这些依赖是否阻塞或拖慢了大家的工做？严重到了什么程度？
2. 基于调查结果，讨论如何消除有问题的依赖，特别是引发了工做阻塞的以及跨部落的依赖关系。为了消除这些有问题的依赖，常常会调整任务优先级、团队组成、架构或技术方案。
3. 必要时，召开SoS（Scrum of Scrums）协调会议。
4. 开发小队自行发布成果，运营小队只负责“铺路”。

 

Chapter（分会）

组织定位：

• 负责传播知识和开发工具。

• 相似于传统的职能部门。

团队成员：

• 同一个部落、相同技能领域、拥有类似技能的一些人。（技能领域，例如：例如敏捷教练，或Web开发。）

• 分会有一个领导，就是分会成员的直线经理，是一个服务式的领导，负责教导和指导分会成员的工做，执行员工发展、定薪等。

• 分会的领导，同时也是某个小队的成员，参与小队平常工做。

工做方式：

• 每一个分会按期聚会，讨论专业知识及遇到的挑战。

Guild（协会）

组织定位：

• 分享知识、工具、代码和实践。

• 轻量级的“兴趣爱好社区”。

团队成员：

• 囊括整个公司的成员，汇集和分享特定领域的知识，例如领导力，Web开发或持续交付。

• 每一个协会都有一个“协会协调人”，负责组织和协调协会的活动。

• 任何人均可以随时加入或离开协会。

工做方式：

• 每一个协会按期组织一些研讨会。

如何解决系统的总体一致性？

1. 现状&问题：

1) Spotify 的技术是高度面向服务的。

2) 一共有 100 多个独立的系统，每一个系统均可以单独地维护和部署。

3) 一般小队须要更新多个系统来完成新特性的开发。

4) 若是没人关注系统总体一致性的话，那么系统架构就会变得一团糟。

2. 解决方案：

• 系统负责人（System Owner）：每一个系统都有一个或一对系统负责人（鼓励结对）。对某些关键的运营系统，系统负责人由开发和运营结对组成（Dev-Ops Pair）—— 一我的拥有开发视角，另外一我的拥有运营视角。
  • 系统负责人负责协调和指导开发人员，以免开发人员之间的冲突。
  • 系统负责人关注于：质量、文档、技术债、稳定性、可扩展性和发布流程。
  • 系统负责人并不是专职，一般也是小队成员或分会领导，还有其余的平常工做。
  • 系统负责人会不时地执行一次“系统负责人日”，以整理一下系统。（系统负责人要在“系统负责人日”上投入的时间，不一样的系统差别较大，可是一般很多于10%。）
• 一个首席架构师，负责协调跨越多个系统的、较高层面的架构问题。
  • 评审新系统的开发工做，以免一些常见错误，并确保新系统和现有的架构设计是一致的。架构师的反馈只是建议和输入——系统设计的最终决策取决于小队。

与传统矩阵式组织的区别

传统矩阵式组织形式

1) 项目立项时，“职员”由“职能经理”从职能部门“分配”到“项目”。

2) 在项目中，“职员”由项目的“项目经理”分配任务。

3) “职员”要例行向“职能经理”进行工做的“汇报”。

4) 项目结项后，“职员”从“项目”释放，回到“职能部门”，等待分配到下一个“项目”。

• Spotify的组织形式：

1) “职员”在“小队”中“持续”工做，与小队中其余人员共同“打造”一款优秀的“产品”。

2) “分会”和“协会”为“职员”提供“服务”，分享知识、工做、代码和实践，解决如何小队成员“如何作得更好”的问题。

• Spotify的组织设计思想：

1) 采用社区（Community）来替代传统的层级式组织（Hierarchical Structure）。

2) “教授和企业家”模型：

3) 产品负责人（PO）就是“企业家”，关注于交付优秀的产品，

4) 分会领导是“教授”，关注于技术卓越。

本文是Spotify敏捷模式详解三部曲第一篇：研发团队，本系列文章的下一篇将继续介绍Spotify的研发管理过程，敬请期待。