设计者-开发者工作流中的迭代模式

本文主要是介绍设计者-开发者工作流中的迭代模式，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

设计者-开发者工作流（designer-developer workflow）这个词已经流行了好几年。它描述了设计人员、开发人员在为Web或桌面应用创造交互体验过程中的关系，而没有表达出设计者、开发者之间的交互和协作。工作流这个术语让我们觉得这种关系是线性的，但实际上它不是。

在项目的整个生命周期中，我们会不停地为项目增加内容。项目本身从开始到结束可能是线性的，但项目参与者之间的协作不是。需要协作的项目，不会变成一个装配流水线；在项目结束之间，我们每个参与者都可能要往项目中不停地添加各种组件、功能片、代码和设计方案。这个过程是有机的，而且——更重要是迭代式的。

作为Adobe的产品部门经理，我经常要和构建各种交互应用、内容的设计和开发人员一起工作。在此过程中我常听到的一点，就是“团队成员间的工作流程，是项目成功的关键；有效减少团队可能遇到的困难的方法是保证项目中每个人之间的清晰、高效沟通”。

在本文中，我将讨论一些可在开发和设计工作中应用的迭代模式，并说明如何利用这些迭代模式实现团队内的高效沟通。

迭代

所谓迭代开发，可定义为全程功能构建。比如在一个项目中，逐步增加各种新特性、交互体验、特性提升和新功能——每次只增加一项。

我们以开发一个简单的游戏为例。游戏的一个关键特性是记录玩家的分数。而这个特性的最初版本，可能就只是通过调用计分系统的功能为用户增加分数。计分系统除了按给定点数未用户加分，没有其他任何功能，目的非常简单。在项目全过程中，我们可以逐步演进和完善计分系统，每次增加一个小的特性或功能，即每次就是一个迭代。对于这里的计分系统而言，我们可以通过迭代逐步增加的各项功能和特性大致有：

通过对计分系统的调用，实现每次按一个点数为某玩家计分
通过对计分系统的调用，实现每次按个数不定的一组点数为某玩家计分
分数达到预先固定的满分时，让计分系统通知游戏
在计分系统创建时，可自定义满分分数
为多个玩家创建多个计分系统实例

作为开发人员，我可以此作为开发某个组件的“特性路标图”，也可用于在完成独立的每个步骤后，标示下一步骤的工作。这样，即使项目周期很长，无论何时我们都能知道自己身在何处，从而可专注于每个独立特性的构建。以这种方式设计整个开发过程，可保证我们不会在未来某个时候遗漏任何工作。

对于大型项目，我可能没有足够时间去定义一份完整的应用规格文档。但我知道大体上可分为哪些部分，并从中选择简单的入手，比如一套Adobe Flex组件，我可以先将这些最基础的组件开发出来。在接下来的每个独立的开发步骤中，我可以扩展已完成功能片的功能，并按我最终希望的形式和作用的要求将它们整合在一起。在此之后，我可以如法炮制对付这个大应用中的其他类似或差别不大的组件。

如此这般，最终我可以构建出所有功能模块，然后将它们集成，从而形成整个应用。这些模块的组织集成也可以用迭代方法完成，通过事件、监听器，逐步在这些模块间构建出通讯桥梁。

设计

迭代如何应用于设计呢？最简单的答案是有两种应用途径——你或许不能立刻想到。

首先，在做系统的整体设计，我从基本构建块（building block）入手：在哪里实现导航？主要内容放在哪里？应用中的这个或那个功能安排什么地方？所有基本构建块一起组成了套件的整体框架（有关终端用户如何使用套件、应用或内容的结构、方法的总体设计）。

当你将系统的主内容块（如导航、部件A/B/C）定下来后，设计过程就开始了。在这个过程中，每完成一个基本构建块的设计，就是一次迭代。在整个过程中，你可以逐步演进和完善自己的设计意图。

第二个方法应用在我已经完成了应用的整体结构，准备在此基础上进行可视化设计的时候。此时用户界面已经确定，结构中每个离散的元素都可以取出来独立设计。在设计了整体结构后再设计其组成元素是非常重要的，因为你需要知道每个组成元素在整个大套件或应用中的运行环境。每个独立的功能模块与其他模块如何交互，将决定该套件或应用的用户界面设计是相对固定还是相对可变化。

