迭代与瀑布

      经过无数次的修改，无数次的需求确认。无数次的反复，客户也累了，我们也累了。最后提交的产品客户还不满意！ 可能有人说是因为需求没搞好，可能有人说是因为开发没搞好。 但我的观点认为，国内大部分开发模式本身就不合适，或者说不对！

      瀑布模式，每个阶段依次进行，需求整理，设计、详细设计、开发、测试。相信很多公司在用，现在在用，相信以后也要用。 可是大家有没有仔细考虑，这种模式到底符不符合我们国内的实际情况! 经过这些年的锤炼，客户的水平我想大家心里都有些数，明白需求的有几个？ 了解技术的有几个？ 客户在乎你的详细设计么？ 客户只是在等你们拿给他们用，等待中，开发中，分歧、问题、理解偏差就慢慢的造成了。 这就导致了很多系统，上线后，客户说这不行，那不行。

      今年上半年，我们结束了一个美国的迭代项目开发。 项目做的异常艰苦，可以说是呕心沥血。在美国构架师的带领下，把一个企业级解决方案从零开始搭建，直到后面整体而完善的框架。我们都不得不佩服自己完成这样一套系统。

      小规模版本的提交、测试，客户可以快速的提供反馈意见、想法，这个过程不断的循环往复，产品会变得越来越强，客户和开发方的信心都在逐步增强，合作会变得愉快而充满信任。在项目中后期，客户的意见变得更加理性，更贴合软件设计及构架的方向，开发方也会感觉越发的顺手、舒服。在不发生大规模基础性变更的前提下，基本上项目都能获得圆满的成功 。虽然这个周期长，辛苦。但是产品质量超越了我们以前任何瀑布开发的产品质量。

      不能说国内没有迭代项目，我觉得国内很少用迭代的原因大部分是因为成本、时间上的考虑。 质量可以稍微放后。 但是实际上往往瀑布的开发成本与迭代不相上下。 时间紧、任务重，需求不明确，测试跟不上，代码质量不高，往往造成了返工、客户意见爆棚的情况。但说多了可能也没用，说句不好听的，经理人的想法可能就是拿项目，钱只要来了大部分，其它的能应付就应付。国情就是这样，我们又能如何？