作者简介 金锐，百度 DevOps 解决方案运营总监，百度工程效能部资深敏捷教练。
引言
笔者 2012 年做为敏捷教练入职百度，到 2018 年年底一直做为敏捷教练，在百度内部进行敏捷开发的推广，DevOps 实施工作。在工作过程中，我被频繁的问到以下几个问题:
- 敏捷/DevOps 教练是做什么的？你能帮我写代码/带项目/做测试么？
- 你看我产品线的现状，适合做 DevOps/敏捷转型么？
- 我的产品线做了敏捷/DevOps/精益，到底能带来什么收益？
- 回到具体的实施，我们应该从哪里开始着手？
相信这些问题也是很多企业的 IT 主管，DevOps 推动者想问的问题。今天我就根据我自己的工作经历来为大家分享一下我的理解和实践:
I.什么是敏捷教练？在百度做敏捷教练是种什么体验？
对于敏捷教练，好像很难有一个统一的定义。引用 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 这样级别公司的研发效率提升，只靠基于人的专家服务模式是行不通的。原因有三个:
- 人力的覆盖密度不够: 我们做过一个估算，对标行业内大型公司的其它团队，为了实现全公司的专家覆盖密度，我们需要建一个近 100 人的专家团队，这是一个相当高昂的成本，而同样 100 人的业务团队，已经可以支撑一个中型以上的业务了；
- 重复工作: 虽然每个产品线面临的问题不同，但是解决方案是共通的，因此我们每切入一个产品线，往往需要将之前做的实践在重新实施一遍。时间久了我们会恍然觉得自己就像被缚的普罗米修斯，每天重复着重生—被啄食肝脏的死循环；团队会因此失去前进的动力和方向，这是非常危险的一件事。
- 效果难以固化: 在咨询行业有一个特色，当企业和咨询师合作紧密的时候，往往企业会取得很好的改善效果；而当合作关系结束，或企业内外部环境发生变化的时候；企业的表现往往又开始回退。其实企业内的产品线也明白这个道理，所以我们的专家一旦投入一个产品线，就很难抽身出来。产品线出于对专家的信任和保持效果的期待，会非常抗拒我们将人员撤出。
上面三个问题形成了一个死循环，因为人力被分散在现有产品线，所以缺少人力投入到新产品线，人力覆盖密度不够。覆盖密度不够，导致实践很难形成共识。难以形成共识，就需要我们不断的靠人去引导实践，对人力的需求就更甚。
所以我们必须将实践中可重复的部分变成公司范围内的共识, 通过研发工具固化下来，靠产品线自身的知识传承去固化效果；同时也减少团队中重复的工作；基于这样的模式，专家团队需要做的事情有这样几件:
- 探索软件工程的前沿领域: AI 开发和传统服务开发有什么区别？云原生概念下，软件工程又变成什么样？有哪些实践发生了变化？
- 引导产品线的多方角色识别瓶颈，达成一致，从而激发产品线自身对效率提升的诉求
- 引导产品线跨越变革过程中的一道道门槛，实现对工程能力永无止境的诉求
综上所述，在百度，我们一方面是最新软件工程实践的践行者，一方面我们是企业研发变革的推动者，一方面，我们又是研发工具的诉求提出者。这就是百度定义的敏捷教练，或者更贴切的，应该叫软件工程方法专家。
接下来就是今天我要重点介绍的: 关于从产品线现状出发，识别研发效率瓶颈，与产品线达成共识的一系列招式，我将其概括为: 一个分析模型—冰山模型，一本路书—Agile fluency model
II. 问题的分层模型—冰山模型
这部分回答了前面的第二个问题: 我的产品线现状是否适合做 devops。首先我们要引入一个概念: 冰山模型
冰山模型是美国著名心理学家麦克利兰于 1973 年提出了一个著名的模型，所谓“冰山模型”，就是将人员个体素质的不同表现表式划分为表面的“冰山以上部分”和深藏的“冰山以下部分” 其中，“冰山以上部分”包括基本知识、基本技能，是外在表现，是容易了解与测量的部分，相对而言也比较容易通过培训来改变和发展。 而“冰山以下部分”包括社会角色、自我形象、特质和动机，是人内在的、难以测量的部分。它们不太容易通过外界的影响而得到改变，但却对人员的行为与表现起着关键性的作用。—— 引自百度百科
我最早接触这个冰山模型，是在 2015 年接受的一次《系统思维》的培训课上，当时老师提到对于一个团队来说，他的行为模式也存在着存在着易于观测的部分，和待挖掘的深层次部分，总结起来，团队的冰山模型是这样的:
这个模型的四个层次分别是:
- 现象: 可被观测到的团队的表现，甚至产品表现。这一部分是团队的内，外部观察者最容易感受到的表象，它是结果而非原因，更深层次的一些问题导致了这些表像。比如我们前文提到的”我觉得团队现在有点乱”就是一种很常见的现象；再比如和团队 one one 沟通的时候团队成员的吐槽，都是可以直接反映出团队的现象。甚至，一款产品稳定性，服务水平的波动，也是团队现象的一种外在表现。在这个层面上，我们能够做的是如实的记录，现象能帮助团队增强对问题和痛点的共识和认可。但是想解决问题，我们需要深入水下，向下挖掘。
- 趋势: 这个层面是对表象的第一层解释，当我们说到”产品质量差”, 在趋势这里，我们需要找到质量变化的量化数据: 稳定性，BUG 数据，测试执行次数等等； 当我们说”团队交付慢”的时候，我们就要找到诸如服务发布频率，单个服务的交付周期等数据。 在这个层面上，组织经常犯的错误有两个: 第一个错误: 缺少恰当的量化的指标来说明趋势，我们说”恰当”包括了两层意思，第一，组织是不是有这样的长期记录的指标来反映趋势: 我个人经常遇到的情况是: QA 反馈说现在 RD 提测的质量越来越差，我问道，噢，我们有最近一段时间提测打回，或者线下 BUG 的记录数据么？结果没有… 那么，即便我们开始强化自测，增加了 RD 的工程实践，我们如何验证效果呢？ 第二，观测出来的指标无法指导下一步的行动: 在这一点上,设计研发效率度量指标和设计产品运营指标并无本质上的区别。指标和行动之间必须有很强的关联关系，比如我们引导 RD 进行单元测试的实践，那么我们就建议 QA 去对产品 BUG 进行分析，记录那些反复出现的 BUG 数量，记录由于代码逻辑问题导致的 BUG 数量。以此来引导 RD 更多的采纳单元测试。第二个错误: 根据趋势采取行动，很多团队的管理者在观察到数据后往往条件反射式的建立一系列的监控和控制措施，试图扭转趋势。但往往无法取得很好的效果，主要是因为产生之类问题的原因还没有找到，而监控和控制措施又需要投入成本去实施，团队本来就不多的注意力进一步被分散到和自己本身工作没有强相关的事情上，实践的采纳效果不好，结果也不好。 经常有团队问我: 你能不能帮我们设计一个变更控制流程/XXX 流程，我会建议他们，我们先找到需求变更的原因，之后找到一种不需要这个流程的解决方案，或者用更简单的契约来代替这样的流程。所以，在这一层面，我们需要的是设计，并长期记录和观察。
- 结构: 在冰山模型中，这一部分是最为核心和关键的层面，也是大多数咨询师，教练关注的层面。什么是结构，结构是一个组织在一段时间内在多个维度的表现，一个组织的结构，在一定的观察期内是静态的(如果组织处在不停的调整期，我们可以认为在人事/业务/技术层面，该组织的表现就是”变化”)。
我们团队经常会使用静态结合动态的结构分析方法:
静态分析: B.A.P.O 4 象限分析:
这套方法并不是百度原创，而是来自于《软件产品线工程》，他讲的是企业如何通过平台和技术复用，实现高效的软件产品研发
在实际工作中，我们通过对产品线关键人员的访谈，从上述 4 个象限来描述一个研发组织的整体现状，这个 4 个象限的关系是这样的:
- Business，也就是业务，或商业模型决定了企业的竞争态势和业务价值流的长度，Business 部分的现状对其它三个象限提出了要求或限制；
- Organization，我们重点关注组织是否具备能够满足业务需求的能力，包括了组织能力的定义，具体人员的能力定义，具体的组织结构，组织的职责边界。在组织维度有一个和效率相关度非常高的指标—最小产生价值的单元，如果我们讲研发效率，这个最小单元的定义就是一个组织内部能够独立提供 IT 服务开发，部署，运维的团队规模大小；单元的规模越小，代表企业的运作越灵活，越能应对快速的变化。在亚马逊，这个单元的大小就是著名的”披萨团队”。
- Architect，包括了当前服务于业务的 IT 系统的技术架构，技术选型，团队对技术实践的采纳；Architect 要能够赋能现有的业务，至少不要成为企业效率的瓶颈。比如微服务，高可用，上云，DevOps 实施，研发的系列工具都属于架构象限；
- Process，定义了产品，运营，研发，运维，测试，OP 等角色间的协同机制，在 process 层面，我们要关注的是是否流程上有缺失，或者 over process 的情况；
动态分析: 系统循环图 关于系统循环图的介绍，大家可以看这篇文章: https://www.sohu.com/a/236938851_114819.
我这里拿出一个例子来，这是 18 年年初我为百度内部一个大型移动开发团队分析版本交付周期时，和产品线共同绘制的一张系统循环图。这是一个典型的增强循环: 一方面需求的增加导致需求间协调成本越高，另一方面团队的技术债务开始积累，直接导致研发的工作被修改 BUG，需求沟通占据，最后留给测试和发布的时间越来越少，于是团队加班越来越严重。研发总监找到我们希望使用更长的迭代周期，在分析了团队的现状之后，我提出了和他最初印象相反的方案: 应该缩短迭代周期，并且在技术，流程，组织方面实施一系列的管理和技术实践，减少无效的沟通和流程，最终提升效率(第二张图所示)
如下图所示: 首先将三周的迭代变为两周，需求批次，研发和产品的组织按照两周的迭代来进行，主要的改进点包括:
- 技术方面: 移动端深入组件化改造，将不同业务方向间的发布解耦； 从服务端开始实施 DevOps，提升代码提交后的效率； 每轮迭代加入一定量的技术类需求，用来清扫技术债务，提升产品性能和稳定性；
- 管理方面: 减少每轮迭代需求输入的批量，并根据团队的实际交付能力调整； 强化需求的准入规则，提升需求质量； 透明化研发过程，提升沟通效率；
团队经过一年多的，截止到今年 Q2，已经实现了每周能够在移动端发布灰度版本，三周发布一个大版本的节奏；单个需求的交付周期缩短了 20%；需求优先级决策时长缩短了 80%；整个底层服务的 devops 实施水平位于公司内部顶尖水平。关于这个团队的故事，可以参考这篇文章: https://developer.baidu.com/topic/show/290264
上面就是我们在组织的结构层面进行的分析方法和实例。对分析方法感兴趣的观众，可以关注” 百度效率云官方公众号”， 回复”调研问卷”获取基础调研模板。也欢迎大家在讨论区提出相关问题
- 价值观: 最深层面，也就是组织在产品研发方面秉承的共同理念。这个层面上，存在着非常简单，但是非常根本性的判断原则，我习惯称之为”Ground rule”。比如: 发布的速度优于产品的质量；大而全的产品方案好过简单实现的 MVP；“听领导的安排是最安全的”。这些原则就像一个组织的潜意识，它的建立，是一个组织在长期磨合的过程中形成的应激性反映。一旦团队面临压力的时候，指导团队行动的不是制订出来的规则，而是这些”潜意识”。这就是为什么很多团队在业务发生变化的时候，改进工作会倒退。这样的组织虽然在结构层面发生了改变，但价值观层面没有发生变化，新的原则没有被植入进去，所以在面临压力的时候，又退回到了原本的表现。
总结一下: 通过冰山模型的建立，我们对一个产品研发组织建立了从表象到根源的立体诊断；这就初步解答了文章开头的第一个问题: 我的企业要不要实施 devops? 答: 我不要我觉得，我要你觉得。做为研发组织的管理者，你希望解决什么问题，你希望取得多大程度的改善，这才是企业在实施 devops 之前需要全盘思考的事情。
III. 改进的 roadmap—Agile fluency model
接下来我来回答第三个问题: 我的产品线做了敏捷/DevOps/精益，到底能带来什么收益？对于这个问题，在一开始我也只能非常宏观的回答说: 提升研发效率，减少研发过程中浪费。直到我看了 Martin Fowler 博客上的这篇文章: 《The Agile fluency model》， 我对企业采纳敏捷开发方法,DevOps，精益产品实践的收益有了更系统化的认识。在这篇文章里，老马提出了一个名为 Agile fluency 的模型，如下:
首先，这不是另一套成熟度/分级模型，根据老马的解释，这是一套企业实施敏捷/DevOps 的演进图。图上共分成 4 个领域，分别是聚焦（Focusing），交付(Delivering)，优化(Optimizing)，强化(Strengthening)。每个领域包含了一系列的管理/工程实践，企业通过熟练掌握这 4 个领域里的实践，可以获得的收益分别是:
- Focusing teams produce business value.
- Delivering teams deliver on the market cadence.
- Optimizing teams lead their market.
- Strengthening teams make their organizations stronger.
这 4 个领域没有严格的改进顺序，企业应该从自身的需求出发，找到最适合当前现状的切入点。这里我们要特别注意的是”熟练掌握”这 4 个字。不同于采纳，尝试，使用，老马在文章中强调，一个组织如何判断自己已经顺联掌握了某一个领域呢？即要求团队即使面临压力，依然能够按照领域中的实践去实施，而不会抛弃掉已经习得的实践。这和我在前面冰山模型中讲述的”组织潜意识”是一个道理。
那么，每个象限具体包括哪些实践，企业实施后预期的收益是什么？付出的时间成本是多少呢？文中也给了这样一个指导:
以上图中 Focusing 领域为例，该领域包含了诸如 scrum ,kanban 等敏捷开发的非技术实践。团队在这个阶段应该将改进的精力投入到工作流程设计。团队需要大概 2-6 个月(取决于团队的迭代周期)。通过熟练掌握 Focusing 领域，团队从交付软件和系统进化到交付业务价值，团队的研发过程从黑盒状态变为高度可视化，以及不断改善的能力。
根据我的经验，这是一个非常诚恳的，切合实际的描述。团队仅仅掌握敏捷开发中的管理实践，并不能给团队的生产力带来提升。敏捷管理实践能够保证的无外乎以下几点:
- 围绕业务价值组织研发流程(USER STORY BASE）
- 可视化的研发过程及瓶颈(可视化看板,kanban 方法)
- 小批量的，高频率发布(user story, iteration)
我们说，虽然发布频率更快，但是在企业人员能力，技术角度没有变化的情况下。这个更快的频率是通过减少批量来实现的，团队本身并没有获得更高的生产力。
再来看 Delivery 领域，这个领域中包含了敏捷开发中的技术实践，比如 XP 中的 TDD, pair programming 等等，我们会发现 DevOps 赫然出现在这个领域。那么实施这些工程实践，我们的预期收益是什么呢? 如下图所示:
- 减少 BUG，团队耗费更少的精力在修复 BUG 上(CI/CD, TDD)
- 提升架构的合理性(reuse, refactoring, micro service)，减少代码技术债务，团队开发新功能的边际成本在下降
- 团队可以根据业务的需求随时发布，更灵活的响应业务需求
所以，团队想获得真正的生产力的提升，应该在 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，需要从企业自身的现状和诉求出发。选择那些能够真正给自己的效率带来提升的实践和方法，期待有一种标准方法能够解决我所有的烦恼，其实是欲速则不达。在文中我提到了一些分析方法和模型。我在这里列一下:
- Agile fluency model: https://www.martinfowler.com/articles/agileFluency.html
- 研发现状调研模板: 关注”百度效率云官方公众号” ， 输入调研问卷，获得调研问卷的下载地址
- 百度工程能力白皮书: 这个是百度工程效能部 10 年软件工程经验的大成，定义了百度的技术分类，标准研发过程，标准实践，实践的度量方法和工具。同样请关注”百度效率云官方公众号”， 输入”工程能力白皮书”获得下载地址。
来源：本文转自公众号“百度敏捷教练”，经平台授权转载，点击此处查看原文。
