3.6 迭代
迭代可以分为三种：
1.系统测试迭代（systems test iteration）。每位程序员都有一些工作要完成，他们对写好的代码进行本地测试（例如，在程序员自己的计算机上测试），然后将其载入系统测试环境之中。接下来，执行新版的系统测试。此时我们有可能会发现一些版本不匹配的问题，也有可能探查出程序员之间对工作的一些误解。频繁地进行系统测试迭代，可以尽早消除这些问题，从而使项目能够更为顺畅地推进。
2.设计迭代（design iteration）。我们有时会把新的系统测试迭代所产生的成果，展示给利益相关者看。他们看完之后，有可能提出要对设计进行修改。如果采用情境驱动设计来制作这个项目，那么这样的改动一般来说是比较小的。如果改动幅度确实很大，那我们可以回到情境设计层面来分析利益相关者所提出的改动要求，并查看将要改变的这些任务之间，具备什么样的依赖关系。对于任何一个大型项目来说，我们顶多只会把新版本展示给其中一小部分利益相关者去看。我们有可能要在不同的时间把应用程序分别展示给这些利益相关者，然而有些场合需要一些判断力，例如，如果你意识到这些利益相关者会产生意见分歧，那么你就应该把新版本同时展示给双方看，以免出现其中一位要求这样做，而另外一位却要求那样做的尴尬局面。
3.用户迭代（user iteration）。这指的是向终端用户发布产品。有些时候，在发布终端用户版本之前，必须先进行硬件安装/培训。此外，很多用户都不希望应用程序变化得太过频繁，因此要确保新旧版本之间不会差得太远。我们不应该草率地进行用户迭代。
这些迭代可能会对当前所要管理的系统测试版本数量提出一定的要求。我们可能需要维护编程团队所使用的最新版本以及最新的稳定版本，需要维护展示给利益相关者的最新版本，而且也需要维护发布到生产环境之中的最新版本。此外，或许还有其他一些版本需要管理。管理这么多的版本，是很耗费时间的，尤其是我们需要把同一个bug的修复补丁，推送到多个版本之中。
从前有很多人讨论过迭代的时机与频率问题。笔者认为，与利益相关者和用户有关的迭代，通常是由外部事件所驱动的，它们的发生频率，不像开发团队所期望的那样高。但笔者坚信：当我们可以看到整个设计的全貌时，最好是应该对迭代进行管理。这使得我们可以更好地安排各种特性之间的优先顺序，并且更好地观察出各项变化之间依赖关系，从而能够将其更为明智地归入不同的特性集之中。