敏捷开发的优势

    敏捷开发解决了长期困扰可用性专家们的三大问题：

    *     以过去50年的经验看，传统瀑布式开发导致了差的用户体验。原因很简单：需求说明书从来没对过。

    *    理想情况下 ，如果严格执行，需求是可能反映用户想要的东西的。但是更通常地反映的是离操作层太远以至于不知道操作细节的“典型”用户们的要求。一般而言，用户想要的和用户需要的是完全不同的，这就是“观其行而非听其言”一直成为首要可用性指南的原因。

    *    如果从撰写需求到交付产品需要很长的时间，用户的需求将非常可能发生变化，致使撰写的需求和用户实际的需求之间距离越来越大。

    *    在过去的25年中，可用性工作中提高设计质量的最好方法之一是观察用户和该设计进行交互（through either a functional or mocked-up screen ）。假如开发者们在时间溜走之前没有这样做，那他们的大部分的开发工作可能是围绕错误的设计在进行。

    *    同样，在瀑布开发后继阶段，按照文档苟且行事会带来诸多问题，更糟糕的是让开发者对照文档逐条逐字实现。很多问题出现在实施交互设计细节之中，在陈旧的设计和用户体验专家也已经早已离开的情况下，让开发者解决可用性问题，有点不现实。

    *    自1989年以来，因为其易操作性，在开发过程中可以被开发者经常使用的“简化的可用性工程”（discount usability engineering）被认为是提高用户体验的最佳方法。然而，在严格的瀑布开发流程中，这个方法根本不可能操作，原因在于无法在流程中获得用户反馈。

    敏捷开发有望解决传统开发方法对良好易用性造成的系统障碍。

    敏捷开发带来的问题

    敏捷开发对系统质量最大威胁在于它是由开发者提出，主要针对系统实现的方法。结果，交互设计和可用性问题经常被低估，而被认为是开发过程的附属结果。这显然和过去30年的经验相矛盾，用户体验在系统开发中的重要性随着我们从大型机发展到个人电脑再到网络的过程中稳步增强。随着用户增多和使用范围的扩大，现实世界对搞可用性的需求日益增大。

    为了建立好质量的用户体验，开发团队需要交互设计和可用性方法。对于小一点的团队，并不一定需要专门的设计师和可用性专家。让开发人员自己做交互设计和可用性考虑最为合适。但是，不管设计或可用性人员是专职还是兼职，重点在于在开发中要将交互设计和可用性设计作为单独明确的开发活动来实施。

    对于一个认真做交互设计和可用性的项目，必须和编码一样平等分配“story points”（译注： Story point是用于评估完成每个Story所要付出劳动，使用相对尺寸来估计）。

    另一个问题是，在开发中把一个产品分解成了更小的模块，让每人一次完成一个模块。此方法就冒了这样的风险：破坏了一个完整的用户体验概念——不同的部分始终如一的表现，帮助用户建立起一个完整的系统概念模型。最糟糕不过的是，界面设计成了修修补补的大杂烩。

    为了解决这个问题，团队可以设计包括用户界面架构的“storyboards” 和“原型”，以这些工具为参考点来设计单独的模块。为了避免在前期花费太多的时间，团队可以设计如纸面原型（不用编码的）的低保真原型，就像我们一直提倡的那样。

    敏捷开发团队通常在相当短的“sprints”中完成所有功能，一般就持续3个星期。以如此紧迫的期限，开发者们可能会绕过可用性设计，因为他们觉得没有时间去做测试或其它用户研究。

    解决方案包含三个部分：

    （1）用几天时间来做一些可用性活动，比如用户测试。一个富有成效的方法是在确切知道测试时会用到的东西时就提前做好准备。每周一次测试是非常可行的，且提供了一个整合多个用户反馈轮回的极好方法，甚至在最短的“sprint”里。

    * 我们有一个关于“怎样操作一回完整的用户测试”的3天课程，课程真实地就团队自己的项目进行测试。 你可以在一天之内完成这种类型的快速测试，而且准备测试的时间和分析结果的时间总共不到一天。

    （2）大部分成功的团队都采用了“并行工作”（parallel track）法，用户体验工作在开发编码之前就连续地进行了。因此，到开始开发一个模块的时候，该模块原始的用户体验工作就刚好完成。

    （3）最后，我们需要全面的用户调研（foundational user research），而不是单独针对功能点的设计开发。比较理想的是，公司应该在一个项目开始之前做这个工作。当然，大公司应该具备一些关于用户工作流程、人物角色和可用性指南的基本知识，这样以后的很多项目都可以参考使用。

    让敏捷和可用性相得益彰

    很有理由相信可用性和敏捷开发方法是一定可以并存来提高用户体验质量的。

    * 敏捷开发提供了很多机会来克服传统开发方法中长期阻止可用性的一些问题。

    * 作为程序设计方法而不是系统开发方法狭隘地使用敏捷开发可能会摧毁近10年来在整合可用性和开发方法的进展。但是，正如上文所说，每个问题都有相应的解决方法。只要团队把它们当成明确的问题来解决，就不会有损产品质量。

    * 最后，我们从研究中得知很多公司工作开展得很顺畅——只要他们用以质量为中心的系统开发方法，并配以合适的敏捷开发。

    对这些优势、问题和起作用的经验事实的分析是基于以下研究：

    （1）对105个设计者和开发专家的调查。

    （2）对12个公司关于敏捷开发项目深入的个案研究。

    虽然这些数据资料表现出很大希望，但我们还是发现了几例不好的结果，强调公司整合敏捷开发和可用性要采取明确措施的必要性。

    对于支持敏捷开发团队的用户体验从业人员来说，主要的变化在于心态。拥有良好而全面的用户体验知识将有助于理解怎样去改变传统设计和评估方法，从而满足敏捷开发团队的不同关注点

    总之，如果要取得成功，你就需要既有自信，又要把握敏捷开发的要义。

    如果你已经准备改变你的做事方法并付诸实施，你就有机会提高自身效率同时提升你在团队中的影响力。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。