寻找合适的研发效能度量指标（上）
最近几年 “软件研发效能” 成了业界的热词 ，频繁出现在各个行业大会，被各大厂、传统行业数字化部门、追求高效能的团队不断的提及并迭代，比如阿里的效能改进211愿景，腾讯的智研平台，百度工程能力白皮书。那么为什么软件研发效能会成为热词，有哪些合适的软件研发效能指标呢? 本文想尝试回答这两个问题。(本文是此系列的上篇，后续两篇将尝试构建一个根据团队上下文的软件研发效能推荐指标图表，和一些实际度量指标的案例。)
为什么软件研发效能会成为热词？咱们先看看现有的问题， 与传统制造业相比，软件研发行业还很年轻，并没有达到传统行业的大规模流水线的生产方式，这解释了为什么没有一种统一的，被广泛认可的方法来衡量开发人员或研发小组的效能。研发效能的度量很大程度上取决于公司的类型，规模，文化，与之合作的项目类型以及其它诸多因素。甚至某些小而精，依靠聪明才智和资深经验的创业团队，不用度量研发效能，团队依然非常高效。很显然，10年前使用代码行数(Lines of code)来度量研发效能的方式已经不适用现代敏捷过程对软件研发的理解了。以前关注代码产出，而不是业务成果，以前关注个人绩效，而不是团队效能。例如: 随着公司和开发人员向着价值驱动和基于团队开发方向的转变，代码行数不再具有任何意义。100行代码是否比20行好？行数是否告诉你取得了良好的进展，还是只是一个没有上下文的抽象指标？软件企业都在寻求其它有效的指标来度量研发效能。同时，如今的软件行业已经不再是“以大吃小”的时代了，而是转变成了“以快吃慢”的时代。对于很多大型软件企业、传统行业的数字化部门。原本“大”是优势，现在却陷入了“大船难掉头”的尴尬。如何破局？研发效能具体来讲就是从需求转化成软件或者服务的能力。改善研发效能从某种方面也在试图解决“大船难掉头”的尴尬。研发效能试图在解决度量和让研发变快的问题，那为什么会成为热词? 为什么最近几年各大厂、传统行业数字化部门、追求高效能的团队，都纷纷开始在研发效能领域发力，我认为这背后的原因有以下四点：
从外部技术视角来看：研发效能的土壤和环境已经就绪，类似高速移动网络的普及为智能手机和App培育了土壤和环境。4G移动网络的普及，让人们可以方便、快速的接入互联网，为智能手机和App铺好了路。现代软件研发的各个环节已经全面数字化，为研发效能的数据收集和度量做好了准备。比如: 电子看板管理任务状态，可数字化团队协作情况。Git等工具管理代码提交，可数字化开发过程。持续部署流水线管理发布过程，可数字化发布情况。DevOps云上编排、监控，可数字化产品运行状态。
从组织内部视角来看：很多公司都有“谷仓” (The Silo Effect)，伴随着市场竞争的日趋激烈，“谷仓” 效应越发突出，局部优化但是无法全局优化，破局“大船难掉头”的尴尬势在必行。开发到测试的衔接完成了优化，但是当用户需求被设计好以后需要很长时间才能传递到开发，当产品上线后，线上问题需要很久才能从运维传递给开发并修复，影响了全局效率。基于协作流程的优化，打破流程中的“谷仓”，去除不必要的等待，让价值流动快起来，也是研发效能试图解决的问题。
从公司业务视角来看：组织发展规模化，技术驱动商业差异化，然而IT交付工厂化，难以应对市场的快速变化。传统企业对于IT投资，追求ROI最大化以及交付过程的透明化，从而缓解市场带来的压力，提升差异化竞争力。研发效能度量的核心是提供数据支撑这个目标的达成，基于数据持续改进。
从外部资源视角来看：以前业务的快速发展靠烧钱、人海战术换取更快的市场占有率，从而达到赢家通吃。那时候关心的是软件产品功能产出，研发效率可以用人、用钱填上。但是随着时间的推移，还有这么多从业人员可填吗？即便有了这么多人还能砸这么多钱吗？每年从事软件研发的毕业生有限，然而行业对人才的需求从没削减过，当抽干一线城市的人才，各个大厂已经开始热衷去二、三线城市的大学招人了。同时，随着产品利润的下降，需要更多的获客，回馈客户，需要开始节流了，节流就是研发效能的提升，同样的资源，同样的时间来获得更多的成果。
上面基本回答了研发效能为什么会成为热词，那什么才是软件研发效能中合适的指标呢? 要度量哪些指标和数据呢？根据不同的场景和目标人群需要给出相应的度量指标。正如《关键对话》中建议的，需要根据信息接收者的兴趣点来构建沟通策略和沟通内容。从研发效能DevOps角度 《Accelerate》 这本书给出了4个指标和评价标准。研发效能是一个比较大的话题，如何根据不同的关注点，给出不同的指标呢？Roy Osherove 的 “Lies, Damned Lies, and Metrics”也给出了很好的归类。根据我们在项目中的实际使用和经验总结，这里把当前常用的度量指标归类如下：
规划进度：评估进度，获取背景信息和上下文，知道任务何时完成，预测问题（未来），对问题复盘与回顾（过去）。
燃尽图 (每个迭代/每个发布) （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)
下篇，将尝试使用项目类型，合作方式，等因素做为维度，放入已知的这些指标，构建一个推荐图表。帮您在了解这些情况之后，选择合适的指标。同时也会列举一些实际度量指标的案例（中篇），并讨论前置业务不明朗时 (fuzzy front end)，如何统计前置时长(lead time)的起始时间。
- 相关阅读 -