这是敏捷开发般若敏捷系列的第九篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九）

经常听到有人提到敏捷开发与“本能反应”非常近似，比如凡事都需“看着办”，比如“不拘泥于形式”，比如“直击代码，不写无用的文档”等等。

那么敏捷开发与本能反应之间的差别是什么呢？

简单地说，敏捷开发就是无我状态的本能反应。

无我，无人（无我，无人，无众生）

按理说，本能反应是最接近最佳路径的，一线人员，工作现场，当下的问题，一定能在事先预定的路径之外找到更好的方法，除非有个“我”字。

1. 比如测试人员最近的工作繁忙，需要多调度几个测试人员过来，才能保证测试不延期。如果按照本能反应，开发人员中的一些人极有可能过来帮忙测试，或帮助编写一些节省人工的自动测试代码（后者是01年我们团队的做法，最终结果是25个开发人员只需要1个测试人员就能完成测试）；但如果“我们是开发人员，他们是测试人员”，尤其是“每发现一个缺陷，他们得10元，我们扣10元”，这件事情多半就办不成。

2. 比如有一个人在每日例会上说遇到了困难，而另有人对此有非常容易解决的方法。如果按照本能反应，可能一句话就能帮助节省几个小时；但如果“我有我的工作，他有他的工作”，尤其是“如果帮助了他，我的工作可能完不成”，这件事情也多半办不成。

3. 比如某个文档在这个产品中的确不需要写，但是“如果他们不写，做CMMI评估的时候我们EPG组就会比较难办”，那么这个文档到底要还是不要写就真成了一个问题。

这些我与别人的分隔，使得很难在事情上走最佳路径，而多半会在人和分工上走最佳路径，尤其是按“我”的利益来走最佳路径。在这种情况下，本能反应就是错误的。

无现在的我，无未来的我（无寿者）

一个人的时候，也会出问题。

1. 一个设计非常复杂，按本能反应，怎么也应该记录下来点东西。但是如果“我现在心里清楚设计不用写，未来也不一定是谁在维护这些代码”，那么就很容易不写这个文档，却在未来产生很大的麻烦。

2. 一个代码这样写未来可能产生缺陷，但是这个版本这样写最快。如果“我要按最快的方法写，管他未来是谁”，那么多半代码就会很烂。

如果一个人说：我不写文档的原因是“我把设计表达在代码里”，如果代码很漂亮则的确如此，如果代码又很烂，就可见前者只是一个借口。

说实话多数吆喝“代码即设计”的程序员代码都很烂。

创造无我的环境

在多数有我的环境中，对某件事情而言，每个人提出的解决方案都不相同，而且没有一个是与这个事情的最佳解决方案重合的，因为每个“我”都按自己的利益行事。

最终的结果，是为了让这些我能凑在一起工作，创造出无数的部门规范、工作流程、中间文档、计划、中间文档的评审标准等等，用来约束每个我的工作。本能反应也就被压抑了。

“如何创造一个无我的环境？”这个问题在每个具体环境中，都有具体的最佳答案，受到具体人、事、物的限制，很难一概而论。

但如果如果没有任何前提条件地回答这个问题，倒也有一个“般若”一点的答案，就是“共振”。

所谓共振，就是在能控制的范围内先取得一些成效，以此换取他人及未来的共鸣，从而推广下去的方法。世界上的各种伟人，无一不是以这种方法工作的，影响力能远达万里、千年。

作为个人，首先可以破除现在的我；作为小团队（比如3个人），可以小范围破除我人之分，共进退；作为开发组，可以局部破除分割和个体考核；作为研发部，可以在部门内部推行新的绩效考核体系，等等。

尽管这些事情看起来都有其困难之处，但与那些“万里、千年”的事情相比，却微不足道，几乎可以说基本上只要去做，没有做不成的。

不过共振的原理，就是不谋求一说就通，一做就成，而是找到事物推广的固有频率，走得太快了，难免做不成先驱，反而成为先烈。

本人曾经在10年里频繁地更换工作，目的是找到一个可以“大展宏图”的地方，但都失败了。直到在一家企业固守了3年，结局令我大吃一惊，原来每个企业都是很容易被推动的，唯一要判断的其实只有一个问题：“这个企业值得推动吗？”

共振的内容，在本系列的以后会有2篇以上的文章还会提及。

点击下载免费的敏捷开发教材：《火星人敏捷开发手册》