敏捷是最新的流行趨勢，如果你還沒有在用，那值得一試。不過在開始前，最好先確認一下你準備好了麼。下面分享一點個人經驗。
1.
為什麼引入敏捷？
這是乙個目標設定問題。僅僅因為敏捷很流行，希望學習，還是因為敏捷是另乙個「銀彈」。很簡單的乙個標準，如果沒有目標，怎麼能夠確認成功？所以在實施敏捷前問問為什麼會對你非常有幫助。
1）你所在的專案沒有任何問題
什麼，居然有這種專案，不太可能吧。那麼不妨將敏捷實施的初始目標定為發現問題。引入迭代，定義「完成」，敏捷可以幫助你讓問題浮現出來。
2）你所在的專案有乙個或幾個明確的問題
這乙個或幾個明確問題往往是很難解決的、相對長期存在的問題，可以把它們作為敏捷實施的目標。利用敏捷對問題進行分解，逐步解決。（參見：敏捷問題解決方式）
3）你所在的專案有很多問題，但是不知道如何解決
當存在很多問題的時候，往往很難理清頭緒。敏捷方法學對這種情況也非常有幫助。引入迭代，定義「完成」，這讓我們有了明確的小目標（相對於整體目標而言）。而為確保這些小目標的完成，頭緒就會變得清晰，也容易確定解決辦法。
例如：將問題「如何確保今年按質按量完成專案？」變成「如何確保本迭代按質按量完成這個功能？」。
2.
在什麼時間引入敏捷？
不如回答什麼時間不適合引入敏捷。對剛開始準備使用敏捷的團隊而言，敏捷是需要學習和練習的，這個時間可不會短。因此如果團隊的專案即將結束，並且結束後團隊就會解散，那麼最好不要在這個時候引入敏捷。
3.
什麼樣的團隊實施敏捷容易成功？
個人認為經驗豐富的敏捷教練能夠極大的增加敏捷實施成功的機率。相對來講無經驗的團隊+經驗豐富的敏捷教練效果會更明顯一些。
1）經驗豐富的團隊
那沒啥說的，讓團隊自己去做就好。可惜這樣的團隊我還沒遇到過。
2）無經驗的團隊+經驗豐富的敏捷教練
近期的乙個嘗試是，讓團隊做敏捷。團隊用敏捷的方式工作，卻沒有花太多時間了解什麼是敏捷。敏捷教練負責協助團隊進行改進，循序漸進引入敏捷實踐或其他工程實踐。這樣的話，團隊的目標完全放在產出上。
3）有經驗的團隊+經驗豐富的敏捷教練
這種配合很好。相對容易出的問題是，容易陷入到什麼是更好的敏捷的爭執中，而這種爭執對團隊目標的達成是有很大妨礙的。
4）有經驗的團隊
成功後能夠成長出不少經驗豐富的成員，但是這種團隊的失敗率還是挺高的。因為在經驗相對不足的情況下，比較難以克服實施過程中出現的思想和組織障礙，例如形式主義、「銀彈」思想、組織障礙等。
5）無經驗的團隊
這在目前還屬於常見情況，團隊對敏捷基本沒有經驗或者經驗很少。推薦引入經驗豐富的敏捷教練。常見失敗包含：一次性實施過多敏捷實踐，超出團隊承受力；目標偏移，為敏捷而敏捷；無法在實施敏捷實踐時得到改進。在實施中注意多問為什
創業，你準備好了麼
很多人提到創業就認為，很簡單啊，某天突發奇想，有個idea，找幾個人一拍腦袋，可行，然後製作原型，發布，或者找找風投。對於小idea，賺一票就走，這或許可行，但要是稍大的專案，考慮可持續發展的，就不行了，人無遠慮必有近憂，你的團隊足夠強大麼？未來是不可預知的，所以本文不打算討論個別的特例，當然成功就...
介面你準備好了麼？
上面這個笑話卻是聽起來聽funny的。這讓我聯想到，我們在實際的專案中，應該什麼時候提供介面？說道這裡大家會想到的是什麼？當然是 抽象三元則了 dry yagni rule of three。簡單的介紹下這三個。dry，don t repeat yourself，是物件導向設計原則中經常被用到的原則...
微軟大會Ignite，你準備好了麼？
微軟每年都會有一次技術盛會，這個盛會在很多國家都會舉行，他的名字叫 teched 我參加的最近的一次teched是2013年的那次，之前也曾在51cto發表過幾次大會記錄，如 不過相信中國區的同學都會發現，teched2014消失了，其實也不能說是消失了，只是這一次，中國區的teched缺席了。令人...