?

多元化時代敏捷軟件開發(fā)的崛起與傳統(tǒng)軟件工程的延續(xù)

?

1.傳統(tǒng)軟件開發(fā)模式

? 1.1瀑布模型

? ? 1.1.1概念

? ? ? 瀑布模型，顧名思義，軟件開發(fā)的過程如同瀑布飛流一般，自上而下，逐級下落。瀑布模型的核心思想是將問題按照工序進行簡化，將軟件結(jié)構(gòu)的設(shè)計與軟件功能的實現(xiàn)分隔開來，同時運用結(jié)構(gòu)化的分析與設(shè)計方法，將軟件的物理基礎(chǔ)與邏輯實現(xiàn)也分隔開來。瀑布模型將軟件開發(fā)周期按照順序線性地分為了六個基本活動階段，分別為制定計劃階段、需求分析階段、軟件設(shè)計階段、程序編寫階段、軟件測試階段以及運行維護階段。這六個階段線性排列，相互銜接，具有嚴格的執(zhí)行順序。瀑布模型的提出很大程度上體現(xiàn)了流程化的設(shè)計思想，便于進行分工與協(xié)作。

? ? 1.1.2優(yōu)點

? ? ? 瀑布模型正是由于其嚴格的階段化流程，因而在流程設(shè)計上具有十分明顯的優(yōu)勢。該模型使得項目本身就可具備了天然的檢查點，階段的劃分為軟件開發(fā)者提供了定時檢查的可能，是較強的標準化措施。而對于軟件開發(fā)者來說，每一階段的完成既象征著下一階段的開始，也意味著上一階段的完結(jié)，因而能夠讓開發(fā)人員集中更多的精力于后續(xù)的開發(fā)，而不再考慮之前的設(shè)計，大大提高了開發(fā)的效率，也提高了項目本身的標準化程度。

? ? 1.1.3缺陷

? ? ? 由于瀑布模型基于了嚴格的階段設(shè)計，而不同的階段的執(zhí)行順序也是線性的，雖然對于軟件開發(fā)人員來說規(guī)定好了開發(fā)的路線，也為不同的階段劃定了嚴格的界限。然而也正是這種界限，使得項目開發(fā)的各個階段之間缺乏必要的交流與探討，也沒有相關(guān)的情況反饋，因而對項目的完整性和交互性沒有很好地約束。另外，順序化的執(zhí)行方式意味著我們只能在項目生命周期的后期才能看到軟件開發(fā)的初步結(jié)果，使得留給后續(xù)測試反饋等工作的時間過少，某些意義上拖長了整個產(chǎn)品的生命周期。除此之外，為了嚴格按照既定時間完成各階段的內(nèi)容，常常要求我們用一些強制性的措施來跟蹤項目的發(fā)展過程，從而保證項目進度的正常，這就意味著整個項目開發(fā)的過程過于死板，難以變通，不具備良好的反應(yīng)能力，更不適應(yīng)用戶的需求變化。

? 1.2迭代模型

? ? 1.2.1概念

? ? ? 迭代開發(fā)是一個大規(guī)模的迭代過程，它將整個項目分解成了若干個小項目，而每一個小項目在一定程度上也可以再繼續(xù)劃分成更小的項目，而對于每一個這樣的劃分出來的小項目，我們都可以基于瀑布模型對其進行完整的一輪開發(fā)，在很短的周期內(nèi)產(chǎn)生一個可發(fā)布的產(chǎn)品，而這個產(chǎn)品則是最終產(chǎn)品的一個子集。迭代開發(fā)由若干個這樣的過程組成，類似于小型瀑布開發(fā)項目的集合。迭代開發(fā)適用于早期需求不斷變化的項目，并且要求分析設(shè)計人員對項目所設(shè)計的領(lǐng)域具有相當高的熟悉程度。總而言之，對于那些風險度較高，用戶參與程度較高，同時要用到面向?qū)ο蠼５捻椖?#xff0c;只要軟件開發(fā)團隊中具有高素質(zhì)的管理者，開發(fā)人員之間協(xié)作模式良好，那么迭代開發(fā)模型將是很好地開發(fā)方式。

? ? 1.2.2優(yōu)點

