是什麼因素導致敏捷開發在中國的廣泛應用？

01-15

由於敏捷開發這個概念是由西方先提出，然後在中國迅速推廣開來。所以我想知道大家在接受敏捷開發時考慮的因素，這些因素又是如何影響開發者和管理者的，比如哪些因素提高/降低了敏捷開發的接受程度？哪些因素重要，哪些因素次要些？
從個人能力、組織和個人的動力、環境（機會）因素和敏捷開發自身特點四個方面考慮，也可與傳統的開發模式比較的角度談談。

我在公司內部推廣實施敏捷4年多了，我認同敏捷的根本原因是因為我認同敏捷的軟體開發世界觀。傳統開發方式的擁護者和敏捷開發方式的擁護者看待軟體開發的世界觀是不同的。

在傳統開發的眼裡，軟體開發過程是確定的、可測的，只要在一開始努力收集到需要的信息並制定好計劃，然後忠實的執行計劃就應該可以成功。如果不成功一定是你在一開始就沒有做好，沒收集到必要的信息，計劃做的不好或者執行不到位。然後傳統開發方式就試圖引入更多的流程，文檔，試圖讓每一步都做到萬無一失。

而在敏捷的眼裡世界可不是這樣的，敏捷認為在軟體開發中，世界是變化的，有很多不確定性的。一方面，從認知角度來說，我們是無法在一開始就收集到確保成功所需要的所有信息的，必然是隨著開發的進行，我們對正在做的東西的認識才越來越深刻。因而做一段時間後常常有發現需求需要調整，或之前的設計不是最合適的情況發生。另一方面，世界本來就是在快速變化中，我們不得不隨之做出調整。因此敏捷的很多實踐主要針對如何應對變化。這對這一目標，敏捷要回答兩個問題：第一，我們如何及時的知道要做變化和做什麼樣的變化？第二，一旦要做變化，我們如何能以最小的代價完成這種變化？所以敏捷的實踐大多在回答這兩個問題。

那麼到底那種想法更接近現實世界的情況呢？

在實際當中我所經歷的項目介於這兩者之間，即並非完全的可測或不可測，但通常隨著項目複雜度的增加，項目的不可測因素就會大大增加，變得越來越的難以把控。而大多數項目都屬於這種有著相當不確定性範疇的。完全可預測，確定的，在一開始就能完全把握的幾乎沒有。所以我認為實際情況更符合敏捷的世界觀。如果這一前提成立，自然敏捷方法就更有效了。

我很喜歡把傳統開發方式比喻成普通火炮，而把敏捷開發比喻成導彈。兩種武器打擊目標的過程很形象的說明了兩種軟體開發過程的區別。火炮打擊目標時，要想打的准，則要寄希望於一開始瞄的夠准，而且對目標運動軌跡估計的夠准。一旦炮彈發射出去，就無法對速度、方向進行控制了。任何瞄準偏差，沒有預料到的目標移動軌跡變化，甚至風向的變化都會導致炮彈打偏。而導彈就不一樣了，只要設定好目標方位，並不需要一開始就精確瞄準。導彈發射出去後，會持續的收集自己的位置、方向、速度並根據目標的方位不斷的調整，最終能夠較精確的長距離命中目標。

其實這一切的根源都在於軟體開發是一個複雜的過程，複雜到各種基於預測的軟體開發方法和流程都不是太好使，因為這樣的成功要依賴於你在一開始就什麼都想到了、都做對了。更何況既定的流程很難應對好這種複雜帶來的不確定性。反而基於經驗式的方法，比如敏捷，不依賴於在一開始就什麼都想對、做對，而是依靠團隊緊密協作並不斷地在向前摸索中根據實際情況做出調整，小步快跑，反而像導彈一樣，更容易命中目標。我在這裡並不是說流程不重要，而是在敏捷開發中，和流程相比，團隊成員的自發協作更重要。

手快活糙

需求變化快

各種野路子

－－－－－－－－－－

