何謂敏捷式軟體開發 (Agile Software Development)？與傳統軟體工程的對比

標籤：經驗   擴充   完全   文章   size   智能   服務   沒有   程式員   

大家好，下面的內容將闡述我對于敏捷軟體開發的產生背景、理解以及在實際運用中對于敏捷開發的誤解。如果有理解闡述不正確的地方，歡迎指正！

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

敏捷開發是一種軟體開發方法,基於迭代和漸進式開發,通過自組織,跨團隊,溝通協作完成開發工作。[1]

想必大家會看到過下面這張圖，對於整個龐大的複雜的軟體項目，在背景知識需求瞭解的基礎上，首先要儘可能的將項目進行模組的劃分，並且盡量減少耦合，對於每一個小的模組

進入該部分的衝刺階段，通過不斷的交付可以使用的軟體(可能只有最終所有功能的一小部分)面對面的討論，而給予開發人員正能量的反饋(包括可以運用的小的demo和使用者給的有

效建議)和使用者可以部分使用的軟體產品，從而使得整個開發過程有效而不死板。

誒？照我這麼說，敏捷式軟體開發 (Agile Software Development)讓開發人員和使用者皆大歡喜，以後都用敏捷式軟體開發 (Agile Software Development)好啦？

其實，敏捷式軟體開發 (Agile Software Development)對於開發人員本身的經驗素質要求比較高，如果不是一個條理很清晰以及有經驗的項目開發人員，恐怕很難做到抽取使用者需求（很多時候，使用者對於自己的需求是表

達不清楚滴~），並將項目有效劃分的。

 

 

敏捷式軟體開發 (Agile Software Development)有一個宣言和12條準則，大家可大概看一下12條準則好對敏捷式軟體開發 (Agile Software Development)的具體有個瞭解，我們詳細闡述對於宣言不等式的理解。

敏捷開發的12條準則

 

這個連結中有詳細的對於12準則的闡述 http://blog.csdn.net/joeyon1985/article/details/42266135  ，目前給我們的感覺是，這是我們一個強大的團隊，具有主動性，可以

不斷的交付部分功能的產品，並能調整好團隊狀態接受建議和未知的改變。

 

敏捷式軟體開發 (Agile Software Development)宣言 

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

工作的軟體 高於 詳盡的文檔

客戶合作 高於 合約談判

響應變化 高於 遵循計劃

O(∩_∩)O~ 接下來是對于敏捷軟體開發宣言這四個不等式的理解，首先請允許我強調一下：

1.敏捷式軟體開發 (Agile Software Development)！= 快速完成項目

　　只要你的老闆一天還覺得敏捷就是快，我覺得這發展情況就一天好不起來。

　　敏捷式軟體開發 (Agile Software Development)是面對複雜長期的項目，具有可擴充性的開發方式，實現的是全域最優，而不是局部最優哦~

2.右邊比左邊更重要，但不代表左邊的方法不好

　　左邊右邊是指敏捷式軟體開發 (Agile Software Development)宣言中的四個不等式，即 個體和互動 > 流程和工具 等。左邊和右邊的準則只不過是在不用量級的項目背景下的選擇而已，沒有好與壞！

3.強調面對面交流！=沒有開發文檔

　　任何事情都請不要理解的辣麼絕對嘛~

4.長期開發實踐項目！長期開發實踐項目！長期開發實踐項目！

• 個體和互動 > 流程和工具　　

　　人是一種需要持續能看到行動的正反饋的動物，只有持續地有正反饋人才能堅持重複一個過程。嗑瓜子就是持續有正反饋，長期學習計劃之所以很難堅持也是因為沒有足夠快的

正反饋。[2]想想你更願意在有小小成就感和正能量的環境下努力完成任務，還是強大壓力看不到進展的模式下前行？

　　敏捷編程就是想辦法製造儘可能快的正反饋給程式員，這樣他們不至於很快疲掉，以至於沒有人想繼續工作在這個項目上了。

　　敏捷開發強調把關注點迴歸到“人”上，其背後的哲學思想可追溯到康德的“人即目的”。

　　同時，主張面對面交流和客戶參與開發, 彌補了缺少文檔而產生資訊流通不暢問題, 認為開發人員之間、開發人員和客戶之間相互協作、相互信任、彼此尊重是保證溝通成功的

