（翻译：张亮）

5. 在敏捷项目中进行用户体验建模
在进行建模时，敏捷业者是非常务实的。敏捷建模方法学描述了敏捷业者是如何进行建模和编写文档的。图二(在本页{zh1})是对敏捷模型驱动式开发方法（Agile Model Driven Development）的生命周期的一个概览。这种方法最初产生于极限编程社区，不过它似乎抓住了一般的敏捷项目建模方法的实质。图中的每个方框表示一个开发活动。位于第0周期中的初始建模活动包括了两个主要的子活动，即初始需求建模和初始体系结构建模，这两个活动同时以迭代的方式被进行。风暴式建模及对模型的实现活动在任何周期中都可能发生，包括第0周期（是的，谣言没有说错，敏捷业者经常会在项目启动后的{dy}个星期中就开始软件编码实现了）。每个方框中所标出的时间表示的是该活动在每次进行时平均需要多长时间：例如，在开发阶段，为了探究某个需求，你通常会和某个利益关系人一起花数分钟的时间进行风暴式建模，然后你会花数小时的时间进行编码。

初始的建模工作一般是在项目开始后的{dy}个星期中进行的。对于持续时间较短的项目（可能需要数个星期），你可以在项目开始后的数小时内就进行这项工作。而对于较长的项目（可能需要12个月或更多），你或许可以决定为之投入长达两个星期的时间。进行初始建模工作可以有两个方法：

·需求建模。你需要确定项目的高层需求以及最近的发布版本中将会包括哪些功能。这样做的目标就是要对整个项目是做什么的有一个较好的大致理解。为了做到这一点，你很可能需要构建初始的用户使用模型，以便来研究用户是如何使用系统的（例如，这种模型可以是用例模型或情景描述），你还可能需要构造一个初始的应用领域模型，以便用来确定基本的业务实体类型及其相互关系。可以选做的其它内容包括另外一些重要的模型，你可以使用这些模型来研究技术上的需求。
·体系结构建模。初始体系结构建模的目标是要试图确定一个极有可能使项目能够很好工作的体系结构。在99%的时间里，敏捷业者所做的就是聚集在一个白板旁边，一边讨论各种各样的体系结构策略，一边画一些没有固定格式的图表。当用户界面方面的体系结构是需要重点考虑的问题时，敏捷建模人员会创建一个用户界面导航图（见图三 在本页{zh1}），它描绘了一些重要的屏幕画面、页面以及报表之间的初始关系（这样就能让你对用户界面有一个概览，从而使得你能够问一些基本的可用性方面的问题）。
在随后的那些活动周期中，初始的模型会随着你对项目了解的增多而逐渐完善，但在第0个周期中，你的目标仅仅是得到一个能够勉强工作的模型，这样整个团队就能开始工作了。你不需要对很多细节进行建模，我再次强调一下：这个阶段的目标是使大家对项目有一个共同的理解，而不是编写详细的文档。

在开发周期中，大部分建模活动都会涉及多个人，通常是两个或三个。他们一边讨论，一边在纸上或白板上花一些草图。这些风暴式建模活动是“应需而做”的：即当发现某个需要解决的问题时，你很快地从团队中找来一些可以帮助你的同事，大家一起研究该问题，然后每个人又都像先前一样回去继续各自的工作。

有些时候，只进行风暴式建模还不够。你可能需要对某些复杂的需求进行建模，而做到这一点需要来自团队外部的某些人提供信息。又或者，你需要对某个遗留系统进行建模，它需要花费相当多的时间。换句话说，你可能需要在真正实现某个需求时，提前就进行建模。尽管传统的建模人员可能会希望如此，可实际上这种情况是不太常见的，不过有时候它的确会发生。

