敏捷式軟體開發 (Agile Software Development) VS. 傳統軟體工程

標籤：團隊組織   學生   tle   practice   敏捷開發   素質   alt   電腦應用   資料   

敏捷式軟體開發 (Agile Software Development) VS. 傳統軟體工程　　　　

 

　　　　自從電腦誕生至今，程式是電腦的靈魂，程式從曾經的小型的計算功能發展到如今的神奇作用，程式碼數更是幾何倍數的增長。面對軟體的開發，人們提出了各種方法以適應不同規模下不同軟體的開發。傳統方式的軟體開發被人們發現越來越多的問題，敏捷開發的概念也在這麼多年的編程經曆下應運而生。

    　　 敏捷開發在2001年被提出，之後越來越多的從事軟體方面工作的人開始接受並認同這種開發方法，與傳統的軟體開發方法相比，這種開發方法更注重溝通，更便利的團隊結構和協作態度。正如敏捷開發的宣言所言，個體和互動高於流程和工具，工作的軟體高於詳盡的文檔，客戶合作高於合約談判，響應變化高於遵循計劃。由此可見敏捷開發更加註重的是參與到軟體工程中的人員的交流，注重的是編程人員和與業務專家之間的交流溝通，頻繁地交付新的軟體版本，能夠更好的適應需求不斷變化的代碼編寫和團隊組織形式，也更加註重了人在軟體開發中的作用。

         傳統的軟體開發的具有連續性的步驟性特徵，正如大家所知傳統軟體開發會有很多步驟如：需求定義，計劃，構建，測試和調度。傳統軟體開發在過去的幾十年中促進了軟體開發的系統化，對於日益龐大的軟體規模，傳統軟體開發難免會遇到一些相對難以解決的問題。

         這篇部落格希望能夠通過介紹傳統的軟體工程和敏捷開發，經過總結對別來體會不同的軟體開發方法優劣。

         一、傳統軟體工程：

         在我們生活的這個星球上有著很多偉大的工程，正如我們所知的胡夫金字塔，它於公元前2560年建成，我們無法相信這樣這樣一項偉大的工程沒有任何的工程管理知識，沒有一定的計劃性。現代的軟體也是一樣的，不同於簡單的幾十行上百行就能實現的小程式，現代軟體的規模往往動輒上萬行，甚至十萬，百萬的規模。如果沒有一定的計劃性，沒有一種科學的方法指導我們很難去完成這樣龐大的項目。

         1）產生原因：

         20世紀60年代大容量、高速度電腦的出現，使電腦的應用範圍擴大，軟體開發急劇增長。進階語言開始出現；作業系統的發展引起了電腦應用方式的變化；大量資料處理導致第一代資料庫管理系統的誕生。軟體系統的規模越來越大，複雜程度越來越高，軟體可靠性問題也越來越突出。原來的個人設計、個人使用的方式不再能滿足要求，迫切需要改變軟體生產方式，提高軟體生產率，軟體危機開始爆發。雖然在這之前人們已經開始使用甘特圖（1.1）來制定計劃，但是僅僅這樣還是無法滿足需求。在這段時間裡，軟體開發的進度越來越難以預測，成本越來越難以控制往往實際成本比預期成本高了不止一個數量級，軟體產品的品質越來越難以保證……軟體工程在這種環境下出現。傳統軟體工程包含過程、方法和工具，這些工具使得快速構建高品質的複雜的電腦系統成為可能。軟體過程包括了五個架構結構：溝通、策劃、建模、構建和部署，這些活動適用於所有的軟體項目。軟體工程實踐遵照一組核心原則，是一個解決問題的活動。

 

 

                                                                          　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 圖1.1

         2）常見的傳統軟體工程的過程模型：

         1、瀑布模型（waterfall approach）

         傳統的瀑布模型大致可以分為五個階段：需求（Requirements）、設計（Design）、實現（Implementation）、測試（Test）、維護（Support）。1.2所示。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 

 

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　圖1.2

         瀑布式模型的核心思想是按工序將問題化簡，將功能實現與設計分開，採用結構化的分析與設計方法將邏輯實現與物理實現分開，並且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。

         

