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

標籤：網路伺服器   轉換   而且   這一   pen   流程   blog   指標   執行   

軟體工程的概念早在1968年便被提出，一路發展至今，也演變為了一門學科，而其中的方法也是層出不窮。這裡，我們便討論一下敏捷式軟體開發 (Agile Software Development)與傳統軟體工程的異同。說到敏捷式軟體開發 (Agile Software Development)，其實很早便有這類方法在實踐中運用了，不過在2001年，一些牛人搞出了一個“敏捷宣言”，從此便明確了敏捷式軟體開發 (Agile Software Development)的方法。

個體和互動：高於 流程和工具。工作的軟體：高於 詳盡的文檔。客戶合作：高於 合約談判。響應變化：高於 遵循計劃。

 

對我們而言，最重要的是通過儘早和不斷交付有價值的軟體滿足客戶需要。我們歡迎需求的變化，即使在開發後期。敏捷過程能夠駕馭變化，保持客戶的競爭優勢。經常交付可以工作的軟體，從幾星期到幾個月，時間尺度越短越好。業務人員和開發人員應該在整個項目過程中始終朝夕在一起工作。圍繞鬥志高昂的人進行軟體開發，給開發人員提供適宜的環境，滿足他們的需要，並相信他們能夠完成任務。在開發小組中最有效率也最有效果的資訊傳達方式是面對面的交談。可以工作的軟體是進度的主要度量標準。 敏捷過程提倡可持續開發。出資人、開發人員和使用者應該總是維持不變的節奏。對卓越技術與良好設計的不斷追求將有助於提高敏捷性。簡單——儘可能減少工作量的藝術至關重要。最好的架構、需求和設計都源自自我組織的團隊。每隔一定時間，團隊都要總結如何更有效率，然後相應地調整自己的行為。

 

敏捷式軟體開發 (Agile Software Development)又是在何種背景下產生的呢？

 

隨著軟體行業發展壯大，軟體系統的規模也越來越大，複雜程度越來越高，開發週期與開發成本便面臨極大的挑戰，與此同時，軟體的可靠性也無法很好的保證。為解決這一系列問題，軟體行業便開始借鑒傳統的工程學、管理學方法。

以“瀑布模型”為代表的傳統軟體開發模型開始出現，它們針對軟體生命週期的各個階段提供了一套規範，以期使工程的進展達到預期的目的。核心強調在軟體開發活動中，所有的活動計劃，排程，交付工作都要直接或間接的和需求保持一致，同時強調軟體需求必須形成“文檔”。最初的軟體(20世紀60-70年代)的顧客都是大型研究機構，軍方，NASA這些，他們需要軟體系統來搞科學計算，軍方項目，和登月項目等，這些系統相當龐大，對準確度要求相當高。20世紀80年代到90年代中，軟體進入了案頭軟體的時代，開發的周期明顯縮短，各種新的方法開始進入實用階段。但是軟體發布的媒介還是磁碟片，CD，DVD，做好一個發布需要較大的經濟投入，不能頻繁更新版本。互連網時代，大部分的服務是通過網路伺服器端實現，在用戶端有各種方便的推送(push)渠道。由於網路的轉播速度和廣度，知識的擷取更加容易，很多軟體服務可以由一個小團隊來實現。同時技術更新的速度在加快，那種一個大型團隊用一個固定技術開發2-3年再發布的時代已經過去了。使用者需求的變化也在加快，開發流程必須跟上這些快速變化的節奏。

這種基於計劃的生命週期的軟體開發方法曾極大地促進了軟體行業的發展，但現如今卻並不能很好的適應社會。為了適應現代的商業環境，與之對應的敏捷式軟體開發 (Agile Software Development)方法提了出來。

 

那敏捷式軟體開發 (Agile Software Development)又是如何運作的呢？

 

個體和互動 勝過 過程和工具

