最近，VersionOne揭曉了2011年度敏捷軟件開發(fā)調(diào)研結(jié)果，再一次向大家展示了敏捷應(yīng)用和發(fā)展趨勢的第一手資料。

今年，我們進(jìn)一步確信敏捷并非一時風(fēng)潮。我們過半的調(diào)查對象坦言他們已經(jīng)親身實踐敏捷超過兩年了，并且三分之一的人把敏捷從一家公司帶到了另一家。大約有三分之二的調(diào)查對象談到，他們公司的項目有超過半數(shù)在使用敏捷方法，有三個以上團(tuán)隊實施了敏捷實踐。

Scrum依然是敏捷方法流行榜中當(dāng)之為愧的狀元，52%的受訪者采用了Scrum（2010年則是58%）。

52%	Scrum
14%	Scrum/XP混合
9%	自定義混合
8%	不確定
17%	其它（包括看板 3%以及 XP 2%）

Matt Badgley在最近的博文中探討了那些“不確定”方法：

我的第一感覺是培訓(xùn)……如果團(tuán)隊沒有接受過敏捷概念以及相關(guān)方法和流程的培訓(xùn)，那么不難理解，當(dāng)你問他們：“你們在搞敏捷 嗎？”……“是的?！薄澳銈冇昧耸裁疵艚莘椒兀俊薄拔也淮_定?！薄蚁肴思一卮稹安淮_定”的另一個原因可能是他們正糾結(jié)于各個敏捷方法論五花八門 的概念中——甚至還混雜著敏捷項目管理和傳統(tǒng)項目管理……團(tuán)隊開始時用這個方法，接著糅合了另一種，在一些狀況下，還要從每種方法中都取點精髓出來。這種 做法有利有弊，它依賴于團(tuán)隊的成熟度和持續(xù)改進(jìn)的能力。

關(guān)于敏捷技術(shù)，每日站立會議、迭代計劃和單元測試名列前茅（保持著去年的態(tài)勢）：

78%	每日站立會議
74%	迭代計劃
70%	單元測試
65%	發(fā)布計劃
64%	燃盡圖
64%	回顧會議
54%	持續(xù)集成
53%	自動構(gòu)建
52%	速率
51%	編碼規(guī)范

Simon Baker在他名為“敏捷在行動”的博客里面剖析了上述敏捷技術(shù)調(diào)查結(jié)果，他還特別分析了一些得票率較低的實踐，如重構(gòu)（48%）、測試驅(qū)動開發(fā)（38%）、自動化驗收測試（25%）以及行為驅(qū)動開發(fā)（9%）：

由這些數(shù)據(jù)我可以推斷，軟件行業(yè)還是在開發(fā)很多糟糕的軟件，還很過分地把敏捷稱為流程。大家還記得個體勝過流程嗎？不管怎樣，我 想知道，投資人花錢買單，但這些糟糕的軟件實際上能給客戶帶來多少價值呢？但愿有一天更多的人能夠意識到，做到敏捷其實是要做到快速、經(jīng)濟(jì)、低風(fēng)險地響應(yīng) 不斷變化的業(yè)務(wù)需求。

“項目失敗的主要原因”的調(diào)查結(jié)果很有意思，其中有16%的調(diào)查對象反應(yīng)他們的敏捷項目從沒有失敗過，位列榜首。下面援引了一些排名前列的失敗原因：

11%	缺乏敏捷方法相關(guān)經(jīng)驗
11%	缺乏對必要的組織層面的變化的認(rèn)識
9%	企業(yè)理念及文化與敏捷理念相沖突
8%	外部要求遵循瀑布模型的壓力

進(jìn)一步實施敏捷的障礙則有：

52%	改變組織文化的能力
40%	是否有足夠的專業(yè)人士
39%	抗拒改變的慣性

就這些障礙，Dave Moran在Software Results上發(fā)表博文，分享了他的觀點:

這些障礙和擔(dān)憂映射出我們所熟知的道理：改變是艱難的。而敏捷開發(fā)就是一種改變。依照我對調(diào)查的解讀，我們獲得的這些實際收益， 恰恰和我們在敏捷實踐過程中所期望的是一致的。它們是更快、更易、堅實的每一步。團(tuán)隊士氣提升則是實施敏捷能夠獲得的第四種益處，也是實施敏捷必然的結(jié) 果。

調(diào)查還顯示，75%的參與者認(rèn)為運用敏捷方法完成項目的時間和用之前的方法差不多，或者更快些（比2010年度的83%降低了）。實施敏捷的主要好處有：

84%	管理變更優(yōu)先級的能力
77%	項目可見性得以改進(jìn)
75%	生產(chǎn)力得到提升
72%	團(tuán)隊士氣有所提升
71%	更快地響應(yīng)市場

在VersionOne站點上，你可以瀏覽到完整的調(diào)查結(jié)果（你同時可以找到2010年的結(jié)果）。今年的調(diào)查結(jié)果有哪些很突出嗎，還是說明敏捷實施趨于穩(wěn)定了？