敏捷人士不建模。其實(shí)敏捷業(yè)者是建模的，只是他們不鼓勵(lì)在初期進(jìn)行大規(guī)模的的設(shè)計(jì)工作，而鼓勵(lì)較為敏捷的建模。
敏捷開發(fā)就是不斷的“即開發(fā)即投入使用”。盡管有些團(tuán)隊(duì)如此，但這并不是規(guī)范的敏捷開發(fā)者的行為。敏捷開發(fā)者通常是有規(guī)律的交付正在開發(fā)中的軟 件，比如幾個(gè)星期，但也通常先在內(nèi)部環(huán)境中測試。而真正投入生產(chǎn)環(huán)境中，則通常需要6到12個(gè)月時(shí)間，也或者少于6個(gè)月，這要看我們最終用戶的要求和能 力，是否允許我們在相對(duì)較短的時(shí)間內(nèi)交付軟件。
XP是唯一的敏捷方法。這是極大的誤解，可能是因?yàn)槟承︰EX業(yè)者想當(dāng)然認(rèn)為這種敏捷方法比其他的敏捷方法都要好，就如同某些人會(huì)認(rèn)為Scrum，敏捷建模，MSF for Agile，或者DSDM也比其他的方法要好。
敏捷團(tuán)隊(duì)中沒有UEX業(yè)者的職位。在很多敏捷方法中放棄了對(duì)特定職位的需求，而是傾向于多功能職位，比如開發(fā)/編程，教練/領(lǐng)導(dǎo)，顧客/利益關(guān)系人。
敏捷者不是專攻一門技能的專家。這可能有道理，因?yàn)槊艚菡吒袷?全能通用專家’
用戶界面(UI)不該被重構(gòu)(refactored)。很多人會(huì)擔(dān)心重構(gòu)(refactoring)用戶界面，這通常是因?yàn)樗麄冋J(rèn)為UEX問題會(huì) 被遺忘，或者最終用者將無法應(yīng)付由重構(gòu)帶來的持續(xù)的變化。而事實(shí)情況是，UI的重構(gòu)帶來的是UI緩慢但安全的進(jìn)化，因此是改善了其設(shè)計(jì)。為了保證UEX問 題不被遺忘，具有UEX技能的人應(yīng)該參與到UI開發(fā)和進(jìn)化的過程中。當(dāng)然，我們希望UI的改變是朝好的方面改變，不過從開發(fā)到投入使用的整個(gè)過程中，只有 那些參與用者測試的人所受的影響最大，其他人受到的影響很少。另外，仔細(xì)想一想，如果可用性測試中發(fā)現(xiàn)了問題，難道開發(fā)者不應(yīng)該有所行動(dòng)來改善UI么?
同樣，敏捷團(tuán)隊(duì)也存在著對(duì)UEX團(tuán)隊(duì)的誤解：
UEX團(tuán)隊(duì)所關(guān)注的就是一套很不錯(cuò)的UI規(guī)范和指南。這是起碼的要求，但UEX不僅僅關(guān)注UI規(guī)范和指南，創(chuàng)建一致的UI，而且還關(guān)注更多
密切合作就可以了 。這也是起碼的要求，但Jokela和Abrahamsson (2004)發(fā)現(xiàn)僅僅靠開發(fā)者和利益關(guān)系人的密切頻繁的合作是根本無法保證好的可用性的。
UEX所作的僅僅是UI設(shè)計(jì)。顯然，UI是UEX的一部分，但是還要去了解用者將會(huì)如何使用你設(shè)計(jì)的系統(tǒng)，還要去了解用者的使用系統(tǒng)的目標(biāo)，這樣你才能夠打造出可以被他們使用的系統(tǒng)。完成這些，需要我們具備相當(dāng)水平的建模和合作能力。
UEX 依賴于前期全面的建模。盡管UEX界中有些人想讓你認(rèn)同這樣的看法（比如Cooper 2004），但是很多人卻不這樣認(rèn)為。在很多方面，做好UI的道理和做好architecture的道理是一樣的，通常是需要一些前期思想，但這并不意味 著一定要采取一系列的方法來實(shí)施。
此文章共有10頁 上一頁 1 2 3 4 5 6 7 8 9 10 下一頁
文章來源：中國項(xiàng)目管理資源網(wǎng)
|
Leadge.com首頁 > 知識(shí)庫 
