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