敏捷軟體之弊

敏捷這個含著密鑰匙誕生的「霹靂嬌娃」似乎是軟體開發行業的救星，從頭到腳、從裡到外無不閃著金光，透著與眾不同。但是，我們需要知道的是，敏捷軟體開發並非軟體開發行業的「銀彈」，因為，軟體行業所謂的「銀彈」永遠不會存在。（推薦大家看《人月神話》的沒有銀彈一章）

那麼，這個集萬千寵愛於一身的敏捷開發難道就沒有什麼瑕疵嗎？當然不可能，故本文列出其可能存在的弊端，有以下幾項：

1. 規模適用性：不適合大型專案

2. 效能適用性：如系統有比較高的關鍵性、可靠性、安全性方面的要求，則可能不完全適合

3. 組織結構適用性：組織結構的文化、人員、溝通則決定了敏捷方法是否適用。比如敏捷對人員的素質要求比較高，組織文化必須支援談判人員彼此信任。傳統的分工基本上是每人負責乙個模組，敏捷要求**共有。而敏捷要求結對，這是對溝通能力的乙個考驗。同時敏捷要求tdd，對開發人員能力要求比較高。

4. 很難把「敏捷」用好：很多團隊都只選用scrum中淺顯簡單的部分應用，例如短迭代和每日例會，更困難而且也是更重要的實踐——如回顧和改進——就不管不顧了。

5. 敏捷依然不是「銀彈」：沒有那種開發方式可以放之四海而皆準，只有不斷的被實踐才會有更好的發展

6. 失之毫釐謬以千里的方案：專案初期的大量假定或者快速收集需求可能導致專案走入誤區，特別是客戶對其自身需要毫無概念的情況下。與之類似，人之天性很容易造成某個人成為主導並將專案目標和設計引入錯誤方向的境況。開發者經常能把不恰當的方案授予客戶，並且直到最後發現問題前都能獲得客戶認同。

7. 難以讓客戶接受敏捷：我們沒有依據能直接說明敏捷軟體開發是可靠有效***的。

還有一些其他的小道看法：

1. 技術負債在敏捷團隊中會快速的膨脹。

2. 敏捷軟體開發團隊會想當然地認為每個團隊成員都專業，稱職並富有責任心。如果事實不是如此，專案開發很快會變得舉步維艱。

3. 由於對敏捷開發實踐的錯誤理解，導致團隊不合理地頻繁交付，疲於奔命。

4. 實施敏捷的門檻太高，敏捷開發需要更強的團隊和個人的紀律性，勇於承諾和高度的公開性，但對乙個不成熟的組織來說這個門檻太高。

5. 績效差的團隊成員很難在高度公開的敏捷團隊中掩飾自己能力的不足。好的團隊往往能夠採取一定的措施來幫助這類成員。但如果沒有採取措施，這些成員往往會想方設法通過消極怠工來掩飾自己能力的不足。

6. 敏捷團隊容易過份關注眼前的短期目標，而忽視長期的戰略目標。儘管在短期內能夠取得成功，長期注定還是會失敗。

7. product owner

承擔了太多的責任，不堪重負，從而成為團隊的瓶頸。

8. 敏捷的效用被過度誇大，大家的期望值太高，很多人認為匯入敏捷能以最小的投入解決實際開發中的所有問題。

9. 可能出現另一種形式的「相互詬病」。成功的敏捷開發團隊一般不會成為產品開發的瓶頸，因此其他部門不能以這個為藉口來指責開發團隊，但是這有可能進一步演變成為政治遊戲。

10.

當product owner開始決定開發的方向，他就會被過度授權。敏捷開發中缺乏足夠的審查和平衡機制。

11.

敏捷實踐大多是針對程式設計師的，很難在組織內平衡工作量。缺乏對團隊中的非程式設計師提供更好的文件以及培訓支援。

不過，敏捷軟體雖然有以上的這些可能的問題，但是畢竟它的高效、高質量是大家有目共睹的。所以大家需要深刻理解敏捷開發的實質，多多實踐，謹慎且有效地使用「敏捷」給你的軟體賦予生命力吧！