今早一金融行業企業CMMI啟動會上，發起人（公司領導） 對如何提升交付質量時，便提到過去專案大部分過程中的 缺陷大部分都是後期，例如系統測試時發現， 很多需求 / 設計 階段的缺陷未在本階段被發現。 他希望大家加強前期的評審， 如需求 、 設計，降低早期引發缺陷，導致後期大量返工。

我估計這發起人有超過30年的 開發行業經驗， 他非常瞭解有效的評審對質量的重要。

讓我們看看CMMI的最佳實踐可如何幫助企業做好 “同行評審”：

PEER REVIEWS 同行評審 (PR)

CMMI V2.0從V1.3特別抽出“驗證”(VER) 中的第二目標“同行評審”作為一個單獨的PA。 可見CMMI也認同同行評審確實可以幫助專案預早找出缺陷和問題，減少後面的返工。

在V2.0， 大部分同行評審的大部分實踐屬於CMMI 2級 (分析部分屬於3級)。以前在V1.3，“驗證”(VER)，包括同行評審， 屬於 3級，工程部分。

同行評審案例分享

越來越多人關注敏捷開發，這幾天在杭州的客戶現場，剛好就有本地諮詢顧問，印度CMMI評估師 和我。 印度老師 除了有20年的CMMI經驗外，也是敏捷的導師。有些人誤解以為敏捷就是要減輕過程，可以不需要文件，只是把開發做好便可以。

這是不對的，這例子說明可以使用一些CMMI的最佳實踐，提高無論是敏捷或傳統開發。

我們在和測試人員討論他們如何評審測試用例，他們說直接把寫好的測試用例發主管，主管覺得可以就可以。其中一位評估組成員覺得不合適，另一位偏敏捷的覺得同行評審測試用例這活動沒有價值，可以節省掉不做。

印度老師說：同行評審有多個不同的形式，有些較嚴格，有些較省力，如發郵件去讓其他人看。

問：對不同的產物有那些不同的評審方法？ 這企業就展示出在專案計劃中的一個列表：

- 需求 - 需要客戶評審

- 設計 - 需要同行評審

- 程式碼 - 也是同行評審

問：同行評審如何定義？ 規定怎樣做？

這企業不同人有不同的理解，公司級也沒有明確定義。

老師接著說：如果同行評審是指審查(Inspection)，程式碼也用正式同行評審是很理想，但可能太費力了，不太實際。

評審方法有很多，常見的包括：

1  審查(Inspection) - 最正規，最嚴謹的方法，通常用於重要的產物，比如框架的設計

2  走查(Walkthrough) - 要求低一些，例如 一起開會，把產物投出來一起看

3  最簡單也可以是兩個人互相檢視，或者發郵件

(如想多瞭解各種同行評審的方法，詳見 PR 同行評審 Peer Review*)

老師接著說：計劃時也要定那些工作產品選用那種評審；例如，像以上那種只說設計/程式碼都是採用某種評審方法便太籠統

他還建議需要有一個專案的質量計劃 (Quality Plan)，預先列出對那些階段的那有產物採取什麼方法來評審。 例如：程式碼評審 - 核心的程式碼你可能就需要做正規的同行評審。但是如果是一些使用者介面那種就簡單一點，但必須要質量計劃(或專案計劃)裡面預先定好，然後按照計劃去做。

最後關於測試用例我們都總結應該要評審的，但是是否所有案例都要評審就看企業需要，起碼關鍵核心的需要做評審。

用 V2.0 解讀上面案例

- PR 2.1 制定同行評審的步驟：需要做同行評審的產物的準則？例如 審查(Inspection) 要怎樣做；也要包括 同行評審的檢查單、模板等，應在公司級制定好。

- PR 2.2 選擇同行評審的產物：正如案例所說，應該在計劃中依據重要程度和預計工作量的經歷，預先規定哪些產物需要什麼方式來評審？哪些需要做評審；哪些不需要做評審。

評審是要耗費人力/時間，所以針對一些重要的產物，才要花人力評審。

- PR 2.3 跟V1.3 的 VER 視訊。2 差不多，同行評審的準備和記錄， 把所有發現的缺陷和應對措施都記錄下來。

- PR 2.4 是新增的,以前v1.3沒有。同行評審最重要的就是跟蹤缺陷，所以必須跟蹤所有缺陷，直到被關閉。缺陷的跟蹤中，有些缺陷在同行評審中就已經被解決，但對需要後面處理的就必須記錄下來、進行跟蹤，制定一個通過標準。

評審最大目標是找出問題，所以特別加這一條，要解決那些發現的問題。

分析並提升(PR 3.1)

從不同維度來做分析，例如：同行評審缺陷源自那個階段？哪類缺陷較多；缺陷的原因等等。從這些分析就可以幫我們判斷哪些同行評審方法最有效，利用同行評審儘早找出缺陷。

利用系統再進一步提升

很多開發團隊都會使用系統和自動化提高質量與生產率。 

例如，測試如果還是用手工的話，你應該想如何開始用自動化測試？

你可以想，我們很多時候測試用例需要複用，迴歸測試。如果靠人工去迴歸測試，很耗時間，效率很低。所以無論是國外還是大陸比較做產品的公司都開始做使用自動化測試，這也是利用系統可以幫助我們做真正改進的一個例子。

如果一個公司以測試人員能力不夠，時間不允許等為藉口，這類公司是很難有真正的提升。

所以另外一個我接觸的顧問，他每次都會問客戶：你現在有沒有用自動化測試？如果沒有的話，他會說為什麼你不做？

我們也合作在杭州做一個很好的敏捷試點，也是利用了自動化測試加上一些度量，確實無論對質量和生產率都有了顯著的提升。

同樣思路，很多團隊都開始使用自動程式碼走查工具來檢查程式碼問題。

但核心程式碼 還是要有經驗的人評審，自動工具代替不了。

PR 同行評審 Peer Review連結如下：http://mwiki.processis.com/agile.cmmi/index.php/PR_%E5%90%8C%E8%A1%8C%E8%AF%84%E5%AE%A1_Peer_Review

也歡迎聯絡我們來獲得相關資料。

聯絡我們

電話：18921395967

QQ：1228021190

微信：processis2009

地址：香港/北京/江蘇

官網：www.processis.org