　　　瀑布模型是最早出發的軟體開發模型，在被廣泛使用的幾十年裡它提供了軟體開發的基本架構。對於瀑布模型優點很明顯，為項目提供了按階段劃分的檢查點，每次完成該任務時只有確保正確才會開展下一步階段，因此使用瀑布模型使軟體開發人員在軟體開發的時候只需考慮當前階段的編程任務。但是正是這種優點也帶給了這種模型很大的局限性，因為瀑布模型有很強的階段性，造成了這種編程方法面對當下複雜多變的程式設計時會很局限：1）當客戶提出新的需求時因為無法復原性，逆轉工作有可能會做到但是成本很大。2）使用這種開發如果在前面階段出現問題會出現累積現象，錯誤會傳遞發揮擴大，導致成本和品質的失控。3）開發模型是線性，使用者只有等到階段末期才能看到開發成果，加大了開發的風險。

         經過這段時間對於這些方面論文或是文章的閱讀，感覺瀑布開發給人感覺是一種很奇怪的模式，也許是因為學生時期代碼量的不足，以及見到的問題過少，感覺在一個項目的初期就能夠構建的很完善這對制定計劃，設計的人是一個很大的挑戰。因此採用這種方式開發就對開發人員準確的瞭解每個模組實現了哪些問題，如何完成一個項目不同要求的處理順序，怎麼確定實現不同任務時需要的工程量有了很高的要求。雖然有了一個架構更容易在一個規定的時間內完成一項任務，但是很多在開發過程中產生的想法和使用者在不同階段的需求無法在這種開發模型中得到很好的實現。

 

         2.演化過程模型

         相對於上面的瀑布開發模型，演化過程模型開始於溝通，軟體開發人員與客戶先進性溝通，定義軟體的整體目標，明確已知的需求，在大致瞭解目標之後快速的設計出一個模型，這個模型的設計主要集中在使用者能夠看得到的方面。然後由利益相關者進行評價，經過利益相關者的反饋資訊，進一步細化軟體的需求。這種開發方法的大致架構1.2.1所示。                                                

                                  

    圖1.2.1

         優劣性：這種開發方法一方面增加了與利益相關者的互動，能夠更好適應複雜多變的需求，讓使用者在看到一個大致架構的基礎上能夠在原本的想法上提出新的需求更加方便。但是這種開發方法的缺點正是因為利益相關者不一定是瞭解開發的人員，因為是各種各樣需求堆積出的程式，就會造成很多意向不到的bug，過多的需求會讓開發人員難以保證整體軟體品質，會造成軟體的可維護性降低。作為一個開發人員在完成當下的一個目標時可能只是想趕快實現，不會過多的考慮演算法問題，隨著規模的累積可能會造成了系統的冗餘，軟體運行速度不夠理想。

         這種開發方法正像是我們學生在寫大作業時候採用的方法，在大二下學期的物件導向課程中，一次作業是出租車的調度系統。這個主題連續出了3、4次問題，從開始簡單的搶單，接送乘客需求，增長到了考慮道路交叉路口的紅綠燈以及道路雙向、立交橋問題。因為每次寫作業時下次作業的需求時未知的，而作業的規定完成時間又很短，自己注重更多的是如何完成這個問題。第一次作業在尋路演算法的選擇上選到了相對簡單但是效率不高的Dijkstra演算法，而且沒有進行最佳化，這就導致了之後的幾次作業處理十分麻煩，想要去修改之前的問題卻發現規模太大，或是太懶就沒有進行修改。這造成了之後的作業代碼效率極低，計算時耗時過長。

 

二、敏捷式軟體開發 (Agile Software Development)

         敏捷開發所推崇的是通過減少繁雜的計劃，構造出多樣的環境來簡化事物，這種觀念下有大量不同的方法，技術和實踐。敏捷軟體工程是哲學理念和一系列開發指南的綜合。這種哲學理念在文章開頭有所介紹，這種哲學理念推崇讓客戶滿意的軟體早期的增量發布，小而高度自主的項目團隊，非正式化的方法，最小化軟體工程工作產品以及整體精簡開發。開發的指導方針強調超越分析和設計的發布，以及開發人員和客戶主動和持續的溝通。

         在敏捷開發中Team Dev是由軟體工程師和利益相關者共同組成的，這個團隊掌握著自己的命運，這就要求團隊的成員要相互交流，相互合作。敏捷雖然能夠帶來很多好處，但是從本質上講敏捷開發只是為了克服傳統軟體開發的弱點形成的。敏捷開發不是完全獨立於傳統軟體工程之外。

         正如Best Practices for Large Software Development Projects這本書中所講述的，早在軟體工程的改變之前，傳統工業就有一場革命。豐田汽車提出了持續改進的觀念，使得豐田汽車公司飛速發展，這種觀念的特徵很像是從課本上瞭解到的敏捷開發。它注重的的是小的增幅，涉及到每個人，集體主義，團隊奮鬥，系統方法，強調小的投資但是非常努力維持，向人員傾斜，爭取更好結果的過程。今井正明是這麼描述持續改進方面：1）每天逐步的把小事情做好。2）設定和實現更高的標準。3）對待每個人都像是對待顧客。4）全面的逐步提高。

         正是這種精益生產推動了傳統工業的發展，敏捷開發與這場傳統工業革命有著相似之處，都是注重了人的交流，強調了和小的方面的進步。常見的敏捷開發有極限編程（XP），Scrum，動態系統開發方法，特徵驅動開發。因為從未接觸到這方面的開發工作，知識的獲得僅僅只能通過課本。以極限編程過程為例，包含了策劃、設計、編碼和測試4個架構活動的規則和實踐。2.1所示：

 

 

