1樓：阿土伯伯2010
如果我是客戶，我是不會任由開發團隊玩敏捷開發。詳細需求和方案沒定就叫買方簽合同出錢，說隨時可以退出，只是看似很美好。如同建築設計師給我畫了乙個美麗的新建築樣圖。
開發團隊沒搞好詳細設計就說可以建，建到一半發現這個設計本身就是個危樓，你說我找誰接手去。
2樓：
如果需求沒搞明白，啥都是坑。你把世界頂級大牛們弄一塊，讓我當產品經理，我有的是辦法讓他們寫出一坨屎山，無論他們採用什麼開發模型，框架，測試。。。
3樓：花萼橫江
很多公司實施的所謂「敏捷「，只是敏捷的改需求罷了。但敏捷開發的架構其實包含很多內容，對產品的相關各方都提出了基本的要求，包括但不限於：確定概要需求，分割需求，分配優先順序，分派任務，跟蹤，迭代。
只在改需求上發揮敏捷，只不過是管理層、非開發部門推卸責任，將所有壓力轉嫁給程式設計師們的手段罷了。
花萼橫江：周記 2019/08/23: 敏捷開發走下神壇
4樓：Amy小姐姐
這點隔壁團隊也分享過這個問題，負責人談到：假如有乙個剛從傳統的開發模式轉而採用Scrum的團隊，由於不習慣這種自我約束、自組織的方式，在Sprint中並沒做多少工作，那麼在會上演示的時候，他們會覺得很尷尬。沒準老闆看到他們花了這麼多時間只做了這麼少的工作而感到很生氣。
發生這種情況當然是大家都不想看到的，但良藥苦口，在下乙個Sprint中，這個團隊肯定會吸取教訓，他們會明白無論什麼情況下都必須Demo，那麼他們必然會很好的完成這個Sprint並演示給大家看。
意思是要意識到：傳統開發模式下軟體開發過程是執行研發計畫，而實際工作中，需求往往在開發過程中會產生巨大變化。敏捷開發更能適應不確定性強的產品和市場。
做乙個最懂技術的需求分析師。
5樓：Junn熊
所以這樣提問, 其實算還沒進入敏捷的門徑. 弄清楚需求, 需求管理, 也屬於敏捷開發實踐框架的一部分. 可以了解一下敏捷/Scrum是如何管理需求的.
gong zhong hao 文章裡都有寫.
6樓：
如果只是講敏捷開發的流程落實講個兩天估計大部分人就能明白個差不多，但是要把敏捷的根兒扎下去一年兩年都是他，要看企業原本的管理風格和老大的推進力度。
基本上著重於流程實現的敏捷大部分都會認為敏捷是乙個坑。
在中國的傳統企業管理文化中，要實現敏捷困難不是一般的大，有些時候是挑戰人性和老闆的格局底線。
敏捷某種程度上有點兒像烏托邦，大家都知道全體社會層面的烏托邦是不現實的，但是區域性是存在可能性的，也就是說在組織內部努力一下是有可能的。
所以敏捷是不是坑首先得看老闆，如果能真正熬一兩年達到理想狀態，人人負責，人人奉獻，敏捷的產出能力是非常值得期待的。
最後，給所有想上敏捷的老闆一句話，一年打基礎，兩年見效果，這樣的預期，這個坑你還進不進？
7樓：CODING
關於敏捷開發，首先我們要了解的是敏捷開發是涉及整個軟體工程的理念與實踐，它的核心是迭代和增量式軟體開發方法。開發者快速發布乙個可執行但不完美的版本投入市場，在後續迭代中根據使用者的反饋改進產品，新增一到多個使用者可以感知的完整功能，從而逼近產品的最終形態。迭代就是整個理論的核心，坦白的說迭代開發並不是新鮮詞彙，但是敏捷開發理論大大完善了迭代開發的理論，使之能夠被廣大的軟體開發團隊認可，並開發了具體的實踐方法如：
Scrum等。
敏捷開發比較特別的地方是它是組織文化，流程以及工具的結合體，在敏捷開發介紹中要著重強調三者的同樣的重要而且缺一不可：「工具，流程，組織文化」。缺少工具支援的敏捷研發無法實現「高速」；缺少組織文化支援的敏捷研發會讓團隊成員之間無法團結一致完成共同的目標。
敏捷研發講究的就是在可控的情況下進行乙個乙個短頻快的迭代，每個迭代環環相扣，快速反饋，快速驗證。本專案的產品經理需要在需求管理模組中制定專案的產品規劃並負責維護和更新。因為接下來的產品迭代都是建立於需求之上的。
下文分享了如何使用 CODING 快速入門敏捷開發——CODING：CODING 敏捷實踐完全指南如果對敏捷開發感興趣，可以關注CODING 的專欄
8樓：
需求沒有搞清楚和搞不清楚需求是兩回事。如果需求明確但執行團隊的成員沒有搞清楚就開始幹活，是會出現題主說的問題，大量無用功，造成對團隊的傷害。敏捷應對搞不清需求的專案時比瀑布優勢明顯，在網際網路開發中，時間緊，任務重，使用者想要的東西還真說不好是哪種，所以用敏捷來做MVP，實現那些最能滿足使用者的需求，推出後看看使用者的反應、資料的表現等，然後反饋給Scrum團隊，這是乙個小步快跑，迭代、同時也是不斷試錯的過程。
敏捷對人的要求更高，所以是不是坑，要看整體團隊對敏捷的理解。
9樓：網易數帆
敏捷開發坑不坑，取決於企業業務發展的階段，和實施敏捷的方式。合適的團隊、管理和工具對敏捷是比較重要的。而千年不變的小業務，敏不敏捷，並沒有多少區別。
從上圖看瀑布開發與敏捷開發的區別，前者是一次把事情做完，統一交付，而後者是多次把事情做完，增量交付。然而，敏捷開發的核心，不是把大的計畫拆分成小的計畫，然後階段性地交付，而是可以通過快速交付後的使用者反饋，不斷地調整需求計畫。這種模式有兩個深層原因：
使用者的真實需求是很難把握的。
使用者的需求通常是快速變化的。
對變化的需求把握、滿足得比較好的，是網際網路公司，這與網際網路技術的應用有很大的關係。對於使用者、市場的研究，網際網路團隊善用收集和分析使用者資料。單看研發流程，伴隨著網際網路的發展，基礎設施從物理機到虛擬機器再到容器（將來可能是函式），開發模式也從傳統的瀑布開發到敏捷流程再到精益迭代，能把敏捷、精益做得好的團隊，管理模式、團隊技能和工具平台，都是有一套的。
管理方面，我司一位大神分享有三個要訣：
乙個產品的版本盡量保持穩定的迭代週期。
產品負責人要讓團隊成員充分地了解需求和規劃。
合理的變更控制。
作為雲計算技術服務商，網易雲比較關注敏捷的工具及其正確應用姿勢。例如，雲計算使得開發者無須再關注硬體資源，使得軟體交付流程更快。當然，由於依賴雲服務廠商的技術穩定性不一樣，企業在架構設計時要更多考慮使用雲的特性來滿足非功能需求。
工具層面，我們可以說：無自動，不敏捷。因為敏捷開發往往意味著系統要頻繁地進行變換，逐步收斂於最新的使用者/市場需求，很難想象沒有自動化流程的支援如何做到這一點。
敏捷的高段，是採用微服務架構，實現 DevOps，包括持續整合/持續交付（CI/CD），各個子產品模組的迭代並行不悖，整個開發測試運維流程，適合自動化的環節全部是自動化的。
我豬廠又一位大神說：
自動化測試是實現每個sprint有足夠高測試覆蓋率的唯一途徑……沒有測試自動化的敏捷專案本質上只是分階段的瀑布專案。所以，網易雲輕舟微服務平台，匯聚微服務框架、DevOps、容器平台、APM、API閘道器、全自動化測試等元件為完整的微服務平台，支援網際網路軟體迭代更高效。
10樓：劉宇峰
敏捷解決需求一開始不清晰，或者以為清晰了，但事實上不清晰的問題。
我知道自己要什麼這個幻覺不僅在軟體開發領域普遍存在，其實在哪兒都有，人對未來的預期力是非常糟糕的，通常缺少無數細節。比如說吧，你想象下自己想要個怎樣的臥室，想好後回憶下，手機充電的插座在哪兒你剛想了麼？然後再想下，手機充電這事是不是很重要，是不是發生得很頻繁，可你為啥就忘了想象呢
所以要迭代式開發，承認說，人腦能力有限，組成乙個團隊後，集體智商又比個體智商更低，還是分迭代想和分析需求靠譜些
11樓：lymim lee
敏捷開發可以模擬於精英教育和家庭病房，要求可以全週期高質量的推進專案進度。
首先人得到位，甲方乙方一對一全程配合，縮短反饋時間，提高效率；
其次環境得到位，開發、測試、跟產，不能說啥缺啥；
再次技術得到位，乙方能及時對新需求做出評估，是扯淡還是需求不能乾到一半才搞清楚；
最後錢得到位，既然得一對一，而且對開發團隊要求這麼高，錢不到位說個雞兒。
12樓：扼殺黑暗
哈哈哈，沒次看到敏捷開發都想笑
敏捷開發的前提是優秀的人才啊啊啊
說白了，因為人才優秀，所以開發效率高，為了讓傳統開發流程不拖累優秀的人，才改為敏捷開發
產品質量的控制一部分能力從qa轉移到了開發者這邊而已是能力強的人為了提高產出選擇了敏捷開發，而不是使用了敏捷開發所以敏捷，明白不
你沒qa，團隊又不優秀，搞毛敏捷開發
13樓：
是。敏捷確實有敏捷的好處，但是如果全盤套用，就是個坑。看到很多公司或者專案組效仿敏捷，最後把自己做死了的。
適當的流程與文件的精簡，以及溝通效率和工具使用便捷的提公升是對的，這也是正常的，其他的都是扯淡，不僅會降低效率，而且還對實際專案沒有任何幫助。
學敏捷，學這一部分就可以了，其他的要慎重。
Lean enterprise也是，適用於大公司的精簡，但是小公司不思考好了自己各方面的問題，上來就lean，就呵呵了，真正有腦子的創業公司沒人會迷信敏捷這套東西。
14樓：徐毅
敏捷是，如果最後總共是100個需求，那麼：先完成5個需求的分析、設計、實現、測試、發布或部署全過程，然後再完成下5個需求的全過程，然後再下5個，迴圈，直到覺得沒有更多需要完成的需求了，而此時可能完成了100個也可能只完成了80個，也可能更多，而時間可能是原來的節點，也可能不是，但重要嗎？不一定重要。
更重要的是，最先完成的都是最重要的需求。
在這個情況下，如果你說的模糊，是說沒有100個需求都清楚就開始開發，那麼這個確實就是敏捷的特點，因為它認為沒有必要那麼早鎖定，你怎麼確定現在對這100個需求的理解一定準確呢？為什麼不能現開發最重要的幾個需求，其他慢慢澄清，更何況，你完全可能會有新的想法嘛。
但另一方面，如果你說的模糊，是連馬上要開始的這5個需求都不清楚，那就有問題了，更有可能的是你們的敏捷是在掛羊頭賣狗肉，找個高手指教，或者請個教練、顧問去輔導吧。
15樓：Agile2-張恂老師
對於多數國內企業和團隊來說，以 Scrum+XP 為代表的轟轟烈烈的「敏捷運動 1.0」確實是乙個坑（還不止乙個坑），一不小心就容易掉坑里。
中美的軟體工程處於不同的發展階段與水平，論平均水平至少還差 8-10 年吧，尤其是人們的科學、工程意識與水平。Scrum+XP 並不是普適的，從一開始就不是針對中國軟體工程的現狀和特點提出來的，所以許多做法基本上不適合國內，適用面非常窄。
Scrum+XP 主推的那些實踐有點用，但缺陷也很明顯，比如理想化、片面、偏激、失衡，極端主義傾向，忽視需求分析、系統建模、架構設計，因此不能很好、有針對性地，或從根本上解決國內團隊面臨的一些現實主要問題，而 Scrum+XP 實踐所要解決的那些問題也並不是國內多數團隊所面臨的真正的短板。
顯然，兩者（賣方與買方）的不匹配，水土不服，加上長期的商務洗頭和運動洗頭式傳播，結果導致國內的偽敏捷、偽 Scrum 比比皆是。
感覺需求都沒有搞清楚，就開始弄的所謂敏捷開發其實浪費了更多的時間和製造了大量無用的消耗
題主提到了需求分析，這正是 Scrum+XP 最薄弱的環節之一。
XP 中的需求分析實踐其實是很弱的，Kent Beck 發明了使用者故事（User Story），想要取代用例故事（Use Case）。
然而，有多少人相信，在實際的工程專案實踐中，僅靠一堆文字量非常有限的故事卡片（用完之後還要優雅地撕掉），加上口頭溝通，而不需要做大量科學、系統、細緻的需求分析，建立起高質量、書面的需求文件和需求模型，就能把複雜軟體的需求真正搞清楚？
連最上游的軟體需求都沒搞清楚，自然會導致開發中的許多返工和浪費，更談不上敏捷了。
從藥學跨考到心理，是從乙個坑跳到另乙個坑嗎？
小黎說運營 醫藥行業的話跟人的健康息息相關，一直都會是朝陽產業，且由於疫情的原因，醫藥更被國家重視，所以藥學專業現在還是挺好就業的，除了傳統的銷售崗 研發崗和生產崗，現在數字醫療的時代已經到來，網際網路醫療的崗位也在廣招醫藥人才。當然心理學碩士也可以從事心理學研究或者去做老師，這種的話會比較穩定些，...
我是乙個新手，PHP開發必須使用框架嗎？現在還有沒有不使用框架的PHP專案嗎？
某某人 嚴格來講，沒有。那些說不用框架的，其實自己也實現了框架，如果完全不用框架，寫起來挺累，幹嘛呢，PHP的優點就是開發效率，框架的目的就是提高效率。也寫過一些專案是不用框架的，寫完了真的不想再維護了 浮雲若海 不使用框架的兩種人 1 我不會 我不學 我不用，寫到哪算哪，不入流的新手 2 怎麼做我...
你的入坑番是哪乙個？
煙滅人盡散 如果不算小時候在電視上看到的一休，少女櫻，蠟筆小新。等等的，讓我第一次認識到 動漫 這個詞的入坑作品是 零度戰姬 初二的時候在網上看到的 聽海聽心 我的入坑番，直到現在我都記憶猶新。因為不僅番好看，op和ed我也一直在聽。哥特蘿莉偵探事件簿 也叫 gosick 偵探型別的番劇我看的不少，...