项目背景

‍

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

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

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

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

‍

项目挑战

‍

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

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

‍

解决方案

‍

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

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

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

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

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

‍

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

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

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

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

展望

‍

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

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

‍