方式方法不同。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人士对敏捷团队的误解：
此文章共有10页 上一页 1 2 3 4 5 6 7 8 9 10 下一页
文章来源：中国项目管理资源网
|
Leadge.com首页 > 知识库 
