起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識為什么我不推薦敏捷開發？
當項目成員越多，我越不推薦敏捷開發，原因在于「當連自己要做什么事、為什么這樣做、這樣做為了解決什么問題」都搞不清楚前，就跳下去玩敏捷開發，那和比通靈還慘，通靈起碼還有個目標物在前面，搞不清楚狀況的人只能陪他跳世界迷霧開地圖了 。
敏捷開發 – MBA智庫百科?最下方有段「對敏捷開發的誤解」?？身槺銋⒖?敏捷軟件開發 – 維基百科。
誤解一：敏捷對人的要求很高
說高不高啦，撇開實作技術不談，你覺得要找到清楚項目開發流程、知道每位項目成員的工作內容、職責范圍、產出，并清楚項目目標、需求、用戶需要的開發人員（含設計師）很容易嗎？
如果上述條件無法達成，又怎么確定運用敏捷開發方式后，所有項目成員方向都是正確的？就因為這種人太難找，所以會產生「對人要求很高」印象。
連在有企劃書、規格書、用戶研究報告的文件情況下都還不知道自己要干嘛、同事在干嘛，能談敏捷嗎？
誤解二：敏捷沒有文檔，也不做設計
文件撰寫與否和敏捷開發一點關系也沒有，敏捷開發強調「適應性而非預見性」，并沒有強硬規定。雖然有一句「可用的軟件：重于 詳盡的文件」，但它沒有叫你不要寫文件。
先想看看寫文件是為了解決什么問題？如果不寫文件會產生什么問題？
以 UI 設計師來講，交出 UI Flow、Wireframe 這種文件是為了解決什么問題？要敏捷開發嘛就不用寫了跳過，直接出 Mockup 吧。因為發現出包有漏改來改去改到死，和找到產品問題改良，是兩回事??！
敏捷開發不是沒文件沒流程的包裝紙。
誤解三：敏捷好，其他方法不好
敏捷開發就是一直小幅度改啊改啊改啊，可以增加工作效率，讓大家工作更順利喔～～（就算是瀑布流式的傳統開發流程，設計師也是一直改啊改啊改啊，效率了什么、順利了什么?。?？）
先承認有問題，才能找出問題，之后找解決方法。而不是先有方法，再想這個方法能解決什么問題。敏捷開發只是一種「方法」，方法論用在敏捷開發上，要回答兩個問題：
- 現有模式為何不能滿足你的需求？
- 敏捷式開發為什么可以？
敏捷開發不是萬靈丹，先找到問題點、知道為什么要采取敏捷，重點是卡在哪里需要敏捷這個「方法」來解決。設計師改來改去是為什么解決什么問題？敏捷 開發的小幅度改來改去、和現況設計師的改來改去有什么不同？如果都一樣為什么要采取敏捷？（不要跟我說因為軟件開發主力是 RD 所以忘記算上設計師。）
現實的扭曲
個人與互動：重于流程與工具
開會是非常燒錢的行為，如果項目成員一多，要用什么方式降低溝通落差、盡量讓每個人理解到的都相同？怎么確保部門和部門間的信息交流順暢？靠出張嘴溝通就能辦到嗎？
可用的軟件：重于詳盡的文件
有文件產生/解決什么問題？沒有文件產生/解決什么問題？不寫文件最愛用「我們是敏捷開發」當借口了，不會寫就不會寫、不知道文件寫來干嘛就老實承認，少拿這個當說詞。
與客戶合作：重于合約協商
如果客戶沒有在好的引導下一起合作，現實狀況會變成「最后一次-確定最終版-說好不改了-V21.psd」。嗯？改來改去不就是敏捷開發嗎？（喂）
回應變化：重于遵循計劃
這不是改來改去改到死的好理由！為什么要「變化」，變化是為了解決什么問題？沒有問題改它干嘛？完全不代表可以沒計劃就上??！
結論
敏捷開發宣言里各種許愿…拔掉敏捷二字不也是所有項目開發的理想？所以為了解決什么問題而采用敏捷式開發？為了改善工作流程加快效率？
那設計師修改到死的工作情況在敏捷開發里要怎么被改善？
我覺得敏捷開發適用「頭腦清楚」的人，只是這種人往往是大神級的了。和大神 PM、大神 Planner、大神 RD 合作，都清楚知道自己在干嘛、別人在干嘛，還能 Cover 一點別人的領域，知道解決這個問題可以往目標更進一步，這種合作模式才有辦法做到「敏捷」，而不是因為抓漏抓蟲在修改。是啦這也算朝目標邁進，但「創新改 良產品」和「讓產品看起來洞沒那么大」的改來改去本質上是兩回事啊！敏捷開發只是個方法，不是萬靈丹。
敏捷式開發就是改來改去？
那「字大一點、Logo大一點、換一張照片、多出幾版讓我挑」也算啊～
原文地址：blog.akanelee.me
作者：@Akane_Lee
確實沒什么邏輯性
樓主說話像是西南地區人士
LZ講的很不錯，稍微偏激的描述還是刺激出了一些人的槽點
我覺得敏捷還挺好用的啊 可能因為我們用魚骨敏捷項目管理開發過程吧 一個標志的大看板 再加上需求 迭代 bug這幾個模塊的管理 就很簡單了啊
你是賣產品的，需求是什么，你怎么描述的。就是幾行字嗎。哈哈
通過以上內容，鑒定書呆子一個。
有點理解樓主的抱怨，不是說敏捷不好，而是說在很多現實情況下，采用敏捷并不能解決問題。對于敏捷方式的采用，需要考慮好需要解決哪些問題，而不是盲目的認為敏捷可以解決現實中出現的任何項目問題。敏捷宣言中的四條，在現實中有時確實很無力。個體和交互，現實中有很多的技術大牛、有能力有經驗的人、有學習鉆研精神的人，但是現在的很多軟件開發人員，很多都是培訓機構培訓幾個月就出來工作的，可想而知（當然不排除有優秀的人）?？蛻艉献?，很多客戶都是想在最短時間，實現最多的功能，尤其對于不懂軟件的人，頻繁出現——這個功能應該很簡單吧，明天可以給我吧，之類的。怎么樣引導客戶合作，確實是一個比較大的問題。響應變化，確實如樓主所說，有些變化真的是無理變化，或者說是舉棋不定的結果，并不是所有的變化我們都需要及時響應的，同時也會導致很多浪費。而這種變化，可能在項目中卻是多數。以上僅為個人工作中的經驗，可能情況會有些極端吧。
個人感悟：敏捷首先從兩個層次去理解，要做什么？為什么要這樣做？然后就是3個“最”最短的時間，最有價值的事務和最小可用版本。在就是兩個持續，持續進行迭代開發與運營，持續與用戶溝通。我們都知道也常在嘴邊念叨計劃趕不上變化，敏捷的開發模式擁抱變化。
一直不理解，什么是傳統開發模式，為什么傳統開發模式就是瀑布模式，瀑布模式就沒有迭代了嗎？瀑布模式也可以多次迭代啊，也能擁抱變化啊，為什么瀑布模式不能多次迭代？
LZ，說實話沒看懂你到底想說什么，思路太不清楚了，表達的目的也沒說清楚
lz這篇文章的核心論點是：敏捷不是萬靈丹，它是適合那些層次稍微高一點，知道大體框架要做什么的團隊，敏捷的核心也是要在有足夠強魯棒性的框架下，再不斷根據需求的變化而不斷迭代優化，讓這個大體框架逐漸明晰。這個和那些根本不知道自己的大體框架要干什么，上來就是東抓一把西抓一把，最后改成一鍋粥的做法是有根本性區別的，首先魯棒性上面都不夠強！
所以他強調，在用敏捷方法前，先弄明白自己團隊的項目大體框架上面要做什么！
敏捷對成員的要求確實高，但是也不全是這個樣子的。
感覺作者不是特別理解敏捷開發，從外表看，敏捷開發和傳統的瀑布開發差別很大，本質上敏捷也不是萬能的，但是，之所以現在數以千計的項目轉來做敏捷，尤其是大而復雜的項目，說明存在必有其道理。不可否認敏捷也有問題，但是相對于傳統的那種要確定需求，設計，流程后才能開發產品的方法，敏捷能更大限度的減少損失（如果失敗的話），我們都不喜歡改來改去，所以敏捷第一宣言就是，歡迎改變，究其原因是因為，事物是發展的，產品的環境是變化的，所以，我們一定要想那個小老鼠嗅嗅一樣，保持敏感，從而達到敏捷。
從你的回答來看，你只會照版的別人的東西。多實踐一下再去做回答。為什么傳統的開發模式就一定是瀑布開發模式，瀑布開發模式為什么就不能迭代了。傳統的開發開發模式也可以擁抱變化，快速迭代。為什么沒有這樣做？請思考一下這個問題？
從你的回答來看，你是來吵架的
說的好，就是這樣。
lz試試真正的瀑布流就能知道效率有多低了~ps：瀑布流意味著有嚴格的界限，而界限意味著有繁冗的流程，更坑的還意味著不可逆性。
不是樓主需要知道什么，你經驗太少，主要是人，瀑布流不一定效率低下，瀑布開發模式也可以多此迭代，主要是人。主要是即懂技術，有懂業務的大牛，有這樣的人管理項目，不管瀑布和敏捷效率都會很高。沒有這樣的人，那個效率都很低。不要盲目的去下結論。
如果需求明確，確實適合瀑布模型，如果需求不明確，使用瀑布模型確實很麻煩，逆向修改要改動的東西太多，從需求規格說明書，概要設計，詳細設計都要修改，但是在實際的開發中沒有人會使用嚴格的某一種模式，大多是混合模式
瀑布模型效率是最高的，迅速就能做完整個項目，然后客戶說我們的需求不是這樣的，你理解錯了，然后你就再次的從新設計整個項目
沒有哪個人一生來就是大神的，樓主這個吐槽明顯看出是個幽怨的UI。。。被pm要求改過去改過來了吧。。。。
贊