敏捷軟件開發VS傳統軟件工程

軟件工程的概念早在1968年便被提出，一路發展至今，也演變爲了一門學科，而其中的方法也是層出不窮。這裏，咱們便討論一下敏捷軟件開發與傳統軟件工程的異同。說到敏捷軟件開發，其實很早便有這類方法在實踐中運用了，不過在2001年，一些牛人搞出了一個「敏捷宣言」，今後便明確了敏捷軟件開發的方法。

個體和互動：高於 流程和工具。

工做的軟件：高於 詳盡的文檔。

客戶合做：高於 合同談判。

響應變化：高於 遵循計劃。

 

對咱們而言，最重要的是經過儘早和不斷交付有價值的軟件知足客戶須要。

咱們歡迎需求的變化，即便在開發後期。敏捷過程可以駕馭變化，保持客戶的競爭優點。

常常交付能夠工做的軟件，從幾星期到幾個月，時間尺度越短越好。

業務人員和開發者應該在整個項目過程當中始終朝夕在一塊兒工做。

圍繞鬥志高昂的人進行軟件開發，給開發者提供適宜的環境，知足他們的須要，並相信他們可以完成任務。

在開發小組中最有效率也最有效果的信息傳達方式是面對面的交談。

能夠工做的軟件是進度的主要度量標準。 敏捷過程提倡可持續開發。出資人、開發人員和用戶應該老是維持不變的節奏。

對卓越技術與良好設計的不斷追求將有助於提升敏捷性。

簡單——儘量減小工做量的藝術相當重要。

最好的架構、需求和設計都源自自我組織的團隊。

每隔必定時間，團隊都要總結如何更有效率，而後相應地調整本身的行爲。

 

敏捷軟件開發又是在何種背景下產生的呢？

 

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

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

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

 

那敏捷軟件開發又是如何運做的呢？

 

個體和交互 賽過 過程和工具

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

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

 

能夠工做的軟件 賽過 面面俱到的文檔

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

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

 

客戶合做 賽過 合同談判

敏捷開發要求在項目過程當中，業務人員與開發人員必須在一塊兒工做，參與開發，採用高效信息的交互平臺以及可以減小歧義溝通和交流的方式進行支持。敏捷方法完成了從重視文本到重視對話，從重視書寫到重視理解的轉換。

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

 

響應變化 賽過 遵循計劃

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

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

 

說到底敏捷軟件開發即是適應現實社會的一種軟件工程方法，我想咱們也不能把精力侷限於文檔，侷限於我的，咱們也應從敏捷軟件開發中學到咱們做爲社會的一份子怎樣更好地融入現實社會。

 

[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]專題討論做業提示