|
|
Chris Tyler在個人博客中針對這些問題做出了回答：
1. 技術負債在敏捷團隊中會快速的膨脹。
是事實，但這并不是敏捷本身的問題，只不過是在敏捷導入和實施過程中沒有引起足夠的重視。經驗豐富的敏捷教練往往十分重視工程類實踐，會強調重構在迭代中的重要性。很多的敏捷實踐(比如TDD，持續集成，重構)及很多敏捷開發者提倡的原則(比如S.O.L.I.D原則，Clean Code,Implementation Patterns )都能幫助敏捷團隊避免過多的技術負債。Uncle Bob甚至認為應該在最初的敏捷宣言中加入第五條原則“Craftsmanship over Crap”，來強調技術的對成功的敏捷項目的重要性。
2. 敏捷軟件開發團隊會想當然地認為每個團隊成員都專業，稱職并富有責任心。如果事實不是如此，項目開發很快會變得舉步維艱。
是事實，但這恰恰又是敏捷的賣點。我們應該做到：謙虛有耐心；勇于承諾；團隊成員互信互助，而不是互相指責批評；承認自己的能力不足，不斷追求進步，需要的時候尋求團隊成員的幫助。很多方法論認為只能通過審查監控的手段來確保項目的順利運行，而敏捷團隊更多的是依靠個人的責任心。在優秀的敏捷團隊中，能力較弱的的團隊成員會感受到來自其他成員的壓力，要不然盡力做好，要不然只有走人。
3. 由于對敏捷開發實踐的錯誤理解，導致團隊不合理地頻繁交付，疲于奔命。
說老實話，在了解敏捷之前，研發團隊才是疲于奔命。敏捷原理打破了傳統的思維模式。人很容易犯錯誤，但是很多敏捷實踐(結對編程，持續集成，TDD)能夠幫助開發團隊及早發現問題，糾正錯誤。因此敏捷反而把我們從傳統的思想束縛中解脫出來。可能是由于對敏捷的過度宣傳，導致大家對敏捷期望值過高，認為敏捷開發是解決所有問題的萬靈藥。其實我們導入敏捷也是受種種因素（客戶環境，團隊對敏捷的認識程度，成員的能力）限制的。如果能夠從其他更成熟的敏捷團隊或者敏捷教練那里吸取經驗這樣會更好，否則只能合理的逐步的導入實踐。很多敏捷項目確實存在過于頻繁的交付，那是由于人們迫于各種壓力，“好大喜功”的天性而忽略了敏捷其實一直在強調的“根據每個迭代能夠實際發布量”（也就是真正能夠達到Done標準的工作量）來調整下一個迭代工作量。如果團隊不能自主調整工作量，這其實已經偏離了敏捷。
4. 實施敏捷的門檻太高，敏捷開發需要更強的團隊和個人的紀律性，勇于承諾和高度的公開性，但對一個不成熟的組織來說這個門檻太高。
是事實。但是這并不意味著不能在不成熟的組織中導入敏捷實踐。這類組織可以逐步地導入敏捷實踐。很多人太過心急，想“一口吃一個胖子”，但這往往是不切實際的。當然，同時必須要注意的是，不能因為采取逐步導入的手段，而降低敏捷定義的門檻(Ron Jeffries有一篇文章)。
5. 績效差的團隊成員很難在高度公開的敏捷團隊中掩飾自己能力的不足。好的團隊往往能夠采取一定的措施來幫助這類成員。但如果沒有采取措施，這些成員往往會想方設法通過消極怠工來掩飾自己能力的不足。
絕對是事實，敏捷需要勇氣，但是這絕對是好事。態度決定一切！敏捷團隊所不能容忍的是那種故意偷懶的成員。每個人都會經歷從學徒到專家的過程（獲得技能的Dreyfus模型，及Apprenticeship Patterns: Guidance For The ASPiring Software Craftsman）。由于每個人的能力不同，背景不同，能達到的高度也是不一樣的。團隊成員應該承認個體差異，努力幫助較弱的團隊成員，使其快速成長。
6. 敏捷團隊容易過份關注眼前的短期目標，而忽視長期的戰略目標。盡管在短期內能夠取得成功，長期注定還是會失敗。
可能是事實，但是這在非敏捷團隊中也屢見不鮮。不可否認的是在敏捷項目中，很多人過分強調了YAGNI，因而在早期忽視了一些戰略性的目標，尤其是業務需求目標，從而導致后期重構十分困難。YAGNI是很有用的，但是需要其他實踐比如TDD和BDD（行為驅動設計）的支持。Kent Beck在極限編程一書中講述了怎樣借助TDD，實現演進式設計。另外需要注意的是，這其實在很大程度上是一個平衡的問題，怎樣在YAGNI與預先設計之間做平衡。
7. Product Owner承擔了太多的責任，不堪重負，從而成為團隊的瓶頸。
也是事實。但是作為對產品最有熱情的人，Product Owner難道不愿意花時間和精力幫助團隊開發出符合需要的產品么？敏捷極大地縮短了從需求到軟件的周期。再也不會出現Product Owner等上6個月或者更長的時間，結果發現做出來的并不是自己想要的東西的情況。Product Owner可以在短時間內就能看到軟件，及時作出調整，因此敏捷極大地減少了開發成本以及相應的機會成本。公司高層的支持也是十分必要的。沒有高層的承諾和授權，不可能組成全功能的團隊。
8. 敏捷的效用被過度夸大，大家的期望值太高，很多人認為導入敏捷能以最小的投入解決實際開發中的所有問題。
這可能也是事實。其實在其他方法論風行的時候，也遇到過類似的批評，比如RUP。大家都期望找到一種能夠解決所有軟件開發痛苦的方法論。作為有經驗的敏捷實踐者，教練，經理和架構師，對敏捷的宣傳應當適度，盡管敏捷確實能夠解決很多軟件開發中遇到的問題，但是它畢竟不是萬靈藥。不要使他人有過高的期望。
9. 可能出現另一種形式的“相互詬病”。成功的敏捷開發團隊一般不會成為產品開發的瓶頸，因此其他部門不能以這個為借口來指責開發團隊，但是這有可能進一步演變成為政治游戲。
這絕對是事實。Chris Tyler提出的建議是，盡早與其他部門溝通，大家的最終目標是一致的，各個部門應當一起尋找生產系統的瓶頸，然后努力突破瓶頸（參見約束理論）。基于這個共同目標，各個部門一起對流程進行修改，就會減少相互詬病。
10. 當Product Owner開始決定開發的方向，他就會被過度授權。敏捷開發中缺乏足夠的審查和平衡機制。
這并不是一個問題！Product Owner應該控制產品發展的方向。Product Owner應當熟悉業務，明確他最終想要什么。盡管開發團隊要利用技術手段，提供解決方案，滿足業務需求。但作為開發團隊不應該對業務方面干涉太多。
11. 敏捷實踐大多是針對程序員的，很難在組織內平衡工作量。缺乏對團隊中的非程序員提供更好的文檔以及培訓支持。
對于這個Chris Tyler既同意也不同意。敏捷團隊是全功能的團隊。如果業務分析師、Product Owner沒有和團隊在一起參與開發，那不是真正的敏捷。敏捷教練、經理也應該承擔培訓團隊中除了工程師以外的成員的職責。對某些團隊來說，文檔會是一個問題，因為客戶總是要求開發團隊提供文檔。其實行為驅動測試BDD就是一種既能夠提供需求文檔又能夠照顧到代碼實現的好方法。敏捷中也有文檔（參見“敏捷的文檔”），只不過是文檔的形式發生了變化，變成了XUnit測試以及代碼。進一步BDD可以成為業務人員和開發人員的橋梁，能夠使業務人員更好地理解XUnit測試以及代碼（另外其實還有Fit）。對于已經習慣于基于類似于IEEE的那種需求管理方式的Product Owner和公司高層們，對開發文檔形式的改變，他們應當保持開放和學習的心態，充分信任團隊，而不是給開發團隊帶來阻礙。
最后，Chris Taylor總結到，敏捷理論很美好，但是實踐起來還是會有各種各樣的問題，也有可能失敗。其實理論描述的是理想情況，實際情況往往不盡相同。但是我們不能因為這個就放棄向理想努力。盡管過去有很多團隊導入敏捷失敗，我們還是不能全面否定敏捷，畢竟也有很多成功的敏捷團隊。正如敏捷項目團隊在開發中不斷進行反省修正一樣，我們也要通過反省來加深對敏捷的理解和認識。
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