所有这些都引出了以下这个问题：和用户体验设计有关的活动怎样才能融入到一个敏捷项目中呢？一个简单的回答是，敏捷业者需要采用面向使用的需求描述方法，例如人物角色，情景描述，或者甚至是用例。常见的方法是在纸上创建出抽象的低保真度原型，就像图四(在本页{zh1})所示的那样用挂图和即时贴来创建。这使得你能够在不用事先进行很多工作的情况下就能快速开始研究用户界面，它甚至使得进行敏捷可用性测试成为可能。事实上，很多的敏捷方法已经这样做了，它们分别是Agile MSF, Agile Modeling 以及AUP方法。

尽管用户体验设计人员会大声疾呼在项目一开始就进行大量设计的必要性，然而敏捷社区却对其充耳不闻。从敏捷业者的角度看来，他们之所以这样做的大致原因就在于：传统的用户体验设计技术对他们不太适用。当你停下来仔细考虑这个解释时，它显得很有讽刺性。为了使用户体验的设计技术对于敏捷业者更加可用，这些技术必须要能反映出敏捷式开发的生命周期。幸运的是，这一点可以通过以下方式来实现：

·在项目的先期进行一些用户界面的建模工作。你需要研究以下三个方面：适用于用户任务结构的各个用户界面是如何构成一个整体的；在各个部分之间进行导航的一般方案；以及视觉和交互方案，这些方案能够通过提供一致的感官体验来支持用户任务。的确，这个活动需要一些先期的工作，不过对于大部分的系统来说，它可以很容易地在第0个周期中完成。请记住，你在先期需要完成的模型数量要视具体情况而定 — 有些团队需要比其它团队做得更多。
·采用一些和敏捷方法相配合的建模工具。例如，极限编程团队倾向于使用索引卡片（index cards），而不是编写文档，AUP团队则倾向于在白板上画草图。幸运的是，纸张和白板对于很多用户体验设计人员来说也是常用的工具。
·在大多数时间内，按照“应需而做”的原则来进行用户界面的开发工作。如果有必要，你应当在实现之前对用户界面方面的重要内容进行研究。进行一次用户研究通常需要预订一些需求量很高的专用设备，以及和恰当的利益关系人预约好时间。因此，你需要稍微提前一些进行建模。
·采用一些敏捷业者熟悉的需求描述方法。就像我前面所说的，一些敏捷方法已经这样做了，例如AUP，DSDM以及Agile MSF方法。同样的道理也适用于极限编程。坦白地说，很多极限编程团队已经意识到要以一种讲故事的方式来实现一个用户界面。

6. 敏捷项目中的用户测试
就本文的目的而言，用户测试包括：
·验收测试（Acceptance testing）
·可用性测试（Usability testing）
·使用测试（Usage testing）

6.1 验收测试
敏捷社区已经意识到了验收测试的重要性，他们已经构造了像Fit（Mugridge and Cunningham 2005）这样的工具来将验收测试自动化。自动化测试会被频繁进行，如果不是每天多次的话，至少也是每天一次。另一方面，手工用户测试一般是在每个迭代周期的结束时进行的。在每个迭代周期结束后，很多敏捷团队会把开发完的系统部署到一个用于质量保证和测试的环境中，在那里将会进行用户和系统测试。这之后，团队会继续开发系统的第N+1个版本，同时他们会收到关于第N个版本的缺陷报告。对这些缺陷报告的处理方式正如对其它的需求一样：它们会被评估，确定优先级，然后被置于一个整体的需求堆中，以便在未来的某个时间对其进行处理。

6.2 可用性测试
在敏捷项目中，可用性测试被认为是可选做的内容。我可以很确信地说，很多的用户体验设计人员会对这种想法感到不满。在可用性测试这一点上，敏捷团队和传统的开发团队没有什么区别，他们很可能无法理解可用性测试的必要性（或为达到可用性目标而采取的其它一些用户体验方面的设计技术）。真正的可用性测试需要在受控的环境下反复对很多用户进行测试。正如验收测试可以在整个开发过程中定期进行一样，可用性测试也应当如此。在敏捷项目中，可用性测试应当在每个迭代周期之后随同用户测试一起进行。当然，这是假定团队中有人具备进行可用性测试所需的技能。

