再发一胡说八道贴,谈一下开发方式
向来不喜欢空谈什么理论，不过最近看了不少开发方式的讨论。谈一下感觉吧。
开发方式有瀑布式、迭代式、测试驱动、模形驱动等
个人觉得使用何种开发方式，要跟据实际情况决定
以前做电力项目时，用的就是瀑布式，因为项目与外设的交互相当多，而用户的需求基不上不会有什么变化，都有具体的操作规章，按操作规章与外设的功能做需求就可以了，能实现的就实现，不能实现的，要么不要，要么换外设。
需求、对外设的性能了解、系统设计、论证用了项目一半的时间。然后代码。然后集成。
做电子政务时，用的就是选代式，因为政府的需求总变，法规也总改。
先做一期，实现了公文流转等基本OA功能。
再做二期，实现了互连审批的跨部门办公的功能，
再做三期，为每个具体的事项做具体的流程
三期没做完，就做四期了，因为具体事项不是一二年可以做完的，分出一部分人做新增事项的调研，流程设计（工作流已经写好了，参与些工作的程序员不需要多高的代码能力）
第四期，添加了效能分析、投诉、监察功能。
在这期间，各期的不同组合以产品的方式又卖给了多家客户。
而测试驱动与模形驱动开发，我觉得完全可以溶入到瀑布式或迭代式开发中。
一般企业应用开发分为用户接口与后台服务两部分。
对于前台(也就是用户接口),我主张模型驱动开发，快速将UI及UI的逻辑关系建立起来，这样的好外就可以让心急的用户与领导前看到一些东西，别外可以用UI与用户进行交流，让用户理解系统，并可快速的找出双方理解有误的部分。
对于后台(也就是服务部份)，我主张用测试驱动开发，原因很简单，服务的代码量不是特别大，但对代码的健壮性、稳定性要求却很高。
在测试驱动开发中，对集成测试，有两种方式，一是从底向上，二是从顶向下。
各有各的好处，
比如我要开发工作流，如果我对引擎非常重视，因为以后要在其他项目中重用，我会用从顶向下的测试，写一些流程做为桩模块以调试引擎。
又比如我要开发工作流，但我对引擎的要求不是很高，我的重点是复杂流程的合理情，我就会使用从底向上的测试，为流程写一些驱动模块。
我前段时间所发的例子，主要是为了演示WF中的Activity使用，所以例子中的工作流引擎属于调试工作流实例的驱动模块。
以后我还会发一些演示引擎的例子，那时我就会为引擎写一些工作流，这时我所写的工作流就是调试引擎的桩模块了.
综上，开发方式跟据团队的特长点、项目的特点决定。而且，对同一项目的不同子系统可以使用不同的开发模式。