一些評論員寫下了敏捷實施中一些常見錯誤和反模式。他們貼出了“Top X”列表，列出了需要避免的事項和他們曾在各種組織實現敏捷時見過的錯誤。

　　Target Process的Michael Dubakov寫了兩篇博文：“10個敏捷實施中最常見的錯誤”（Part 1; Part 2 ）。他認為“許多公司在敏捷實施中再三犯同樣的錯誤。”

　　他的常見錯誤列表如下：

　　1. 從一個工具開始
　　 敏捷開發是不同的。一個工具不會立刻產生影響，不會由于這一工具的存在而解決多數的問題。而且，你由于需要為工具的實施投入精力，這會影響更重要的目標--敏捷實施。

　　2. 從一個過程開始
　　多數公司是從一個過程開始的。這錯誤不是很嚴重，但更常見。如果你讀讀Scrum相關資料，會覺得它看起來很容易啟動。你實施所有的Scrum實踐，在若干sprint后發現開發有了點改進，但遠沒有達到預期。于是熱情開始消退，過程開始退化。任何公司開始嘗試任何敏捷過程前做的第一件事應該是，專注于敏捷價值，比如：溝通、協作、反饋、信任和熱情。如果你對這些價值中的任何一個做出妥協，就幾乎不可能實施一個良好地開發過程。

　　3.開發實踐就足夠了
　　有趣的是，開發人員傾向于實施技術實踐，像TDD、持續集成甚至是結對編程，但很少注意到溝通、整體團隊、客戶現場協作和回顧。

　　4. Scrum就足夠了
　　真正的錯誤在于，完全依賴Scrum，認為它是能解決所有問題的過程。它能做到這點，但你要開放思想并愿意做各種嘗試：從結對編程到BDD。最好的敏捷教練相信，Scrum的實施應該與XP技術實踐緊密的結合起來。

　　5. CSM無所不知
　　認證的Scrum Master不是神。是的，他有一些關于 Scrum的基礎知識，但許多情況下也就僅此而已。

　　6. CST無所不知
　　認證的Scrum培訓師不是上帝。是的，他知道不少，也有相當的經驗。很有可能他有能力幫助敏捷的實施，但也僅僅是幫助。他也許對你所在領域、你獨特的狀況和你所在組織的根本問題一無所知。如果你完全依賴于 CST，把敏捷實施完全委托給他，敏捷實施將會失敗。

　　7. 職能部門應該幸存
　　完全沒有理由保留職能部門和職能團隊。只要可能，大家應作為一個團隊共同工作。很明顯，如果測試人員在美國而開發人員在印度，這幾乎是不可能的。但如果每個人都在同一棟樓里，卻沒有跨職能的團隊就很愚蠢了。

　　8. 我們可以不要客戶反饋

　　敏捷主要在于快速反饋。來自客戶的反饋最為重要。如果用錯誤的方法建造了某樣東西，這是不好的。但如果建造錯了東西，那就太糟糕了。為什么？因為稍后你將不 得不把丟棄它。來自客戶的定期（快速?。┓答伨拖袷窃诒椴冀甘暮持泻叫械闹改?。需要在風向和其他因素變化時不斷調整航向?？蛻羰亲钣袃r值的團隊成員， 應該得到重視。

　　9. 自我組織很容易
　　純粹 的自我組織認為會有領導者出現。這不常出現，許多情況下沒有領導者，團隊會失去生氣、變得平庸。領導者設置一個目標，并推動團隊朝著正確的方向前進。領導者使團隊自信、有熱情及自我反思。最終實現自我組織。
　　當領導者離開團隊會發生什么？多數情況下團隊會出現倒退或慢慢退化。這是個明確的信號：能夠判斷出團隊是否實現了自我組織。真正的自我組織團隊在沒有領導者的情況下保持他們的價值和進步。

　　10. 錯誤的目標（如：客戶要求我們是敏捷的）
　　如果你的客戶堅持在他的項目中使用敏捷過程，你應該為此感謝上蒼。利用這個機會作為轉折點，開始實施敏捷。
　　不幸的是，為了得到合約，許多公司只是試著“模擬”敏捷實施。他們派人去上CSM課程、購買一個敏捷項目管理工具并淺薄地實施Scrum。他們這么做沒有什么深層次的目標和文化上的變化。他們沒有任何激情的在做這些。

　　Mike Griffiths 在博客 Leading Answers寫了篇博文：“敏捷實施反模式”，并列出了他曾見過的五個常見錯誤：

　　1. 敏捷是銀彈 - 是的，敏捷方法能節約時間、增加商業信任及創作出高質量的產品，但他們不是銀彈.他們不會扭曲空間或是時間，讓你在有限時間、預算和資源的限制下能交付更多工作。

