敏捷開發與傳統開發方式的比較


敏捷開發的起源

在90年代末期,傳統軟件開發的方式因為其繁雜的過程,以及對文檔的過於嚴格的要求,造成了很大程度上的效率下降,也就是人們所說的“重型化危機”。因為這一原因,人們開始反思傳統方法的利弊,並對其弊端進行了改進,提出了敏捷方法。

2001年2月,由Martin Fowler,Jim Highsmith等17位軟件開發專家起草的敏捷宣言發表,敏捷聯盟成立。敏捷開發作為一種新的方法正式誕生。敏捷宣言中所表述的價值觀分為四個方面:

(1)個體和互動 高於 流程和工具(2)工作的軟件 高於 詳盡的文檔
(3)客戶合作 高於 合同談判
(4)響應變化 高於 遵循計划

同時敏捷宣言還包括12條原則。這十二條原則是以上四條主要的價值觀在實際工作中的體現。

總體來說,敏捷開發作為一種新的軟件工程方法,與傳統方法相比更加注重人的因素。不再把開發者當作一個物化的,投入多少時間可以完成相應數量代碼的代碼開發機器;而是注重開發者之間的互動以及開發者和用戶之間的互動,同時因為增加了交流和協作使得開發的項目更加靈活和易於修改。

敏捷開發的主要特點

與傳統開發方法相比,在敏捷開發的整個過程中,有以下幾個主要的特點:

(1)敏捷開發的過程有着更強的適應性而不是預設性,從敏捷宣言的第四條響應變化高於預設計划便可以看出來。因為軟件開發過程的本身的不可預見性,很多用戶在項目開始時不可能對於這個項目有着一個完整而明確的預期。很多對軟件的預期都在后期的修改和完善過程中產生。因此高適應性顯然更加符合軟件工程開發的實際。而敏捷開發實現其適應性的方式主要在於,第一,縮短把項目提交給用戶的周期;第二,增加用戶,業務人員,開發人員這三者之間的交流;第三,通過減少重構的成本以增加軟件的適應性。

(2)敏捷開發的過程中,更加的注重人的因素。在傳統軟件工程中,個人的因素很少的被考慮到分工中,每個個體都是只是整個代碼開發機器的一個小小的螺絲釘,個人的意志和創造力很大程度上的被抹去為了更好的為集體服務。而在敏捷開發過程中,每個個人的潛力被充分的考慮,應用什么技術很大程度上直接由在第一線開發的技術人員決定;每個人的特點和創造力都可以充分地發揮,這樣開發出來的軟件更加的具有生命力,因為他融入了開發者的心血和創意,開發者不再是進行機械的乏味的堆砌,而是創造屬於自己的藝術品,這樣的條件下產生的代碼必然在質量上更占優勢。

(3)在敏捷開發的過程中,整個項目是測試驅動的而不是文檔驅動的。不僅每個模塊有着自己的相應的測試單元,開發人員在開發自己的模塊的過程中必須保證自己所開發的模塊可以通過這一單元的測試,並且集成測試貫穿了整個開發過程的始終。集成測試每天會進行十幾次甚至幾十次,而不是像傳統方法一樣只有當各個模塊的編碼都結束了之后再進行聯合調試。這樣,在軟件開發的進程中每一點改動所引起的問題都容嘉容易暴露出來,使得更加容易在錯誤剛剛產生的時候發現問題從而解決問題。這樣就避免了在最后整個系統完成時錯誤隱藏的太深給調試造成極大的困難。

 

 敏捷過程模型的一個實例:極限編程

敏捷過程作為一種開發過程模型,產生了很多不同的可以應用到實際中的編程方法。這里介紹一種應用的比較廣泛的開發方法,極限編程,來具體體現一些敏捷開發過程的特點。

極限編程過程分為策划、設計、編碼和測試四個階段。

(1)策划階段

首先在策划階段,用戶和開發這進行交流,開發者總結出一系列“用戶故事”,描述軟件某一部分功能。之后客戶對這些功能進行優先級排序,xp團隊評估每一個故事的成本。之后客戶和xp團隊共同決定在開發的下一個版本中將會新增哪些功能。而在版本不斷的迭代的過程中,會進行很多次這樣的策划過程,每一次客戶都可以根據已有的功能來決定是否要新增一些功能,以及要新增哪些功能。

(2)設計階段

在設計階段,開發人員會根據用戶故事,提出這些用戶故事的實現方案。設計的過程中主要遵循簡潔的原則,也就是盡量使用簡介的表述而不是復雜的表述。而設計的另一個方面則是重構,重構是一種通過不改變代碼的外部功能的情況下改變軟件模塊的內部結構從而優化軟件系統的功能的過程。這是一種改進代碼的設計。

