1. 敏捷软件开发 (ASD – Agile Software Development)

为了解决软件开发者所面临的困难，2001年7月，一个由17个方法学家组成的小组成立了敏捷软件开发联盟(Agile Software Development Alliance)，简称为敏捷联盟(Agile Alliance)。有趣的是，小组每个成员的背景都不相同，但却最后达成了方法学家们通常不会一致通过的协议。该小组共同制定了一个宣言，该宣言包含4 个价值和12个原则，主要目的是促进更优秀的软件开发方法；该宣言还制定了ASD过程的标准。

如同软件工程协会的软件能力成熟度模型 (Software Engineering Institute’s Capability Maturity Model Integrated (CMMI))为重量级软件开发过程定义的需求，敏捷宣言则定了敏捷软件开发过程的需求。反应了这些需求的敏捷过程包含如下内容：

• Agile Data (AD)
• Agile Microsoft Solutions Framework (MSF)
• Agile Modeling (AM)
• Agile Unified Process (AUP)
• Dynamic System Development Method (DSDM)
• Extreme Programming (XP)
• Feature Driven Development (FDD)
• Scrum
• Usage-Centered Design (UCD)

绝大多数的敏捷项目的开发团队都少于10个人，在同一地点工作，可以直接和利益关系人们(stakeholders)沟通，利用一些常用的建模工具比如写字板(writeboard)和公告板(corkboard)，拥有自己的开发机器，使用一些必需的工具，比如测试工具。也有人指出，有些敏捷团队可能也会比较大（可能好几百人），可能分散在不同的地理位置上，有些人不是总能够很容易的接触到利益关系人 (Eckstein 2004)。虽然多数的敏捷团队都采用测试主导的开发方式(TDD – test-driven development)，也就是开发的过程中间进行测试，写完一部分代码就测试一部分，他们通常都没有测试UI的工具。而且，他们几乎都没有可用性实验室(usability lab)，因此从该角度来说，这样的敏捷和传统开发的区别不大。

我在图一描述了一个普通的敏捷SDLC*，包含了4个阶段：第0周期，开发阶段，发布阶段，和生产阶段。尽管很多敏捷开发者否认这种阶段式的概念，但实际上很多的敏捷过程中都包含了各个阶段，比如XP，AUP, 以及敏捷MSF（这里将“阶段”叫做track）。

图一：敏捷SDLC

下面我们来看看每一个阶段：

1. 第0周期 敏捷项目开始的第一周时间左右，通常被称为第0周期（”Iteration 0” or “Cycle 0”）。在本阶段中启动项目，主要目标是收集项目的最初支持和资助，积极主动的与利益关系人沟通从而在较层次上定义要开发的软件系统；组建团队；为最初的结构建模；并准备好工作环境。

2. *开发阶段*。在开发阶段，敏捷软件开发者逐步交付高质量的、可以满足利益关系人的不断变化的需求的软件产品。

3. 发布阶段 在此发布阶段，敏捷软件业者将开发中的系统交付到使用生产中。

4. 生产阶段 本阶段/周期目标是保证系统投入使用后，一直有用，并具备持续的生产能力。基本目标是保证系统的正常运行，并帮助最终使用者来使用该系统。

表面上看起来，图一中所示的敏捷SDLC非常像传统的SDLC，但你仔细观察，很快就会发现，它们是不一样的。由于敏捷SDLC是需要高度协作的、重复(iteractive)、循序渐进的，并且和传统项目中的开发者相比，敏捷开发者所承担的责任要多的多。在传统项目中，商业分析师(business analyst)先创建需求模型，之后交给构架师；构架师继而创建设计模型，再交给程序员；程序员写出程序之后再给测试工程师，等等。而在敏捷项目中，开放者和利益关系人密切合作，从而可以更好的了解他们的需求；他们相互配合来实施并测试系统，之后将系统展现给利益关系人从而获得快速的反馈。传统开发过程中分工细致，具有不同专长的人在不同阶段接力传递产品，并可能在整个链条中的各个阶段加入新的问题；敏捷开发者们综合了各种专业技能从而达成完整生命周期。更重要的是从用户体验的角度来看，它们采用了不同于传统方法的建模和测试过程。

