标签：spotify 部落 再谈 小队 规模化 敏捷 团队 我们

•  背景介绍

关于介绍spotify的文章和相关材料，搜索引擎里搜索一下其实还是很多的，那笔者为什么还要老生常谈，再和大家聊一聊这个话题呢，其实更多的是基于实践中的一些感慨，因为笔者正好在一家基于spotify框架基础上尝试敏捷规模化的公司工作过，也看到了这个模式带来的改变，但更感慨的则是一些形似神不似的“伪敏捷”。公司面临的现状是外包人员比例较高，这无疑增加来了管理的复杂性，而同时有一定的存量系统需要进行重构和下线，加上为了满足市场需求，又要不断的进行产品更新迭代；管理难度高、重构任务重、市场竞争大，成了摆在团队面前的三大难题，而最明显的体现就是资源争抢，业务团队希望尽快满足需求、交付价值，技术团队要兼顾重构和偿还技术债务的任务。这样的背景之下，公司决定借鉴spotify的典型实践，尝试改变现状。

•  Spotify组织形式

关于spotify这家公司的背景介绍，这里就不再赘述了，我们直接进入主题，聊一聊spotify的典型实践和组织架构。首先，笔者所在的公司希望借鉴spotify的组织形式，第一步就是尝试改变团队结构，进行“小队化”，“部落化”，这里有必要解释下所谓的小队和部落，spotify框架里最小的组织单元是squad，我们管它叫做小队，小队基本上可以理解为scrum中的敏捷团队，包括了PO、ScrumMaster和Team，我们期望这样的形式可以做到资源对齐，每一个业务领域都有部落与之对应，资源边界更加清晰，沟通更加顺畅，小队本身的特点可以概括为三个方面：

• 稳定
• 自组织
• 特性团队

所谓稳定是期望团队不要有大的变动，因为根据塔克曼模型，每一个团队都要经历从组建、震荡、规范、成熟和解散的几个阶段，如果一个团队一直无法保持稳定，团队成员来来去去，那可能团队永远处于磨合期，这时再谈文化建设、敏捷转型、高效合作、学习型组织这样的话题，似乎都没有意义，因为你没有这一切的基础-稳定的团队；而自组织又是一个“好说不好做”的话题，至于特性团队，我们希望每一个小队都是能够独立交付特性的，客户的需求提出后，小队可以给客户一个满意的答案，功能需是完整的最重要是有价值的，而相对应的团队形式就是交付某一个组件，对客户来说这个组件没有价值，因为它不能解决任何问题，而要想得到完整的产品特性，要依靠多个团队的协作，这种团队即组件团队。                           
而部落的概念是多个小队的集合，之所以把他们定义为部落，是因为他们之前存在一定的关联，比如：都交付某一个业务领域的特性；有部落就有部落长，我们叫他酋长，他是这个大团队队的负责人，需要为团队提供支持和指导。

那回到公司部落化的话题上来，首先公司组织了培训工作，对核心成员做了培训，说明了什么是部落化，部落化能帮我们解决什么问题，比如：部落化能让产品和研发变为“一根绳上的蚂蚱”，部落化能解决资源争抢的现状，培训后大家对这个模式充满期待，但是似乎漏掉了什么？部落化固然好，但是它一定是建立在敏捷基础之上的，而被培训者有多少人真正理解了敏捷的精髓，敏捷宣言重点强调的又是什么？是不写文档吗？还是不需要制定计划？先不管，规模化的步伐已经迈出了。既然纵向做了部落化，就要谈到spotify的横向拉通了，spotify中有分会和协会的概念，分会主要是基于角色或职能的，比如测试分会，虽然测试人员已经划分到了不同的小队和部落，但是横向他们依然属于一个分会，分会也有负责人，比如测试分会的负责人就类似传统架构的测试经理，区别是分会负责人不会有过重的管理职能，更多的是赋能、输送血液，他要招聘新成员、要不断利用各种手段提高测试人员的能力水平，好的，又有问题了，测试人员该向谁汇报，绩效谁来评？而协会的概念更多的是基于兴趣的小组，比如Python协会，管你是java开发还是性能测试工程师，只要你感兴趣就可以参与，笔者认为这是很好的实践，因为大家需要有机会去学习感兴趣的东西，去接触不同的朋友，长期来看这也是团队建设的好手段。但是这个层级在公司的实践中，似乎被抛弃了。并没有兴趣小组，因为大家要把全部的精力放在完成功能交付上。

