2011年度敏捷軟件開發調研結果發布

openkk 12年前發布 | 11K 次閱讀 敏捷

最近,VersionOne 揭曉了 2011 年度敏捷軟件開發調研結果,再一次向大家展示了敏捷應用和發展趨勢的第一手資料。

今年,我們進一步確信敏捷并非一時風潮。我們過半的調查對象坦言他們已經親身實踐敏捷超過兩年了,并且三分之一的人把敏捷從一家公司帶到了另一家。大約有三分之二的調查對象談到,他們公司的項目有超過半數在使用敏捷方法,有三個以上團隊實施了敏捷實踐。

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

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

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

我的第一感覺是培訓……如果團隊沒有接受過敏捷概念以及相關方法和流程的培訓,那么不難理解,當你問他們:“你們在搞敏捷嗎?”……“是的。”“你們用了什么敏捷方法呢?”……“我不確定。”……我想人家回答“不確定”的另一個原因可能是他們正糾結于各個敏捷方法論五花八門的概念中——甚至還混雜著敏捷項目管理和傳統項目管理……團隊開始時用這個方法,接著糅合了另一種,在一些狀況下,還要從每種方法中都取點精髓出來。這種做法有利有弊,它依賴于團隊的成熟度和持續改進的能力。

關于敏捷技術,每日站立會議、迭代計劃和單元測試名列前茅(保持著去年的態勢):

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

Simon Baker他名為“敏捷在行動”的博客里面剖析了上述敏捷技術調查結果,他還特別分析了一些得票率較低的實踐,如重構(48%)、測試驅動開發(38%)、自動化驗收測試(25%)以及行為驅動開發(9%):

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

“項目失敗的主要原因”的調查結果很有意思,其中有 16% 的調查對象反應他們的敏捷項目從沒有失敗過,位列榜首。下面援引了一些排名前列的失敗原因:

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

進一步實施敏捷的障礙則有:

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

就這些障礙,Dave MoranSoftware Results 上發表博文,分享了他的觀點:

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

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

84% 管理變更優先級的能力
77% 項目可見性得以改進
75% 生產力得到提升
72% 團隊士氣有所提升
71% 更快地響應市場

在 VersionOne 站點上,你可以瀏覽到完整的調查結果(你同時可以找到2010年的結果)。今年的調查結果有哪些很突出嗎,還是說明敏捷實施趨于穩定了?

查看英文原文:2011 State of Agile Survey Results Show Agile Adoption Stable

來自: InfoQ
 本文由用戶 openkk 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!