数据驱动研发效能提升

1. 数据驱动研发效能提

2. 1 目录 CONTENTS 什么是好的研发效能 2 有效的度量指标 3 数据驱动效能提升案例 4 经验总结

3. 01 什么是好的研发效能

4. 研发效能的困扰产品延期质量差效率低加班很多，但产品依然延开发提测质量差，测试周期团队成员集体熬夜加班，期。长，代码返工率高，上线后大把时间花在等待环境、 BUG和故障很多等待验证上不可持续开发人员疲于应付业务，没有精力去钻研技术，团队士气低迷，生产效率低下，无法支撑持续的高效开发

5. 什么是好的研发效能持续快速、高质量地交付用户价值 2 Delivery 1 Sustaina bility 可持续性高效能需要可持续性，短期的高产出可能会伤害长期的产出，比如连续熬夜加班导致效率低下 3 Efficienc y 更短的交付周期更快的效率产品更新速度决定市场，研发团价值流动效率：各环节和部门高队快速发布产品，应对竞争日益效协作，需求顺利流畅、减少挤激烈的市场，快速试错。压和等待。 4 quality 更好的质量交付出去的产品质量尽量少的 BUG和故障，用户满意度高

6. 02 有效的度量指标

7. 2019 DevOps全球状态报告部署频率每天多次变更前置时间小时级故障恢复时间低于一小时部署频率部署代码的频率吞吐量变更前置时间从代码提交到代码成功运行到生产环境需要的时间故障恢复时间发生服务故障时（例如：计划外终端，服务受损），恢复服务通常需要的时间稳定性变更失败率小于15% 变更失败率有多大比例的变更会导致务受损或者中断，需要进行热修复、打补丁或者回滚

8. 透明研发过程数据开发 • • • • • • • • 需求 • • • • • • 需求总量需求状态分布需求交付周期需求吞吐量需求评审通过率需求变更率发布代码提交量、提交频率有效代码率代码扫描问题数代码评审次数、评审通过率单元测试覆盖率构建次数、频率构建时长构建成功率 • • • • • 发布次数发布频率发布成功率发布回滚率发布时长测试 • • • • • • • 测试用例数量功能测试代码覆盖率线下缺陷数量、密度缺陷解决时长缺陷解决率、缺陷逃逸率自动化测试持续时长持续集成红灯修复时长运维 • • • • • 资源利用率应用性能系统可用性线上缺陷密度故障恢复时间

9. 从可度量的数据中挖掘价值引领性指标改进的措施 ➢ 可预见性数据 ➢ 可控性生产研发过程提炼反馈度量指标滞后性指标 ➢ 强烈的目的性 ➢ 结论性（历史数据）改进的依据

10. DevOps度量指标 DevOps度量指标阶段需求阶段研发阶段测试阶段发布阶段引领性指标滞后性指标项目完成度（燃尽图）交付频率代码规范符合度代码提交频率重复代码率、代码圈复杂度等有效代码占比提测次数 Bug重开率自动化测试通过率、代码覆盖率千行代码缺陷率发布部署时长发布频率部署效率平均恢复时间

11. 目标矩阵方法目标（Goal）： G 保证产品交付的代码质量！ Q 研发各阶段的工作是否都 M 1 M 2 M 3 代码扫描：缺陷率控制在5‰以根据度量指标反馈的现象建立目标。问题（ Question ）：定义我们在逐步靠近目标的过程中遇到的问题，以确定进展或者目标的实现。识别矩阵并设置行动模型：使用特定的必要矩阵来组织问题的答案的方法建立度量模型，进而设置行动模型。符合这个目标？下； Code Review：必须由专人Review代码；自动化测试：单元测试覆盖率60%以上；功能测试代码覆盖率100%

12. 03 数据驱动效能提升案例

13. 案例1-团队问题团队问题：总是延期交付，团队士气不高，天天加班，质量差，到底发生了什么？需求完成数需求完成时长代码扫描缺陷数新增BUG数线上发布成功率

14. 案例1-数据的背后-找到问题需求完成时间长干活多、缺陷多缺陷重视度不高需求传统瀑布模式，迭代了一半，大家加班加点的干活，负载较重，管理不规范，优先级划分不清楚，需求还没定下来，开发时间不足一引入的缺陷也较多，PD 和用户不甚至残留重要缺陷留在 bug 列表周，开发加班加点，质量不达标。满意带来的修改又会加重工作量，里面未解决而流到了线上引发故障数据表征上就是之前需求数量较少， 9月份突然完成了很多而且时间很长的需求如此恶性循环

15. 案例1-数据的背后-改进 01 需求拆分需求细化，拆分成最小可交付产出，尽量避免一个需求做了 1 个多月才去和 PD 和用户验收。 02 快速验证随时拥抱用户，迭代式产出，交付即验收，让不准确性降到最低，在错误误差最小的时候修正 03 04 提测卡点尽早修复设置提测卡点，代码扫描高级缺陷全部清零，代码review卡点重点跟进质量管理和运营，透明数据，鼓励团队尽早尽快修复 bug，并有严格的上线前 bug 解决率标准 05 发布保证尽最大力量保证线上发布成功率

16. 案例1-改进的结果需求完成数代码扫描缺陷数需求完成时长新增BUG数线上发布成功率

17. 案例2-精准化测试保证质量精准化测试变更代码业务需求测试覆盖代码功能测试代码覆盖率功能测试

18. 案例3-有效产出量产品有效代码率 90% 800 700 600 53% 72% 500 400 60% 某个项目投入了大量人力，但产出低下，原因是什么？需求变更？人员效能？ 300 200 100 0 产品A 产品B 产品C 产品D

19. 04 经验总结

20. 度量的经验总结数据只是手段，辅助我们去诊断，而不是衡量。 C 不要用数据去度量个体，度量的初衷是通过客观指标反馈团队的问题，并引起团队关注 B D 度量不是控制，度量的目标是改善。 A 经验总结学会利用数据，不要被数据利用

21. THANKS