【正文】 任務列表，是對“海平面”層任務的線性化歸檔。也就是說，任務列表，以單一維度羅列的方式，對“海平面”層任務進行了詳細的、規(guī)范的記錄。它對每個任務都會記錄以下方面的內容：? 任務名稱? 編號? 所屬任務組? 是否為核心任務? 用戶、使用頻率、對用戶的價值、對業(yè)務的價值、物理環(huán)境? 任務創(chuàng)建過程中的任何信息任務模型為每一“海平面”層的任務都提供了上下文背景（語境圖）；任務列表則記錄了每個任務的詳細信息。任務列表相當于未細化的用例，包含了用例名稱、用例的范圍、用例的執(zhí)行者（Actor）、用例的目標層次、前置條件和觸發(fā)事件等。在下一節(jié)“編寫用例”時，我們將會豐富用例的“場景和步驟”以及其他部分信息。編寫用例星期日, 09月 13th, 2009 在編寫用例前，我們要理清該用例所要描述是任務所處的業(yè)務過程。也就是說，我們需要理清云彩層、風箏層、海平面層的所有任務以及其相互間的從屬關系，然后，我們重點分解海平面層（對應用戶級目標）的任務。當然，我們不可能一下就將任務粒度分解到海平面級，我們可以在任務分解過程中慢慢調整任務的粒度，最終都將任務分解為有最小業(yè)務價值的海平面級的任務。這種自上而下與自下而上的往返過程，正是我們所提倡的敏捷思想的體現——迭代?！霸诘^程中，任務的不確定性逐漸減小，我們對任務的描述也越來越明確?！倍_定“海平面”層的任務，已經在上一節(jié)“任務分解”的時候搞定。我們現在要做的，就是對每個“海平面”層的任務進行分解。對“海平面”層的任務進行分解的過程，也就是詳細的用例編寫過程。編寫用例的詳細過程以下是Alistair Cockburn給出的編寫用例的具體過程：1) 定義系統的范圍和邊界。 追蹤帶有輸入/輸出列表的初始語境圖的變化。 2) 集中討論，并列出主執(zhí)行者。 在系統整個生命周期內，找出每個人或非人的主執(zhí)行者。 3) 集中討論，并盡可能列出系統所有的用戶目標。 產生初始的執(zhí)行者目標列表。 4) 捕獲最外部的概要用例，看看哪個最值得關注。 對每個主執(zhí)行者檢查最外部的概要用例。 5) 再次考慮和修改概要用例。增加、減少或者合并用戶目標。 對基于時間的觸發(fā)事件以及系統邊界上的其他事件進行雙重檢查。 6) 選擇一個用例進行擴展。 考慮編寫一個敘述文檔來記錄資料。 7) 捕獲項目相關人員和利益、前提條件和保證。 系統確保前提條件和利益得到滿足。 8 ) 編寫主成功場景。 用3~9個步驟滿足所有利益和保證。 9) 集中討論，并盡可能列出所有擴展條件。 包括系統所能檢測到并且必須處理的所有條件 10) 編寫擴展處理的步驟。 每個處理結束于：返回主成功場景，一個單獨的成功結束條件，或者失敗。 11) 抽取復雜的處理流程作為子用例；合并瑣碎的子用例。 抽取子用例是容易的，但這會增加項目的開銷。 12) 重新調整用例集：進行必要的增加、減少和合并。 檢查可讀性、完備性以及是否滿足項目相關人員的利益。編寫用例的前5個步驟非常重要，我們在真正著手分解任務前，需要確定3點：我們所要分解的任務其范圍有多大，以及其所處的上下文背景（語境圖）是什么；執(zhí)行該任務的用戶是什么樣的；用戶執(zhí)行此項任務所要達到的目標有哪些。提供上下文背景的，正是我們上一節(jié)完成的“任務模型”，由任務模型充當每個用例的“語境圖”，為每個用例的編寫提供“全景導航”?！坝脩簟焙汀澳繕恕眲t是對應于我們之前完成的“用戶模型”和“目標模型”。在詳細編寫用例的每一步驟時，我們重點要描述的是每一步驟的“意圖”（相當于“較低層次的目標”），而非用戶執(zhí)行的動作。用戶執(zhí)行的具體動作與用戶所使用的“工具”（即我們要為其提供的軟件）有關，而這些與“工具”相關的動作，是我們在下一階段“UI設計”的時候才會考慮的事情?！熬帉懹美比匀皇窃诿枋鲇脩魹榱诉_到某種目標而采取的“行動”，只是用例中的步驟對應于較低層次（游魚層、蛤貝層）的目標罷了；編寫用例的過程屬于“分析問題”的過程，而UI設計，則是針對問題“提供解決方案”的過程。好的用例一般有3~9個步驟。幾乎所有多于11步的用例都可以被刪減/合并步驟而不影響其表達。也許，這與短時記憶的“7177。2”容量有關。當多于7步時，人們就開始自動“合并、歸類”，使操作步驟處在7177。2這樣一個短時記憶的容量限度內。Alistair Cockburn的經驗：至今還未見過一個合理的反例能證明交互步驟的多少對用例質量沒有影響。如果用例中的步驟超過了10，那么很有可能是涉及了過多的用戶界面的細節(jié)信息或者是所執(zhí)行步驟的“目標層次”太低（蛤貝層）。對于這種情況，我們可做如下處理：刪除用戶界面細節(jié)信息。顯示執(zhí)行者的目標，而非他的操作細節(jié)。提升目標層次，通過YY問“為什么”找出較高層次的目標。將某些交互步驟合并。用例什么時候才算寫完？當滿足如下要求時，用例的編寫才算完成：已經命名了與系統相關的全部“主執(zhí)行者”及其“用戶目標”。捕獲了系統的“全部觸發(fā)條件”，既包括用例觸發(fā)條件，也包括擴展條件。編寫了所有用戶目標用例以及必要的“概要用例”和“子功能用例”。每個用例描述的足夠清晰，使得：—投資方“確認”他們能夠區(qū)分這個用例是或不是要提交的用例?！脩簟按_認”用例表達了他們的要求，或者能接受這些用例作為系統的行為?！_發(fā)人員“確認”可以實現所有用例表示的功能。投資方“確認”用例集可以實現所有用例表示的功能。編寫用例的過程要敏捷（通過多次迭代來完善用例）我們不可能在一開始就將所有的用例細節(jié)都編寫到位，我們需要逐漸完善用例，合理分配精力，這樣，我們就不至于會在剛開始寫用例的時候陷于各種用例細節(jié)而失去了全局觀。這樣做有兩個好處：1）能讓團隊成員有機會深入考慮并修改用例的優(yōu)先級；2）確定優(yōu)先級后的用例，可以分派給多個小組并行撰寫用例步驟，這樣會提高團隊的整體工作效率。用例的編寫，基本可以分為4個階段：1) 找出用例的執(zhí)行者和目標（Actoramp。Goal） 列出系統所支持的執(zhí)行者及其目標。審查這個列表的正確性和完整性。劃分目標的優(yōu)先級，并將其分配到各小組和不同的發(fā)布版本中。至此，可獲得具有初級精度的功能需求。2) 撰寫用例概述和主成功場景。對于所選出的需要進一步細化的用例，勾勒出其主成功場景。審查這些草稿，以確保系統能夠真正表達我們所關心的項目相關人員的利益。3) 考慮操作失敗的場景。完成主成功場景，并集中討論所有可能發(fā)生的失敗場景。在想出系統如何處理這些失敗場景的辦法之前，首先擬定一個完整的失敗場景列表。4) 失敗場景的具體操作過程。寫出系統應該如何對這些失敗場景作出反應。這經常是棘手的、累人的工作，但同時也是最有價值的工作，因為在撰寫失敗場景的處理方案時，我們會澄清一個個原本模糊的業(yè)務規(guī)則，或者你會發(fā)現系統需要支持的新執(zhí)行者和新目標。其他注意事項我們編寫的用例主要是“海平面”層的。我們編寫用例時，用例所對應的用戶目標位“海平面”層。用例也可以對應更高層次的用戶目標，但那樣的用例更多的是在描述“業(yè)務”，而非“人機交互過程”。低于“海平面”的人機交互過程，通常不作為單獨的用例存在，但有一種情況例外：當該子用例“可重用”時就有必要單獨成為用例?！霸鰟h改查”的用例“子用例”對應于低于海平面的用戶目標，與此相反，“增刪改查”的用例則需要將多個海平面層的用戶目標合并在一起作為一個高于海平面的概要級用例。增加一個實體、刪除一個實體、修改一個實體、查找一個實體，這些都是基于數據庫操作的用例，我們可以將每一系列的操作作為同一個用例中的不同備選流程來對待。用例和需求的關系Alistair Cockburn強調了兩點：用例就是需求。但用例不是所有的需求。需求除了描述人機交互過程外，還包括：外部接口、數據格式、業(yè)務規(guī)則等。但是，為了使需求分析有章可循，我將需求的其他方面（如：外部接口、數據格式、業(yè)務規(guī)則等）也都包含在了用例中，這樣便于統一大家的需求分析方法，提高團隊的需求收集能力。輸出成果：用例集“編寫用例”階段的輸出成果就是將“任務建模”階段“任務列表”中提到的海平面級任務的人機交互過程詳細描述出來，即一整套編寫完畢的“用例集”。如下是我給出的用例模板，供大家參考：確定增量版本計劃，確定迭代開發(fā)計劃星期日, 09月 13th, 2009 計劃趕不上變化，但我們不能沒有“計劃”。敏捷思想提倡大家擁抱變化，但是“計劃”是我們行動的起點，是對我們未來工作的“假設”；執(zhí)行計劃的過程，也是擁抱變化的過程，是以穩(wěn)扎穩(wěn)打的項目進展驗證、替代對工作的原有“假設”（即，計劃）的過程。確定增量版本計劃在任務分解完畢后，我們就會得到“任務模型”?；谌蝿漳Ｐ?，我們就應該確定粗略的產品版本計劃：我們在第一個版本要為那些任務（業(yè)務）提供工具支持；第二個版本……；第三個版本……；……。版本計劃，對應于產品“增量發(fā)布”的計劃。每個版本，都是一個可以成形發(fā)布的產品。確定迭代開發(fā)計劃根據“任務模型”初步確定好“增量的版本計劃”后。我們需要為第一版本中涉及到的任務“編寫用例”，我們會最終形成第一個產品版本的“用例集”。采用功能分解或功能層次結構形成的用例集，展示了行為需求通信方面的有效性，并且使編程變得易于理解，系統行為也可以清晰地傳遞到更高層次。這種功能分解的方式可能有利于需求的收集，卻不一定有利于軟件的開發(fā)設計。數據和行為的封裝比較有利于軟件的開發(fā)和維護，但不利于需求收集。需求的收集得益于功能分解，但是軟件的開發(fā)和維護卻要得益于數據和行為的構件化。用例是按照不同的組織模式來劃分整個系統的，而不是按照對象而劃分整個系統。因此，面向對象的軟件開發(fā)人員，需要對用例進行必要的抽象，找出“對象”，并且將用例中涉及到的功能拆分成一個個“用戶故事”：也就是以“作為某種類型的用戶，我需要執(zhí)行任務，這樣我就能到達的目標”的格式描述的一個個功能點。每個“用戶故事”中只包含一個功能點（features），但是，一個功能點，也有不同的完善程度。例如：“發(fā)郵件”這一功能。僅考慮必要性步驟：? 表明我要發(fā)送一封郵件? 指名收件人? 寫郵件正文? 表明我要立刻發(fā)送郵件在必要性步驟的基礎上我們會進一步考慮可選步驟：? 寫郵件主題? 抄送或密送給其他人? 添加附件? 保存到已發(fā)送文件夾? 轉發(fā)然后，我們會考慮檢查和更正用戶輸入，添加業(yè)務規(guī)則限制某些操作：? 收件人地址檢查? 防止附加超過規(guī)定大小的文件最后，我們會考慮如何使每一步更簡單、更快捷和更有趣：? 自動填寫已有收件人地址? 拼寫和語法檢查? 在郵件正文添加表情圖標根據這些迭代依據，我們就可以確定每個迭代周期內所有實現的各用戶故事的功能層次。迭代計劃如下圖所示：小結有了迭代計劃和增量的版本計劃，我們就可以逐步踐行我們的敏捷用戶體驗涉及過程。什么是UI設計？09月 13th, 2009 在談“UI設計”之前，讓我們看看什么是“設計”？設計就是分析問題、并為之提供解決方案的過程，就是從備選方案中不斷做出決策的過程。通常，設計是由頭腦中的某個成形的備選方案開始的，隨著時間的推移，對問題的分析將會逐步被有效的解決方案所代替。通常，對問題的不斷探索有助于驗證解決方案的有效性。在我們之前提到的內容中，業(yè)務分析、用戶研究、用戶建模、任務分解等工作都是屬于“分析問題”的范疇；而編寫用例、提取用戶故事以及后面會提到的UI設計等工作，都是在“解決問題”。而銜接“分析問題”和“解決問題”的兩項工作——任務分解和編寫用例，你很難說它們到底是在分析問題還是在解決問題。“需求”與“設計”的區(qū)別就在于你是否做出了決策。如果做出了決策，你就是在做設計；如果沒有，你所面對的就只是需求。軟件設計的過程就是一環(huán)套一環(huán)的決策過程，UI設計是該決策過程的一部分。參考“用戶體驗要素模型”，從戰(zhàn)略層、范圍層、結構層、框架層到最后的表現層，都是一環(huán)套一環(huán)的決策過程。在軟件設計時，我們對問題的分析結果就是“需求”。需求有以下幾種：? 業(yè)務需求– 反映了客戶（或老板）對產品高層次的目標要求– 在項目愿景與范圍文檔中予以說明? 用戶需求– 描述了用戶使用產品必須要完成的任務– 可以在用例（或用戶故事）中予以說明? 功能需求– 定義了技術開發(fā)人員必須實現的軟件功能– 使得用戶能完成他們的任務，從而滿足了業(yè)務需求? 非功能需求– “過程需求”有交付、實現方法和標準等需求– “產品需求’包含性能、可用性、實用性、可靠性、可移植性、安全保密性、容錯性等方面的需求– “外部需求”有法規(guī)、成本、操作性等需求。而軟件設計過程中所涉及到的每個界面方面的決策，我們都需要將其畫出來，這就是“UI設計”。在“結構層”做出的決策，其表現方式就是功能/信息結構圖和流程圖。功能/信息結構圖體現的功能/信息的逐級分解體現的是整體與局部的關系；而流程圖是體現一屏屏的界面直接的跳轉關系的。由于流程圖涉及具體的屏幕界面，所以，它與框架層要輸出的成果——線框圖有著密切的關系。在具體的設計過程中，二者是同步成形的：線框圖記錄每個屏幕所要展現的細節(jié)；而流程圖則體現這些屏幕間的相互關系。最后，能體現表現層所做決策的成果就是視覺界面圖了。各位還記得用戶體驗的3層境界嗎？能用、好用、愛用。目標建模、任務建模以及業(yè)務分析工作，它們只能保證軟件產品“能用”。如果想讓軟件產品達到“好用”甚至“愛用”的用戶體驗境界，這主要是UI設計（以及用戶建模）所要解決的問題。50