? ? ? 由于將整個大項目變成了若干個小項目的迭代和，因而迭代模型很大程度上降低了項目開發(fā)過程中在一個增量上的開支風險，倘若開發(fā)人員在某一迭代上出現(xiàn)了問題，也只會在此個迭代上進行風險的評估，對于其他迭代的影響不大。另外該模式降低了產(chǎn)品無法按照既定進度進駐市場的風險，因為在迭代的早期我們就可以預估出開發(fā)過程中面臨的風險，從而提早作出規(guī)劃，避免了開發(fā)過程中遇見風險后的手忙腳亂導致的一系列難以預料的問題。迭代風險通過不斷的迭代加快了開發(fā)人員的開發(fā)效率，因為在迭代的過程中會有一個不動點，開發(fā)人員只要把握準這個不動點，就可以確定問題的焦點所在，從而進行高效率的開發(fā)，加快項目工作的進度。而相對于單純的瀑布模型，迭代模型對于用戶的需求更改則顯得更為適應(yīng)，在這種模型下，用戶的需求在開發(fā)前期并不十分明確，并且常常隨著開發(fā)過程的進行在不斷變化，迭代的過程也正是對新需求的適應(yīng)過程，完美的解決了用戶需求的更改與產(chǎn)品開發(fā)之間的沖突問題。

? ? 1.2.3缺陷

? ? ? 迭代開發(fā)由于要進行不斷的迭代來完善產(chǎn)品，以適應(yīng)用戶的需求變化，因而如果用戶的需求相對較為固定，如果仍然采用邊寫邊重構(gòu)的方式進行開發(fā)，無疑會增加很多無謂的重復工作。加之在迭代前期對產(chǎn)品的形態(tài)缺乏最終概念的時候，如果對于迭代的方向把握不準確則很容易偏離最初的意圖，造成不必要的損失，因而迭代開發(fā)模式更加要求開發(fā)人員的設(shè)計水平以及全局觀念，更需要一個較強的架構(gòu)師進行架構(gòu)管理，這也是迭代開發(fā)的一個難以普及的難點。

? 1.3其他模型

? ? 1.3.1快速原型模型

? ? ? 快速原型模型是在開發(fā)真實系統(tǒng)之前先構(gòu)造一個系統(tǒng)原型，并在該原型的基礎(chǔ)上進一步地逐漸進行整個系統(tǒng)的全面開發(fā)工作。開發(fā)原型的過程事實上也是與用戶進行交互的過程，獲取用戶對原型的評價，從而在后續(xù)的開發(fā)過程中根據(jù)評價有針對性的對系統(tǒng)作出調(diào)整和修改，使其一步一步滿足用戶的需求。該模型克服了瀑布模型的缺點，減少了由于軟件需求的不明確而帶來的開發(fā)風險，但與此同時快速建立的系統(tǒng)模型結(jié)構(gòu)以及重復多次的連續(xù)修改會使得產(chǎn)品的質(zhì)量相對較低，并且限制了開發(fā)人員開發(fā)項目的創(chuàng)新性。

? ? 1.3.2螺旋模型

? ? ? 螺旋模型以前面幾個模型為基礎(chǔ)，基于一個快速形成的模型，以進化的開發(fā)方式為中心，定義了四個項目階段，并且在每個階段周期都采用迭代開發(fā)的方法，使得軟件開發(fā)路徑沿著螺旋線迭代前進，從而帶來了層次的不斷遞進。螺旋開發(fā)強調(diào)了風險的分析，它要求每個開發(fā)人員都要了解每一個層次可能出現(xiàn)的風險，并且及時對風險進行分析，采取相應(yīng)的措施，減少風險帶來的損害。螺旋模型很好的解決了開發(fā)高風險系統(tǒng)的軟件開發(fā)過程的實現(xiàn)。

2.敏捷軟件開發(fā)模式

? 2.1何為敏捷開發(fā)

? ? ? 所謂敏捷開發(fā)，自然是相對于“非敏捷開發(fā)”而言的。而相比“非敏捷開發(fā)”，敏捷開發(fā)最重要的就是程序員團隊與業(yè)務(wù)專家之間的緊密合作、團隊成員之間的面對面的溝通交流以及頻繁的軟件版本的交付。而這樣的軟件開發(fā)方式極大地適應(yīng)了當前社會情形下用戶需求不斷更改的特點，敏捷開發(fā)可以對用戶的新要求迅速作出反應(yīng)，適合小規(guī)模團隊開發(fā)軟件使用，更凸顯了每個“人”在軟件開發(fā)周期中的作用。

