定期專案現狀評審

軟體專案現狀評審（有時候稱為管理評估）可以為專案相關各方提供必要的資訊，以便進一步針對情況做出決策或者批覆，同時能跟蹤之前評審所做決策的執行情況。對於被拯救後重啟的專案而言，專案現狀評審作為EWS的一部分，也具有同樣的目的。這種評審能夠提供關於專案狀況的資訊，識別並監控目前存在的問題及其解決途徑，並確保關鍵的問題得到解決。

專案評審主要是基於資料的，這可以解釋針對開發度量指標收集資料工作的重要性。如果缺少了資料收集工作，那麼專案評估就變得毫無價值。這一點從12.1節所舉案例中的第一次評估可以看出來（這次評估的唯一價值在於確保了下一次可以做得更好）。

專案評估應該週期性地進行，通常每個月舉行一次。但特殊情況下可以增加頻率（例如每兩週舉行一次）或者偶爾降低頻率（每兩個月或者三個月舉行一次）。過多的專案評估會帶來額外的負擔（每次評估及其準備工作都要投入相當的時間和精力），但評估頻率太低的話則會導致問題積壓得不到有效的解決。

評估應該如何進行？這方面存在很多相關的標準，其中的一個例子就是IEEE Std 1028，該標準涵蓋了一個廣義範圍內的專案評估（包括管理評估，技術評估等）。雖然這些不同型別的評估都是可以根據情況靈活定製的，但對於一個只具備有限的軟體開發過程的開發機構而言，若把各種不同型別的評估都引入進來，那麼將是相當沉重的負擔。幸運的是，經歷過災難拯救過程並重啟後的專案的EWS系統不需要IEEE標準中所規定的全部評估內容。

在前一小節中，我們已經討論過如何在一個陷入災難的專案中引進度量指標，評審技術的引進與此類此：只需引進一個評審過程中的那些對於被拯救專案的成功完成來說必不可少的元素即可（當然，如果當前開發機構已經在使用某種有效且更全面的評估技術，那麼繼續使用它們）。

接下來，我們將討論如何將一個通用的專案評估標準（例如IEEE專案評估標準）修改成符合陷入災難的專案所需要的版本（其他的標準，例如ISO專案評估標準也可以同樣進行定製修改）。

1．專案現狀（管理）評審

IEEE標準涵蓋了多種型別的軟體專案評審：管理評估、技術評估、審查、走查和審計。對於陷入災難的專案而言，其EWS系統的最小所需是管理評估。該標準中明確了管理評估的目的在於：“監控軟體開發的程式，明確當前計劃實施的狀況，確認需求及為它們配置的資源，評估當前管理方法的有效性。管理評估能夠有效支援關於校正行動、資源配置變更或者專案範圍變更等的決策工作。”這一目標完全符合陷入災難的專案的EWS系統的需要。

2．評審參與者

專案現狀評審需要以下各方共同參與。

關鍵的管理決策者

評審領導人（主持評審過程的人）

記錄員（記錄評審過程中的主要事件和決定）

專案經理

技術人員

其他專案成員

客戶或顧客代表（可選）

根據實際情況的需要，也可以邀請其他個體參與有關問題的討論。

3．評估的時長

根據專案的規模和狀況，評估應花費兩個小時到一天的時間。

一個大型的專案或者問題比較多的專案可能需要一整天的時間來完成評估，但對於小型的專案（少於15人/年）或者沒有什麼大問題的專案而言，評估可能只需兩個小時左右的時間。

4．評估的議程安排

IEEE標準涵蓋了評估中各方面的主題，對於一個被拯救後重啟的專案而言，這些主題可以縮減為下面幾個。

1．總體介紹：包括評估的概述、範圍和目標。

2．之前的評估所確定下來的行動的進展情況彙報。

3．對當前存在的緊急問題的討論。

4．專案現狀及進展情況介紹，包括：

進度

預算

人員配備

開發進展

軟體缺陷

其他相關問題

5．專案管理存在的問題和解決方案，包括風險狀況。

6．決議和批覆。

7．應對的措施（包括行動、執行人以及完成的時間期限）。

5．準備

IEEE軟體評估標準1028既是一個標準，也是一個指南。它包括了評估前的準備（例如應提供合適的場所來舉行評估）、評估計劃（例如日程安排和會議宣傳，分發相關材料等），以及評估執行（例如確立一個評估領導，對評估過程進行記錄等）。

本文節選自《災難拯救——讓軟體專案重回軌道》一書

[美]Bennatan（本拿塔）著

侯豔飛，侯玉芳，李萌譯

圖書詳細資訊:http://space.itpub.net/?uid-13164110-action-viewspace-itemid-734730

定期專案現狀評審