189 8069 5689
背景介绍
关于介绍 Spotify 的文章和相关材料，搜索引擎里搜索一下其实还是很多的， 那笔者为什么还要老生常谈，再和大家聊一聊这个话题呢，其实更多的是基于实践中的一些感慨，因为笔者正好在一家基于 Spotify 框架基础上尝试敏捷规模化的公司工作过，也看到了这个模式带来的改变，但更感慨的则是一些形似神不似的“假敏捷”。
公司面临的现状是外包人员比例较高，这无疑增加了管理的复杂性，而同时有一定的存量系统需要进行重构和下线，加上为了满足市场需求，又要不断进行产品更新迭代；管理难度高、重构任务重、市场竞争大，成了摆在团队面前的三大难题，而最明显的体现就是资源争抢，业务团队希望尽快满足需求、交付价值，技术团队要兼顾重构和偿还技术债务的任务。这样的背景之下，公司决定借鉴 Spotify 的典型实践，尝试改变现状。Spotify组织形式
关于 Spotify 这家公司的背景介绍，这里就不再赘述了，我们直接进入主题， 聊一聊 Spotify 的典型实践和组织架构。
首先，笔者所在的公司希望借鉴 Spotify 的组织形式，第一步就是尝试改变团队结构，进行“小队化”，“部落化”， 这里有必要解释下所谓的小队和部落，Spotify 框架里最小的组织单元是 squad， 我们管它叫做小队，小队基本上可以理解为 Scrum 中的敏捷团队，包括了 PO、 Scrum Master 和 Team，我们期望这样的形式可以做到资源对齐，每一个业务领域都有部落与之对应，资源边界更加清晰，沟通更加顺畅，小队本身的特点可以概括为三个方面：
而部落的概念是多个小队的集合，之所以把他们定义为部落，是因为他们之前存在一定的关联，比如：都交付某一个业务领域的特性；有部落就有部落长， 我们叫他酋长，他是这个大团队队的负责人，需要为团队提供支持和指导。
那回到公司部落化的话题上来，首先公司组织了培训工作，对核心成员做了培训，说明了什么是部落化，部落化能帮我们解决什么问题，比如：部落化能让产品和研发变为“一根绳上的蚂蚱”，部落化能解决资源争抢的现状，培训后大家对这个模式充满期待，但是似乎漏掉了什么？部落化固然好，但是它一定是建立在敏捷基础之上的，而被培训者有多少人真正理解了敏捷的精髓，敏捷宣言重点强调的又是什么？是不写文档吗？还是不需要制定计划？先不管，规模化的步伐已经迈出了。既然纵向做了部落化，就要谈到 Spotify 的横向拉通了，Spotify 中有分会和协会的概念，分会主要是基于角色或职能的，比如测试分会，虽然测试人员已经划分到了不同的小队和部落，但是横向他们依然属于一个分会，分会也有负责人， 比如测试分会的负责人就类似传统架构的测试经理，区别是分会负责人不会有过重的管理职能，更多的是赋能、输送血液，他要招聘新成员、要不断利用各种手 段提高测试人员的能力水平。好的，又有问题了，测试人员该向谁汇报，绩效谁来评？而协会的概念更多的是基于兴趣的小组，比如 Python 协会，管你是 java 开发还是性能测试工程师，只要你感兴趣就可以参与，笔者认为这是很好的实践， 因为大家需要有机会去学习感兴趣的东西，去接触不同的朋友，长期来看这也是团队建设的好手段。但是这个层级在公司的实践中，似乎被抛弃了。并没有兴趣小组，因为大家要把全部的精力放在完成功能交付上。
所以这也引出了 Spotify 很重要的一种文化，创新文化，Spotify 是非常鼓励创新的，他们可以在每个迭代留时间做创新尝试，甚至用一个完整的迭代来做创新活动，而我们并没有考虑过创新，原因就是需求太多，工作太忙。这恰好类似下方的这幅图展示的含义：一位朋友在路灯下找钥匙，别人会问你为什么只在这里找，你确定是掉落在这里吗？他说不确定，但是这里有光，我能看得到，而我们难道不也是这样吗？我们关注的都是看得到的地方，那我们永远被限定在了这里，我们忙于日常交付似乎永远没有时间创新，但当你试着将目光放的更远时， 可能答案就在那里等着你。
我们的尝试
Spotify 的核心价值观是：创新、激情、真诚、协作、好玩，如果只是简单的做部落化而不考虑背后的价值观，那一点都不好玩。所以笔者写这些内容并不是为了吐槽公司做得有多不好，而是把这个反模式写出来，如果您的公司恰好也希望借鉴Spotify，那请先想好什么是重点。而我们发现这些问题后，也在努力解决这些问题。首先，我们开始试着让敏捷开始开花结果，我们开始做培训，不只是针对领导层，也不只是针对核心骨干，而是全员，我们期望大家理解敏捷的核心思想， 我们通过看板做可视化，通过各种各样的信息辐射源促进透明，我们做兴趣社区，做敏捷交流小组，我们尝试多种方法开好回顾会，同时公司层面也开始推动 DevOps 落地。我们期望发布更容易，这样就可以实现频繁的发布，发布的规模也会变的很小，这样我们就更容易发布，也就形成了良性的循环。但是当我们不断的追求快速交付价值的过程中，却逐渐的忽略了质量，我们 开始发现质量下降，我们开始不断的救火，所以我们很快进入了第二个阶段提高质量。提高质量似乎比快速迭代更难，我们从很多细小的点出发，我们梳理 DOR， 明确 DOD，我们开始推动结对代码评审（因为结对编程领导不认可，只能退一步海阔天空），我们开始考虑测试左移。大家都明白，大部分的缺陷是在开发阶段引入的，但是大部分缺陷是在测试阶段的后期才被发现，甚至是在版本发布之后，而随着时间的推移修复的成本成指数级增长，所以我们期望尽早发现缺陷， 我们开始提高单元测试覆盖率，我们开始推动团队做重构，以求得到更好的设计。我们也考虑测试右移，接入了更好的线上监控工具，开始做灰度发布，质量提升的工作还在不断尝试，整个组织也在不断成长。
还有很多话没有说
这篇文章只是个引子，我期望后续把更多更具体的实践、做法和经验分享出 来，透过全文，大家可以发现我对 Spotify 的介绍并不多，而更多的是说明我们在参考 Spotify 转型后，所面临的问题和应对措施，其实各种公司转型都一样， 任何一种框架模仿起来都很简单，哪怕 SAFe 这个大家都觉得比较复杂的框架， 花些时间和精力，再请高人做下指点，也能模仿个七七八八，但是这似乎都不是重点，重点的是文化的转变，兵马未动粮草先行，转型未动文化先行，我们虽然没有做到文化先行，但总归还是打破了组织重力，改变了组织文化，所以走到现在，我们对后续的路更充满期待，我们不期望到达一个完美的终点，我们要做的是持续改进。路还很长，似乎这个过程比结果更有趣。
