ITPub博客

首页 > 自动化运维 > DevOps > 敏捷规模化框架的思考-再谈Spotify

敏捷规模化框架的思考-再谈Spotify

DevOps 作者:DevOps订阅号 时间:2020-06-24 08:51:42 0 删除 编辑


背景介绍



关于介绍 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 这个大家都觉得比较复杂的框架, 花些时间和精力,再请高人做下指点,也能模仿个七七八八,但是这似乎都不是重点,重点的是文化的转变,兵马未动粮草先行,转型未动文化先行,我们虽然没有做到文化先行,但总归还是打破了组织重力,改变了组织文化,所以走到现在,我们对后续的路更充满期待,我们不期望到达一个完美的终点,我们要做的是持续改进。路还很长,似乎这个过程比结果更有趣。

- 作者:杨久成 - 
IDCF FDCC认证学员。10余年工作经验,现就职于平安银行PMO团队,高级项目经理/PMP/PBA/ACP/ITIL4/DevOps Master,以程序员身份开启自己的职业生涯,之后转型做项目管理工作,早期主要做传统项目管理,后期开始接触敏捷,并开始对敏捷、DevOps以及各种新事物、新思维充满热情,现主要负责敏捷转型、研发效能改进、内训师等工作。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31558019/viewspace-2700368/,如需转载,请注明出处,否则将追究法律责任。

全部评论

注册时间:2018-10-12

  • 博文量
    34
  • 访问量
    19078