作者 Scott W. Ambler

閱讀本文英文原文 （翻譯：張亮）

1. 敏捷軟件開發(fā) (ASD – Agile Software Development)

為了解決軟件開發(fā)者所面臨的困難，2001年7月，一個由17個方法學(xué)家組成的小組成立了敏捷軟件開發(fā)聯(lián)盟(Agile Software Development Alliance)，簡稱為敏捷聯(lián)盟(Agile Alliance)。有趣的是，小組每個成員的背景都不相同，但卻最后達成了方法學(xué)家們通常不會一致通過的協(xié)議。該小組共同制定了一個宣言，該宣言包含4 個價值和12個原則，主要目的是促進更優(yōu)秀的軟件開發(fā)方法；該宣言還制定了ASD過程的標(biāo)準(zhǔn)。

如同軟件工程協(xié)會的軟件能力成熟度模型 (Software Engineering Institute’s Capability Maturity Model Integrated (CMMI))為重量級軟件開發(fā)過程定義的需求，敏捷宣言則定了敏捷軟件開發(fā)過程的需求。反應(yīng)了這些需求的敏捷過程包含如下內(nèi)容：

• Agile Data (AD)
• Agile Microsoft Solutions Framework (MSF)
• Agile Modeling (AM)
• Agile Unified Process (AUP)
• Dynamic System Development Method (DSDM)
• Extreme Programming (XP)
• Feature Driven Development (FDD)
• Scrum
• Usage-Centered Design (UCD)

絕大多數(shù)的敏捷項目的開發(fā)團隊都少于10個人，在同一地點工作，可以直接和利益關(guān)系人們(stakeholders)溝 通，利用一些常用的建模工具比如寫字板(writeboard)和公告板(corkboard)，擁有自己的開發(fā)機器，使用一些必需的工具，比如測試工 具。也有人指出，有些敏捷團隊可能也會比較大（可能好幾百人），可能分散在不同的地理位置上，有些人不是總能夠很容易的接觸到利益關(guān)系人 (Eckstein 2004)。雖然多數(shù)的敏捷團隊都采用測試主導(dǎo)的開發(fā)方式(TDD – test-driven development)，也就是開發(fā)的過程中間進行測試，寫完一部分代碼就測試一部分，他們通常都沒有測試UI的工具。而且，他們幾乎都沒有可用性實驗 室(usability lab)，因此從該角度來說，這樣的敏捷和傳統(tǒng)開發(fā)的區(qū)別不大。

我在圖一描述了一個普通的敏捷SDLC*，包含了4個階段：第0周期，開發(fā)階段，發(fā)布階段，和生產(chǎn)階段。盡管很多敏捷開發(fā)者否認這種階段式的概念，但實際上很多的敏捷過程中都包含了各個階段，比如XP，AUP, 以及敏捷MSF（這里將“階段”叫做track）。
*SDLC: Software Development Life Cycle – 軟件開發(fā)的生命周期

圖一：敏捷SDLC

下面我們來看看每一個階段：
1. 第0周期 敏捷項目開始的第一周時間左右，通常被稱為第0周期（”Iteration 0” or “Cycle 0”）。在本階段中啟動項目，主要目標(biāo)是收集項目的最初支持和資助，積極主動的與利益關(guān)系人溝通從而在較層次上定義要開發(fā)的軟件系統(tǒng)；組建團隊；為最初的 結(jié)構(gòu)建模；并準(zhǔn)備好工作環(huán)境。
2. *開發(fā)階段*。在開發(fā)階段，敏捷軟件開發(fā)者逐步交付高質(zhì)量的、可以滿足利益關(guān)系人的不斷變化的需求的軟件產(chǎn)品。
3. 發(fā)布階段 在此發(fā)布階段，敏捷軟件業(yè)者將開發(fā)中的系統(tǒng)交付到使用生產(chǎn)中。
4. 生產(chǎn)階段 本階段/周期目標(biāo)是保證系統(tǒng)投入使用后，一直有用，并具備持續(xù)的生產(chǎn)能力?；灸繕?biāo)是保證系統(tǒng)的正常運行，并幫助最終使用者來使用該系統(tǒng)。

