摘 要：文章對現(xiàn)在現(xiàn)有常用的各種軟件開發(fā)模式進行了簡要的分析和對比之后，著重介紹了當前頗為流行的敏捷軟件開發(fā)（Agile software Development）的開發(fā)流程。隨后，對彩信系統(tǒng)的開發(fā)案例的需求進行了簡要的分析，體現(xiàn)了敏捷開發(fā)模式在開發(fā)中小型軟件系統(tǒng)中存在的有效性。

關鍵詞：敏捷模式；持續(xù)集成；TDD

中圖分類號：TP311.52

隨著我國軟件開發(fā)項目的規(guī)模日益擴大，客戶的需求也在不斷變更，軟件交付周期在保證質量的情況下盡可能縮短，在這些因素的影響下，不斷地讓我國傳統(tǒng)的軟件開發(fā)方法的開發(fā)成本不斷的提升，之前傳統(tǒng)的軟件開發(fā)的方法已經(jīng)滿足不了現(xiàn)代軟件開發(fā)的總體需求。

傳統(tǒng)的軟件開發(fā)方法有瀑布模型、螺旋模型、噴泉模型、RUP（Rational UnifiedProcess）四類，它們注重文檔的完整，程序的易讀性，結構的完整性，屬于重型軟件開發(fā)方法，被廣泛的用在公司的軟件開發(fā)中[1]。

為了滿足市場需要以及客戶的需求，解決以上描述中軟件開發(fā)存在的諸多問題，為此，我國軟件開發(fā)業(yè)研發(fā)出了一種新型的軟件開發(fā)方法，這種軟件開發(fā)方法具有快捷、輕便的思維方式，同時還會快速的解決傳統(tǒng)軟件開發(fā)企業(yè)中地下的生產(chǎn)效率，而這一軟件開發(fā)方法也在最短的時間內得到了快速的推廣，我們稱這種新型的軟件開發(fā)方法為敏捷軟件開發(fā)（Agile Development）方法。

所謂的敏捷軟件開發(fā)（Agile Development）方法其實就是以人為核心、重復、循序漸進的新型開發(fā)方法。當我們在敏捷軟件開發(fā)的過程中，我們需要將敏捷軟件項目的構成進行分割，將項目構成分割成多個子項目，接下來，需要對每一個子項目的研究成果進行分別的測試，這種做法的主要目的就是為了讓軟件項目構成的每一個子項目都具備集成和可運行這一特征。換一種說法就是講一個大項目分成為很多個相互連接，同時，他們還可以成為一個獨立運行的小項目，可以完成不同的任務，在這整個過程中，敏捷軟件開發(fā)項目的狀態(tài)是可使用狀態(tài)。我國業(yè)界專家針對企業(yè)目前的狀態(tài)提出了一些可以讓軟件開發(fā)團隊具備快速工作、相應變化能力的價值觀和原則，同時，他們還成立了敏捷聯(lián)盟，是在2001年的剛開始的時候。

1 敏捷開發(fā)流程介紹

測試驅動開發(fā)（Test-Driven Development）在敏捷軟件整個開發(fā)過程中占有非常重要的地位。ThoughtWorks中，不管是哪一個功能，首先需要做的就是對其進行測試。第一，我們需要對業(yè)務的需求進行簡要分析與概括，然后對業(yè)務需求進行分解，之后就會得到了很多Story，然后將所有數(shù)據(jù)都記錄在StoryCard中。之后，兩個工作人員坐在電腦前進行操作，一個從業(yè)務需求的角度編寫測試代碼，而另一個人看著他進行操作，并在那個人進行編寫測試代碼的時候進行思索，假設，那個人才編寫測試代碼的過程中產(chǎn)生了自己獨到的見解，這個人就提出來，兩個人進行商討，當商討的意見相同后，那么，在這種情況下所編寫出來的測試代碼才可以準確無誤的反映出業(yè)務功能需求。接下來就由另一個人對電腦進行控制，編寫測試代碼的實現(xiàn)。假設，我們沒有測試代碼，那么，編寫功能實現(xiàn)代碼就形同虛設。因此，我們首先需要做的就是測試代碼的編寫，讓敏捷開發(fā)人員有一個前進的目標，通過測試。

還沒有敏捷軟件開發(fā)方法之前，傳統(tǒng)的軟件開發(fā)過程中都會存在集成這一個程序，而這個程序是非常領人頭疼的問題，因為軟件集成的時間比較長，而在集成的過程中會出現(xiàn)很多影響因素，例如build未通過或者單元測試失敗。當敏捷軟件開發(fā)方法踢出來后，敏捷軟件開發(fā)中提倡持續(xù)集成（Continuous Integration），持續(xù)集成可以在一天當中集成很多次，這種頻繁的集成方式可以降低沖突，因為集成的頻率比較高，每一次集成所改變的也比較少，所以，集成失敗也就是定位失敗。進行集成需要做到所有的源代碼、運行的單元測試、功能測試和編譯源代碼；當確認編譯和測試沒有通過后，就會將報告發(fā)送出去。我們在進行集成工作的過程中還可以進行其他工作，即代碼分析以及測試覆蓋率等。

