职场老司机@IT·互联网

从业务侧视角如何度量研发效能

2022-01-15  本文已影响0人  老猿享说

关于研发效能是否可以度量这个问题,业界有两钟对立的观点,一派是以现代管理学之父 Peter Drucker 的理论为依据,主张研发效能是能够度量的;另一派是以世界级软件开发大师 Martin Fowler 为代表,主张研发效能不可度量的。那么在老猿看来在一定范围内研发效能是可以度量的,比较直观可操作的是可以从业务侧视角几个维度来度量研发效能。详见下面阐述。

一.持续快速发布速率体现交付业务价值的速度

也就是敏捷开发的核心主张,主要有两个度量指标,分别是:

1.1发布频率,即是单位时间内有效发布次数。比如每周或每两周发布一次,这个发布频率取决于业务特性和开发团队的工程能力,当然体现研发团队对交付业务价值的响应的流动速度。

1.2发布前置时间,也就是从代码提交到功能上线花费的时间,它体现了开发团队发布能力。如果发布前置时间开销很大,发布频率是提不上来的。比如一个老旧系统,历史包袱多,每次发布前都提心吊胆,必须360度测试验证后才敢发布,这样的系统发布频率肯定很难提上去的。

二.需求响应周期。这个周期包含两个度量指标,分别是:

1.1交付周期时间,即是从确认产品提出的需求开始到需求上线所经历的平均时长。它反映研发团队对业务问题或业务机会的响应速度;

1.2开发周期时间,即是从开发团队理解需求开始到上线所经历的平均时长。它反映技术团队的响应能力。一般开发周期大于交付周期,开发周期跟交付周期时间差越短响应速度越快。

  ▎三.交付吞吐率,即是单位时间内完成交付需求的数量。

这个好理解,比如每两周发布一个版本,每个版本完成的需求数目多少体现交付吞吐率。这个有争议的点是如何拆解需求才是合理的,一般1-2人天完成的需求颗粒度拆解比较合适,这个指标更多强调单个团队的需求吞吐率变化、趋势和问题。

四.交付质量,即是交付后软件运行服务的稳定性和可用性。

同样也包含两个度量指标:1.软件发布上线后单位时间内发生的故障次数;2.单位时间内整体故障平均解决恢复时长。如每年发生P0级的故障次数及其平均解决恢复时间。这两个指标决定了交付价值的稳定性和持续性。当然这个维度指标需要整个产研团队共同来支撑保证,不只是开发团队能做到的,开发只是比较重要的一环。

以上研发效能度量指标可以在管理研发团队运用,同时跟业务方沟通协商达成双方认可的交付模式,体现研发效能输出有效方式。因为需求是永远也做不完的,业务、产品和研发都要共同关注价值,不然内耗扯皮是永远也扯不完的。


文/老猿,写代码写诗写职场的程序猿大叔,倾力原创简单实用的硬干货,转载此文请联系老猿

上一篇下一篇

猜你喜欢

热点阅读