近年来，由于敏捷与 DevOps 是软件交付行业的大势所趋，几乎每家公司都有专职做敏捷与 DevOps 的。这么大力的金钱和人力投入，效果如何呢？

01 现象

通过和一些专职做敏捷与 DevOps 的朋友聊天，也印证了我的几个观察。

照本宣科

这特别体现在敏捷与 DevOps 教练身上，但错未必在教练身上。本来，教练带过的公司和团队多，见识广，经验多，应该能为公司和团队带来有价值的指导。

然而，由于每家公司的投入都有限，特别是高价聘请的外部教练，往往被分配到多个部门、团队和项目，导致他们对每个部门、团队和项目的情况掌握只能是蜻蜓点水，没有时间和精力深入理解每个团队和项目的具体情况。

而且，他们与一家公司合作的期限也是有限的。在时间的压力之下，他们往往只能开统一的药方。对基础知识的扫盲培训往往成了他们对被服务的公司和团队最大的贡献。

由于无差别地服用同一剂药方，各部门、团队和项目往往吃不消。转型很快变形，流于形式。教练一走便打回原形。

追求数字

管理层为了驱动各团队、项目转型，往往会制定一些 KPI（也会美曰 OKR），比如更高的自动化测试覆盖率、更短的交付周期等。一旦这些 KPI 成了考核目标，异化便不可避免。

为了满足这些指标，就把一次发布拆分成若干个无业务价值的发布的现象比比皆是。

追求“完成”

由于敏捷与 DevOps 是高层定下的转型目标，有些管理层非常重视，为了满足目标，申请了专门的预算，聘请教练和专职的监督、考核团队，强制所有团队按照教练定下的框架行事，并以形式上满足框架的要求的情况进行评审。把转型作为一个专项项目来执行，急于求成。

项目结束时，便对外宣称他们的敏捷与 DevOps 转型已“完成”。至于各团队和项目的交付效率是否真的有提升，是否需要继续持续改善和投入，不再是他们关注的重点。

02 原因

以上种种做法，无疑是要做掉敏捷与 DevOps。很多公司和团队都在反思，这几年轰轰烈烈的敏捷与 DevOps 革命，到底带来了什么好处。很多不良现象和转型的副作用，都被归咎于敏捷与 DevOps。

造成这些现象的原因有：

缺乏对具体交付问题的洞见

笔者认为，所谓敏捷与 DevOps 转型，是针对具体交付问题的演进过程，不能生搬硬套书本上的知识。正如前文所说的，与团队的交付经理相比，教练，特别是外聘教练有丰富的跨团队视野和指导经验。然而，由于他们无法深入到每一个具体团队和项目中，对于具体的交付问题认识不足，无法开出针对性的药方。

教练就像是一个医生，在开药之前，势必要弄清楚病人到底得了什么病。

一刀切、简单化

作为管理层，面对着形形色色的团队和项目，不可能具体理解每个团队和项目的痛点。但他们都希望每个团队和项目能有自驱力，持续改进，提高效率。从他们的角度，制定简单的指标然后考核、比较，是简单、通用的方法。

但正如管理学大师德鲁克所说的，你考核什么，就会得到什么。而你得到的，往往并不是你想要的。

政绩工程

转型作为最高层定下的目标，各领导都希望在这一领域有所作为，包括以此为依据拿到额外的预算，扩充团队和影响力。他们便希望转型有个终点，就像百米冲刺那样，跑过去就能拿到奖牌。

03 解药

尊重差异以具体问题为本

转型不是目标，是手段。

每个部门、团队和项目都有自己具体的交付问题。根据自己的具体情况，找到适合自己的转型之路，提升效率，减少浪费，才是目标。

我们应该始终围绕着这些具体问题找解决方案，而且我一直强调，敏捷与 DevOps 的各种实践和工具，只是扩充了我们的武器库，增加了解决方案的选项，切勿将其视为唯一的选择。

作为敏捷与 DevOps 专家，我从不排斥瀑布模型里的实践与工具，我经常用 Micorsoft Project 来确定 WBS、Networking Diagram 和 Critical Path，因为一个项目或复杂任务往往有复杂的依赖关系，我们需要通过这些实践和工具分解问题，有全局观，并回应客户关于成本和交付日期的疑问。

敏捷与 DevOps 倡导的价值观和原则则是普世的，它们不光能指导我们的软件交付工作，还能影响我们的领导力和管理观。这些才是我们学习的重点。

作为团队或项目负责人，对自己的具体问题有了充分了解，便可借助见多识广的教练来扩充自己的选项，找到最适合自己的道路。

作为敏捷与 DevOps 教练，切勿形而上学，一定要充分理解团队和项目的具体问题，因材施教，并且搭建交流和分享平台，举一反三，把从各团队、项目收集的经验扩展开来。

指标驱动但不考核

为了推动整个组织实现 DevOps，我们公司高层制定了一些“简单粗暴”的指标——今年的发布数量要比去年翻倍，故障数量要比去年减半。这些 OKR 成了所有 IT 系统负责人的共同目标。

乍一看，这样的目标很不合理。然而，只要我们端正对这些目标的态度，结果则大不一样。如果我们狭隘地追求数字，应付考核，当然不会得到好的结果。

但如果我们把它当成驱动力，不断审视自己的团队和系统还有哪些方面可以改进，则会有很多意外收获。

作为其中一个 IT 系统负责人，我也要接受这些目标的要求。但通过围绕着这些目标对自己系统的持续改进，我们获得了以下成果：

1. 实现了某些变更类型的在工作日的自动化发布，从而使发布数量比去年同期增长了 192%，差不多是过去的 3 倍，远远抛离要求的目标。具体措施可参阅《另辟蹊径，传统银行供应商系统持续交付之路》

   
   

2. 改进工单排序流程，把时间精力用在刀刃上。具体措施可参阅《从急诊室故事联想到系统运维》

   
   

3. 每周故障分析会议，持续跟进故障长期解决方案的交付，分析故障和请求类型，建立知识库减少重复故障和请求。

   
   

4. 加强监控，包括系统指标监控和业务流量增长，感知系统健康情况，防范于未然，也能减少人工登陆服务器的次数和工单数量。

   
   

5. 标准化运维流程，把具体的标准运维流程写成分步文档，并提供审批申请模板，便于每个运维人员严格按照规范执行，减少出错和降低风险。

   
   

6. 在合规的情况下，标准化发布后系统检查清单，为发布质量提供最基本的保障。

我们也一直强调，每个系统的情况都很不一样，有些是新建的，有些是遗留的，有些是自主开发的，有些是依赖第三方厂商的，“家家有本难念的经”。

所以不应该把不同团队进行横比。这些目标，更重要的是驱动每个团队对自己进行持续改进，所以对自己的纵比更有意义。

以我们公司的实践，指标驱动的 DevOps 转型是可行的，但是这需要管理层对指标背后的目的有明确的阐释，各团队也要对指标有正确的理解，视之为工具，而不是考核，才能避免异化，达到持续改进的目的。

激励每个人都投入变革

如何激励每一个人都发挥主观能动性，持续改进自己和团队的工作环境呢？我们的实践是，在年末进行绩效考评时，拿到更高的评分的其中一个重要考量是你在这一年有没有为团队和部门带来过好的变化。

如果你只是做好被分配的本职工作，“有苦劳但没有功劳”，对不起，你的评分只能是平均水平。要想得到更高的评分，你就要为团队、部门的变革做出过贡献。像上面提到的，就是一个例子。

而升职、奖金和加薪都和绩效考评结果有关系。这就变相激励了每一个人都要对变革做出自己的贡献。而每个人更清楚自己所处环境的问题和差异，可以提出更有针对性的解决方案。

经过过去五年全集团的敏捷与 DevOps 转型，我觉得我们最大的收获并不是多少团队在实践 Scrum 或 XP、自动化测试代码覆盖率提高了多少、发布频率提高了多少等，而是敏捷与 DevOps 的思想深入人心，DevOps & Agile (DnA)成了每个人的 DNA。

从 IT 的角度，各团队响应业务需求的能力显著提高；在业务方，业务的话术中敏捷与 IT 术语越来越多。

觉得文章不错，顺手转发给朋友们吧。

分割线 卡通

相关阅读：

敏捷转型是根据具体问题的演进过程

KPI驱动的DevOps转型可行吗？

刘华：看板那么好，为什么都成了摆设？

关于作者

刘华（Kenneth）

• 著有书籍《猎豹行动：硝烟中的敏捷转型之旅》《软件交付那些事儿》

• 《图数据库实战》中文译者之一。

• 世界 500 强银行科技部云平台技术主管

• 敏捷、精益、DevOps 专家

• 公众号“敏于思 捷于行”博主

• 精通极限编程、Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发、DevOps 工具栈、Docker、Kubernetes (Google Kubernetes Engine, GKE)

• 曾在 GDevOps、DevOpsDays Meetup、中国软件技术大会、ArchSummit、Top 100 等论坛发表主题演讲

• 阿里云、谷歌云认证架构师

觉得好看转发给朋友们，欢迎你留言。