迭代式（Iterative)软件开发似乎已经成为了目前业内被证明最有效的开发方式，不管是微软模式，还是RUP或者XP，还有别的个别公司和个人尝到的模式，除去具体细节上的差别，核心思想都是迭代。
这
世界上道理是想通的，邓小平“摸着石头过河”也就是迭代式的思想，走一步看看情况如何，然后决定下一步怎么走。迭代式开发也就是将开发过程分成若干周期，
每个周期结束的时候总结一下发现的问题，然后继续下一个周期。迭代式开发的主要好处就是可以减少开发风险，较早的发现问题，传统的瀑布模型往往在最后关头
才发现一开始忽视了一个需求。不过在经历了几个项目之后，我感觉这种方式还是容易误入陷阱：
陷阱一: 不合理的目标
迭代式开发每
个周期开始都要指定计划，包括这个周期要实现的目标，但是目标的指定要参考以往周期的经验，如果上一个周期目标的实现有问题，就改考虑调整计划了。我看有
的管理者在项目之初就指定了每个周期的计划和目标，然后强制灭个周期都要完成这些目标，这样倒是能够让管理者了解项目进度，但是如果不能发现问题并调整计
划，就没有完全发挥迭代式的好处。强制完成计划会带来很多问题，如代码质量下降，士气低落。
所以，要根据以往的周期，灵活的改变计划和周期目标。
陷阱二： 不能保证单个周期质量
把
开发过程分为多个周期是为了降低风险，提高质量和效率，不能为了周期而周期。每个周期应该能够deliver一个稳定的版本，从用户角度出发，一个功能不
全但是已有功能稳定的软件比功能齐全但是bug无数的软件要好的多。但是管理者容易倾向于催促开发者按照自己的想法meet进度，于是开发人员也就会牺牲
质量来赶上进度。如果管理者继续这种做法的话，很容易导致恶性循环，即没有一个周期能够提供一个稳定版本。
陷阱三: 不能协调多个部门的步伐
迭
代式开发不只是程序员的事情，需求部门测试部门等相关部门都需要按照迭代的方式前进，而且各部门之间需要交流协调以保证质量。如果测试部门只有在最后一个
周期之后在上，我很怀疑他们接到是不是一个可以测试的版本，如果需求部门不能即是获得开发部门每个周期的反馈并细化明确需求，最后获得的也很有可能不是他
们想要的软件。