作者简介 金锐,百度 DevOps 解决方案运营总监,百度工程效能部资深敏捷教练。
笔者 2012 年做为敏捷教练入职百度,到 2018 年年底一直做为敏捷教练,在百度内部进行敏捷开发的推广,DevOps 实施工作。在工作过程中,我被频繁的问到以下几个问题:
相信这些问题也是很多企业的 IT 主管,DevOps 推动者想问的问题。今天我就根据我自己的工作经历来为大家分享一下我的理解和实践:
对于敏捷教练,好像很难有一个统一的定义。引用 CIO.COM 上一位博主的原话:
Agile coaches help train corporate teams on the agile methodology and oversee the development of agile teams to ensure effective outcomes for the organization. They are responsible for guiding teams through the implementation process and are tasked with encouraging workers and leadership to embrace the agile method. The agile coach’s ultimate goal is to arm agile teams with the right knowledge, tools and training so that they’ll be able to use agile to its full potential.
提取上一段内容里的关键词:一名敏捷教练的工作方式是通过激励一线员工和领导者的教练方式,去引导团队使用正确的知识(敏捷开发知识),工具和培训,从而激发团队的真正潜力,最终能够保证团队的有效产出。
接下来讲,在百度做一名敏捷教练是一种什么体验。下面这张图是我在描述自己工作的时候经常使用的一张图:
充电: 获取知识:
对于一名百度敏捷教练来说,不断的吸收新的业界知识无疑是非常重要的,扎实的理论知识是我们在产品线开展工作的重要基础。
重要的是,只了解敏捷开发是不够的,我们在产品线里面临的是各种各样的角色协作,研发效率,工具甚至技术上的问题。这就要求我们首先
接下来,我们需要在自己擅长的领域建立一个完整的知识体系:
我们说 scrum、kanban、SAFe 这些敏捷开发框架是一个个的知识点,填充了产品研发过程中开发,测试,到发布阶段的管理实践。向前到用户诉求的挖掘,向后到服务上线后效果的分析,我们又需要掌握客户开发,创新思维,数据分析的知识,这样串联起来形成了一个知识面;这样还不够,我们还需要深入到开发,测试,运维的体系去了解工程实践,诸如代码重构,单元测试,持续交付,自动化测试等 DevOps 领域的知识,在现在的云原生时代,我们还需要去了解云,容器,集群等基础设施的知识,这样才形成了一个知识体系。
这个体系包括了从企业 IT 基础设施,到技术栈,到产品研发生命周期的管理实践,工程实践的知识。唯有这样,我们才能从容面对产品线复杂的情况。
基于上述的原因,我们在百度内部叫做软件工程方法团队— Software Engineering Team, 简称 SET。我们的定位是软件工程领域的知识和实践专家,而并非单纯的敏捷开发专家。
赋能: 体现价值:
上面这张图的右侧是百度的各条产品线,我们对敏捷教练的核心要求是: 要给产品线带来变化,提现自身的价值。多年以来,我们对于这句话的理解已经达成了共识。变化的是什么?是引导团队从现有状态达到一个更高效能和效率的状态。
我们和产品线合作的初期,产品线的需求往往只有一句话: 我觉得我这里现在有点乱,你能来帮我看看是怎么回事么?做为教练,我们就需要在前期清晰的识别到哪些导致”乱”的问题并给出解决方案,并引导产品线通过一系列实践解决掉这个问题,从而使研发团队达到一个更高效的状态。
关于效率和效能我们在后面章节详细介绍,在这里我想表达的是: 百度敏捷教练的价值不在于做了多少次培训,为多少个团队引入了敏捷实践,而在于是否能够解决问题,提升效率和效能。对我们来说,培训,方法,工具都是解决问题的手段,我们要关注的是结果,这是真正提现价值的地方。
沉淀: 形成方案:
最后,也是最重要的部分,是我们要把在产品线验证过的实践形成可复制的方案。方案中包括了工具的优化和引入,管理和工程两方面的具体实践,产品线的实施案例。我们意识到: 想撬动体量如 BAT 这样级别公司的研发效率提升,只靠基于人的专家服务模式是行不通的。原因有三个:
上面三个问题形成了一个死循环,因为人力被分散在现有产品线,所以缺少人力投入到新产品线,人力覆盖密度不够。覆盖密度不够,导致实践很难形成共识。难以形成共识,就需要我们不断的靠人去引导实践,对人力的需求就更甚。
所以我们必须将实践中可重复的部分变成公司范围内的共识, 通过研发工具固化下来,靠产品线自身的知识传承去固化效果;同时也减少团队中重复的工作;基于这样的模式,专家团队需要做的事情有这样几件:
综上所述,在百度,我们一方面是最新软件工程实践的践行者,一方面我们是企业研发变革的推动者,一方面,我们又是研发工具的诉求提出者。这就是百度定义的敏捷教练,或者更贴切的,应该叫软件工程方法专家。
接下来就是今天我要重点介绍的: 关于从产品线现状出发,识别研发效率瓶颈,与产品线达成共识的一系列招式,我将其概括为: 一个分析模型—冰山模型,一本路书—Agile fluency model
这部分回答了前面的第二个问题: 我的产品线现状是否适合做 devops。首先我们要引入一个概念: 冰山模型
冰山模型是美国著名心理学家麦克利兰于 1973 年提出了一个著名的模型,所谓“冰山模型”,就是将人员个体素质的不同表现表式划分为表面的“冰山以上部分”和深藏的“冰山以下部分” 其中,“冰山以上部分”包括基本知识、基本技能,是外在表现,是容易了解与测量的部分,相对而言也比较容易通过培训来改变和发展。 而“冰山以下部分”包括社会角色、自我形象、特质和动机,是人内在的、难以测量的部分。它们不太容易通过外界的影响而得到改变,但却对人员的行为与表现起着关键性的作用。—— 引自百度百科
我最早接触这个冰山模型,是在 2015 年接受的一次《系统思维》的培训课上,当时老师提到对于一个团队来说,他的行为模式也存在着存在着易于观测的部分,和待挖掘的深层次部分,总结起来,团队的冰山模型是这样的:
这个模型的四个层次分别是:
我们团队经常会使用静态结合动态的结构分析方法:
静态分析: B.A.P.O 4 象限分析:
这套方法并不是百度原创,而是来自于《软件产品线工程》,他讲的是企业如何通过平台和技术复用,实现高效的软件产品研发
在实际工作中,我们通过对产品线关键人员的访谈,从上述 4 个象限来描述一个研发组织的整体现状,这个 4 个象限的关系是这样的:
动态分析: 系统循环图 关于系统循环图的介绍,大家可以看这篇文章: https://www.sohu.com/a/236938851_114819.
我这里拿出一个例子来,这是 18 年年初我为百度内部一个大型移动开发团队分析版本交付周期时,和产品线共同绘制的一张系统循环图。这是一个典型的增强循环: 一方面需求的增加导致需求间协调成本越高,另一方面团队的技术债务开始积累,直接导致研发的工作被修改 BUG,需求沟通占据,最后留给测试和发布的时间越来越少,于是团队加班越来越严重。研发总监找到我们希望使用更长的迭代周期,在分析了团队的现状之后,我提出了和他最初印象相反的方案: 应该缩短迭代周期,并且在技术,流程,组织方面实施一系列的管理和技术实践,减少无效的沟通和流程,最终提升效率(第二张图所示)
如下图所示: 首先将三周的迭代变为两周,需求批次,研发和产品的组织按照两周的迭代来进行,主要的改进点包括:
团队经过一年多的,截止到今年 Q2,已经实现了每周能够在移动端发布灰度版本,三周发布一个大版本的节奏;单个需求的交付周期缩短了 20%;需求优先级决策时长缩短了 80%;整个底层服务的 devops 实施水平位于公司内部顶尖水平。关于这个团队的故事,可以参考这篇文章: https://developer.baidu.com/topic/show/290264
上面就是我们在组织的结构层面进行的分析方法和实例。对分析方法感兴趣的观众,可以关注” 百度效率云官方公众号”, 回复”调研问卷”获取基础调研模板。也欢迎大家在讨论区提出相关问题
总结一下: 通过冰山模型的建立,我们对一个产品研发组织建立了从表象到根源的立体诊断;这就初步解答了文章开头的第一个问题: 我的企业要不要实施 devops? 答: 我不要我觉得,我要你觉得。做为研发组织的管理者,你希望解决什么问题,你希望取得多大程度的改善,这才是企业在实施 devops 之前需要全盘思考的事情。
接下来我来回答第三个问题: 我的产品线做了敏捷/DevOps/精益,到底能带来什么收益?对于这个问题,在一开始我也只能非常宏观的回答说: 提升研发效率,减少研发过程中浪费。直到我看了 Martin Fowler 博客上的这篇文章: 《The Agile fluency model》, 我对企业采纳敏捷开发方法,DevOps,精益产品实践的收益有了更系统化的认识。在这篇文章里,老马提出了一个名为 Agile fluency 的模型,如下:
首先,这不是另一套成熟度/分级模型,根据老马的解释,这是一套企业实施敏捷/DevOps 的演进图。图上共分成 4 个领域,分别是聚焦(Focusing),交付(Delivering),优化(Optimizing),强化(Strengthening)。每个领域包含了一系列的管理/工程实践,企业通过熟练掌握这 4 个领域里的实践,可以获得的收益分别是:
这 4 个领域没有严格的改进顺序,企业应该从自身的需求出发,找到最适合当前现状的切入点。这里我们要特别注意的是”熟练掌握”这 4 个字。不同于采纳,尝试,使用,老马在文章中强调,一个组织如何判断自己已经顺联掌握了某一个领域呢?即要求团队即使面临压力,依然能够按照领域中的实践去实施,而不会抛弃掉已经习得的实践。这和我在前面冰山模型中讲述的”组织潜意识”是一个道理。
那么,每个象限具体包括哪些实践,企业实施后预期的收益是什么?付出的时间成本是多少呢?文中也给了这样一个指导:
以上图中 Focusing 领域为例,该领域包含了诸如 scrum ,kanban 等敏捷开发的非技术实践。团队在这个阶段应该将改进的精力投入到工作流程设计。团队需要大概 2-6 个月(取决于团队的迭代周期)。通过熟练掌握 Focusing 领域,团队从交付软件和系统进化到交付业务价值,团队的研发过程从黑盒状态变为高度可视化,以及不断改善的能力。
根据我的经验,这是一个非常诚恳的,切合实际的描述。团队仅仅掌握敏捷开发中的管理实践,并不能给团队的生产力带来提升。敏捷管理实践能够保证的无外乎以下几点:
我们说,虽然发布频率更快,但是在企业人员能力,技术角度没有变化的情况下。这个更快的频率是通过减少批量来实现的,团队本身并没有获得更高的生产力。
再来看 Delivery 领域,这个领域中包含了敏捷开发中的技术实践,比如 XP 中的 TDD, pair programming 等等,我们会发现 DevOps 赫然出现在这个领域。那么实施这些工程实践,我们的预期收益是什么呢? 如下图所示:
所以,团队想获得真正的生产力的提升,应该在 delivery 领域发力。还是以 delivery 领域为例,企业掌握这个领域需要付出哪些成本呢?
最大的成本是团队的学习成本。团队想熟练掌握 delivery 领域,就必须忍受在前期学习技术实践时暂时性的生产力下降,但是,一旦团队开始适应新的工作方式,生产力将获得极大的飞跃(如下面的学习曲线示意图)。
举个实际的例子,在 2014 年,我曾经指导百度地图的客户端团队和一部分服务端团队实施 devops。服务端团队的约 30 名 RD 花费了大约三个月的时间来练习书写单元测试,接口测试,并将其在自动化流水线上运行起来,又经过了两个月来养成快速修复构建和代码提交的院队习惯。最后我们做了一下效率方面的: 在尝试 Devops 实践之前,这个团队在两周的迭代周期内,开发和测试的时间占比平均是 1:1;尝试 Devops 实践之后,团队一个迭代周期内,只需要 1 天的时间进行手工的验证和测试,就可以发布服务。这意味着团队每两周就多出至少 3 天的开发时间!这是生产力上巨大的飞跃。
再来看移动客户端的成就,客户端的团队共在实施 DevOps 之前,每个版本 release 周期是 3-4 周,其中有 1 周时间 QA 要求 code freeze,完全进行测试工作;我们用了两个月的时间搭建了自动化的移动端流水线,尝试了如 robotium, espresso,capybara 等移动端的 UI 测试工具,又用了 4-6 个月不断的补充自动化测试用例。在 15 年初的时候,三轮的回归测试工作可以在 3 天内完成,当时一个 QA 的经理和我说,我最大的感受是,每个月最后一周不用每天加班到后半夜了>_<。我认为,这是产品线实打实感受到的提升。
最后,这个模型里也附带说明了企业如何选择自己的实施切入点: 对于业务方向多,决策过程冗长的团队,可以尝试从 Focus 领域切入,建立从客户价值视角审视项目的机制。打破业务方向之间在需求优先级层面难以达成共识的怪圈。在百度的实际工作中,我们发现往往是那些通过业务调整,在短时间内团队规模和业务范围急剧扩大的团队需要先熟练掌握这个领域。
对于交付周期长,经常因为质量等问题发布失败的团队,可以尝试从 delivery 领域切入,积极的拥抱 Devops。通过减少技术债务,架构优化来提升整个团队的生产力。在百度的实际工作中,我们发现底层的服务团队,或者有明确的交付时间点的团队需要尽快掌握 delivery 领域中的实践
对于那些处在创业状态,需要快速实现 PMF(product market fit)或者快速增长的团队,可以尝试从 optimizing 的领域切入,更好的理解自己所处的市场和客户需求。我们在一部分小型的业务创新型团队尝试过此类实践。
至于 strengthening 领域,我目前还没有太多的经验,所以就不在这里班门弄斧了 :)
总结一下,实施 devops,需要从企业自身的现状和诉求出发。选择那些能够真正给自己的效率带来提升的实践和方法,期待有一种标准方法能够解决我所有的烦恼,其实是欲速则不达。在文中我提到了一些分析方法和模型。我在这里列一下:
来源:本文转自公众号“百度敏捷教练”,经平台授权转载,点击此处查看原文。