从这场著名的论战看来，国外采用敏捷的公司不但众多，而且越来越多，而且最常用的一种方式就是从Scrum做起[1]。为什么先用Scrum呢？因为Scrum主要是管理的实践。对组织里的领导来说，管理是其基础，改善的管理实践对他们是最能看得见、摸得着的，也最容易被他们接受。那么采用了Scrum之后的组织，是否真正敏捷了呢？是否达到实施敏捷的目的了吗？
Jame Shore认为，许多组织采用了Scrum，但是情况变得更糟：“So, unfortunately, a lot of self-described Agile projects are going to fail.”[2]。
然而Jurgen声称，他们的公司只用了Scrum，也相当成功：“Today all our project managers agreed that the introduction of Scrum has increased the success of our projects. ”[3]。
其实单独采用Scrum能否成功这才是这场论战的焦点之争。如果是实践是检验真理的唯一标准，暂且认为他们二人所述属实，则Shore的数据来自更多的公司，明显占了上风。而Jurgen仅从自己公司入手，在随后的辩论过程中，更让人疑窦丛生，比如Jonathon Golden就认为Jurgen一定有什么事儿瞒着我们：“There is clearly something he's not telling us.”
其实组织采用敏捷，目的无非体验是敏捷带来的好处：改善软件质量，提高软件交付的成功率。那么敏捷怎样达到这一点呢？单独采用Scrum为什么不够呢，Ron Jeffies给出了Scrum必须使用重构这个XP实践的理由，相当精彩[4]：
引用
如果你真的要用Scrum，那么：
* 你必须从第一个Sprint起开始交付软件；
* 你必须在随后的每一个Sprint中交付软件；
* 如果你在第一个Sprint里交付软件，那么当时所作出的设计就会比较脆弱，因为你没时间把一切都弄好。
* 因为这样一个设计没法从头到尾承载起项目，你就不得不改进设计；
改善既有代码的设计，即为重构之名。你必须做重构...
* 你必须从第一个Sprint起开始交付软件；
* 你必须在随后的每一个Sprint中交付软件；
* 如果你在第一个Sprint里交付软件，那么当时所作出的设计就会比较脆弱，因为你没时间把一切都弄好。
* 因为这样一个设计没法从头到尾承载起项目，你就不得不改进设计；
改善既有代码的设计，即为重构之名。你必须做重构...
可见即使只采用Scrum的组织，重构也是很有必要的。既然已经采用Scrum了，不妨也采用重构吧。看看另一个实践TDD：
测试驱动开发与传统先写代码后补测试相比，更能保证代码有对应的测试覆盖。这样重构之后，通过运行单元测试可以保证重构不会引入新的bug。这也是为什么TDD把重构纳入它的一个步骤的原因。当然除此之外，TDD还有很多其它好处。所以既然重构了，为什么不采用TDD呢？
那么结对编程呢？很多尝试过结对编程的人说，2个人一块干活确实不如分别干活快；当然也有人得出类似结论，结对编程在某些情况下合适，在其它一些情况下不合适。但是看看结对编程给代码带来的质量的提高吧；看看频繁交流对组员带来的技术上的提高；看看交换结对后每个人都能熟悉每个模块，是怎样降低了人员流失带来的风险，等等诸多好处。对这些我想首先是毋庸置疑的。其次结对编程真的会使生产效率下降吗？以前有数据说编程人员的最高最低效率相差能够达到20倍，你的项目中会全部都是效率很高的牛人吗？他们一天8小时会一直效率很高吗？数据说明编程人员一天高效率的时间只有2-3个小时。而有了结对编程之后，Marko Majkic在Yahoo Scrum讨论小组中《 Rotten apple in Scrum team》中说道，某人的产出是其他人的一半：”Average contribution per developer is 38 usp (user story points). One of the members makes only 19 usp - twice less than the others.“所以最高最高效率的差别大大缩小了，可能只有2倍左右。同时也有数据表明结对编程后程序员的高效时间能够延长到4-5个小时。
如果以整个项目周期内每个程序员每日所做的工作量来看，结对编程的效率不但不会低，反倒很可能会高。何况代码有了更高的质量。所以，为什么不采用结对编程呢？
关于其它XP实践，我想都有类似的理由。虽然表面看来不采用某些实践，对你的项目影响不大，但实际上它们在各个方面扮演着重要的角色，是敏捷战车上的重要组件。因此，把它们作为一个整体，你会发现项目大有不同。
目前国内敏捷社区对此讨论甚少，平静如一滩死水。其中原因，想必主要是国内实施敏捷的公司太少。你的项目是否采用敏捷了？是否只实施了Scrum的实践呢？如果觉得哪里不太对劲，项目仍在苦苦挣扎的话，XP很可能就是你的答案。