重構（Refactoring）是在對軟件系統(tǒng)內部結構進行整理和優(yōu)化，不會改變系統(tǒng)外部的構成，讓代碼可以簡單化。在傳統(tǒng)的軟件開發(fā)的過程中，主要是有需求才來，可是，現(xiàn)在的系統(tǒng)架構不會那么容易實現(xiàn)，因此，我們就需要對原有的軟件系統(tǒng)內部結構進行重構；再者就是還有剩余時間的時候，對代碼進行重構。但是，重構在敏捷軟件開發(fā)的整個過程中。重點：進行重構中，每一次的改變不應太大，用單元測試保證重構不會引起不良，這樣不僅可以實現(xiàn)代碼重構，還會對測試代碼的重復進行重構。

結對編程（Pair-Programming）。在敏捷軟件開發(fā)的過程中，不管是什么事情都是結對的。結對做事存在很大的好處，兩個人在一塊討論會產(chǎn)生意想不到的效果，不會走彎路。

站立會議（Stand up）。在每天上班后項目小組的所有成員先進行站立會議，因為站立會議是成員站立的狀態(tài)下進行的，所以，我建議，站立會議的時間不應太長，盡量控制在15-20之內。站立會議的內容主要有三點，依次是：第一個問題是：你昨天都做了些什么？第二個問題是：你今天需要做什么？第三個問題是：在工作中你都遇到了什么困難？通過這種形式讓每位成員進行交流，相互了解彼此的工作內容。

較少的文檔（Minimal Documentation）。在敏捷軟件開發(fā)中有大量的測試文檔。測試代碼貼切的反映了客戶的需求和系統(tǒng)API的用法，如果項目小組來了位新成員，讓其了解快捷項目的最好辦法就是讓新成員看測試代碼。如果用書面文檔的形式，萬一代碼發(fā)生改變，那么文檔就必須要更新，如果及時更新，就會出現(xiàn)差錯，讓人費解。在敏捷中這種情況就不會出現(xiàn)，因為測試改變，代碼也會隨著改變，測試可以反映代碼的真實情況。

2 日常項目管理

目標：形成團隊成員自發(fā)地回顧、總結、重計劃，發(fā)現(xiàn)問題及時主動閉環(huán)改進，真正形成自組織的團隊。

動作：

（1）發(fā)布計劃會議

輸入：已經(jīng)討論、評審通過的MSL（MASTER STORY LIBRARY）。

劃分迭代：根據(jù)業(yè)界標準敏捷對迭代的劃分方式，結合我們自身情況，決定采用兩周一個迭代。

將MSL中的每一個STORY通過價值、風險進行優(yōu)先級劃分，高價值及高風險>高價值及低風險>低價值低風險>低價值高風險，劃分為高、中、低三種優(yōu)先級，然后再把劃分好優(yōu)先級的STORY大概劃分到每一迭代中，生成整個發(fā)布計劃，其中，仔細考慮劃分在第一迭代的STORY，后續(xù)迭代的STORY可以在迭代計劃會議時調整。

對MSL中的每一個STORY都進行工作量/規(guī)模估計，估計方法采用STORY POINT的DELPHI相對估計法；（相對估計法詳細介紹請看南京敏捷顧問項目第二周回顧）。

（2）迭代計劃會議

重新估計STORY的優(yōu)先級，確認、調整在該迭代中實現(xiàn)的STORY，細化討論每一個在該迭代中實現(xiàn)STORY的實現(xiàn)方案、重新估計工作量；

（3）迭代回顧會議

回顧會議一般是在迭代結束時召開，主要是總結本次迭代有哪些好的實踐可以在后續(xù)迭代中繼續(xù)傳承下去，總結本次迭代有哪些做得不足的地方，可供后續(xù)迭代吸取教訓，要求所有成員全部參加；最后發(fā)現(xiàn)的問題要給出解決措施并讓大家認領，當場確定出跟蹤機制，認領后責任人定期匯報解決進度，最后要形成解決閉環(huán)。

在回顧過程中，為了能夠讓分析過程更有效，要注意聚焦問題根因，先使用20%的解決措施解決80%的問題，其它問題后續(xù)再重新分析解決。

實際上在類似迭代回顧會議等總結、分析行動中，頭腦風暴、5WHY法、因果圖法、柏拉圖等質量方法就展示出威力，為項目分析、解決問題提供了很好的幫助。

參考文獻：

[1]W.B.Arthur.Increasing Return and the New World of Business[J].Harvard Business Review，1996（74）.

[2]張海潘.軟件工程導論（第四版）[M].北京：清華大學出版社，2003：179-192.

作者單位：江蘇商貿職業(yè)學院 藝術與電子信息學院，江蘇南通 226011