敏捷可用性 - 敏捷项目中的用户体验（转载） 07.04.23 from 夏天  |
上一篇 下一篇 |
| Tag: |
这篇文章不错，快看看收藏了该文章的所有2人，我也要收藏 |
|
|||||
阅读本文英文原文 （翻译：张亮）
为了解决软件开发者所面临的困难，2001年7月，一个由17个方法学家组成的小组成立了敏捷软件开发联盟(Agile Software Development Alliance)，简称为敏捷联盟(Agile Alliance)。有趣的是，小组每个成员的背景都不相同，但却最后达成了方法学家们通常不会一致通过的协议。该小组共同制定了一个宣言，该宣言包含4 个价值和12个原则，主要目的是促进更优秀的软件开发方法；该宣言还制定了ASD过程的标准。
如同软件工程协会的软件能力成熟度模型 (Software Engineering Institute’s Capability Maturity Model Integrated (CMMI))为重量级软件开发过程定义的需求，敏捷宣言则定了敏捷软件开发过程的需求。反应了这些需求的敏捷过程包含如下内容：
绝大多数的敏捷项目的开发团队都少于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)先创建需求模型，之后交给构架师；构架师继而创建设计模型，再交给程序员；程序员写出程序之后再给测试工程师，等等。而在敏捷项目中，开 放者和利益关系人密切合作，从而可以更好的了解他们的需求；他们相互配合来实施并测试系统，之后将系统展现给利益关系人从而获得快速的反馈。传统开发过程 中分工细致，具有不同专长的人在不同阶段接力传递产品，并可能在整个链条中的各个阶段加入新的问题；敏捷开发者们综合了各种专业技能从而达成完整生命周 期。更重要的是从用户体验的角度来看，它们采用了不同于传统方法的建模和测试过程。
可用性是系统的一个质量属性，具体来说包括产品的可学性、使用效率、可记忆性、容错能力、和用户的满意度（Neilson 1994）。用户中心设计也叫做UCD，这几个字写起来简单，但却是高度结构化的产品开发过程，其核心在于理解使用者的需求和目标。Alan Cooper提出交互设计Interaction Design (ID)这种方法，其目标为产品的功能既要满足使用者的需求也要有用。在ID中，交互设计师关注用者所需的，工程师关注自身能力（技术上能实现什么、实现 到何种程度），商业利益关系人关注可行性。在此我这里统一使用用者体验一词(UEX)来涵盖所有的概念，尽管有些概念是不一样的，但在此为了讲述方便就没 有必要区分那么细致了。
为什么敏捷业者(agile practitioners)要考虑UEX的重要性呢？这是一个很关键的问题。Jeff Patton认为UEX解决了对于ASD团队成功与否至关重要的几个问题：
我在本文中使用的其它重要的词汇如下：
先来说好消息。我相信在敏捷团体和UEX团体中，对于双方协同工作的好处的认同感是在增加的。敏捷团体中，Larry Constantine的UCD工作是广受赞誉的，ASD的承诺也鼓舞着UEX人士。有一个邮件列表Agile Usability mailing list比较活跃，通过此列表ASD和UEX业者定期进行有规律的交流。在最近的UPA 2005和Agile 2005大会上，都有敏捷和可用性的讲座。目前也有一些呼声希望将两个团体合并起来。
现在来说坏消息。如果要想让两个团体能够有效的工作，目前还需要克服一些困难。就像我们在讨论两个不同团体，这本身就暗示着两者的合作可能存在一些困难，包括如下：
敏捷方法和UEX方法的比较
敏捷方法
UEX方法
为了推动这两个团体间更有效的合作，我们需要在这里澄清一些彼此间的误解。下面先列出UEX人士对敏捷团队的误解：
同样，敏捷团队也存在着对UEX团队的误解：
在进行建模时，敏捷业者是非常务实的。敏捷建模方法学描述了敏捷业者是如何进行建模和编写文档的。图二(在本页最后)是对敏捷模型驱动式开发方法 （Agile Model Driven Development）的生命周期的一个概览。这种方法最初产生于极限编程社区，不过它似乎抓住了一般的敏捷项目建模方法的实质。图中的每个方框表示一 个开发活动。位于第0周期中的初始建模活动包括了两个主要的子活动，即初始需求建模和初始体系结构建模，这两个活动同时以迭代的方式被进行。风暴式建模及 对模型的实现活动在任何周期中都可能发生，包括第0周期（是的，谣言没有说错，敏捷业者经常会在项目启动后的第一个星期中就开始软件编码实现了）。每个方 框中所标出的时间表示的是该活动在每次进行时平均需要多长时间：例如，在开发阶段，为了探究某个需求，你通常会和某个利益关系人一起花数分钟的时间进行风 暴式建模，然后你会花数小时的时间进行编码。
初始的建模工作一般是在项目开始后的第一个星期中进行的。对于持续时间较短的项目（可能需要数个星期），你可以在项目开始后的数小时内就进行这项工 作。而对于较长的项目（可能需要12个月或更多），你或许可以决定为之投入长达两个星期的时间。进行初始建模工作可以有两个方法：
在随后的那些活动周期中，初始的模型会随着你对项目了解的增多而逐渐完善，但在第0个周期中，你的目标仅仅是得到一个能够勉强工作的模型，这样整个 团队就能开始工作了。你不需要对很多细节进行建模，我再次强调一下：这个阶段的目标是使大家对项目有一个共同的理解，而不是编写详细的文档。
在开发周期中，大部分建模活动都会涉及多个人，通常是两个或三个。他们一边讨论，一边在纸上或白板上花一些草图。这些风暴式建模活动是“应需而做” 的：即当发现某个需要解决的问题时，你很快地从团队中找来一些可以帮助你的同事，大家一起研究该问题，然后每个人又都像先前一样回去继续各自的工作。
有些时候，只进行风暴式建模还不够。你可能需要对某些复杂的需求进行建模，而做到这一点需要来自团队外部的某些人提供信息。又或者，你需要对某个遗 留系统进行建模，它需要花费相当多的时间。换句话说，你可能需要在真正实现某个需求时，提前就进行建模。尽管传统的建模人员可能会希望如此，可实际上这种 情况是不太常见的，不过有时候它的确会发生。
所有这些都引出了以下这个问题：和用户体验设计有关的活动怎样才能融入到一个敏捷项目中呢？一个简单的回答是，敏捷业者需要采用面向使用的需求描述 方法，例如人物角色，情景描述，或者甚至是用例。常见的方法是在纸上创建出抽象的低保真度原型，就像图四(在本页最后)所示的那样用挂图和即时贴来创建。 这使得你能够在不用事先进行很多工作的情况下就能快速开始研究用户界面，它甚至使得进行敏捷可用性测试成为可能。事实上，很多的敏捷方法已经这样做了，它 们分别是Agile MSF, Agile Modeling 以及AUP方法。
尽管用户体验设计人员会大声疾呼在项目一开始就进行大量设计的必要性，然而敏捷社区却对其充耳不闻。从敏捷业者的角度看来，他们之所以这样做的大致 原因就在于：传统的用户体验设计技术对他们不太适用。当你停下来仔细考虑这个解释时，它显得很有讽刺性。为了使用户体验的设计技术对于敏捷业者更加可用， 这些技术必须要能反映出敏捷式开发的生命周期。幸运的是，这一点可以通过以下方式来实现：
就本文的目的而言，用户测试包括：
敏捷社区已经意识到了验收测试的重要性，他们已经构造了像Fit（Mugridge and Cunningham 2005）这样的工具来将验收测试自动化。自动化测试会被频繁进行，如果不是每天多次的话，至少也是每天一次。另一方面，手工用户测试一般是在每个迭代周 期的结束时进行的。在每个迭代周期结束后，很多敏捷团队会把开发完的系统部署到一个用于质量保证和测试的环境中，在那里将会进行用户和系统测试。这之后， 团队会继续开发系统的第N+1个版本，同时他们会收到关于第N个版本的缺陷报告。对这些缺陷报告的处理方式正如对其它的需求一样：它们会被评估，确定优先 级，然后被置于一个整体的需求堆中，以便在未来的某个时间对其进行处理。
在敏捷项目中，可用性测试被认为是可选做的内容。我可以很确信地说，很多的用户体验设计人员会对这种想法感到不满。在可用性测试这一点上，敏捷团队 和传统的开发团队没有什么区别，他们很可能无法理解可用性测试的必要性（或为达到可用性目标而采取的其它一些用户体验方面的设计技术）。真正的可用性测试 需要在受控的环境下反复对很多用户进行测试。正如验收测试可以在整个开发过程中定期进行一样，可用性测试也应当如此。在敏捷项目中，可用性测试应当在每个 迭代周期之后随同用户测试一起进行。当然，这是假定团队中有人具备进行可用性测试所需的技能。
在敏捷项目中，可用性测试的正式程度并非一成不变。较为“灵活”的方法是Jeff Patton提出的可用性测试。在2006年敏捷开发大会的一个工作组讨论中，Patton描述了一种使用抽象的原型来模拟系统的技术（见图四在本页最 后）。在这种方法中，一个开发人员负责模拟系统。他们不允许说话，只是帮助用户在“屏幕”（即纸面原型）之间进行导航。尽管有两个用户最好，不过要至少有 一个用户利用纸面原型来完成场景中描述的任务。例如，在某大学系统中，某个场景可能是要求用户来报名参加某个研讨会。用户（们）应当在他们使用系统时说出 他们正在思考什么。一个或多个开发人员担任观察者，他们做记录，但是他们不应当在用户使用系统时对这些纸面原型进行修改。
较为“正式”的方法则是传统的可用性测试。在这种情况下，研究人员在可用性实验室中观察用户如何使用系统。可用性实验室一般配备有单向玻璃，这使得 研究人员可以看到用户。对于开发人员来说，这通常都是一次很有价值的经历，因为他们之前往往会错误地认为自己设计的用户界面很棒。有些可用性实验室甚至还 配备有摄像机，这样你就可以记录下更精确的交互过程，从而可以回放用户的使用方法，对设计进行改进，以便去支持更有效的使用方法。
你可以自由地在项目进行到某些阶段时采取较为灵活的可用性测试，而在其它阶段采用较为正式的方法。你也可以自由地选择一种介于灵活和正式之间的可用性测试方法。
使用场景测试是这样的一种技术，它可以用来在实施之前测试你的设计中所蕴含的逻辑是否正确。这项技术包括了很多内容，它使得项目的利益关系人可以积 极地参与其中。同时，该技术能够并且应当和建模工作同时进行，以保证模型精确地反映了业务需求。你可以使用一个或多个使用场景（场景指的是人们如何使用系 统的一些列的步骤）来审查类模型，以便验证它们是否能够支持这些场景。如果模型不能支持场景，你就可以适当地修改模型（或者是修改代码，这要视具体情况而 定）。图五(在本页最后)展示了从审查类模型的角度来进行基于使用场景的测试过程。你可以遵循同样的逻辑来验证用户界面原型（即使对于抽象原型也可以如 此）。
如果敏捷社区和用户体验社区想要有效地一起工作，他们就需要找到一个中间立场。我相信这个中间立场是存在的，只是双方都需要做出一些改变才能成功做到这一点。首先，敏捷业者必须做到以下几点：
学习用户体验技术。开发人员应当接受用户体验设计技术方面的培训，并把这些技术应用到他们的开发实践中。这将使得开发人员能够更加有效地和用户体验设计人员一起工作。
认识到可用性是一个关键的质量因素。幸运的是，敏捷业者已经被“质量问题所感染” – 他们知道进行高质量工作的重要性，并且已经有了采取某些技术来取得高质量成果的良好记录，这些技术包括：测试先于编码的编程方式、代码重构以及数据库重 构。只有在开发过程中采取系统化的可用性工程活动，才能保证最终产品具有较好的可用性。
遵循用户界面及使用风格的设计指南。开发人员必须认识到，他们不仅是在编码时需要遵循共同的规范，在设计用户界面时也要如此。
同样地，用户体验设计人员也必须做出一些改变。他们需要：
不要局限于用户体验。我认为，开发人员和用户体验设计人员之间的很多矛盾都可以归因于他们职责的分工过于专门化，以及他们相互之间进行工作衔接时产 生的问题。敏捷业者基本上已经放弃了那种认为团队应当由专家来构成的想法，而是更喜欢由“知识广博的专家”构成的团队。这就意味着，尽管用户体验设计人员 为开发团队带来了一项关键的技能，然而为了能够产生真正的效果，他们仍然需要学习更多方面的技能。此外，敏捷业者通过更紧密的人员合作加强了软件项目中的 反馈过程，从而把风险和成本都减低了，而这继而又减少了不同成员之间的工作衔接的必要性。
融入到敏捷软件开发过程中。通过将用户体验设计人员融入到敏捷团队中的方法不仅能增加用户体验方面的问题被处理的机会，而且它还有助于提高敏捷社区在用户体验方面的设计技能，这是因为当人们在进行合作时，他们会从其他人那里学会新的技能。
给敏捷软件开发一个机会。Kent Beck 对于Alan Cooper的建议是，在项目开始时用一个星期的时间来研究交互设计方面的问题，而Cooper认为这还不够。到底谁说的对呢？最简单的方法就是在实践中去尝试。
不要局限于极限编程。在前文我已经说过，这里我再说一次，敏捷软件开发远不只是极限编程。敏捷方法是灵活的，它们不是要按照某个固定的模式来使用， 而是要根据项目所遇到的特殊情况来灵活运用。为了解决用户体验方面的问题，你很可能会发现，你需要把有关敏捷建模和（或）以用户为中心的设计方法的原理及 实施措施进行相应地调整，并把它们结合到你的软件开发过程中。
让敏捷业者花些时间来学习用户体验方面的技能并遵循恰当的界面设计指南，这个建议说起来容易，然而在现实中，还有很多其它同样重要的技能需要引起重 视，例如数据库设计和建模。更糟糕的是，很少有面向开发人员的书籍涉及用户界面设计及可用性方面的问题。很少的一些能够像我的“The Object Primer”一书那样谈到这个问题的书籍也很少会用超过一章的篇幅来讨论。我担心很多敏捷业者甚至根本意识不到这方面的问题。
同样地，用户体验设计人员也面临着不同的努力方向。尽管我提倡他们成为“知识广播的专家”，然而业界仍然鼓励他们更加专业—用户体验专家的待遇非常 好，大部分机构期望他们能够专注于用户体验设计这种特定的工作。敏捷业者也面临着这样的挑战：如果学习一门有关Java编程的课程能够得到相关的证书和更 高的工资，为什么要去学习一门用户界面设计的入门课程呢？
用户体验设计人员应当融入在敏捷项目中，这一点也是说起来容易。它这只有当项目中具有用户体验方面的专业人员时才可行。很少的机构具有这样的人员。 更糟糕的是，很少有机构会在制定需求计划或项目计划的过程中考虑交互设计。因此，很多机构可能认识不到聘用具有这些技能的人员的必要性。
如果没有专人负责用户界面设计的问题，这将意味着不论这方面的技能如何，每个人都想参与用户界面设计，而这会导致委员会式的设计（design by committee）。尽管在敏捷社区中有一种普遍的认同，即敏捷业者应当谦虚地认识到自己的能力，并且在解决某个特定的问题时应当尊重其它具有合适技能 的人，然而事情并不总是这样的—因为很显然，敏捷业者也是普通人。
用户体验设计人员有可能在敏捷团队中做出非常有价值的贡献，同时我认为与在传统的开发团队中工作相比，他们更有可能取得成功。到目前为止，可用性社 区在主流开发团队中试图积极参与其中的尝试还没有取得什么成功，因此是到了采取一种新方法的时候了。我的建议是，可用性设计人员应当同他们的敏捷业者“狱 友”紧密合作，以使得“监狱”得到更合理的控制。
我要感谢Paul Oldfield 和Tim Tuxworth ，他们提供了有关敏捷建模方法的列表，这使得我得以完成本文。
图二. 敏捷模型驱动式开发方法的生命周期（Agile Model Driven Development）
图三. 某个大学系统的用户界面导航图（徒手绘制）。
图四. 使用纸张创建出的一个抽象的用户界面原型。
图五. 从审查类模型的角度来进行基于使用场景的测试过程
| 上一篇 下一篇 （夏天的分类目录[用户体验]中共53篇） |
| 以文找文：搜索互联网上的相关文章 |
| 相关文章 |
|
或是邮件反馈可也:
askdama[AT]googlegroups.com
订阅 substack 体验古早写作:
关注公众号, 持续获得相关各种嗯哼:
