1. 研发效能度量 - 为了更好地驱动研发效能改进 王俊怡 - Userly CTO - 前哈啰出行研发效能&PMO负责人 - 前微盟研发效能负责人

2. 背景介绍 • 外企工作了11年 • 互联网新兵（当年新） • CI/CD，IT费用归属，项目管理，质量保障 一样又不一样 • 效能度量新的课题 • 研发效能是不是锦衣卫，和研发是不是兄弟 • 度量是给Leader做的，给HR做的，还是给谁做的 • 研发效能度量精准吗 图片来自网络

3. 缘起 – 度量-研发过程数据中的北极星指标 老板的老板经常让老板回答一个问题：招了那么多人，大家都挺忙，但是… 人都去哪儿了，人都在干嘛 每当老板想起一个新的尝试方向或者项目，很 难找到剩余的资源，也很难找合适调动的资源 重要的项目和方向是不是投入相应的人员，足 够多吗？还是过多了？ 图片来自网络

4. 缘起 – 度量-指标 从项目立项开始，做好人力投入的预估，价值产 出等评估，需要完善的管理流程和平台来支持 其中包括 • 准确的项目分级（S,A,B,C） • 正确的父子项目关系 • 准确的人力统计

5. 缘起 – 度量-指标

6. 缘起 – 度量-指标

7. 缘起 – 度量-指标

8. 缘起 – 度量-指标

9. 缘起 – 度量-指标（外企同类参考）

10. 缘起 – 度量-指标

11. 缘起 – 度量-指标

12. 开发效 率, 15% 可测 性, 20% 可维护 性, 15% 缘起 – 度量-指标 研发质量分从正确性, 可维护性, 可测性, 开发效率和数据质量五个维度, 每个维度合计100分 分项在研发质量分占比重按照当前公司需要作调整, 例如目前建议正确性占50%, 可维护性占15%, 可测性占20%, 开发效率15% 质量维度 指标 统计周期 每出现1个一次冒烟未通过需求，扣5分； 每出现1个最终冒烟未通过需求，再扣5分； 权值为 25 分。 低级bug数 每发现1个低级bug，扣5分； 权值为 25 分，扣完为 以Sprint滚动 止。 生产bug遗漏数 出现P4级生产故障，每个扣5分； 出现P3级生产故障，每个扣10分； 出现P2级生产故障，每个扣15分； 出现P1级以上生产故障，本项目0分； 权值为 25 分，扣完为 以季度滚动 止。 千行代码bug率 千行代码bug率，以2.5‰（参考CMM3级2.39‰）为基准，每低1‰，扣5分； 静态代码扫描规则 可维护性 安全白盒扫描规则 接口注释率 单测通过率 40 40 30 40 * (1 - 高优先级问题/代码总行数 * 1000) * (1 - 安全问题/代码总行数 * 1000) * 接口注释率 * 单测通过率 行覆盖率 提测服务单测代码行覆盖率高于50%，得30分，每低1%，扣 2 分； 变更行覆盖率 单测变更代码行覆盖率高于90%，得30分，每低1%，扣 2 分； 延期提测数 每出现1个延期提测，扣5分。 开发效率 bug reopen次数 bug修复时长 数据质量 备注 冒烟未通过数 正确性 可测性 研发质量分 分数计算方式 bug出现第1次reopen，扣5分，第2次，扣10分，第3次，扣20分； bug出现3次以上的reopen，本项0分； 单个bug修复时长大于4小时，每个扣5分； 权值为 止。 权值为 权值为 权值为 权值为 权值为 止。 权值为 止。 权值为 止。 25 分，扣完为 40 40 20 40 30 分。 分。 分。 分。 分，扣完为 30 分，扣完为 30 分，扣完为 以Sprint滚动 以Sprint滚动 以Sprint滚动 以Sprint滚动 以Sprint滚动 以Sprint滚动 以Sprint滚动 以Sprint滚动 以Sprint滚动 权值为 30 分，扣完为 以Sprint滚动 止。 权值为 40 分，扣完为 以Sprint滚动 止。 权值为 40 分。 以Sprint滚动 正确 性, 50%

