关于研发效能是否可以度量这个问题，业界有两钟对立的观点，一派是以现代管理学之父 Peter Drucker 的理论为依据，主张研发效能是能够度量的；另一派是以世界级软件开发大师 Martin Fowler 为代表，主张研发效能不可度量的。那么在老猿看来在一定范围内研发效能是可以度量的，比较直观可操作的是可以从业务侧视角几个维度来度量研发效能。详见下面阐述。
▎一．持续快速发布速率体现交付业务价值的速度
也就是敏捷开发的核心主张，主要有两个度量指标，分别是：
1.1发布频率，即是单位时间内有效发布次数。比如每周或每两周发布一次，这个发布频率取决于业务特性和开发团队的工程能力，当然体现研发团队对交付业务价值的响应的流动速度。
1.2发布前置时间，也就是从代码提交到功能上线花费的时间，它体现了开发团队发布能力。如果发布前置时间开销很大，发布频率是提不上来的。比如一个老旧系统，历史包袱多，每次发布前都提心吊胆，必须360度测试验证后才敢发布，这样的系统发布频率肯定很难提上去的。
▎二．需求响应周期。这个周期包含两个度量指标，分别是：
1.1交付周期时间，即是从确认产品提出的需求开始到需求上线所经历的平均时长。它反映研发团队对业务问题或业务机会的响应速度；
1.2开发周期时间，即是从开发团队理解需求开始到上线所经历的平均时长。它反映技术团队的响应能力。一般开发周期大于交付周期，开发周期跟交付周期时间差越短响应速度越快。
▎三．交付吞吐率，即是单位时间内完成交付需求的数量。
这个好理解，比如每两周发布一个版本，每个版本完成的需求数目多少体现交付吞吐率。这个有争议的点是如何拆解需求才是合理的，一般1-2人天完成的需求颗粒度拆解比较合适，这个指标更多强调单个团队的需求吞吐率变化、趋势和问题。
▎四．交付质量，即是交付后软件运行服务的稳定性和可用性。
同样也包含两个度量指标：1.软件发布上线后单位时间内发生的故障次数；2.单位时间内整体故障平均解决恢复时长。如每年发生P0级的故障次数及其平均解决恢复时间。这两个指标决定了交付价值的稳定性和持续性。当然这个维度指标需要整个产研团队共同来支撑保证，不只是开发团队能做到的，开发只是比较重要的一环。
以上研发效能度量指标可以在管理研发团队运用，同时跟业务方沟通协商达成双方认可的交付模式，体现研发效能输出有效方式。因为需求是永远也做不完的，业务、产品和研发都要共同关注价值，不然内耗扯皮是永远也扯不完的。
文/老猿，写代码写诗写职场的程序猿大叔，倾力原创简单实用的硬干货，转载此文请联系老猿
