用戶故事vs使用案例

Question

用例是否只是多個用戶故事？

使用用戶故事比使用用例有什麼好處？反之亦然...何時使用用戶故事比其他... 所有敏捷方法都使用用戶故事嗎？

Answer 1

實際上，原來的用例（請參閱Jacobson's OOSE）非常輕便，就像用戶故事現在一樣。隨着時間的推移，它們會不斷髮展，直到現在用於「用例」的通用格式是一個帶有輸入，輸出，繼承，使用關係，僞代碼等的複雜文檔。程序員通常會嘗試將所有內容轉換爲編程。

在任何情況下，試圖定義什麼從「用戶故事」一「用例」區別開來回回一個「情景」是相當徒勞的，因爲它很難找到兩個部門誰同意。\

個人，我發現模式「[演員] [動詞] [名詞]獲得[商業價值]」有幫助。如果它解決了一段文字，它可能太大了。

Answer 2

當涉及到它時，「敏捷」只是一個標籤，人們對它的含義不一致。同樣，人們稱不同的事物爲「用例」。

根據我的經驗，兩者之間的主要區別在於用戶故事集中在用戶身上，而且通常更短，更不正式 - 理想情況下，它應該很容易放在明信片上。它可能不給錯誤的細節處理等

用例可以更加正式的（雖然有些人寫他們非正式太） - 他們注重與系統的每一次互動，並很可能進入更多關於同一用例中幾個不同系統/演員/等的細節。

雖然這只是我的經驗 - 每個人都有可能以不同的方式使用這些工具。我不會太在意標籤 - 只是使用適合您的項目的東西。

Answer 3

您可以將用例視爲用戶故事，而不是其他方式。用例將涵蓋故事的多個「結尾」，特殊要求（例如，表單字段必須以xyz格式輸入，如果用戶以錯誤的格式輸入字段，則顯示錯誤消息123）。此外，用例還可以包含對外部文檔的其他引用，例如安全準則。

Answer 4

總之，沒有。

使用案例通常是詳細的規範，規定了某些特定功能將如何工作，或者特定用戶將如何使用該系統。它通常具有特定用戶（或演員）的聲音並且相當獨立。

另一方面，用戶故事是「討論邀請」。它通常是一兩句話。 Here是一個很好的資源。 Mike Cohn的User Stories Applied非常值得。

典型的語法是「作爲一個<用戶>我需要<功能>實現<商業價值>」，或者「要實現<商業價值>作爲<用戶>我需要<功能>」驅動回家故事的價值。

用戶故事是而不是意思是獨立的，但意味着邀請開發者和客戶（或客戶代理）之間的故事的討論。

Answer 5

使用情況都不是用戶故事彙編。

用戶故事通常比使用情況要簡單得多。我認爲用例試圖覆蓋與系統某些方面的行爲有關的所有事情。也就是說，所有行爲，所有錯誤路徑和所有異常處理。

爲用戶推薦的模板是：

作爲一個（角色）我想（的東西），這樣（的利益）

（感謝邁克·科恩提供了這個簡單的模板）

像這樣表達的行爲描述更敏捷。

這種類型的模板，您可以使用不同級別的細節描述的行爲。例如：

1. 對於在稍後的衝刺中實施的那些故事，您可以以高級別的方式描述行爲，例如，作爲一名ops團隊成員，我想遠程監控系統，以便我可以在路上確定系統健康狀況。
2. 對於在下一次衝刺中實施的故事，您可以描述行爲是一種稍微更詳細的方式，例如，作爲ops團隊成員，我希望擁有專門的ops only登錄，以便我可以檢查系統運行狀況。
3. 對於在當前衝刺中實施的那些故事，您可以用非常詳細的方式描述行爲，例如，作爲ops團隊成員，我希望有一個Web界面，以便我可以檢查攝入ftp服務器的當前狀態。

恕我直言用例更刻在石頭上！因此在初始版本之後更新可能會有問題。

HTH

歡呼聲，

羅布

Answer 6

我同意大多數在這個頁面的答案，特意從埃利的一個，但我仍然認爲這是值得總結會的想法。

因此，用例是一個UserStory，可能由一組互相連接的用戶故事組成，它向用戶交付業務價值。

讓我解釋一下我自己：最關鍵的區別是「相關的商業利益」。結果。

例如一個用例時ATM可能是「用戶使用ATM得到一些現金。」有一個用戶，一個系統和一個結果明確的用例。現在，如果我們在敏捷團隊中開發ATM，我們可能會有一個「用戶登錄ATM」的故事。因此，用戶故事可以是用戶在與系統進行交互但沒有明確結果時所做的「有趣的」可測試和相關的一組操作。沒有人會爲了娛樂而登錄系統。這樣做沒有好處。在一個UML用例圖中，也許我們仍然是一個用例...也許使用「包含」關係......但是我認爲這將會使用用例圖發出嗒嗒聲。因此，正如Elie所說，用例是一個有目的的結果用戶故事。所以，這就是你想成爲「用例驅動」而不是「用戶故事」驅動的方式。因爲，也許最好的方式來實現一個沒有結果的用戶故事就是將它從你的系統中刪除:)。 如果ATM可以看我的臉，讓我在沒有我輸入可能很好的密碼。