必要條件。但注意，敏捷式軟體開發 (Agile Software Development)重視面對面對於項目的討論，但不是不需要文檔。敏捷開發不是沒檔案沒流程的封裝紙。

　　背後的現實——開發過程中的人力資本的高企。 　　一個典型的項目花在人力上的金錢是花在硬體上的時間的20 倍, 這意味著一個項目每年要花2 0 萬美元在程式員身上, 而僅僅花10 萬美元在電腦裝置上。很多聰明的程式員說:“ 我們如此聰明, 發現一種方法可以節省20%的硬體開銷” , 然後他們使得來源程式大且難懂和難以維護, 他們會說: “ 但是我們節省了20%或者2 萬美元每年, 很大的節省” 。但財務事實告訴我們，如果程式簡單而且容易擴充,我們將至少節省10%的人力開銷，這將是一筆更大的節省。同時，軟體開發的職業本身也決定了數量少但精乾的團隊的效率與產出大於臃腫、混亂的大團隊。敏捷開發一般適用於20-40人、甚至更少。

• 可以工作的軟體 > 面面俱到的文檔

　　區別於傳統的軟體開發模式，客戶只有在系統被開發完成以後才能真正去體會它。敏捷編程通過要求不斷交付可用的軟體, 周期越短越好，加強客戶的反饋來縮短開發的周期, 同時獲得足夠的時間來改變功能和獲得使用者的認同。但並不是要求你快速的完成整個項目，開發人員不要有太大壓力，因為可工作的軟體是想要給你小小的成就感，面對面的交談是想給你更加直接有有效反饋。

　　背後的現實——“快魚吃慢魚”的競爭模式。
　　區別於工業社會的利用流水線、規模化的生產模式，資訊時代更強調對使用者需求的快速響應。標準化生產所帶來的低成本、高可靠性的特點不能直接保證市場的高份額。相反，對使用者需求的細膩把握和快速響應卻是以使用者為導向的服務型公司的生命線！

• 客戶合作 > 合約談判

 

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

　　背後的現實——使用者無法對其自身需求進行有效描述
　　誠然，在實際項目開發過程中，使用者是無法對自身的需求進行有效描述，這一點如果有失敗，將會導致最終的產品不可能完全滿足客戶需求。最經典的例子莫過於蘋果的iPad、iPhone了。在喬布斯沒有推出iPhone之前，使用者是不知道他們需要智能機，更準確地來說就是無法對智能機的需求進行有效描述的。這也就是為什麼諸如諾基亞、摩托羅拉等公司失敗的原因之一。他們不是沒有市場部門，不是沒有進行市場調研、使用者需求分析，問題在於一般使用者在缺乏相關知識與指導的情況下是無法對自身需求（特別是潛在需求）進行有效描述。這一缺陷在市場競爭隨著節奏的加快顯得愈發致命！

 

• 響應變化 > 遵循計劃

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

　　背後的現實——試錯成本低、執行力要求高
　　現代社會最重要的特點就是多元化，用所謂的“互連網思維”說就是“去中心化”，具體到個人應該就是 Open mind。這一社會現實反應在軟體開發上就是 試錯成本變得相當較低。但與此同時，快速變化的商業大環境也對執行力提出了高要求，而執行力的關鍵計量就是對變化的快速響應！  寫在最後的話 實際上，敏捷式軟體開發 (Agile Software Development)方法對“人”提出要求，需要思維模式和價值觀的支撐，才能真正理解並運用“敏捷”方法。在《管理3.0》一書中，作者Jurgen Appelo給出了一個具有六隻眼睛的異形生物，並取名為“Martie”，代表了運用“敏捷”方法的人應該所具備的六種思維模式，如的“六眼怪”，所以要實現敏捷式軟體開發 (Agile Software Development)的路還很長。

 

引用文獻

[1].http://www.cnblogs.com/kkun/archive/2011/07/06/2099253.html 敏捷式軟體開發 (Agile Software Development)

[2].http://www.zhihu.com/question/23429937 什麼是 Agile Software Development（敏捷式軟體開發 (Agile Software Development)）

另附對于敏捷軟體開發反對的一篇文章 http://www.woshipm.com/zhichang/160479.html 為什麼我不推薦敏捷開發？

 

何謂敏捷式軟體開發 (Agile Software Development)？與傳統軟體工程的對比