簡介：本文以筆者的項目管理實踐為基礎，介紹基于經驗過程控制（Empirical Process Control）模型、缺陷預防以及敏捷價值觀的敏捷質量管理思想及其實踐。希望通過本文為廣大項目管理人員提供質量管理的一些思路和經驗分享。
經驗過程控制
經驗過程控制是一種問題驅動的輕型過程控制模型。在進一步介紹經驗過程控制之前，我們先看一個日常生活中應用經驗過程控制的一個例子：在菜肴的烹飪過程中，人們往往先觀察菜肴的顏色，或者用筷子檢查其軟硬度來判斷菜肴是否已經煮熟。若不夠熟，則繼續煮。待到菜肴快熟時，我們開始放鹽、味精之類的調料。然后嘗嘗菜肴的咸淡是否適中，若太淡了則繼續加鹽，直到我們滿意為止。經過這樣一個過程，烹飪者滿意的一道菜肴才能完成。
上述例子正好體現了經驗過程控制的三大支柱——透明性（Transparency）、檢查（Inspection）、適應（Adaption）。透明性指影響最終產出結果的因素對于過程控制者來說可觀察或者使其可觀察。“透明性”在上述例子中表現為：菜肴煮熟程度是影響菜肴質量的一個因素，而這個因素可以通過菜肴的顏色或其硬度反映出來。檢查指對影響最終產出的因素進行觀察和評價的動作。上述例子中提到的觀察菜肴的顏色、嘗嘗菜肴的咸淡就是“檢查”。適應指檢查過程中發現不可接受的結果、偏差時所采取的矯正動作。上述例子提及的在發現菜肴味道偏淡的情況下采取的繼續加鹽的動作就是“適應”。
從經驗過程控制的三大支柱我們可以看到其問題驅動的性質。問題驅動是指在過程實施時所進行的活動是基于有哪些因素影響了最終產出的結果，而不是像一些傳統的過程控制實施者是從一些預定義的活動集合中“剪裁”一些活動。從一個活動集合中剪裁出一些活動，這本身就要求剪裁者對這個活動集合中的每個活動足夠了解，從而能夠選擇適合自己的活動。這個剪裁的過程使得這些傳統的過程控制實施起來相對困難，而經驗過程控制因為省卻了“剪裁”的過程而使得其實施相對容易。
基于經驗過程控制的質量管理其實施的基本思路是先通過經驗或者對質量問題進行根因分析（Root Cause Analysis）發現影響質量的因素，再采取措施使這些因素成為可觀察的因素（對應經驗過程的“透明性”）。然后，在項目實施過程中對這些因素進行檢查（對應經驗過程控制的“檢查”）。檢查過程中發現不可接受的結果或者偏差時及時采取措施進行矯正以防止缺陷的引入或者缺陷流入下一道工序中（對應經驗過程控制的“適應”），從而保證了最終產出的質量。
缺陷預防
《孫子兵法·謀攻》中提到“百戰百勝非善之善者，不戰而屈人兵，善之善者”。每次打仗都取勝不是戰爭的最高境界，戰爭的最高境界是不費兵卒而取得勝利。同樣，在軟件開發過程中，找出所有缺陷并將其一一去除不是質量管理的最高境界。質量管理的最高境界是將缺陷扼殺在搖籃之中——缺陷預防。經驗過程控制三大支柱所體現的其問題驅動的特性說明了它可以幫助我們去實施缺陷預防。基于經驗過程控制的缺陷預防是通過使缺陷來源成為可觀察的因素，然后在軟件開發過程中對這些因素進行檢查，發現不可接受的偏差時及時采取措施進行矯正，從而避免了缺陷的引入。比如，當我們發現開發人員對需求理解的錯誤、不全面是缺陷的一個重要來源時，我們就可以應用經驗過程控制的思想，先采取措施使開發人員對需求的理解成為可觀察的因素。然后對其進行檢查，若發現有需求理解上的偏差，則進行矯正，從而避免了因需求理解偏差而引入缺陷。
誠然，軟件測試的目的是發現缺陷。也正因此大多數公司和個人也就把測試人員定位成缺陷的發現者。然而，測試畢竟是一種事后控制型的質量管理手段，這不是上上策。能否往測試人員這個角色的職責的定義中增加一個缺陷預防的職能呢？筆者曾經在所帶團隊中引導測試人員往缺陷預防方面發展，在這方面多做貢獻，而不是僅僅把自己定位為缺陷的發現者。在開發測試一體化團隊中，測試人員同開發人員一起參與需求分析、評審。項目經理可以通過一些獎勵措施鼓勵測試人員多去發現需求本身的錯誤以及開發人員對需求理解的偏差，從而避免了需求相關的缺陷。另一方面，測試人員往往習慣于從發現缺陷中獲得成就感。在引導測試人員在缺陷預防上多做貢獻的過程中，項目經理需要引導測試人員使其認識到預防缺陷比發現缺陷更加能夠體現一個人的能力和價值。
需求澄清
需求規格說明書本身的錯誤、不明確是軟件缺陷的一個重要來源。因此，消除需求本身的問題是缺陷預防的一個重要內容。筆者在所帶的項目中是通過開展需求澄清活動來消除需求本身的問題的。在開發團隊內部進行需求規格說明書評審之后，評審意見被匯總成一個列表，這個列表可以是一個 Excel 表格，我們稱之為需求問題確認列表。然后，我們邀請客戶過來和開發團隊一起對問題列表中的每個問題進行討論。團隊成員負責提出和解釋問題確認列表中的問題，客戶代表則負責解答和澄清團隊成員提出的問題。客戶對于問題的回復我們會記錄到問題確認列表的“回復”一欄。需求澄清活動往往是以頭腦風暴會議的形式展開的，而不僅僅是一個一問一答的過程。對于客戶當場給的問題回復，團隊成員可能因為通過自己的分析認為客戶的回復是錯誤或者不合理的而當場對客戶代表的回復提出質疑。客戶代表往往也因此對其回復進行重新思考從而給出與會人員一致認同的回復。
《敏捷宣言》中提到“客戶協作勝過合同談判”，需求澄清活動的基本前提就是客戶代表的參與。因此它是符合敏捷開發的價值觀的。
表 1. 需求澄清活動
需求宣講
團隊成員對需求理解的偏差也是軟件缺陷的一個重要來源。我們可以應用經驗過程控制的思想對這種因需求理解偏差而引入的缺陷進行預防。其基本思路是先使團隊成員對需求的理解成為可觀察的因素，然后對這個因素進行檢查。檢查過程中發現不可接受的偏差時及時采取措施進行糾正，從而避免了缺陷的引入。筆者通過在團隊內開展需求宣講活動來具體實施這個缺陷預防。
需求宣講是在開發人員開始編碼、測試人員開始設計測試用例前，由全體團隊成員參與的一個頭腦風暴會議。在這個會議上，開發人員隨機選取一個 Story，然后口頭表述其對所選擇的 Story 的理解。通過這個講解，開發人員對需求理解就成為了一個可以觀察的因素。當其他與會人從需求講解人的講解中發現其對需求理解上的偏差時，可以及時指出進行糾正。其他與會人員也可對其講解提出疑問和質疑。當講解人的回復無法得到團隊成員的一致認同時，則進行討論，最終達到對需求理解的一致。而對于討論無法達成一致認識的問題，可以記錄入需求問題確認列表會后再進行確認。
當然，當開發人員被要求講述其對需求的理解時，可能會說他其實已經理解了需求只是不知道如何表述。且不論這句話是否屬實，項目經理應當引導團隊成員意識到：在敏捷開發團隊中，個人對需求是如何理解的，理解的對與錯，深與淺不是其一個人的事情，而是整個團隊的事情，因為它影響了這個團隊最終交付的軟件的質量！從另外一個角度來講，當一個人能清晰得表述一件事物時，才說明其對這件事物是真正理解的。
雖然需求評審和需求澄清這兩個活動也能一定程度上反映活動參與者對需求的理解，但是它們更多的是用于發現需求本身的問題。而需求宣講則是專門用于檢驗活動參與者對需求的理解正確性和全面性。
表 2. 需求宣講活動
