敏捷外包工程系列之四：合理選擇品質管理的等級（一）

文章目錄

• 品質控制 Quality Control
• 敏捷品質控制

敏捷外包工程系列的第四篇（欄目目錄）。

業界存在的問題

CMMI最近沒有以往火了，原因之一是SEI發現中國和印度的很多企業在層級評估上造假，尤其是高等級評估。為此SEI還在4級以上做了複審的規定。

為什麼那麼多企業爭先恐後地爭搶高等級呢？因為想證明自己的品質高。

在軟體外包，或者說項目開發（而非產品研發）中，進度、品質、成本、需求這些因素雖然可能達到的最終效果有限，但各自的投入卻可能是無限的，只是每個因素都以對數曲線規律運行，任憑你投入10倍的人力物力，它只增加一倍。

所以，在投入之前，應該問自己：到底哪個是我的終極目標呢？

在軟體外包或者說項目開發領域，成本是終極目的。

因為外包或項目的終極目的是交易，是一個以金錢購買人力的過程，如果成本超過了合約額，無論進度、品質、需求如何，交易的本質目標已經受到了傷害，甲乙雙方遲早均會為此付出代價。

因此，甲乙雙方應該審時度勢地合理選擇品質等級，來控製成本。

順便說一下產品研發的終極目的是提供功能（即項目開發中的需求），剩下的三者則為其服務。

品質管理的等級

品質管理活動大致有以下這些，並因為實施了這些活動而可以達到對應的品質管理等級：

品質控制 Quality Control

品質保證 (Process and Product) Quality Assurance

品質定義 Quality Definition

量化品質管理 Quantitative Quality Management

根源分析與缺陷預防 Causal Analysis and Resolution

品質控制 Quality Control

實施品質控制的一個典型情況是有基本的軟體測試行為，對應CMMI的1級（一個在CMMI模型中描述過，但沒有定義的層級）。

為什麼稱之為Control呢？因為測試活動發生在產品完成之後，因此它本身不能直接提升產品的品質，但可以把產品中不好的部分檢查出來。在製造業中，不合格品檢出後會被扔掉，而軟體界則把不合格品退回重新修改。

品質控制存在局限性：

1. 效果有限

正如我們不希望購買到被“返修”的汽車、家電一樣，“重新修改”過的軟體也是存在問題的，因為多數缺陷不是孤立的事件，而是軟體整體品質低下的一個表象。

2. 成本高

如果一輛汽車只有完整安裝好後才知道品質如何，而一旦知道了就只能整個扔掉或完全拆開修，將是一個很痛苦的事情。

而軟體測試正是如此，在軟體能運行之前是無法測試的，而測出了缺陷和發現了缺陷是兩碼事，得用肉眼重新“拆”開軟體，才能找到缺陷的根源。

敏捷品質控制

敏捷開發中的持續整合和自動化測試可以有效降低成本高的問題，因為持續整合極大地加速了裝、拆兩個過程。

加速裝的過程很好理解，為什麼說可以加速拆的過程呢？

由於每次持續整合，被“裝”進去的代碼很少，所以一旦測試發現問題，就能很容易地判斷問題存在的地方就是剛剛加進去的代碼，或至少是由這些代碼引起的，因而可以迅速定位問題。

這比在最終產品成型的時候才進行測試，拆的過程要快得多。

不過，既然知道持續整合是用來解決成本問題的，那麼就別投入過多的人力做持續整合本身，要問自己一些問題，來判斷持續整合是否發揮了作用，比如：

1. 項目的長度，是否長到需要中間持續整合？

如果只有1個月，估計1個月後大家拆裝的速度也未必差到哪裡去。

2. 即使需要持續整合，應該以何種頻率和程度進行整合和測試？

切忌不要為了敏捷而敏捷。

3. 在整合後，是否順便邀請了客戶來觀摩一下當前的產品，以便提出改進？

有些改進未必是代碼缺陷問題，興許是需求缺陷問題。

4. 這個項目有沒有二期三期四期，是否需要把持續整合和測試環境搭建地好一點？

5. 這個項目有沒有多個客戶？（已經接近產品化了）

這影響到是否需要一個大環境同時架設多個客戶，以便在為一家客戶修改底層後，快速檢查一下是否其他客戶受到了影響。

……