所以这也引出了spotify很重要的一种文化，创新文化，spotify是非常鼓励创新的，他们可以在每个迭代留时间做创新尝试，甚至用一个完整的迭代来做创新活动，而我们并没有考虑过创新，原因就是需求太多，工作太忙。这恰好类似下方的这幅图展示的含义：一位朋友在路灯下找钥匙，别人会问你为什么只在这里找，你确定是掉落在这里吗？他说不确定，但是这里有光，我能看得到，而我们难道不也是这样吗？我们关注的都是看得到的地方，那我们永远被限定在了这里，我们忙于日常交付似乎永远没有时间创新，但当你试着将目光放的更远时，可能答案就在那里等着你。

•  我们的尝试

Spotify的核心价值观是：创新、激情、真诚、协作、好玩，如果只是简单的做部落化而不考虑背后的价值观，那一点都不好玩。所以笔者写这些内容并不是为了吐槽公司做的有多不好，而是把这个反模式写出来，如果您的公司恰好也希望借鉴spotify，那请先想好什么是重点。而我们发现这些问题后，也在努力解决这些问题。首先，我们开始试着让敏捷开始开花结果，我们开始做培训，不只是针对领导层，也不只是针对核心骨干，而是全员，我们期望大家理解敏捷的核心思想，我们通过看板做可视化，通过各种各样的信息辐射源促进透明，我们做兴趣社区，做敏捷交流小组，我们尝试多种方法开好回顾会，同时公司层面也开始推动DevOps落地。我们期望发布更容易，这样就可以实现频繁的发布，发布的规模也会变的很小，这样我们就更容易发布，也就形成了良性的循环。但是当我们不断的追求快速交付价值的过程中，却逐渐的忽略了质量，我们开始发现质量下降，我们开始不断的救火，所以我们很快进入了第二个阶段提高质量。提高质量似乎比快速迭代更难，我们从很多细小的点出发，我们梳理DOR，明确DOD，我们开始推动结对代码评审（因为结对编程领导不认可，只能退一步海阔天空），我们开始考虑测试左移。大家都明白，大部分的缺陷是在开发阶段引入的，但是大部分缺陷是在测试阶段的后期才被发现，甚至是在版本发布之后，而随着时间的推移修复的成本成指数级增长，所以我们期望尽早发现缺陷，我们开始提高单元测试覆盖率，我们开始推动团队做重构，以求得到更好的设计。我们也考虑测试右移，接入了更好的线上监控工具，开始做灰度发布，质量提升的工作还在不断尝试，整个组织也在不断成长。

•  还有很多话没有说

这篇文章只是个引子，我期望后续把更多更具体的实践、做法和经验分享出来，透过全文，大家可以发现我对spotify的介绍并不多，而更多的是说明我们在参考spotify转型后，所面临的问题和应对措施，其实各种公司转型都一样，任何一种框架模仿起来都很简单，哪怕SAFe这个大家都觉得比较复杂的框架，花些时间和精力，再请高人做下指点，也能模仿个七七八八，但是这似乎都不是重点，重点的是文化的转变，兵马未动粮草先行，转型未动文化先行，我们虽然没有做到文化先行，但总归还是打破了组织重力，改变了组织文化，所以走到现在，我们对后续的路更充满期待，我们不期望到达一个完美的终点，我们要做的是持续改进。路还很长，似乎这个过程比结果更有趣。

标签：spotify,部落,再谈,小队,规模化,敏捷,团队,我们
来源： https://blog.51cto.com/13676635/2589467

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。