表面上看起來，圖一中所示的敏捷SDLC非常像傳統(tǒng)的SDLC，但你仔細觀察，很快就會發(fā)現(xiàn)，它們是不一樣的。由于敏捷SDLC是需要高度協(xié)作的、 重復(fù) (iteractive)、循序漸進的，并且和傳統(tǒng)項目中的開發(fā)者相比，敏捷開發(fā)者所承擔(dān)的責(zé)任要多的多。在傳統(tǒng)項目中，商業(yè)分析師(business analyst)先創(chuàng)建需求模型，之后交給構(gòu)架師；構(gòu)架師繼而創(chuàng)建設(shè)計模型，再交給程序員；程序員寫出程序之后再給測試工程師，等等。而在敏捷項目中，開 放者和利益關(guān)系人密切合作，從而可以更好的了解他們的需求；他們相互配合來實施并測試系統(tǒng)，之后將系統(tǒng)展現(xiàn)給利益關(guān)系人從而獲得快速的反饋。傳統(tǒng)開發(fā)過程 中分工細致，具有不同專長的人在不同階段接力傳遞產(chǎn)品，并可能在整個鏈條中的各個階段加入新的問題；敏捷開發(fā)者們綜合了各種專業(yè)技能從而達成完整生命周 期。更重要的是從用戶體驗的角度來看，它們采用了不同于傳統(tǒng)方法的建模和測試過程。

2．用者體驗

可用性是系統(tǒng)的一個質(zhì)量屬性，具體來說包括產(chǎn)品的可學(xué)性、使用效率、可記憶性、容錯能力、和用戶的滿意度（Neilson 1994）。用戶中心設(shè)計也叫做UCD，這幾個字寫起來簡單，但卻是高度結(jié)構(gòu)化的產(chǎn)品開發(fā)過程，其核心在于理解使用者的需求和目標(biāo)。Alan Cooper提出交互設(shè)計Interaction Design (ID)這種方法，其目標(biāo)為產(chǎn)品的功能既要滿足使用者的需求也要有用。在ID中，交互設(shè)計師關(guān)注用者所需的，工程師關(guān)注自身能力（技術(shù)上能實現(xiàn)什么、實現(xiàn) 到何種程度），商業(yè)利益關(guān)系人關(guān)注可行性。在此我這里統(tǒng)一使用用者體驗一詞(UEX)來涵蓋所有的概念，盡管有些概念是不一樣的，但在此為了講述方便就沒 有必要區(qū)分那么細致了。

為什么敏捷業(yè)者(agile practitioners)要考慮UEX的重要性呢？這是一個很關(guān)鍵的問題。Jeff Patton認為UEX解決了對于ASD團隊成功與否至關(guān)重要的幾個問題：

• UEX強調(diào)了使用需求的必要性，必須要滿足用戶的需求目標(biāo)
• UEX可以幫助識別并確認軟件必須要有的功能
• 通過不同程度的手續(xù)和手段，UEX方法可以被采納的，這樣就使得UEX方法和敏捷方法是相容的，而不是相斥的。

我在本文中使用的其它重要的詞匯如下：

• 系統(tǒng) 就是產(chǎn)品，這里通常指在開發(fā)中的軟件
• 使用者/用者 通常也被稱為最終使用者，指的是最后將要使用這個目前正在開發(fā)中的系統(tǒng)/產(chǎn)品的那個/哪些人
• 開發(fā)者 構(gòu)建系統(tǒng)的IT專業(yè)人士
• 利益關(guān)系人利益關(guān)系人(stakeholders)指的是和本系統(tǒng)的研發(fā)或者使用有利益關(guān)系的任何人。這包括了直接用者、非直接用者、用者的管理 者、高級經(jīng)理、開發(fā)者、運行/操作員、技術(shù)支持者、和本系統(tǒng)有關(guān)系的其他系統(tǒng)的開發(fā)者、系統(tǒng)開發(fā)過程中或者系統(tǒng)實施時有可能受到涉及到維護者。在有些敏捷 方法學(xué)中，特別是 XP中，則籠統(tǒng)的將利益關(guān)系人叫做客戶(customer)。
• 驗收測試 是一種測試技術(shù)，其目標(biāo)是來驗證某系統(tǒng)是否達到了驗收(acceptance)標(biāo)準(zhǔn)，是否可以讓利益關(guān)系人來決定是否接受該系統(tǒng)。
• 可用性測試 讓該系統(tǒng)的用者們來執(zhí)行一系列的操作，從而來衡量該系統(tǒng)是否易于使用、測量任務(wù)的執(zhí)行時間和效率、用者的體驗和感覺?？捎眯詼y試可以很正式也可以不太正式，有的測試在配置了專門測試工具的房間中進行，有的測試則使用簡單的模型。
• 用者測試. 測試活動，包括接受度測試和可用性測試，通常利益關(guān)系人們都主動積極的參與。