在敏捷项目中，可用性测试的正式程度并非一成不变。较为“灵活”的方法是Jeff Patton提出的可用性测试。在2006年敏捷开发大会的一个工作组讨论中，Patton描述了一种使用抽象的原型来模拟系统的技术（见图四 在本页{zh1}）。在这种方法中，一个开发人员负责模拟系统。他们不允许说话，只是帮助用户在“屏幕”（即纸面原型）之间进行导航。尽管有两个用户{zh0}，不过要至少有一个用户利用纸面原型来完成场景中描述的任务。例如，在某大学系统中，某个场景可能是要求用户来报名参加某个研讨会。用户（们）应当在他们使用系统时说出他们正在思考什么。一个或多个开发人员担任观察者，他们做记录，但是他们不应当在用户使用系统时对这些纸面原型进行修改。

较为“正式”的方法则是传统的可用性测试。在这种情况下，研究人员在可用性实验室中观察用户如何使用系统。可用性实验室一般配备有单向玻璃，这使得研究人员可以看到用户。对于开发人员来说，这通常都是一次很有价值的经历，因为他们之前往往会错误地认为自己设计的用户界面很棒。有些可用性实验室甚至还配备有摄像机，这样你就可以记录下更xx的交互过程，从而可以回放用户的使用方法，对设计进行改进，以便去支持更有效的使用方法。

你可以自由地在项目进行到某些阶段时采取较为灵活的可用性测试，而在其它阶段采用较为正式的方法。你也可以自由地选择一种介于灵活和正式之间的可用性测试方法。

6.3 使用测试
使用场景测试是这样的一种技术，它可以用来在实施之前测试你的设计中所蕴含的逻辑是否正确。这项技术包括了很多内容，它使得项目的利益关系人可以积极地参与其中。同时，该技术能够并且应当和建模工作同时进行，以保证模型xx地反映了业务需求。你可以使用一个或多个使用场景（场景指的是人们如何使用系统的一些列的步骤）来审查类模型，以便验证它们是否能够支持这些场景。如果模型不能支持场景，你就可以适当地修改模型（或者是修改代码，这要视具体情况而定）。图五(在本页{zh1})展示了从审查类模型的角度来进行基于使用场景的测试过程。你可以遵循同样的逻辑来验证用户界面原型（即使对于抽象原型也可以如此）。

7. 开始行动
如果敏捷社区和用户体验社区想要有效地一起工作，他们就需要找到一个中间立场。我相信这个中间立场是存在的，只是双方都需要做出一些改变才能成功做到这一点。首先，敏捷业者必须做到以下几点：

学习用户体验技术。开发人员应当接受用户体验设计技术方面的培训，并把这些技术应用到他们的开发实践中。这将使得开发人员能够更加有效地和用户体验设计人员一起工作。

认识到可用性是一个关键的质量因素。幸运的是，敏捷业者已经被“质量问题所感染” – 他们知道进行高质量工作的重要性，并且已经有了采取某些技术来取得高质量成果的良好记录，这些技术包括：测试先于编码的编程方式、代码重构以及数据库重构。只有在开发过程中采取系统化的可用性工程活动，才能保证最终产品具有较好的可用性。

遵循用户界面及使用风格的设计指南。开发人员必须认识到，他们不仅是在编码时需要遵循共同的规范，在设计用户界面时也要如此。

同样地，用户体验设计人员也必须做出一些改变。他们需要：

不要局限于用户体验。我认为，开发人员和用户体验设计人员之间的很多矛盾都可以归因于他们职责的分工过于专门化，以及他们相互之间进行工作衔接时产生的问题。敏捷业者基本上已经放弃了那种认为团队应当由专家来构成的想法，而是更喜欢由“知识广博的专家”构成的团队。这就意味着，尽管用户体验设计人员为开发团队带来了一项关键的技能，然而为了能够产生真正的效果，他们仍然需要学习更多方面的技能。此外，敏捷业者通过更紧密的人员合作加强了软件项目中的反馈过程，从而把风险和成本都减低了，而这继而又减少了不同成员之间的工作衔接的必要性。

