這是敏捷開發一千零一問系列的第三十四篇。（在這裡提問，之一，之二，之三，問題總目錄）問題如題。這是很多企業都問過的問題，尤其是那些底子比較薄弱，想引入敏捷開發但又很擔心失敗的公司。分析現在整體上敏捷開發培訓市場的課程分為幾大類。第一類：概念類介紹基本概念為主的，特點是大綱“全面”但比較淩亂，嘗試把所有敏捷開發的要素都覆蓋到但很難深入到實踐的層面。這類課程的價值其實不大，因為所有內容都能百度到或在某本書中讀到，所以
如果只是想知道敏捷開發的基本概念，建議以自學為主。第二類：實戰類是以實戰訓練為目標的，包括使用者故事編寫、計劃、估算、跟蹤這類內容。很多人都很希望直接能從一次課程中學會這些技能，但很可惜，幾乎做不到。若沒有任何經驗參加這類課程，常常會在課堂上感覺到“很奇特”“很好”，但回去後會發現困難重重，用不起來。實戰累課程一般與下面提到的“最佳實務類”課程有所重合，也就是說課堂實戰應該是建立在之前的實際企業實踐過的基礎上的，而不是只是練習一些傳說中的實踐。第三類：案例類或最佳實務類以業界的最佳實務為主的課程，包括具體活動的技巧，某些活動的變通，特定領域的實現等。有一個誤區是很多個人或企業都很想從“一個完整案例”中學習到所有知識。實際上企業千變萬化，還沒有一家企業說自己的敏捷開發做到了極致以至於值得全民學習。此外企業的差異也使得學習過程不會很順利，比如Google招聘人的時候會選擇對敏捷思想認同的員工，就這一點就沒幾個企業能“學會”。所以實際上講師要積累的最佳實務和案例應該非常廣泛，並能根據客戶的需要摘選其中一些講解，而不能手裡拿著鎚子把什麼問題都當作釘子。
方案
下面介紹一下我個人觀察及理解的引入敏捷開發培訓或諮詢的比較好的時機。
步驟1：個別團隊自主嘗試階段這個階段團隊無需正式的培訓，可以通過閱讀書籍（推薦：《硝煙中的Scrum與XP》）或網路讀物（推薦《火星人敏捷開發手冊》），自行進行一段時間的嘗試。敏捷開發的前半年可以說是個痛苦的過渡期，最好不要培訓完了才“陣痛”，而是陣痛後再重新學習為好。
步驟2：通過培訓提升階段在嘗試半年以上並發現新問題後，可以選擇第二類實戰類或第三類最佳實務類培訓，以解決實際問題。建議在確定培訓講師前，與講師進行30分鐘左右的電話售前溝通，參會者必須包括曾經嘗試敏捷又遇到問題的團隊成員。通過此溝通，可以大致瞭解講師是否有能力和思路解決自己遇到的問題。具體培訓或諮詢過程中，應該少涉及基本概念，多涉及實戰和案例，並針對客戶的實際問題變換方法。
步驟3：通過參與會議和短訓進行提升的階段某些內容在培訓課程上是很難展開的，或者說在“培訓”這個階段，很難深入討論某些問題，比如“績效考核”“組織圖變革”“使用者群定位”“大團隊管理”等等。無論說得多好，都是聽起來很美，但很難直接應用。但如果有兩三年的積累和嘗試之後，再去討論這些重點問題，就變得可能了。不過，由於需求很少，很難找到培訓課程，不如通過參會和短訓（幾個小時的）來擷取知識。在這個層面上學習的人，不能指望聽到答案，能聽到思路就足夠了，剩下的都是獨立思考出來的。
其他問題
問：培訓好還是諮詢好？答：很難回答的一個問題。建議若資金有限，先自己嘗試，在做內訓即可。除非資金充足，不做諮詢。本人做過多年諮詢，發現要真正深刻認識一個企業的問題，大約需要1年左右；而要能提出左右企業的想法，則需要2年。因此十幾天或幾十天的諮詢，都很難觸動企業研發的本質，只能帶來一些看似能用但困難重重的實踐。這些錢最後多數都交學費了。我曾經呆過的一家國外諮詢公司，都有諮詢師常駐在歐洲客戶那裡，最多的一家客戶駐紮了12位全職諮詢師，全是各種研發管理類的諮詢。所以，不如企業內部的骨幹去主動、深入地學習敏捷開發，然後根據自己企業的狀況來變通使用，比讓諮詢師來瞭解企業的狀況要來得容易，也更有價值。除非，能發動上百天的長期諮詢活動。
問：敏捷開發技術類培訓怎麼做？答：敏捷開發的技術類培訓不好找，建議曲線救國。多數做培訓講師的都脫離實踐一段時間了，而正在實踐的人又還不足以出來培訓，所以非常兩難。替代方法包括：1. 招聘一個同行業、同技術的人員來公司，把技術帶過來2. 自己團隊找一個技術優秀而又喜歡學習的人出去學學，外加自己摸索3. 多參加外面的會議，多上網找找，外加自己摸索------------實際上，這些答案反應的是“火星人諺語”的思路，尤其是“問問題的人負責找答案”，具體可見http://blog.csdn.net/cheny_com/article/category/915225。