其實便是更注重人與人的交流，而不是文檔的約束。敏捷開發強調把關注點定位到“人”上，其背後的哲學思想可追溯到康德的“人即目的”。同時，主張面對面交流和客戶參與開發，彌補了缺少文檔而產生資訊流通不暢問題，認為開發人員之間、開發人員和客戶之間相互協作、相互信任、彼此尊重是保證溝通成功的必要條件。

看似一個深奧的演算法可以節省很多硬體上的壓力與花銷，但在現今這種人力花銷更加巨大的環境，易讀易擴充的程式節省的人力將為公司帶來更多利益。很多聰明的程式員也許可以發現奇妙的方法節省20%的硬體開銷，然而他們使得來源程式難懂並且難以維護，表面上他們節省了許多硬體的開銷。但財務事實告訴我們，如果程式簡單而且容易擴充，我們將至少節省10%的人力開銷，這將是一筆更大的節省。同時，軟體開發的職業本身也決定了數量少但精乾的團隊的效率與產出大於臃腫、混亂的大團隊。敏捷開發一般適用於20-40人、甚至更少。

 

可以工作的軟體 勝過 面面俱到的文檔

區別於傳統的軟體開發模式，客戶只有在系統被開發完成以後才能真正去體會它。敏捷編程通過要求不斷交付可用的軟體，周期越短越好，加強客戶的反饋來縮短開發的周期，同時獲得足夠的時間來改變功能和獲得使用者的認同。

可用的軟體可以讓客戶更直觀的提出更多建議與需求，區別於工業社會的利用流水線、規模化的生產模式，資訊時代更強調對使用者需求的快速響應。標準化生產所帶來的低成本、高可靠性的特點不能直接保證市場的高份額。相反，對使用者需求的細膩把握和快速響應卻是以使用者為導向的服務型公司的生命線。

 

客戶合作 勝過 合約談判

敏捷開發要求在項目過程中，業務人員與開發人員必須在一起工作，參與開發，採用高效資訊的互動平台以及能夠減少歧義溝通和交流的方式進行支援。敏捷方法完成了從重視文本到重視對話，從重視書寫到重視理解的轉換。

很簡單的道理，那便是使用者無法對其自身需求進行有效描述。就像iPhone，在喬布斯沒有推出iPhone前，使用者並不知道他們需要智能機，更準確地來說就是無法對智能機的需求進行有效描述的，他們不知道他們想要觸屏，想要在手機上做什麼，換句話說其實是使用者並不知道什麼可以實現，什麼無法實現，怎麼樣的實現會有一個良好的化學反應。這也就是為什麼諸如諾基亞、摩托羅拉等公司失敗的原因之一。他們不是沒有市場部門，不是沒有進行市場調研、使用者需求分析，問題在於一般使用者在缺乏相關知識與指導的情況下是無法對自身需求進行有效描述。這一缺陷在市場競爭隨著節奏的加快顯得愈發致命。

 

響應變化 勝過 遵循計劃

敏捷開發的口號是擁抱變化，即歡迎對需求提出變更，甚至是在項目開發後期。要善於利用需求變更，協助客戶獲得競爭優勢。

資訊世界發展如此之快，創業公司更是數不勝數，一個想法的成功，勢必會帶領一個熱潮，佔得先機才能得到更多利益。現代社會最重要的特點就是多元化，用所謂的“互連網思維”就是“去中心化”，具體到個人應該就是Open mind。這一社會現實反應在軟體開發上就是 把想法變成實際的成本變得相當較低。但與此同時，快速變化的商業大環境也對執行力提出了高要求，而執行力的關鍵計量就是對變化的快速響應。

 

說到底敏捷式軟體開發 (Agile Software Development)便是適應現實社會的一種軟體工程方法，我想我們也不能把精力局限於文檔，局限於個人，我們也應從敏捷式軟體開發 (Agile Software Development)中學到我們作為社會的一份子怎樣更好地融入現實社會。

 

[1] https://zh.wikipedia.org/wiki/%E6%95%8F%E6%8D%B7%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91 維基百科

[2] http://www.cnblogs.com/xinz/archive/2011/04/27/2031118.html 部落格園 博文

[3]專題討論作業提示

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