阅读本文英文原文 （翻译：刘松涛）

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: Software Development Life Cycle – 软件开发的生命周期

图一：敏捷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的道理是一样的，通常是需要一些前期思想，但这并不意味着一定要采取一系列的方法来实施。

本文作者 Scott W. Ambler, 最初发表于 http://www.uigarden.net/chinese/min-jie-1。如想阅读更多类似文章，请到： www.uigarden.net

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