敏捷方法在小型軟件企業(yè)軟件過程改進(jìn)中的實踐

張安勤　田秀霞　彭源

摘 要：CMM/CMMI是國際上主要采用的軟件過程改進(jìn)模型，但這些模型主要來源于大型軟件企業(yè)的軟件過程經(jīng)驗，在小型企業(yè)中實施起來存在一定困難。敏捷方法是一種“輕量型”的軟件開發(fā)方法。在敏捷方法開發(fā)過程中圍繞用戶的需求，采用迭代的方法進(jìn)行開發(fā)。本文結(jié)合一個小型企業(yè)的軟件過程改進(jìn)實踐，采用敏捷開發(fā)方法和CMM/CMMI相結(jié)合的思路，經(jīng)過兩年在上海某小型軟件企業(yè)的改革和實踐，探索到了適合小型軟件企業(yè)軟件過程改進(jìn)的方法和模型。

關(guān)鍵詞：小規(guī)模軟件企業(yè)；敏捷方法；迭代方法；軟件過程改進(jìn)

中圖分類號：TP311.5-4 文獻(xiàn)標(biāo)識碼：A

1 引言（Introduction）

能力成熟度模型CMM（Capability Maturity Model）及能力成熟度模型集成CMMI（Capability Maturity Model Integration）是國際上采用的軟件過程改進(jìn)模型，是被廣泛應(yīng)用于現(xiàn)代軟件企業(yè)的過程改進(jìn)和評估中的主要模型。目前，在實施軟件過程改進(jìn)的軟件企業(yè)中，超過一半的企業(yè)采用了CMMI作為過程改進(jìn)的指導(dǎo)模型。但是，CMM/CMMI的主要是根據(jù)大型軟件企業(yè)的開發(fā)經(jīng)驗提出的，而我國軟件企業(yè)中大多數(shù)是中小型企業(yè)。CMMI過于龐大和復(fù)雜，對于這些小型企業(yè)來說，實施起來存在諸多困難。

為了使開發(fā)團(tuán)隊具有高效工作和快速相應(yīng)變化的能力，17位著名的軟件專家提出了敏捷方法（Agile Method）。敏捷方法的主要強(qiáng)調(diào)：優(yōu)秀的團(tuán)隊成員是項目獲得成功的重要因素，可以工作的軟件勝過面面俱到的文檔，與客戶的合作勝過與客戶的談判，相應(yīng)變化勝過遵循計劃。

敏捷方法是一系列“輕量型”的軟件開發(fā)方法，是以快捷、輕便的思維方式面對各種變化的新軟件工程思想的統(tǒng)稱。

極限編程（eXtreme Programming，XP）是敏捷過程中最負(fù)盛名的一個，其名稱“極限”二字的含義是指把好的開發(fā)實踐運用到極致。極限編程有許多有效開發(fā)實踐，這些實踐都是前人經(jīng)驗的總結(jié)，我們選擇了方便實現(xiàn)的客戶參與、代碼規(guī)范、代碼集體所有等進(jìn)行了嘗試，在項目的開發(fā)中取得了較好的效果。

本人產(chǎn)學(xué)研所在的上海A公司是一個具有30多人的軟件公司，之所以選擇這樣規(guī)模的公司，是因為這樣的公司在國內(nèi)具有代表性。而且現(xiàn)在鼓勵學(xué)生自主創(chuàng)業(yè)，如何在學(xué)生創(chuàng)業(yè)初期給予一定的指導(dǎo)，并給出一些指導(dǎo)模型尤為重要。本文結(jié)合A公司的軟件過程改進(jìn)實踐提出了一種結(jié)合敏捷方法的小型軟件企業(yè)的軟件過程改進(jìn)的模型，在項目的開發(fā)的實際過程中取得了不錯的效果，能給同類的企業(yè)提供一定的借鑒。

2 小規(guī)模企業(yè)軟件過程管理現(xiàn)狀（The present

situation of small scale enterprise software

process management）

2.1 小規(guī)模軟件企業(yè)的特點[1]

我國的軟件企業(yè)以中小企業(yè)為主，大多數(shù)是50人以下的小企業(yè)，這些小企業(yè)具有以下一些特點：

（1）員工的年齡比較年輕，但是卻沒有相應(yīng)的培訓(xùn)計劃。企業(yè)的領(lǐng)導(dǎo)認(rèn)為員工的培訓(xùn)是一種浪費時間與金錢、沒有回報的付出。

（2）小型軟件企業(yè)員工用戶需求變更頻繁，人員流動大。

（3）小型軟件企業(yè)的經(jīng)營者缺乏有效的管理手段，業(yè)務(wù)負(fù)責(zé)人大多是計算機(jī)、軟件和其他的相關(guān)專業(yè)，極少是管理專業(yè)，表現(xiàn)出人員的管理混亂，難以準(zhǔn)確地掌握并控制產(chǎn)品及項目的開發(fā)成本。

