3C's = 卡 (Card)，會話 Conversation)，確認 (Confirmation)”;

這個模板（來自Ron Jeffries）捕獲了用戶故事的組成部分：

• 第一個C (Card) 是原始形式的用戶故事，即卡片。用戶故事手動寫在索引“卡”上，以保持簡潔。標準格式有3個基本組件：作為[用戶類型]，我想/需要[目標]，以便我可以完成[理由/商業價值]。該卡只是一個占位符。
• 第二個C (Conversion) 是對話。對話有必要獲得有關卡的更多詳細信息。該對話促進了敏捷團隊之間的增量和持續協作，以便圍繞問題和潛在解決方案建立共同理解。
• 第三個C (Confirmation) 是確認。確認是接受標準，它捕獲基本要求并將其轉換為測試標準，以便我們知道何時成功交付了用戶故事。

---

1.卡 (Card)

用戶故事應該能夠放在3“x5”便條卡上，有效地捕獲最重要的信息。雖然這個“C”有時指的是實際的記錄卡，但我們的意思是它指的是用戶故事的最佳尺寸。正如杰弗里斯所寫，卡片不應包含有關要求的所有信息，而是足以用于規劃識別要求并提醒項目團隊的故事。每個用戶故事都應遵循以下標準化格式：

“作為[特定用戶]，我想[執行此操作]，以便[我可以實現此目標。]”

專注于收集每種用戶類型的用戶故事，以創建一組最具代表性的用戶故事。用戶故事應盡可能直接由用戶編寫。但是，根據項目類型和組織細節，用戶故事也可以由項目團隊成員和/或產品所有者編寫。可以使用常見的啟發技術（如訪談，問卷調查，觀察和用戶故事撰寫研討會）收集完整的用戶故事集，以確保用戶故事準確反映用戶需求。

2.對話 (Conversation)

在用戶故事即將被放入sprint之前，產品所有者應該與客戶討論他們的用戶故事（或與其業務領域相關的用戶故事）以進行詳細說明和驗證。與用戶的協商對話是必要的，因為用戶故事可能難以解釋，可能需要一些背景知識來實現??，或者自編寫故事以來需求可能已經改變。

對話代表項目團隊與產品所有者或其他利益相關者和商業中小企業之間的討論。在這些對話中，產品所有者告知利益相關者正在發生的事情，利益相關者或團隊成員交換想法，意見和感受。對話應在整個項目生命周期中進行。雖然我們主要討論口頭討論，但對話還可以包括通過電子郵件，內部聊天程序或通過需求管理和業務分析工具（如Enfocus Requirements Suite?）進行的電子通信。

3.確認 (Confirmation)

用戶故事的最后一個組成部分是用于確認用戶故事是否已正確實施并成功交付的驗收標準。必須在開發開始之前定義驗收標準，以確定每個用戶故事何時完成并按用戶的意圖工作。驗收標準可用于演示用戶故事的界限，并且通常在產品所有者，項目團隊和用戶之間進行對話時進行考慮。建議用戶是編寫驗收標準的用戶，因為每個用戶故事都是從用戶的角度編寫的 - 因此確保用戶故事完成和滿意的測試也應由用戶編寫。

最好是這樣定義驗收標準的細節正是時候用戶故事被放置在一個沖刺前。提供太多細節是浪費和耗時的，因為如果用戶故事發生變化，則還需要更改細節。但是，提供太少的細節通常會導致重大的返工，并迫使開發人員做出錯誤的假設。它們應該被寫成勉強夠用; 也就是說，用戶故事應該只包含啟用開發所需的絕對最小信息量，并允許測試以合理的效率進行。這樣做的理由是最大限度地減少在不增加最終產品價值的任何事情上花費的時間。

敏捷軟件開發文章

• 什么是敏捷軟件開發？
• 什么是用戶故事？
• 什么是用戶故事映射？
• 用戶故事與敏捷軟件開發的使用案例

總結

以上是生活随笔為你收集整理的用户案例 - 3Cs的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。