MARI概述

MARI是一套面向软件研发，应用于研发效能度量及实践落地的方法论。

MARI的目的是建立研发效能度量和改进的闭环。研发团队结合实际情况，将价值流中的关键阻碍问题定位为提升点后，可以应用 MARI 方法论，对问题进行量化评估、分析和拆解，获取效能瓶颈、改进机会等洞见，进而落地为软件工程实践的逐步优化，以及切实的研发效能提升。

MARI由以下四个步骤组成，这四个步骤共同组成一轮完整的优化迭代。大部分情况下，问题改进需要经历多个迭代，持续度量改进效果，不断校准改进的方向和方法。

MARI方法论

• 度量 Measure

无论任何改进活动，首先需结合组织及团队实际认知需求，面向改进目标通过量化数据对过程及目标进行刻画，即建立度量。度量需要统一数据及指标的采集方法。

• 分析 Analyze

有了量化指标，运用统计分析方法，对数据的趋势、分布、关联等信息进行分析，得到对现状的量化理解。

• 回顾 Review

基于分析结果，对产生“果”（结果）的“因”（影响因子），进行回顾，挖掘对结果产生影响的根本原因，定位关键问题。

• 改进 Improve

针对关键问题，建立可落地的改进措施，通过调整“因”（影响因子），最终影响“果”（目标）的达成，并进入下一轮度量验证。

‍

背景

MARI在《软件研发效能度量规范》团体标准的框架下制定，沿袭了框架的多维度量原则，指标面向交付价值、交付速率、交付质量、交付成本、交付能力五大认知域，覆盖需求、设计、开发、测试、发布、运营六大实践域，并根据不同角色在不同场景下的认知需求，对同一指标设计了多种分析、回顾和改进方法。

MARI实践方法论以外，开源的研发数据平台Dev Lake能够作为自动化的数据采集及可视化工具，应用于其中的M（Measure度量）与A（Analyze分析）环节，帮助研发团队低成本实现实时、跨数据源的度量，为后续更进一步的回顾和改进提供数据支撑。MARI 与 Dev Lake 共同支持了研发效能度量框架的落地。

-图：标准、工具及MARI指南关系图-‍

‍

最佳实践

• 由少到多，持续下钻

结合团队实际需求情况，面向改进目标选取度量指标。先选取北极星指标，比如“需求交付周期”。然后再下钻到实践域的各阶段进行观察分析，比如“需求颗粒度”、“代码评审轮数”、“测试缺陷率”、“构建次数”等。

• 综合分析，关联制衡

研发效能涉及软件生命周期的各个阶段，一个或少数指标并不能反应全貌。比如“需求交付周期”衡量研发团队需求交付速度，它反映了研发的快速响应能力。理论上，向客户交付价值的速度越快越好，然而，还必须要考虑顾客的期望、需求吞吐量和交付质量，过快的交付并不总是带来价值。

• 层层推进，追问根因

研发效能度量不能止步于数据本身。研发管理者紧盯数据，可能导致自上而下的面子工程或教条主义，效果适得其反。

MARI 框架强调对指标数据进行下钻分析，首先对数据进行多视角的分析与解读，获取有效信号；进而结合其他关联指标和调查方法，追问根因，定位效能瓶颈和优化机会；最终将这些洞见落地为明确、可执行、可验证的改进方案，规范研发过程、建立良好研发文化。

层层推进的框架设计，使度量带动思考和行动，才能发挥出度量真正的价值。

-图：MARI方法的持续改进-

• 构建闭环，持续改进

效能提升不能靠阶段性冲刺。要达到有效且可持续的效能提升，需要将度量和改进的实践融入日常研发流程，持续追踪，持续改进。

MARI框架强调构建研发效能管理的闭环。在基于数据解读制定改进方案后，需要持续度量观察效能趋势，对改进后的指标数据进一步分析解读，对改进方案的有效性做出快速反馈。若改进推进一段时间后，继续提升效果不明显，边际效应降低，这一机制也有助于团队快速判断，及时将资源投入下一改进项。

‍

当前涵盖指标概览

这张概览图展示了 MARI 指南目前已涵盖的效能指标。

研发效能度量是一项复杂的系统工程：一方面需要打通软件研发不同环节，避免效率竖井和局部优化；另一方面，度量需要灵活支持效能管理的不同需求和不同场景。

因此，在 MARI 指南中，每个指标都具备“实践域”及“认知域”属性。

• “实践域”表明该指标对应的研发环节，可能是“需求 - 设计 - 开发 - 测试 - 发布 - 运营”研发全生命周期中的一个或多个环节。
• “认知域”表明该指标主要应用于研发效能认知的哪个维度。认知域分为交付速率、交付质量、交付成本、交付能力和交付价值五个维度。

在这张概览图中，实践域与认知域分别作为研发度量体系内的两条坐标轴，直观呈现出单点指标在体系内的定位。

• 在实际使用中，研发团队可以先结合实际情况，分析度量需求，明确度量需求所对应的实践域与认知域，借助这张概览图找到相关指标，再深入阅读该指标的 MARI 指南。