按傳統的軟工手段，還得配齊各色人等。

聽說老外新流行出來個什麼XP開發，不就是我們一直搞的哪一套嗎？

身兼多職，管它三七二十，搞出來再說。

1，崇拜外國先進方法

2，自己關注的大牛推薦

3，尋找銀彈解決自身問題

4，看別人用得很好

5，銷售鼓吹

6，行業需要一個新鮮的東西來折騰

7，其他……

因為

需求變得太快

環境變得太快

用大項目管理方式來管

死得慘的太多

敏捷開發在國內的流行和廣泛應用大概是集中於以下幾點原因：

1. 時勢：瀑布、MSF、極限、SCRUM等都是在2000年前就在國外發展若干年，此時國內的軟體業剛剛起步，發展的重點是電子化、信息化，比如說財務軟體、專業軟體、辦公自動化、稅務以及ERP等工具性質的信息系統，軟體公司的典型代表是金山、用友、金蝶、東軟等，再加上網路環境等受限，在2006--2009年左右，各大軟體軟體公司基本上是軟體作坊、瀑布式、微軟的三駕馬車式架構，由於產品的收費方式就是靠授權（光碟、加密狗），需要積攢大量的功能客戶才買賬（同時網路限制導致經常發布也不現實），產品發布也大都按照年來發布，比如各種KV2006等，也是中間件興起的一年，各個工資公司考慮搭建自己的技術平台（工作流、許可權等，用友的UAP（？）），團隊開發規模大多數開始往50-100人，甚至更多發展。在2006年前後，Web2.0興起，2009年左右團購、電商等開始大幅發展，移動應用也隨著啟動，也就是所謂的互聯網企業和移動企業，此時的軟體產品的特點大多數通過網路分發，滿足人類的需求大多數也比較簡單，業務邏輯不複雜，團隊比較少，大多在10人左右，由於發布的便捷性，收費方式的改變，不需要積攢功能後向用戶發布收費，此時頻繁的發布成為特點。團隊小、功能少、發布頻繁、客戶反饋快等特點決定需要輕量級的開發過程模式，敏捷模式正是響應了這一需求。

2. 人員特點：雖然我國軟體業發展也有二三十年的歷史，但是從業者魚龍混雜，水平也完全不一樣，大多數人都未學習過軟體工程、項目管理等內容，大多數軟體公司也都處於軟體作坊的狀態（2009年有人依然通過文件共享的方式來做代碼管理，2011年有人問我能否在一個單元文件中看到所有的程序邏輯），姑且不說瀑布僅僅是生命周期模型，不算是過程方法，也有很多人沒有按照瀑布模型走下來。這種情況下，敏捷二字很吸引人，特別符合國人的武功秘籍的心態。

3. 方法論的複雜與簡單程度：在RUP、敏捷、MSF以及CMMI、項目管理等各種方法框架中，敏捷是最簡單的最易懂的也是入門最容易的，其他都是需要下功夫深入學習理解實踐的，這無疑導致學習成本很高。RUP不僅是一套完整的體系，還包括一大堆的工具等，學習壓力非常大。MSF在國內很少看見學習資料，基本上沒有人採用。CMMI大多數被作為敲門磚，項目管理也多數作為了敲門磚。另外也是很少人了解這些框架方法，RUP、MSF、CMMI、項目管理都有關於迭代、增量、漸進明細、需求優先順序的論述，而在很多人的心中這些框架和瀑布差不多。

4. 諮詢、考證的推波助瀾。各種SCRUM Master的認證等推波助瀾，很多Scrum master可能都是雞而不是豬。

5. 老闆信了。很神奇的事情，不知道為啥這幾年老闆居然信了

綜上，在需要快速推出產品，團隊成員對各種框架的學習成本以及框架方法自身的特點，敏捷在國內流行開始是很必然的。

---------------------------------------------------------------------------------------------------------------------------------------

