全球知名IT研究公司Gartner 研究表明，到2012年底，敏捷開發(fā)方法將占軟件開發(fā)項目的80%。 PMI推出了敏捷管理專業(yè)人士認(rèn)證（PMI AgileCertified Practitioner（ACPsm）），以培養(yǎng)更多的敏捷管理人才。關(guān)于敏捷方法和傳統(tǒng)瀑布方法的偏見
對于敏捷方法和傳統(tǒng)瀑布方法一直以來都有很多誤解：
走向敏捷就是革了官僚體系和瀑布式流程的命。從事敏捷工作的人努力地與這些東西劃清界限。于是所謂的遷移就是走向與傳統(tǒng)瀑布模型完全相反的方向（只有很少的甚至是沒有文檔、流程和操作方法等）。
那些采用傳統(tǒng)瀑布模型的公司則走向另一個極端，它們頑固地堅持以控制為導(dǎo)向，強調(diào)對成本和時間的精確估計和嚴(yán)格管理。若要以精確的管理成本和時間作為目標(biāo)，優(yōu)秀的項目經(jīng)理都知道他們必須控制用戶需求和項目范圍的變化。如此也就不難理解，這部分人難以接受敏捷方法中對變化的那種高靈活性和容忍度。
2003年，巴里·波姆（Barry Boehm）和理查德·圖納（Richard Turner）提到：
“不幸的是，這兩種方法沒有選擇互相補充、求同存異，而是把對方當(dāng)作敵人，把這看作一個零和游戲。敏捷支持者攻擊傳統(tǒng)方法‘衛(wèi)道士’過分崇拜流程，不夠人性化的軟件開發(fā)方法，而‘衛(wèi)道士’們則指責(zé)敏捷方法容易導(dǎo)致項目失控，質(zhì)量低下，以及不夠嚴(yán)謹(jǐn)。兩個陣營的堅定支持者們大肆鼓吹他們的信念，就好像他們是上帝派來的使者，這使得那些想要改進(jìn)開發(fā)策略的軟件開發(fā)者和項目經(jīng)理越加迷惑了?！?/span>
在那之后，這兩種論點都有一些新的發(fā)展，但是在很多情況下人們還是認(rèn)為它們是大相徑庭的。
敏捷方法已經(jīng)越來越成熟。類似Scrum的方法現(xiàn)在已經(jīng)不僅是一個開發(fā)流程，其背后有著強大的理論和實踐的支撐。但在很多人的腦海中，敏捷方法仍然是一個不嚴(yán)謹(jǐn)?shù)拈_發(fā)流程。
有很多人采用了新的方法使傳統(tǒng)開發(fā)模式變得更加靈活，讓文檔和流程變得更有意義，并越來越多地采用了迭代開發(fā)模式來平衡項目的靈活性和控制性。但這沒有改變很多人始終認(rèn)為的傳統(tǒng)開發(fā)方法就意味著獨斷和官僚。
現(xiàn)在是到了找到一個中間地帶的時候了，我們需要在兩者的鴻溝間建起一座橋梁，其實大部分的差異不是真實存在的，而是由人們的偏見造成的。在很多情況下，理解如何實施這些方法比理解方法本身更加重要。
想要建立一個切實可行的企業(yè)整體戰(zhàn)略，需要更深入地了解這兩個領(lǐng)域；想要建立一個更大的知識體系，需要掌握跨越敏捷和傳統(tǒng)模式的很多方法論、實踐和原理。對于所有的組織機構(gòu)來講，選擇合適的方法或多個方法的組合都是非常關(guān)鍵的戰(zhàn)略決策。所選擇的方法必須跟企業(yè)的業(yè)務(wù)戰(zhàn)略、企業(yè)文化、所處商業(yè)環(huán)境及特定項目所面臨的風(fēng)險和項目復(fù)雜程度協(xié)調(diào)一致。例如：
在一個高風(fēng)險的行業(yè)或應(yīng)用領(lǐng)域，必須要相應(yīng)地提前計劃，只有這樣才能保證對潛在風(fēng)險的預(yù)測并建立起風(fēng)險應(yīng)對機制。
而在一個高度管制的領(lǐng)域，必須編寫規(guī)范的文檔來描述項目需求、測試計劃和測試結(jié)果等，以滿足政策上的要求。
在以上的各種情況中，需要找到控制和靈活之間的平衡以滿足這些要求。而現(xiàn)實中有很多方法不需要完全放棄控制性，也可以獲得一定的靈活性。選擇合適的方法要由業(yè)務(wù)部門和開發(fā)部門共同完成，需要了解各種可選方案的優(yōu)缺點?？贪宓靥子媒炭茣系臉?biāo)準(zhǔn)方法（不管是敏捷的還是傳統(tǒng)的），而不針對具體業(yè)務(wù)情況做出調(diào)整很難獲得成功。另外，最佳方案有可能不是某個單獨的方法而是根據(jù)每個項目的具體需求量身定做的多個方法的組合方案。
1.4 盲目跟風(fēng)現(xiàn)象
任何新的方法，當(dāng)它是個大熱門的時候，都有可能造成盲目