敏捷開發與瀑布開發相比有什麼優勢？
用兩個詞吧，一個是擁抱變化，一個是進度可視。
1.任何軟體類系統或項目，即使你前期花在需求上的時間足夠長，你也很難在需求階段真正的分析和挖掘出所有的需求。有些需求註定會在設計實現或用戶使用過程中才逐漸出現。要承認軟體開發中存在這種不確定性。而瀑布模型將這種識別變化延遲到最好的測試或用戶使用階段才發現，極大的增加了返工或變更成本。敏捷思想裡面通過短周期迭代，儘可能早的交付可用的迭代版本來擁抱和適應變化。
2.任何一個軟體項目，需求或設計做完我們並不清楚進度是否真正完成了60%或者更多，任何不是經過測試通過的功能我們都很難把握真正的完成進度情況。因此在敏捷裡面換了一種思路，如講這個項目拆分為100個粒度差不多的功能點，如果有60個功能點全部完成並通過驗證和測試，我們就比較有把握說整體進度完成了60%。這種可視化的評估進度模式在瀑布裡面較難以做到。
其它的優勢就太多了，可以仔細看敏捷方法論和思想，在這些裡面最重要的又是從方法和工程轉到對人主觀能動性，溝通和協同交互，自適應的關注。唉，有人總認為某一個就一定適用於一切，A就一定比B強。事實上，真得不是如此。每一種過程論（瀑布、迭代、螺旋、敏捷——在這裡討論的敏捷，都屬於過程模型），都有其適用的場景，拋開場景盲目的談優點和缺點，完全就屬於非理性的言論，不應該得到支持的。我不知道上面這些專家為什麼這麼熱衷於在這種不確定的情況下的優劣評價，難道多年的開發經歷，不能夠讓你們真正體會到過程與項目之間的適用關係么？難道非要拿著步槍當鋤頭，才覺得這樣耕地比較高大上么？確實，現在大多數項目的變更頻繁，需求不確定，但是有沒有人反思過，需求不確定和頻繁變化可能來源於你的技術人員不專業無法深度挖掘到用戶的實際需求呢？不要盲目的說用戶的實際需求第一次是一定挖掘不到的——這樣的言論本身就代表著不負責任。為什麼非要做如此盲目的定義，你是覺得自己或者自己團隊的技術人員不夠專業，不適合做這個方向么？妄自菲薄和盲目自大以及故作深沉，都是不利於事務展現它原本面目的做法。客觀的看待，冷靜的分析，認真地處理，這樣的行為才能讓事情和問題得到恰當的解決，而不是直接定義某個一定比另一個好。
周日剛好去中關村聽了格知CEO叉小包的分享，分享里叉小包老師說了到敏捷開發，講得十分透徹，讓我對敏捷開發有更深層的理解。下面是叉小包老師關於敏捷開發的部分分享筆記：
----------------------------------------------
我個人認為敏捷最大價值是什麼？8個字，避免浪費走向精益。我們先說說避免浪費。首先要回顧一下歷史，敏捷，軟體開發歷史很長，敏捷思想出現很晚，我們不妨來回顧一下，這個軟體研發的思想史，歷史上都出現過哪些。首先敏捷也好，復古流人類管理生產活動的理念，我們上一代或者再上一代，爺爺奶奶，覺得工廠工人是很光榮的，在流水線里上班。流水線是什麼概念？其實就是大規模的人聚集在一起協同工作，他已經擺脫了簡單小作坊。這張圖你看是什麼圖？汽車流水線，最早的福特發明汽車以後開始了大規模工業生產。汽車流水線發現什麼？有什麼特點？這個旁邊堆了很多輪胎，這個環節的工人根本不了解上一個環節的工人做什麼。軟體開發是智慧型生產，智慧型生產之前是大工業生產，所以現在管理理念是從過去傳統製造業來。
製造業管理理念，20世紀有一次重大飛躍，豐田生產體系，就是TPS。小日本二戰以後發展汽車，覺得要跟美國學，豐田有一考察團到美國去，看到了類似剛才那張照片，實際上堆放得很亂，沒有他們想像中好，這時候他們到工廠旁邊便利店很受啟發，便利店裡不堆貨，不做自己的倉儲，他們覺得這個東西很靈活，忽然受到啟發，這個環節要堆放這麼多的輪胎，一條生產線一天生產多少車，你知道，你這裡堆的輪胎是兩個月用不完的輪胎，你堆在這裡就要有人管理，還得清點、搬運過來組裝。在日本人看來，這種過程是浪費的，大家通過這一點出發發展出一整套的管理汽車流水線的體系，就把流水線生產每一個環節有浪費總結起來，從這幾個點避免浪費，他們提出七個浪費是哪七個。
1、庫存，不直接生產價值，並增加管理成本。
2、返工，上一個流程交付不可用。
3、過度生產，生產多餘所需。
4、搬運，本來就擺放錯的資源。
5，多餘動作，任何不增加價值的設備和人員的動作。
6、過程不當，對最終產品不能增加價值的活動。
7，等待，兩個關聯要素不能同步。
我們看7種浪費，是不是感覺跟軟體研發已經有點像了，你們流程研發裡面，產品經理定義一個功能，最後上線這個過程裡面你們反思一下有沒有浪費，有沒有類似情況？我相信類似情況是有的。再回顧軟體研發歷史，互聯網研發模式從產品經理到程序員到最後上線這個過程，時間也不長，是很年輕的體系。
你們流程研發裡面，產品經理定義一個功能，最後上線這個過程裡面你們反思一下有沒有浪費，有沒有類似情況？我相信類似情況是有的。再回顧軟體研發歷史，互聯網研發模式從產品經理到程序員到最後上線這個過程，時間也不長，是很年輕的體系。
敏捷真正價值是什麼？如果你在做一件創新的事情，只有敏捷能幫你把這件事情做好，為什麼？因為你需求是無限的。傳統軟體開發流程跟傳統工業流程是一樣，初始條件，一連串線性流程，明確目標。實際上是已驗證的需求，瀑布流，清晰、準確可預估，你們目標提出來模式是按這個模式來提的，這些時間這些人肯定能做到。
---------
感謝PMCAFF產品經理社區組織活動這次活動和提供筆記，很贊!
兩者各有什麼優勢？
這問題寫得貌似像在挑選午餐的地點，西餐或中餐，兩者各有什麼優勢？
實在對不起，有很多東西不是我們想要就能有的，瀑布是否你想做就能做到、也能夠產生效果我不知道，但我很肯定地知道，敏捷絕對不是你今天想要明天就能夠做到、更不是能夠立刻產生效果的。
敏捷和瀑布更多的是一種思維的變化，如果思維沒有轉變，你就想像一下，雙手十指交叉的時候，挪動一下大拇指的位置，感覺如何？在從傳統瀑布方式走向敏捷方式的時候，會有非常多的不適應和「老方法不是蠻好的么」的瞬間，克服他們，才能得到優勢。
優勢是什麼？
優勢就是，對於現代更佔主導地位的軟體開發類型來說，敏捷才是更適合它們的方法。當然了，更適合瀑布方法的軟體開發類型或許仍然存在，但如果敏捷方法同樣也能夠適合這種開發的話，瀑布還有什麼優勢呢？
最後一句，還有「真的」瀑布開發么？
第三方業務風險控制服務行業目前還沒有發展出固定的行業標杆，大家都在競爭中追求最大範圍的滿足行業需求。在這樣的背景前提下，大部分項目都沒有明確和長久穩定的需求。但是，作為行業客戶，在大部分的商務場景下客戶都會希望通過固定成本合同來實現自己的利益最大化，問題是現在合同雙方都很難在項目開始時明確約定需求和最終實現方式。
我認為，在客戶不能接受 Scrum 時，通常選擇外瀑布內敏捷的項目管理模式較好，滿足雙方的利益。
2、舉例：
如果把拍婚紗照作為一個項目，攝影師和新人作為項目主要成員，項目基本流程滿足：
- 選婚紗照的套餐（固定成本，確定基本需求）
- 拍攝（項目啟動）
- 挑照片（提交測試，開始驗收）
- 根據底片修圖（修復）
- 拿到照片（項目結束）
&>&>&>&>以上就是順序執行，瀑布式的結果。
然而，拍攝的過程中新人通常都會要求：
- 較短短時間內提出新增造型、內景換外景的要求（切換pose的任務）
- 配合攝影師完成拍攝環節的工作（通過迭代，完成項目）
&>&>&>&>以上就是內部快速迭代，敏捷式的結果。
很顯然，新人在拍婚紗照之前並不知道自己最終拿到的照片穿的會是哪套衣服，擺的會是哪個pose；但是，很清楚的是哪天拍照、哪天挑照片、哪天可以拿到照片，這套流程同時滿足了內部和外部需求。
只是，為了項目順利結束，可能在內部和外部需求時，並沒有要求完全以相同的速度前進，就像你不能以你配合完成攝影的速度去要求攝影樓馬上提供婚紗照。
第三方業務風險控制服務企業產品服務流程
其實，作為第三方風控服務的企業，我們的項目服務流程基本上和拍婚紗照一樣，更靈活的是在選擇套餐前，我們提供了免費測試環節，基本流程滿足：
第三方業務風險控制服務行業目前還沒有發展出固定的行業標杆，沒有一套可稱為標準的、行之有效的流程打通各個環節。更重要的問題——合同雙方都很難在項目開始時明確約定需求和最終實現方式。在市場經濟不斷發展、時刻變化的現代互聯網環境下，適應變化、擁抱變化的第三方業務風控服務企業的項目管理，才是友好的、可行的管理模式。
某博主po的一個很有趣的「敏捷和瀑布」對比例子，給大家作為閱讀參考：
（以下為轉載內容，僅為參考用）
1、敏捷開發
- 客人到餐館來點菜（新項目）
- 不確定客戶想吃什麼的時候，通常選好餐廳後會先看看餐廳的菜單（客戶往往提不出具體的需求）
- 根據圖文菜單，客人點了是個菜（根據原型和設計稿，基本確定了需求）
- 後廚開始準備（項目啟動）
- 配菜、炒菜，先上了兩盤，讓客人嘗了嘗味道（先提供可用實例給客戶用）
- 客人說還不錯，後廚繼續準備後面的菜，陸續上菜（不斷迭代，不斷測試）
- 上菜過程中，客人突然發現有個菜的味道太淡了，讓後廚加了點鹽又端上來了（敏捷的好處，可以不斷測試和需求變更）
- 又上了兩盤，不夠辣，又拿到後廚加了辣（敏捷的壞處，需求沒有提前明確，反覆迭代，增加了工作量）
- 到最後兩盤時，客人要求換兩個菜，還好沒炒（迭代的好處，隨時接受需求變更）
- 客人吃完，很滿意（基本滿足了全部的要求）
·
2、瀑布模型開發
- 客人到餐館來點菜（新項目）
- 不確定客戶想吃什麼的時候，通常選好餐廳後會先看看餐廳的菜單（客戶往往提不出具體的需求）
- 根據圖文菜單，客人點了十個菜（根據原型和設計稿，基本確定了需求）
- 後廚開始準備（項目啟動）
- 根據客人的下單配菜，炒菜（基本上不會主動去了解完整需求）
- 半個小時了，菜還沒上桌，客人餓極了（項目啟動後很長一段時間客戶什麼都看不到）
- 再過了二十分鐘，十個菜都一起上來了（項目最終一次交付）
- 客人說，有幾個菜挺好的，但是有個菜味道淡了，有兩個不夠辣，還有兩盤重複了想換掉（我是買單的，我要變需求）
- 這時候大堂經理來了，說，「味道淡了可以加鹽，不辣可以加辣，但是換菜不行，已經炒好的那兩盤菜也是要算成本的」（瀑布的壞處，需求變更比較麻煩）
- 於是，後廚只給客戶加了鹽，加了辣
- 客人吃完，不是很滿意，下次不來了（沒有滿足需求）
個人認為，目前的敏捷開發，無非是分階段的瀑布開發而已。每一次迭代都是一次瀑布開發。相比之下，頻繁交付帶來的是對需求的不斷修正，最後交付的時候，用戶是可以接受的。但是這種敏捷開發的適用場景大多是從無到有，從零做起的新項目。
並不是所有項目都適合敏捷。
-------------update/04/19/2014-----------吐槽下敏捷開發。無非是需求不明確，卻又想做出讓客戶滿意的產品。敏捷開發，可能大家關注的是先把東西做出來，交付或者上線，在實際場景中去修改彌補需求中的不足，快速修改，再次發布版本。再次上線或者交付。如此循環，直到用戶（客戶）滿意。適用於需求不明確的項目、創新性的項目或者需要搶佔市場的項目
瀑布式開發，要求明確的需求，大家按照需求一步步做好規劃，在項目運作過程中嚴格產出各種文檔，按著流程一步步走下去。這種模式一般適用於需求比較明確、to B端項目
但總的來說，在現在管理項目過程中，並沒有嚴格的按照完全的敏捷或者完全的瀑布模式，都是各自摻雜了其他的方式。在實際項目過程中，過於強調模式並沒有意義，重要的是能不能預防問題的發生，在問題發生之後能不能用最小的成本解決，模式更多起一個參考作用
最後借用民國時候的一句話：少研究一些主義，多關注一些實際問題
一點點個人見解，歡迎討論
工作強度更高
原文來自這裡:
敏捷開發與瀑布開發相比有什麼優勢? | Teambition知識文檔
敏捷開發與瀑布開發相比主要有兩個優勢, 用兩個詞吧，一個是擁抱變化，一個是進度可視。
1.任何一個軟體項目，需求或設計做完我們並不清楚進度是否真正完成了60%或者更多，任何不是經過測試通過的功能我們都很難把握真正的完成進度情況。因此在敏捷裡面換了一種思路，如講這個項目拆分為100個粒度差不多的功能點，如果有60個功能點全部完成並通過驗證和測試，我們就比較有把握說整體進度完成了60%。這種可視化的評估進度模式在瀑布裡面較難以做到。2.任何軟體類系統或項目，即使你前期花在需求上的時間足夠長，你也很難在需求階段真正的分析和挖掘出所有的需求。有些需求註定會在設計實現或用戶使用過程中才逐漸出現。要承認軟體開發中存在這種不確定性。而瀑布模型將這種識別變化延遲到最好的測試或用戶使用階段才發現，極大的增加了返工或變更成本。敏捷思想裡面通過短周期迭代，儘可能早的交付可用的迭代版本來擁抱和適應變化。
與傳統方法相比，敏捷具有明顯的優勢，包括更大的靈活性和穩定性、更少的非生產性工作、更快的高質量交付、更高的開發團隊績效、更嚴格的項目管理控和更快的失敗檢測
瀑布VS敏捷
古代婚姻VS現代婚姻
古代婚姻：父母之意，媒妁之言。在婚前，經過媒人的接觸，彼此雙方的父母了解了彼此的家庭背景、孩子的長相和品性，自家孩子的意願，等等。如果合適，那就定下這門親事，然後開始準備婚禮，等等。
在洞房花燭夜之前，彼此是不能見面的。
現在婚姻：從彼此認識的那一刻起，就通過彼此約會，相互了解。中間經歷磨合、吵架、分手，最終找到合適自己的伴侶。
用兩個詞吧，一個是擁抱變化，一個是進度可視。
1.任何軟體類系統或項目，即使你前期花在需求上的時間足夠長，你也很難在需求階段真正的分析和挖掘出所有的需求。有些需求註定會在設計實現或用戶使用過程中才逐漸出現。要承認軟體開發中存在這種不確定性。而瀑布模型將這種識別變化延遲到最好的測試或用戶使用階段才發現，極大的增加了返工或變更成本。敏捷思想裡面通過短周期迭代，儘可能早的交付可用的迭代版本來擁抱和適應變化。
2.任何一個軟體項目，需求或設計做完我們並不清楚進度是否真正完成了60%或者更多，任何不是經過測試通過的功能我們都很難把握真正的完成進度情況。因此在敏捷裡面換了一種思路，如講這個項目拆分為100個粒度差不多的功能點，如果有60個功能點全部完成並通過驗證和測試，我們就比較有把握說整體進度完成了60%。這種可視化的評估進度模式在瀑布裡面較難以做到。
其它的優勢就太多了，可以仔細看敏捷方法論和思想，在這些裡面最重要的又是從方法和工程轉到對人主觀能動性，溝通和協同交互，自適應的關注。
了解詳情：敏捷說明會
如今人人都在談敏捷，輕便的管理模式讓更多的企業願意進行嘗試，為何會拋棄傳統的瀑布開發模式，其本質還是瀑布式開發存在一些弊端，接下來和大家解析：為什麼瀑布式開發的小船說翻就翻。
各類大中小型企業所運用的傳統軟體構建方法，即是眾人皆知的「瀑布」型開發方法。此模型存在很多變體，但其典型性是在開發初期制定詳細的計劃，在計劃中最終產品己被仔細研究，設計，並且一切詳細資料都記錄在案。
任務已設計制定，並且在工作中使用如Gantt (甘特)圖表等工具和Microsoft Project項目管理軟體。開發團隊預計開發項目的時間是以累計其相每關一步驟而得出的。當項目管理者(stakeholder)全面審核開發計劃並表示贊同，開發團隊即時開始工作。團隊成員完成他們所專長的部分工作，即刻轉交給其他成員，形成生產流水線的形式。當全部工作都已完成，成品將會轉交給產品質量控制部門，在這裡將會進行在產品到達客戶手中之前的全面檢測。在整個流程中，所有相對於原始計劃的分歧都將受到嚴格的控制，以保證生產的成品與原始設計保持一致。
此種模式有優點但也有不足之處。它的最大的優點是非常有邏輯性：在構建之前思考，並全部記錄下來，按照計劃實施，保持各項事務儘可能的有組織性。它有一個最大的弱點就是：人的參與。
比如：此種方式要求所有的建議和想法都要在開發周期的起始階段提出，此時建議和想法將可以被融入開發計劃之中。但是眾所周知，好的想法和建議的出現會貫穿整個開發過程——在開發啟始階段，在開發中期，有時可以在產品交付使用的前一天，如果整個開發過程中不容許變化的產生，那麼將會遏制創新的產生。在使用「瀑布」型開發方式時，開發末期出現的創新將不是好的徵兆，而是對整個產品開發產生的危機。
瀑布型開發方式特別注重將事件記錄在案，以此作為傳遞重要信息的首要方法。因此合理的假定是如果我可以把我的想法儘可能都記錄下來，這樣將會使信息更可靠的傳輸到團隊每一個成員的頭腦中；另外，因為所有東西都記錄在案，這將是我完成任務的實際的證據。但是實際上，在大多數情況下，沒人會讀這些50頁左右的詳細規格要求資料。同樣，如果有人讀取該資料，那麼將會產生許多的誤解。記錄的資料只是我頭腦中想法的抽象提取；當你閱讀此資料時，你將會產生另一個抽象的概念，此時與我的真正想法已經相距甚遠了。所以嚴重誤解的產生也就不足為奇了。
當人參與時,還有一種情況會發生——「實際應用中產生的靈感」——在第一次實際應用產品時，你可能會立刻產生20種使產品更加完美的靈感。但是遺憾的是，這些非常有價值的想法通常會在產品開發的末期產生，這時創新是困難和具有分裂性的——換句話說，是做正確抉擇昂貴的時刻。
人的預知未來的能力是有限的。比如，某場比賽的終結果是出人意料的。不可預測的技術問題的突然出現，會強制開發方向的轉變。此外，人們往往非常欠缺對於未來作出長遠計劃的能力——今天猜測未來八個月中每周你如何工作將如幻覺般渺茫，這正是Gantt (甘特)圖表的衰敗表現。
另外，瀑布型方式將會促使團隊成員在交接工作時產生敵對的關係。「他要求我構建在規範要求中不存在的東西。」「她經常改變主意。」「我不可能對我不能控制的東西負任何的責任。」這些都引起我們對瀑布方式的另一種思考——在此種方式中工作毫無興趣可言。事實上，進一步說，瀑布型方式是造成產品開發人員苦惱的根源，並且最終產品將不會體現出他們的創造力，技能和開發創造者的激情。人不是機器人，此種將人認為是機器人的流程將會造成人們工作激情的喪失。
一個僵硬的，拒絕變革的流程也會造成低劣產品的產生。客戶可能會得到根據他們第一需求所生產的產品，但是產品在形成階段時還是客戶真正需要的嗎？在開發之前收集所有的需求並將它們嵌入毫無改變可言的頑石般的計劃中，此產品將被宣告只會和起始的想法保持一致，而不是開發團隊在實踐中不斷發現可能性而使其盡善盡美。
許多使用瀑布型方式的團隊不斷的體驗到了它的缺陷，但是它看起來是如此富有邏輯性的方式，因此第一的自然反應就是對內部工作的譴責：「如果我們嘗試更好的使用它，它將會發揮作用」——如果我們計劃的更詳盡，記錄更詳細，更嚴格的拒絕任何變革，一切將會很順利地進行。遺憾的是，許多開發團隊只得到的相反的效果：他們越竭盡全力嘗試此方法，得到的結果越差！
如此，「瀑布式」開發的小船說翻就翻就不足為奇了。
敏捷就是android系統， 瀑布就是IOS系統
傳統開發的瀑布方法 雖然實行多年但是工作效率極低 文檔太多佔用太多時間等問題為人們所煩惱。
現在越來越多的團隊使用敏捷迭代看板，阿里、騰訊等都驗證了敏捷看板可以有效提高工作效率。
精益敏捷開發看板在傳統看板工具上進行了實用性的提升。 對比經典的看板，精益看板的可視化效果更佳，更加易懂實用。尤其在移動互聯網時代，一個企業通常有多端研發小組（web，iOS，安卓，微信等），精益看板能能解決產品需求在多個研發小組之間有效率的協作。
1新建項目
新建項目時選擇精益敏捷開發項目。
2添加成員，分配許可權
3設置階段與泳道
精益看板分為四個大的階段，產品，研發，測試，發布。
在產品下面又分為需求池，設計，確認，待開發四個子階段，產品經理整理所有的待開發需求，按優先順序進入產品的設計，設計完成後，和技術進行需求確認，確認完成後就是待開發的需求了。
將待開發的需求拖到第二個大階段研發，代表需求進入了研發階段。 研發階段下面是各個研發小組（用泳道來進行設置），對需求直接拆分子任務到各個小組。子任務完成後進入研發階段的完成列， 整個需求完成後，需求進入第三個階段，測試。
測試階段分為待測試， 已測試兩個子階段。
已經測試的需求，產品經理確認後拖到第四個階段發布，代表需求可以上線了。
4設置衝刺（sprint）周期
建議按一到四周設置衝刺周期，周期開始時確定衝刺周期內要完成的研發需求。可以認為一個衝刺周期就是一個階段性目標的設置。
5產品需求整理
產品經理和運營經理使用產品Tab進行需求收集，整理。可以分產品模塊歸類需求以備未來查找， 同時也可以使用版本來歸類需求，記錄版本的演進過程。在版本里有發布版本的按鈕，點擊後記錄版本上線的時間，形成產品迭代的路線圖。
例如：魚骨當前是一個星期伺服器升級一次，那麼我們就按升級日期發布該版本，記錄版本下面需求的更新時間。將需求關聯到模塊和版本能結構化整理產品的需求變更和發布時間，提供產品經理一個大局觀的視圖，幫助產品經理從產品整體上去提升產品。
產品經理完成需求的設計後， 將需求提交研發部門。
6需求拆分任務
在看板的第二個大階段研發經理按需求拆分為多個子任務，分配給多個研發小組。按任務可以設置完成時間。 子任務完成後拖到後面的完成列，任務完成。
7確定衝刺階段的需求
每個衝刺周期前，產品經理和研發人員一起回顧整理產品各需求的進展狀況，確定下個周期需要完成的需求。 將需求向左側Task拖拽，進入當前的衝刺周期，或者可以在需求卡片上面修改Sprint進入當前的衝刺周期。
8分配任務和需求到人
在負責人看板，可以方便的拖拽調整團隊成員負責的任務，平衡工作量。
9每日站會
Scrum的每日站會是一個非常有效率的做法，雖然在國內很少團隊能堅持。 站會中，看板是一個必備的會議工具。 項目經理在會議中通過拖拽卡片調整需求和任務的進度，團隊成員信息及時同步，明確工作目標。
10衝刺周期總結
每個衝刺周期結束，團隊總結衝刺周期內的經驗。將周期內未完成需求調整到下一個衝刺周期。
對比同類軟體，首先魚骨更適合整個工作團隊一起協作使用。同類的工具基本都是研發專用的任務記錄或者Bug記錄工具，產品部門、運營部門以及公司管理層很難融入使用；其次，魚骨的協作功能更強大，任務的多種功能滿足團隊實際工作中的複雜需求；最後魚骨的各種提醒功能，聊天功能等讓項目的協作更加便捷。
在使用中，有任何的建議請及時反饋給我們。 我們一起將這個工具做的更好！
1、敏捷開發屬於增量式開發，對於需求範圍不明確，需求變更較多的項目而言，可以很大程度上響應及擁抱變化。
2、對於互聯網產品而言，市場風向轉變很快，需要一種及時快速的交付形式，而敏捷開發則能更好地適用於此。
3、敏捷開發可最大程度體現80/20法則的價值，通過增量迭代，每次都優先交付那能產生80%價值效益的20%功能。能最大化單位成本收益。
敏捷開發集成了新型開發模式的共同特點，它重點強調：
1.敏捷就是「快」。快才可以適應目前社會的快節奏，要快就要發揮個人的個性思維多一些個性思維的增多。
2.客戶參與。以人為本，客戶是軟體的使用者，是業務理解的專家，沒有客戶的參與，開發者很難理解客戶的真實需求。
3.強調軟體開發的產品是軟體，而不是文檔。文檔是為軟體開發服務的，而不是開發的主體。
4.設計周密是為了最終軟體的質量，但不表明設計比實現更重要。
5.迭代。軟體的功能是客戶的需求，界面的操作是客戶的「感覺」。對迭代的強調是縮短了軟體版本的周期。
6.小版本。快速功能的展現，看似簡單，但對於複雜的客戶需求合理地分割與總體上的統一，要很好地二者兼顧是不容易的。
更多敏捷開發交流：敏捷落地分享會
敏捷開發對整個團隊的要求更高，當然項目風險更容易早期控制，大規模的項目就比較難玩了。
敏捷開發講求idear的快速落地，高效實踐為重點
嗯，敏捷開發也是要人員跟得上才行
推薦閱讀：