13. 缘起 – 度量-指标 某团队在1个Sprint周期内,冒烟未通过次数为2次, 低级Bug数为1个, 生产无Bug, 千行代码Bug率为1.5‰ 服务质量分 服务 质量维 度 指标 分数计算方式 考核维度 备注 多环境治理支持 10*已部署多环境的服务比例 服务维度 预防发布故障，支持容灾。 服务治理 20分，超过50%的接口部署为满分，每减少2.5%减1分 服务维度 需对链路与接口进行配置熔断、限流降 级才能在故障发送时产生有效的保护。 性能基线 故障预案 架构 后端服务 规范检查 告警治理 代码质 静态代码扫描规则 量 单元测试覆盖率 20分*接口合格的比例 服务维度 10分，后台配置各业务线预计合格的预案数量，15*预案 服务维度 准备的比例 15分，通过规范检查工具最终核算出一个规范合格率， 10*规范合格率。第一期规范工具包含中间件的接入率。 一期：服务数/人员比例+服务QPS数达标。开发规范扫描 服务维度 合格率：接口定义规范等；sonar扫描合格率。中间件接 入率。代码重复率。 恶化的接口或资源访问将带来滚雪球的 灾难，接口或资源访问的性能应控制在 合理的范围内。基线采用动态预测的方 法。 只有充分准备预案，才能在故障发生时 快速解决处理掉。 只有满足规范的要求开发代码、sql、 发布check等才能有效的预防故障的发 生。 25分，10分检查业务告警配置的完善率，在后台设置各 业务告警的合格配置数量，计算为10*业务告警配置比率。 15分为告警治理，warning(<=30,多5个扣减1分)、 服务维度 high(<=5,多1个扣减1分)、disaster(<=1，多1个扣减2 分)，数量和分值可在后台配置 告警需配置完整才能及时发现，告警的 有效治理才能预防故障的发生。 50 * (1 - 高优先级问题/代码总行数 * 1000) 服务维度 权值为 50 分。 单测代码行覆盖率高于50%，得30分，每低1%，扣 2 分； 服务维度 权值为 50 分。

14. 缘起 – 度量-指标 某团队在1个Sprint周期内,冒烟未通过次数为2次, 低级Bug数为1个, 生产无Bug, 千行代码Bug率为1.5‰ 首屏加载时间 线上环境合成监控性能份数 线上健康 JS页面异常率 白屏率 前端服务 API错误率 npm包版本准入 架构 线上环境合成监控最佳实践份数 CI环境合成监控分数（涵盖性能及最佳实践） 代码规范 代码重复率 代码质量 基础库单元测试覆盖率 0 ~ 1秒首屏时间算100分， 0~1秒的pv量记做totalA 1 ~ 2秒首屏时间算75分，1 ~ 2秒的pv量记做totalB 2 ~ 3秒首屏时间算50分，2 ~ 3秒的pv量记做totalC 服务维度 3 ~ 6秒首屏时间算25分，3 ~ 6秒的pv量记做totalD 6秒以上 0分，6秒以上的pv量totalE 最后得分 = (100*totalA + 75*totalB + 50*totalC + 25*totalD + 0*totalE) / (totalA+totalB+totalC+totalD+totalE) lighthouse针对线上环境巡查得到的性能分数 服务维度 令js页面异常率为x 0% ~ 0.12%。f(x) = x * 100 * 10 / 12。 0.12% ~ 20%。f(x) = 10 + (90 / (0.2 - 0.0012)) * (x - 0.0012) 需 服务维度 调整。 20%以上0分。f(x) = 0; 得分 = 100 - f(x) 令白屏率为x 0% ~ 0.1%。f(x) = x * 100 * 10 / 10 0.1% ~ 10%。f(x) = 10 + (90 / (0.1 - 0.001)) * (x - 0.001) 需调整 服务维度 10%以上0分。f(x) = 0; 得分 = 100 - f(x) 令API错误率为x 0% ~ 0.1%。f(x) = x * 100 * 10 / 10 0.1% ~ 5%。f(x) = 10 + (90 / (0.05 - 0.001)) * (x - 0.001) 需调整 服务维度 5%以上0分。f(x) = 0; 得分 = 100 - f(x) 涵盖axios / vue / typescript / chaos / tangram / tian-qi / moro 等主要npm包（还需细化）。满分100分。 针对主要npm包，每依赖一个准入版本范围外的包，分数减10分， 服务维度 直到0分。 主要npm包之外的依赖包，每依赖一个alpha / beta版本的包，分 数减10分，直到0分。 lighthouse针对线上环境巡查得到的最佳实践的分数 服务维度 lighthouse针对开发环境巡查得到的性能分及最佳实践的份数，其 服务维度 中性能占比50%，最佳实践占比50% 总分100分，每条不合规范的项目减0.5分，直到0分。 服务维度 得分 = 100 - 代码重复率 * 100。 服务维度 每个npm包的分数为单元测试分支覆盖率。例如90%分支覆盖率， 则得分为90分。 npm包个数为x时， 团队维度 若x=0，此项不计分，权重均分到其他项目。 若x>0，得分 = 自研npm包的单测分数的平均分 页面异常率 = 发生js异常的页面pv 量 / 总的pv量 小程序白屏率 = 6秒内setData未调 用的pv量 / 总的pv量 H5白屏率 = 2秒内setData未调用 的pv量 / 总的pv量 API错误率 = (http状态码大于等于 400或者小于200的请求量) / (http总请求量) 使用eslint进行代码规范检查 超过（包含）5行重复则定义为重复

15. 缘起 – 度量-指标 研发效能指数 (0-100) = 45% x 质量 (0-100) + 35% x 发布回退指数 线上故障指数 45% x ... 人均机器指数 应用迭代周期 5% x 5% x 应用发布周期 产出 (0-100) 80% x 人均提交代码 + 20% x 机器使用率 + 15% x + + + 10% x 40% x + + 20% x 研发活动效率 + 10% x 45% x + 30% x 投入 (0-100) 千行BUG指数 + 10% x 40% x 效率 (0-100) 40% x ... 人均关闭需求 + 5% x 人均关闭缺陷 + + ... ...

