敏捷人士不建模。其实敏捷业者是建模的，只是他们不鼓励在初期进行大规模的的设计工作，而鼓励较为敏捷的建模。
敏捷开发就是不断的“即开发即投入使用”。尽管有些团队如此，但这并不是规范的敏捷开发者的行为。敏捷开发者通常是有规律的交付正在开发中的软 件，比如几个星期，但也通常先在内部环境中测试。而真正投入生产环境中，则通常需要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的道理是一样的，通常是需要一些前期思想，但这并不意味 着一定要采取一系列的方法来实施。
此文章共有10页 上一页 1 2 3 4 5 6 7 8 9 10 下一页
文章来源：中国项目管理资源网
|
Leadge.com首页 > 知识库 