3. 敏捷和UEX的現(xiàn)狀

先來說好消息。我相信在敏捷團體和UEX團體中，對于雙方協(xié)同工作的好處的認同感是在增加的。敏捷團體中，Larry Constantine的UCD工作是廣受贊譽的，ASD的承諾也鼓舞著UEX人士。有一個郵件列表Agile Usability mailing list比較活躍，通過此列表ASD和UEX業(yè)者定期進行有規(guī)律的交流。在最近的UPA 2005和Agile 2005大會上，都有敏捷和可用性的講座。目前也有一些呼聲希望將兩個團體合并起來。

現(xiàn)在來說壞消息。如果要想讓兩個團體能夠有效的工作，目前還需要克服一些困難。就像我們在討論兩個不同團體，這本身就暗示著兩者的合作可能存在一些困難，包括如下：

• 目標(biāo)不同. 軟件工程師關(guān)注軟件系統(tǒng)在技術(shù)上的設(shè)計、實施、以及維護。UEX業(yè)者則關(guān)注如何開發(fā)讓最終用者可以有效使用的系統(tǒng)。遺憾的是，兩個團體的人都無可避免的忽視了對方所關(guān)注的東西。
• 方式方法不同。UEX方法論集中用者身上，而敏捷方法論則更廣泛的關(guān)注利益關(guān)系人。采用UEX方法的人，在開始實施項目前，會試圖從整體上了解用者的需求，之后產(chǎn)生出一個用戶界面的整體計劃。敏捷方法則通常不會在實施前先進行設(shè)計，而是更注重較早的交付成型的軟件。
• 組織上的困難。敏捷業(yè)者遵從高度合作、流動性很強的組織結(jié)構(gòu)，團隊成員都是自我管理、自我組織的。然而，在高度集中化的UEX團隊中，情形就不是這樣了。UEX的中心是關(guān)注如何工作、關(guān)注提供所需的工具和標(biāo)準(zhǔn)等，強大的組織和管理結(jié)構(gòu)則可能會有問題。
• 進度不匹配。敏捷人士在項目的早期不會進行細致的建模過程，也就是被他們稱作“Big Design Up Front (BDUF)”。很多UEX人士則更喜歡在項目的初期進行較為綜合全面的建模過程，從而在開發(fā)開始前就設(shè)計出更合理的交互模型。
• UEX 業(yè)者較難被支持和了解。盡管在傳統(tǒng)團隊中敏捷的概念也很難被支持和了解，但相比之下UEX業(yè)者的處境更不好，因為敏捷業(yè)者還是比較贊同高層次的協(xié)同工作。 Jokela and Abrahamsson (2004)認為UEX業(yè)者經(jīng)常抱怨他們的工作成果沒有在設(shè)計結(jié)果中考慮到。他們還指出，在Agile Alliance成立的時候，也沒有UEX業(yè)者被邀請加入，這也可能是為什么ASD社團中缺乏UEX影響力的原因。
• 我們的精神領(lǐng)袖可能有些太極端。這表現(xiàn)在Kent Beck和Alan Cooper的討論中，他們分別是Extreme Programming (XP) 和 Interaction Design (ID)思想的創(chuàng)始人。我們在表一中標(biāo)出了他們討論的agile和UEX哲學(xué)的不同之處。不幸的是，Beck和Cooper似乎在這場討論中都很極端，我 們可以從對他們的采訪中看到有些原則性問題的爭論仍沒有解決。

敏捷方法和UEX方法的比較

敏捷方法

• 通常會問“在此階段我們?nèi)绾尾拍芨纳片F(xiàn)有的系統(tǒng)呢？”
• 你應(yīng)該緊密的和利益關(guān)系人或客戶協(xié)作，從而找出他們真正需求。
• 需求背后的細節(jié)可以在研發(fā)過程采用“臨時抱佛腳”的方法來發(fā)掘
• 細致的先期建模充其量也僅僅是個有風(fēng)險的工作
• 交互設(shè)計的工作從項目的一開始就存在，并伴隨整個項目過程

UEX方法

• 通常會問“理想的系統(tǒng)是什么樣呢？”
• 定義軟件產(chǎn)品或者服務(wù)是非常困難的，必須要從理解復(fù)雜系統(tǒng)，并對系統(tǒng)視圖化開始，而不能一上來就開發(fā)。
• 所有的行為細節(jié)要在開發(fā)前就得討論清楚

4. 澄清一些誤解

為了推動這兩個團體間更有效的合作，我們需要在這里澄清一些彼此間的誤解。下面先列出UEX人士對敏捷團隊的誤解：

