写点什么

思码逸 X 贝壳:用代码分析,升级既有效能度量体系

  • 2022-11-03
    江苏
  • 本文字数:1474 字

    阅读完需:约 5 分钟

思码逸 X 贝壳:用代码分析,升级既有效能度量体系

客户简介

作为居住产业数字化服务平台,贝壳致力于推进居住服务的产业数字化、智能化进程,通过聚合、助力优质服务者,为中国家庭提供包括二手房交易、新房交易、租赁、家装、家居、家服等一站式、高品质、高效率服务。


项目背景

作为革新房产交易行业的产业互联网企业,贝壳的业务形态、组织文化、技术架构方面与纯互联网企业有所差异。



这些差异决定了贝壳的研发效能建设需要兼顾业务、产品、研发多方视角,以需求为效能度量核心,串连起端到端的价值交付,实现全局优化。

此前,随着贝壳的规模扩大,各业务团队间工具建设重复严重。2019 年,贝壳开始建设一站式研发管理平台 KeOnes,实现需求产出到上线环节的流程集中管理、统一规范;并继续向上游拓展,打通业务到产品环节,实现了全程可视化。

依托 KeOnes ,贝壳已经建立起以需求交付为核心的效能度量体系。


项目挑战

尽管已经搭建起效能度量体系,作为效能核心的需求指标却存在数据不全不准、颗粒度不一致等问题。

这一方面会影响度量的可信度,另一方面,颗粒度不一致也导致需求吞吐量难以预估,合理规划排期、合理分配人力资源等提效实践难以开展。


解决方案

依托代码当量指标,校准需求/ MR 颗粒度

思码逸帮助贝壳引入了编码环节的工作量指标代码当量。在贝壳看来,这个指标的优势在于直接从代码提交中解析出工作量信息。换句话说,代码当量仅依赖代码这一研发中间产物,受主观因素影响较小,且准确度优于传统的代码行数指标。

贝壳代码当量指标来量化需求的颗粒度大小,并分析需求颗粒度的分布。基于这些分析,贝壳可以了解各业务团队的需求拆分是否颗粒度稳定、大小合理;并在全面了解的基础上,建立起组织级基线,及时识别超出基线的需求颗粒度异常点并给出引导。

在引入代码当量前,贝壳使用两个指标来量化需求的大小:规划阶段的估点大小和事后统计的交付工时。估点大小受需求分析阶段主观判断的影响,而交付工时受需求状态流转是否及时的影响。代码当量可以用于这两个指标的校准,帮助团队识别估点偏差、工时记录不全不准等问题,增强需求相关指标的可信度,使效能度量更加可靠。


同理,代码当量也可以用来量化 Merge Request(代码合并请求,GitHub 中称为 Pull Request)的颗粒度,并设定 MR 颗粒度建议值,改进工程实践,避免 MR 过大带来的问题多、冲突多、测试及 debug 成本高的问题。


估算需求吞吐量,为版本规划提供参考


在前面校准需求颗粒度的基础上,贝壳从时间维度上分析了周新增当量与周交付需求个数的拟合情况。

数据显示部分业务团队的周新增当量与周交付个数的相关性较高,可使用每周新增当量的均值来估算团队的需求吞吐能力。

这一数据可以为迭代规划提供参考,辅助产研团队根据业务重心谨慎选择准入需求,合理排期,保障高优先级需求的快速交付。


展望

由于贝壳规模庞大,各研发团队的业务属性存在较大差异。为了保障度量平稳落地,基于改进的思路,贝壳工程效率团队目前向一线研发团队提供客观指标的呈现与引导,促进团队自身提效。

接下来,贝壳希望效能度量能够为一线研发管理者带来更多价值,帮助他们全面了解研发现状,并根据团队的实际情况,自主制订可执行的研发管理与过程改进措施,强健研发团队效能健康度。措施包括基于工时与代码当量,量化团队的开发负载,进而评价项目的人力资源投入健康度;基于需求类型与代码当量,识别周期内团队在不同需求类型上的工作量分布,进而合理调整研发工作重心。


思码逸 Merico 研发效能分析平台,致力于帮助研发团队解决 效率、质量和人才 三大痛点,提升研发效率与软件工程质量。点击官网获取更多研效信息~如果您想要与思码逸团队交流,欢迎在评论区留言探讨!

发布于: 刚刚阅读数: 3
用户头像

还未添加个人签名 2022-04-12 加入

还未添加个人简介

评论

发布
暂无评论
思码逸 X 贝壳:用代码分析,升级既有效能度量体系_数据_思码逸研发效能_InfoQ写作社区