但國內目前流行的敏捷大多數是偽敏捷（就有迭代、增量以及站立會的形式，價值觀以及原則都未貫徹實踐），而其他的框架方法也有非常多的可取之處，如果想推進軟體項目成功率，建議不妨多看看其他家的內容，單純了解敏捷而又對技術比較了解，推薦極限

啥是敏捷？

傳統過程沒有技術炒作嗎？ iso，cmm，rup……哪個沒被拿來當過面子工程。敏捷有很多問題？世界上有多少團隊，有多少樣式的應用。道可道非恆道，任何一個具體的方法論必然會有局限性，就連哲學也不是普遍適用的。

中國自古有技術沒科學，很少有理論和方法論被流傳下來，所以像極限編程，敏捷開發這類的實踐與方法論流入時讓很多人耳目一新。一時間，懂的不懂的，照抄的重構的，鋪天蓋地。

如此流行一定有他的道理，無數團隊受益也是事實。罩杯有沒有用，關鍵要看你size夠不夠，平胸卻說些內衣沒用的怪話者比比皆是。

謝謝邀請。

個人覺得其實敏捷開發和最原始的小作坊協作模式非常像。

在經歷了大規模工業化的洗禮之後，人類開始進入大規模生產的時代。巨量的人組織在一起產生了比分散的小團體的總產量之和更大的價值。於是人們逐漸把流水線生產奉若神明。

而信息革命的觸發又讓人回到了小規模合作的環境。幾個人的價值又可以再次超越一群人，於是敏捷開發被提出來了。

國內的作坊看上去很敏捷，但是各種組織構架不清，管理落後，工藝發展停滯等弊病還是很全面的。所以，我覺得國內廣泛應用的是類敏捷開發的原始作坊模式，只是配上電話電腦等高科技的工具後看上去還是煞有介事的。

說白了就是指哪打哪。

純手工的活，一個人身兼數職，一人搞全部。

本來流程化的東西，全部都堆在一起，累死人，hr開心了，招一個人干五個人的活，壓榨員工的新方法。

從某種角度看，敏捷開發就是壓榨程序員的一種工具。

　　敏捷開發的優勢:

　　滿足用戶不斷變化的需求是軟體開發的長期無法解決的難題之一,經典的瀑布模式在一個迭代周期內表現優異,但一旦需求變化,瀑布模式卻顯得無能為力。敏捷方法滿足需求的辦法主要通過迭代。在每一次迭代周期結束時,都能交付用戶一個可用的、可部署的系統,用戶使用並體驗該系統並反饋意見,在隨後的迭代周期這些意見和需求的其他變化一起在產品中實現和集成。每次迭代周期應儘可能短,以便能及時地處理需求變化和用戶反饋。

　　敏捷開發方式能給企業和用戶帶來以下好處:

　　1.
精確。瀑布模式通常會在產品起點與最終結果之間規划出一條直線,然後沿著直線不斷往前走。然而當項目到達終點時,用戶通常會發現那已經不是他們想去的地方。而敏捷方法則採用小步快跑,每走完一步再調整並為下一步確定方向,直到真正的終點。

　　2. 質量。敏捷方法對每一次迭代周期的質量都有嚴格要求。一些敏捷方法如極限編程等,甚至使用測試驅動開發(test-driven
development),即在正式開發功能代碼之前先開發該功能的測試代碼。這些都為敏捷項目的整個開發周期提供了可靠的質量保證。

　　3. 速度。敏捷團隊只專註於開發項目中當前最需要的、最具價值的部分。這樣能很快地投入開發。另外,較短的迭代周期使團隊成員能迅速進入開發狀態。

　　4. 豐厚的投資回報率。在敏捷開發過程中,最具價值的功能總是被優先開發,這樣能給客戶帶來最大的投資回報率。

　　5.
高效的自我管理團隊。敏捷開發要求團隊成員必須積極主動,自我管理。在這樣的團隊中工作,每個團隊成員的技術能力、交流、社交、表達和領導能力也都能得以提高。

了解更多詳情：PMI-ACP敏捷認證價值