没有研发过程数字化，DevOps 就是水中月、雾中花

原文作者：行云创新 CEO 马洪喜

前不久，老马很荣幸受邀参加了 2023QECon 质效城市论坛深圳站，在会上与来自腾讯、思码逸、Agilean 的质效专家们交流和探讨了研发过程数字化和的关系，感触颇多，记录下来以供更多朋友们参考，如果能激发一些深度的思考，更是美事一件，希望大家不吝赐教，请告诉我您的想法。

我本人 2018 年获得了 DevOps 沙盘教练认证，后来也带过很多期的学员通过沙盘游戏践行 DevOps 文化。我经常和学员们感慨，工业领域特别是汽车制造业，对敏捷的采用比软件业高明了很多，很多企业的看板其实是形同虚设的，上面都落灰了——而去修车的时候总会发现 4S 店的看板用得很高效。软件业谈敏捷、DevOps 本身好些概念也是来自于汽车制造业，但 DevOps 没能很好的落地，这里不乏有软件的工序复杂度问题，超级多任务协同问题、跨部门协调等非技术问题。成功的 DevOps 可能差不多，不太成功的 DevOps 则各有各的难处。

我一直都是一名“实用 DevOps 者”，我强调 DevOps 的使命是和企业使命（创新、盈利）对齐的，DevOps 也绝对不是一个工具或是四个指标，而是一种企业践行创新的文化：高效、协同、主动甚至是奉献精神。我心目中没有 100 分的 DevOps，也没有 59 分，其实只要去尝试了，哪怕获得一分的受益也比之前好。所以，很多学员朋友说，我们企业有部门墙啊，DevOps 落地不了什么的……我觉得是不是可以不要 100 分，甚至不要 80 分，先从能做的地方开始，让 DevOps 对原来的工作有所改善。

当然，践行 DevOps 这个过程不容易，特别是当阻力颇多的时候，这些挑战让当初兴致勃勃做起来的看板蒙尘。可以有 100 种困难让 DevOps 的推进遭遇挫败感，这时我们需要数字化，来看一看，是不是我们的部署频次提升了？上线前置时间变短了？出错的恢复时间短了？出错率低了？如果这四个 DORA 维度的指标还不能马上体现出来，可以看看平均解 BUG 时间、PR 合入时间等更细的粒度。有了这些数据指标，DevOps 的践行客观性多一点、主观性少一点，这样会鼓励多一点、挫败少一点，DevOps 也不再是变得虎头蛇尾、大家避而不谈的失败。

我们软件人是在帮助我们的企业我们的客户做数字化转型，但我们自己的数字化手段还很匮乏，甚至是生产力工具还很落后。数据分散在 Git, Jenkins, Jira, SonarQube N 多不同的研发系统里，之前总是在想怎么样把这些工具串起来做 CICD，但很少聚焦于把里面的研发管理数据拉通，为效能服务。

Apache DevLake 就是这样的一个开源项目，他通过插件聚合了不同研发工具的研发活动数据，为研发效能提供数据参考。

更多数据展示示例，请参考：apache 官网。

很多优秀的互联网公司研发效率已经很高了，但还是精益求精地利用研发过程数据做进一步的“优化”。反而是没有特别高效的企业研发管理还是多少有一种凭直觉、拍脑袋的做法。对于效率还处于这种“温饱线”的团队，光是逼着大伙加班加点的干也不是办法，升级生产力工具（工欲善其事、必先利其器） + 研发过程数字化是可以尝试采用的手段。

研发过程数字化，DORA 指标、PR、BUG 的合入、修复的效率固然是很重要的结果性指标，可以通过看不同周期的数据变化来检验 DevOps 践行的情况。但“牛排几分熟”可能还不是“温饱线”的团队首要关心的，而更应该关注的问题是：团队每天在干啥？早 10 点最宝贵的时间有多少人真的在开发工作上？晚上 21 点看起来加班的人不少，但都真的在做开发相关的事吗？一个人一天又有多少时间花在研发上呢？这些数据可能会更有意义，他会告诉我们的研发管理者，可能是会议和其他的杂事太多了，真正干活儿的时间太少了；亦或是，你的团队也在此种内耗中享受摸鱼的快乐。

如何知道“团队里晚上九点有多少人还在真的干活？某位组员一天里哪些时间在编码？”这正是云原生 IDE 可以监测到并与 Apache DevLake 连通后可以展现的，与其他 DevLake 数据融合后的报表，可以给到研发管理者多维的透明度。

想要获取老马在本次质效城市论坛深圳站的主题演讲 PPT《Apache DevLake 在云原生 IDE 构建过程中的落地实践》请您与我联系。也欢迎您到 www.titanide.cn 来免费下载云原生 IDE，我们把 DevLake 的研发效能看板做到了 TitanIDE 的模板市场里，像其他众多 IDE 模板一样，只需要下载并可一键安装、马上体验到云原生 IDE 的无限乐趣，并利用研发过程的数字化手段为您的企业创新提效。