这是鼎叔的第一百一十八篇原创文章。行业大牛和刚毕业的小白，都可以进来聊聊。
欢迎关注本专栏和微信公众号《敏捷测试转型》，星标收藏，大量原创思考文章陆续推出。本人新书《无测试组织 - 测试团队的敏捷转型》已出版（机械工业出版社），文末有链接。
前文 聊聊软件生命周期中的度量指标 https://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484754&idx=1&sn=6fe0d88765436de0f4e431211fa5a3f9&chksm=c24fb030f538392679597e9a3d16529821b5d35eed155dc52abdc560ce6407642cb44dbf1670&scene=21#wechat_redirect， 介绍了软件生命周期各个阶段的核心指标，非常详细了，但这系列指标是从需求研发（事）的角度来开展度量改进活动，还不能满足管理层的所有需求，我们还可以从管理者角度来度量团队（人）的健康度。我们这篇具体聊聊研发工程成熟度，参考阿里巴巴的卓越工程度量经验，每个公司可以裁剪适合自己的度量公式。
阿里巴巴集团的卓越工程度量
阿里巴巴和蚂蚁集团在全集团所有事业部（BU，约 30 多个）推行了三年的卓越工程建设，整体而言没有收到负面看法，收获成果还是不错的。
作为强业务导向的研发团队，业务交付永远是最重要的，而对卓越工程的重视程度一般。当业务压力大时，能够用于自身工程能力建设的精力也很有限，还技术债的投入比重不高。
但是，只要有清晰的成熟度度量方法，可以用低成本引导技术团队自行改进薄弱地方，加强内功。
整体度量框架说明如下：
一： 以团队为单位进行研发指标度量，最终给团队一个工程成熟度（卓越工程）评分和评级。
评分是 100 分满分制，例如，95 分以上是 “大师” 等级，85-95 分是 “精英” 等级，60-85 分是 “良好” 等级，40-60 分是 “普通” 等级，40 分以下是 “初始” 等级。
二：卓越工程分数在内部官网上实时呈现，网页会展示这个总分是怎么计算出来的，它由一系列关键指标加权计算而来。
关键指标也会定期增加，相应的权重会发生调整，以满足总分 100。
所有指标由研发管理平台自动化采集提供。
针对每一个关键指标的分数，网页都会给出指标的计算公式，以及如何提升的 “官方推荐”。点击问号会跳转到相应的方法介绍页面，传播优秀的实践经验。
三： 良好及以下等级根据分数自动确认。
精英及大师级别，除了分数要在几个月内保持达标，还需要向技术委员会申报，由专家确认，才能正式授予高等级的认证证书。
四：各个事业部技术接口人，会定期开会交流本事业部技术团队在卓越工程行动中取得的进展，分享治理心得和优秀案例。
卓越工程专家团队也会定期组织工程文化活动，比如单元测试沙龙，编码比赛，工程专家课程等等。
卓越工程专家团队还会为每个 BU 输出技术工程成熟度报告和工程满意度报告。（后者也很有意思，以后再聊）
五：各个事业部的技术一把手，会把卓越工程治理目标，纳入技术 OKR 的考虑中。
由此，形成从度量到改进的闭环。
卓越工程的度量框架
基于软件研发生命周期的度量框架，都是大同小异的，不同公司完全可以有自己的指标裁剪和偏好，不需要完全对标一个大公司来制定。
能否运行出好的效果，还是看执行力和基础设施。
因为不同公司的研发基础平台水平是不同的，工程度量指标又希望是全自动化采集，如果基础设施的数据采集能力弱，那么有些指标只能被替换，或者退而求其次，给出精度较低的指标。
简单讲解下构成工程成熟度各个权重的推荐指标，以及如何采集的说明，不涉及具体公司的工具或技术。
大权重的指标可以包括这七个部分：代码规范，代码评审，单元测试，验收测试（单测以外的各种自动化测试），测试环境健康度，构建效率，部署效率。
每个部分都可以单独治理。从质量左移出发，代码规范 + 代码评审 + 单元测试是核心开发活动，工程成熟度的权重占比 40-50%。其他主要模块每个权重 10% 左右。
代码规范
代码是软件开发的源头。从自动化原则出发，主要通过各种代码扫描工具进行评分。
主要权重指标：
千行代码阻塞问题数量
千行代码严重问题数量
代码评审
代码评审的目的是找出并修正在软件开发初期的错误，从质量左移的法则上来看，大部分的缺陷都应该在编译之前发现，代码评审就是最重要的手段。
从编程者的视角，代码评审可以形成良性的社交压力，推动代码可读性得到保证，并在组织内传播有价值的知识。
为了让代码评审更加规范，可以参考谷歌等公司制定代码审查标准，包括评审需要附带的关键信息，评审通过的门槛是什么，评论是否都要解决等。
建议对相关团队进行评审结果的通知，让干系人都了解谁在提交评审，谁在输出有价值的评审意见，这往往是很好的正向激励。
主要权重指标：
发起 CR 次数：团队内员工发起 CR 的总次数
发起 CR 平均代码行数
参与 CR 次数：看团队内员工参与 CR 的总数。
参与 CR 平均代码行数
评审者评论数：参与评审者的发表评论总数，还可以按照千行代码看评论密度。
单元测试
单元测试首要的价值是降低开发同学修改代码时的心理负担，提高重构效率，有利于测试驱动开发的落地。一旦单测水平进入成熟期，单测活动能够降低需求的整体交付时长。
卓越工程强调单元测试应该：快速，独立，可重复，自检查（无需人工交互）。单测不关心功能测试环境。一个完整的功能交付，单测代码也是重要的交付产物。
几个核心权重指标：
单元测试接入率：有单测结果任务的代码库，占团队总代码库的比例。
全量行覆盖率： 在成功运行的单元测试任务中，全量代码行覆盖的占比。
全量分支覆盖率
增量行覆盖率
单测实践也是有优先级的，如果一个系统已经很稳定，不会频繁的修改和发布，可以降低单测的优先级，把人力投入到发布频率更高，风险更大的业务。
验收测试
测试环境健康度
对于大多数公司，测试环境是阻碍效能提升的最大障碍之一。这块的健康度当然体现了工程成熟水平，如果能提供一个高效稳定的线下环境供工程师自测和联调，提效就非常显著。尤其主干环境的稳定性是重中之重。
预发环境也会因为资源有限发生争抢，还容易污染到生产数据引发故障。我们应该尽可能左移到线下的项目环境进行测试，保障多套测试环境能并行使用。
在线下完成所有的开发自测，集成测试，联调测试，最后部署到预发环境做正式发布前的验证。
主要权重指标：
主干环境的接入率: 团队线上的总应用中，多少比例的应用接入了主干环境。
主干环境的 SLA（服务水平）：当月团队应用在主干环境的平均稳定性，可以每 10 分钟做一次可用性采样。
预发环境的 SLA
构建效率
随着业务变得越来越复杂，如果不刻意治理，代码构建的效率不可避免地会被降低。我们度量构建效率，主要看构建时长和构建失败率的改善，尽可能缩短 “从代码提交到可测” 这个过程的耗时。
常见的构建提效方法有：正确配置目录，正确使用增量构建，谨慎使用 Snapshot，依赖瘦身和减少依赖深度，Docker 构建的规范化，基础软件的版本升级，代码冲突预先检查等。
主要权重指标：
构建平均时长：成功构建实例的构建编译打包时长。
用户原因构建失败率：非项目环境原因，而是用户原因导致的失败。
部署效率
应用的部署一直是非常耗时的事，它导致测试环境验证过程很漫长，还会带来线上风险。改善部署耗时的关键影响因素可以有效提升发布效率。
具体治理手段有加速应用启动的异步初始化方法，中间件的启动配置优化等。权重指标有：
生产应用启动时长：在生产环境成功部署实例的应用平均启动时长
预发应用启动时长
发布整体：返工和折返
这块效率指标作为面向发布过程的通用评分事件，观测研发团队的效能表现。
效能表现是受到多个维度影响的复杂评估对象，比如业务节奏，需求质量，需求大小，系统复杂度，交互复杂度，人员技能，技术基建等等。
只要能看到问题就有找到具体改进方法的机会。改进方法和前面多个模块的改进方法都可能有关，和 DevOps 建设的水平也强相关。
主要权重指标：
变更前置时长：从首次提交变更代码，到变更成功发布之间的时间
代码修改预发折返率。也可以统计折返次数和平均折返时长。
发布失败率
平均发布频次。
其他权重模块（可选）
对于大型公司，不同技术部门在业务上独立，但是基础技术组件上又有很多合作和复用，可以把二方包的治理水平作为可选的权重评分。二方包就是集团内部共享但非开源的基础软件包，它在跨事业部的业务中起到重要的纽带作用，也会影响集成方的体验。
在集团内部提高二方包的规范性和易用度，可以提高研发质量和效率，促进了跨部门的学习氛围，凸显了开放协作组织的价值。
主要指标：
团队代码开放率：活跃代码的已开放比例。活跃代码指近期有代码提交的代码库。
二方包合规率
对于强调线上治理水平的公司，可以选择把发布后的治理能力也做为工程成熟度的一部分，具体指标可以包括：
线上监控覆盖率（看应用基础的覆盖情况）
人均监控处理量
监控平均处理时长
对工程成熟度的总结
有些业界的成熟度模型很容易被滥用，组织容易在成熟度模型的牵引下形成惯性，不自觉地开始低级的 “内卷”，从而忘记了提升研发体验和业务满意度才是根本目标。
如果没有人认真思考高级能力该如何构建，那眼前的众多改进措施不可能持续落地，或者付出的成本高于收益。
我们希望通过工程成熟度模型来产生有效的工程文化，让研发团队看清楚改进清单，积累优秀的成功实践案例和惨痛的反模式，从而建立共识。
这个过程不可能通过行政命令达成，而是需要人和人的切磋交流，也需要卓越工程师的深度参与。