2.2 小規(guī)模軟件企業(yè)應(yīng)對策略[2]

由于小型軟件企業(yè)存在以上一些特點，導(dǎo)致了這些軟件開發(fā)企業(yè)經(jīng)常會遇到任務(wù)完成進(jìn)度難以控制、項目延期，疲于應(yīng)付需求的變更、軟件版本混亂、軟件質(zhì)量難以保證、沒有有效的項目管理方法和實踐指導(dǎo)等問題，從而使得客戶滿意度降低。針對這些管理和與技術(shù)方面的問題，許多小型軟件開發(fā)企業(yè)已開始在軟件過程管理、軟件過程改進(jìn)方面采取一系列措施和手段。

3 敏捷方法使用中存在的誤區(qū)（The misunderstanding

in the use of agile method）[3]

（1）敏捷方法沒有文檔，也不做設(shè)計

敏捷方法并不是所有的文檔都不寫，敏捷方法奉行的是“必要且意義重大的文檔”才寫。

敏捷遵循的是持續(xù)設(shè)計，并不是不設(shè)計。這實際上是將設(shè)計工作分到了每天的日常工作中，不斷的設(shè)計、改善。敏捷方法不是不設(shè)計，而是更重視設(shè)計。

（2）敏捷好，其他方法不好

似乎敏捷和其他方法是完全對立的。事實上敏捷方法也吸取了其他方法論的優(yōu)點，敏捷依然保持了很多歷史悠久的實踐和原則。

（3）敏捷就是XP，就是Scrum

XP和Scrum只是眾多敏捷方法中的兩種，還有很多其他的敏捷方法。

即使將XP或Scrum完全的應(yīng)用到項目中，也不一定就能成功，適合別的項目的方法未必就適合所有的項目。最適合的方式還要在實際工作中探索和尋找。

4 軟件過程改進(jìn)模型（Software process

improvement model）

在上海A公司的軟件開發(fā)過程中，筆者所在的軟件開發(fā)團(tuán)隊借鑒了RUP中的迭代式開發(fā)和敏捷方法中若干有效的實踐方法，提出了一個結(jié)合敏捷方法的迭代的軟件過程改進(jìn)模型。具體措施如圖1所示。

圖1 基于敏捷方法的迭代的軟件過程改進(jìn)模型

Fig.1 The improved iterative software process model

based on agile method

4.1 重點突破[2]

軟件過程改進(jìn)是要在一定程度上改變軟件企業(yè)現(xiàn)有的軟件開發(fā)和管理過程，對于已經(jīng)習(xí)慣了企業(yè)現(xiàn)有的工作方式的員工來說，大規(guī)模的改動不太容易被接受，也很難取得相應(yīng)的效果。因此應(yīng)該從企業(yè)當(dāng)前存在問題的地方開始，重點突破。

軟件開發(fā)過程中的需求、設(shè)計、編碼等階段，主要依賴于企業(yè)的技術(shù)實力和開發(fā)人員的能力，對于項目計劃、軟件測試、配置和質(zhì)量保證則依賴于軟件過程的改進(jìn)和管理。

因此本文結(jié)合A軟件公司的特點以項目計劃、軟件評審和測試、配置和質(zhì)量保證幾個方面作為軟件過程改進(jìn)的重點突破點。

（1）項目計劃

項目計劃是項目成功的前提，大部分項目的失敗的原因都是不合理的計劃或者計劃執(zhí)行不到位。

項目計劃應(yīng)從以下幾方面進(jìn)行：

①應(yīng)對項目進(jìn)行準(zhǔn)確的項目估算。參考?xì)v史數(shù)據(jù)庫中的規(guī)模數(shù)據(jù)或者估算者所能做的最好猜測，估算待開發(fā)產(chǎn)品的規(guī)模。

②資源估算，這里主要是指人力資源，主要單位是人月、人天或者是人時。由于軟件工程師每個月能夠提供的有效資源有很大差異，人月會帶來額外的不確定性，因此建議使用人天和人時這樣的單位來描述項目的人力資源需求。而且在項目執(zhí)行時項目任務(wù)要充分并行，以提高人力資源的利用率。

③計劃安排不能過于樂觀，應(yīng)留有一定余地，避免項目延期的情況。

④合理評估項目計劃的變更，充分考慮到所有可能會受到影響的因素。

（2）軟件評審和測試

為了盡可能地消除軟件產(chǎn)品中的缺陷，在我們的軟件過程改進(jìn)模型中，采取了評審和測試兩種方法來發(fā)現(xiàn)和消除缺陷。

本模型的軟件評審和測試改進(jìn)主要體現(xiàn)在以下方面：

①由于缺陷在開發(fā)過程中停留的越久，消除它的代價就越高，因此應(yīng)盡早地消除缺陷。

②在軟件測試計劃中，引入個人評審和小組評審，有經(jīng)驗的評審者可以在產(chǎn)品進(jìn)入測試之前發(fā)現(xiàn)，并消除80%左右的缺陷，這樣大大提高了測試消除缺陷的效率。

本模型以測試驅(qū)動開發(fā)，并引入評審機(jī)制，評審和測試工作貫穿于整個軟件開發(fā)過程。

（3）配置管理

配置管理的目的是建立和維護(hù)工作產(chǎn)品的完整性。本模型的配置管理措施如下：

①選擇合適的配置管理軟件。

②對軟件版本進(jìn)行統(tǒng)一管理。

③規(guī)范配置項變更控制流程，使整個開發(fā)和管理過程可以被追溯。

（4）質(zhì)量管理

在小型軟件企業(yè)中過于復(fù)雜的質(zhì)量管理措施，往往不具有實用性，因此結(jié)合A公司的實際情況，本模型中采用了用缺陷管理代替質(zhì)量管理，這樣大大簡化了質(zhì)量管理的方法，使得質(zhì)量管理更加易于操作。在質(zhì)量管理過程中，以測試為驅(qū)動，結(jié)合軟件評審方法，可以顯著減少缺陷消除代價；而且質(zhì)量人員就可以由評審和測試人員擔(dān)任，能夠減少人力成本。

4.2 個體軟件過程改進(jìn)[4]

開發(fā)人員的技術(shù)水平和個人能力對軟件的質(zhì)量起著決定性的作用。合格的軟件工程師，應(yīng)該自己度量、跟蹤和管理自己的工作，應(yīng)該自己管理軟件的質(zhì)量，應(yīng)該從自己開發(fā)過程的偏差中學(xué)習(xí)總結(jié)，建立持續(xù)的自我改進(jìn)機(jī)制。

個體軟件過程改進(jìn)的具體措施可以從時間管理、缺陷管理、規(guī)模度量和計劃管理等幾個方面著手，并以任務(wù)檢查單作為輔助工具。

①對于時間管理，我們要求軟件工程師先確定純工作時間，再確定日程上需要多少天（周）可以提供這么多的純工作時間。通過時間日志，個體軟件工程師可以了解時間的消耗情況，了解自己的有效工作時間狀態(tài)，從而更加有效地確定開發(fā)日程。

②缺陷管理要求工程師使用缺陷日志對各個階段發(fā)現(xiàn)的缺陷進(jìn)行記錄。這些記錄的缺陷信息可以很方便地統(tǒng)計出缺陷在整個開發(fā)階段被引入和消除的狀況，從而為提升過程質(zhì)量、更加有效地消除缺陷提供了參考。

③規(guī)模度量方面我們采用了代碼行作為度量的主要方式，并輔以功能點度量方式，從實際度量的效果來看，代碼行這種規(guī)模度量方式可以更好地反映實際開發(fā)成本。

④任務(wù)檢查單可以與計劃管理和缺陷管理搭配使用，有利于個人工作任務(wù)的管理。

圖2 PSP的訓(xùn)練框圖

Fig.2 The train diagram of PSP

4.3 TSP與敏捷開發(fā)方法的結(jié)合[5]

軟件開發(fā)在絕大多數(shù)情況下是團(tuán)隊作戰(zhàn)，團(tuán)隊的有效性決定了產(chǎn)品的質(zhì)量。TSP團(tuán)隊在軟件項目開發(fā)過程中可運用。在A公司的軟件開發(fā)實踐中，我們結(jié)合了XP、RUP等敏捷方法，提高了軟件開發(fā)的效率和質(zhì)量，形成了有自己風(fēng)格的軟件開發(fā)過程模型。

（1）客戶作為開發(fā)團(tuán)隊的成員

必須至少有一名客戶代表在項目的整個開發(fā)周期中與開發(fā)人員一起緊密地配合工作，客戶代表負(fù)責(zé)確定需求、回答開發(fā)人員的問題并且設(shè)計功能驗收測試方案。

（2）每日站立會議

通過每天舉行一次的“站立會議”，解決遇到的問題、調(diào)整迭代計劃。在每天的會議中主要關(guān)注三個問題：昨天完成了什么，今天需要做什么，有什么困難。這種方法每天所花時間一般只有15分鐘，但是效果非常好。既能促進(jìn)項目組成員了解彼此的進(jìn)展，獲得項目的真實情況、增強(qiáng)團(tuán)隊的凝聚力、又能培養(yǎng)團(tuán)隊的文化。

（3）編碼規(guī)范

開發(fā)團(tuán)隊結(jié)合以前的工作，并參考一些公開的編碼規(guī)范，經(jīng)過多次討論和征求意見，制訂了符合團(tuán)隊習(xí)慣的編碼規(guī)范。這種方法可以很好地增強(qiáng)程序的可讀性以及改善遺留系統(tǒng)可修改性。

