你认为迭代开发的难点和应该注意的地方在哪里？

小小的调查一下。希望大家踊跃发言。

迭代开发，代码总是越写越多，系统也是越来越复杂。

什么时候该小步前进，什么时候该下决心改进设计，这个决定最难。

迭代开发对于不同的角色（如项目经理，组件负责人，开发人员）有不同的粒度。

在这几种角色中我做为程序员的时间最长。
作为程序员，迭代粒度，个人认为，应该是能够控制何时提交代码，并在提交的代码中能够写出合适的注释。

Road Map很难定
Road Map定下来,设计的时候瞻前顾后的很麻烦

有时候明明知道某个需求是需要的,但可能不是当前版本马上去实现，而是下个版本或以后的版本去实现.
设计的时候考虑吧,又担心进入过度设计,时间可能也不允许; 不考虑吧,以后十有八九又会添加上去的,到时考虑可能会很麻烦.

我上面的担忧是不是说明我对迭代开发理解还有问题?我们的开发流程有点Rup XP的综合, 需求是先分析成文档的,然后再决定分成三个交互阶段. 当然后续时间肯定也会包含对需求的更新迭代

相信大家都能认同迭代的重要性
整个业界也都开始在利用TDD,XP,refactoring来实现迭代
uml for java programmers中dX就是对迭代的一种具体阐述

其实道理大家都容易懂
关键还是经验上的差距
何时做什么样的迭代
这应该是博弈的问题了吧
没有一个强大的经验积累,个人感觉很难把迭代做好

我个人觉得，有几个因素是影响迭代开发最大的。第一，就是每次迭代选择的内容，这个在很多人眼中觉得很轻松的事情，其实是最难的，因为在每次迭代开发的要求中，要求目标是可达到的，并且应该是成功的，那么任务的选择是非常关键的，而任务的选择往往又来自于对任务的评估的和目标的分析（例如需求的分析，技术的分析等）；其次，是迭代的范围，在一次完整的开发中究竟需要多少次迭代，而每次迭代的范围又是什么（主要指时间范围，而时间范围又制约着迭代的目标范围），又人认为一个礼拜，有人认为一个月，有人认为三个月，在不同的项目，不同的人的眼中，它的差别是相当大的。现在有比较极端的趋势，也就是熟悉开发但不太熟悉项目管理的人喜欢将迭代时间越短越好（我不敢说这是否是对XP的错误理解），而比较高层的项目经理（对开发不太熟悉），喜欢将迭代时间限制在一个比较长的时间（一般是两到三个月，甚至有半年，这应该也是对RUP的一种错误理解吧）。第三，也就是迭代周期的deadline的把握，在我发现，许多推崇XP的人似乎没有太多deadline的概念，在这点上似乎值得向RUP的milestone来学习。为什么我这么强调deadline，就是因为在许多人在任务的规划与实施上都是先轻后重，大量的任务或者难度的任务总喜欢在最后来解决。在版本提交前的一个礼拜，似乎是每个项目组最忙的时候，总会出现许多莫名的问题，从而导致版本提交的延迟，其主要原因之一，也就是开发人员对于deadline的概念并不深刻。
当然，影响迭代开发的因素还有很多，上面只是我个人的一些看法而已。

迭代计划的制定，比如怎样考虑各个迭代任务之间的相互影响和耦合关系。

我认为是每次迭代对系统架构的灵活性和稳定性的影响
我们在每次迭代的时候是只考虑本次迭代的功能，用最简单的方式实现（XP思想）
还是考虑以后迭代的影响，在开始的时候就设计一个灵活的框架，来适应以后迭代带来的变化
这个是比较难以取舍的

个人认为使用迭代开发首先是开发方法要在开发团队中得到认可，如果有人就是认为这是不可行的，有抵触的心里那么迭代可能就难了。

建议采用第二种方式，一个优秀框架的最大优点就是可以将迭代开发所带来的变动影响控制在系统规模层面，而不会扩散至系统复杂度层面。