回退
迭代式开发和设计的一大好处是当我走远或走歪的时候，可以清晰回溯到还原点纠正错误,继续前进。
比如，我们现在需要游戏中的计分系统支持减分，就可以倒回去增加这项功能。对于更复杂的项目来说，即使某些基础性的东西需要变化，我们也能将项目回退可实现此变化的状态，然后修改、重新将它引入原模块，并修复任何可能出现的集成问题。
以前面的导航结构为例，如果发现需要增加三级导航，我可以回到构建二级导航的地方，并添加三级导航。如果发现三级导航不能和该套件或应用的整体环境较好的协同工作，我可以回溯到更远点，将二级导航返工，然后再引入三级导航，并使其生效。
对于多数设计和开发人员而言，这些听起来有点老生常谈，但的确都是指导我们如何工作、如何向项目持续增加内容的基本方法。即使在软件开发领域之外的设计准则中，它往往也是适用的。例如视频编辑就是一个典型的迭代式设计实践。编辑人员每段时间只处理一个视频片段，然后是场景，再然后才是整个视频。从单独元素开始，逐步让其成长，容纳更多元素，这是我们在大型项目中采用的最基本的工作方法。
迭代离不开沟通
在迭代模式中，无论是设计人员还是开发人员，都会面临一个难题：每个成员如何与正在构建套件或应用中的小组中其他专业的成员实现有效沟通？
答案之一是在每步迭代中向全体成员广播信息——但无疑只有每次迭代在粒度上得到了充分划分，这种沟通才会产生作用。此外还要求它与项目存在相关性。当然在项目的当前时候，它不可能总是相关的；但在开发过程中的未来某个时候，它必定又是有价值的。这样，团队成员在整个过程中都可以获得他们需要的信息。
灵活性，是迭代开发和设计的一大要点。团队所有成员都向迭代过程贡献自己的成果，因此他们的工作必须是灵活的、开放的，只有这样，过程产出的各种组件、设计方案和代码最终才能有效集成。要想迭代设计和开发最后取得成功，那么所有参与者就必须在项目中取得共识。
很多时候，应用的设计和开发人员最开始都会认真制定详细规格书，并以此为基础开始工作。但不久，他们就会按照每个人自己的想法“私奔”了。多数情况下，规格书并不能容纳应用中全部设计和功能用例，因此在执行过程中，他们有为满足需求而自行改编的倾向。但问题是设计和开发彼此分离，互不依赖，那么最后碰头时，必然发现互不兼容，必须予以修改才能解决二者之间的差异。
规定统一的沟通语言，是项目第一步。在项目开始的时候，设计和开发团队必须就项目的主要组件达成一致。详细规定这些组件的功能和设计或许并非必需，但在它们的主要方面达成一致至关重要。例如某应用程序包含一个菜单、某种聊天功能和一些对象。团队必须就应用中的命名规则、基本组件的作用、以及每个主要组件的主要目标达成一致。
完成了这些要素的定义后，团队成员就可以开始迭代工作了。开发和设计人员可以将这些定义作为他们不断开展迭代的基础，在每步工作的同时，规划出下一步骤。如果功能发生变化，可以在未来的迭代步骤做出调整以适应变化了的需求。
如在一个迭代步骤中，不同部件间出现了冲突，参与者可以通过沟通解决这些问题并继续前进，无需将整个组件、套件或应用返工。
组织与管理
有多种技术和系统可帮助设计和开发人员组织和管理迭代。对开发人员而言，必不可少的工具就是代码版本控制系统，它负责将每个迭代过程形成的代码予以保存，供未来使用，开发人员可以根据要求返回到先前的任意迭代阶段。
对于设计人员而言，像Adobe Version Cue这样的设计档案管理系统，能为迭代开发提供重要的版本管理能力。此外，在团队范围内采用某种统一的文件命名规范也会大有好处。像Subversion这样的代码存储系统，也可用于设计迭代过程。
对于团队来说，建立Wiki、内部开发博客或其他类似的沟通工具，帮助团队成员自动实现信息的收集和分发，对整个团队的沟通效果也有极大帮助。
不过，最关键的一点，还是无论你们选择什么工具，整个团队都必须要使用这些工具。否则，工具将不存在任何意义。如果一个团队成员只顾干自己的，不利用这些工具跟踪其他成员的迭代成果，他们最后开发出来的模块将被弃用，或在集成时出现问题。
总结
研究并和你的团队成员讨论文中提到的技术，并确定哪项技术最适用于你的团队，这是要做的第一步工作。要找到这项技术，需要打开心扉，仔细思考各种可能和以前可能从未入过你眼的工具。再次强调，这些技术的最终目标是让你的团队良好工作，就像我前面提到过的那样，团队成功沟通和协作，是项目走向成功的秘诀。
若需了解设计人员-开发人员工作流的更多信息，请参考Fireworks Developer Center中design/development、iterative prototyping等相关文章，以及Adobe Labs的Flash Catalyst、Flash Builder。
