Chris Tyler在個人博客中針對這些問題做出了回答：

1. 技術(shù)負(fù)債在敏捷團隊中會快速的膨脹。

是事實，但這并不是敏捷本身的問題，只不過是在敏捷導(dǎo)入和實施過程中沒有引起足夠的重視。經(jīng)驗豐富的敏捷教練往往十分重視工程類實踐，會強調(diào)重構(gòu)在迭代中的重要性。很多的敏捷實踐(比如TDD，持續(xù)集成，重構(gòu))及很多敏捷開發(fā)者提倡的原則(比如S.O.L.I.D原則，Clean Code,Implementation Patterns )都能幫助敏捷團隊避免過多的技術(shù)負(fù)債。Uncle Bob甚至認(rèn)為應(yīng)該在最初的敏捷宣言中加入第五條原則“Craftsmanship over Crap”，來強調(diào)技術(shù)的對成功的敏捷項目的重要性。

2. 敏捷軟件開發(fā)團隊會想當(dāng)然地認(rèn)為每個團隊成員都專業(yè)，稱職并富有責(zé)任心。如果事實不是如此，項目開發(fā)很快會變得舉步維艱。

是事實，但這恰恰又是敏捷的賣點。我們應(yīng)該做到：謙虛有耐心；勇于承諾；團隊成員互信互助，而不是互相指責(zé)批評；承認(rèn)自己的能力不足，不斷追求進步，需要的時候?qū)で髨F隊成員的幫助。很多方法論認(rèn)為只能通過審查監(jiān)控的手段來確保項目的順利運行，而敏捷團隊更多的是依靠個人的責(zé)任心。在優(yōu)秀的敏捷團隊中，能力較弱的的團隊成員會感受到來自其他成員的壓力，要不然盡力做好，要不然只有走人。

3. 由于對敏捷開發(fā)實踐的錯誤理解，導(dǎo)致團隊不合理地頻繁交付，疲于奔命。

說老實話，在了解敏捷之前，研發(fā)團隊才是疲于奔命。敏捷原理打破了傳統(tǒng)的思維模式。人很容易犯錯誤，但是很多敏捷實踐(結(jié)對編程，持續(xù)集成，TDD)能夠幫助開發(fā)團隊及早發(fā)現(xiàn)問題，糾正錯誤。因此敏捷反而把我們從傳統(tǒng)的思想束縛中解脫出來。可能是由于對敏捷的過度宣傳，導(dǎo)致大家對敏捷期望值過高，認(rèn)為敏捷開發(fā)是解決所有問題的萬靈藥。其實我們導(dǎo)入敏捷也是受種種因素（客戶環(huán)境，團隊對敏捷的認(rèn)識程度，成員的能力）限制的。如果能夠從其他更成熟的敏捷團隊或者敏捷教練那里吸取經(jīng)驗這樣會更好，否則只能合理的逐步的導(dǎo)入實踐。很多敏捷項目確實存在過于頻繁的交付，那是由于人們迫于各種壓力，“好大喜功”的天性而忽略了敏捷其實一直在強調(diào)的“根據(jù)每個迭代能夠?qū)嶋H發(fā)布量”（也就是真正能夠達到Done標(biāo)準(zhǔn)的工作量）來調(diào)整下一個迭代工作量。如果團隊不能自主調(diào)整工作量，這其實已經(jīng)偏離了敏捷。

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

是事實。但是這并不意味著不能在不成熟的組織中導(dǎo)入敏捷實踐。這類組織可以逐步地導(dǎo)入敏捷實踐。很多人太過心急，想“一口吃一個胖子”，但這往往是不切實際的。當(dāng)然，同時必須要注意的是，不能因為采取逐步導(dǎo)入的手段，而降低敏捷定義的門檻(Ron Jeffries有一篇文章)。

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

絕對是事實，敏捷需要勇氣，但是這絕對是好事。態(tài)度決定一切！敏捷團隊所不能容忍的是那種故意偷懶的成員。每個人都會經(jīng)歷從學(xué)徒到專家的過程（獲得技能的Dreyfus模型，及Apprenticeship Patterns: Guidance For The ASPiring Software Craftsman）。由于每個人的能力不同，背景不同，能達到的高度也是不一樣的。團隊成員應(yīng)該承認(rèn)個體差異，努力幫助較弱的團隊成員，使其快速成長。

6. 敏捷團隊容易過份關(guān)注眼前的短期目標(biāo)，而忽視長期的戰(zhàn)略目標(biāo)。盡管在短期內(nèi)能夠取得成功，長期注定還是會失敗。

可能是事實，但是這在非敏捷團隊中也屢見不鮮。不可否認(rèn)的是在敏捷項目中，很多人過分強調(diào)了YAGNI，因而在早期忽視了一些戰(zhàn)略性的目標(biāo)，尤其是業(yè)務(wù)需求目標(biāo)，從而導(dǎo)致后期重構(gòu)十分困難。YAGNI是很有用的，但是需要其他實踐比如TDD和BDD（行為驅(qū)動設(shè)計）的支持。Kent Beck在極限編程一書中講述了怎樣借助TDD，實現(xiàn)演進式設(shè)計。另外需要注意的是，這其實在很大程度上是一個平衡的問題，怎樣在YAGNI與預(yù)先設(shè)計之間做平衡。