2．用者体验

可用性是系统的一个质量属性，具体来说包括产品的可学性、使用效率、可记忆性、容错能力、和用户的满意度（Neilson 1994）。用户中心设计也叫做UCD，这几个字写起来简单，但却是高度结构化的产品开发过程，其核心在于理解使用者的需求和目标。Alan Cooper提出交互设计Interaction Design (ID)这种方法，其目标为产品的功能既要满足使用者的需求也要有用。在ID中，交互设计师关注用者所需的，工程师关注自身能力（技术上能实现什么、实现到何种程度），商业利益关系人 关注可行性。在此我这里统一使用用者体验一词(UEX)来涵盖所有的概念，尽管有些概念是不一样的，但在此为了讲述方便就没有必要区分那么细致了。

为什么敏捷业者(agile practitioners)要考虑UEX的重要性呢？这是一个很关键的问题。Jeff Patton认为UEX解决了对于ASD团队成功与否至关重要的几个问题：

• UEX强调了使用需求的必要性，必须要满足用户的需求目标
• UEX可以帮助识别并确认软件必须要有的功能
• 通过不同程度的手续和手段，UEX方法可以被采纳的，这样就使得UEX方法和敏捷方法是相容的，而不是相斥的。

我在本文中使用的其它重要的词汇如下：

• 系统 就是产品，这里通常指在开发中的软件
• 使用者/用者 通常也被称为最终使用者，指的是最后将要使用这个目前正在开发中的系统/产品的那个/哪些人
• 开发者 构建系统的IT专业人士
• 利益关系人 利益关系人(stakeholders)指的是和本系统的研发或者使用有利益关系的任何人。这包括了直接用者、非直接用者、用者的管理者、高级经理、开发者、运行/操作员、技术支持者、和本系统有关系的其他系统的开发者、系统开发过程中或者系统实施时有可能受到涉及到维护者。在有些敏捷方法学中，特别是XP中，则笼统的将利益关系人叫做客户(customer)。
• 验收测试 是一种测试技术，其目标是来验证某系统是否达到了验收(acceptance)标准，是否可以让利益关系人来决定是否接受该系统。
• 可用性测试 让该系统的用者们来执行一系列的操作，从而来衡量该系统是否易于使用、测量任务的执行时间和效率、用者的体验和感觉。可用性测试可以很正式也可以不太正式，有的测试在配置了专门测试工具的房间中进行，有的测试则使用简单的模型。
• 用者测试. 测试活动，包括接受度测试和可用性测试，通常利益关系人们都主动积极的参与。

3. 敏捷和UEX的现状

先来说好消息。我相信在敏捷团体和UEX团体中，对于双方协同工作的好处的认同感是在增加的。敏捷团体中，Larry Constantine的UCD工作是广受赞誉的，ASD的承诺也鼓舞着UEX人士。有一个邮件列表Agile Usability mailing list比较活跃，通过此列表ASD和UEX业者定期进行有规律的交流。在最近的UPA 2005和Agile 2005大会上，都有敏捷和可用性的讲座。目前也有一些呼声希望将两个团体合并起来。

现在来说坏消息。如果要想让两个团体能够有效的工作，目前还需要克服一些困难。就像我们在讨论两个不同团体，这本身就暗示着两者的合作可能存在一些困难，包括如下：

