你是做敏捷与DevOps的，还是做掉敏捷与DevOps的？

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

01

—

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

照本宣科

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

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

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

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

追求数字

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

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

追求“完成”

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

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

解药

尊重差异以具体问题为本

转型不是目标，是手段。

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

我们应该始终围绕着这些具体问题找解决方案，而且我一直强调，敏捷与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术语越来越多。