分享一下我之前整理几篇跟估算相关的文章给各位当个参考：
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。
最后，对我来说，
敏捷开发团队最有效的运作方式就是“持续改善”、“自主管理”。
当大家发现有足够的权利、能力、动机，来对自己好一点、为自己好一点，
他们就会持续改善。