用户案例怎么写_用户运营案例

大家好，又见面了，我是你们的朋友全栈君。

3C’s = 卡 (Card)，会话 Conversation)，确认 (Confirmation)”;

这个模板（来自Ron Jeffries）捕获了用户故事的组成部分：

第一个C (Card) 是原始形式的用户故事，即卡片。用户故事手动写在索引“卡”上，以保持简洁。标准格式有3个基本组件：作为[用户类型]，我想/需要[目标]，以便我可以完成[理由/商业价值]。该卡只是一个占位符。
第二个C (Conversion) 是对话。对话有必要获得有关卡的更多详细信息。该对话促进了敏捷团队之间的增量和持续协作，以便围绕问题和潜在解决方案建立共同理解。
第三个C (Confirmation) 是确认。确认是接受标准，它捕获基本要求并将其转换为测试标准，以便我们知道何时成功交付了用户故事。

用户案例 - 3Cs

1.卡 (Card)

用户故事应该能够放在3“x5”便条卡上，有效地捕获最重要的信息。虽然这个“C”有时指的是实际的记录卡，但我们的意思是它指的是用户故事的最佳尺寸。正如杰弗里斯所写，卡片不应包含有关要求的所有信息，而是足以用于规划识别要求并提醒项目团队的故事。每个用户故事都应遵循以下标准化格式：

“作为[特定用户]，我想[执行此操作]，以便[我可以实现此目标。]”

专注于收集每种用户类型的用户故事，以创建一组最具代表性的用户故事。用户故事应尽可能直接由用户编写。但是，根据项目类型和组织细节，用户故事也可以由项目团队成员和/或产品所有者编写。可以使用常见的启发技术（如访谈，问卷调查，观察和用户故事撰写研讨会）收集完整的用户故事集，以确保用户故事准确反映用户需求。

2.对话 (Conversation)

在用户故事即将被放入sprint之前，产品所有者应该与客户讨论他们的用户故事（或与其业务领域相关的用户故事）以进行详细说明和验证。与用户的协商对话是必要的，因为用户故事可能难以解释，可能需要一些背景知识来实现，或者自编写故事以来需求可能已经改变。

对话代表项目团队与产品所有者或其他利益相关者和商业中小企业之间的讨论。在这些对话中，产品所有者告知利益相关者正在发生的事情，利益相关者或团队成员交换想法，意见和感受。对话应在整个项目生命周期中进行。虽然我们主要讨论口头讨论，但对话还可以包括通过电子邮件，内部聊天程序或通过需求管理和业务分析工具（如Enfocus Requirements Suite™）进行的电子通信。

3.确认 (Confirmation)

用户故事的最后一个组成部分是用于确认用户故事是否已正确实施并成功交付的验收标准。必须在开发开始之前定义验收标准，以确定每个用户故事何时完成并按用户的意图工作。验收标准可用于演示用户故事的界限，并且通常在产品所有者，项目团队和用户之间进行对话时进行考虑。建议用户是编写验收标准的用户，因为每个用户故事都是从用户的角度编写的 – 因此确保用户故事完成和满意的测试也应由用户编写。

最好是这样定义验收标准的细节正是时候用户故事被放置在一个冲刺前。提供太多细节是浪费和耗时的，因为如果用户故事发生变化，则还需要更改细节。但是，提供太少的细节通常会导致重大的返工，并迫使开发人员做出错误的假设。它们应该被写成勉强够用; 也就是说，用户故事应该只包含启用开发所需的绝对最小信息量，并允许测试以合理的效率进行。这样做的理由是最大限度地减少在不增加最终产品价值的任何事情上花费的时间。