规范化 GQM 指标体系
1. GQM 的规范化
GQM 即 Goal/Question/Metric(目标/问题/指标),是软件工程领域进行系统化度量和分析的一个框架Basili(1984) vanSolingen(2002) Ren(2022),被称为研发效能度量方法的“事实标准”。
- 在概念层,目标定义度量的目的(如“改进”)、对象(如“需求交付”)、维度(如“速度”)以及关注的角色(如“项目经理”)。
- 在操作层,以问题的形式拆解目标,刻画度量的模型及其组成,例如:“需求交付延迟的瓶颈在哪里?”
- 在量化层, 每个问题对应回答问题所需的指标及其分析方法。
- 更多了解 GQM,请参见《GQM 从入门到精通》。
- GQM 解决收集哪些有效数据和数据如何分析的问题,即 MARI 方法论中的“M”和“A”;而数据的使用和后续行动由 MARI 方法论中的“R”和“I”涵盖。指标字典给出了每个指标对应 MARI 的详细描述。
MARI 的规范化 GQM 是在 GQM 框架基础上的进一步发展,结合了国内外众多企业的实践,称之为“GQM 2.0”。定义目标和问题,需要确保其实用性和规范性:
- 实用性:GQM 框架原本为专业的软件工程分析人员设计,而我们的指标体系直接服务开发团队,需要更多从终端用户的视角进行实用化,同时支持直接可用的产品实现。
- 规范性:传统软件过程改进咨询服务,依赖咨询专家个人的经验和水平,无法系统地在其他开发团队复刻和持续应用。我们的指标体系旨在结构化软件工程分析的过程,对基本的单元进行抽象和规范。
综上,MARI 指标体系将 GQM 框架实用化,对分析实践进行规范化,是开发团队实现效能洞察的最佳实践指南。
2. 规范化目标体系
现代 GQM 框架Ren(2022)定义了目标的四个要素,我们对其具体实现做了如下几方面简化,以利于实用。
- 对象:过程、产物、资源等对象通常都具有层级结构,比如软件作为产物包含组件、文件等,团队作为资源通常包含下一级团队。我们在定义目标时采用更高层的通用对象,而将下层对象的分析实现为数据的下探,而非设定新的目标。
- 维度:虽然维度是开放集合,我们将其归纳为认知域中规定的一个推荐集,可从中选取。这样的有限集合有利于规范化,应用统一的分析方法和专家系统等技术。
- 目的:在实践中,了解和评价往往伴随而生,单纯刻画对象(即“了解”)而不与其他对象对比(即“评价”)无法满足用户的信息需要,所以我们将两者归并称为认知(know);改进和控制都是希望通过开发过程对指标的变化做出干预,我们统称为管理(manage);预测是相对独立的目的,保持一个单独的门类。
- 角色:通常一个目标可服务多个角色,所以我们将角色视为 (对象, 维度, 目的) 三元组定义的基本目标上的一组标签。在效能度量产品中,用户可根据自身角色访问对应标签的目标。
综上,MARI 中的目标以如下的形式定义:
(认知|管理|预测)<对象>的<维度>,适用于{角色}
其中,()
表示选择其内有限集合中的一个元素;<>
表示其内概念的一个实例;{}
表示其内概念的一个或多个实例。下文亦采用相同的符号含义。
例如:认知项目需求的交付速度,适用于高级管理者、项目经理、开发者。
3. 规范化问题体系
在 GQM 框架中,针对特定目标可以灵活地提出问题。这种灵活性需要专家经验才能很好地运用和把握,有时也反映个人的处理方式。但应用 MARI 的开发团队未必在 GQM 方面有特别多的经验,也不一定要成为这方面的专家。为此,我们总结了问题的基本范式。以规范化的方式提问,有助于开发团队复刻行业经验,快速有效建立 GQM 度量和分析体系。
现代 GQM 框架Ren(2022)中的“速查表”举例说明了提问的方向。我们将这些问题具体化为如下一系列模板,并进行了统一编码以方便梳理和应用。
问题角度及编码
为了认知和管理目标,我们需要围绕目标的对象和维度深入提问。相应地,问题模板以 QT-<O><P><T>
格式编码,其中 <O>
标记围绕对象(objective)的提问角度,<P>
标记围绕维度(perspective)的提问角度,<T>
标记围绕时间(time)周期的提问角度。
围绕对象有如下三种提问角度:
- 问对象整体,标记为
O
(overall)。直接对目标对象整体提问。对象可能是一个元素,也可能是一个集合(但指标最终由集合整体得出而不是其中个体)。例如:该项目的需求吞吐量怎么样?软件交付后的缺陷有多少? - 问对象同类,标记为
G
(group)。与同类对象比较,是建立“参照系”的一类典型做法。进行对比的“同类对象”可以是具体的一个集合,也可以是特定集合上抽象的统计值(如组织的基线、行业的基线等),还可以是同一个对象在不同周期的实例(如一个对象计算环比时可视为两个同类对象间的比较)。例如:作为项目经理关注的目标,当前外包项目的缺陷密度与其他外包项目比怎么样? - 问对象组成,标记为
E
(elements)。有些对象具备层级结构(如团队包含子团队、项目包含子项目)或由若干部分构成(如需求交付过程包含若干阶段、软件包含若干模块),那么可以对目标对象的组成元素提问,通常以分析主因或瓶颈为目的。例如:部门内各团队的代码产出量怎么样?需求交付过程各阶段耗时多久?
围绕维度有如下三种提问角度:
- 单一维度问题,标记为
S
(single)。对目标对象的一个或多个具体维度分别刻画,每个问题通常可以通过单个量化指标来回答。例如,系统的部署频率是多少?再比如,要“认知项目的需求交付水平”,我们需要知道做了多少需求、每个需求花了多少时间,而这两个问题可通过需求吞吐量和需求交付时长分别进行回答,它们都是独立的单一维度问题。 - 组合维度问题,标记为
C
(combinational)。有些问题涉及多个具体维度和指标,需要它们组合到一起才能获得认知或支持管理动作。我们强调系统化度量,希望同时从多个具体维度观察。例如,“哪些团队代码产出快、质量高?”组合维度问题强调多个具体维度的综合(或可衍生为复合指标),而不是单独的维度或者它们之间的关系。 - 关联维度问题,标记为
R
(relational)。有些具体维度会相互影响,可以进行组合提问,但以其中用户视角最关心的一个为主,其余为辅。例如,需求交付周期(RDC)与需求颗粒度(RG)之间存在关联,即:,其中 表示一定的函数关系。所以,我们在认知需求交付周期时应同时关注需求颗粒度,可以表述成“项目的需求交付时长是多少?与需求颗粒度的关系如何?”前者为主,后者为辅。关联维度问题强调具体维度间的关系。
除了目标和维度两个在目标中显式定义的参数,时间是另一个隐含的参数,决定提问的方式,主要有如下两种:
- 周期整体问题,标记为
F
(full)。针对现状或选择周期整体提问。如果问题表述没有提及时间,默认理解为此。 - 周期分段问题,标记为
P
(periods)。针对某个周期内各个时间段提问,时间段的长度称为步长。问题表述中通常以“历史表现”“最近变化”等关键词体现。
基于维度和对象,我们可以把问题模板按下表进行梳理。
单一维度 | 组合维度 | 关联维度 | |
---|---|---|---|
对象整体 | QT-OSF QT-OSP | QT-OCF QT-OCP | QT-ORF QT-ORP |
同类对象 | QT-GSF QT-GSP | QT-GCF | QT-GRF |
对象组成 | QT-ESF QT-ESP | QT-ECF | QT-ERF |
当一个问题中的对象和维度都有多个,再对周期分段会让回答变得很复杂,通常不推荐,所以未列入表中。
注意在应用问题模版前,首先要明确目标中的概念。例如,用户表达的目标是“认知软件的可靠性”,那么“可靠性”这个概念怎么定义呢?如果希望用软件交付后的缺陷数量来衡量可靠性,那么问题围绕的对象实为软件交付后的缺陷,针对的维度则是其数量。所以,目标表述中的对象和维度有时需要进一步拆解或转换。
问题列表及视图
对上述各类问题的回答主要以指标度量的数据视图(即图表)为载体,我们在此一并列出,方便更具像化的理解。问题模板的表述比较技术化,主要为了反映问题实质。在实际应用中,它们可转换成更容易被开发团队理解的表述。
QT-OSF
:<对象>的<指标>是多少?
这是最直接的提问方式,适用于简单易懂的指标。表述中未提及时间要素,默认指周期整体。以“需求吞吐量”为例,如果开发团队都了解这个概念,那么可以直接按模板提问,即“项目的需求吞吐量是多少”;否则,可转述成“项目近期交付的需求有多少”。
📈 典型视图:单一数值;其他视图上的辅助线。
QT-OSP
:<对象>的<指标>近期怎么样?
认知包含了解和评价,而 QT-OSF
类问题的回答是单一数值,可供“了解”,但缺乏“参照系”,无法形成数值高低的概念或判断(即“评价”),在实际当中的可用性往往打折扣。从时间维度看指标变化,是建立“参照系”的一种典型做法。我们可以跟自己比,看指标某时间段是处于高位还是低位。
例如,“该项目最近几周开发当量的离散系数怎么样?”——或转述为“该项目最近几周开发产出是否稳定?”
📈 典型视图:单折线图/柱状图,纵轴为指标值,横轴为时间(按特定步长)。
QT-GSF
:<对象>的<指标>与{同类对象}比怎么样?
例如,“当前团队开发效率与顶级开源社区比怎么样?”“该项目的部署频率在组织中处于什么水平?”
📈 典型视图:
- 柱状图,纵轴为指标值,横轴为各对象;
- 在指标周边呈现对比值,或在视图上加辅助线。
QT-GSP
:<对象>的<指标>与{同类对象}比近期怎么样?
例如,“当前团队开发效率与顶级开源社区比近期怎么样?”
📈 典型视图:多折线图/分组柱状图/堆叠图,纵轴为指标值,横轴为时间(按特定步长)。
QT-ESF
:{对象各部分}的<指标>是多少?
例如,“当前团队各位开发者的代码当量是多少?”——或转述为“当前团队哪些开发者贡献了最多的代码?”
📈 典型视图:
- 柱状图按高到低排列,纵轴是指标值,横轴是对象各个部分;
- 饼状图。
QT-ESP
:{对象各部分}的<指标>近期怎么样?
为了更好认知一个对象各部分对整体的影响,我们可进一步观察它们随时间的变化。例如,“该项目中各类型事务数近期有多少?”
📈 典型视图:多折线图/分组柱状图/堆叠图,纵轴是指标值,横轴是时间(按特定步长)。
QT-OCF
:<对象>的{指标}怎么样?
当多个指标需要紧密组合、同时了解时,可采用这个问题模板。例如,“该开发者代码的如下五个质量指标怎么样?”另外一种情况是,我们把多个统计值组合在一起,比如中位数、上下四分位、最大最小值等。
📈 典型视图:多数值;雷达图;箱线图。
QT-OCP
:<对象>的{指标}近期怎么样?
与从 QT-OSF
到 QT-OSP
的扩展类似,该问题模板为 QT-OCF
加入了时间轴。为了视图可读性,加入时间轴后,通常只选取少数指标呈现,且它们的单位通常统一到至多两种上。例如,“该开发者的代码产出和缺陷数量近期怎么样?”
📈 典型视图:
- 多折线图/分组柱状图/堆叠图,两条纵轴对应两种指标值,横轴为时间(按特定步长);
- 多箱线图,纵轴是指标值,横轴是时间(按特定步长)。
QT-GCF
:<对象>的{指标}与{同类对象}比怎么样?
例如,“项目各迭代完成的需求、修复、重构类事务数分别有多少?”其中“各迭代”涵盖了目标迭代和对比的其他迭代,不必拘泥于上述模板表达方式。
📈 典型视图:
- 分组柱状图/堆叠图,两条纵轴对应两种指标值,横轴是各对象;
- 雷达图;
- 四象限图,横纵轴为两种指标值;
- 多箱线图,纵轴是指标值,横轴是对象各部分。
QT-ECF
:{对象各部分}的{指标}是多少?
例如,大项目负责人要看各子项目情况,可以问“各项目人均生产率的中位数和范围是多少?”
📈 典型视图:
- 分组柱状图/堆叠图,两条纵轴对应两种指标值,横轴是对象各部分;
- 雷达图;
- 四象限图,横纵轴为两种指标值;
- 多箱线图,纵轴是指标值,横轴是对象各部分。
QT-ORF
:<对象>的<指标>是多少?与{关联指标}的关系如何?
例如,“该项目整体代码产出怎么样?贡献代码的人数有多少?”
📈 典型视图:多数值,可按主次呈现。
QT-ORP
:<对象>的<指标>近期怎么样?与{关联指标}的关系如何?
例如,“该项目整体代码产出近期怎么样?与贡献代码人数的关系如何?”
📈 典型视图:柱状图和折线图搭配,主纵轴是目标指标值,副纵轴是关联指标值,横轴为时间(按特定步长)。
QT-GRF
:<对象>的<指标>与{同类对象}比怎么样?与{关联指标}的关系如何?
例如,“项目各迭代需求吞吐量是多少?与需求颗粒度的关系如何?”
📈 典型视图:柱状图和折线图搭配,主纵轴是目标指标值,副纵轴是关联指标值,横轴是各对象。
QT-ERF
:{对象各部分}的<指标>是多少?与{关联指标}的关系如何?
例如,“部门内各团队的人均生产率是多少?与团队人数的关系如何?”
📈 典型视图:柱状图和折线图搭配,主纵轴是目标指标值,副纵轴是关联指标值,横轴是对象各部分。
在上述各类问题模板中的指标,可以是由事实数据按照通用概念直接度量得出的基础指标(如《软件研发效能度量规范》中的定义),也可以是基础指标上的统计值,或者是多个指标的复合(如“质效综合评分”“开发负载评级”,其复合的算法可能是加权平均等简单公式,也可能依赖回归或人工智能等)。统计值或复合指标可以直接回答单一维度问题,并呈现为相应的视图;如果想搞清楚其主要的影响因素,也可以进一步下探,提出相应的对象同类、对象组成、周期分段或者组合维度问题。
问题间关系
有些问题适宜为开发团队显式提出,而有些问题则组合在一起体现在同一个视图中,或者隐含在辅助线、辅助视图以及视图的跳转中。虽然有些问题不显式提出,但它们依然可以帮助我们规范对数据的分析。问题间关系都是在问题模板基础上进一步提问,具体包括如下三类。
综合
对一个问题得到的数据视图整体进行进一步提问,我们称之为综合。例如,当数据视图中呈现多个数据点时,辅以数据点的一些统计值,如均值、离散系数、拟合线等,可以帮助我们认知数据。下面列出一些典型问题上可进一步提出的综合类问题。
- 综合多个时间片段:
QT-OSP
QT-OSF
/QT-OCF
。例如,在回答问题“该项目近期新增代码当量有多少”(QT-OSP
)的视图上,我们可以进一步提问“该项目每周新增代码当量的离散系数是多少”(QT-OSF
)来评估开发产出稳定性,呈现为视图上标记的一个数值,而该数值本身不再有时间维度。 - 综合多个对象:
- 另有一类分析不改变问题形式但从每个数据点上计算出新的值,我们也归入综合类。例如数据点之间的比值或者各自占总数的比例:问题“各团队开发者人数是多少”(
QT-ESF
)的视图上可以标记出“各团队开发人数占多大比例”(同为QT-ESF
)。
我们不推荐在较复杂的视图上再综合其他问题,会导致视图信息过载,不便于用户理解。例如,QT-GSP
和 QT-ESP
同时包含了多个对象和时间变化,再添加辅助线会降低图表可读性。同理,关联维度类问题如果综合多个对象,综合结果在视图上不易区分对应哪个维度,故不推荐。
聚焦
在一张数据图表中,用户可能会关注到某个元素,希望获得更多信息,我们称之为聚焦。这种行为本质是进一步的提问,其回答有时会作为后续下探的基础。聚焦的方式有三种:
- 聚焦于某个时间段,将时间编码由
P
变为F
(即选取某一个时间段,将其视为完整周期); - 聚焦于某个对象,将对象编码由
G
/E
变为O
; - 聚焦于某个维度,将维度编码由
C
/R
变为S
。
三种聚焦方式可同时应用。例如,QT-ORP
→QT-OSF
同时在时间和维度上聚焦。具体以回答“项目的需求吞吐量近期怎么样?与需求颗粒度的关系如何?”(QT-ORP
)的视图为例,可以选取某一时间段的需求吞吐量或者需求颗粒度,以呈现具体信息,那么相应的问题分别是“项目在该时间段的需求吞吐量是多少”或“项目在该时间段的需求颗粒度是多少”(QT-OSF
)。
结合实际场景,聚焦后的问题应属于如下模板之一:
QT-OSF
:聚焦一个对象特定时间段的某个维度(例如某些视图中选取一个柱子);QT-OSP
:聚焦一个对象各个时间段的某个维度(例如某些视图中选取一条折线);QT-GSF
/QT-ESF
:聚焦多个对象特定时间段的某个维度(例如某些视图中选取一个时间段上的各个数据点);QT-OCF
:聚焦一个对象特定时间段的多个维度(例如某雷达图中选取一圈折线)。
下探
管理行动(控制或改进)需要定位指标高低背后的原因或瓶颈,伴随多种数据下探分析,也是聚焦之后再进一步的提问。从实现角度看,“下探”通常是从一个视图的关注点,跳转到更深度反映其信息的另一个视图。我们总结了下探的典型方式(聚焦问题下探问题)。
- 基于时间下探:
- 基于对象下探:
- 基于维度下探:
QT-OSF
QT-OCF
,聚焦对象整体在周期内的单个指标后,下探呈现影响该指标的若干指标。定位影响整体的主要指标,或对比各指标的均衡程度。QT-OSP
QT-OCP
,聚焦对象整体在各时间段的单个指标后,下探呈现影响该指标的若干指标在各时间段的变化。定位影响整体变化的主要指标,或对比各指标的相对变化趋势。QT-GSF
QT-GCF
,聚焦一组对象在周期内的单个指标后,下探呈现影响该指标的若干指标。定位影响对像间差异的主要指标,或对比各对象在各指标上的均衡程度。QT-ESF
QT-ECF
,聚焦对象各部分在周期内的单个指标后,下探呈现各部分的多个指标。定位影响各部分的主要指标,或对比各部分在各指标上的均衡程度。
本内容由思码逸公司(https://merico.cn)和 OpenMARI 贡献者(https://openmari.dev)以《署名-相同方式共享 4.0 国际(CC BY-SA 4.0)》协议授权。
欢迎提交贡献或到访论坛分享洞见!
参考阅读
- V. R. Basili and D. M. Weiss, "A Methodology for Collecting Valid Software Engineering Data," in IEEE Transactions on Software Engineering, vol. SE-10, no. 6, pp. 728-738, Nov. 1984. https://doi.org/10.1109/TSE.1984.5010301↩
- van Solingen, R., (Revision), Basili, V., (Original article, 1994 ed.), Caldiera, G., (Original article, 1994 ed.) and Rombach, H.D., (Original article, 1994 ed.) (2002). Goal Question Metric (GQM) Approach. In Encyclopedia of Software Engineering, J.J. Marciniak (Ed.). https://doi.org/10.1002/0471028959.sof142↩
- 任晶磊.GQM 从入门到精通.研发效能评论,2022-06-08.https://meri.co/55bb4126↩