作为思考工具的敏捷

  • 麦天志

2009 年 8 月 27 日

话题:敏捷最佳实践架构文化 & 方法

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 在最后结论中指出几个学习重点:

  • 清楚知道自己的深层目标是什么
  • 敏捷是工具,不是目标
    • 工具不会失败,但人会
    • 没有什么“好工具”或者“坏工具”,只有好或者坏的时机、地点、如何、为何的决定
  • 不要限制自己只用单一工具
    • 学会越多工具越好
    • 比较是为了认识,而不是决定
    • 集中在“为什么”,而不是“如何”
  • 不妨实验,而更重要的是享受过程
    • 不用担心最初使用时用得不对,因为没有人可以做到一开始就绝对正确
    • 只有未能从失败中学习才是真正的失败
敏捷最佳实践架构文化 & 方法