CMMI—4體系下的項目敏捷開發(fā)模式研究

楊銘 戚華

摘 要：通過對CMMI尤其是CMMI-4體系及敏捷開發(fā)模式各自特點的分析，給出符合CMMI-4體系規(guī)范的項目敏捷開發(fā)模式，使之能在保證項目整體可控情況下，更快地響應用戶的需求變化，從而提升用戶滿意度。

關鍵詞：軟件產品；質量保證；CMMI認證；敏捷開發(fā)

本文中涉及的項目類型為可視化實施類項目，此類項目的內容為根據用戶的需求，進行展示場景的設計，并使用公司自主開發(fā)的可視化平臺進行配置實施，其特點為用戶的需求不定且變化非常頻繁，配置實施的成本/效能為線性關系，因此本質上項目組歡迎變化并有能力進行快速響應，因為這并不會帶來額外的成本投入，并可顯著提升用戶滿意度。

敏捷軟件開發(fā)又稱敏捷開發(fā)，是從 1990 年開始逐漸引起廣泛關注的一種新型軟件開發(fā)方法， 是一種應對快速變化的需求的一種軟件開發(fā)能力。敏捷開發(fā)的核心思想是：以人為本，適應變化。

敏捷軟件開發(fā)突出如下四點： ①個體和交互勝過過程與工具；②可以工作的軟件勝過面面俱到的文檔；③客戶合作勝過合同談判；④響應變化勝過遵循計劃。

敏捷過程具有下列五項共通的特性： ①客戶與項目組人員形成密切合作的團隊，共同努力達成項目目標；②項目最終的目標是提交給客戶需要的工作產品， 因此所有的中間產品必須經過審慎評估；③采用增量、迭代方式分階段進行；④過程可以簡單，但規(guī)劃與執(zhí)行必須嚴謹；⑤強調團隊合作，賦予高度的責任，團隊有自主權得以因應變化做調整。

敏捷開發(fā)的適用項目的選擇條件： ①相對比較成熟的產品團隊；②開發(fā)技術架構穩(wěn)定；③項目人員能力較強；④具備較強的自我學習和較高的管理能力；⑤當前進度要求不緊迫。

1 敏捷模式的建立

可視化實施類項目的敏捷研發(fā)模式是參考業(yè)界各種敏捷開發(fā)流程，經過團隊實踐總結出的項目開發(fā)流程及實施模型。該模式通過產品Backlog整理產品需求，并通過迭代Backlog將需求按照迭代次數分解，每個迭代推薦以2周時間為一個Scrum周期，在迭代過程中團隊通過每日站立會議溝通項目進展以及問題，在每個迭代結束時，交付可用的增量產品。該模型引導團隊敏捷迭代、小步快跑，持續(xù)交付有價值的產品。以反饋→需求→迭代→發(fā)布為主線，貫穿整個敏捷開發(fā)生命周期。（表1）

1.1 需求階段

在項目啟動之初，應確定項目的愿景目標，并與用戶達成一致。通過關鍵目標分解和用戶反饋，收集所有需求歸總需求池；PDM從需求池中整理出一份按重要性排序的需求列表。需求列表至少包括場景編號、描述、目標、重要性等。PDM定期維護需求列表（注：“重要性”是對目標、對用戶而言的重要性，不等同于“優(yōu)先級”）。根據項目的實施計劃，由PDM和SM在需求列表的基礎上，分解細化擴充關鍵字段， 把原始需求拆分成最小顆粒度的用戶故事，以方便團隊拆分任務（Task）、估算開發(fā)時間、領取開發(fā)任務，從而規(guī)劃出一份Product Backlog，如：規(guī)模、場景內容、優(yōu)先級等。

1.2 計劃階段

項目在啟動階段與其他項目類似，需要制定整個項目的總體計劃以及其他附屬計劃，包括：配置管理計劃、測量與分析計劃、質量保證計劃等。需求負責人、項目經理以及項目團隊應該對項目的風險進行管理，并在每次迭代中持續(xù)進行風險管理。同時，項目經理需要明確各階段目標，并確定大概的時間范圍。

在每次迭代規(guī)劃會議中，項目經理和團隊成員根據各階段目標，對Product Backlog中的用戶故事進行排序，選取合適的用戶故事進行本輪迭代，并為每一任務分派合適的人員。

1.3 配置實施

在配置實施階段，項目組需要每日對配置成果進行檢查，它體現的思想是每天都可以交付新功能，每天都可以展示產品現狀，交付產品價值，及時獲取反饋。鼓勵團隊提交工作成果，幫助團隊及時收到反饋并修正錯誤，持續(xù)、頻繁的集成將集成化風險降到最低點。可視化實施類項目直接在用戶環(huán)境中進行配置，用戶會持續(xù)對配置的階段成果進行驗證及確認。

1.4 測試階段及用戶反饋

在項目進行過程中，時刻保持用戶的積極參與，能有效地降低項目的風險，避免不必要的理解偏差與變更。因此，項目組在配置實施階段，定期召集用戶方相關人員進行階段成果評審，并持續(xù)跟蹤用戶反饋，由需求負責人整理后，以郵件、Excel等方式轉給項目團隊跟進處理，并把反饋轉為Bug或需求。

1.5 過程跟進與總結階段

因為敏捷模式下每個迭代周期都非常短，因此及時的溝通顯得尤為重要。除項目組集中辦公外，項目組必須進行每日站立會議，在會議上每個項目組成員都要發(fā)言，以Sprint Backlog為核心，每個人說三句話，昨天做了什么，今天準備做什么，有沒有需要協調的問題。會議必須在15分鐘內結束，因此在會議過程中只記錄問題，不解決問題。會議不需要有詳細的會議記錄，但是必須有會議問題的列表及跟蹤情況。

在每個Scrum周期結束后，需要有正式的迭代回顧會議，在會議上對本次迭代的數據進行分析，Review本次迭代過程中的所有障礙和問題及上個迭代針對過程改進措施的改進效果，對下個迭代中重點改進的問題及解決方案進行討論。

2 敏捷模式與CMMI-4活動的對照

如表2所示，分析了一個迭代周期內主要項目活動與CMMI過程域的對照關系，可以看出，敏捷開發(fā)模式與傳統的軟件開發(fā)模型并無本質區(qū)別，也同樣經歷有需求設計實現測試的環(huán)節(jié)；而CMMI-4著重于對項目進行量化管理，而因為敏捷開發(fā)在工作量評估上采用故事點估算，且在迭代過程中使用燃盡圖進行進度控制，因此敏捷模式與CMMI-4具有天然的親和性。

3 具體實踐及成果

在剛開始對可視化實施類項目進行規(guī)范管理時，因為使用的是適用于軟件開發(fā)的瀑布模型，因此對項目進行中發(fā)生的變更應對不及時，項目過程中或多或少地存在著實際項目工作與流程不符的情況，有效的項目管控工作很難開展；尤其是在公司推行CMMI-4體系管理后，因為各項目執(zhí)行階段的無序性，導致很難收集到準確的度量數據，對建立準確的量化模型及實施量化管理帶來了很大的難度。在嘗試建立敏捷開發(fā)模式并采用其進行項目實施后，因強調“持續(xù)構建，階段交付”，用戶可以隨時看到最新的工作成果。

參考文獻：

[1]徐俊，彭章綱.敏捷開發(fā)過程與CMMI實施融合研究[J].現代計算

機，2011.12.

[2]James Shore， Shane Warden.敏捷開發(fā)的藝術[M].機械工業(yè)出版社，2009.

[3]張敬周.Agile方法研究綜述[J].計算機應用與軟件，2002.06.