很多人非常推崇敏捷，我也是这样，我们的团队采用的就是敏捷开发方法，但是不少同行在讨论敏捷的事后，通常把敏捷中的一些形式看得很重，例如迭代、例如story等，这里就我们的体会来和大家做一些探讨。

首先，虽然有很多异议，但是我个人认为软件开发的基本模型仍然是瀑布法，任何一个软件系统，它一定要经历分析、设计、编码、测试，才能物理上被生产出来，才能成为最终的交付实体交付给客户，所以无论讨论什么开发模型，归根到底，其本质仍然离不开这个最基本的瀑布模型。

其次，敏捷开发方法实际上是瀑布模型的一个变种而已。就象很多人贬低PO（面向过程），而推崇OO一样。软件系统的本质不过就是算法＋数据，只不过PO把这个工作做得太早，在宏观的层面上就做这种分解，以至于设计出来的系统显得太刚性了；而OO的好处不过是把这个工作推迟了，先按照对象分解问题域，然后在比较小的颗粒上在做算法和数据的分离。所以本质上OO也是PO的一种变异。对于敏捷模型来讲，与通常的瀑布模型最大的差异就是把一个完整的系统切成若干小份，然后在每个小份里在采用瀑布模型完成小系统的开发工作，最后拼接成为一个完整的大系统。

所以，敏捷模型与OO方法其实有着异曲同工之妙。在现实中的一个情况是，任何一个系统，在开发伊始，开发人员都是不可能知道完成的最终结果是什么样子，而且客户也说不清楚，开发所依据的需求会在开发的过程中不断明晰、也在不断变动，这样敏捷模型可以保证开发组先把知道的做了，不知道的、或者要变动的部分可以放在后面完成，这样一个个迭代，步步为营，一直到把开发任务完成。

不过，和瀑布模型一样，这种基于敏捷、采用迭代模式的开发方法仍然是一种理想的期望。这段时间也和很多朋友聊过这个话题。其实从国外传过来的敏捷模型在实践中往往和XP混在一起，我们且不论这种概念是否正确，但是就面向应用场景来讲，如果按照这种模式开发系统，那么其基础就是要有一群优秀的程序员，能够通过彼此默契地配合来在程序上适应各种需求的变化。事实上，对于一个软件系统，尤其是行业客户的应用系统来讲，这样是极度危险的。因为这种模型对开发团队的要求太高了，每个程序员都要是业务专家、都是架构师、都是沟通高手，而在国内的环境下，这种黄金团队又有多少呢？如果存在，一般肯定是找着投资，自己创业了。

其实，讨论开发模型一定不能离开“人”这个因素。每个公司的开发模型之所以有所差别，其实也就是每个公司的人是不同的，人所处的环境也是不同的。一个开发模型的优劣，其实关键不是看它采用哪种先进的方法，而是它能够在多大程度上剔除“人”的因素。所以，从本质上讲，其实我是推崇瀑布模型的。因为在瀑布模型的情况下，每一步的成果都是稳定的，这样，即使人员出现变动，损失的也就是本阶段的成果而已。当然，在现实中，瀑布模型确确实实是有着很多弊病，我们要做的其实是利用敏捷的一些思想，来优化传统的开发方法。所以，说到这里，我们就有了一个结论，就是瀑布是本，敏捷是末！

开发一个系统，最关键的就是通盘考虑，虽然正统的敏捷方法反对这样做。通盘考虑的事情主要是在业务上，要能够在较短地时间里，把握客户业务的一些抽象模型，建立业务架构，这样才可能对客户的需求有所预测，设计的系统才可能就有一些前瞻性。系统开发的一半以上的工作要做业务分析阶段完成，开发的难度要能够通过业务的调整来简化。其次是架构设计，架构设计绝对不是做程序架构，而是基于业务架构能够在领域里建立一些应用层次的通用模型，这样把系统未来的扩展方向和内容给固定下来。这样业务预测加上系统预测，三分天下，已据其二了。

上面的工作尽量一次做好，做不好的，也要在架构层面进行预测，在这样的基础上，再通过迭代，逐步把系统实现，这样系统开发的成功率自然也就要高出很多了。