1-彭晶-从谈度量’色变’到度量成为日常研发的晴雨表.pdf

《1-彭晶-从谈度量’色变’到度量成为日常研发的晴雨表.pdf》由会员分享，可在线阅读，更多相关《1-彭晶-从谈度量’色变’到度量成为日常研发的晴雨表.pdf（44页珍藏版）》请在三个皮匠报告上搜索。

1、从谈度量色变到度量成为日常研发的晴雨表2023.7 北京彭晶彭晶负责AI、大数据开发团队的质量保障、测试体系建设、测试工具平台的规划及落地负责寿险科技研发度量体系建设及度量平台的规划落地平安寿险总部 质量管理团队 测试经理嘉宾照片目录CONTENTS面临现状：谈度量色变，只增工作量，不增质效？01 改变观念：让度量成为工具，而不是负担02 搭建体系：从被动要求的度量到我们需要什么样的度量03 深入应用：能有效发现问题的度量才是好度量04 获得认可：度量成为日常研发过程的晴雨表05 01面临现状：谈度量色变，只增工作，不增质效？研发度量的必要性1/2传统金融公司的IT研发团队同样需要基于研发度量

2、持续推动质效改进IT行业发展需求1.无限的需求和有限的资源冲突2.研发人员规模的边际收益递减经济发展大环境需求1.经济向下背景下降本增效的要求2.业务需要更清晰的研发效能数据透视投入产出比组织自身发展需求1.数字化背景下研发过程的数字化成为必然趋势研发度量的必要性2/2生产问题多，技术团队交付质量差技术团队响应慢，需求积压业务方的抱怨需求质量差、文档不清晰、澄清需求耗时多临时插入需求需求变更频繁测试验收缺陷不及时开发的抱怨需求/技术方案变更未同步提测质量差，冒烟测试不通过提测延期了，压缩测试时间缺陷修复未自测，反复验证测试的抱怨一直在说人不够、很忙很忙，但是业务方反馈需求积压、响应慢，不知道你

3、们在忙什么业务经常投诉生产问题很多管理者的抱怨实际研发中遇到的各种问题，需要通过度量数据来找到背后的原因金融公司的特点：管控？VS改进？集团研发管理要求各子公司研发团队统一的指标库，标准一刀切公司级QA，如何落地？被动接受任务结果：达成任务？vs 研发最佳实践？任务的方式强制推动指标设计的挑战落地的挑战角色分工的特殊性：研发质效改进缺乏统筹角色不同角色的职责定位不同，关注局部，缺乏整体研发质效闭环的统筹角色02改变观念：让度量成为工具，而不是负担打破角色分工的约束，重塑质量团队的职责1.测试岗位的特殊性，天然具备研发全流程质量把控的优势2.独立的质量团队具备资源整合和协调推动的优势开展业务测试

4、需参与从需求评审到生产上线的全过程处于链条末端，熟悉全流程的研发规范生产质量是质量保障的最终的交付结果对过程质量的管理和分析，可以推动整体的效率和质量左移基于质量团队的角色优势，由质量团队来牵头度量体系建设工作，统筹推动研发质效改进让度量成为工具，而不是负担度量指标重点在于推动研发质效问题的发现和改进，不是为了完成任务03搭建体系：从被动要求的度量到我们需要什么样的度量迭代过程质量管理现状问题分析及改进只局限于各开发团队内，经验难以复制，无法改善科技整体的研发质量基线各团队独立行为实施情况依赖于各自组织者成熟度不足之处指标项选择不同相同指标口径不同手工统计分析脚本或工具平台统计分析不同团队存在

5、从0到1的重复建设数据只能应用于各自团队内，无法应用于分析科技整体情况最佳实践在科技整体层面推进无抓手经验教训难以复制指标或口径不统一采集统计方式不统一体系或平台重复建设数据无法互通无法推动整体改进线上质量管理现状问题分级缺少支撑问题改进缺少目标定级不统一、边界模糊问题处理流程在消除异常后就终止缺少整体性的复盘分析及改进治理改进无法持续质量变化趋势缺少数据下钻效果无法评估线上问题数据分散在各个平台部分问题缺少记录或线下维护缺少数据底座缺乏统一的定级标准、统一的问题管理、统一的问题复盘及改进，无法掌握全局线上质量情况研发生命周期关键活动需求阶段需求阶段需求评审需求变更开发阶段开发阶段开发提测设计

6、代码评审用例设计评审测试阶段测试阶段冒烟测试系统测试UAT测试抓到一个是一个？抓到一个是一个？生产运营阶段生产运营阶段业务验收告警与监控运营配置管理发布阶段发布阶段发布评审版本验收质效问题覆盖从需求到生产运营阶段的研发全生命周期各个关键活动，需分别建立度量指标度量体系建设路径推推动动质效质效改进改进合理合理设计设计有有效牵引效牵引.数据驱动数据驱动持续改进持续改进透明质量透明质量了解现状了解现状指指标设计原则标设计原则1.借鉴行业经验，立足自身实际需求2.广泛沟通，达成一致3.兼容不同团队应用类型及发展阶段指标体系内容指标体系内容1.覆盖需求到生产全研发周期2.结果指标、过程指标的分层指标体系