　　2. 把敏捷作為無規范的借口 - 與他人的觀念相左，敏捷方法不是拋棄規范，跳過規劃和評估就直接開始編碼。敏捷方法中包含了許多高度規范的活動和技術，比如：測試驅動開發、 Wideband Delphi估算法，并且雙周迭代規劃及評估會議需要許多規范。

　　3.敏捷不需解釋 - 項目和團隊不在真空里；他們會與組織內許多其他干系人交流。而首先在你的團隊和你有更多影響力的領域實施敏捷也許會更容易些，但總有一天你要向其他人解釋一下這些工作實踐。

　　4. 淺反饋- 敏捷方法依賴于來自不斷發展的系統的反饋，以確認理解正確并驗收已完成工作。典型的新功能會演示給客戶，并留下測試環境供他們實驗并收集反饋。我們很容易 認為，收到很少或沒有反饋意味著用戶一定對我們開發的產品很滿意。然而更可能的是，客戶沒有真正正確地去察看它、或沒有用實際數據或場景測試它。

　　5.依戀敏捷過程 - 人們對敏捷方法抱有熱情，這是件好事。但如果人們開始過于專注于過程，并犧牲商業價值的交付，那就有問題了。通常，項目的建立和進行是為了實現一些商業改變或改進。我們不是要實踐完美的方法，最終的目標是讓我們的投資者和用戶滿意，而不是沉迷于過程或構建履歷。

　　Craig Larman和Bas Vode寫了篇名為“大型敏捷實施的十大組織障礙”的文章，這篇文章“詢問了一群在大型公司內工作或與之合作的敏捷開發專家，什么是最具挑戰性的組織障礙。

　　他們的前十列表包括下面這些：

　　10. Jeff Sutherland，Scrum的共同創始人，認為不能移除組織障礙是大型組織中的主要障礙。

　　9. Peter Alfvin，一名經驗豐富的開發經理，他參與了在施樂引入精益原則，Petri Haapio是Reaktor Innovations公司敏捷培訓部門的主管。他們兩人都提到了，為追求成本‘節約’和‘協作’的部門集中化導致了本地優化，這成為了一個障礙。

　　8. Sami Lilja，諾西網絡的敏捷開發活動全球協調官，注意到一些組織認為學習是浪費時間和金錢。

　　7. Larry Cai，上海愛立信的專家，提到職能組織（單一職能團體）是最大的障礙之一。他們阻礙單位間的溝通，并助長了單位之間的指責。

　　6.Esther Derby，顧問、教練、協調專家并著有兩本關于組織學習的書，認為促進本地優化勝過全球優化的系統是主要障礙。她給出了一些例子，包括目標管理（MBO）和預算系統。

　　5. Mike Bria，前西門子醫療系統敏捷教練，提到“自我進行改進”是個障礙。他強調了一個有問題的態度：人們在讀了一兩本書后認為“我們知道怎么做了”。

　　4. 某A.（按當事人要求匿名），某大型電子商務網站的一名Scrum培訓師，提到個人績效評估和獎勵是個主要障礙。它們會使開發人員和經理們感到沮喪，妨礙團隊績效并促進里命令和控制式管理。

　　3. Lü Yi，諾西網絡杭州的一名Scrum培訓師及大型開發團隊的部門經理，認為“承諾游戲”和不切實際的允諾是主要的組織障礙。這導致走捷徑、持續救火及遺留代碼。

　　2. Diana Larsen，協調專家、與Esther Derby合著<敏捷回顧>一書，簡單地說道，“假設一切全都與開發人員有關。”

　　1. 幾乎每個人都認為“認為敏捷是銀彈和膚淺的敏捷實施”是主要障礙。

　　除此之外，Larman和Vode提到另外兩個他們常見的阻礙：

　　Craig認為關鍵阻礙是每個工作者的文化而不是真實的團隊和團隊合作的文化。他拜訪了許多表面上在應用Scrum的個人，并看到些癥狀，如：“Jill做Jill的任務，Raj做Raj的任務”等等，而不是“整個團隊一起”的結對行動，在團體內多方學習。

　　Bas認為管理人員和第一線的人員之間的分歧是關鍵障礙。經常是這樣，管理層的變動對做真正有價值工作沒什么影響（或者說，至少沒有正面的影響）。同樣地，第一線的開發人員做的決定通常與組織的方向不一致。

　　由Cory Foy 提供的另一個列表可以在這里看到。

　　什么是實現敏捷技術中的常見錯誤和問題？團隊和組織如何才能避免它們？

　　查看英文原文：Common Mistakes in Agile Adoptions

it知識庫：敏捷實施中的常見錯誤，轉載需保留來源！

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