敏捷擁護者眼中敏捷開發的常見問題

近幾個月來，關於Scrum、技術負債、質量等等問題的爭論一直無休無止。先有James Shore的敏捷的衰落一文，而後Martin Fowler在部落格上發表了Flaccid Scrum，指出Scrum教練應該承擔更多的責任，在推廣Scrum的同時，也不能忽視技術實踐。Uncle Bob和Ron Jeffies也分別發表文章（Dirty Rotten ScrumDrels，Speed Kills，Context, My Foot，Quality-Speed Tradeoff, Are You Kidding Yourself?）表示類似的觀點。

一些敏捷實踐者在鹽湖城的敏捷圓桌會議中也對敏捷開發中的常見問題進行了討論，Sean Landis會後在個人部落格上總結了常見的十一個問題：

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

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

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

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

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

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

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

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

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

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

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

Chris Tyler在個人部落格（注，可能需要爬牆）中針對這些問題做出了回答。

問題一，是事實，但這並不是敏捷本身的問題，只不過是在敏捷匯入和實施過程中沒有引起足夠的重視。經驗豐富的敏捷教練往往十分重視工程類實踐，會強調重構在迭代中的重要性。很多的敏捷實踐(比如TDD，持續整合，重構)及很多敏捷開發者提倡的原則(比如S.O.L.I.D原則，Clean Code,Implementation Patterns )都能幫助敏捷團隊避免過多的技術負債。Uncle Bob甚至認為應該在最初的敏捷宣言中加入第五條原則“Craftsmanship over Crap”，來強調技術的對成功的敏捷專案的重要性。

問題二，是事實，但這恰恰又是敏捷的賣點。我們應該做到：謙虛有耐心；勇於承諾；團隊成員互信互助，而不是互相指責批評；承認自己的能力不足，不斷追求進步，需要的時候尋求團隊成員的幫助。很多方法論認為只能通過審查監控的手段來確保專案的順利執行，而敏捷團隊更多的是依靠個人的責任心。在優秀的敏捷團隊中，能力較弱的的團隊成員會感受到來自其他成員的壓力，要不然盡力做好，要不然只有走人。

問題三，說老實話，在瞭解敏捷之前，研發團隊才是疲於奔命。敏捷原理打破了傳統的思維模式。人很容易犯錯誤，但是很多敏捷實踐(結對程式設計，持續整合，TDD)能夠幫助開發團隊及早發現問題，糾正錯誤。因此敏捷反而把我們從傳統的思想束縛中解脫出來。可能是由於對敏捷的過度宣傳，導致大家對敏捷期望值過高，認為敏捷開發是解決所有問題的萬靈藥。其實我們匯入敏捷也是受種種因素（客戶環境，團隊對敏捷的認識程度，成員的能力）限制的。如果能夠從其他更成熟的敏捷團隊或者敏捷教練那裡吸取經驗這樣會更好，否則只能合理的逐步的匯入實踐。很多敏捷專案確實存在過於頻繁的交付，那是由於人們迫於各種壓力，“好大喜功”的天性而忽略了敏捷其實一直在強調的“根據每個迭代能夠實際釋出量”（也就是真正能夠達到Done標準的工作量）來調整下一個迭代工作量。如果團隊不能自主調整工作量，這其實已經偏離了敏捷。

問題四，是事實。但是這並不意味著不能在不成熟的組織中匯入敏捷實踐。這類組織可以逐步地匯入敏捷實踐。很多人太過心急，想“一口吃一個胖子”，但這往往是不切實際的。當然，同時必須要注意的是，不能因為採取逐步匯入的手段，而降低敏捷定義的門檻(Ron Jeffries有一篇文章"Agile Is, Not, Maybe")。

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

問題六，可能是事實，但是這在非敏捷團隊中也屢見不鮮。不可否認的是在敏捷專案中，很多人過分強調了YAGNI，因而在早期忽視了一些戰略性的目標，尤其是業務需求目標，從而導致後期重構十分困難。YAGNI是很有用的，但是需要其他實踐比如TDD和BDD（行為驅動設計）的支援。Kent Beck在極限程式設計一書中講述了怎樣藉助TDD，實現演進式設計。另外需要注意的是，這其實在很大程度上是一個平衡的問題，怎樣在YAGNI與預先設計之間做平衡。

問題七，也是事實。但是作為對產品最有熱情的人，Product Owner難道不願意花時間和精力幫助團隊開發出符合需要的產品麼？敏捷極大地縮短了從需求到軟體的週期。再也不會出現Product Owner等上6個月或者更長的時間，結果發現做出來的並不是自己想要的東西的情況。Product Owner可以在短時間內就能看到軟體，及時作出調整，因此敏捷極大地減少了開發成本以及相應的機會成本。公司高層的支援也是十分必要的。沒有高層的承諾和授權，不可能組成全功能的團隊。

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

問題九，這絕對是事實。Chris Tyler提出的建議是，儘早與其他部門溝通，大家的最終目標是一致的，各個部門應當一起尋找生產系統的瓶頸，然後努力突破瓶頸（參見約束理論）。基於這個共同目標，各個部門一起對流程進行修改，就會減少相互詬病。

問題十，這並不是一個問題！Product Owner應該控制產品發展的方向。Product Owner應當熟悉業務，明確他最終想要什麼。儘管開發團隊要利用技術手段，提供解決方案，滿足業務需求。但作為開發團隊不應該對業務方面干涉太多。

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

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

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-566757/，如需轉載，請註明出處，否則將追究法律責任。