敏捷专家的衰落——实施敏捷必须面面俱到？

最近国外敏捷社区颇不宁静，你方唱罢我登场。

Joel 和 Jeff 的 podcast 系列，先是惹着了 Kent Beck ，然后又惹着了 Robert Martin 。

关于 Scrum 的是是非非，讨论组里仍是争论不休，InfoQ 这篇新闻：采用敏捷需要面面俱到，归纳了一些讨论组里的动向，在英文站上还有30 多个跟帖。

而更热闹的是，Jurgen Appelo 在博客里对Ron Jeffries，Robert Martin，James Shore，Alistair Cockburn 以及Martin Fowler 点名，以辛辣反讽的语气，批驳了他们的观点。

Jurgen 在文中说：

现在，那些敏捷专家告诉我，为了实施Scrum，或是XP，或是其他任何形式的敏捷开发，你都必须要做重构。你没得选。必须这么干。他们说每个人都需要单元测试, 还说因为 Scrum 忽略了一些重要（但是困难）的敏捷工程实践，让事情变得更遭，还说如果你不是每天至少有一次构建集成的话你就不是敏捷……这些日子以来，他们甚至声称 agile 就是按照 X、Y、Z 这样的实践做事。搞极限编程的人开玩笑说，把 XP 里面那些起作用的技术实践去掉就成了 Scrum。 ……

我们已经完全实施了 Scrum，但是 XP 实践还去之甚远。我们就低人一等么？敏捷专家们说，离开了 XP 实践的 Scrum，会带来很多技术债，使生产力降低，造成项目失败。每次我看到这种话，我都觉得哪里有问题。我觉得我该说点什么，但不知道怎么说。

直到今天……今天，我们所有的项目经理都认为，引入 Scrum 对我们的项目成功起到了很大帮助。我听做开发的说，（因为有 Scrum），他们终于至少有机会远离技术债了。客户也说我们现在的项目质量很高……

这些里面都见不到 XP。怎么弄的？ 为什么每个敏捷专家，还有他们的大叔（译注，这里指的是 Robert Martin，他被人称作 Uncle Bob），都在警告大家不要单纯的实施 Scrum 而不用 XP 实践，但是我们的组织却正好按照那种做法做的很成功？为了理解所发生的一切，我们得干一些敏捷 专家们这些年都没干过的事情……那就是思考，还有回溯敏捷的根源。

接下来，Jurgen 先是用复杂性理论（complexity theory）中的“混沌边界（The edge of chaos）”来支持他的观点。

他提到，在从左到右，从“有序”到“混沌”的这样一条谱系中，当系统位于居中的“复杂”区域内，它的适应性、创造能力等等都是最强的。对于那些一直在用有 序、结构化的方式生产软件的公司，敏捷会把他们从左边（即有序）向右推，推向混沌的方向，但不会进入混沌。而如果你没有用一些恰到好处的实践——包括技术 实践——敏捷方法就会把你推的太远，直至混沌。这可能就是为什么大多数敏捷专家都在说“Scrum in not enough”。但是，大多数组织并不是处在有序的位置。对于这种情况，敏捷方法会把他们从右往左推，推向有序的方向。这时，倘若强加一些实践于其上，就 会跟官僚政治一样，危害整个系统。所以一切都要依具体环境而定。

紧接着，他又谈到了博弈理论中的“进化稳定策略（ Evolutionary stable strategy ）”。他说：

除了适应性以外，在 ESS 中没有任何单个属性是必须存在的。的确，生物体的眼和脚给他们带来了好处，但是植物和细菌照样过得很好。很多公司通过市场和广告 获益，但也有些公司根本不考虑这个。很多软件开发项目用了自动化测试、现场客户、结对编程。但也有很多项目没用这些东西，也做的很好，我谢谢你们，谢谢你 们八辈祖宗。 ……

博弈理论告诉我们，从来不会有一个最佳策略可以适用于一个环境中的所有因素……认为某些敏捷实践必须得用，这种幼稚（或是自大）就跟认为人类基因是世界上最佳的 DNA 链一样。

此文一出，我们自然可以料想得到社区中的反应，Ron Jeffies 在博客回帖中说：

重构这里的关键点是逻辑，Jurgen，不是命令。我不会发号施令。我也不在乎你用不用重构。但是，如果你真的要用 Scrum，那么： - 你必须从第一个 Sprint 起开始交付软件；

• 你必须在随后的每一个 Sprint 中交付软件；
• 如果你在第一个 Sprint 里交付软件，那么当时所作出的设计就会比较脆弱，因为你没时间把一切都弄好。
• 因为这样一个设计没法从头到尾承载起项目，你就不得不改进设计；

改善既有代码的设计，即为重构之名。

