阅读本文你将收获:
1、搞清楚什么是研发效能度量;
2、研发效能度量体系的构成;
3、研发效能度量之“MARI”实践方法论;
前言:人们常常认为软件研发度量为管理者提供了一把标尺,可以简单丈量出团队乃至个人的表现,但这个隐喻背后其实包含了对研发效能度量的一些误解,本文就研发效能管理如何建立闭环给出了答案;
什么是研发效能度量
在讨论研发效能度量怎么做之前,需要先理解它是什么。
研发是相当复杂的系统工程,导致我们很难找到一两个指标来概括研发效能的全貌。因此,研发效能度量并不是指物理度量,不是在单项指标上追求绝对精准和正确。
研发效能度量更接近统计度量,需要科学地设计度量体系,在一定误差范围内发现数据的共性规律,辅以分析和调研,挖掘根本的原因。这个关键的基础认知能够帮助我们更准确地理解和管理研发效能。
既然是统计度量,设计度量体系时需要关注两个要素:
- 系统思维
在复杂体系的度量中,任何单一指标被过度宽泛地解读、被过度简化地归因、被过度粗暴地使用,甚至削足适履,都是危险的。比如用千行代码缺陷率指标来度量代码质量,就很可能使团队陷入教条主义,造成效能“血案”。关于度量体系中的系统思维,晶磊老师之前的文章《研发效能度量:破解千行代码缺陷率引发的“血案”》有更详细的阐述。
- 制衡机制
当某些指标被赋予过多意义,工程师往往很有动力进行一些“粉饰”。这种工程师与度量体系的博弈不仅浪费精力与成本,有时还会造成负面效果,比如为了代码行数指标好看,把一行代码拆成多行,把应当抽象成函数的代码复制粘贴,反而会使代码可读性和可维护性下降。
这种情况下,可能就需要代码开发当量这类挤掉水分的工作量指标,代码复用度这类反映软件工程质量的指标来做制衡。通过度量体系的整体设计,提高“粉饰”指标的门槛,来对冲单点指标的负向牵引效应。
研发效能管理度量体系
近期完成立项的《软件研发效能度量规范》为研发团队定义并搭建度量体系提供了可参考的框架。以下对框架涉及到的概念进行解读:
- 度量
度量需要覆盖研发全生命周期,支持DevOps工具链上的不同数据源,打通需求-设计-开发-测试-交付-运营各环节,由价值流动效率串联各环节的资源效率。
- 认知
度量的直接目标是获得认知。认知被分为价值、速率、质量、成本、能力五个维度,从多个视角观察、理解软件研发流程及其成果,能够为后续的可落地、可持续的效能改进提供基础。
- 持续改进
度量不能停留在数字层面,需要层层深入挖掘根本原因,使度量带动思考和行动,建立持续改进的闭环。MARI实践方法论就是为这一环节设计,在第三部分会展开介绍。
- 研发效能
度量的最终目标是提升研发效能。研发效能包括三方面:效益,即研发效能应服务于业务交付的效果;效率,即高效高质完成任务,减少人力与资源的浪费;卓越能力,即团队工程能力需要同步提升。
研发效能管理 之MARI 实践方法
MARI是一套应用于软件效能度量实践落地的方法论,其目的是建立效能度量和改进的闭环。Amy老师结合『需求交付时间过长』案例,对MARI的思路与实操方法进行了深入解读。
MARI由以下四个步骤组成:
M 度量 Measure
无论任何改进活动,首先需结合团队实际需求,面向改进目标通过量化数据对过程及目标进行刻画,并统一数据及指标的采集方法。
在梳理度量需求时,需要辨别不同角色在不同认知维度下需要什么信息,希望借助度量达到什么目的。提前进行全面梳理和优先级排序,能帮助研发团队识别关键度量需求。同时,需要关注度量的成本和收益,忌求多求全。
A 分析 Analyze
在量化指标的基础上,运用统计分析方法,对数据的趋势、分布、关联等信息进行分析,从项目、阶段、团队乃至个人不同角度下钻,得到对现状的量化理解。
R 回顾 Review
基于分析结果,对产生“果”(结果)的“因”(影响因子)进行回顾,挖掘对结果产生影响的根本原因,定位关键少数瓶颈。回顾阶段的要点在于团队达成共识:讨论和调查不是为了甩锅,而是为了找到根因。
在实操中,团队可以从流程设置、工具体系、制度设计、资源分配等角度来筛查问题的根因所在。如果团队认为问题起源某些不可控的因素(比如一个粗心的过失),那么可能还需要继续追问和挖掘。
I 改进 Improve
针对关键问题,聚焦根本原因,建立可落地的改进措施。通过调整“因”(影响因子),最终影响“果”(目标)的达成,并进入下一轮度量验证,持续跟踪改进效果,适时调整改进策略。
改进环节的要点在于聚焦关键少数问题和关键少数瓶颈,重点突破。在推行改进措施的过程中,先制定小目标,在小团队内试点验证,循序渐进将瓶颈逐个突破,再推广至全员。另外,在改进流程和工具时,优先从自动化、减少人工干预的思路入手,避免以增加团队工作量为代价进行改进。