? 2.2敏捷開發(fā)的特點

? ? ? 在敏捷聯(lián)盟的官方網(wǎng)站上，我們可以看到這樣的四句宣言：個人與溝通勝過過程與工具；可工作的軟件勝過面面俱到的文檔；客戶協(xié)作勝過合同談判；相應(yīng)變化勝過遵循計劃。這四句話完美的概括了敏捷開發(fā)的四個特點，體現(xiàn)了使開發(fā)團隊快速工作并具有應(yīng)變能力的價值觀和原則。敏捷開發(fā)看重團體中每個“人”的作用，強調(diào)每個開發(fā)人員相互之間的溝通與協(xié)作，開發(fā)過程和開發(fā)工具在“人”的面前就要稍低一等。而這個“人”也不僅僅指的是開發(fā)人員，還包括了需要服務(wù)的客戶，核心思想就是以本設(shè)計團體為中心，和外界各類人員進行配合。敏捷開發(fā)重視的是實際產(chǎn)品的開發(fā)與交付，一個能實際工作的軟件遠遠要好于求全責備的各種文檔。另外敏捷開發(fā)注重交互，尤其是與用戶之間的交互，開發(fā)人員根據(jù)用戶的需求的變化，不斷調(diào)整軟件的功能為用戶提供不同版本的可運行的軟件。

? 2.3開發(fā)原則

? ? ? 敏捷開發(fā)事實上是基于用戶需求的一種開發(fā)方法，因而開發(fā)的深度應(yīng)當隨用戶的需求的不斷展開而逐步深入。因而在項目開發(fā)的初期，敏捷開發(fā)不提倡過度的需求分析，保證對需求的變化的響應(yīng)是動態(tài)且及時的。另外敏捷開發(fā)的項目在設(shè)計上應(yīng)當分為數(shù)個迭代周期，在每個周期內(nèi)都應(yīng)當產(chǎn)出可交付的軟件產(chǎn)品，并且將用戶的反饋作為下一次迭代開發(fā)的基礎(chǔ)。總結(jié)來說，可交付的可執(zhí)行軟件是評判敏捷開發(fā)項目進展以及成果的最主要的依據(jù)，而整個開發(fā)過程又是自反饋的，這種迭代式的自反饋使得開發(fā)的過程也是不斷改進，不斷完善的過程。

? 2.4開發(fā)流程

? ? ? 敏捷開發(fā)大體上將項目管理開發(fā)的生命周期分為了三個階段，分別為項目規(guī)劃階段、項目啟動階段以及迭代開發(fā)與發(fā)布階段。項目規(guī)劃階段類似于傳統(tǒng)開發(fā)過程中的可行性分析和需求分析階段，在這一階段內(nèi)開發(fā)人員需要確定軟件開發(fā)的計劃以及對客戶的需求進行初步的了解分析。項目啟動階段是一個過渡階段，用于軟硬件環(huán)境的準備、開發(fā)場地布置、資源準備等等。在必要的情況下還可以對前一階段的需求分析進行更詳盡的處理。迭代開發(fā)與發(fā)布階段是整個流程的核心部分，項目組會根據(jù)目標系統(tǒng)的發(fā)布版本，將這一階段分成多個迭代重復的過程，并且每一次的過程都是一次目標系統(tǒng)的增量在開發(fā)環(huán)境中實現(xiàn)，并從開發(fā)環(huán)境到生產(chǎn)環(huán)境進行遷移。這里需要強調(diào)的是在這個階段里最重要的過程既不是開發(fā)過程，也不是測試過程，而是常常被傳統(tǒng)開發(fā)過程所忽視的發(fā)布過程。因為在敏捷開發(fā)模型中，產(chǎn)品的第一次發(fā)布會在較早的時間產(chǎn)生，而這個版本的發(fā)布會對客戶的投資以及市場的反饋還有后續(xù)的項目走向調(diào)整產(chǎn)生重要的意義。

? 2.5優(yōu)點

