分享一下我之前整理幾篇跟估算相關的文章給各位當個參考：
http://bit.ly/scrum-estimation-91
最近這半年，也有幾個場子邀請我去講過相關的主題，分別是
1. Agile Tour Taipei 2015
2. JCConf 2015
3. kkbox 內部 tech talk
4. skilltree day
這邊也貼上參加學員所整理的筆記心得文：
http://bit.ly/scrum-estimation-model-notes
想額外說的是，我相信很多朋友都被「假的敏捷」荼毒過，
往往就是高掛著某主管或某人的KPI，就這樣不分青紅皂白的強暴底下做事的人。
這不是敏捷的錯，是那些人跟他們方式的問題。
最大的問題在於，他們根本沒去聆聽實際做事的人，痛點在哪，需要什麼樣的幫助。
就如同我在該主題中一再強調的，
與其導什麼敏捷開發、TDD （因為這兩個都是我教育訓練的主題），
還不如撥個雙螢幕跟SSD給開發團隊使用，效果來得顯著有效。
敏捷、Scrum 都只是個詞，重點還是在解決問題，run 什麼真的不是這麼重要的。
design pattern 亂用的時候一樣是害死成千上萬的工程師，
也不代表 design patterns 就是十惡不赦，這是一樣的道理的。
我自己在很多團隊成功進行導入XP practice跟敏捷轉型，
第一個重點都是不要執著，重點不在導入什麼東西，而在可以改善什麼痛點。
所以第一件事就是聆聽開發團隊的痛點，取交集，爭取資源，累積credit，
讓上頭知道這一切都是為了滿足上頭的需求而需要進行改善，
讓做事的人明白，是來幫助他們改善痛點的，
搭起這道橋樑，做出讓上頭接受的成果，做出讓做事人嚐到的甜頭，
不執著，一切都在持續改善跟自主管理中自然發展，一切就會水到渠成。
而這對我來說，不是台灣或非台灣的問題，
在於導入人員對軟體開發流程（不只敏捷）瞭解有多深，
在於導入人員是不是跟著大家一起挽起袖子打仗，
在於導入人員是不是曾經也是打仗的一員，還是只出張嘴下指導棋的那種傢伙，
在於導入人員是否贏得開發團隊的信任，是否贏得主管與高階長官的信任，
在於導入人員是否能用心體會、聆聽、引導大家的痛點，
只要導入人員想的是「改變」，而不是「改善」，就很容易走偏。
因為他會被某個有形的框架綁住，而無法活學活用，
他在乎的是有沒有正確的使用某個方法論或框架，
而不是開發團隊是否快樂、是否改善了痛點，
當他失敗時，他會覺得都是這些人、團隊、文化無法改變，
他覺得不是他的問題，也不是敏捷或什麼方法論的問題，都是別人的問題。
相同的，很多人都是找藉口，不是找方法，
所以都歸咎在敏捷的問題，歸咎在公司環境、文化的問題，歸咎在老闆的問題，
我得說，的確很多時候都是環境、文化、老闆的問題，
但有心的人會找到改善這些問題的法子。
Show, don't just talk.
ptt 要討論這些到很深入，不是挺容易的，但歡迎大家在 facebook 上找我討論。
我的FB粉絲專頁是 https://www.facebook.com/91agile/
也可以在上述我的文章底下留下你的 comment。
最後，對我來說，
敏捷開發團隊最有效的運作方式就是「持續改善」、「自主管理」。
當大家發現有足夠的權利、能力、動機，來對自己好一點、為自己好一點，
他們就會持續改善。