跳到主要内容

代码当量

属性
指标定义代码当量是对开发工作量的一种合理估计,通过开发过程对抽象语法树的更改量计算,也可理解为源代码编译成的抽象语法树的复杂度。
指标价值

1. 与代码行数、提交数等指标等浅层统计相比,代码当量不易受到编程习惯或特定行为的干扰(如换行、注释等),并且更能反映代码开发所涉及的逻辑量或复杂度。
2. 作为代码贡献的基准指标,为研发效能提供更合理的度量,并用于对需求复杂度估算的准确性进行校准。
3. 采用千代码当量缺陷率替代千行代码缺陷率,可以有效避免人为干扰对代码规模的影响,客观统计基于规模的代码质量。

指标来源静态代码分析系统
实践域开发
认知域交付速率
度量范围项目、团队

MARI 方法

度量(Measure)

  • 从项目或团队维度,按需求周期及步长统计代码当量。
提示

度量时,需注意排除非正常生产力数据(如:框架代码、第三方合入代码等)造成的异常高值,避免对准确性造成干扰。

  • 统计分析周期内相应步长(1 周、双周、1 月)的人均代码当量,得到人均生产率数据。

    人均生产率计算公式为:人均代码当量 = 统计周期内相应步长总代码当量/代码提交者数。

分析(Analyze)

  • 累计当量趋势

    • 项目/团队累计代码当量趋势

      观察团队活跃度、代码增速合理性。对比分析同类项目,在人力接近的情况下,观察人力投入产出的差异及原因。

      • 版本周期累计当量趋势

        可通过观察即将发版的代码是否仍存在活跃的代码提交,来判断版本是否趋于稳定。

  • 人均当量趋势

    • 单值控制图

      使用控制图对项目/团队的人均当量进行分析,当一组随机生产率数据样本符合正态分布,且数据过程较为稳定(离散系数小于0.5),可通过1.96~2个标准差建立上下限进行样本数据的观察分析。

      落入上下限之外的数据概率为 5%,这部分数据通常会作为小概率事件的异常值进行识别。

  • 离散系数图

    离散系数是测量数据离散程度的相对统计量,主要是用于比较不同样本数据的离散程度。

    计算公式:离散系数 = 标准差/均值,离散系数越小代表数据的聚拢及稳定性越高。

    过程数据稳定的价值是可为数据波动提供合理的判断区间,同时基于稳定的生产率过程数据,可进行建模分析,对按期付率、工作量等变量提供预测分析。

    当离散系数大于 0.5 时,需分析数据过于分散的原因。

  • 异常值检验

    对计划建立控制图的人均当量样本进行异常值检验,如数据出现异常离群点,需对数据进行合理剔除后再进行分析。

    当数据出现显著分层,需结合实际情况分析原因,并合理选取建立过程参考基线的范围。

    控制图分析判异原则:

    • 数据点出界即判断为异常
    • 界内点排列不随机即判断为异常
    • 连续链:连续 9 个数据点在中心线之下或之上
    • 间断链:大多数数据点在中心线一侧(链为控制图中各数据点之间的连线)
    • 多数据点屡屡靠近控制界限(在 2-3 倍的标准差区域内出现)
    • 倾向性(连续不少于 6 个数据点有上升或下降的倾向)与周期性
    • 连续 14 个数据点中相邻交替上下

  • 分析控制图

    通过拟合线趋势,对统计周期内,相应步长(周/月)的生产率水平的上升/下降趋势变化进行判断。

通过生产率波动规律,可观察生产率是否存在连续上升、下降或数据分层等现象。连续上升、下降提示受产品排期、任务拆分及人力调配合理性的影响,引发的忙闲不均现象。

当数据出现向上或向下分层,通常与业务需求的紧凑性、人力资源的变化等因素相关,需进一步分析。

  • 生产率横向分析

    横向分析,有助于了解组织整体水平,建立参考基线,并识别短板进行改进。

    通过箱线图或柱状图,进行项目/团队间人均当量的横向分析,基于中位数或均值对生产率偏低或偏高值的合理性进行分析。

同时,通过效率(人均生产率)与稳定性(离散系数)双变量散点图,分析各项目/团队在不同象限的分布,分析项目/团队在效率稳定性上的表现。

使用历史基线或行业指标,对过程性能进行对标分析,以了解现状与历史生产力、行业指标之间的比较情况。

回顾(Review)

基于分析结果,聚焦少数关键异常点,采用头脑风暴对影响因素进行罗列,并进一步识别关键影响因素。

