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

楊銘 戚華

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

關(guān)鍵詞：軟件產(chǎn)品；質(zhì)量保證；CMMI認(rèn)證；敏捷開發(fā)

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

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

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

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

敏捷開發(fā)的適用項(xiàng)目的選擇條件： ①相對比較成熟的產(chǎn)品團(tuán)隊(duì)；②開發(fā)技術(shù)架構(gòu)穩(wěn)定；③項(xiàng)目人員能力較強(qiáng)；④具備較強(qiáng)的自我學(xué)習(xí)和較高的管理能力；⑤當(dāng)前進(jìn)度要求不緊迫。

1 敏捷模式的建立

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

1.1 需求階段

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

1.2 計(jì)劃階段

項(xiàng)目在啟動階段與其他項(xiàng)目類似，需要制定整個(gè)項(xiàng)目的總體計(jì)劃以及其他附屬計(jì)劃，包括：配置管理計(jì)劃、測量與分析計(jì)劃、質(zhì)量保證計(jì)劃等。需求負(fù)責(zé)人、項(xiàng)目經(jīng)理以及項(xiàng)目團(tuán)隊(duì)?wèi)?yīng)該對項(xiàng)目的風(fēng)險(xiǎn)進(jìn)行管理，并在每次迭代中持續(xù)進(jìn)行風(fēng)險(xiǎn)管理。同時(shí)，項(xiàng)目經(jīng)理需要明確各階段目標(biāo)，并確定大概的時(shí)間范圍。

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

1.3 配置實(shí)施

在配置實(shí)施階段，項(xiàng)目組需要每日對配置成果進(jìn)行檢查，它體現(xiàn)的思想是每天都可以交付新功能，每天都可以展示產(chǎn)品現(xiàn)狀，交付產(chǎn)品價(jià)值，及時(shí)獲取反饋。鼓勵(lì)團(tuán)隊(duì)提交工作成果，幫助團(tuán)隊(duì)及時(shí)收到反饋并修正錯(cuò)誤，持續(xù)、頻繁的集成將集成化風(fēng)險(xiǎn)降到最低點(diǎn)?？梢暬瘜?shí)施類項(xiàng)目直接在用戶環(huán)境中進(jìn)行配置，用戶會持續(xù)對配置的階段成果進(jìn)行驗(yàn)證及確認(rèn)。

1.4 測試階段及用戶反饋

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

1.5 過程跟進(jìn)與總結(jié)階段

因?yàn)槊艚菽Ｊ较旅總€(gè)迭代周期都非常短，因此及時(shí)的溝通顯得尤為重要。除項(xiàng)目組集中辦公外，項(xiàng)目組必須進(jìn)行每日站立會議，在會議上每個(gè)項(xiàng)目組成員都要發(fā)言，以Sprint Backlog為核心，每個(gè)人說三句話，昨天做了什么，今天準(zhǔn)備做什么，有沒有需要協(xié)調(diào)的問題。會議必須在15分鐘內(nèi)結(jié)束，因此在會議過程中只記錄問題，不解決問題。會議不需要有詳細(xì)的會議記錄，但是必須有會議問題的列表及跟蹤情況。

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

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

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

3 具體實(shí)踐及成果

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

參考文獻(xiàn)：

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

機(jī)，2011.12.

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

[3]張敬周.Agile方法研究綜述[J].計(jì)算機(jī)應(yīng)用與軟件，2002.06.