你必须做重构——改善设计，不是因为我这样说你才做，而是因为除了改进代码以外你别无他法，要么就等着项目嗝屁。不过像你这么强悍，项目还嗝屁不了。

然后 Jurgen Appelo 又回应说：

重构跟单元测试或其他 XP 实践一样，都是一种投资。人们这样做，是为了 * 在将来 * 获取收益。当然，随着时间推移，脆弱的设计会变的不稳定。但最本质的问题在于，投资 * 何时 * 能够得到回报？

举个例子：如果我做的东西只会用一个月，而构建就要花三周的时间，那我为啥要做重构？……

另一个例子：如果我知道竞争对手在用 Scrum 的同时做重构，我可能就会打算不用重构。这样就可以更快把产品做完。没错，代码设计会比较糟糕，但 * 我 * 会得到合同！！他们就得不到！！* 有了 * 新合同以后，等交付完第一期产品，我就有钱再花时间做重构了。

这只是两个例子，我还能给出更多，随便什么都行，不管是重构、单元测试，还是结对编程。

你说的是“你必须这样，你必须那样”，可你忘了这是个复杂的世界。

没有什么是必须的。

在 xp yahoogroup 中，George Dinwiddie 说：

我只是想知道他们是怎么办到不用重构而远离技术债的。

Jonathon Golden 说：

有件事情让我感到很惊讶，他一直在说他们做的有多棒有多棒，但最后他还是说“嘿，我们要用一些 XP 实践了”。他肯定有些事情瞒着我们没说。他们组织里遇到 了一些问题，如果早点引入 XP 实践的话那些问题可能就不会出现了。现在他就不得不说，“怎么引入这些血淋淋的 XP 实践”。我把他这种做法叫做扯淡。

论战在 Jurgen Appelo 的博客上继续，Jason Gorman 说：

你引用了复杂性理论，但是把代码中无可逃避的熵却视而不见。
代码会变老。跟人一样。我们会新陈代谢。我们从外界摄取有用的东西，维持我们的身体所需，但与之同时我们也会摄取进一些无用的东西。 写代码跟这个很类似。软件成长的过程中，有益或是有害的东西都会加进来。代码腐烂的速度是很惊人的——尤其是在第一个小发布之前。

Ron 的意思是，如果你想保持生产效率——尤其是想在开发几周以后继续保持——那就必须与不断增长的熵作斗争。

Jurgen 回应说：

Jason，我当然了解熵。因为有熵，所以我们需要常常打扫房间。但是 Ron 的意思是，你 * 必须 * 打扫房间，他甚至还制定了一个频率：每个 Sprint！ 我打赌，不是这样的。

这要看房子。还有家庭。还有环境。

Ilja Preuß也反对 Jurgen 的说法，他说道：

Jurgen，有个有责任心的厨子会时时保证厨房整洁的。这不需要看环境，这只是干好工作的必要条件。

我刚开始学精密制造的时候，学到的最重要的一点就是每天下午清理工作环境。这一点没得商量，不需要看环境。不然你就没法干好工作。

Jurgen 继续回应：

我觉得你的类比有问题。

这也许适用于西欧国家的专业厨师，但在其他国家，其他地方就不一定适用了。你也许从没看过中国饭馆的厨房……

Ron Jeffries 稍后针对 Jurgen 的话又写了一篇博客，叫做为什么必须做重构？在博客中他说道：

对于成功的迭代项目而言，重构是一条自然法则。下面用 Scrum 的名词来解释一下原因：

1. Scrum 需要在每个 Sprint 结束的时候交付“完成”的软件。团队来决定完成的含义，但基本上都表示着系统可以运行，经过了测试、集成，可以交付给客户。
2. 在传统的 Scrum 中，Sprint 的长度为一个月，现在一般时间更短。所以团队就得在项目刚开始的两周或者一个月内交付完成的软件。
3. 软件来自于产品负责人的 backlog。它必须由特征组成。要正确的做到 Scrum，我们不能叫做基础架构之类的东西，我们要交付特征。
4. 所以，在开始几个 Sprint 中，团队就没时间把最终产品所需要的整个稳定的基础架构做好。我们只能做好一小部分而已。
5. 但是，整个产品肯定需要一个大型的，性能强劲的，更加稳定的架构。
6. 所以项目中的架构必须要改，不是因为我这样说你才这样做，而是因为刚一开始我们没有，而到最后我们得需要。
7. 要修改基础架构的方法不多。我们可以每个 Sprint 重写一次，或者是对它做改进。每次都重写的话效率太低。所以我们必须做改进。软件的改进就是重构。这就是重构。

在我们学到怎么改进设计之前，Scrum 有可能给我们带来好处，但是我们肯定发挥不了最大的能力，时间慢慢过去，我们还会面临速度减缓的危险。

这场论战牵涉范围甚众，这个话题就先报道到这里，回见。