迭代开发是近年来软件开发领域的热门词汇，我们的开发团队也曾有幸用过类似方法，但就我个人观察而言问题还是非常多的。
国内近年来培养的游戏开发团队，多为软件开发团队，因为缺乏原创所以大多数团队是执行团队，是功能模块开发团队。采用迭代开发，模块化分割再拼装的方法，并不适合完全创意型产品，在产品同质化严重的当下，功能性开发的游戏产品劣势越来越明显，创意型产品，无论大小反而成功概率增大。但迭代的开发，对拼装之后的成果是缺乏校验能力的，一旦拼接完成，发现不符合要求，则反复成本巨大。很多公司的产品基本都是在最后阶段才能看到产品全貌，这无疑是一场高昂的赌局。
那如何解决这些问题呢?
1、我始终强调注重小团队的原型研发、注重DEMO版本的开发，这个阶段，极力赞成反复推敲，甚至是推倒重来，而不要在这个阶段去做功能性的、工作量性质的工作。
2、原型本身就已是一个产品、一个游戏了，如果好玩、能及格才有继续扩充的必要，或者说根本不需要扩充，在原有核心玩法上做深挖潜。
3、要有充足的耐心，允许开发团队停下来思考问题，哪怕是思路不成熟，让开发团队放假也好过思路不清晰，带着团队四处乱撞。在你迷路的时候，停下来辨别方向，不要四处乱跑。
4、要抵御迭代开发在前期迅速推进的诱惑和假象。在当今很多游戏开发团队都以程序员出身的项目经理带队的情况下，一定要明白，游戏的程序是为何服务的。开发资源是最宝贵的资源，能少用当然要少用，希望用程序弥补在策划上的不足不靠谱，早晚还要补上，越晚补，代价越大风险越高，今后可逆转的可能性越低。
5、目标阶段设定要“碎”，不以工作量完成为里程碑，要以达成的游戏效果、目的、和感受为里程碑。经常REVIEW当初产品设定的核心玩法，核心卖点。很多项目不是一开始跑偏的，而是逐步跑偏的。如果某一阶段，你的直觉告诉你，这游戏不好玩，没兴趣，请立即停止，不要寄希望于、自欺欺人的认为功能完善之后，这个问题会得到缓解。
大概总结了一些小经验给大家分享了，只写了10分钟，估计有错别字，同时也只是一家之言。
