【IT168 技术文章】
设计者-开发者工作流（designer-developer workflow）这个词已经流行了好几年。它描述了设计人员、开发人员在为Web或桌面应用创造交互体验过程中的关系，而没有表达出设计者、开发者之间的交互和协作。工作流这个术语让我们觉得这种关系是线性的，但实际上它不是。
在项目的整个生命周期中，我们会不停地为项目增加内容。项目本身从开始到结束可能是线性的，但项目参与者之间的协作不是。需要协作的项目，不会变成一个装配流水线；在项目结束之间，我们每个参与者都可能要往项目中不停地添加各种组件、功能片、代码和设计方案。这个过程是有机的，而且——更重要是迭代式的。
作为Adobe的产品部门经理，我经常要和构建各种交互应用、内容的设计和开发人员一起工作。在此过程中我常听到的一点，就是“团队成员间的工作流程，是项目成功的关键；有效减少团队可能遇到的困难的方法是保证项目中每个人之间的清晰、高效沟通”。
在本文中，我将讨论一些可在开发和设计工作中应用的迭代模式，并说明如何利用这些迭代模式实现团队内的高效沟通。
迭代
所谓迭代开发，可定义为全程功能构建。比如在一个项目中，逐步增加各种新特性、交互体验、特性提升和新功能——每次只增加一项。
我们以开发一个简单的游戏为例。游戏的一个关键特性是记录玩家的分数。而这个特性的最初版本，可能就只是通过调用计分系统的功能为用户增加分数。计分系统除了按给定点数未用户加分，没有其他任何功能，目的非常简单。在项目全过程中，我们可以逐步演进和完善计分系统，每次增加一个小的特性或功能，即每次就是一个迭代。对于这里的计分系统而言，我们可以通过迭代逐步增加的各项功能和特性大致有：
- 通过对计分系统的调用，实现每次按一个点数为某玩家计分
- 通过对计分系统的调用，实现每次按个数不定的一组点数为某玩家计分
- 分数达到预先固定的满分时，让计分系统通知游戏
- 在计分系统创建时，可自定义满分分数
- 为多个玩家创建多个计分系统实例
作为开发人员，我可以此作为开发某个组件的“特性路标图”，也可用于在完成独立的每个步骤后，标示下一步骤的工作。这样，即使项目周期很长，无论何时我们都能知道自己身在何处，从而可专注于每个独立特性的构建。以这种方式设计整个开发过程，可保证我们不会在未来某个时候遗漏任何工作。
对于大型项目，我可能没有足够时间去定义一份完整的应用规格文档。但我知道大体上可分为哪些部分，并从中选择简单的入手，比如一套Adobe Flex组件，我可以先将这些最基础的组件开发出来。在接下来的每个独立的开发步骤中，我可以扩展已完成功能片的功能，并按我最终希望的形式和作用的要求将它们整合在一起。在此之后，我可以如法炮制对付这个大应用中的其他类似或差别不大的组件。
如此这般，最终我可以构建出所有功能模块，然后将它们集成，从而形成整个应用。这些模块的组织集成也可以用迭代方法完成，通过事件、监听器，逐步在这些模块间构建出通讯桥梁。
设计
迭代如何应用于设计呢？最简单的答案是有两种应用途径——你或许不能立刻想到。
首先，在做系统的整体设计，我从基本构建块（building block）入手：在哪里实现导航？主要内容放在哪里？应用中的这个或那个功能安排什么地方？所有基本构建块一起组成了套件的整体框架（有关终端用户如何使用套件、应用或内容的结构、方法的总体设计）。
当你将系统的主内容块（如导航、部件A/B/C）定下来后，设计过程就开始了。在这个过程中，每完成一个基本构建块的设计，就是一次迭代。在整个过程中，你可以逐步演进和完善自己的设计意图。
第二个方法应用在我已经完成了应用的整体结构，准备在此基础上进行可视化设计的时候。此时用户界面已经确定，结构中每个离散的元素都可以取出来独立设计。在设计了整体结构后再设计其组成元素是非常重要的，因为你需要知道每个组成元素在整个大套件或应用中的运行环境。每个独立的功能模块与其他模块如何交互，将决定该套件或应用的用户界面设计是相对固定还是相对可变化。
比如前面举到的导航例子，我将迭代设计此组件，最开始使用其缺省状态，然后再扩展引入其他元素。假设在我的游戏中需要一个菜单栏。在设计它时，我可以迭代式设计各种特性，具体可包括：
- 设计初始导航状态，不支持鼠标交互。
- 支持鼠标悬浮移动。
- 支持鼠标悬浮移动和提示框。
- 支持鼠标点击一级导航元素。
- 支持二级导航。
- 在二级导航中支持鼠标悬浮移动。
- 实现完整导航结构。
在每一步骤中，组件（本例中即菜单）的设计，都需要考虑与导航结构协作；同时，它需工作在整个套件或应用的环境中，因此必须保证其设计和交互流程与该环境适配。
导航结构完成后，你就可以想办法对付下一个组件元素了。