（4）代碼集體所有

程序代碼屬于整個開發(fā)小組集體所有，小組的每個成員都有更改代碼的權(quán)利，每個成員都對全部代碼的質(zhì)量負(fù)責(zé)。在具體實踐過程中，必須對代碼更改的情況進(jìn)行記錄，包括修改人，修改時間，修改部分的修改前后的代碼。因為小型軟件企業(yè)的項目規(guī)模一般不大，開發(fā)團(tuán)隊人員較少，每個開發(fā)人員都要承擔(dān)多種不同任務(wù)，實施“代碼集體所有”并輔以“編碼規(guī)范”，互相配合，修改代碼會變得比較容易，項目的人員調(diào)配也比較靈活。

4.4 有效地評價機(jī)制

為了檢驗?zāi)Ｐ偷男Ч卦O(shè)置了一個評分規(guī)則[1]，列出一系列評分指標(biāo)及權(quán)重，并通過若干位小軟件企業(yè)項目管理負(fù)責(zé)人和若干位專家進(jìn)行評價。列出6個評分指標(biāo)，每個指標(biāo)的滿分指為10分，這些指標(biāo)如表1所示。

表1 評價指標(biāo)表

Tab.1 The evaluation index table

評價指標(biāo) 不及格（6分以下） 及格（6-7分） 良好（7-9分） 優(yōu)秀（9-10分）

是否符合軟件規(guī)格說明

是否完成客戶提出的要求

是否易于軟件工程師理解、使用和接受

每個過程是否能取得明確的結(jié)果以及是否對外可見

是否會出現(xiàn)過程錯誤

是否易受外界問題的影響

5 結(jié)論（Conclusion）

軟件過程改進(jìn)是一個循序漸進(jìn)的過程，軟件企業(yè)需要在不斷的積累中持續(xù)改進(jìn)。本文在A公司的過程改進(jìn)實踐基礎(chǔ)之上定義了一個基于敏捷方法的迭代式的軟件過程改進(jìn)模型。A公司在實踐這一模型時取得了如下的成效：

（1）項目組建立了規(guī)范的研發(fā)過程，使得項目開發(fā)有了可參照的過程標(biāo)準(zhǔn)[6]。

（2）能夠比較準(zhǔn)確地估算項目，在此基礎(chǔ)上所做的項目計劃比較合理，項目延期的情況有了較好地改善。

（3）以測試驅(qū)動開發(fā)，并引入評審機(jī)制，評審和測試工作貫穿于整個軟件開發(fā)程，大大提高了軟件的質(zhì)量，受到了客戶的好評。

（4）項目組成員養(yǎng)成了良好的配置管理習(xí)慣，使得軟件版本混亂和難以查找的問題得到了很好的改善。

（5）充分重視新進(jìn)員工的培訓(xùn)，在開發(fā)過程中嚴(yán)格進(jìn)行規(guī)范的個體軟件過程改進(jìn)。

（6）項目開發(fā)中結(jié)合了XP、RUP等敏捷方法，提高了軟件開發(fā)的效率和質(zhì)量。

本人“產(chǎn)學(xué)研”項目所在的上海A公司是典型的小型軟件企業(yè)，在該公司的軟件開發(fā)和改進(jìn)中提出的方法和過程可以供其他小型軟件企業(yè)進(jìn)行過程改進(jìn)借鑒和參考。

參考文獻(xiàn)（References）

[1] 馬小龍.一種中小型軟件企業(yè)軟件過程改進(jìn)框架研究[J].電腦

與電信，2010（10）：38-39.

[2] 楚書來，于文新.小規(guī)模軟件企業(yè)軟件過程管理與改進(jìn)策略研

究[J].黑龍江科技信息，2012（2）：199-200.

[3] 對敏捷開發(fā)的五大誤解.http：//www.searchsoa.com.cn/

showcontent_24633.htm.

[4] 徐玲，等.高校軟件開發(fā)項目中的軟件過程改進(jìn)[J].計算機(jī)教

育，2012（24）：77-81.

[5] 隋立江.敏捷方法在軟件開發(fā)過程中的實踐[J].航空制造技

術(shù)，2011（10）：64-67.

[6] 田麗從，李鐵牛，彭宏.中小型企業(yè)軟件過程改進(jìn)方法研究[J].

計算機(jī)應(yīng)用與軟件，2011（4）：208-211.

作者簡介：

張安勤（1974-），女，博士生，副教授.研究領(lǐng)域：軟件工程.

田秀霞（1976-），女，博士，教授.研究領(lǐng)域：信息安全.

彭 源（1981-），女，博士，副教授.研究領(lǐng)域：圖像處理.