陈泽荣-研发效能数据治理

中国DevOps社区峰会2023·广州 研发效能数据治理 Agilean高级咨询顾问陈泽荣 目录 1 2 Agilean-adapt-研发效能数据治理 Agilean-adapt-研发效能数据治理 揭秘研发效能研发效能困境 3破局-数据治理 Agilean-adapt-研发效能数据治理 4破局-工具助力 5破局-组织保障 6Q&A Agilean-adapt-研发效能数据治理 Agilean-adapt-研发效能数据治理 揭露研发效能本质 研发效能的本质 Agilean-adapt-研发效能数据治理 研发效能的现象 ap Agilean-adap Agilean-adt-研发效能数据治理 研发效能数据治理 t- ilean- 业务成功 赞 快 多 快速响应 高效交付 交付速率 好 交付质量 以质量为牵引探索长期效率 质量指标牵引工程资产沉淀和架构演进 以吞吐率对齐科技产能，做到已知约束下探索更高的业务价值 以时效对齐业务感知和预期 以流动效率为牵引持续提升团队交付能力（包括团队协作，研发节奏等） 对齐业务预期，做到短期高质量承诺，透明研发进度 组织战略 组织阵型 业务交付 能力 adapt-研发效能数据治理 Ag 研发效能本质 Agilean-adapt-研发效能数据治理 研发效能当前现象 数据不准，没参考价值 Agilean-adapt-研发效能数据治理 数据不全 以后我就只看数了怎 么看 ？ 谁看？ 数据太多，看哪些 可不可以告诉我有问题的数据是哪 些？ Agilean-adapt-研发效能数据治理 工具和我的流程不一样 数据没有太多参考价值…… Agilean-adapt-研发效能数据治理 Agilean-adapt-研发效能数据治理 研发效能困境 Agilean-adapt-研发效能数据治理 研发效能的困境解析 研发效能数据治理 - ean-adapt Ag il t-Agilean-adap 研发效能数据治理 n-adapt- Agile 研发效能数据治理 a 详解研发效能困境根因 预期偏差 领导层期望过高，不具备可行性，精准度量人效，度量和KPI对等；没有预期，不看数，不和实际管理场景结合。 没有对齐度量目标，没有以终为始 为了度量而度量，和管理层实际管理需要背道而驰度量目标不清晰，度量对象不清晰 数据脏，数据不可信 线上线下不同步，线上化不及时；出现人为的数据操纵，缺乏可信度 工具缺失数据治理的功能 工具缺失多角度验证和下钻分析的能力，导致数据治理无从下手 缺乏组织机制保障来推进数据持续改进 组织缺乏“军师”、“参谋”来定期看数，数据解读，异常数据捕捉，决策上升 Agilean-adapt-研发效能数据治理 Agilean-adapt-研发效能数据治理 破局-数据治理 对体系 对人数 Agilean-adapt-研发效能数据治理 对吞吐 对时效 对内容 对质量 Agilean-adapt-研发效能数据治理 六对研发效能数据 对体系 •对齐需求体系 对质量 •对齐实践质量 Agilean-adapt-研发效能数据治理 •对齐线上线下质量 对内容 •对齐实践、规范 •对齐小队人数 对人数 对吞吐 •稳定团队吞吐，减少波动 Agilean-adapt-研发效能数据治理 •对齐吞吐的真实性 对时效 •契合协同产生的数据 •脏数据控制 稳敏双态的乱像 研发效能数据治理Agilean- 业务/产品 没问题，但是规定需要以敏态需求的方式提，不t- Agilean-adap 能用稳态需求提…… 研发 对对对，我们针对敏态和稳态有专门的流程 adapt-研发效能数据治理 这里有个需求，XXX，背景是……，我已经提需求了 稳敏双态的区别在于组织阵型，控制点差异而不在于研发流程 -研发效能数据治理 有些PM/教练 tAgilean-adap 稳态流程和敏态流程不一样，研发数据没法统一 什么时候用敏态还是稳态？都是开发测试上线，有啥不 一样？ Agilean-adapt-研发效能数据治理 Agilean 鉴于国内金融组织的业务特点，我们推荐采用需求-系统功能-个人任务的需求管理体系： ilean-adapt-研发效能数据治理 需求：提供完整业务价值，能够细化到一次发布完整上线的程度。 作量。Ag 需求层（单个需求在1个产品版本周期 以需求1人，如需求2用例编研发效能数据治理需求N天工作 t- 系统功能层（单个系统功能在10人天以内，单小队Agilean-adap 单迭代） 系统功能：需求被拆分到不同系统，每个系统功能必须对应到单个系统，可测试，建议每个系统功能不超过10人天工 内）个人任务：将系统功能分解到个 量。 前端开发任务、后端开发任务、测试 写，建议每个个人任务不超过3人 书同文、车同轨，统一研发术语，统一度量衡 系统功能A 系统功能B 系统功能C 系统功能D 系统功能E Agilean-adapt-研发效能数据治理 「需求」价值流* 活动频率： 迭代内按需 每年每月 每版本 Agilean 提� 已优选 编写中 已业务评审 待排期 已排期 研发中 待验收 待上线 已完成 优 选 优 待需求已选 需 列 表 需 列 表 求优选求 业务技术 研发效能数据治理 评审评审 待需求需求 排 期 求 列 表 需排期验收 完成需求拆分，提供用于需求排期的系统功能列表t- Agilean-adap 「系统功能」价值流* 小 能迭代计划待办开发中待测试测试中已完成队部 系 统功 列迭 表 代落 每日站会研发效能数据治理回月 顾度 开发设计代码评审用例评审桌面检查会经营 会 t- 共识价值流，明确关键环节DoD，和实践结合构建协同基础 Agilean-adap 「版本」价值流*形成可测试版本，进行多轮测试 已规划测试中已封版已回归已完成 版 功 本版本 能封板 列 表 潜在 本 版本版版本 付 回归交发布 列表 备注：实际价值流可有所增加或裁剪 Agilean-adapt-研发效能数据治理 六对研发效能数据 对体系 •对齐需求体系 对质量 •对齐实践质量 Agilean-adapt-研发效能数据治理 •对齐线上线下质量 对内容 •对齐实践、规范 •对齐小队人数 对人数 对吞吐 •稳定团队吞吐，减少波动 Agilean-adapt-研发效能数据治理 •对齐吞吐的真实性 对时效 •契合协同产生的数据 •脏数据控制 - 研发效能数据治理 apt n-adapt- Agil Agilean-ad Agilean-adapt-研发效能数据治理 ea 研发效能数据治理 对人数：盘部门、团队、小队，小队齐业务线/系统线 盘 部门 盘 业务线 盘 团队 盘 小队 业务域系统 小队融合团队行会 团队长产品总监架构师版本经理 产品 示例产产产 品品品 小队长 BA 开发测试 UI 行会 虚拟小队度量单元构建行会机制 小队人数约定合理的管理半径内， 人数在7±2 特殊小队可结合系统复杂度进行划 分，不受严格7±2约束 构建有特定业务领域/系统支持的 小队 不受现有的职能团队划分影响 支持虚拟小队的度量体系，并按虚 拟团队做聚合 Agilean-adapt-研发效能数据治理 研发效能数据治理 对人数：组织阵型线上化 t- Agilean-adap 研发效能数据治理 t-Agilean-adap 盘 角色 盘 编制 盘 地域 组织阵型，部门、团队、小队划分线上化小队人数、角色、地域、编制线上化 人事系统 Agilean-adapt-研发效能数据治理 六对研发效能数据 对体系 •对齐需求体系 对质量 •对齐实践质量 Agilean-adapt-研发效能数据治理 •对齐线上线下质量 对内容 •对齐实践、规范 •对齐小队人数 对人数 对吞吐 •稳定团队吞吐，减少波动 Agilean-adapt-研发效能数据治理 •对齐吞吐的真实性 对时效 •契合协同产生的数据 •脏数据控制 避免波动太大，避免断流 需求漏斗控制稳定流（对于超过区间的需求需要专项治理跟进） ilean-adapt-研发效能数据治理 Agilean-adapt-研发效能数据治理 对吞吐：指标相互验证 迭代吞吐量波动分析 Ag 影响需求规划控制稳定流入 版本/迭代完成率 用户故事人均吞吐量 用户故事有父需求的占比（指定区间用户故事有产品需求/用户故事的总数，专项治理） 产品需求人均吞吐量 用户故事研发周期（开发中~测试完成） 衡量是否影响故事过度拆分 •小队人数没变的情况下，故事吞吐量明显提升，但是研发周期没有降低 Agilean-adapt-研发效能数据治理 警惕 古德哈特定律：如果一个指标变成了目标，它将不再是一个好指标 研发效能数据治理 对吞吐：需求漏斗来观察价值流动，减少开发并行数 Agilean- adapt- 需求意向数（未开始） 希望记录下来的产品创新一项 比例低于1T：说明创新不足，或体外管理意向比例高于6T：需求进行进行定期意向清理，否则大量的堆积需求没有反馈会影响业务满意度比例低于0.8T时，需要观察下待排期需求数 待排期需求数低于0.5T时，则未来月份可能会导致需求断流待排期需求处于合理值时，则是需要推动产品和业务及时优选需求，补充需求待排期需求高于1.5T时，无断流风险 比例过高：警惕因产品经理并行度过高，而带来浪费 如果待排期需求数低于0.5T，则需要分析编写中需求停留在那个状态，及时推动需求往待排期移动 比例低于0.5T：则有可能导致需求断流 需要推动编写中的需求数及时流动如果本月研发测试需求数低于0.8T，则需求接下来存在断流如果本月研发测试需求数高于1.5T，则有当前月�现了过度承诺，团队会�现超负荷运作，会导致当前迭代完成率偏低 比例高于1.5T：有可能是研发消耗需求的能力跟不上 如果本月研发测试需求数低于0.8T，则说明排期有问题或者需求是批量提过来的如果本月研发测试需求数高于1.5T，则需要分析是不是常态情况，如果是，可能是研发研发满足不了业务 需要，需要做业务优选或者团队扩容 比例低于0.8T 待排期需求数高于0.5T时，需要分析是不是人员减少导致团队需求容量减少或者是否是待排期需求存在批量移交的情况导致的或者就是需求断流 待排期需求数低于0.5T，需求断流或者团队人员减少 比例过高：可能会因研发测试并行度过高，而带来浪费 监控吞吐量的变化情况如果需求吞吐量�现升高，结合升高幅度，判断是否是需求拆细，人员增加、人员能力提升带来的产能提升等原因导致的 如果需求吞吐量�现降低，结合降低幅度，判断是否是团队人员减少、需求较复杂，需求较大等原因导致 1T–6T 编写评审中需求数（已初选+需求分析+待需求评审） 在途的需求数量该值作为整个需求漏斗的基准值 Agilean-adapt-研发效能数据治理 0.8T–1.2T 研发效能数据治理 待排期需求数（待排期+已排期（未来月份）） 所有已通过业务内审、且通过技术评审，但未排期的需求数 或已排期但是属于未来月份的需求数 0.5T–1.5T t-Agilean-adap 本月研发测试需求数 （已排期（本月）++研发中+待验收+待上线+本月上线） 在途的需求数量该值作为整个需求漏斗的基准值 0.8T–1.5T 需求吞吐量 （上月，3个月，半年）该值作为整个需求漏斗的 基准值 T+-x% Agilean-adapt-研发效能数据治理 六对研发效能数据 对体系 •对齐需求体系 对质量 •对齐实践质量 Agilean-adapt-研发效能数据治理 •对齐线上线下质量 对内容 •对齐实践、规范 •对齐小队人数 对人数 对吞吐 •稳定团队吞吐，减少波动 Agilean-adapt-研发效能数据治理 •对齐吞吐的真实性 对时效 •契合协同产生的