? ? ??敏捷開發(fā)采用了簡單的計劃策略，因而開發(fā)的周期較短，適合于中小規(guī)模項目的開發(fā)。并且在敏捷開發(fā)的整個開發(fā)過程中，我們都采用了迭代增量開發(fā)，不斷反饋修正，不斷測試的方法，既有力的保障了軟件的質(zhì)量。最重要的一點是敏捷開發(fā)很好地適應(yīng)了用戶瞬息萬變的需求，能夠做到及時響應(yīng)，及時調(diào)整，為用戶能夠提供高質(zhì)量的軟件。

3.敏捷開發(fā)模型與傳統(tǒng)軟件開發(fā)模型的對比

? 3.1與瀑布開發(fā)模型的對比

?

? ? ?圖 3 - 1

?

? ? ? 瀑布模型將軟件開發(fā)周期分為六個基本活動，并且規(guī)定了其自上而下的銜接順序，雖然這樣的開發(fā)方式易于使用并且方便實用，但是很難表達出用戶的需求，不適應(yīng)于需求的變化。

? ? ??圖 3 - 2

?

? ? ? 敏捷開發(fā)以人為核心，將軟件項目切分成多個子項目，各個子項目都經(jīng)過測試，具備集成和可運行的特征，即把大項目分解成為多個相互聯(lián)系但也可以獨立運行的小項目，在這個過程中，軟件一直處于可運行的狀態(tài)。

? 3.2與迭代開發(fā)模型的對比

? ? ? 敏捷開發(fā)與迭代開發(fā)都強調(diào)在較短的開發(fā)周期內(nèi)提交軟件，但是基于Scrum的迭代開發(fā)卻會在一個較長的迭代周期頻率下不斷交付。在迭代開發(fā)的過程中我們不允許有不斷改變的需求，否則迭代的方向會不停的改變，使得偏離預想的路線，因而在這樣的一些場景下就會使得迭代變得十分困難。與此同時，迭代開發(fā)在項目的估算方面難度很大，導致對項目的安排缺乏宏觀性，不容易作出相關(guān)的一些承諾。相比較而言敏捷開發(fā)則是適應(yīng)型的開發(fā)方法，更有利于處理變化的需求，而其具備的小團隊的特點則有利于開發(fā)人員之間的溝通交流以及用戶代表與開發(fā)團隊之間的交流，這種交互是很關(guān)鍵的反饋模式。“人與交互”帶來的是知識的迅速傳播以及思維共享。

? 3.3與螺旋開發(fā)模型的對比

? ? ? 與螺旋開發(fā)模型相比，敏捷開發(fā)的方法強調(diào)更多的是適應(yīng)性而非預見性。螺旋開發(fā)的本質(zhì)是將瀑布模型和快速原型模型結(jié)合起來，并且對其他模型所忽視的風險加以分析，因而適用于大型的系統(tǒng)。螺旋模型的特點在于我們不需要在開始的時候就完全定義清楚客戶的需求以及軟件開發(fā)的基線，我們只需要定義清楚最主要的功能，然后不斷的迭代，從客戶的意見與反饋修正迭代方向，從而完善軟件的功能。我們可以這樣認為，螺旋開發(fā)模型很大程度上是由風險驅(qū)動的，我們不可能在不對每個階段進行風險評估的情況下進行循環(huán)迭代，因而在螺旋開發(fā)的模型中，風險評估往往是很重要的一部分。而對于敏捷開發(fā)來說，在整個開發(fā)周期內(nèi)，很多情況的發(fā)生都具有不可預見性，因而敏捷開發(fā)強調(diào)的不是風險的預估而是對風險的適應(yīng)，如何快速集中地適應(yīng)發(fā)生的變化，才是敏捷開發(fā)最需要研究的問題。

? 3.4與CMMI模型的對比

? ? ? CMMI標準是目前對軟件組織能力進行評價時使用的最為廣泛的模型，它能夠規(guī)范軟件開發(fā)的過程，并且產(chǎn)生和維護大量的文檔，所以被稱為“重載方法”，與此相對，敏捷開發(fā)因為其較高的軟件開發(fā)效率而被稱作“輕載方法”。雖然敏捷開發(fā)能夠提高軟件開發(fā)的效率，克服了傳統(tǒng)軟件工程中認識和實踐上的弱點，但是其本身也存在很多不足，比如在工程上和管理過程上缺乏一致性和充分性的考慮，并且常常只使用于中小型軟件的開發(fā)，對于大中型的軟件支持不足。因而在某種意義上來說，CMMI與敏捷開發(fā)既是對立的，也是是互補的。CMMI是一個非常好的框架，它強調(diào)了機構(gòu)性的過程管理，但是如果沒有很好的理解和正確的實施，常常會造成不必要的浪費和損失。敏捷開發(fā)強調(diào)的是可實現(xiàn)功能的軟件，追求開發(fā)的效率，盡量縮短開發(fā)周期，并且開發(fā)是面向非結(jié)構(gòu)性的，具有應(yīng)變的時間。