圖2-1

         對於不同的活動：1）策劃，策劃開始於傾聽，建立一系列使用者需求的“故事”，每個故事都有自己的權值，權值是客戶根據價值標註出來的，開發人員預估成本，當成本超過了3個開發周，故事將進一步細化，新的故事可以在任意時刻書寫。2）設計，嚴格遵循KIS原則，即使用簡單的表述。設計為故事提供了不多也不少的實現原則。3）編碼，在故事開發和初步設計完成後，團隊應當開發一系列用於檢測本次發布的所有故事的單元測試，這樣開發人員就能集中精力於實現內容。在編碼中注重的是結對程式設計，結對的兩個人互相分工。4）測試，在編碼開始之前建立單元測試是XP方法的關鍵因素，這種方式支援代碼修改以後及時的迴歸測試。一旦將個人的單元測試組織到一個“通用測試集”，每天都可以進行系統的整合和確認測試。XP的驗收測試著眼於客戶可見的，可評審的系統級特徵和功能。

         過於教條化的內容也許不是自己在這一周兩周的閱讀中所能體會到，但是通過閱讀和自己的理解，敏捷開發注重開發中人的作用，強調了程式員團隊和利益相關者之間的緊密協作，面對面溝通，頻繁的交付新的軟體版本。這種方法相較於傳統的軟體開發隊伍中的人員高度協作，適用於需求不斷變化的產品。 瀑布模型嚴格遵守了順序執行，使用者可能在開發的前期只能看到一個個文檔，無法看到自己需要的產品是否是Team Dev正在做的。而敏捷開發擅長於及時和客戶交流，是一種周期短的迭代式開發，雖然不重視文檔但是還是有適量的文檔，這些文檔在開始時產生的在不斷的開發中也會隨之變化，指導軟體的開發。更多的是需要團隊成員的交流。

         敏捷開發在我理解裡和傳統製造業中的豐田很相似，明白實現目標的優先順序，當產品經理或者客戶提出需求時開發人員可以互相溝通，能夠明確開發的目標和每個人的任務。面對打的任務要求細化任務，每個人負責一部分，Do little things gradually better every day.開發的時候開發人員因為需求比較細更容易吃透需求，理清邏輯，有問題時能夠及時和同事或者產品的需求人員交流。在開發的過程中負責人員能夠根據任務需要進行人力資源的分配。測試要求了開發一個功能就跟進一個功能的測試，這樣一方面有效解決了問題累積的可能性，另一方面減輕了最後統一測試的壓力。

       但是敏捷開發對於整個團隊的需求會更高，傳統的軟體開發對於制定計劃的人要求比較高，在面對手下的人員良莠不齊的情況下提前制定好了計劃，就不是很需要成員相互交流，這樣水平低的開發人員在開發中只需要做好自己分內的事情就可以了，全部的目標就是完成自己的代碼。如果對於這樣的團隊要求敏捷開發就會出現大牛和水平低的人聊不到一塊，大家注意到的內容不一樣，最後可能無法形成良性的迴圈。對於團隊規模來說一個很龐大的團隊在執行敏捷開發時的難度要高於傳統軟體工程的，如何協調大團隊之間交流成本比大家埋頭苦幹自己分內的事情要大的多。

 

三、總結

         敏捷開發雖然在外表上和傳統軟體工程差別很大，但是敏捷不是萬能的，敏捷開發中也脫離不了傳統軟體工程的精華，相較於傳統軟體工程敏捷開發像是一個走迷宮的小老鼠，每一次在嘗試，都在改變，面對複雜多變的變化能夠不斷修正自己的方向，一步步走出迷宮。傳統軟體工程注重了過程的統一性，要求了階段性，雖然面對變化反應遲緩，開發週期很長，但是對於成員的要求要比敏捷開發低，在固定了開發目標的前提下出錯率更好保證。面對需求越來越多變的當下敏捷開發能夠更好的適應，但是敏捷開發使用的團隊整體素質需求相對高，而且要求差距不能過於明顯。無論是敏捷開發還是傳統開發都各有優劣，選擇團隊最合適的開發方法才能更好的完成任務。

四、參考文獻

[1].Roger S Pressman,軟體工程——實踐者的研究方法（第七版）,機械工業出版社

[2].Thomas Stober;Uwe Hansmann,     Best Practices for Large Software Development Projects ,  Springer Publishing Company, Incorporated, 2010

[3].David Cohen, Mikael Lindvall, and Patricia Costa,Fraunhofer Center Maryland,    Agile Software Development( DACS State-of-the-Art/Practice Report)

[4].淺談敏捷開發與其他傳統開發方式的區別  梁永幸 

[5].敏捷開發之Scrum掃盲篇 Taven.李錫遠 出處：http://taven.cnblogs.com/

敏捷式軟體開發 (Agile Software Development) VS. 傳統軟體工程