• 敏捷人士不建模。其實敏捷業(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è)者想當(dāng)然認為這種敏捷方法比其他的敏捷方法都要好，就如同某些人會認為Scrum，敏捷建模，MSF for Agile，或者DSDM也比其他的方法要好。
• 敏捷團隊中沒有UEX業(yè)者的職位。在很多敏捷方法中放棄了對特定職位的需求，而是傾向于多功能職位，比如開發(fā)/編程，教練/領(lǐng)導(dǎo)，顧客/利益關(guān)系人。
• 敏捷者不是專攻一門技能的專家。這可能有道理，因為敏捷者更像是‘全能通用專家’
• 用戶界面(UI)不該被重構(gòu)(refactored)。很多人會擔(dān)心重構(gòu)(refactoring)用戶界面，這通常是因為他們認為UEX問題會 被遺忘，或者最終用者將無法應(yīng)付由重構(gòu)帶來的持續(xù)的變化。而事實情況是，UI的重構(gòu)帶來的是UI緩慢但安全的進化，因此是改善了其設(shè)計。為了保證UEX問 題不被遺忘，具有UEX技能的人應(yīng)該參與到UI開發(fā)和進化的過程中。當(dāng)然，我們希望UI的改變是朝好的方面改變，不過從開發(fā)到投入使用的整個過程中，只有 那些參與用者測試的人所受的影響最大，其他人受到的影響很少。另外，仔細想一想，如果可用性測試中發(fā)現(xiàn)了問題，難道開發(fā)者不應(yīng)該有所行動來改善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)的目標(biāo)，這樣你才能夠打造出可以被他們使用的系統(tǒng)。完成這些，需要我們具備相當(dāng)水平的建模和合作能力。
• UEX 依賴于前期全面的建模。盡管UEX界中有些人想讓你認同這樣的看法（比如Cooper 2004），但是很多人卻不這樣認為。在很多方面，做好UI的道理和做好architecture的道理是一樣的，通常是需要一些前期思想，但這并不意味 著一定要采取一系列的方法來實施。

5. 在敏捷項目中進行用戶體驗建模

在進行建模時，敏捷業(yè)者是非常務(wù)實的。敏捷建模方法學(xué)描述了敏捷業(yè)者是如何進行建模和編寫文檔的。圖二(在本頁最后)是對敏捷模型驅(qū)動式開發(fā)方法 （Agile Model Driven Development）的生命周期的一個概覽。這種方法最初產(chǎn)生于極限編程社區(qū)，不過它似乎抓住了一般的敏捷項目建模方法的實質(zhì)。圖中的每個方框表示一 個開發(fā)活動。位于第0周期中的初始建?；顒影藘蓚€主要的子活動，即初始需求建模和初始體系結(jié)構(gòu)建模，這兩個活動同時以迭代的方式被進行。風(fēng)暴式建模及 對模型的實現(xiàn)活動在任何周期中都可能發(fā)生，包括第0周期（是的，謠言沒有說錯，敏捷業(yè)者經(jīng)常會在項目啟動后的第一個星期中就開始軟件編碼實現(xiàn)了）。每個方 框中所標(biāo)出的時間表示的是該活動在每次進行時平均需要多長時間：例如，在開發(fā)階段，為了探究某個需求，你通常會和某個利益關(guān)系人一起花數(shù)分鐘的時間進行風(fēng) 暴式建模，然后你會花數(shù)小時的時間進行編碼。

初始的建模工作一般是在項目開始后的第一個星期中進行的。對于持續(xù)時間較短的項目（可能需要數(shù)個星期），你可以在項目開始后的數(shù)小時內(nèi)就進行這項工 作。而對于較長的項目（可能需要12個月或更多），你或許可以決定為之投入長達兩個星期的時間。進行初始建模工作可以有兩個方法：

1. 需求建模。你需要確定項目的高層需求以及最近的發(fā)布版本中將會包括哪些功能。這樣做的目標(biāo)就是要對整個項目是做什么的有一個較好的大致理解。為了 做到這一點，你很可能需要構(gòu)建初始的用戶使用模型，以便來研究用戶是如何使用系統(tǒng)的（例如，這種模型可以是用例模型或情景描述），你還可能需要構(gòu)造一個初 始的應(yīng)用領(lǐng)域模型，以便用來確定基本的業(yè)務(wù)實體類型及其相互關(guān)系。可以選做的其它內(nèi)容包括另外一些重要的模型，你可以使用這些模型來研究技術(shù)上的需求。

