方式方法不同。UEX方法論集中用者身上，而敏捷方法論則更廣泛的關注利益關系人。采用UEX方法的人，在開始實施項目前，會試圖從整體上了解用者的需求，之后產(chǎn)生出一個用戶界面的整體計劃。敏捷方法則通常不會在實施前先進行設計，而是更注重較早的交付成型的軟件。
組織上的困難。敏捷業(yè)者遵從高度合作、流動性很強的組織結(jié)構(gòu)，團隊成員都是自我管理、自我組織的。然而，在高度集中化的UEX團隊中，情形就不是這樣了。UEX的中心是關注如何工作、關注提供所需的工具和標準等，強大的組織和管理結(jié)構(gòu)則可能會有問題。
進度不匹配。敏捷人士在項目的早期不會進行細致的建模過程，也就是被他們稱作“Big Design Up Front (BDUF)”。很多UEX人士則更喜歡在項目的初期進行較為綜合全面的建模過程，從而在開發(fā)開始前就設計出更合理的交互模型。
UEX 業(yè)者較難被支持和了解。盡管在傳統(tǒng)團隊中敏捷的概念也很難被支持和了解，但相比之下UEX業(yè)者的處境更不好，因為敏捷業(yè)者還是比較贊同高層次的協(xié)同工作。 Jokela and Abrahamsson (2004)認為UEX業(yè)者經(jīng)常抱怨他們的工作成果沒有在設計結(jié)果中考慮到。他們還指出，在Agile Alliance成立的時候，也沒有UEX業(yè)者被邀請加入，這也可能是為什么ASD社團中缺乏UEX影響力的原因。
我們的精神領袖可能有些太極端。這表現(xiàn)在Kent Beck和Alan Cooper的討論中，他們分別是Extreme Programming (XP) 和 Interaction Design (ID)思想的創(chuàng)始人。我們在表一中標出了他們討論的agile和UEX哲學的不同之處。不幸的是，Beck和Cooper似乎在這場討論中都很極端，我 們可以從對他們的采訪中看到有些原則性問題的爭論仍沒有解決。
敏捷方法和UEX方法的比較
敏捷方法
通常會問“在此階段我們?nèi)绾尾拍芨纳片F(xiàn)有的系統(tǒng)呢？”
你應該緊密的和利益關系人或客戶協(xié)作，從而找出他們真正需求。
需求背后的細節(jié)可以在研發(fā)過程采用“臨時抱佛腳”的方法來發(fā)掘
細致的先期建模充其量也僅僅是個有風險的工作
交互設計的工作從項目的一開始就存在，并伴隨整個項目過程
UEX方法
通常會問“理想的系統(tǒng)是什么樣呢？”
定義軟件產(chǎn)品或者服務是非常困難的，必須要從理解復雜系統(tǒng)，并對系統(tǒng)視圖化開始，而不能一上來就開發(fā)。
所有的行為細節(jié)要在開發(fā)前就得討論清楚
4. 澄清一些誤解
為了推動這兩個團體間更有效的合作，我們需要在這里澄清一些彼此間的誤解。下面先列出UEX人士對敏捷團隊的誤解：
此文章共有10頁 上一頁 1 2 3 4 5 6 7 8 9 10 下一頁
文章來源：中國項目管理資源網(wǎng)
|
Leadge.com首頁 > 知識庫 
