經常有這麼一個問題：QA爲什麼對過程改進有幫助。答案當然與如何理解、如何管理、如何處理QA與項目之間的關係密不可分。這裏有很多議素我們需要好好探討。其中一個比較實在一點的，就是如何讓QA可以在審覈之中，發現項目是否遵從標準規程之餘，還能否發現可以提高項目效率的機會，並且提出有針對性地建議，讓項目可以更有效地達成項目的目標。
QA審覈的內容，通常都可以從審覈的檢查單之中看到一個端倪。如果檢查單裏的問題，他們的答案明顯與項目的效能無關的，按照這樣的檢查單審覈，就當然不能發現如何幫助項目提高效能。所以我提到QA需要制定“有效性”的檢查單。
問題立刻出現了，就是“什麼樣的檢查單纔是有效性的檢查單？”本文的目的就是希望解答這個問題。
讓我首先作幾個聲明：
1）當我們談“有效性”審覈的時候，我們不是說“遵從性”的審覈不好。我希望強調一點：“遵從性”是制度化與成熟程度的基礎。沒有了遵從性的團隊、組織，是不成熟的，過程操作一般是低效的。只有具備了一定程度上的遵從性，過程管理才能開始生效。請大家明白這一點。
所以我們談有效性審覈，其實是說在遵從性審覈的基礎上，考慮有效性的問題。這是一個能力水平的提升，而不是一個對標準規程的叛逆。
2）要提升過程的效能，因爲每一個項目團隊能力、風格不一樣，是需要針對性的。這些針對性，就反映在調整檢查單上面。我也遇到過這樣的問題：“QA的標準規程裏有標準的檢查單，我們是否必須者用同樣的檢查單，纔是符合標準的QA審覈？”
我希望說明的就是：在符合標準要求的情況下，進行部分的調整是可以容許的。這個概念，就體現在 CMMI 要求標準規程裏提供“適配”，並要求制定適配的準則。我們需要了解這一點。當然這個需要對規程與過程管理具備一定的瞭解與判斷能力。這些知識與經驗是需要積累的。
3）千萬不要認爲只有一個方法制定檢查單。做任何事情，都有很多實際方法、途徑可以完成。這裏只是一個案例。我希望大家可以看到要考慮什麼問題，要如何思維，然後發展自己的觀察、分析、判斷等能力，這纔是最重要的。
好了，我們就談談如何制定“有效性”的檢查單吧。我拿了一個案例來說明。這個案例是一個組織在使用的，用來審覈“估算”的標準檢查單。這裏就來說明如何從這個檢查單開始，加入“有效性”因素的考慮，來達到一個既滿足本來的遵從性審覈任務，也可以反映項目的操作是否有效的檢查單。
制定有效性檢查單的步驟：
1）我們要知道，“有效性”就是能夠達到目標。如果沒有目標，或是QA不清楚目標，有效性是無從談起的。
所以QA一定需要知道檢查單上面每一個條款，如何與項目的目標相關聯。
2）符合性與有效性既相互關連，也相互獨立。如果要過程有效，我們需要建立制度化。制度化的一個條件，就是每一個員工都需要有願意遵從規程，符合規程的意願。我們需要用一種大家都瞭解的，一致的方法，來處理日常的、或是不理想的、特殊的情況。要過程改進，我們就需要有遵從的紀律。
所以有效性是建立在“遵從、符合”的基礎上的。
另一方面，如果規程制定得不合理，或是缺乏靈活性，來適應不同的項目、技術、產品。比如，無論項目大小，週期長短，都要求用“Wideband Delphi”進行估算。這就不靈活了。短週期的小項目就很不適合了。又或是要求嚴格複雜的測試用例分析、策劃等等，也有同樣的問題。那麼，項目的過程就是符合，也不會有效。
所以QA需要具備專業態度與獨立精神來處理現實中“符合性”與“有效性”的衝突與一致。
3）因爲過程有效性，就是能夠達到目標。那麼，審覈過程的有效性，就需要判斷。所以一定要求審覈的人（QA）具備這種判斷能力，而不是期待把檢查單細化到沒有判斷能力的人也可以實施。
舉一個例子，如果檢查單裏的問題是：
一）估算是否按計劃的時間完成？ 那麼誰都可以判斷。但這不是有效性的。因爲我們沒有考慮不按計劃的時間完成是否影響項目的目標。
二）估算完成的時間是否對項目達成目標造成風險？這個問題纔是有效性的。那麼，就需要判斷了。我們不能夠有效地定義：超時兩天就可以，三天就不可以。這在大部分的情況底下其實是不可能的。能夠回答這類問題的人，需要有判斷能力。
這是爲什麼我們要求QA不斷提高自己的能力的原因。
談到QA能力，我在這裏先問一下：我們可否識別“子過程的目標”與“審覈子過程的目標”？我們需要能夠分辨這個。舉一個例子：“同級評審”的目標，就是發現缺陷。但是爲什麼我們要審覈“同級評審”這個子過程？那麼目標就可以有很多：比如，作爲考覈的依據；查看項目是否遵從標準規程；評價這個子過程的操作實效；發現項目是否具備實施同級評審的技巧，等等。我們一定要能夠分辨這些不同層次的目標。
4）總結一下：要從事有效性的審覈也好，制定有效的規程也好，就需要考慮：
- 每一個條款或是步驟是爲什麼，要解決什麼問題？ （要解決什麼？）
- 這個條款或是步驟有什麼後果？ （有什麼後果？）
- 這些要解決的問題與實施後果如何影響項目的目標？（對項目的影響與風險）
這些就是QA需要能夠回答的問題。
QA需要養成一個考慮這些問題的習慣來建立自己回答這些問題的能力。
5）假設我們已經具備這些能力，那麼制定有效性的檢查單就不難了。第一個考慮的概念，就是“層次”。假設EPG提交了一個檢查單，如下：
|
審覈子過程/活動
|
檢查項
|
檢查方法
|
|
二次估算
|
是否按時進行了二次估算？
|
按照PMS計劃本月要求評審完成的子系統方案都應該進行二次估算。
|
|
作者是否參與集成測試活動估算？
|
檢查&訪談&參與估算會議：
1、估算報告中是否有該子系統方案作者的估算記錄。 2、訪談該子系統方案作者是否參與了估算。 |
|
|
作者是否參與各模塊開發活動估算？
|
檢查&訪談&參與估算會議：
1、估算報告中是否有該子系統方案作者的估算記錄。 2、訪談該子系統方案作者是否參與了估算。 |
|
|
開發相關人員是否都參與集成測試活動估算？
|
檢查&訪談&參與估算會議：
1、估算報告中是否有所有相關開發人員或開發科長/開發經理的估算記錄。 2、訪談開發人員/開發科長/開發經理是否在估算前對估算對象進行了瞭解，並參與了估算。 重點關注參與估算的開發人員必須是這個模塊的編寫人員或者是這個模塊負責的開發科長或開發經理。 |
|
|
開發相關人員是否都參與各模塊開發活動估算？
|
檢查&訪談&參與估算會議：
1、估算報告中是否有所有相關開發人員或開發科長/開發經理的估算記錄。 2、訪談開發人員/開發科長/開發經理是否在估算前對估算對象進行了瞭解，並參與了估算。 重點關注參與估算的開發人員必須是這個模塊的編寫人員或者是這個模塊負責的開發科長或開發經理。 |
|
|
是否會議方式估算？
|
檢查&訪談&參與估算會議：
重點關注是否通過會議方式進行估算，並對估算結果達成共識。一般可在子系統方案的最後一次評審會上（要求在PMS進度計劃中子系統方案評審任務完成時間點前）進行。 |
|
|
詳細設計估算是否完整有效？
|
檢查&訪談&參與估算會議：
1、關注模塊的完整性，即是否每個涉及的模塊都有估算（例如：如果有涉及到網管的是否進行了估算）。 2、關注詳細設計相關估算內容（詳細設計文檔規模、工作量、評審工作量）的完整性。 3、關注最終估算結果的合理性：每個估算對象的“估算結果”是否取自估算過程中偏差最小的“平均值”欄中結果（同時注意估算公式是否正確，項目組目前二次估算採用delphi方法） |
|
|
編碼估算是否完整有效？
|
檢查&訪談&參與估算會議：
1、關注模塊的完整性，即是否每個涉及的模塊都有估算（例如：如果有涉及到網管的是否進行了估算）。 2、關注編碼相關估算內容（編碼代碼行、工作量）的完整性。 3、關注最終估算結果的合理性：每個估算對象的“估算結果”是否取自估算過程中偏差最小的“平均值”欄中結果（同時注意估算公式是否正確，項目組目前二次估算採用delphi方法） |
|
|
單元測試估算是否完整有效？
|
檢查&訪談&參與估算會議：
1、關注模塊的完整性，即是否每個涉及的模塊都有估算（例如：如果有涉及到網管的是否進行了估算）。 2、關注單元測試相關估算內容（單元測試用例編寫工作量、測試用例條目數、測試執行工作量）的完整性。 3、關注最終估算結果的合理性：每個估算對象的“估算結果”是否取自估算過程中偏差最小的“平均值”欄中結果（同時注意估算公式是否正確，項目組目前二次估算採用delphi方法） |
|
|
集成測試用例估算是否完整有效？
|
檢查&訪談&參與估算會議：
1、關注集成測試用例相關估算內容（集成測試用例文檔規模、用例數、工作量、評審工作量）的完整性。 2、關注最終估算結果的合理性：每個估算對象的“估算結果”是否取自估算過程中偏差最小的“平均值”欄中結果。（同時注意估算公式是否正確，項目組目前二次估算採用delphi方法） |
|
|
集成測試執行估算是否完整有效？
|
檢查&訪談&參與估算會議：
1、關注集成測試第一階段工作量/第二階段估算內容的完整性。 2、關注最終估算結果的合理性：每個估算對象的“估算結果”是否取自估算過程中偏差最小的“平均值”欄中結果。（同時注意估算公式是否正確，二次估算採用delphi方法） |
|
|
偏差超過約定的偏差值是否再次估算？
|
檢查&訪談&參與估算會議：
參與估算會議或者檢查估算報告，針對估算偏差超過約定偏差值（目前項目組約定爲50％）的估算項，關注是否保留有估算過程數據。 |
|
|
是否完整填寫估算人員姓名及過程數據？
|
檢查&訪談：
檢查估算報告中每個sheet中是否明確填寫估算人員姓名，以及每個估算人員的估算過程數據，必要時進行訪談。 |
|
|
估算報告是否及時歸檔？
|
檢查：關注是否在PMS進度計劃中對應子系統方案評審任務完成時間點前及時歸檔到SVN中“子系統設計/二次估算”目錄下
|
檢查項包括：
- 是否按時進行了二次估算？
- 作者是否參與集成測試活動估算？
- 作者是否參與各模塊開發活動估算？
- 開發相關人員是否都參與集成測試活動估算？
- 是否會議方式估算？
- 詳細設計估算是否完整有效？
- 編碼估算是否完整有效？
- 單元測試估算是否完整有效？
- 集成測試用例估算是否完整有效？
- 集成測試執行估算是否完整有效？
- 偏差超過約定的偏差值是否再次估算？
- 是否完整填寫估算人員姓名及過程數據？
- 估算報告是否及時歸檔？
我們可以看到，這個單裏的條款，它們的重要性不是同一個層次的。這不是一個制定任何規程的好習慣。我們需要知道把同一個層次的條項羅列在同一個層面上。比如：
- 是否按時進行了二次估算？
- 作者是否參與集成測試活動估算？
- 有哪些與這個估算相關的活動？
- 作者是否參與各模塊開發活動估算？
- 開發相關人員是否都參與集成測試活動估算？
- 是否會議方式估算？
- 有哪些與這個估算相關的績效？
- 詳細設計估算是否完整有效？
- 編碼估算是否完整有效？
- 單元測試估算是否完整有效？
- 集成測試用例估算是否完整有效？
- 集成測試執行估算是否完整有效？
- 偏差超過約定的偏差值是否再次估算？
- 估算報告是否及時歸檔？
層次這個概念在很多地方都有應用。看看我們公司的結構，你就可以體會到層次的普遍應用程度。不同層次的，就不會在同一個級別的領導之下。比如，生產、財務、市場都是在同一個層次上。我們不會把“融資”放在同一個層次，它一定是在財務底下的。
層次會影響效率。比如我們的檢查單，合理的層次，會讓員工與QA更明確各個部分的重要性，在開展工作的時候也可以更好地掌握注意力。
要了解層次，可以這樣看：同一個層次的，是比較相對獨立，互不影響的。低一個層次的，是它上面層次的一部分，或者說，是會對上面層次的提供貢獻。比如：“是否按時進行了二次估算？”和“有哪些與這個估算相關的活動？”是相對獨立的。但“作者是否參與各模塊開發活動估算？”就是與估算相關的活動之一。這個有點像CMMI的級別定義原則。這些都是幫助有效的理念，並且被廣泛應用在過程管理與以外的很多方面的。
檢查單的組織可以考慮條項的層次。
如果不瞭解這個“層次”的觀念，就請你提問。我們務必交流清楚。
6）下一步就是分辨符合性與有效性。還記得上面提到的三個考慮麼：
- 每一個條款或是步驟是爲什麼，要解決什麼問題？（要解決什麼？）
- 這個條款或是步驟有什麼後果？ （有什麼後果？）
- 這些要解決的問題與實施後果如何影響項目的目標？（對項目的影響與風險）
我們要知道，如果問題是：
- 是否按時進行了二次估算？
我們的答案就會是“是”或是“否”。這個問題要解決的，就是：你是否遵從計劃？是一個符合性的問題。所以解答這個問題一點都不難。但是如果問題是：
- 完成二次估算的時間對項目有什麼影響？
這個問題要知道完成時間對項目有什麼影響，要知道估算知否有效。這纔是有效性的檢查項。回答這個問題就一點都不簡單。我們要知道這個完成時間有什麼後果。早於計劃的要求完成？按計劃時間要求完成？超時了？超了一點點？超了很多？還有更厲害的：這個模塊/任務是否在關鍵路徑上面？我們要知道所有這些，可能還有其他的，才能作一個判斷。做這個判斷，就要知道關鍵因素與它們的後果。比如：
估算晚了兩個星期。但這是一個2 年的項目，而且這個任務可以有5 個星期的靈活性。那麼，這樣晚了兩個星期的作用就不很大。他是不符合。但後果不大。
如果估算晚了兩個星期，項目是2 年的項目，而且任務是在關鍵路徑上。後果就可能讓項目延誤兩星期。是大概2 %的延誤。這樣的延誤，絕大部分客戶可能發現（重要），但都不會太計較的（不嚴重）。
如果估算晚了兩天，任務在關鍵路徑，項目是2個月的項目。這樣問題就嚴重好多了。
所以如果要作有效性審覈，我們需要知道關鍵因素，以及他們的後果。
一個步驟的目的，如果單單是看項目是否符合，而不考慮後果的，這樣的管理，目的就是在於“限制行爲”。限制或是規範行爲的壞處，就是引起項目的抗拒。所以“限制行爲”的管理很難有好效果的。
7）那麼，我們可以開始把這些關鍵因素組織一下，爲把檢查單改變成爲有效性的檢查單做準備。我們需要把原本的改成符合與有效兼顧，並且增加一些遺漏的關鍵因素。首先，我們可以把下面的條項：
- 是否按時進行了二次估算？
- 作者是否參與集成測試活動估算？
- 有哪些與這個估算相關的活動？
- 作者是否參與各模塊開發活動估算？
- 開發相關人員是否都參與集成測試活動估算？
- 是否會議方式估算？
- 有哪些與這個估算相關的績效？
- 詳細設計估算是否完整有效？
- 編碼估算是否完整有效？
- 單元測試估算是否完整有效？
- 集成測試用例估算是否完整有效？
- 集成測試執行估算是否完整有效？
- 偏差超過約定的偏差值是否再次估算？
- 估算報告是否及時歸檔？
小心看一下，用提高效率的觀點，考慮每一個條項的後果，改編成有效性的條款，如下：
- 估算完成的時間對項目的影響：
- 作者樂於承諾估算結果的程度與原因：
- （暫時忽略）
- 估算的方法與過程保證了估算的合理性：
- （暫時忽略）
- （暫時忽略）
- 估算結果得到維護與使用：（包含了“估算報告是否及時歸檔？”）
我們現在加入我提到的三個因素：
- 負責任務的人親自牽頭估算
- 大家（項目組與客戶）對任務範圍與內容的認識是一致的。
- 方法與參考數據的使用是合理的
檢查單就變成：（斜字代表這個步驟新加進來的。）
- 估算完成時間對項目的影響：
- 作者樂於承諾估算結果的程度與原因：
- 負責任務的人牽頭估算
- 估算的方法與過程保證了估算的合理性：
- 大家對任務範圍與內容有一致的認識
- 估算方法適合項目要求
- 方法的調整是合理的
- 估算結果得到維護與使用：
- 項目計劃使用了估算結果來安排任務
如果需要，可以把原來的符合性的放回去。可以把它們放在另一個部分，也可以把它們放在適合的層次。比如：
- 估算完成得時間對項目的影響：
· 是否按時進行了二次估算？
- 作者樂於承諾估算結果的程度與原因:
· 負責任務的人牽頭估算
- 估算的方法與過程保證了估算的合理性:
· 大家對任務範圍與內容有一致的認識
· 估算方法適合項目要求
· 方法的調整是合理的
· 是否會議方式估算？
· 作者是否參與各模塊開發活動估算？
· 開發相關人員是否都參與集成測試活動估算
· （如果用Delphi方法）偏差超過約定的偏差值是否再次估算？
- 估算結果得到維護與使用：
· 估算結果在計劃裏項目計劃使用了估算結果來安排任務
· 估算報告是否及時歸檔？
- 以往估算的績效：
· 詳細設計估算是否完整有效？
· 編碼估算是否完整有效？
· 單元測試估算是否完整有效？
· 集成測試用例估算是否完整有效？
· 集成測試執行估算是否完整有效？
現在的檢查單包含了本來的條項，也包括了從有效性的角度的內容。但有效性方面還是不充分的。所以我們需要每一個條項都問這個問題：
我如何可以判斷這些條項的有效程度？這個也需要我們瞭解過程的關鍵因素！
上面已經提到過估算的完成時間如何影響項目。包括延誤的比率、客戶的要求、任務是否在關鍵路徑等等。其他的，我就把我考慮的加到相關的條項底下，如下：
- 估算完成得時間對項目的影響：
· 是否按時進行了二次估算？
· 延誤程度對比項目的里程碑與週期的影響有多嚴重
· 延誤如何對比任務的關鍵路徑寬容時間
· 考慮這個任務的關鍵性與項目對它的依賴程度
- 作者樂於承諾估算結果的程度與原因:
· 負責任務的人牽頭估算
· 判斷負責人對結果的信心
· 查看負責人以前的承諾（按時完成任務）表現
- 估算的方法與過程保證了估算的合理性:
· 大家對任務範圍與內容有一致的認識
o 在如下面兩條羅列的估算活動以及其他情況底下，多方面的干係人的表達是一致的。
o 如果有開估算會議，討論覆蓋足夠的內容與議素，但進行順利，沒有理解不一致的跡象。
o （還可以有其他的蛛絲馬跡來判斷）
· 估算方法的效能適合項目的目標
· 參考與使用的歷史數據與對比、調整的合理性
· 是否會議方式估算？
· 作者是否參與各模塊開發活動估算？
· 開發相關人員是否都參與集成測試活動估算？
· 偏差超過約定的偏差值是否再次估算？
- 估算結果得到維護與使用：
· 項目計劃使用了估算結果來安排任務
· 項目明確有哪些活動受這個估算結果影響（可以更好處理將來的延誤）
· 估算報告是否及時歸檔？
- 以往估算的績效：
· 詳細設計估算是否完整有效？
· 編碼估算是否完整有效？
· 單元測試估算是否完整有效？
· 集成測試用例估算是否完整有效？
· 集成測試執行估算是否完整有效？
希望大家可以關注到這裏檢查點之間的關聯性，以及我們的步驟如何影響項目的專注。
8）上面的表就是一個從你們本來使用的檢查單，增加了審覈有效性的角度而得來的。讓我們把這個資料放到一個表格裏：
|
因素
|
後果
|
檢查項
|
檢查方法
|
符合
|
|
估算完成得時間對項目的影響
|
|
是否按時進行了二次估算？
|
|
|
|
延誤程度對比項目的里程碑與週期的影響有多嚴重
|
|
|
||
|
延誤如何對比任務的關鍵路徑寬容時間
|
|
|
||
|
考慮這個任務的關鍵性慾項目對它的依賴程度
|
|
|
||
|
作者樂於承諾估算結果的程度與原因
|
|
負責任務的人牽頭估算
|
|
|
|
判斷負責人對結果的信心
|
|
|
||
|
查看負責人以前的承諾（按時完成任務）表現
|
|
|
||
|
估算的方法與過程保證了估算的合理性
|
|
大家對任務範圍與內容有一致的認識
|
|
|
|
估算方法的效能適合項目的目標
|
|
|
||
|
參考與使用的歷史數據與對比、調整的合理性
|
|
|
||
|
是否會議方式估算？
|
|
|
||
|
作者是否參與各模塊開發活動估算？
|
|
|
||
|
開發相關人員是否都參與集成測試活動估算？
|
|
|
||
|
估算結果得到維護與使用
|
|
項目計劃使用了估算結果來安排任務
|
|
|
|
項目明確有哪些活動受這個估算結果影響
|
|
|
||
|
估算報告是否及時歸檔？
|
|
|
||
|
偏差超過約定的偏差值是否再次估算？
|
|
|
大家可以補充“檢查方法”這一列。大家也可以按這個思路，增、減因素與檢查項的內容與細節。其實標準的檢查單，也應該可以讓大家按情況“調整”。請留意，我不說修改，而說調整，含義是：我們需要按標準的思路，讓它更有效，而不是把內容隨意變動。我說的明白麼？
這樣的表格跟以前的有兩個分別：
- 語氣是開放式的，不鼓勵是否地打勾。每填一個條項，都希望QA知道需要明白後果。以後習慣了這樣思維，我們就可以不那麼關注語氣的問題了。我鼓勵大家目前還是在意一點比較好。
- 內容多了一些有效性的關鍵因素。這個是可以積累的。我們需要從工作中觀察，以需要多討論，多交流，多看書。一位QA發現一個關鍵因素之後，不能單單加到自己的檢查單裏。QA小組最好組織討論會議，讓每一位QA都知道一個關鍵因素的來龍去脈，原因後果。這樣才能讓QA團隊的經驗建立起來。
也請留意，每一個關鍵因素都有數個檢查項，但對項目來說，同一個關鍵因素的所有檢查項加起來只有一個後果，我們不單單在乎是否打勾，而是要判斷項目的表現有什麼後果。我們可以按關鍵因素預設一些後果。比如：超越預期、沒有風險、有可承擔的風險、有不可承擔的風險、不可承擔又不可緩解的風險等。項目的操作狀態，就是這幾個關鍵因素的執行後果。每一個關鍵因素的後果，都取決於它下面的檢查項。但我以前也說過，我覺得每一項打分，然後加起來，不是一個很好的方法，因爲有些條項的重要性，會因爲其他的條項內容而改變的。我們可以這樣做，然後參考那些分數。只是不要把分數看成決定一切就可以了。
想象一下，如果我們的QA審覈報告都是這樣的，大家就會越來越清楚如何提高項目的效率。將來的過程問題，大部分都可以從QA報告的歷史資料找到答案。過程改進將會變得非常容易。
9）不要以爲這是唯一的有效性檢查單，所以不要把這個看成經典。有效性的檢查單可以有很多。比如，我們如果不一定要求從你們本來的檢查單開始，我們可以從我提到的三個因素開始。那麼，檢查單就會不一樣。
我們要能夠分辨得細一點，要爭取了解細一點的議素。比如，不要把上面的檢查單看成固定不變的。但也不要以爲什麼事情都不能是固定的。有些事情固定了，就不靈活，不能適應不同的情況，效果就不好。有些事情是不會改變的，改了，就沒有效果了。如何判斷呢？
基本上：
- 因果關係是不會變的。沒有了因，就不會有果。
- 解決方案，就幾乎永遠都會有不同的方案，達到相同或是接近的效果。
要進步，我們就要慢慢掌握這些理念，並且能夠把它應用到自己的工作上。