專案管理

您可以利用 MSF for CMMI Process Improvement 指引的 [專案管理] 區段，更加充分了解如何管理、規劃及協調軟體產品的開發與維護。如需 CMMI 的詳細資訊，請參閱 CMMI 的背景。

CMMI 中流程區域的 [專案管理] 群組包含 [專案規劃]、[專案監控]、[供應商合約管理]、[整合式專案管理]、[風險管理] 和 [量化專案管理]。除了 [量化專案管理] 以外，所有群組都屬於模型層級 2 或 3。[量化專案管理] 是模型層級 4 活動，可反映出高度成熟的組織如何使用量化、統計防禦、客觀資料來進行管理決策，並引導專案朝向成功且可預期的結果。

專案管理活動表示加值型工程活動的經濟成本。對於管理風險、協調成功的工程作業，以及適當地設定客戶預期值而言，這些活動很重要且不可或缺。不過，您應該將投注於這些活動上的付出降至最低。「少而頻繁」是個好原則。較小的批次作業方式可減少複雜度和協調成本。在定義及修改流程定義時，您應該記住專案管理活動應盡可能簡化，但又要滿足專案的風險概況。

反覆開發

Team Foundation 搭配 MSF for CMMI 流程範本即可支援反覆工作。反覆開發作業藉著在整個專案期間定期提供可以實際展示且經過測試的軟體之方式來管理風險。

專案排程會組織成一系列的反覆項目，通常為期四到六週的時間。每一個反覆項目都是以示範可使用且經過測試的軟體作為結尾。如需詳細資訊，請參閱建立和修改區域和反覆項目。

• 「專案計劃」(Project Plan) 會陳述要在每一個反覆項目中開發的功能需求。專案計劃會在反覆項目 0 中進行開發，而在每一個反覆項目的開頭時檢閱。檢視專案計劃的方法有很多種，例如透過 [專案儀表板]。如需詳細資訊，請參閱需求 (CMMI)和專案儀表板 (CMMI)。

• 每一個「反覆項目計劃」(Iteration Plan) 會陳述要在該反覆項目期間執行的工作。大部分工作是滿足針對該反覆項目排程之功能需求所需的開發和測試工作。您可以透過 [進度儀表板] 檢視反覆項目計劃。如需詳細資訊，請參閱工作 (CMMI)和進度儀表板 (CMMI)。

反覆工作不會自動管理風險。若要使風險降至最低，您必須逐步安排專案計劃。早期的反覆項目應提供「端對端的最簡功能」，也就是，該產品大部分重要行為的最小版本。之後的反覆項目會加入更多功能。

相比之下，若在專案的前期排程購物網站的所有銷售部分，在中期排程所有倉儲系統，並在後期排程所有付款系統，則是比較不實用的作法。此種排程會產生引人注目且功能豐富的銷售網站，但卻無法讓企業從客戶身上獲利，所以會有風險。此種方式雖是循環的但卻沒有累加的效果。

累加開發有下列好處：

• 符合真實的需求。專案關係人有機會試驗產品，而這麼做一定能夠改善其所陳述的需求。

• 微調架構。讓開發小組能夠發現並處理其平台所遇到的任何難題，以及其設計上的可能改善之處。

• 確定結果。專案關係人曉得，即使專案資源中途遭到刪減，而累計至今的支付也並未浪費掉。如果證實開發前評估過於樂觀，而您必須放棄比較不重要的功能時也有同樣效果。

如需如何以適當格式表達累加開發需求的詳細資訊，請參閱開發需求。

較大和較小的週期

專案與反覆項目並非軟體開發的唯一週期性部分。例如，在反覆項目中，小組成員會開始及完成作業並簽入程式碼。建置系統會以連續方式或是在夜間建置產品。小組會對反覆項目工作進度進行簡短的每日檢討。

大型專案

小組透過一系列反覆項目來作業的專案有可能屬於較大型的專案或方案。大型專案會有好幾個小組平行作業。每個小組通常有 4 到 16 人。

為每一個小組開啟個別的版本控制分支。每一個小組應在每一個反覆項目結束時與主要分支整合。如需詳細資訊，請參閱使用分支隔離風險。

保留主要分支以便進行整合和測試。組建電腦應在整合之後執行一組完整的測試。

指派區域給每一個小組，以便輕易區分其工作項目與其他小組的工作項目。如需詳細資訊，請參閱建立和修改區域和反覆項目。

小組可以共用一系列的整合作業，但不見得一定要這麼做。如果小組並未同步處理整合作業，則每一個小組必須有自己專屬的反覆項目名稱前置詞。

本章節內容

專案週期：開始進行專案、蒐集需求、建立專案計劃、將專案分割成反覆項目，以及交付各個版本。管理風險，以及管理計劃的變更。	專案活動
反覆項目週期：檢閱和更新需求、規劃要實作需求的工作，以及管理所發生的問題。	反覆項目活動

請參閱

概念

適用於 Visual Studio ALM 的 CMMI 流程範本