使用者故事與用例相容嗎？

在網上搜尋一番後，敏捷智者認為用例與使用者故事是兩種不同的事物：

• 麥克·科恩：使用者故事並非用例
• 艾利斯泰爾·柯克本：使用者故事之於用例，正如羚羊之於涼亭
• 極限程式設計網：使用者故事與用例的目的相同，但並非同一事物。

以用例為導向的方法曾是需求收集中最熱門的技術之一，但如今有些人認為這是一種過時的、老派的技術，與許多問題相關，這些問題導致你的團隊無法真正「敏捷」，原因在於用例本身存在的問題：

• 前期需求——試圖定義所有前期方面的細節，將導致大量無效的努力與時間浪費，因為大部分工作最終都需要重新進行。
• 功能分解：用例的功能性自然導致系統的功能分解，以具體與抽象的用例為基礎，這些用例透過「擴展」與「包含」的用例關聯相互連結。

如果你使用關鍵字「用例對比使用者故事」在網上搜尋，會找到一長串文章，指出用例方法的缺點、問題或陷阱，而關於使用者故事優點的清單甚至更長。有趣的是，IT產業的變化如此迅速，而人們從過去的「時尚」事物轉向現在的「新潮」事物的速度更是驚人。

有趣的是，有些人喜歡以二元對立的方式看待事物，並透過象徵性地連結時尚事物來追逐潮流，而非真正地實踐。有些人甚至不願讓別人知道他們仍在使用用例，否則可能會被認為過時且老派。

現在有些人將使用者故事與用例之間畫上等號：

• 敏捷 = 使用者故事，或敏捷 = 使用者故事 + 敏捷流程
• 使用者故事 = 剛好足夠且剛好及時
• 使用者故事 = 滿足使用者期望與滿意
• 用例 = 前期詳細的需求收集
• 用例 = <<包含>> + <<擴展>> = 功能分解
• 用例僅為「使用者輸入」→「系統回應」的單一模式
• 用例 = 老派且過時

作為工具供應商，我們在方法、工具與技術上保持相當中立。個人而言，我想強調的是，我非常支持敏捷開發、使用者故事與敏捷流程。特別是與以下概念相關的基礎原則與最佳實務：

• 需求探索而非需求交付
• 根據上述原則，敏捷開發過程將產生兩個重要特性：
  • 剛好及時
  • 剛好足夠

（我將撰寫更多與上述原則相關的個人觀點文章，這與我1992至1995年博士研究領域——元模型與模式轉換——密切相關）

現在，讓我們回到「用例對比使用者故事」這個主題。畢竟，重量級的敏捷智者們早已表態，我是否如此固執，試圖推翻他們的「投票」，僅僅因為我主張它們相似甚至相同？

讓我舉個例子，來說明使用者故事是否真的與用例「如此不同」：

範例

良好的使用者故事遠不止是陳述而已。一個標準的使用者故事由三個部分組成，通常被稱為三個C。

每個使用者故事的第一個「C」應遵循標準化格式：

作為[角色]，我希望[做某事]，以便[獲得利益]

這就是放入卡片中的使用者故事的最小內容。

對話是使用者故事第二個「C」的內容，代表終端使用者、專案負責人與開發團隊之間的討論。在這些對話中，會記錄口頭討論內容，以及其他許多有用的資訊，例如電子郵件、線框圖或任何與專案相關的其他內容。

使用者故事的最後一個「C」是確認，也就是用來確認使用者故事是否正確實現並成功交付的驗收標準。

讓我進一步說明如何發展使用者故事的確認部分。在這裡我們使用最著名的模板，稱為Gherkin，它採用「Given-When-Then」公式來引導撰寫使用者故事的驗收測試：

• (Given.. and) 某些情境
• (When.. and) 某些動作被執行
• (Then.. and) 執行某些動作

像Cucumber和Jbehave測試框架之類的工具，鼓勵使用Given/When/Then模板進行自動化測試，儘管它也可以純粹作為一種啟發式方法使用，而不論是否使用工具。

讓我們收集「註冊課程」使用者故事的所有資訊，並以三C格式呈現：

我採用了常見的三C格式來呈現「註冊課程」使用者故事。同樣地，我也採用了最廣泛使用的格式來描述相同的「註冊課程」用例，該用例由用例描述詳細說明。我為使用者故事的確認部分（最後一個C）的步驟編號，這些編號與我在用例描述中所列的步驟編號相對應。兩種方法都包含相同的「九步」情境，只是順序不同。我相信兩種模型表達方式對各自的支持者而言都是可接受的。那麼問題再次出現：使用者故事與用例非常相似，但又有所不同，還是步驟順序的差異導致對用例方法的各種批評？

語義等價但意義不同？

讓我們調查一下在建模領域是否存在類似情況，以便與這裡的情況進行比較，或這或許能幫助我們對「使用者故事 vs 用例」做出自己的判斷，而不是盲目跟隨群眾或像鸚鵡般重複聖賢的話。

範例：語義等價

在UML中，我們可以用順序圖來描述用例情境，但通常不會使用協作圖來達成相同目的；儘管這兩種圖在語義上是等價的。換句話說，順序圖與協作圖中參與情境的物件數量相同，傳遞的訊息數量也相同，且這些訊息是在相同的一組物件之間傳遞，以完成情境中的任務。然而，前者以時間為焦點，後者以空間為焦點。順序圖在與情境建模一起使用時更具直覺性，而協作圖則適合用來模擬物件之間的結構關係。例如，您希望將參與物件的情境以結構化的方式呈現於MVC架構（模型/檢視與控制層）中。

個人而言，我不認為使用使用者故事就能讓我的團隊變得敏捷，也不認為使用用例會讓我的團隊變得「過度預先規劃」。最重要的是我們以何種心態和最佳實務來應用和使用這些工具。我並不擔心別人認為我「老派」或過時，因為我實際上是採取敏捷的行動。

我仍記得結構化分析與設計的時代，或許我們可以在ADA中使用抽象資料類型來應用物件導向分析與設計原則，即使當時並未支援OOP，對吧？不幸的是，你甚至可能完全沒有接觸過抽象資料類型的概念！噢！我的天，我意外透露了——我老了嗎？還是我應該樂觀一點——有經驗？