• 目标不同. 软件工程师关注软件系统在技术上的设计、实施、以及维护。UEX业者则关注如何开发让最终用者可以有效使用的系统。遗憾的是，两个团体的人都无可避免的忽视了对方所关注的东西。
• 方式方法不同。UEX方法论集中用者身上，而敏捷方法论则更广泛的关注利益关系人。采用UEX方法的人，在开始实施项目前，会试图从整体上了解用者的需求，之后产生出一个用户界面的整体计划。敏捷方法则通常不会在实施前先进行设计，而是更注重较早的交付成型的软件。
• 组织上的困难。敏捷业者遵从高度合作、流动性很强的组织结构，团队成员都是自我管理、自我组织的。然而，在高度集中化的UEX团队中，情形就不是这样了。UEX的中心是关注如何工作、关注提供所需的工具和标准等，强大的组织和管理结构则可能会有问题。
• 进度不匹配。敏捷人士在项目的早期不会进行细致的建模过程，也就是被他们称作“Big Design Up Front (BDUF)”。很多UEX人士则更喜欢在项目的初期进行较为综合全面的建模过程，从而在开发开始前就设计出更合理的交互模型。
• UEX业者较难被支持和了解。尽管在传统团队中敏捷的概念也很难被支持和了解，但相比之下UEX业者的处境更不好，因为敏捷业者还是比较赞同高层次的协同工作。Jokela and Abrahamsson (2004)认为UEX业者经常抱怨他们的工作成果没有在设计结果中考虑到。他们还指出，在Agile Alliance成立的时候，也没有UEX业者被邀请加入，这也可能是为什么ASD社团中缺乏UEX影响力的原因。
• 我们的精神领袖可能有些太极端。这表现在Kent Beck和Alan Cooper的讨论中，他们分别是Extreme Programming (XP) 和 Interaction Design (ID)思想的创始人。我们在表一中标出了他们讨论的agile和UEX哲学的不同之处。不幸的是，Beck和Cooper似乎在这场讨论中都很极端，我们可以从对他们的采访中看到有些原则性问题的争论仍没有解决。

敏捷方法和UEX方法的比较

敏捷方法

• 通常会问“在此阶段我们如何才能改善现有的系统呢？”
• 你应该紧密的和利益关系人或客户协作，从而找出他们真正需求。
• 需求背后的细节可以在研发过程采用“临时抱佛脚”的方法来发掘
• 细致的先期建模充其量也仅仅是个有风险的工作
• 交互设计的工作从项目的一开始就存在，并伴随整个项目过程

UEX方法

• 通常会问“理想的系统是什么样呢？”
• 定义软件产品或者服务是非常困难的，必须要从理解复杂系统，并对系统视图化开始，而不能一上来就开发。
• 所有的行为细节要在开发前就得讨论清楚

4. 澄清一些误解

为了推动这两个团体间更有效的合作，我们需要在这里澄清一些彼此间的误解。下面先列出UEX人士对敏捷团队的误解：

• 敏捷人士不建模。其实敏捷业者是建模的，只是他们不鼓励在初期进行大规模的的设计工作，而鼓励较为敏捷的建模。
• 敏捷开发就是不断的“即开发即投入使用”。尽管有些团队如此，但这并不是规范的敏捷开发者的行为。敏捷开发者通常是有规律的交付正在开发中的软件，比如几个星期，但也通常先在内部环境中测试。而真正投入生产环境中，则通常需要6到12个月时间，也或者少于6个月，这要看我们最终用户的要求和能力，是否允许我们在相对较短的时间内交付软件。
• XP是唯一的敏捷方法。这是极大的误解，可能是因为某些UEX业者想当然认为这种敏捷方法比其他的敏捷方法都要好，就如同某些人会认为Scrum，敏捷建模，MSF for Agile，或者DSDM也比其他的方法要好。
• 敏捷团队中没有UEX业者的职位。在很多敏捷方法中放弃了对特定职位的需求，而是倾向于多功能职位，比如开发/编程，教练/领导，顾客/利益关系人。
• 敏捷者不是专攻一门技能的专家。这可能有道理，因为敏捷者更像是‘全能通用专家’
• 用户界面(UI)不该被重构(refactored)。很多人会担心重构(refactoring)用户界面，这通常是因为他们认为UEX问题会被遗忘，或者最终用者将无法应付由重构带来的持续的变化。而事实情况是，UI的重构带来的是UI缓慢但安全的进化，因此是改善了其设计。为了保证UEX问题不被遗忘，具有UEX技能的人应该参与到UI开发和进化的过程中。当然，我们希望UI的改变是朝好的方面改变，不过从开发到投入使用的整个过程中，只有那些参与用者测试的人所受的影响最大，其他人受到的影响很少。另外，仔细想一想，如果可用性测试中发现了问题，难道开发者不应该有所行动来改善UI么?