? 3.5宏觀對比

? ? ? 總結(jié)而言，敏捷開發(fā)一部分程度上是基于傳統(tǒng)的開發(fā)方法而改進的，但它能夠吸收其他方法的優(yōu)點，而盡量減少其缺點，正所謂融百家之所長。然而在繼承的基礎(chǔ)上，敏捷開發(fā)也很好地做到了改進。

? ? ? 比如在分工方面，傳統(tǒng)方法階段的劃分分明，一般來說不同階段的工作由不同的人來完成，每個人都有標準的分工。但是對于某些需要全體成員積極參與的項目比如課程設(shè)計或者畢業(yè)設(shè)計這樣的項目，采用傳統(tǒng)的方法意味著告訴前面已完成工作的開發(fā)人員不必要再關(guān)注后續(xù)部分的工作，這樣既降低了所有人的項目參與度，也不利于互相之間的交流學習。敏捷開發(fā)很好地解決了這個問題，團隊的每個成員從與客戶的交互到代碼的編寫，都需要親身體驗，這就保證了各個成員的參與度。

? ? ? 又比如在用戶需求方面，傳統(tǒng)方法常常要求用戶提供明確的需求，并且開發(fā)人員也只能在正確的需求條件下才能完成正確的開發(fā)。但是我們都知道一方面是因為計算機的發(fā)展速度之快，以致于固定的需求已經(jīng)不再是軟件的基本要求，而應(yīng)當是跟隨市場的反饋而追求不斷的變化與創(chuàng)新，隨著時間的推移而產(chǎn)生巨大的變化，另一方面是顧客與開發(fā)人員之間的溝通可能存在不到位的情況，致使理解出現(xiàn)了偏差，導致對需求的明確度不高。所以傳統(tǒng)開發(fā)模型對于變化的需求不能很好地適應(yīng)，這一點遠遠比不上敏捷開發(fā)極強的適應(yīng)性。

? ? ? 還比如多數(shù)傳統(tǒng)的開發(fā)方法是由文檔驅(qū)動的，在開發(fā)的每一個階段都需要相應(yīng)的文檔進行總結(jié)分析，并指出后續(xù)的開發(fā)要點，因而如果前面的階段沒有完成或是沒有及時編寫文檔，開發(fā)人員是無法繼續(xù)進行下一階段的工作的。敏捷開發(fā)則不同，它是由功能驅(qū)動的，因而重點在于每一階段的測試工作的完成，這很有利于小規(guī)模團體之間的交流協(xié)作與提升開發(fā)興趣。

? ? ? 再比如說傳統(tǒng)開發(fā)方法中對于顧客的定位是觀察者，而不是參與者，這就決定了顧客與開發(fā)團隊之間的利益博弈的關(guān)系，用戶的參與度不高，常常導致開發(fā)團隊交付的軟件與用戶預想的結(jié)果有較大的差異。在敏捷開發(fā)模型中，顧客與團隊是相輔相成的，顧客可以直接參與軟件的開發(fā)過程并及時提出相應(yīng)的修改意見，一旦有了交互的過程，就意味著開發(fā)出來的軟件具有極高的適用性，能夠促進客戶與團隊之間關(guān)系的良性循環(huán)。

? ? ? 最后我們看看軟件模塊的集成。傳統(tǒng)開發(fā)方法的的集成工作常常會堆在開發(fā)的末期進行處理，這就使得在集成的過程中如果出現(xiàn)問題的話很難有足夠的時間進行調(diào)試和修改，而敏捷開發(fā)在每個階段都會有一次模塊的集成，每一次的集成對于軟件的改動相對較小，因而發(fā)現(xiàn)問題可以及時定位糾正。事實上，敏捷開發(fā)的測試往往是自動化的，所以這也給開發(fā)人員減輕了很多壓力與負擔。另外，傳統(tǒng)軟件開發(fā)的周期比較長，獲得可執(zhí)行軟件的時間也比較晚，而敏捷開發(fā)的周期較短，并且很早就能獲得第一版可執(zhí)行軟件，留給用戶進行反饋的時間也比較充分。