融入到敏捷软件开发过程中。通过将用户体验设计人员融入到敏捷团队中的方法不仅能增加用户体验方面的问题被处理的机会，而且它还有助于提高敏捷社区在用户体验方面的设计技能，这是因为当人们在进行合作时，他们会从其他人那里学会新的技能。

给敏捷软件开发一个机会。Kent Beck 对于Alan Cooper的建议是，在项目开始时用一个星期的时间来研究交互设计方面的问题，而Cooper认为这还不够。到底谁说的对呢？最简单的方法就是在实践中去尝试。

不要局限于极限编程。在前文我已经说过，这里我再说一次，敏捷软件开发远不只是极限编程。敏捷方法是灵活的，它们不是要按照某个固定的模式来使用，而是要根据项目所遇到的特殊情况来灵活运用。为了解决用户体验方面的问题，你很可能会发现，你需要把有关敏捷建模和（或）以用户为中心的设计方法的原理及实施措施进行相应地调整，并把它们结合到你的软件开发过程中。

8. 潜在的挑战
让敏捷业者花些时间来学习用户体验方面的技能并遵循恰当的界面设计指南，这个建议说起来容易，然而在现实中，还有很多其它同样重要的技能需要引起重视，例如数据库设计和建模。更糟糕的是，很少有面向开发人员的书籍涉及用户界面设计及可用性方面的问题。很少的一些能够像我的“The Object Primer”一书那样谈到这个问题的书籍也很少会用超过一章的篇幅来讨论。我担心很多敏捷业者甚至根本意识不到这方面的问题。

同样地，用户体验设计人员也面临着不同的努力方向。尽管我提倡他们成为“知识广播的专家”，然而业界仍然鼓励他们更加专业—用户体验专家的待遇非常好，大部分机构期望他们能够专注于用户体验设计这种特定的工作。敏捷业者也面临着这样的挑战：如果学习一门有关Java编程的课程能够得到相关的证书和更高的工资，为什么要去学习一门用户界面设计的入门课程呢？

用户体验设计人员应当融入在敏捷项目中，这一点也是说起来容易。它这只有当项目中具有用户体验方面的专业人员时才可行。很少的机构具有这样的人员。更糟糕的是，很少有机构会在制定需求计划或项目计划的过程中考虑交互设计。因此，很多机构可能认识不到聘用具有这些技能的人员的必要性。

如果没有专人负责用户界面设计的问题，这将意味着不论这方面的技能如何，每个人都想参与用户界面设计，而这会导致委员会式的设计（design by committee）。尽管在敏捷社区中有一种普遍的认同，即敏捷业者应当谦虚地认识到自己的能力，并且在解决某个特定的问题时应当尊重其它具有合适技能的人，然而事情并不总是这样的—因为很显然，敏捷业者也是普通人。

用户体验设计人员有可能在敏捷团队中做出非常有价值的贡献，同时我认为与在传统的开发团队中工作相比，他们更有可能取得成功。到目前为止，可用性社区在主流开发团队中试图积极参与其中的尝试还没有取得什么成功，因此是到了采取一种新方法的时候了。我的建议是，可用性设计人员应当同他们的敏捷业者“狱友”紧密合作，以使得“监狱”得到更合理的控制。

9. 感谢
我要感谢Paul Oldfield 和Tim Tuxworth ，他们提供了有关敏捷建模方法的列表，这使得我得以完成本文。

图二. 敏捷模型驱动式开发方法的生命周期（Agile Model Driven Development）

图三. 某个大学系统的用户界面导航图（徒手绘制）。

图四. 使用纸张创建出的一个抽象的用户界面原型。

图五. 从审查类模型的角度来进行基于使用场景的测试过程

本文作者 Scott W. Ambler, 最初发表于 。如想阅读更多类似文章，请到：

© ui花园版权所有，经许可转载。

中国创意设计人才网相关职位信息：
[深圳]
[上海]
[上海]
[杭州]