以下为可参考的回顾思路:

改进(Improve)

基于回顾结果,聚焦关键根因,盘点潜在的改善措施。

改进步骤的思考与盘点,一方面能进一步验证影响因素与问题之间的关联性,另一方面也能辅助团队制定可落地的改善方案。

以下为可参考的改进思路:

影响因素问题分析改进建议
产品排期产品排期不紧凑、缺乏规律性,导致项目/团队忙闲不匀,出现活等人、人等活的现象。

1. 参照历史生产力(生产率水平),预估季度、月度需求的交付能力,按生产率进行产品需求的排期及项目规划。
2. 建立需求、生产力、开发人数三者间的数据关联,合理预估可用资源及需求的交付周期。
3. 团队线根据产品排期节奏,参照个人生产率预估工作量,提前规划人力资源。
4. 按迭代任务计划,合理规划阶段性清理技术债及重构任务。
5. 平衡资源负载及任务饱和度。避免任务过载造成的加班赶工,及任务饱和度低引发的资源冗余。

需求稳定性

1. 需求颗粒度大,拆分不细,导致需求模糊,理解不一致,开发阶段需求频繁变更。
2. 缺少必要的需求变更控制流程,需求变更随意,缺少接收入口及规则。

1. 需求拆分尽可能细(纳入迭代需求列表时,对超过 8 人时的需求/功能进一步拆分)
2. 细分需求后,按照需求价值,优先实现最有价值且相对稳定的功能点。使每个迭代均可交付演示版本。
3. 利用历史偏差率、
开发经验,提高迭代估算的准确率。4. 建立需求分级变更管控流程,提高需求稳定性,降低需求蔓延、变更造成的返工工作量。

资源调配

1. 特定任务只能由少数人力承担。
2. 项目长时段闲置人力未得到及时释放。
3. 缺少客观衡量人力投入产出的指标数据。

1. 通过需求反讲、业务说明会、代码评审等方式,对复杂业务及逻辑进行说明及培训,实现人力备份。
2. 均衡迭代任务拆分和分配,减少任务间的串行等待时长。
3. 通过思码逸贡献者视图,分析个人累计代码增量、增速,判断人力投入产出合理性。

人力复用人力在多个并行任务间切换,降低了在单一任务的专注度,同时造成任务切换的浪费。

1. 按项目线划分团队,减少团队成员跨项目、跨业务的人力复用。
2. 对于无法避免的人力复用,提高单一任务的专注时间,避免任务间频繁切换。个人跨项目数不超过 5 个。

研发流程阶段式开发无法快速响应需求的变更,重复工作和返工加大工期的同时,降低了生产效率。

1. 对于新项目、新业务,需求不稳定的项目,采用短周期迭代模式,迭代周期不超过 2 周。
2. 各迭代需明确验收标准,每个迭代结束,需交付可演示版本进行需求确认,并作为进入下一迭代的入口准则。

评价标准

1. 缺少统一的效能评价标准。
2. 缺少评估贡献的牵引指标,形成面向需求价值和代码价值的开发氛围。(代码行不能准确体现个人/团队的贡献价值。)
3. 个体贡献的黑盒,难以形成自我管理、自我提升的驱动力。

1. 按业务差异(前端/后端)、项目阶段差异(开发阶段/维护阶段)分别建立人均生产率基线,用以分析项目/团队/个人的生产率水平及变化。
2. 有效利用开发价值排行榜作为牵引指标,客观评估贡献者价值。

代码质量单元测试、代码走查这两类动态/静态测试手段,可有效降低代码缺陷率及返工工作量。

1. 定义代码走查/评审的覆盖范围,落实编码规范,进一步提升代码质量,定义评价设计好坏的准则,提升设计质量。
2. 定义单元测试的覆盖范围。可参考的单元测试准则:
- 新平台产品类代码的前 1K-2K 代码
- 新项目第一个月的代码
- 新员工头 3 个月的代码
- 核心功能代码
- 圈复杂度高于 15 的代码 f.底层复用组件。

制定改进措施时,须从见效周期、成本投入、可行性及重要性等维度进行评估,区分轻重缓急。改进措施可采用矩阵法进行优先级评分,通过循序渐进的改进策略进行落地推进。

针对回顾结果,对阻塞环节,从规范、流程、工具、行为等方面给出针对性改进措施,明确提升目标、改进措施、验证周期及责任人。

改进成果也应当是可量化的,便于持续度量,追踪改进效果。