Chris Tyler在個(gè)人博客中針對(duì)這些問(wèn)題做出了回答：

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

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

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

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

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

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

4. 實(shí)施敏捷的門檻太高，敏捷開發(fā)需要更強(qiáng)的團(tuán)隊(duì)和個(gè)人的紀(jì)律性，勇于承諾和高度的公開性，但對(duì)一個(gè)不成熟的組織來(lái)說(shuō)這個(gè)門檻太高。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

it知識(shí)庫(kù)：敏捷開發(fā)的常見問(wèn)題，轉(zhuǎn)載需保留來(lái)源！

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