1. 體系結(jié)構(gòu)建模。初始體系結(jié)構(gòu)建模的目標(biāo)是要試圖確定一個極有可能使項目能夠很好工作的體系結(jié)構(gòu)。在99%的時間里，敏捷業(yè)者所做的就是聚集在一個 白板旁邊，一邊討論各種各樣的體系結(jié)構(gòu)策略，一邊畫一些沒有固定格式的圖表。當(dāng)用戶界面方面的體系結(jié)構(gòu)是需要重點考慮的問題時，敏捷建模人員會創(chuàng)建一個用 戶界面導(dǎo)航圖（見圖三在本頁最后），它描繪了一些重要的屏幕畫面、頁面以及報表之間的初始關(guān)系（這樣就能讓你對用戶界面有一個概覽，從而使得你能夠問一些 基本的可用性方面的問題）。

在隨后的那些活動周期中，初始的模型會隨著你對項目了解的增多而逐漸完善，但在第0個周期中，你的目標(biāo)僅僅是得到一個能夠勉強工作的模型，這樣整個 團隊就能開始工作了。你不需要對很多細節(jié)進行建模，我再次強調(diào)一下：這個階段的目標(biāo)是使大家對項目有一個共同的理解，而不是編寫詳細的文檔。

在開發(fā)周期中，大部分建模活動都會涉及多個人，通常是兩個或三個。他們一邊討論，一邊在紙上或白板上花一些草圖。這些風(fēng)暴式建?；顒邮?#8220;應(yīng)需而做” 的：即當(dāng)發(fā)現(xiàn)某個需要解決的問題時，你很快地從團隊中找來一些可以幫助你的同事，大家一起研究該問題，然后每個人又都像先前一樣回去繼續(xù)各自的工作。

有些時候，只進行風(fēng)暴式建模還不夠。你可能需要對某些復(fù)雜的需求進行建模，而做到這一點需要來自團隊外部的某些人提供信息。又或者，你需要對某個遺 留系統(tǒng)進行建模，它需要花費相當(dāng)多的時間。換句話說，你可能需要在真正實現(xiàn)某個需求時，提前就進行建模。盡管傳統(tǒng)的建模人員可能會希望如此，可實際上這種 情況是不太常見的，不過有時候它的確會發(fā)生。

所有這些都引出了以下這個問題：和用戶體驗設(shè)計有關(guān)的活動怎樣才能融入到一個敏捷項目中呢？一個簡單的回答是，敏捷業(yè)者需要采用面向使用的需求描述 方法，例如人物角色，情景描述，或者甚至是用例。常見的方法是在紙上創(chuàng)建出抽象的低保真度原型，就像圖四(在本頁最后)所示的那樣用掛圖和即時貼來創(chuàng)建。 這使得你能夠在不用事先進行很多工作的情況下就能快速開始研究用戶界面，它甚至使得進行敏捷可用性測試成為可能。事實上，很多的敏捷方法已經(jīng)這樣做了，它 們分別是Agile MSF, Agile Modeling 以及AUP方法。

盡管用戶體驗設(shè)計人員會大聲疾呼在項目一開始就進行大量設(shè)計的必要性，然而敏捷社區(qū)卻對其充耳不聞。從敏捷業(yè)者的角度看來，他們之所以這樣做的大致 原因就在于：傳統(tǒng)的用戶體驗設(shè)計技術(shù)對他們不太適用。當(dāng)你停下來仔細考慮這個解釋時，它顯得很有諷刺性。為了使用戶體驗的設(shè)計技術(shù)對于敏捷業(yè)者更加可用， 這些技術(shù)必須要能反映出敏捷式開發(fā)的生命周期。幸運的是，這一點可以通過以下方式來實現(xiàn)：

