敏捷軟件開發與傳統軟件開發的對比算法
最先了解敏捷開發是經過大二的一次博雅課堂,一位在百度工做的北航學長跟咱們分享了他近年來從事敏捷開發的經歷。印象最深的一句話是一個延遲3個月交付100%功能的軟件和一個按時交付75%核心功能的軟件,敏捷軟件開發者更願意選擇後者。本學期的軟件工程基礎課又向咱們講授了傳統軟件開發,通過課上和課後的學習,對於敏捷軟件開發和傳統軟件開發有了淺顯的認識和理解。因爲課上學習的重點是傳統軟件開發,因此課下對敏捷軟件開發進行了更多的涉獵,本文以敏捷軟件開發爲主體,來分析其與傳統軟件開發的對比。編程
敏捷軟件開發與傳統開發方法相比具備很大的不一樣,其特色是適應性而不是預測性,強調溝通和反饋,開發團隊不只包括開發人員,還包括管理人員和客戶。它鼓勵團隊成員的相互交流經過反饋機制儘早糾正軟件中的錯誤,提升開發效率,同時爲需求的調整提供更多機會,保證軟件向正確的方向發展。工具
傳統軟件開發如瀑布模型強調預見性,嚴格遵循計劃、分析、設計、編碼、測試和維護等幾個階段。瀑布模型開發各階段間具備嚴格的順序性和依賴性,必須等到前一階段的工做結束後才能開始下一階段的工做,前一階段的輸出文檔是後一階段的輸入文檔,只有前一階段的輸出文檔徹底正確,後一階段才能得到正確的結果。學習
對敏捷聯盟宣言的理解測試
1.個體和交互賽過過程和工具,強調軟件開發必須發揮人的積極性和創造性,更看重人的溝通和團隊的力量;優化
2.能夠工做的軟件賽過面面俱到的文檔,敏捷軟件開發要求文檔短小簡明,能說明系統的高層結構和歸納的設計原理,將精力集中在代碼和測試上;編碼
3.客戶合做賽過合同談判,知足合同的軟件並不必定是成功的軟件,只有知足客戶真實需求的軟件纔是成功的。客戶與開發團隊密切工做在一塊兒,不斷溝通和反饋;spa
4.響應變化賽過遵循計劃,只爲下兩週作詳細的計劃,爲下三個月作粗略的計劃,爲之後作極爲粗糙的計劃。設計
常見的敏捷軟件開發方法的特色對象
1.極限編程(XP):溝通,簡單,反饋,膽識,爲四項基本準則,快速反饋,假設簡單,遞增更改,優質工做,爲5條法則,幾乎無文檔。在全部的敏捷方法中,XP對日期產生的興趣最多,而且在對良好不定的問題領域的特殊實踐方面最爲具體。
2.SCRUM:特別強調開發隊伍和管理層的交流協做。天天,開發隊伍都會向管理層彙報進度,若是有問題,也會向管理層要求幫助解決。
3.動態系統開發方法:堅持功能在項目的全過程當中均可以改變,當功能被容許改變時,經過使用時間框控制的目的就能達到。重視爲項目營造一個正確的文化氛圍,如手冊中描述了項目有不一樣的側重點,並指出對於那些缺陷在傳統方法中轉變起來是多麼的困難。也很是重視協做價值和原理,以及文檔。
4.功能驅動開發方法,短期的迭代階段和可見可用的功能,適合於那些不肯定或常變動的需求的系統。它抓住了軟件開發的核心問題領域,即正確和及時地構造軟件。
5.水晶系列方法:相對於其它敏捷方法,水晶系列方法強調軟件開發流程的紀律性,因此它比其它敏捷方法易於使用,但它的生產率不如Xp等其它敏捷方法。水晶系列與Xp同樣,都有以人爲中心的理念,但在實踐上有所不一樣。人們通常很難嚴格遵循一個紀律約束很強的過程,所以,與Xp的高度紀律性不一樣,水晶系列方法試圖用最少紀律約束而仍能成功的方法,從而在產出效率與易於運做上達到一種平衡。
6.自適應軟件開發(ASD):ASD強調開發方法的適應性,這一思想來源於複雜系統的混沌理論。ASD不像其餘方法那樣有不少具體的實踐作法,它更側重爲ASD的重要性提供最根本的基礎,並從更高的組織和管理層次來闡述開發方法爲何要具有適應性。
各類敏捷軟件開發方面的共同特徵
(1)迭代式開發。整個開發過程被分爲幾個迭代週期,每一個迭代期是一個定長或不定長的時間塊,每一個迭代週期持續的時間通常較短,一般爲1~6 周。
(2)增量交付。產品在每一個迭代週期結束時被逐步交付使用,而不是在整個開發過程結束時一次性交付。每次交付的都是可被部署到用戶應用環境中的、能給用戶帶來即時效益和價值的產品。
(3)開發團隊和用戶反饋推進產品開發。敏捷開發方法主張用戶可以全程參與整個開發過程。這使需求變化和用戶反饋能動態管理並及時集成到產品中。同時,團隊也能及時對用戶的需求提供反饋意見。
(4)持續集成。新的功能或需求變化老是儘量頻繁地被整合到產品中。一些項目是在每一個迭代週期結束的時候集成,有些項目則天天都在集成。
(5)開發團隊自我管理。擁有一個積極的、自我管理的、具有自由交流風格的開發團隊,是每一個敏捷項目的必要條件。敏捷開發老是以人爲中心創建開發的過程和機制,而非把過程和機制強加給人。
項目角度分析區別
下面從敏捷管理、敏捷需求分析、敏捷軟件開發三個主要方面來探討敏捷開發與傳統軟件開發的主要區別和特色。
敏捷管理,創建自組織的團隊,敏捷團隊一個重要的目標是實現快速適應現實的變化,因此敏捷項目管理把控制和計劃移交給整個團隊,而不是管理者。客戶被看作團隊成員。管理者主要是對團隊進行指導,提供必需的資料以及掃清工做障礙。
敏捷需求分析,傳統軟件工程是一個不斷反覆的需求定義、文檔記錄、需求演進的過程,並最終在驗證的基礎上凍結需求。敏捷軟件開發以迭代思想爲核心,項目須要經過屢次構建,它的需求須要在最後一次構建版本時才能完整的定義。敏捷需求分析會把客戶的各類需求按優先級排列,從高到低進行實現,優先級低的需求也可能被拋棄。
敏捷軟件開發,主張演化設計或迭代設計,不作大型的預先設計,快速進入編碼階段,經過重構來維持改進設計。
敏捷開發在人的層面和技術層面都強調及時反饋,測試、設計、編碼交替進行。在儘量短的迭代週期內完成一個小的功能模塊,並快速測試,展現給客戶,得到反饋。
主要特色分析區別
下面從團隊建設、管理流程、用戶參與程度、業務需求、交付頻率和文檔量六個方面來總結一下敏捷軟件開發和傳統軟件開發的區別。
1.團隊建設:以團隊爲單位,強調團隊建設,賦予高度的責任,支持開發、透明的交流環境;以項目經理爲領導核心,團隊成員之間交付不多
2.管理流程:流程能夠簡單,但規劃與執行必須嚴謹;複雜,繁瑣,靜態,變動成本大
3.用戶參與程度:強調用戶保持密切的聯繫和交流;不多涉及用戶參與
4.業務需求:需求具備優先級次序,開發以增量方式逐步完成功能,有助於量化項目過程;假設需求是明確的,一旦需求變動勢必增長其他環節的複雜度
5.交付頻率:常常交付,交付週期短;項目結束時交付,交付週期長
6.文檔量:最必要最實用,高的應用度和閱讀度;產生大量中間文檔,低的應用度和閱讀度
傳統開發生命週期中兩個重要缺陷及敏捷軟件開發的應對策略
1.測試階段每每是整個代碼編寫完成後進行,測試無問題後將產品交付給客戶。假如在測試階段發現了問題,則有可能須要對整個模塊進行返工來修改。
2.因爲開發早期客戶每每不能明確本身須要實現什麼,所以早期創建的需求模型每每不能準確包含系統所需的功能,而在整個產品按照線性模式開發完後,客戶則提出改變需求的要求,這樣對系統進行頻繁修改後,將致使整個系統的兼容性受到影響,尤爲在大型系統中更是表現突出。
相對於傳統軟件開發方法,敏捷方法中避免了客戶在開發初期不能提供準確詳細需求致使的問題,採用迭代式的開發。經過不斷髮布新版本並演示給客戶,使得客戶在與系統交互的過程當中發現本身須要的系統特性,從而改善在每次迭代前提供的需求。這種開發方式中容許客戶延遲某些決定,等有價值的信息出現或對技術優化後纔去決定,這也是敏捷開發的一個優點。實際的敏捷開發中,甚至能夠在任何需求都未知的狀況下開始開發。另外一方面,敏捷開發能夠提供給客戶一個更符合需求的最終產品。每個短的迭代,都爲客戶提供一個完整的模塊以便於討論,因爲這些模塊並非完整的系統,因此以後的任何新增功能的開發都不會增長開發費用。這樣開發者能夠隨時爲客戶增長任何功能,而且系統將在客戶沒有再須要添加的功能後進行整合。所以,敏捷開發的產品將是徹底符合客戶需求的完整的系統。
誤區解讀
通過與傳統軟件開發的對比,可能會有不少人陷入幾個誤區,下面對此進行說明。
首先,敏捷開發並非說能夠不要規範不要文檔,敏捷開發一樣須要文檔,只不過它對規範和文檔像對開發人員同樣,要求把它們組織得更加清晰,高效,要求簡化的只是沒必要要的部分。
其次,不是說敏捷軟件開發與傳統軟件開發相比有這麼多優勢就十全十美了,它固然也有本身的缺陷。
敏捷軟件開發的缺陷
下面就經過與傳統軟件開發的對比來看看敏捷軟件開發的缺陷。
敏捷方法明顯地下降了文檔的數量,甚至聲明代碼自己就是文檔。這就須要開發人員爲代碼添加更多的註釋,可是對於不習慣敏捷開發或團隊新成員則很難作到,他們必須不斷詢問有經驗的開發人員,這樣會致使延遲迭代交付時間,甚至增長開發費用。而傳統開發則強調文檔對團隊成員的指導做用,開發人員能夠在不知道項目細節的狀況下完成開發。
敏捷開發中強調交互和客戶的參與。每次迭代前,團隊和客戶都將召開一個會議,團隊成員將介紹在此次迭代中所做的工做,而客戶則根據成員的介紹給出新的功能要求。實際中大部分狀況,這種例會是很是乏味和沉悶的,由於團隊成員必須重複地向其餘
成員和客戶展現本身負責的模塊,接受給出各類對需求的更改,並且每次迭代都是如此,一般爲迭代分配的時間都是以周爲單位的,開發人員常常感到時間不夠用,尤爲是本身負責的模塊中包含一些複雜的算法時,時間就變得越緊,常常使得迭代延遲。而傳統開發中客戶不會參與開發過程,實現過程當中開發人員只是根據文檔編寫代碼,而後交付最終產品。這樣開發人員沒必要關心那些頻繁的迭代會議,並且時間上更加寬泛,有利於開發出更好的產品。
敏捷開發對開發人員的我的技能要求更高。敏捷開發強調交互和客戶的參與,這就意味着每一個團隊成員都要具有必定的我的能力和社交技能。每次迭代都必須給客戶提供完整的功能模塊,而且須要讓客戶明白當前的開發進程以及開發中遇到的一些問題,開發人員不但須要將本身的工做描述清楚,還得正確理解客戶提出的新需求,這須要具有較好的溝通技能。而實際中,不必定每個開發人員都能具有這樣的技能,一旦某一我的不能正確理解一些重要信息,將可能致使下一次迭代不能準確交付,更糟糕的是,若是理解有誤,會使得開發的模塊中包含多餘的功能,結果是對模塊進行修改,從而增長開發費用。所以,開發人員社交技能的提高將增長開發過程的穩定性。
敏捷開發容許增長需求也致使兩個設計中的問題:系統過於僵硬和機動性強。僵硬是指系統中一旦有更改的地方容易引發其餘模塊的級聯改動。機動性是指可能因爲需求改變而壓縮一些可重複使用的組件,這意味着大量的工做量和對系統總體穩健性帶來風險。若是系統中存在這些問題,會違反面向對象設計中的接口隔離原則,從而致使部署過程當中的不少問題。
因此,敏捷軟件開發和傳統軟件開發在當今都有屬於本身的舞臺,都會向着更好的方向發展。
【參考文獻】
1.基於Scrum敏捷開發的軟件過程管理研究 王敏 《昆明理工大學》 2010
2.基於構件的敏捷軟件開發方法 潘悅,沈備軍 《計算機工程》, 2005, 31(15):68-69
3.幾種常見的敏捷軟件方法綜述 聶華北,沈劍翹 《計算機系統應用》, 2008, 17(12):157-161
4.敏捷過程在軟件工程課程中的教學實踐_樸勇 《計算機教育》, 2015(24):78-80
5.敏捷開發_極限編程在管理信息系統開發中的實踐探討 鄧靖穎,黃穗 《計算機工程》, 2004, 30(24):189-191
6.敏捷開發方法及一個非典型應用實例 林海,徐曉飛,潘金貴 《計算機科學》, 2005, 32(2):125-128
7.敏捷開發軟件模式初探 姚立新,梁宏濤 《電子技術與軟件工程》, 2013(20):82-83
8.敏捷軟件開發技術研究 周瑩瑩 《長春理工大學》, 2006
9.軟件開發生命週期法比較之敏捷與傳統_張志麗 《電腦開發與應用》, 2013(12):32-34
10.敏捷軟件開發方法在軟件維護中的應用研究 於士文 《湖南大學》, 2006