Henrik Kniberg 于阿姆斯特丹举行的 Integrating Agile 2009 大会上发表了 “敏捷”作为思考工具的主题演说，以另一个角度去思考引入敏捷方法当中遇到的问题。
Henrik 开宗明义说道：不同敏捷方法如极限编程、Scrum、精益等都是工具，他指出：
所有用作完成任务或达成目的的东西，都是工具。
接下来，他将工具做了不同的分类：
- “成套工具”（Toolkits），又称作框架（Frameworks），例如 Scrum、RUP
- “过程工具”（Process tools），又称组织模式（Organisational patterns），例如结对编程
- “思考工具”（Thinking tools），又称思维方式，例如约束定律（Theory of Constraints）、系统思维（System Thinking）
- “有形工具”（Physical tools）
Henrik 亦指出开发团队一般的演化过程：
- 杂乱无章的工作方法；
- 瀑布式开发加上以元件为本的组织架构；
- 变为 ScrumButt，也就是宣称使用 Scrum 但因为种种理由而不完全使用 Scrum 实践和原则；
- 真正的 Scrum 团队，并以特征团队组织人手
- 开发团队以 Scrum 和特征团队作开发，支援团队以看板方式进行维持活动；
这带出一个问题，什么是好的工具和方法？Henrik 在文中也作出了回答：
工具的价值在于它如何限制你的行为，没有单一方法和工具是完整的，必须适当配合，而比较工具和方法是为了了解，而不是作出判断。 从这里再带出深层次一点：
先集中在 “为什么” 而不是 “如何”。
这不只是纸上谈兵，Henrik 也举了具体例子，透过系统思维去分析事情的利弊以及了解更深层次的原因，而不是解决表面征状了事，文中的例子是文中最精彩部份，不容错过。
Henrik 在最后结论中指出几个学习重点：
清楚知道自己的深层目标是什么
敏捷是工具，不是目标
- 工具不会失败，但人会
- 没有什么“好工具”或者“坏工具”，只有好或者坏的时机、地点、如何、为何的决定
不要限制自己只用单一工具
- 学会越多工具越好
- 比较是为了认识，而不是决定
- 集中在“为什么”，而不是“如何”
不妨实验，而更重要的是享受过程
- 不用担心最初使用时用得不对，因为没有人可以做到一开始就绝对正确
- 只有未能从失败中学习才是真正的失败
暂无签名
最新发布
和 Dave Thomas 谈开始实施敏捷时的困难
2009 年 10 月 22 日
用"蕃茄"来减轻时限压力
2009 年 6 月 3 日
艾永亮谈腾讯的自运转团队
2011 年 8 月 15 日
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
达达集团高可用系统架构进化之路
分布式研发团队管理哲学
弹性云原生大数据系统架构实践
评论