敏捷开发智慧敏捷系列之一：序言 .

本文将解决各种敏捷中需要辩证思考的问题，包括：写文档还是不写文档？拥抱变更还是迭代期内无变更？持续交付的产品因为不完整被客户鄙视怎么办？做架构设计还是不做？突出进度忽略了质量怎么办？我们不用文档就能开发但客户偏偏要文档怎么办？自动化测试费力而且测试代码可能跟应用代码一起被抛弃怎么办？……

缘起

敏捷开发中一直有几个根本问题无法回答：什么是敏捷？怎样知道我是否敏捷了？应该怎样推行敏捷？敏捷的未来会怎样？……

开始业界还有压力，因为这些问题如此难以回答。后来这些问题问得多了，大家也就释然了：“这些都是没有答案的问题。”

身为投身业界较早的一员，感觉草草收场太有点对不起那些心中一直有疑问的后来者了，那种感觉就像黑暗中侥幸躲过一块拌脚的石头，总是想停下来把它除掉。

最近在看一些业界之外的东西，才知道这些问题在很久以前就解决了。答案非常真切，能令接触敏捷很久的我一看就知道问题已经结束了。

不过，这个答案相当不容易用语言描述，憋了很久还是没能写出来，现在和最近的将来都心里明白但写不出来。

本系列不是直接描述这些根本问题的答案的，而是最近在微博、博客上又看到一些关于敏捷实践的纷争，而心里很清楚纷争的原因，所以特写此系列帮助后来者辨析一些概念，建立一些基本的思考方法。

兴许写几篇这个系列，就能帮我把那个系列写出来了呢。

题解

一直以来都有数据与信息的辨析。就是说数据是死的，要从中分析得到信息，才能对人有所帮助。

实际上完整的层次结构是：数据，信息，知识，智慧。这个是在《冬吴相对论》的很早一期中顺带提及的，但对我们推广敏捷很有帮助。

数据，基本上接近客观事实，不只是指数字，也指那些真实发生的所有事情，对应各种真实的敏捷案例。

信息，指从实际事情中提炼出来的有意义的实践，对应我们看到的各种用户故事、自动化测试、测试驱动等敏捷实践。

知识，指这些有意义的实践被文字化描述，广为传播。

智慧，指这些广为传播的实践的背后，所蕴含的真正道理。

数据与信息，都是受到“因缘”约束的。因是内因，缘是外部条件。

（这个案例不是敏捷开发的，但很直观）“在一家数字电视企业，人们大规模地做了软件仿真代替真实硬件，来防止太多环节的硬件捣乱”，这整句话就是数据，而“软件仿真”就是从中提出的信息。若把它写下来传播，就成了知识。

但是是不是哪里都适用呢？不是。

当时的内因，在于这家企业的研发团队很强（是我个人从事一线研发9年中经历过最强的），能够完成这一系列仿真，这个是追求卓越工作的内因；而外部环境中，从前到后硬件环节多达10层有余，客观上导致了不仿真是开发不下去的。

像这种实践，就存在很大的因缘成分，一旦离开因缘，很难重现。

敏捷开发中的多数实践要好得多，因为之所以被抽取出来，就是多少存在共性和可推广性。但这并不表明其可以无限超越因缘限制。

在敏捷开发中大家都很崇拜案例，因为案例是真实的，表明这件事情真正发生过。所以每当一方能指出“某某公司就是使用XX方法，从而才能……的”的时候，都会感觉非常立刻找到了答案，无需多说。

但是案例背后的问题在于：案例太真实了，以至于它们有的只能在一个地方发生，有的甚至只能发生一次。

智慧敏捷

而智慧，则是超越因缘的。（之后我们会看到其实“妙智慧”就是“般若”才真正超越因缘）

那个团队为什么使用软件仿真？因为追求卓越工作？因为要克服硬件限制？当然不是。

一家企业不会无缘无故追求卓越（尤其是这种内部技术层面的），而要克服硬件限制，加班加点多测试几次也能通过。

早在开始，团队并没有尝试软件仿真绕过硬件，也在以普通的妥协和加班来换取硬件大发慈悲，直到遇到一个最不讲理的硬件：IC卡。这东西连个显示界面都没有，不能单步运行，不能显示中间状态，就傻乎乎地以极低的速度执行极少数业务命令，其他一切无视。这是第一次被逼无奈，放弃加班加点或多和IC卡开发者沟通之类的笨方法，开始用仿真卡代替真实卡。

而在这一活动被证实简单有效后，其他几个不太讲理的硬件也被仿真了，最终系统越做越顺。曾经有一年聚会的时候，得知当时的市场占有率是60%（之后不详）。

在整个过程里边真正驱动大家改变看法的，不是“追求卓越”，而是：“到底哪种方法最快呢？”刚开始答案是“蛮干”，而后来则是“巧干”。

千万不要误解“蛮干”，在很多情况下“巧干”很容易产生需求镀金和过度设计，蛮干反而最快；但也不能总是蛮干，有时候撞上南墙，还是要巧干才行。

那到底蛮干好还是巧干好？都不好，他们都属于“信息”层面的东西，受到因缘的限制。这个问题一旦这么问，就无解了。

好的问题是：“到底哪种最快？”每次问这个问题，每次答案可能都不相同，但每次答案却总是正确的，这是智慧。

本系列会帮助辨析一些常见的问题，来探讨如何智慧地使用敏捷方法。这些。问题包括：

写文档还是不写文档？拥抱变更还是迭代期内无变更？持续交付的产品因为不完整被客户鄙视怎么办？做架构设计还是不做？突出进度忽略了质量怎么办？我们不用文档就能开发但客户偏偏要文档怎么办？自动化测试费力而且测试代码可能跟应用代码一起被抛弃怎么办？……

这些问题没有开头提的那些问题那么本质，但是也能反映出一些敏捷实践层面不好解决的问题，在智慧层面其实早有答案。

这些问题几乎都是本人在工作中碰到或培训/咨询中被问到的问题，若掌握了智慧层面的内容，这些问题即使被第一次问到而之前从没考虑过，也能在5分钟后让发问人满意而归。

每个人在理解了敏捷开发中的智慧后，都能做到这一点；或者反之：当事人之所以困惑良久而来发问，是因为一直没能超脱于因缘之外观察敏捷实践背后的智慧。