軟體專案的過程評審(轉載)

我們在管理軟體專案時，常常會出現在測試階段和使用者驗收階段缺陷率太高，需要投入大量的人去修bug, 但是由於時間緊，往往改好一個bug,又引入新的bug,導致惡性迴圈，越改bug越多。最後專案延期，成本超出預算，員工對加班意見很大，客戶也對交付的軟體不滿意。造成這樣後果的原因很多，比如需求分析沒有做好，設計沒有做好等等，有一個原因大家往往容易忽視，那就是過程的評審(Review)。

在設計，編碼，測試各個階段都需要做很好的review，不能走過場，比如，專案經理對Lead說，“你把設計文件review 一下”，“你把開發人員的程式碼review一下”，Lead點點頭，結果沒有下文，或者馬馬虎虎花個幾分鐘看看，就算了，根本起不到review的作用。要真正讓review發揮作用，儘早發現設計和開發過程的缺陷，必須要建立嚴格的review流程：

1. 專案經理制定專案計劃的時候需要把review的時間考慮進去，專案計劃裡面要體現review, rework的時間，週期。

2. 要根據專案的需要，建立review的 check list. 比如程式碼評審，需要根據規範建立評審項。

3. 在專案執行過程中，嚴格按照專案計劃進行評審，安排評審會議。在會議前按照checklist 對設計文件或程式碼進行review，生成review報告。在評審會議中，對報告的內容進行分析和討論，review出的缺陷要記錄文件或系統。

4. 對review的缺陷進行修復

5. 定期對缺陷的原因進行分析，採取措施，避免以後發生同樣的問題

6. 專案結束後，對review的效果進行統計分析，一般有兩個指標衡量review的效果, 1) review efficiency 2) review effectiveness, 按照行業的標準，一般情況下，如果review找到的缺陷達到專案發現的總缺陷的60%以上( review effectiveness)，或者review 每小時能找到1.5個以上的bug. 說明review起來比較好的效果。如果沒有到達，那麼分析原因，採取措施，以後逐步改進。

總之，只要對過程評審足夠重視，並真正地落實，才能發揮評審的作用，儘早發現專案中存在的問題和缺陷，降低總的缺陷數量，減少後期維護成本。