比如前面举到的导航例子，我将迭代设计此组件，最开始使用其缺省状态，然后再扩展引入其他元素。假设在我的游戏中需要一个菜单栏。在设计它时，我可以迭代式设计各种特性，具体可包括：

设计初始导航状态，不支持鼠标交互。
支持鼠标悬浮移动。
支持鼠标悬浮移动和提示框。
支持鼠标点击一级导航元素。
支持二级导航。
在二级导航中支持鼠标悬浮移动。
实现完整导航结构。

在每一步骤中，组件（本例中即菜单）的设计，都需要考虑与导航结构协作；同时，它需工作在整个套件或应用的环境中，因此必须保证其设计和交互流程与该环境适配。

导航结构完成后，你就可以想办法对付下一个组件元素了。

回退

迭代式开发和设计的一大好处是当我走远或走歪的时候，可以清晰回溯到还原点纠正错误,继续前进。

比如，我们现在需要游戏中的计分系统支持减分，就可以倒回去增加这项功能。对于更复杂的项目来说，即使某些基础性的东西需要变化，我们也能将项目回退可实现此变化的状态，然后修改、重新将它引入原模块，并修复任何可能出现的集成问题。

以前面的导航结构为例，如果发现需要增加三级导航，我可以回到构建二级导航的地方，并添加三级导航。如果发现三级导航不能和该套件或应用的整体环境较好的协同工作，我可以回溯到更远点，将二级导航返工，然后再引入三级导航，并使其生效。

对于多数设计和开发人员而言，这些听起来有点老生常谈，但的确都是指导我们如何工作、如何向项目持续增加内容的基本方法。即使在软件开发领域之外的设计准则中，它往往也是适用的。例如视频编辑就是一个典型的迭代式设计实践。编辑人员每段时间只处理一个视频片段，然后是场景，再然后才是整个视频。从单独元素开始，逐步让其成长，容纳更多元素，这是我们在大型项目中采用的最基本的工作方法。

迭代离不开沟通

在迭代模式中，无论是设计人员还是开发人员，都会面临一个难题：每个成员如何与正在构建套件或应用中的小组中其他专业的成员实现有效沟通？

答案之一是在每步迭代中向全体成员广播信息——但无疑只有每次迭代在粒度上得到了充分划分，这种沟通才会产生作用。此外还要求它与项目存在相关性。当然在项目的当前时候，它不可能总是相关的；但在开发过程中的未来某个时候，它必定又是有价值的。这样，团队成员在整个过程中都可以获得他们需要的信息。

灵活性，是迭代开发和设计的一大要点。团队所有成员都向迭代过程贡献自己的成果，因此他们的工作必须是灵活的、开放的，只有这样，过程产出的各种组件、设计方案和代码最终才能有效集成。要想迭代设计和开发最后取得成功，那么所有参与者就必须在项目中取得共识。

很多时候，应用的设计和开发人员最开始都会认真制定详细规格书，并以此为基础开始工作。但不久，他们就会按照每个人自己的想法“私奔”了。多数情况下，规格书并不能容纳应用中全部设计和功能用例，因此在执行过程中，他们有为满足需求而自行改编的倾向。但问题是设计和开发彼此分离，互不依赖，那么最后碰头时，必然发现互不兼容，必须予以修改才能解决二者之间的差异。

规定统一的沟通语言，是项目第一步。在项目开始的时候，设计和开发团队必须就项目的主要组件达成一致。详细规定这些组件的功能和设计或许并非必需，但在它们的主要方面达成一致至关重要。例如某应用程序包含一个菜单、某种聊天功能和一些对象。团队必须就应用中的命名规则、基本组件的作用、以及每个主要组件的主要目标达成一致。

完成了这些要素的定义后，团队成员就可以开始迭代工作了。开发和设计人员可以将这些定义作为他们不断开展迭代的基础，在每步工作的同时，规划出下一步骤。如果功能发生变化，可以在未来的迭代步骤做出调整以适应变化了的需求。

如在一个迭代步骤中，不同部件间出现了冲突，参与者可以通过沟通解决这些问题并继续前进，无需将整个组件、套件或应用返工。