同行評審對於軟體企業來說是很有效的一種方式，無論是國外還是國內企業越來越認識到了同行評審的重要性，但是在實施的過程中效果不是很理想，常常會出現走形式，使評審會議變成了討論會議，對具體的問題爭論不休，經常離題，使評審的效果大大的降低。我在實施的過程中根據同行評審的要求，總結出來以下經驗供大家參考，同行評審的目的是及早高效的發現並消除開發過程中出現的缺陷。很多公司也制定了相應的評審流程，項目開始的時候也做了評審計畫，但是在具體的實踐中把握不好一些細節的東西，這些主要的問題大多數發生在評審會議的組織上，而這些細小的環節才是評審是否成果的關鍵。只有評審會議比較完滿了，其他修改bug、消除缺陷都比較容易完成。我在這裡主要講一下評審會議的組織，至於評審計畫、評審執行過程的數據採集、測量等環節不再詳述。
評審會議流程一般採取以下幾個步驟：評審會議的準備、評審會議的召開、評審會議的跟蹤三大環節。
一、評審會議的準備
會議的發起人召集會議，發出評審通知（評審內容、會議時間、會議地點、參加人員等），並且將相關待評審的相關資料也傳送給參加會議的評審；主要的目的有兩個：第一、讓參加會議的人員對會議的內容有一定的了解，在會議前做好準備，避免盲目的參加會議而浪費自己和其他人的時間；第二、如果該評審在會議時間有其他緊急的事情，可以及早反饋給會議召集人，必便召集人重新確定評審或者評審會議改期召開。
二、評審會議的召開
一般情況下，確定一個會議主持人；其主要的職責是控制會議的進度、時間、協調會議中出現的偏差。
對於待評審的工作產品由其生產者採用“走讀”的形式進行講解，在講解的過程中回答評審提出的問題。
會議記錄人主要是記錄會議中發現的所有問題，方便會後的修改完善。
sqa人員參加會議主要的關注點在於對照sqa的檢查表checklist檢查評審的流程是否符合規範。
三、評審會議的跟蹤
將記錄的問題匯總到《評審記錄表》，由項目組進行修改、完善；sqa監督所有問題是否封閉。
附錄：
（1）列舉重要工作產品評審的重點：
a計畫的評審
主要是關注的核心在於估計是否準確；人員安排是否合理；以上兩個方面如果合理，項目的進度就不會出很大的問題。
b需求的評審
主要關注需求來源、需求的準確性、需求的完整性，避免產生二義性；最好讓測試人員和客戶參加，以便讓各角色達成共識。
c總體設計的評審
在總體設計評審中，最好將已經評審通過的需求文檔從配置管理庫中提出，對照總體設計是否和需求一致；另外，技術領域專家參加評審還要關注於設計的合理性、可實現性以及完整性。
d代碼評審
由項目組內進行代碼審核，主要關注代碼的格式、整體邏輯、變數的命名、程式注釋等表面的屬性；至於運行質量應當放在單元測試中解決。