同样，敏捷团队也存在着对UEX团队的误解：

• UEX团队所关注的就是一套很不错的UI规范和指南。这是起码的要求，但UEX不仅仅关注UI规范和指南，创建一致的UI，而且还关注更多
• 密切合作就可以了 。这也是起码的要求，但Jokela和Abrahamsson (2004)发现仅仅靠开发者和利益关系人的密切频繁的合作是根本无法保证好的可用性的。
• UEX所作的仅仅是UI设计。显然，UI是UEX的一部分，但是还要去了解用者将会如何使用你设计的系统，还要去了解用者的使用系统的目标，这样你才能够打造出可以被他们使用的系统。完成这些，需要我们具备相当水平的建模和合作能力。
• UEX依赖于前期全面的建模。尽管UEX界中有些人想让你认同这样的看法（比如Cooper 2004），但是很多人却不这样认为。在很多方面，做好UI的道理和做好architecture的道理是一样的，通常是需要一些前期思想，但这并不意味着一定要采取一系列的方法来实施。

5. 在敏捷项目中进行用户体验建模

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

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

• 需求建模。你需要确定项目的高层需求以及最近的发布版本中将会包括哪些功能。这样做的目标就是要对整个项目是做什么的有一个较好的大致理解。为了做到这一点，你很可能需要构建初始的用户使用模型，以便来研究用户是如何使用系统的（例如，这种模型可以是用例模型或情景描述），你还可能需要构造一个初始的应用领域模型，以便用来确定基本的业务实体类型及其相互关系。可以选做的其它内容包括另外一些重要的模型，你可以使用这些模型来研究技术上的需求。
• 体系结构建模。初始体系结构建模的目标是要试图确定一个极有可能使项目能够很好工作的体系结构。在99%的时间里，敏捷业者所做的就是聚集在一个白板旁边，一边讨论各种各样的体系结构策略，一边画一些没有固定格式的图表。当用户界面方面的体系结构是需要重点考虑的问题时，敏捷建模人员会创建一个用户界面导航图（见图三 在本页最后），它描绘了一些重要的屏幕画面、页面以及报表之间的初始关系（这样就能让你对用户界面有一个概览，从而使得你能够问一些基本的可用性方面的问题）。

在随后的那些活动周期中，初始的模型会随着你对项目了解的增多而逐渐完善，但在第0个周期中，你的目标仅仅是得到一个能够勉强工作的模型，这样整个团队就能开始工作了。你不需要对很多细节进行建模，我再次强调一下：这个阶段的目标是使大家对项目有一个共同的理解，而不是编写详细的文档。

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

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

所有这些都引出了以下这个问题：和用户体验设计有关的活动怎样才能融入到一个敏捷项目中呢？一个简单的回答是，敏捷业者需要采用面向使用的需求描述方法，例如人物角色，情景描述，或者甚至是用例。常见的方法是在纸上创建出抽象的低保真度原型，就像图四(在本页最后)所示的那样用挂图和即时贴来创建。这使得你能够在不用事先进行很多工作的情况下就能快速开始研究用户界面，它甚至使得进行敏捷可用性测试成为可能。事实上，很多的敏捷方法已经这样做了，它们分别是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描述了一种使用抽象的原型来模拟系统的技术（见图四 在本页最后）。在这种方法中，一个开发人员负责模拟系统。他们不允许说话，只是帮助用户在“屏幕”（即纸面原型）之间进行导航。尽管有两个用户最好，不过要至少有一个用户利用纸面原型来完成场景中描述的任务。例如，在某大学系统中，某个场景可能是要求用户来报名参加某个研讨会。用户（们）应当在他们使用系统时说出他们正在思考什么。一个或多个开发人员担任观察者，他们做记录，但是他们不应当在用户使用系统时对这些纸面原型进行修改。

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

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

6.3 使用测试

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

7. 开始行动

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

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

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

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

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

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

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

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

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

8. 潜在的挑战

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

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

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

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

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

9. 感谢

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

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

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

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

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