摘要：我們在代碼上取得的進步，但在影響代碼的設計和需求上，需要做出正確的判斷。通過評審活動，降低因個人能力可能帶來的風險。而評審活動更多的是主觀的過程，我們建議採用PPQA督促+工具（DMP，SVN）方式來如實反映評審活動的數據，爲提高評審的質量和覆蓋率提供科學的依據。
參考：
lDMP評審流程；
lSVN LOG PRE-COMMIT；
l阿里巴巴評審情況說明【孟子】；
l部分度量數據參考：IBMIPD-CMMI；
lDEVOPS；
1.背景
SONAR推廣有半年以上時間，在代碼質量方面，我們取得了進步。正如一個蓋房子，我們具備了熟練的工人，要造出好的房子，還需要在需求和設計上下功夫。軟件過程中的評審，正是解決這個問題的重要方法之一。
2.障礙
2.1.時間因素
大家通常疲於應付工作，天天面對各個任務的最後期限，時間被塞的滿滿的。很少或沒有爲評審計劃時間。
2.2.一團和氣
評審發現的問題，內部消化，根據DMP要求填寫字段，不能如實反映真實情況。
度量數據作爲考覈依據，大家不願意如實填寫。
2.3.無法對評審活動和結果進行測量和管理
什麼被評審？什麼沒有被評審？評審有多徹底?有多有效？風險部分在哪裏？
2.4.文檔長度太長容易提高逃逸率
一個文檔太長，有需要在限定時間完成，部分章節被跳過評審。
3.應對
3.1.原則
評審更多的是主觀過程，我們主要靠人的監督，輔助工具來完成評審質量的提升。
l允許錯誤，不允許犯戒【堅決反對數據造假】；
l評審中發現的問題度量數據不作爲考覈數據；
l引入PPQA作爲參與者，監督者，全量全程參與；
l嚴格控制SVN提交【沒有評審ID或問題ID禁止提交】；
l建議最大文檔有效內容：20-24頁，【參考IBMIPD-CMMI，評審效率10-12頁/小時；從人的行爲心理學來說，太長的文件評審容易跳過某些內容章節】；
l建議評審時間不超過2小時【參考SmartBearSoftware，超過2小時後，評審效率降低】。評審的確很長，建議中途休息30-60分鐘。
l參與評審的人數：4-8人。【人多了，帶來太多發散；有的人就是來打醬油的；會議成本很高】。
l文檔的確很長的，可以分章節，分層次評審。
3.2.步驟
3.2.1.制定一個月計劃
經理必須爲評審預留時間。
根據同比和環比，大概可以確定一個月可能的需求，可能的評審。
比較簡單的做法：
無大項目狀態：本月需求=（同比需求+環比需求）/2。
有大項目狀態：採用類比/類推方法，根據上一個類似項目需求時間變化曲線，得到需求時間增長率，計算得到可能的需求數。
評審項識別：在做計劃的時候,需要識別出哪些設計/方案/文檔是需要評審的, 讓PPQA做出評審計劃。[w1]
3.2.2.評審內容自己先審查
代碼已經可以通過SONAR檢查，文檔需要比對文檔模板。在評審過程中出現格式錯誤，是不可接受的。
自己覺得審查不夠，可以請人幫忙。
這個時候，文檔提交到SVN。
3.2.3.選擇評審委員
不同的評審需要選擇不同角色的評委。在選擇評委的時候必須注意互補性。
工作產品類型 | 建議參與角色 |
需求規格說明書 | 需求分析師，項目經理，架構師，系統測試工程師，PPQA，用戶或市場代表，文檔工程師，業務專家，IT人員 |
項目計劃 | 項目經理，需求提出者，用戶或市場代表，技術負責人，PPQA |
架構或概要設計 | 技術經理，架構師，需求分析師，設計師，測試工程師 |
詳細設計 | 設計師，架構師，程序員，測試工程師 |
測試文檔 | 測試工程師，程序員（單元測試）或架構師（集成測試）或需求分析師（系統測試），質量保證代表 |
源代碼 | 程序員，設計師，維護者，編碼標準專家 |
用戶界面設計 | 用戶界面設計師，市場代表，測試工程師 |
可選內部角色：
l需求分析師
l項目經理
l技術經理
lPPQA
l架構師
l程序員
l測試工程師
lIT人員
l業務專家
l有接口的產品對應人員
l市場代表
l文檔工程師
l用戶界面設計師
3.2.4.評審內容郵件發送，做到預評審
提前時間參考量：10頁/天
注：這裏的頁數：有效頁數。
預評審最低預留時間：0.5天。
3.2.5.評審過程
請根據評審類型的CHECKLIST，客觀評審。
評審注意事項：參考評審培訓。
3.2.6.PPQA必須參加評審會議，如實記錄
CMMI模型進一步強調的是過程和產品質量保證和評價，即PPQA。
PPQA應該參與到評審的過程中。
問題描述：作者，第幾頁（章節），問題的大小（由評審組決定）
3.2.7.評審錄入
發現的問題轉換爲問題，在DMP錄入。評審會議上必須爲每個問題指定審覈者。
如果問題較嚴重，可以重新評審（評審組決定）。
3.2.8.文檔提交SVN，必須有評審號/問題號。
評審後文檔接受SVN監管。
如果向SVN提交文檔變化，必須有評審號或問題號。
評審號和問題號來自DMP。
3.2.9.問題跟蹤
1 PPQA負責跟蹤，在DMP上跟蹤。
2 記錄解決問題的時長。
3 因爲問題修改提交SVN，必須有問題ID號
注意事項：
1.評審中發現的問題而觸發的修改，一律以修訂模式保存。
2.PPQA檢查文檔修改結果，確認後審閱通過再提交到SVN。
3.3.評審審查
評審審查是糾正評審中的方向。
3.3.1.根據評審結果跟蹤：
業界的通用準則如下：
（1）設計同行評審工作量應占設計階段總工作量的1/3以上，其質量準則爲：設計文檔同行評審應該至少發現3個缺陷/頁。經評審修改後，缺陷清除率1級100%，2級100%，3級80%以上，殘留缺陷密度控制在0.5個/頁以下。
（2）代碼同行評審工作量應占實現階段總工作量的1/3以上。
（3）同行評審準備過程發現的缺陷數應該是同行評審會上發現的缺陷數的2倍以上。
發現數據偏離公司數據或行業參考數據的，及時瞭解情況。
如果是確認的數據，進入公司數據。
3.3.2.根據BUG結果跟蹤：
可以通過魚骨圖，因果圖來判斷評審中的質量。
需要指出的，BUG需要追溯到最早偏離點。
3.3.3.在月報上反映
l在評審週報上列出非正常提交的TOP3，並請產品經理分析原因並整改。
l在評審週報上列出下列指標
1.評審文檔覆蓋率：實際評審文檔/SVN上實際文檔
3.4.評審獎勵
通過積分獎勵：
發現一個重大問題：獎勵5分
發現一個普通問題：獎勵3分
發現一個輕微問題：獎勵1分。
多人共同發現，分數均攤。
3.5.文檔受控過程
文檔提交到SVN即接受監管。
3.6.CHECKLIST更新
由於面對的項目，技術水平差異，建議一年更新一次CHECKLIST。請李小平（總）牽頭CHECKLIST更新。
4.評審結果行業參考值
阿里巴巴孟子：review人員有30%責任；阿里希望能夠通過流程和機制來消除PM個人能力導致的項目風險，但是目前來看，重大的項目還是不行，一般的需求和項目基本可控。
5.時間計劃
時間點 | 任務 | 輸出物 |
12月13日前 | 完成評審工作開展準備； 得到領導認可 | 評審過程文檔； |
12月14日-15日 | 分2批和開發人員討論評審過程 | 修訂後的評審過程文檔 |
12月16日 | 評審文檔再確認 | 最終評審過程文檔 |
12月17日 | 工具，接口確認 | 腳本 |
12月18日-20日 | 評審活動推廣，解釋 | 活動記錄 |
6.評審培訓
評審培訓在週末或晚上舉行。每個人都要參與，掌握評審方法，技巧。
6.1.主持人培訓
6.1.1.對象
每個人都可能成爲主持人，每個人都應該參與。
6.1.2.評審設計
主持人要選擇評委：選擇的角色是否恰當。
選擇哪些是重點評審
如何引導評審的方向。
6.1.3.評審準備
包含評審材料，如果準備不充分，延遲評審。
6.1.4.明確評審目標
不要被不是目標的話題轉移後不能回來或在某個細節上花費太多時間。
6.1.5.設計方案得到認同時，引導大家討論方案中風險點
如果講述完文檔，大家都十分認同，而且也找不到任何問題，在這種情況下，主持人應該把討論轉向是否有潛在問題，是否存在風險的話題上。
6.2.評委培訓
6.2.1.對象
每個人都可能成爲評委，每個人都應該參與。
6.2.2.評委的主觀意見
尤其在評審中涉及到界面風格的時候，主觀意見很突出。設計者應該說明自己是根據什麼規範和什麼原則來設計的。
6.2.3.評審意見模糊
這種結論無益結果的改進。
6.2.4.嚴禁破壞性評審
6.2.5.關注評審內容，而不是評審人
6.2.6.表達個人喜好一定要提前聲明
這樣既可以讓設計師瞭解到評審人員的直觀感受，又避免了上述評論成爲評審中討論的重點。
6.2.7.肯定做的好的一面
一方面是對設計師所做工作的肯定，另一方面明確了哪些部分是比較好的，需要保留並可以繼續探索。
6.2.8.不要被設計者的假設條件迷惑
也不是要全面否認，能從歷史項目和經驗中，發現不正常的假設條件。
7.典型案例[w2]
7.1.一個設計評審
程序員小強接受經理安排，對某個需求編寫了一個設計，現在需要評審。
小強該怎麼操作呢？
1.小強根據需求類型（項目類型）在公司的文檔模板庫找到對應的文檔模板。
包含:設計模板，設計評審模板
2.小強在瞭解需求後在模板上編寫設計，一共寫了20頁（有效頁數15頁）。設計文檔必須指明實現了需求的那個章節（功能點）和需求約束（如性能）。
3.小強根據設計評審模板，自己檢查注意事項。
4.小強對自己的設計審查不放心，請經理幫忙審查一下。
5.小強從PPQA小田那裏得到文檔應該存放的SVN路徑，並提交到SVN。
6.小強請經理一起確定參加評審的角色，評委清單。
7.小強預訂會議室。
8.經理髮送郵件，通知參加評審的人，包含評審對象，評審的作者，評審時間，評審目標，評審參考的CHECKLIST。
9.小強發現設計有些問題，以修訂方式修改文檔，沒有提交到SVN。
禁止在發出評審通知後以普通方式修改文檔，如果評審時候評委發現文檔差異，預評審就失去意義。
10.評委收到通知後，抽空閱讀文檔，並把自己的意見標註。
11.2天后評審會議在會議室舉行（15頁/10（頁/天）=1.5 =2天）
12.小強心裏回顧了一下評審注意事項，開始評審會議。
13.小強花5分鐘總體介紹了評審對象，2分鐘介紹評審目標。
14.小強根據文檔順序，介紹章節標題，大家根據預審發現的問題，及時提出問題。
15.在某個問題上，大家爭論不休，PPQA提醒大家，這個問題花費了10分鐘，請先擱置，作爲存在的問題，會下繼續討論。技術經理決定這個問題是否還需要重新召開評審會議。
16.大家繼續評審。花費60分鐘
17.評審對象結束後，評審作者綜述評審活動，指出肯定的地方和存在問題的地方。花費5分鐘。
18.評委決定該評審的結論：通過/有條件通過/不通過。PPQA記錄。花費3分鐘。
19.技術經理指定問題的跟蹤人員。花費2分鐘。
20.評審作者將評審文檔提交到SVN（非修訂方式）。
21.評審作者在DMP錄入評審信息，包含問題。
22.PPQA收到評審信息後，覈查信息是否和會議結論一致。
。。。
23.評審對象作者以修訂方式修改評審中發現問題，完成後提交到SVN（修訂方式）。（SVN LOG需要指明問題編號）
24.問題跟蹤者從SVN下載文檔，覈查問題是否修改。如果問題得到修改，將修訂模式取消，提交到SVN。（SVN LOG需要指明問題編號）
25.問題跟蹤者將DMP上對應問題關閉。
。。。
26.SQA（崇斯田）根據DMP信息，覈對度量數據，對發現偏離值40%的評審進行調查。
7.2.問題和討論
問題：
1.如果是需求評審，該怎麼辦？
2.如果小強的設計有外部接口，該如何辦？
3.如果外部接口存在爭論而沒有結論，是否應該重新評審。
4.如果評審中沒有發現問題，該怎麼辦？
回答：
1.需求評審的文檔模板不同，需要選擇的評委角色不同。
2.需要通知到外部接口負責人蔘與評審，優先評審外部接口。
3.必須的。不過新開評審只需討論接口。作者應該在會下再設計接口定義。
4.評審主持引導大家討論可能的風險，假設。時間控制應該在預計會議時間的一半時間。
8.評審度量統計
8.1.第一階段：產品級別統計
8.1.1.評審覆蓋率
以文檔爲單位統計覆蓋率。
1.PPQA統計自己對應產品的評審覆蓋率。
PPQA從DMP上獲取被評審的文檔個數，頁數（需求/設計）。
PPQA從SVN上獲取被監管的文檔個數，頁數（需求/設計）。
PPQA計算文檔覆蓋率。包含文檔個數覆蓋率，頁數覆蓋率。
8.1.2.評審發現問題
1.PPQA統計自己對應產品的評審覆蓋率。
PPQA從DMP上獲取被評審的文檔個數，頁數（需求/設計）。
PPQA從SVN上獲取被監管的文檔個數，頁數（需求/設計）。
PPQA計算文檔覆蓋率。包含文檔個數覆蓋率，頁數覆蓋率。
8.1.3.評審問題跟蹤
1.PPQA負責對應產品的評審問題跟蹤。
PPQA從DMP上獲取被評審的文檔問題數據。
包含問題大小，是否解決，解決時間。
8.1.4.SQA合併報表
SQA每週/月合併報表。
8.2.第二階段：精細化統計
8.2.1.個人文檔質量
8.2.2.個人評委質量
8.2.3.評審覆蓋率（頁/章節）
8.2.4.重複出現的問題
評審的質量