7. Product Owner承擔(dān)了太多的責(zé)任，不堪重負(fù)，從而成為團隊的瓶頸。

也是事實。但是作為對產(chǎn)品最有熱情的人，Product Owner難道不愿意花時間和精力幫助團隊開發(fā)出符合需要的產(chǎn)品么？敏捷極大地縮短了從需求到軟件的周期。再也不會出現(xiàn)Product Owner等上6個月或者更長的時間，結(jié)果發(fā)現(xiàn)做出來的并不是自己想要的東西的情況。Product Owner可以在短時間內(nèi)就能看到軟件，及時作出調(diào)整，因此敏捷極大地減少了開發(fā)成本以及相應(yīng)的機會成本。公司高層的支持也是十分必要的。沒有高層的承諾和授權(quán)，不可能組成全功能的團隊。

8. 敏捷的效用被過度夸大，大家的期望值太高，很多人認(rèn)為導(dǎo)入敏捷能以最小的投入解決實際開發(fā)中的所有問題。

這可能也是事實。其實在其他方法論風(fēng)行的時候，也遇到過類似的批評，比如RUP。大家都期望找到一種能夠解決所有軟件開發(fā)痛苦的方法論。作為有經(jīng)驗的敏捷實踐者，教練，經(jīng)理和架構(gòu)師，對敏捷的宣傳應(yīng)當(dāng)適度，盡管敏捷確實能夠解決很多軟件開發(fā)中遇到的問題，但是它畢竟不是萬靈藥。不要使他人有過高的期望。

9. 可能出現(xiàn)另一種形式的“相互詬病”。成功的敏捷開發(fā)團隊一般不會成為產(chǎn)品開發(fā)的瓶頸，因此其他部門不能以這個為借口來指責(zé)開發(fā)團隊，但是這有可能進一步演變成為政治游戲。

這絕對是事實。Chris Tyler提出的建議是，盡早與其他部門溝通，大家的最終目標(biāo)是一致的，各個部門應(yīng)當(dāng)一起尋找生產(chǎn)系統(tǒng)的瓶頸，然后努力突破瓶頸（參見約束理論）。基于這個共同目標(biāo)，各個部門一起對流程進行修改，就會減少相互詬病。

10. 當(dāng)Product Owner開始決定開發(fā)的方向，他就會被過度授權(quán)。敏捷開發(fā)中缺乏足夠的審查和平衡機制。

這并不是一個問題！Product Owner應(yīng)該控制產(chǎn)品發(fā)展的方向。Product Owner應(yīng)當(dāng)熟悉業(yè)務(wù)，明確他最終想要什么。盡管開發(fā)團隊要利用技術(shù)手段，提供解決方案，滿足業(yè)務(wù)需求。但作為開發(fā)團隊不應(yīng)該對業(yè)務(wù)方面干涉太多。

11. 敏捷實踐大多是針對程序員的，很難在組織內(nèi)平衡工作量。缺乏對團隊中的非程序員提供更好的文檔以及培訓(xùn)支持。

對于這個Chris Tyler既同意也不同意。敏捷團隊是全功能的團隊。如果業(yè)務(wù)分析師、Product Owner沒有和團隊在一起參與開發(fā)，那不是真正的敏捷。敏捷教練、經(jīng)理也應(yīng)該承擔(dān)培訓(xùn)團隊中除了工程師以外的成員的職責(zé)。對某些團隊來說，文檔會是一個問題，因為客戶總是要求開發(fā)團隊提供文檔。其實行為驅(qū)動測試BDD就是一種既能夠提供需求文檔又能夠照顧到代碼實現(xiàn)的好方法。敏捷中也有文檔（參見“敏捷的文檔”），只不過是文檔的形式發(fā)生了變化，變成了XUnit測試以及代碼。進一步BDD可以成為業(yè)務(wù)人員和開發(fā)人員的橋梁，能夠使業(yè)務(wù)人員更好地理解XUnit測試以及代碼（另外其實還有Fit）。對于已經(jīng)習(xí)慣于基于類似于IEEE的那種需求管理方式的Product Owner和公司高層們，對開發(fā)文檔形式的改變，他們應(yīng)當(dāng)保持開放和學(xué)習(xí)的心態(tài)，充分信任團隊，而不是給開發(fā)團隊帶來阻礙。

最后，Chris Taylor總結(jié)到，敏捷理論很美好，但是實踐起來還是會有各種各樣的問題，也有可能失敗。其實理論描述的是理想情況，實際情況往往不盡相同。但是我們不能因為這個就放棄向理想努力。盡管過去有很多團隊導(dǎo)入敏捷失敗，我們還是不能全面否定敏捷，畢竟也有很多成功的敏捷團隊。正如敏捷項目團隊在開發(fā)中不斷進行反省修正一樣，我們也要通過反省來加深對敏捷的理解和認(rèn)識。

it知識庫：敏捷開發(fā)的常見問題，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。