敏捷開發(fā)模式的研究及案例需求分析

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

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

中圖分類號(hào)：TP311.52

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

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

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

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

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

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

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

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

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

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

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

2 日常項(xiàng)目管理

目標(biāo)：形成團(tuán)隊(duì)成員自發(fā)地回顧、總結(jié)、重計(jì)劃，發(fā)現(xiàn)問題及時(shí)主動(dòng)閉環(huán)改進(jìn)，真正形成自組織的團(tuán)隊(duì)。

動(dòng)作：

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

輸入：已經(jīng)討論、評(píng)審?fù)ㄟ^的MSL（MASTER STORY LIBRARY）。

劃分迭代：根據(jù)業(yè)界標(biāo)準(zhǔn)敏捷對(duì)迭代的劃分方式，結(jié)合我們自身情況，決定采用兩周一個(gè)迭代。

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

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

（2）迭代計(jì)劃會(huì)議

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

（3）迭代回顧會(huì)議

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

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

實(shí)際上在類似迭代回顧會(huì)議等總結(jié)、分析行動(dòng)中，頭腦風(fēng)暴、5WHY法、因果圖法、柏拉圖等質(zhì)量方法就展示出威力，為項(xiàng)目分析、解決問題提供了很好的幫助。

參考文獻(xiàn)：

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

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

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