敏捷运动——被阉割的革命

本书是一本非常好的学习敏捷开发方法的书。书中列举了大量的事实，详细的介绍了如何在软件开发过程中实现敏捷方法，作者对敏捷的一些感悟等等。如果对敏捷方法没有深刻的认识，可以在看过敏捷宣言以后，仔细研读这本书，作为对敏捷方法的入门。我在这里不想过多的来吹捧这本书的优点，我想谈一下就这本书透露出来的敏捷运动的不足。

我第一次了解敏捷大约是在4年以前，最开始只是了解了敏捷宣言，后来又了解了敏捷的前身—XP。本来我对敏捷运动报着很大的希望，因为敏捷宣言里面提到了一些在传统软件开发方法中没有注意到的思想，这些思想是真的可以为软件开发方法带来革命。而事情发展到今天，这场革命在各种因素的综合作用下，事实上已经失败了。现在大多数人提到敏捷（包括很多资深的敏捷运动成员），都认为敏捷仅仅只是对传统软件开发方法的改良，而非革命，它仅仅只是把传统软件开发过程中好的元素综合起来了而已，而最开始，事实并非如此。

虽然敏捷宣言最开始有12条，但是事实上其中只有三条是核心“我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意”“在整个项目开发期间，业务人员和开发人员必须天天都在一起工作”“即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势”。这3条意味着，和传统开发方法相比，敏捷开发方法是一种用户驱动的开发方法，它事实上是通过用户最快速度的使用，让用户明白计算机可以为他做什么，然后再由用户重组他对目标解决方案的设计。进而，为了快速的达到这一目标，其他的方法最大限度的加快了软件开发速度。从软件工程的发展趋势上来看，敏捷方法将原来用户和软件开发人员相对剥离的状况转变为一种紧密结合，将软件开发过程看做是双方之间的协作而非双方之间的买卖。是的，这本来是一个革命性的思想，这个思想甚至意味着全行业对软件需求认识上的改变。
然而最终，什么变化都没有发生，敏捷打开了一扇大门，又最终把它关上了。现在任何一个组织都宣称自己是敏捷的，甚至连敏捷本来的死对头UP也宣称自己是敏捷的，就连敏捷自己，也在实践中逐渐迷失了自己最重要的特性，最终泯然众人了。
拿IBM的Rational平台来说（09年《程序员》3月刊28页），其宣称自己是敏捷的，甚至宣称自己是大规模敏捷的，但是就其介绍，我们丝毫看不出这个敏捷和紧密结合用户的思想有什么关系，而此所谓的“敏捷方法”，事实上是通过提供统一平台，提高实现级别来实现的，这实质上是一种减小含混性的方法，而并非敏捷宣言的初衷。这本身是两种完全不同的思想，却在他们的介绍下被莫名其妙的混在了一起。

敏捷运动为什么失败了？是因为在最初其革命性太强了。敏捷方法一出，号称颠覆了传统的所有软件开发方法，其宣称的不写文档也确实存在大量拥护者。但其方法本身只是一个从实践走过来的方法，其缺乏扎实的理论根基和与其配套的完整理论体系（比如一种更好的客户开发人员的交流方法等）。相比于早期的UML，先从图形化入手，提供一套便于传统软件开发方法上手的工具，进而逐步向UP甚至模型转换方向发展这种稳定的步伐，敏捷一出来就锋芒壁炉，结果在锋芒中迷失。甚至直到今天，敏捷方法也没有拿出一个靠得住的需求获取方法，而这可是最初12条宣言中最看家的本领。

敏捷失败了，未来会怎么样？
从软件工程发展的历史上来看，从最初的自己自足，到混乱型，到瀑布模型，到原型法，到迭代方法，敏捷方法等等，其本质沿着混乱，到流水线，到一次迭代，到多次迭代，到用户主导，将来必然会更加趋向于协同合作，而非独立自治。而在实现级别上，由最开始的机器码，到汇编，C，面向对象语言，动态语言，SOA，甚至未来可能到达的模型转化，其实现的级别越来越高。未来的软件开发方法，必然更加强调用户主导，快速响应，协同工作，甚至随需而变，而我们的精力必然随着实现级别的拔高，不断的向更高层次的目标转移，不断的去挖掘用户的潜在目标，形成完整的软件服务链。
敏捷虽然失败了，但是下一次变革必然带来更强烈的交互协同，这个大趋势是不会变的，必然会存在着一天，用户和开发者将摆脱当前这种被动的交流状态，转变为相互主动的交流，共同完成对目标的优化。