? ? ? “取其精華，去其糟粕”，這是敏捷開發(fā)方法之于傳統(tǒng)軟件開發(fā)方法之間最重要的區(qū)別與聯(lián)系。

4.新軟件形勢下的敏捷開發(fā)

? 4.1實現(xiàn)敏捷開發(fā)在實際項目中的應(yīng)用

? ? 4.1.1國內(nèi)軟件開發(fā)環(huán)境

? ? ? （1）中小型企業(yè)較多，大中型企業(yè)較少，很多企業(yè)開發(fā)的項目達不到所預期的效果；

? ? ? （2）多數(shù)公司對于軟件開發(fā)的測試過程不夠重視，不足以應(yīng)對敏捷開發(fā)所要求的測試技能以及需求的變化；

? ? ? （3）無論是什么開發(fā)方式都要求團隊之間的配合度和和諧性，但是很多團隊目前的默契度不足以支持敏捷開發(fā)的各個階段；

? ? ? （4）目前很少有企業(yè)領(lǐng)導對敏捷開發(fā)方式有足夠高的重視度，如果不能自上而下的實行，底層開發(fā)團隊往往有心無力；

? ? ? （5）中小型公司缺乏相關(guān)的專業(yè)人才，很難普及相應(yīng)的模式；

? ? ? （6）公司常常注重的是個人能力，相信的是少數(shù)人的能力，以此來保證軟件的開發(fā)，但是這種信任則是冒著很大的風險；也有的公司更加看重項目的流程，對項目本身的效率造成了很大的影響，難以產(chǎn)生高的效益。

? ? 4.1.2敏捷開發(fā)與企業(yè)架構(gòu)的兼容性

? ? ? 我們知道敏捷開發(fā)常常適用于中小項目的開發(fā)，并且開發(fā)團隊以3-5人為宜，而這顯然是與傳統(tǒng)企業(yè)的架構(gòu)是格格不入的。但是面對著客戶需求由“單一化”到“動態(tài)化”的新型軟件格局的普遍化，傳統(tǒng)軟件工程的開發(fā)方法受到了相當嚴重的打擊。我們知道傳統(tǒng)的軟件開發(fā)模型大多都是線性流程，這種流程帶來的最大的問題就是架構(gòu)單一，難于變通和創(chuàng)新。因而敏捷開發(fā)的思想在當前的環(huán)境下就顯得格外重要。那么敏捷開發(fā)如何實際應(yīng)用于傳統(tǒng)軟件企業(yè)當中呢？事實上敏捷開發(fā)與企業(yè)架構(gòu)是可兼容的，但是我們需要為之付出不小的努力。從目標來看，企業(yè)架構(gòu)以及敏捷開發(fā)的目的都是向顧客交付功能與需求對齊的高質(zhì)量軟件，并且不斷響應(yīng)過程中需求的變更，然而兩者的實現(xiàn)方式截然不同。事實上從某種程度上來講，對于一項工程，無論是哪種開發(fā)方式的缺失都有可能帶來一些微小的問題。比如對于一個文檔處理系統(tǒng)來說，僅僅使用敏捷開發(fā)方式雖然效率很高，但是很難協(xié)調(diào)處理好企業(yè)架構(gòu)的需要，類似跨越需求，接口或是操作性的問題。或者比如說一個使用瀑布模型開發(fā)的系統(tǒng)，很完美地處理好了企業(yè)架構(gòu)的問題，但是卻不能在較早的時間向客戶展示系統(tǒng)的價值，也幾乎不可能通過迭代解決可能遇到的風險。所以均衡這兩者是軟件開發(fā)最為平衡的模式。我們可以這樣實現(xiàn)二者的均衡：對于一個敏捷開發(fā)團隊，它可以屬于一個企業(yè)架構(gòu)組，團隊中的成員有必要與組內(nèi)成員互相交流，互相聯(lián)系。敏捷開發(fā)在保證自身工作完整性的條件下兼容組織架構(gòu)的運行，使得兩者相互包容，和諧相處。

