作为思考工具的敏捷

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亦指出开发团队一般的演化过程：

1. 杂乱无章的工作方法；
2. 瀑布式开发加上以元件为本的组织架构；
3. 变为ScrumButt，也就是宣称使用 Scrum 但因为种种理由而不完全使用 Scrum 实践和原则；
4. 真正的 Scrum 团队，并以特征团队组织人手
5. 开发团队以Scrum和特征团队作开发，支援团队以看板方式进行维持活动；

这带出一个问题，什么是好的工具和方法？Henrik在文中也作出了回答：

工具的价值在于它如何限制你的行为，没有单一方法和工具是完整的，必须适当配合，而比较工具和方法是为了了解，而不是作出判断。

从这里再带出深层次一点：

先集中在 “为什么” 而不是 “如何”。

这不只是纸上谈兵，Henrik也举了具体例子，透过系统思维去分析事情的利弊以及了解更深层次的原因，而不是解决表面征状了事，文中的例子是文中最精彩部份，不容错过。

Henrik在最后结论中指出几个学习重点：

• 清楚知道自己的深层目标是什么
• 敏捷是工具，不是目标
  • 工具不会失败，但人会
  • 没有什么“好工具”或者“坏工具”，只有好或者坏的时机、地点、如何、为何的决定

• 不要限制自己只用单一工具
  • 学会越多工具越好
  • 比较是为了认识，而不是决定
  • 集中在“为什么”，而不是“如何”
• 不妨实验，而更重要的是享受过程
  • 不用担心最初使用时用得不对，因为没有人可以做到一开始就绝对正确
  • 只有未能从失败中学习才是真正的失败