• 在項目的先期進行一些用戶界面的建模工作。你需要研究以下三個方面：適用于用戶任務(wù)結(jié)構(gòu)的各個用戶界面是如何構(gòu)成一個整體的；在各個部分之間進行 導(dǎo)航的一般方案；以及視覺和交互方案，這些方案能夠通過提供一致的感官體驗來支持用戶任務(wù)。的確，這個活動需要一些先期的工作，不過對于大部分的系統(tǒng)來 說，它可以很容易地在第0個周期中完成。請記住，你在先期需要完成的模型數(shù)量要視具體情況而定 — 有些團隊需要比其它團隊做得更多。
• 采用一些和敏捷方法相配合的建模工具。例如，極限編程團隊傾向于使用索引卡片（index cards），而不是編寫文檔，AUP團隊則傾向于在白板上畫草圖。幸運的是，紙張和白板對于很多用戶體驗設(shè)計人員來說也是常用的工具。
• 在大多數(shù)時間內(nèi)，按照“應(yīng)需而做”的原則來進行用戶界面的開發(fā)工作。如果有必要，你應(yīng)當(dāng)在實現(xiàn)之前對用戶界面方面的重要內(nèi)容進行研究。進行一次用戶研究通常需要預(yù)訂一些需求量很高的專用設(shè)備，以及和恰當(dāng)?shù)睦骊P(guān)系人預(yù)約好時間。因此，你需要稍微提前一些進行建模。
• 采用一些敏捷業(yè)者熟悉的需求描述方法。就像我前面所說的，一些敏捷方法已經(jīng)這樣做了，例如AUP，DSDM以及Agile MSF方法。同樣的道理也適用于極限編程。坦白地說，很多極限編程團隊已經(jīng)意識到要以一種講故事的方式來實現(xiàn)一個用戶界面。

6. 敏捷項目中的用戶測試

就本文的目的而言，用戶測試包括：

• 驗收測試（Acceptance testing）
• 可用性測試（Usability testing）
• 使用測試（Usage testing）

6.1 驗收測試

敏捷社區(qū)已經(jīng)意識到了驗收測試的重要性，他們已經(jīng)構(gòu)造了像Fit（Mugridge and Cunningham 2005）這樣的工具來將驗收測試自動化。自動化測試會被頻繁進行，如果不是每天多次的話，至少也是每天一次。另一方面，手工用戶測試一般是在每個迭代周 期的結(jié)束時進行的。在每個迭代周期結(jié)束后，很多敏捷團隊會把開發(fā)完的系統(tǒng)部署到一個用于質(zhì)量保證和測試的環(huán)境中，在那里將會進行用戶和系統(tǒng)測試。這之后， 團隊會繼續(xù)開發(fā)系統(tǒng)的第N+1個版本，同時他們會收到關(guān)于第N個版本的缺陷報告。對這些缺陷報告的處理方式正如對其它的需求一樣：它們會被評估，確定優(yōu)先 級，然后被置于一個整體的需求堆中，以便在未來的某個時間對其進行處理。

6.2 可用性測試

在敏捷項目中，可用性測試被認為是可選做的內(nèi)容。我可以很確信地說，很多的用戶體驗設(shè)計人員會對這種想法感到不滿。在可用性測試這一點上，敏捷團隊 和傳統(tǒng)的開發(fā)團隊沒有什么區(qū)別，他們很可能無法理解可用性測試的必要性（或為達到可用性目標(biāo)而采取的其它一些用戶體驗方面的設(shè)計技術(shù)）。真正的可用性測試 需要在受控的環(huán)境下反復(fù)對很多用戶進行測試。正如驗收測試可以在整個開發(fā)過程中定期進行一樣，可用性測試也應(yīng)當(dāng)如此。在敏捷項目中，可用性測試應(yīng)當(dāng)在每個 迭代周期之后隨同用戶測試一起進行。當(dāng)然，這是假定團隊中有人具備進行可用性測試所需的技能。

在敏捷項目中，可用性測試的正式程度并非一成不變。較為“靈活”的方法是Jeff Patton提出的可用性測試。在2006年敏捷開發(fā)大會的一個工作組討論中，Patton描述了一種使用抽象的原型來模擬系統(tǒng)的技術(shù)（見圖四在本頁最 后）。在這種方法中，一個開發(fā)人員負責(zé)模擬系統(tǒng)。他們不允許說話，只是幫助用戶在“屏幕”（即紙面原型）之間進行導(dǎo)航。盡管有兩個用戶最好，不過要至少有 一個用戶利用紙面原型來完成場景中描述的任務(wù)。例如，在某大學(xué)系統(tǒng)中，某個場景可能是要求用戶來報名參加某個研討會。用戶（們）應(yīng)當(dāng)在他們使用系統(tǒng)時說出 他們正在思考什么。一個或多個開發(fā)人員擔(dān)任觀察者，他們做記錄，但是他們不應(yīng)當(dāng)在用戶使用系統(tǒng)時對這些紙面原型進行修改。