16. 出发 – 研发数据的来源 最佳的场景是我们不生产数据，我们只是数据的搬运工，可世事通常并非如此 手撸平台，保障数据合理有效 • 有发布平台吗？有，有发布数据吗？有，但是只有次 数 • 项目管理平台有接口吗？有但是项目分组有点乱 • 质量平台有吗？有，质量还不错，但是数据没有对外 接口 • 运维监控有数据吗？有很多，你要哪个 效能 平台 • 工单系统，告警平台，…… 图片来自网络

17. 出发 – 研发数据的来源 项目集管理 驾驶舱 路线图 设计平台（管理） 项目管理 需求管理 项目计划 效能管理 仪表盘 效能分析 效能报告 计划 变更管理 进度管理 跨项目进度 产品管理 任务管理 版本管理 缺陷管理 交付物管理 迭代管理 资源管理 项目成员 工单管理 商家反馈 内部技术（稳定性） 工单流转 工单跟踪 产品设计 系统设计 交互设计 功能设计 组件库 接口设计 效能预警 质量管理 研发过程管理 用例管理 团队管理 发布管理 测试自动化 代码管理 制品管理 测试报告 应用管理 配置管理 质量门禁 数据工厂

18. 出发 – 研发数据的来源 图片来自网络 图片来自网络 图片来自网络 图片来自网络

19. 出发 – 研发数据的来源 1. 项目管理平台：Jira(直连数据库)，TAPD(对接接口)，Ones，自研 平台 2. 发布平台：对接原有平台+数据统计，重新研发 3. 质量平台：Metersphere，TAPD，自研 各对接模块 4. 运维监控平台： Zabbix， Nagios， Prometheus, 各云平台接口等 5. 告警平台： Prometheus, 自研平台 6. 工单系统：Ones，自研平台 分析展示 7. 文档及知识库管理系统 8. CMDB：团队数据，人员信息，应用信息，IT信息等 API CONF

20. 深入 – 研发平台的建设方法和内容 研发平台与发布平台，项目管理平台，测试平台，甚至架构部的各个平台的关系是什么 研发视角来呈现一切能力， 视角的转换本身就可以提高极大的效率 • 运维提供了运维平台 • 测试提供了测试平台 • 项目经理指定了项目管理平台 • 产品都给我指定好了文档的平台 • 那谁来给我提供研发平台 图片来自网络

21. 深入 – 研发平台的建设方法和内容 围绕服务提供代码管理、服务配置管理、信息查询、服务中间件资源信息查询进行管理的一站式开发辅助 平台

22. 深入 – 研发平台的建设方法和内容 摆脱gitlab混乱的权限管理，摆脱复杂的发布系统，摆脱分离的配置管理系统，使用all in one的研发平台

23. 思考 – 持续交付实践-研发过程数据的使用和参考 有了合理的平台，那么多数据，我应该来干点什么呢 让每一个普通员工变成大佬一样的效率， 让更多的经历聚焦在业务价值 • 工具链和平台提供便利性 • 数据提供管理的参考 • 没有必要纠结数据是否精准，我们要的是趋势 • 研发效能数据永远不是衡量个人的，是管理能力的试 金石，调整和运营是长期的 图片来自网络

24. 思考 – 持续交付实践-研发过程数据的使用和参考

25. 思考 – 持续交付实践-研发过程数据的使用和参考

26. 思考 – 持续交付实践-研发过程数据的使用和参考

27. 思考 – 持续交付实践-研发过程数据的使用和参考

28. 思考 – 持续交付实践-研发过程数据的使用和参考

29. 思考 – 持续交付实践-研发过程数据的使用和参考 7月 质量分、效率分 8月 质量分、效率分 效率 88 86 86 84 84 82 82 80 业务Z 业务B 业务Z 76 质量 业务L 74 业务G 78 业务G 业务D 质量 76 业务L 74 72 业务D 业务B 80 业务D 业务P 78 效率 88 业务P 72 业务D 70 70 68 68 66 66 64 46 50 54 58 62 66 70 74 78 82 86 64 46 50 54 58 X轴 - 质量； Y轴 - 效率；交叉线为均值；圆形大小代表 人均交付需求点数 62 66 70 74 78 82 86

30. 思考 – 持续交付实践-研发过程数据的使用和参考 研发效能治理完后的副产品，清晰的IT费用统计系统

31. 业务对齐（Business Alignment） -- 所有力量都汇向着选择的业务目标 良好计划（Planning） -- 找出可以计划的部分计划好 员工卓越（Employee Excellence） -- 提供更加优化的方式来衡量改进研发的工作 北极星指标（DORA Metric） -- 找出适合行业和公司的度量维度

32. Q&A 个人微信 欢迎交流

33. THANKS