敏捷模式下的质量度量和质量预测

徐朝阳

摘 要：本文介绍了敏捷模式下，使用有效的质量度量和质量预测方式来实施项目质量管理。有效的质量度量在纷繁复杂的项目中起着指南针的作用，质量预测更是为困顿中的项目运营起着导航仪的作用，文中详细说明了质量趋势图和累积流图作为质量度量手段和质量预测的手段，如何在具体项目上有效地实施。

关键词：敏捷实践、质量管理、质量趋势、累积流图、数据库

传统的质量管理体系如ISO9001等应用到在消费类电子产品开发项目上时，往往显得非常笨重和不适用，而90年代后期出现的迭代开发模式，敏捷模式等在实践上更多的在于能快速协调需求推出新产品，质量上的不足一般做法是通过快速迭代发布来弥补，这样的做法在互联网软件和手机App开发领域尤为常见，但是消费类电子产品因为生产成本较高，即使在敏捷模式下，仍然要求每次发布都能达到质量标准。

科亿尔数码科技和惠普分别是一个软件公司和硬件公司，虽然业务内容不同，面向市场不同，但产品同属于消费类电子行业，市场竞争激烈，对项目时效性和质量都有很高的要求。本文详细阐述如何将质量趋势图应用于Player11项目的有效质量管理，并进而如何将累积流图应用于惠普的Transformer项目的有效质量管理。

一、通用质量管理系统的局限性

通用的有效质量管理系统一般由测试策略规划、测试计划、测试用例及数据库、Bug管理系统及测试度量图表组成并构成一个闭环系统。其中，测试度量是将质量目标分解成具体指标性数据用于质量评审。

通用的质量管理系統往往只能反映质量现状能否符合预期的质量目标，如若不符合就只能否决发布，或者为了争取商机选择质量降级发布，而后者是很多消费类电子产品企业的现状。因此一个成功的项目除了质量目标还有工期目标，在实际项目中，需要有进一步的方法帮助项目组从项目初期就能在满足工期目标的前提下预测质量目标完成的可能性，这是本文要探讨的质量趋势图和累积流图在这方面的实践。

二、质量趋势和预测

2.1应用质量趋势图的背景

科亿尔公司的Player11产品是一个Windows平台的音视频播放器，为了赢得市场先机，该项目从立项到发布只有短短4个月时间，力图利用市场时间差形成差异化竞争力。该项目采用敏捷开发模式，人员组成精干。由于其差异化的产品定位，公司高层要求不惜代价保证该项目必须成功按时发布，在该项目中，质量部门启用了质量趋势图，在该项目的质量管理中起了非常重要的作用。

2.2常用的质量度量方法

通常一个新产品或者项目的研发过程要经过多次质量评审，在项目早期流程中，质量部门除了详细的测试结果和测试记录之外，还提供以下两份数据图表供评审审阅讨论：

2.3早期质量度量方法的缺陷

对于一个正在进行中的项目来说，这两份图表能反映的问题非常有限，主要表现在如下几点：

1）存量问题数量和项目是否健康无直接关系。也许100个简单的问题解决之后不产生新的风险，但是也许1、2个复杂的问题就给项目交付带来很大的不确定性。

2）项目风险信息不全面。软件系统项目由于模块之间的耦合和系统资源的耦合，只要代码还在变动，就无法避免新的问题会出现，曾经修复的问题也会再次出现。就图1来看，项目目前还有56个存量问题，但这只是当前的静态数据，在项目结束前，这个数据每天都在变动。

3）存量数据不利于制定风险预案。一个项目的风险往往从立项和设计初期就有了决定性的因子，并不是到项目后期才体现出后果，如果质量度量能把历史数据串起来形成质量趋势，就能让评审委员们以更加全面的视角了解项目的风险，并进而在项目中前期就能给项目组提供必要的修正手段，如增加资源等等，并为项目可能出现的风险做出预案，避免企业损失。

2.4质量度量方法的改进

2.4.1Bugzilla数据库的应用

要建立有效的质量度量，一个重要前提是有详细的测试记录和问题记录，Player11项目使用Bugzilla作为bug管理数据库并做了二次开发，并利用Excel作为质量度量的分析工具，通过ODBC从Bugzilla直接读取数据并做分析，而测试用例的管理仍然通过基本的Excel报表来完成。

2.4.2质量度量的改进

Player 11项目改进了质量管理系统使每个流程的规范更加具体和详细，比如测试策略要详细列出每个阶段应完成的项目模块，测试项目、测试方法以及验收标准等等。其中最重要的改进是测试度量——Player11的质量度量相对于初期的度量多了问题走势图和预期走势图，使之真正与质量目标形成闭环的数据。

但是Bugzilla并不能直接提供质量部门需要的数据，这两个走势图是在对Bugzilla中的数据进行统计分析后的结果，其原理与bug的生命周期有关。

2.4.3质量趋势图的原理

大部分bug管理系统中对于Bug生命周期的管理机制大同小异，从质量管理角度，Bug的状态可以简单分为“打开”和“关闭”两种状态类别，这两个类别与Bugzilla数据库中bug的实际状态对比如下：

Bugzilla提供的数据只有当前最新的状态，这也是早期的质量度量只能反映当前问题状态的原因，但是Bugzilla实际上也保存了每个Bug的历史活动记录，用Excel可以借由ODBC从Bugzilla数据库中导出Bug的历史活动记录，再根据Bug的当前状态用以下公式往前倒推，可以计算出过去每个时间段处于“打开”和“关闭”状态的Bug数量。

上次“打开”数量 = 当前“打开”数量 -（新增+重开）+（已验证+已关闭）

上次“关闭”数量 = 当前“关闭”数量 -（已验证+已关闭）+（新增+重开）

2.4.4质量趋势图的效果

有了各历史阶段“打开”和“关闭”的Bug数量，然后通过Excel强大的函数和数据透视表可以整理出各历史阶段的值，并进而画出历史质量趋势图，如图2所示：

图2：Bug历史趋势图

图2的历史趋势图至少可以反映如下两个信息：

1）目前存量问题在收敛中，但是收敛速度较慢且有小幅波动

2）存量问题的修复增速有所降低，需要深入关注原因

如果结合图1和表1的存量数据信息，再结合项目计划，通过质量趋势图可以深入挖掘更多信息，反映出更多问题，比如问题收敛的小幅波动是否由于某个新功能的加入导致，是否与版本管理有关系，问题修复速度降低是否跟开发团队的变动有关等等。

质量趋势图反映的是“打开”和“关闭”状态的问题在过去的时间里分别走势如何，相对于图1的静态数据，除了能反映项目的风险，还能对项目团队控制风险的能力有所展示，因为其来源于真实数据，反映的问题也比较客观。

2.4.5质量预测能力的提升

基于图1和图2的数据，质量部门在评估质量风险的时候就有了更多的数据和信息。但是开发过程没有风险的项目几乎是不存在的，在市场竞争激烈的情形下，企业更加关注的是在预定发布日期能否修复所有问题，达到预定质量目标。这就对质量管理部门提出更高的要求，如果有风险，必须能在发布日期之前给出预警，从而能给项目组成员和企业管理者足够空间做出策略性调整，避免项目最后阶段才发现质量目标无法达成的情况，

通常开发组每周更新一次内部软件版本供质量部门测试，在跟开发部门长期合作中，质量部门完全掌握平均每周新增bug的数量，开发部门平均每周能修复的bug数量，以及有多少Bug可能被重新打开过（即质量），在项目开发进入胶着期时，这些平均值基本能反映版本的质量及开发部门修复Bug的能力，在没有特殊措施的情况下，预期这种情况仍然可以持续，当产品质量真正出现收敛时，预期新开Bug将会逐渐降低。根据这个规律，质量部门可以对质量收敛做出预测。

下表是Player11在截止9月底时的实际数据和预测数据，其中灰色部分就是根据9月底之前的数据估计出未来几周内新增和关闭的Bug数量，并用以上公式计算出未来几周每周处于“打开”和“关闭”状态的Bug数量，从表中可以看到，预计项目终评日11月15日那一周“打开”状态的Bug数量将降至0，因此目前项目状态是良好，可以满足质量目标和工期目标，当然前提是每周新开Bug数量应该不大于预估计值，所以应该不断监控用实际值取代估计值，直到逼近预定评审日期。

据上表可以绘出质量预测图如下图3，可以看到该图不但包含实际值（实线），也包含了估计值（虚线）。

根据该预测图，质量部门可以拟合出一个展望前景：根据项目现状和已经观察到的风险，Player11产品将在发布前一周出现显著收敛特征，原因是从9月中旬开始新增Bug数量减少，也没有新的功能加入，预期代码变动将减少，开发人员以修复现有Bug为主，测试方面以回归测试为主，所以未来修复Bug数量将超过新增Bug，所以逐渐可以收敛。只要开发组和测试组重点关注代码质量，控制质量回归，产品在11月中旬可以满足质量目标和工期目标。

图3：Player11项目质量预测图

这个数据和结论就是评审委员会需要的信息，后来的事实确实也证实了质量部门的管控和判断是正确的。以上改进措施也突出体现了质量管理部门对于项目风险的把控能力，而且工作简单易行，只需要对Bugzilla数据库有充分了解，也对数据分析技术比较熟悉，就可以实现比较有效的质量管理。

但是在Player11项目中，由于测试用例是用Excel表格的方式来管理的，没有跟bugzilla的数据充分联结，还有大量测试数据的潜力没有充分挖掘出来。在Transformer项目上，惠普公司有更加完善的流程架构，因而可以实现更加强大的数据统计功能，使得质量管控更为得心应手，这就是累积流图的使用。

三、累积流图

3.1使用累积流图的背景

与Player11项目情形比较相似，惠普的Transformer激光打印机项目也面临很大的时间压力。该项目立项时考虑原有软硬件方案比较成熟，所以项目周期从立项到正式量产只有短短8个月时间，比以往的项目整整少了一半时间，因此该项目从一开始就进入强力监控模式，一旦发现有失控风险就及时报告高层管理者调集资源以支持该项目，而质量监控是通过累积流图进行的。

3.2累积流图的原理

累积流图是基于排队理论的面积图工具，被广泛应用于敏捷开发管理，但是基本要求是将测试数据和测试记录全部数据化，Transformer项目正是基于这个基础，实现了更加全面的质量管理和预测。

累积流图的基本特性如下图4所示：

图4：累积流图示意图

从图4可见，任何项目都有两个维度的目标，一个是总工作量（竖轴），一个是时间（横轴），共同围成一个矩形，对角线就是基准参考线，在该基准线上，工作量随时间线性推进，但实际项目不可能是线性的，而是一条波动的曲线。如果波动曲线总体在基准线之上，该项目就是相对健康的，反之该项目存在风险。因为项目实际推进过程是不断波动的，经验上连续三周到四周的数据是基本可以反映项目团队的平均效率和项目掌控能力的，所以可以根据连续三周或者四周的数据点拟合出趋势向量。

3.3Transformer项目质量管理系统改进

累积流图的使用是以测试数据和测试记录全部数据化为基础的，Transformer项目的质量管理系统相应地比Player11项目有更多的改进，具体内容下：

1）测试计划、测试用例、测试执行和Bug管理全部基于ALM（Application Lifecycle Management）數据库进行的，尤其因为测试用例与Bug数据连接后，这使得质量管理可用的数据成级数增长，特别是测试用例与Bug数据增加了更多属性信息，使得管理数据更细更具体。

2）由于质量管理数据更多， Transformer项目的测试度量相对于Player11项目可以多若干度量值，毕竟Player 11只有Bug管理是基于数据库的，测试用例等是基于Excel管理，难以实现测试全过程的量化管理。

3.4累积流图的应用效果

测试用例数据库和Bug数据库联动之后，再加上累积流图的使用，质量管理就更有针对性，更加细致化。

图5：Transformer现有问题累计流图

如图5所示，质量部门在11月中旬，提前近3个月开始告警，因为新发现问题速率超过修复的速率，意味着项目不可能在预定日期1月底之前修复所有问题，开发部门迅速调集资源在一个月内修复了大量问题，但是直到12月中旬的监控数据仍然提示在1月底之前，Transformer的质量难以达到发布标准。

为给开发部门和高层管理者更清晰的调整方向，质量部门模拟出预期的问题修复速度，如图6所示，蓝色框内即为预期的每周问题修复速度，只有开发部门按照这个速度去修复问题并控制代码质量防止质量回归，项目才有可能在预定日期达到质量标准。

图6：问题发现-修复每周一揽图

通过这一系列质量度量工具，质量部门完整而且清晰地将质量现状和预期状态显示给项目组和评审委员会成员，使得项目管理和质量管理方向和目标明确，有的放矢，最终产品圆满地于预定日期达到质量標准，交付生产。

四、结论

在敏捷开发模式下，应用质量趋势图和质量预测图能很好地实现对质量的直观展示和预期展望，为项目组提供全面质量视角，而且累积流图能更进一步提供可分解可量化的管理目标，在必须保证工期的前提下，以详实有效的量化指标实现质量管理。

在项目实际运用质量预测和累积流图的时候，必须紧扣实际项目开发需求，优化管理流程，牢固树立客户利益第一，质量目标和工期目标并重的企业文化，其次数据化管理是个基础，只有提升质量人员的业务管理水平，质量管理才能真正落到实处。

参考文献：

[1]Lisa Crispin & Janet Gregory，《敏捷软件测试：测试人员与敏捷团队的实践指南》，清华大学出版社，2010

[2]黄文海，《敏捷项目管理实战之质量管理》，IBM学习社区，2011