較為“正式”的方法則是傳統(tǒng)的可用性測試。在這種情況下，研究人員在可用性實驗室中觀察用戶如何使用系統(tǒng)?？捎眯詫嶒炇乙话闩鋫溆袉蜗虿Ａ?，這使得 研究人員可以看到用戶。對于開發(fā)人員來說，這通常都是一次很有價值的經(jīng)歷，因為他們之前往往會錯誤地認為自己設(shè)計的用戶界面很棒。有些可用性實驗室甚至還 配備有攝像機，這樣你就可以記錄下更精確的交互過程，從而可以回放用戶的使用方法，對設(shè)計進行改進，以便去支持更有效的使用方法。

你可以自由地在項目進行到某些階段時采取較為靈活的可用性測試，而在其它階段采用較為正式的方法。你也可以自由地選擇一種介于靈活和正式之間的可用性測試方法。

6.3 使用測試

使用場景測試是這樣的一種技術(shù)，它可以用來在實施之前測試你的設(shè)計中所蘊含的邏輯是否正確。這項技術(shù)包括了很多內(nèi)容，它使得項目的利益關(guān)系人可以積 極地參與其中。同時，該技術(shù)能夠并且應(yīng)當(dāng)和建模工作同時進行，以保證模型精確地反映了業(yè)務(wù)需求。你可以使用一個或多個使用場景（場景指的是人們?nèi)绾问褂孟? 統(tǒng)的一些列的步驟）來審查類模型，以便驗證它們是否能夠支持這些場景。如果模型不能支持場景，你就可以適當(dāng)?shù)匦薷哪Ｐ停ɑ蛘呤切薷拇a，這要視具體情況而 定）。圖五(在本頁最后)展示了從審查類模型的角度來進行基于使用場景的測試過程。你可以遵循同樣的邏輯來驗證用戶界面原型（即使對于抽象原型也可以如 此）。

7. 開始行動

如果敏捷社區(qū)和用戶體驗社區(qū)想要有效地一起工作，他們就需要找到一個中間立場。我相信這個中間立場是存在的，只是雙方都需要做出一些改變才能成功做到這一點。首先，敏捷業(yè)者必須做到以下幾點：

學(xué)習(xí)用戶體驗技術(shù)。開發(fā)人員應(yīng)當(dāng)接受用戶體驗設(shè)計技術(shù)方面的培訓(xùn)，并把這些技術(shù)應(yīng)用到他們的開發(fā)實踐中。這將使得開發(fā)人員能夠更加有效地和用戶體驗設(shè)計人員一起工作。

認識到可用性是一個關(guān)鍵的質(zhì)量因素。幸運的是，敏捷業(yè)者已經(jīng)被“質(zhì)量問題所感染” – 他們知道進行高質(zhì)量工作的重要性，并且已經(jīng)有了采取某些技術(shù)來取得高質(zhì)量成果的良好記錄，這些技術(shù)包括：測試先于編碼的編程方式、代碼重構(gòu)以及數(shù)據(jù)庫重 構(gòu)。只有在開發(fā)過程中采取系統(tǒng)化的可用性工程活動，才能保證最終產(chǎn)品具有較好的可用性。

遵循用戶界面及使用風(fēng)格的設(shè)計指南。開發(fā)人員必須認識到，他們不僅是在編碼時需要遵循共同的規(guī)范，在設(shè)計用戶界面時也要如此。

同樣地，用戶體驗設(shè)計人員也必須做出一些改變。他們需要：

不要局限于用戶體驗。我認為，開發(fā)人員和用戶體驗設(shè)計人員之間的很多矛盾都可以歸因于他們職責(zé)的分工過于專門化，以及他們相互之間進行工作銜接時產(chǎn) 生的問題。敏捷業(yè)者基本上已經(jīng)放棄了那種認為團隊?wèi)?yīng)當(dāng)由專家來構(gòu)成的想法，而是更喜歡由“知識廣博的專家”構(gòu)成的團隊。這就意味著，盡管用戶體驗設(shè)計人員 為開發(fā)團隊帶來了一項關(guān)鍵的技能，然而為了能夠產(chǎn)生真正的效果，他們?nèi)匀恍枰獙W(xué)習(xí)更多方面的技能。此外，敏捷業(yè)者通過更緊密的人員合作加強了軟件項目中的 反饋過程，從而把風(fēng)險和成本都減低了，而這繼而又減少了不同成員之間的工作銜接的必要性。

融入到敏捷軟件開發(fā)過程中。通過將用戶體驗設(shè)計人員融入到敏捷團隊中的方法不僅能增加用戶體驗方面的問題被處理的機會，而且它還有助于提高敏捷社區(qū)在用戶體驗方面的設(shè)計技能，這是因為當(dāng)人們在進行合作時，他們會從其他人那里學(xué)會新的技能。

