最近阅读了公众号 Thoughtworks 洞见的系列文章《寻找合适的研发效能度量指标》，记录一下要点：

《寻找合适的研发效能度量指标（上）》

  • 有哪些合适的软件研发效能度量指标呢？从以下几个方面列出了一些指标：
    • 规划进度
    • 快速反馈
    • 团队转型
    • 辅助决策
    • 工程能力

当您在为团队寻找研发效能指标时，其实并没有一个恒定不变的模板，需要分析多个因素，选择最适合您的指标，并与团队一起不断的使用它们，不断的根据价值交付为导向来修改和迭代。 您自己团队的度量指标很可能与其他公司或团队的指标完全不同，这是完全正常的事情。 因为正如前面提到的，研发效能的度量很大程度上取决于公司的类型，规模，文化，与之合作的项目类型以及其它因素。

《寻找合适的研发效能度量指标（中）》

在一线开发过程中对效能的三个观察和观点：

  • 莫让度量变目标。让度量指标和数据收集尽量真实，需要关注的是趋势和阻塞。

    经济学家查尔斯·古德哈特在1975提出了古德哈特定律 : When a measure becomes a target, it ceases to be a good measure. “当一个度量本身成为目标时，它就不再是一个好的度量”。 让度量指标和数据收集尽量真实，需要关注的是趋势和阻塞。

  • 无法拆解的度量指标，可能不是一个好的度量指标。

  • 可持续扩展的度量，才可能驱动价值流的增效。

    • 从DevOps工程实践开始，关注此方面的度量和指标，有了完善的CI/CD，但不一定快速的响应了客户的需求。
    • 所以需要持续扩展度量，驱动价值流增效。

《寻找合适的研发效能度量指标（下）》

三种项目类型：通过识别项目类型来找到此类型合适的度量指标，这可能是一个快速高效的方案。

  • 绿地：新项目，不与其他（遗留）系统集成，无历史包袱。

    • 选择 “辅助决策、工程能力” 为首要指标。关注端到端的价值流，保证初期就有良好的工程实践落地。
    • 选择 “规划进度、快速反馈” 为次要指标，辅助端到端价值流度量的达成。

  • 黄地：在现有（遗留）项目基础上开发和部署新的软件系统，需考虑与现有系统共存。有一定的历史包袱。

    • 选择 “规划进度、工程能力” 为首要指标。关注交付任务的进度、架构和工程能力的改善。
    • 选择 “辅助决策” 为次要指标，拓展功能交付所产生价值的度量，促进端到端的价值流度量。

    接手此类项目一般会有很多协调和沟通工作，“谷仓”（The Silo Effect）严重，一开始就想从需求源头度量比较困难，从交付延展至价值度量是一个更合适的方式。

    • 可以加入 “团队转型、快速反馈” 这两类指标为首要指标，协助完成变革诉求。

  • 红地：系统进入维护期，不开发新功能，只修复 Bug，进入消亡期，后期考虑被新系统取代。

    • 选择 “规划进度” 为首要指标，保证有良好的 Bug 修复吞吐量。
    • 选择 “快速反馈” 为次要指标，帮助加速发布周期从而快速响应终端用户的 Bug 诉求。

度量债与治理

  • 与技术债类似，会有利息，越早重视越好。
  • 与技术债的治理方法类似，尽量只留下谨慎的（Prudent），避免鲁莽的（Reckless），不管是故意的（Deliberate）还是无心的（Inadvertent）。

基于项目类型的效能指标推荐图

未经许可不能引用，因此，请点开原文查看……

https://mmbiz.qpic.cn/mmbiz_jpg/aaVJqS7LaMI08IrXcFKuK9VTickbIia8KyOYDbgeV3doNYe4YyRy3jWupbocNnbeaoRmibyHVqaNVnWXXentQxZAw/640

五个方面的具体指标

规划进度：评估进度，获取背景信息和上下文，知道任务何时完成，预测问题（未来），对问题复盘与回顾（过去）。

  • 燃尽图 (每个迭代/每个发布) （Burn down chart sprint/release)
  • 速率图 (Velocity chart)
  • 标准差 (Standard deviation)
  • 吞吐量（Throughput)
  • 累积流程图 (Cumulative flow diagram)
  • 控制图 (Control chart)
  • 看板 在制品限制图 (Kanban WIP board)

快速反馈：持续集成，持续部署。

  • 构建与部署速度 (Build & Deploy speed)
  • 测试速度 (Test speed)
  • 代码签审时长 (PR approval Time)
  • 单元测试通过速率 (Unit tests passed)
  • 集成测试通过速率 (Integration tests passed)

团队转型：使用特定指标来衡量不同工作方式的方法，可以影响行为，帮助改变人们的行为方式。也可以向管理层说明某些事情不合理，需要改变，或者说明需要更多的时间和预算。

  • 结对编程的时长 (Pairing Time)
  • 手工测试的时长 (Time spent manual testing)
  • 代码签审时长 (PR approval Time)
  • 修复失败构建的耗时 (Fix red build time)
  • 修复Bug的耗时 (Cost of fixing bug in Dev/Prod)
  • 测试覆盖率 (Coverage test count)
  • 功效分配比率 (Effort allocation, New work / Unplanned work or rework / Other work)

辅助决策：可进行实验并不断寻找新的度量指标，帮助做决策。

  • 前置时长 (Lead time)
  • 发布出去的Bug数 (Escaped bugs 线上逃逸Bug数)
  • 功效分配比率 (Effort allocation, New work / Unplanned work or rework / Other work)
  • 交付的价值 (Valued delivered)

工程能力：4 key metrics 度量并找出团队工程实践的弱点。

  • 变更前置时长 (Lead Time for Changes)
  • 部署频率 (Deployment Frequency)
  • 变更失败率 (Change Fail Rate)
  • 服务恢复耗时 (Time to restore service)