|
[轉]任務、用例、用戶故事和場景 2010-12-21 22:47閱讀：1,466 任務Task任務，來自“目標導向的活動模型”，即：目標-任務-工具，它所描述的是人們?yōu)榱说竭_某種目標而采取的行動。用戶所采取的行動有大有小、有粗有細，其粒度是與“目標”的層次相對應的。設計軟件時，我們需要考慮海平面及更高的任務目標。 任務是對用戶為了達到某種目標所采取的行動的統(tǒng)稱，它既可以是海平面級的任務，也可以是風箏層、云彩層的任務。海平面級的任務是最小粒度的任務，游魚層、蛤貝層的用戶“行動”一般對應執(zhí)行任務時所采取的“步驟”，它們都沒有業(yè)務價值。因此，我們可以講任務定義為“有業(yè)務價值的”用戶行動。由于海平面級的任務有著最小的業(yè)務價值，所以，我們以后提到“任務”一詞時通常都特指“海平面級的任務”，對應“用戶級別的目標”。 用例UseCase“用例是代表系統(tǒng)中各涉眾之間就系統(tǒng)的行為所達成的契約。用例描述了在不同條件下，系統(tǒng)對某一涉眾的請求所做出的響應。提出請求的涉眾被稱為主執(zhí)行者（primaryactor）。主執(zhí)行者通過發(fā)起與系統(tǒng)的一次交互來實現某個目標。系統(tǒng)對任一執(zhí)行者所做出的響應，要保證所有涉眾的利益不受侵犯。根據執(zhí)行者做出的請求和請求涉及的條件，系統(tǒng)將執(zhí)行不同的行為序列，每一行為序列稱之為一個場景（Scenario）。一個用例是多個不同場景的集合?！?br/> 以上是AlistairCockburn在《編寫有效用例》中對“用例”的一段描述。在我看來，用例更像是一種文學體裁，一種與小說、詩歌、散文等并列的文學體裁。用例這種體裁很適合用來描述業(yè)務過程、軟件需求以及人機交互過程。也就是說，我們寫用例的目的，就是要對業(yè)務過程、軟件需求、人機交互過程等進行詳細準確的描述，以便讓涉眾就軟件系統(tǒng)的行為達成一致。而用例，正是能清晰地記錄涉眾所達成的一致意見的最佳表達形式，所以，用例不僅僅是一種“契約”，它也正是記錄涉眾就系統(tǒng)行為所達成的一致意見的“最佳體裁”。 正如任務會有不同的層級（云彩層、風箏層、海平面層），用例也可以描述不同層次的內容。因為用例只是一種“體裁”，所以它的內容可以非常廣泛：業(yè)務過程、軟件需求、人機交互過程。我們在“任務建?！彪A段，主要用用例來描述人機交互過程，并且，多數情況下是用來描述“用戶目標級”的任務的。用例也會包含這兩種情況：1）只描述用戶執(zhí)行任務的步驟；2）既描述用戶執(zhí)行任務的步驟又描述系統(tǒng)的反饋，此時的用 加載中... 內容加載失敗，點擊此處重試 加載全文 例反映整體的人機交互過程。在此給出用例的模板，供大家參考。 用戶故事UserStory在介紹“敏捷軟件開發(fā)生命周期：產品–>版本計劃–>迭代–>用戶故事”時，我們已經對“用戶故事”有過介紹：用戶故事是最基本的設計單元。用戶故事就是以用戶的語言對產品功能（feature）所作的描述。關于用戶故事，應注意以下幾點： 每個用戶故事，只描述一個功能（feature） 用戶故事，用的是用戶的語言，體現了“以用戶為中心”的思想 用戶故事是產品設計的上下文背景 用戶故事，是用來做出開發(fā)計劃的，每個用戶故事的開發(fā)周期不要太長，建議不超過1周或10天（屬經驗性估計，僅供參考，您別跟我較真，別問我為什么不是1周零一天或11天等等…….。一個用戶故事是最小的開發(fā)單元，所以開發(fā)一個用戶故事的時長最好是您能掌控的最小開發(fā)周期，所以給出了1周或10天的建議。） 接上一點。“能掌控”，就意味著每個用戶故事都可以在“事前”被準確地估量出來，“事后”被準確地衡量。 用戶故事由3部分組成：用戶（user）、任務（task）以及用戶執(zhí)行該任務所要達到的目標（goal）。通常的格式如下： 作為 [某種類型的用戶] 我想 [執(zhí)行某某任務] 這樣，我就能 [達成某某目標] 例如： 作為 “直奔主題”的購物者 我想 在店內找到CD的位置 這樣，我就能 快速買下它，然后馬上離開；我好繼續(xù)回到自己的生活軌跡中，愛干嘛干嘛了。 “Why”一般包括以下幾個當面： 1. 客戶要求（客戶價值） 2. 給公司帶來直接或者間接的經濟效益（公司價值） 3. 減小公司的成本，例如降低風險等（平臺價值） “用戶故事”這一概念是在敏捷開發(fā)過程中為了控制項目的迭代進度而采用的。用戶故事是最小的設計單元，它只包含一個功能點，可以被任意地分配給任何一個開發(fā)人員來實現。用戶故事中所包含的功能點，可能只對應用例/任務中某一步驟中所涉及的某一個具體操作，UserStory通常會比UseCase小。但是，為了在開發(fā)人員在實現該功能時，能夠貫徹UCD思想，體現用戶目標，所以我們會在描述該功能的時候提及用戶的“目標”和“任務”，當然，也會說明該功能所要面對的用戶是什么樣子的。這樣，就有了用戶故事“作為[××用戶]，我需要[××功能]支持我完成[××任務]，這樣，我就能達成[××目標]”。 Alistair Cockburn曾對User Story、Use Case、Scenario作過區(qū)分： A user story is the title of one scenario whereas a use case is thecontents of multiple scenarios “用戶故事”相當于“場景”的標題，而“用例”則是多個“場景”內容的集合。 由于“場景”是一個“行為序列”，那么它必定會涉及多個操作，勢必也需要軟件系統(tǒng)提供多個“功能”。依我本人的看法，每個用戶故事只會包含一個功能點，這樣會方便開發(fā)工作的分配，有利于項目迭代進度的掌控。但是，依Cockburn的看法，每個用戶故事會包含一個“行為序列”中的所有功能（不值一個功能）。我是這么處置我與Cockburn觀點上的分歧的：如果每個用戶故事包含一個功能點好安排工作、有利于掌控項目進度，我們就在每個用戶故事中只包含一個功能點；如果每個用戶故事包含一個“行為序列”（一個場景）中涉及的多個功能點更利于安排工作、更利于掌控項目進度，我們就在每個用戶故事中包含多個功能點。 “用戶故事”是項目管理的一種工具，每個用戶故事的開發(fā)時間不應長于10天，否則項目進度不易掌控。UserStory更像是分析問題、規(guī)劃項目進度時所用工具，而Use Case則是對業(yè)務、需求等分析的結果。 場景Scenario “場景”這個詞，有兩撥人在用：一撥是交互設計師（如AlanCooper）；另一撥是需求分析師（如AlistairCockburn）。當然，他們所指的含義也不一樣。關于“場景”一詞兩用的情況，在RUP（Rational UnifiedProcess）中已有辨析：“場景”在 RUP內部指用例實例，即只是一個經過可能的基本流和備選流的特定“路徑”（即Cockburn所說的“一個行為序列”）。但是，在以用戶為中心的設計方法和用戶界面設計方法中常常將“場景”描述為使用經歷（Cooper就這么做），這實際上包含了更多的細節(jié)，而不僅局限于事件流。雖然該附加信息可能與后來的設計階段無關，但它對于了解用戶、任務和環(huán)境卻必不可少。因此，場景可以在業(yè)務建模工作流程中廣泛應用，但是在需求工作流中，重點則轉移到用例上。 小結任務來自“目標導向的活動模型”（目標-任務-工具），它所描述的是人們?yōu)榱说竭_某種目標而采取的行動。沒有其他說明的情況下，“任務”一詞通常都特指“海平面級的任務”，對應“用戶級別的目標”。海平面級的任務是最小粒度的任務。 用例是記錄各涉眾之間就系統(tǒng)的行為所達成的契約的“最佳體裁”。 用戶故事是分析問題、規(guī)劃項目進度時所用工具，而用例則是對業(yè)務、需求等分析的結果。用戶故事是最小的設計單元，它只包含一個功能點。 場景經常被交互設計師用來描述業(yè)務建模工作流程中用戶的使用經歷，但是在需求工作流中，場景則是用例的一個具體實例，是一個經過可能的基本流和備選流的特定“路徑”（即Cockburn所說的“一個行為序列”）。交互設計師所說的場景中涉及的Actor肯定是人，而用例中的場景，它的Actor既可以是人，也可以是軟件系統(tǒng)。 Alistair Cockburn說：“用戶故事”相當于“場景”的標題，而“用例”則是多個“場景”內容的集合。 |
|
|