給敏捷軟件開發(fā)一個機會。Kent Beck 對于Alan Cooper的建議是，在項目開始時用一個星期的時間來研究交互設(shè)計方面的問題，而Cooper認為這還不夠。到底誰說的對呢？最簡單的方法就是在實踐中去嘗試。

不要局限于極限編程。在前文我已經(jīng)說過，這里我再說一次，敏捷軟件開發(fā)遠不只是極限編程。敏捷方法是靈活的，它們不是要按照某個固定的模式來使用， 而是要根據(jù)項目所遇到的特殊情況來靈活運用。為了解決用戶體驗方面的問題，你很可能會發(fā)現(xiàn)，你需要把有關(guān)敏捷建模和（或）以用戶為中心的設(shè)計方法的原理及 實施措施進行相應(yīng)地調(diào)整，并把它們結(jié)合到你的軟件開發(fā)過程中。

8. 潛在的挑戰(zhàn)

讓敏捷業(yè)者花些時間來學(xué)習(xí)用戶體驗方面的技能并遵循恰當(dāng)?shù)慕缑嬖O(shè)計指南，這個建議說起來容易，然而在現(xiàn)實中，還有很多其它同樣重要的技能需要引起重 視，例如數(shù)據(jù)庫設(shè)計和建模。更糟糕的是，很少有面向開發(fā)人員的書籍涉及用戶界面設(shè)計及可用性方面的問題。很少的一些能夠像我的“The Object Primer”一書那樣談到這個問題的書籍也很少會用超過一章的篇幅來討論。我擔(dān)心很多敏捷業(yè)者甚至根本意識不到這方面的問題。

同樣地，用戶體驗設(shè)計人員也面臨著不同的努力方向。盡管我提倡他們成為“知識廣播的專家”，然而業(yè)界仍然鼓勵他們更加專業(yè)—用戶體驗專家的待遇非常 好，大部分機構(gòu)期望他們能夠?qū)Ｗ⒂谟脩趔w驗設(shè)計這種特定的工作。敏捷業(yè)者也面臨著這樣的挑戰(zhàn)：如果學(xué)習(xí)一門有關(guān)Java編程的課程能夠得到相關(guān)的證書和更 高的工資，為什么要去學(xué)習(xí)一門用戶界面設(shè)計的入門課程呢？

用戶體驗設(shè)計人員應(yīng)當(dāng)融入在敏捷項目中，這一點也是說起來容易。它這只有當(dāng)項目中具有用戶體驗方面的專業(yè)人員時才可行。很少的機構(gòu)具有這樣的人員。 更糟糕的是，很少有機構(gòu)會在制定需求計劃或項目計劃的過程中考慮交互設(shè)計。因此，很多機構(gòu)可能認識不到聘用具有這些技能的人員的必要性。

如果沒有專人負責(zé)用戶界面設(shè)計的問題，這將意味著不論這方面的技能如何，每個人都想?yún)⑴c用戶界面設(shè)計，而這會導(dǎo)致委員會式的設(shè)計（design by committee）。盡管在敏捷社區(qū)中有一種普遍的認同，即敏捷業(yè)者應(yīng)當(dāng)謙虛地認識到自己的能力，并且在解決某個特定的問題時應(yīng)當(dāng)尊重其它具有合適技能 的人，然而事情并不總是這樣的—因為很顯然，敏捷業(yè)者也是普通人。

用戶體驗設(shè)計人員有可能在敏捷團隊中做出非常有價值的貢獻，同時我認為與在傳統(tǒng)的開發(fā)團隊中工作相比，他們更有可能取得成功。到目前為止，可用性社 區(qū)在主流開發(fā)團隊中試圖積極參與其中的嘗試還沒有取得什么成功，因此是到了采取一種新方法的時候了。我的建議是，可用性設(shè)計人員應(yīng)當(dāng)同他們的敏捷業(yè)者“獄 友”緊密合作，以使得“監(jiān)獄”得到更合理的控制。

9. 感謝

我要感謝Paul Oldfield 和Tim Tuxworth ，他們提供了有關(guān)敏捷建模方法的列表，這使得我得以完成本文。

圖二. 敏捷模型驅(qū)動式開發(fā)方法的生命周期（Agile Model Driven Development）

圖三. 某個大學(xué)系統(tǒng)的用戶界面導(dǎo)航圖（徒手繪制）。

圖四. 使用紙張創(chuàng)建出的一個抽象的用戶界面原型。

圖五. 從審查類模型的角度來進行基于使用場景的測試過程