? ? 4.1.3敏捷開發(fā)與CMMI模型的共存

? ? ? 在這里我們需要強調(diào)兩個概念，融合與共存。

? ? ? 什么是融合？一杯牛奶和一杯咖啡，各取半杯混成一杯，這就叫融合。但是融合成的這一杯牛奶咖啡真的好喝么？也許合適的比例下得到的產(chǎn)物味道很好，但是這樣能夠給予我們多大的好處呢？對于敏捷開發(fā)和CMMI來說，融合并不是一個好的選擇，因為一旦融合就意味著必然有一者會消失被另一個吞并，或是兩者都消失，轉(zhuǎn)化成新的東西。從理論上來講，CMMI與敏捷開發(fā)兩個行業(yè)的差別很大，所解決的問題，所要面臨的問題以及自身的客觀規(guī)律也都相差很大，而CMMI與敏捷開發(fā)在行業(yè)中的定位僅僅只是方法，因而如果不能使得行業(yè)本身或是其自身規(guī)律融合，僅僅只有方法的融合，這是不協(xié)調(diào)的。目前的狀況是我們很難找到不同問題之間的融合點，因而這兩個方法之間的融合也成了無稽之談。

? ? ? 不能融合并不代表不能共存。什么是共存？老虎獅子各自在自己的領(lǐng)域中活動，必要時相互協(xié)作，這是共存。CMMI與敏捷開發(fā)的關(guān)系就如同家里的桌椅之間的關(guān)系，桌子和椅子單獨使用總是不能夠盡善盡美，但是也沒有什么融合的必要，而如果桌椅擺放在一起就能協(xié)調(diào)運轉(zhuǎn)，完成相應(yīng)的功能。

? ? ? 所以在兩者可以共存的前提下，我們需要考慮的是面對什么項目應(yīng)當選取哪種開發(fā)方式，在哪些階段使用哪種開發(fā)方式，兩者能否結(jié)合使用這些問題。我們可以通過一些切入點來思考這些問題：

? ? ? （1）??? 明確軟件整體的發(fā)展方向，認準軟件發(fā)展形勢，在提高自身競爭力的前提下選擇合適的開發(fā)模式；

? ? ? （2）??? 根據(jù)企業(yè)自身的規(guī)模以及發(fā)展情況適當選取模型，拿小型公司來說，CMMI對于企業(yè)劃分成五個等級，小公司自身處于CMMI所規(guī)定的等級中的較低級，在這樣一種情況下貿(mào)然采用敏捷開發(fā)是有相當大的風險的。而對于中等規(guī)模的公司來說，在項目過程達到要求的情況下可以適當選擇敏捷開發(fā)以提升開發(fā)的效率。對于大公司來講，大公司講究的是企業(yè)的基礎(chǔ)和文化，并且擁有優(yōu)秀的開發(fā)和測試人員，因而最好不要輕易的改變自身的項目開發(fā)模型，但是可以現(xiàn)在小型項目上進行試驗，以此來積累經(jīng)驗減小風險。

? ? ? （3）??? 對于特定的項目開發(fā)，我們?nèi)绻饶芊螩MMI的規(guī)范，又能采用敏捷開發(fā)提高效率，那當然是再好不過了，這樣我們便可以獲得真正意義上的開發(fā)的可重復性以及成本風險的可預測性等等好處。

? ? ? （4）??? 采用敏捷開發(fā)一定要考慮到自身的利益，以及未來發(fā)展的期望，目光長遠才能穩(wěn)定發(fā)展，不能急功近利，只看眼前。

? 4.2敏捷開發(fā)在項目開發(fā)中的要點

? ? ? 近些年來，越來越多的開發(fā)團隊開始采用敏捷開發(fā)的開發(fā)方式對軟件進行開發(fā)，并且取得了較好的效果。而敏捷開發(fā)模型其實也是一把雙刃劍，合理利用可以極大的提升開發(fā)的效率，一旦沒有把握開發(fā)中的要點，有可能帶來資源的浪費以及成本的損失。所以對于敏捷開發(fā)人員來說，需要在開發(fā)周期中重視下面幾個要點，這些要點也常常與傳統(tǒng)開發(fā)方式的要點相反：