在設計的這兩個層面中,我們可以看到在xp開發過程中,設計和開發是同步進行的。我們在不斷實現開始設計的過程中,同時要對到嗎進行優化也就是重新設計。這樣,大大的增強了整個軟件開發的適應性,而不是始終刻板的實現最開始的第一版設計。

(3)編碼階段

xp開發的第一件任務不是直接對初步的設計和用戶故事進行編碼,而是針對這些設計全力開發單元測試。完成了單元測試也就確定了開發者要實現的所有功能。這樣開發者就只需要全力通過單元測試,而不必在實現什么功能上再浪費不必要的時間和精力。這正體現了敏捷開發的以測試驅動的特點。

而在敏捷開發中,很重要的一個提高效率的方式就是結對編程。在結對編程的過程中,兩個開發者共用一台電腦,並各有分工。其中一個人進行實際的編碼實現,另一個人在旁邊考慮代碼在宏觀上該如何實現,比如針對什么功能應該使用什么樣的算法。這樣,在編碼者工作遇到問題時,兩個人交換位置。這時在旁邊思考的人更有可能可以解決這一問題。事實上,結對編程的形式不必拘泥於什么規矩。關鍵在於,兩個人共同開發的過程中,兩個人的交流可以使得大部分的問題可以在第一時間解決。並且,因為兩個人中只有一個人在進行編程這一項比較疲憊的工作,另一個人較為輕松,這樣可以保證開發效率一直保持在一個比較高的狀態。

(4)測試階段

每一個模塊都通過自己的單元測試之后,開發者會將所有的模塊集成到一起進行測試。這樣可以及時發現每一模塊在最近一次改動之中出現的問題同時避免一些兼容性問題。每一次改動一點小問題要比等到最后一次集中修改所有問題要容易得多。

敏捷開發生態系統

敏捷開發模型在實際中有着很多表現形式。極限過程開發(xp)時其中的最為廣泛應用的一種。還有很多其他的,比如:自適應軟件開發、Scrum、動態系統開發、Crystal、特征驅動開發、精益軟件開發、敏捷建模、敏捷統一過程等。這里只舉兩個例子介紹一下其主要的特點。

自適應軟件開發主要從整體上強調軟件項目團隊具有自我組織的動態性、人與人之間的協作、個人以及團隊的學習,從而使團隊更有可能取得成功。

Scrum開發方法,這個開發方法最大的特征就是每日例會。在每日例會中,每個人交流自己昨天干了什么,今天將要干什么,以及自己在工作中遇到了哪些問題。這樣大大地加強了團隊成員之間的交流。

我們可以看到,很多人都投入到了敏捷開發的研究和使用中。敏捷開發確實有着非常強大的生命力。

敏捷開發與傳統開發方法的比較

優勢

敏捷開發的高適應性,以人為本的特性,和輕量型的開發方法即以測試為驅動取代了以文檔為驅動,這三個主要的特點,也就是敏捷開發相對與傳統開發方式的主要有點。因為他更加的靈活並且更加充分的利用了每個開發者的優勢,調動了每個人的工作熱情。

劣勢

與傳統開發方式相比,敏捷開發的最主要的劣勢在於敏捷開發歡迎新的需求,而在每次新的需求產生時都可能引起整個系統的大幅度的修改。因為開發者在開發上一個版本的時候,完全沒有考慮以后的優化將要如何進行。這樣的開發方式實際的軟件開發過程中,並不一定總是有效的。

而另一個方面,敏捷開發因為缺乏很多在敏捷開發中被認為“不重要”的文檔,這樣在一個大型項目比如一個操作系統開發的時候,由於其項目周期很長,所以很難保證開發的人員不更換,而沒有文檔就會造成在交接的過程中出現很大的困難。

 

參考文獻

[1]基於scrum敏捷開發的軟件過程管理研究 王敏

[2]敏捷開發在軟件開發的過程中的應用研究 彭志楠

[3]敏捷軟件開發技術研究 周瑩瑩

[4]敏捷軟件開發應用研究 范洪濤

[5]http://agilemanifesto.org/iso/zhchs/manifesto.html 敏捷軟件開發宣言

[6]http://agilemanifesto.org/iso/zhchs/manifesto.html CSDN 敏捷開發的優缺點

[7]http://www.vaikan.com/agile-programming-10-years-on-did-it-deliver/ 外刊IT評論 敏捷十年,成效幾何?

[8]http://www.infoq.com/cn/news/2010/02/scrum-failings Bob大叔關於Scrum和敏捷的七條缺陷

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM