傳統軟體開發與敏捷式軟體開發 (Agile Software Development)的比較

標籤：管理   交流   images   敏捷   順序   進度   發展   scope   方法   

　　本篇部落格分別基於軟體開發生命週期和範圍管理這兩個不同的方面對傳統軟體開發方法和敏捷式軟體開發 (Agile Software Development)方法進行分析比較，希望與讀者分享交流。

 

傳統方法：

　　從本質來講，傳統軟體開發方法是一個軟體開發架構，其開發過程是通過一系列階段順序展開的。通常，這一方法不能很好地表達和描述使用者的需求，而且在項目整個開發週期的所有階段都有需要不斷完善的文檔。

 

敏捷方法：

　　軟體行業飛快發展，軟體技術不斷創新，客戶期望迅速變化，考慮到需要克服傳統開發方法的缺點，敏捷開發在近十年來興起，以其靈活性，易操作性得到軟體行業的廣泛關注。敏捷方法通過使用迭代、早期測試和客戶協作來處理不穩定的需求，在項目的整個開發週期中不斷改進，從而使得敏捷開發方法能夠儘快提供業務價值。也因此，在過去幾年中，敏捷式軟體開發 (Agile Software Development)已經成為一種極具前景的複雜性方法，並提出了各種敏捷方法，其中包括被廣泛應用的極限編程（XP）。

 

一、傳統方法與敏捷方法基於軟體開發生命週期法的比較

　　軟體開發生命週期（SDLC：software development life cycle）是指軟體開發的全部過程、活動和任務的結構架構，其一般步驟包括：確定問題、可行性分析與開發計劃、收集需求、分析與設計、編碼開發、測試、安裝、維護。

　　軟體開發生命週期法也稱為結構化系統開發方法，將這一概念進行工具化，就得到了軟體開發生命週期模式。通過軟體開發生命週期模式，能清晰、直觀地看到軟體開發的全過程。

1、傳統軟體開發生命週期模式

　　傳統模式階段劃分分明，項目需求的細節要求在開發之前給定，並且要求使用者需求明確，只有在正確的需求下才能得到正確的下一步結果。與此相對應的，每一階段沒有得到相應的文檔，是無法進行下一階段工作的。開發過程中客戶不會參與。這也往往會導致最終開發軟體與顧客理想軟體有差距。瀑布模式是傳統方法最典型的代表，其生命週期圖1所示。

 

　　在實際的軟體開發過程中，軟體的需求往往是變化的，而瀑布開發模型很難適應這種變化。針對瀑布模型的這一不足，又出現了螺旋模型和統一過程開發模型，但仍然無法很好地適應需求的快速變化。

2、敏捷開發生命週期模式

　　不同於傳統模式，敏捷開發以使用者的需求進化為核心，採用迭代、循序漸進的方法進行軟體開發。所有的迭代（不論長度）都有相同的模式，這也是敏捷開發規律的一部分。在敏捷開發中，軟體項目在構建初期被切分成多個子項目（得到大概的需求和架構模型），各個子項目的成果都經過測試，具備可視、可整合和可運行使用的特徵。由此，敏捷開發的生命週期由多個迭代過程完成，在迭代的每次過程中都要重複分析、設計、編碼等，2所示。

 

　　敏捷方法允許變化可以隨時隨地發生。極限編程（XP）是較為典型、最為完善的敏捷開發方法。XP作為一種近螺旋式的敏捷開發方法，將複雜的開發過程分解為一個個相對比較簡單的小周期，通過與客戶積極的溝通、反饋以及其它一系列的技術方法，這一過程使得開發人員和客戶都可以非常清楚開發的進度、變化、待解決的問題和潛在的阻力等，並根據實際情況及時調整開發過程。XP的生命週期3所示，它首先創造一個候選架構，然後通過一個關於整個系統運作方式的簡單描述來指導全部開發過程，而不需要提前進行詳細架構設計。

 

3、比較討論

　　傳統方法在開發初期和客戶溝通，擷取儘可能明確詳盡的需求，其開發軟體的過程往往是客戶與Team Dev的利益博弈的過程，所以在開發過程中顧客的參與度不高，主要強調計劃、過程和文檔等。而敏捷方法對於需求不明確的複雜項目，要求客戶和Team Dev一起開發能夠在較短時間和較低預算內成功完成，主要強調團隊、客戶合作和擁抱變化等。

　　綜上，我們可以認為敏捷方法是綜合多種傳統方法優點整理出來的一種開發方法，是一個新的思路，但這並不意味著不一定是所有軟體開發的最優選擇。當然，敏捷方法也存在一些問題，如敏捷方法中通常使用代碼替代文檔，在很多實際情況下大大降低了系統的可讀性。這就需要我們能夠隨機應變，採用更務實的思想和方法。

 

二、傳統方法和敏捷方法基於範圍管理的比較

　　範圍用以限制和控制項目中包含的工作。良好定義和良好管理的範圍對於項目成本效益和軟體開發時間表非常重要。專案範圍主要涉及到兩方面內容：

　　①產品範圍界定：產品範圍的特徵和功能包含在產品或服務中。

　　②工作範圍界定：項目工作的完成為的是能交付一個有特殊的特徵和功能的產品。

　　專案範圍管理組件括的程式，要求能確保該項目所覆蓋的整體工作要求和單項工作要求，從而促使項目工作成功地完成。針對軟體開發過程中不明確的需求、停用資源，不斷變化的環境和不靈活性等眾多可能問題，項目中需要進行範圍管理，如果不仔細管理，可能導致項目失敗。範圍管理主要包括以下五個過程：

　　①啟動階段：督促專案管理組織開始著手項目下一階段的工作。

　　②範圍規劃報告：寫出一份書面報告，作為未來項目決策基礎。

　　③範圍界定：把主要的項目工作細目分解成更小、更易管理操作的單元。

　　④範圍核實：正式認可這個專案範圍。

　　⑤範圍變化控制：對專案範圍的變化進行控制。

1、傳統方法的範圍管理

　　在傳統軟體開發方法中，範圍被定義為軟體項目的完整需求規範。它包含項目開始時的詳細需求，在開發過程的後期階段需要分析使用這些需求。然而，耗費開發人員很多時間和精力完成的相關文檔並不支援在開發過程的後期階段可能發生的變化。這些不可控的變化往往會導致範圍蠕變（在產品或項目開發期間，需求驅動發生變化，帶來一些開始沒有計劃的產品特點，對產品品質或軟體開發時間表產生影響），而處理範圍蠕變需要使用不同的工具和技術，這可能使得項目逾期並且超出預算。

　　傳統方法建立分工結構圖（WBS），用以把項目可交付成果和項目工作分解成較小的、更易於管理的組成部分的過程。當範圍發生變化時，傳統方法需要審查整個分工結構圖，很難基於特定變化做出良好快速的適應，這將不可避免地影響項目的成本、資源、品質和時間表。因此，為避免項目失敗，傳統方法需要非常仔細地定義和管理其範圍。

2、敏捷方法的範圍管理

　　敏捷方法擁抱軟體開發過程的後期階段的變化，即接受專案範圍的波動。因此，敏捷方法的專案範圍常常需要滿足進階別的要求。敏捷方法的範圍採用迭代並接受漸進的變化，由負責接受或拒絕在每個迭代期間完成的功能的客戶來驗證和控制。

　　管理範圍蠕變是敏捷方法範圍管理的一個非常重要的方面。在軟體開發過程中會不斷地產生一些變化，其中可能存在著影響整個項目的變化，敏捷方法中的範圍管理技術會管理這些不可控的改變，這在一定程度上保證了軟體項目在開發過程中的穩定性。與傳統方法不同，在敏捷方法中沒有建立WBS。

3、比較總結

　　範圍定義了軟體開發過程的邊界。範圍管理是關乎敏捷方法和傳統方法成功完成整個過程的一個重要因素。敏捷方法中的範圍管理與傳統方法的大致對比4所示。

 

　　敏捷方法中的範圍管理允許變化並且可以減少不必要的變化，在範圍上遵循反覆項目計劃，需要滿足進階別的要求。具有上述特徵使得敏捷方法的範圍管理保證了軟體的時間表，並且軟體產品可以在預算內以良好的品質交付。

　　傳統方法中的範圍管理中不可控的變化導致範圍蠕變，往往使項目超出預算並且破壞軟體開發時間表。同時，在傳統方法中需要建立WBS，且管理的範圍需要以全面的文檔的形式進行詳細定義。

　　基於上述比較分析，我們可以認為敏捷方法在產品成本、項目資源和軟體開發時間表等方面都足以成為傳統方法的更優替代。

 

參考文獻：

[1] 張志麗.軟體開發生命週期法比較之敏捷與傳統[J].軟硬體開發, 2013 (12) : 32-37.

[2] Rehman, I.U. & S.ullah & A.Rauf & A.A.Shahid. Scope Management in Agile Versus Traditional Software Development Methods[C]. New York: NSEC ‘10 Proceedings of the 2010 National Software Engineering Conference, 2010.

[3] 王沖.敏捷開發與傳統瀑布模型的比較及教學[J].研究與探討, 2011 (4) : 61-62.

[4] Shawky, D.M. Traditional vs Agile development a comparison using chaos theory[C]. Software Paradigm Trends (ICSOFT-PT), 2014 9th International Conference on, 2014。

[5] http://baike.baidu.com/item/%E8%8C%83%E5%9B%B4%E7%AE%A1%E7%90%86

[6] http://baike.baidu.com/item/%E7%89%B9%E5%BE%81%E8%A0%95%E5%8F%98

[7] http://baike.baidu.com/view/259207.htm

[8] http://baike.baidu.com/view/47193.htm

 

傳統軟體開發與敏捷式軟體開發 (Agile Software Development)的比較