敏捷模式下的質量度量和質量預測

徐朝陽

摘 要：本文介紹了敏捷模式下，使用有效的質量度量和質量預測方式來實施項目質量管理。有效的質量度量在紛繁復雜的項目中起著指南針的作用，質量預測更是為困頓中的項目運營起著導航儀的作用，文中詳細說明了質量趨勢圖和累積流圖作為質量度量手段和質量預測的手段，如何在具體項目上有效地實施。

關鍵詞：敏捷實踐、質量管理、質量趨勢、累積流圖、數據庫

傳統的質量管理體系如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