? ? ? （1）??? 敏捷開發(fā)需要重視概念和架構(gòu)的設(shè)計，適當看淡產(chǎn)品的詳細設(shè)計，強調(diào)的是產(chǎn)品的路線規(guī)劃、市場趨勢、客戶價值、技術(shù)趨勢、實現(xiàn)方式、層次分布、層次關(guān)系設(shè)計等，而不是具體的設(shè)計和做法以及API接口；

? ? ? （2）??? 建立系統(tǒng)化的分析方法，對產(chǎn)品進行SWOT分析，注重客戶的需求，適應(yīng)市場的變化；

? ? ? （3）??? 開發(fā)由業(yè)務(wù)和客戶進行驅(qū)動，而不應(yīng)由開發(fā)技術(shù)進行驅(qū)動，或者說不要從技術(shù)方面盲目的擴大需求，這種需求往往并不是客戶真正想要的需求。另外就是敏捷開發(fā)雖然擁抱變化，但不歡迎盲目的變化，它崇尚簡單的設(shè)計而不是顛覆性的設(shè)計，意味著如果我們需要做出一些改動，務(wù)必保證版本遷移的平滑性； ?

? ? ? （4）??? 測試優(yōu)先，在編碼之前應(yīng)當先編寫測試。與傳統(tǒng)的開發(fā)模型恰恰相反，先編寫測試用例，既是一種驗證，更是一種設(shè)計，在這個過程中，我們可以發(fā)現(xiàn)某些需求設(shè)計上的缺陷從而便于更改需求和設(shè)計，避免付出無謂的勞動，造成無意義的浪費；

? ? ? （5）??? 時刻考慮版本的兼容性，當設(shè)計變動的時候，要時刻考慮產(chǎn)品的架構(gòu)，產(chǎn)品的規(guī)劃以及上一個版本的兼容性，以方便后期的維護工作；

? ? ? （6）??? 不看重的文檔，但并不意味著不撰寫文檔，敏捷開發(fā)重視溝通，文檔也是溝通的一種方式。敏捷開發(fā)所排斥的是開發(fā)過程中的冗余文檔，有利于節(jié)省大量的時間和成本；

? ? ? （7）??? 敏捷開發(fā)提倡溝通，溝通才能使效益最大化，這里的溝通既包含了團隊內(nèi)開發(fā)人員的相互溝通，更包括了開發(fā)人員與客戶之間的溝通，溝通的效果會直接影響軟件的質(zhì)量、成本以及軟件能否順利交付；

? ? ? （8）??? 時刻保證開發(fā)團隊的活力與激情，只有這樣才能隨時適應(yīng)需求等設(shè)計的變化，從而做出更高質(zhì)量的軟件。

5.總結(jié)

? ? ? 在當下日益發(fā)展的計算機軟件環(huán)境下，敏捷開發(fā)已然成為軟件開發(fā)者不可或缺的一種開發(fā)模式，當然其自身仍然存在著一些尚未解決的缺陷，而我們要做的就是合理運用敏捷開發(fā)的模式，并與傳統(tǒng)開發(fā)模式相結(jié)合，因地制宜，對癥下藥，這樣才能有效地降低開發(fā)的成本，提高開發(fā)的效率，適應(yīng)軟件社會的發(fā)展趨勢。

6.參考文獻

[1] 張林、張德勇，敏捷開發(fā)在軟件產(chǎn)品項目中的應(yīng)用實踐[A].2011.

[2] Roger S Pressman，軟件工程-實踐者的研究方法[M].北京：機械工業(yè)出版社，1999.

[3] Jakobsen C R，Sutherland J.Scrum and CMMI going from good to great[C].Chicago，IL：IEEE，2009：333-337.

[4] 鄧輝，敏捷軟件開發(fā)：原則、模式與實踐.清華大學出版社，2003：9，132.

[5] 蘇敬凱，敏捷軟件開發(fā)[M].機械工業(yè)出版社，2008，1.

[6] CMMI Product Team. CMMI for development，version 1.2[M].Pittsburgh：Carnegie Mellon University Software Engineering Institute，2006.

轉(zhuǎn)載于:https://www.cnblogs.com/ztc14061055/p/5985127.html

總結(jié)

以上是生活随笔為你收集整理的多元化时代敏捷软件开发的崛起与传统软件工程的延续的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。