课程名称：DDD（领域驱动设计）思想解读及优秀实践
课程章节： 战略设计
课程讲师： 尤达_技术咖啡
课程内容：
如何进行用户故事描述？如何描述模型？从用户故事到通用语言
1，为什么需要用户故事？以及用户故事的作用？
因为研发总觉得产品文档写的不够细致，需求需要改动，而产品也是根据自己的认证范围给出的合理需求。所以无法做到产品和研发之间很好的沟通，所以需要用户故事描述，用户故事描述就是总结一句话：对问题的描述。
它从终端用户的角度对软件系统特性进行捕捉的一种方式。用户故事描述了不 同类型的用户需要什么以及为什么需要，它可以帮助我们创建需求的简单描述。
2，用户故事组成，以及怎么操作？3C和3W
三C： 卡片，谈话，验收
3W： 卡片内容，who（角色）,what（做什么），why（好处，便于）
在软件开发和演进过程中，随着产品和开发对产品认识的加深，需求总是在不断变化，所以，过早地进入需求细节以及对细节的描述，是一种时间上的巨大浪费。从这一
点来说，用户故事提供了一种恰到好处的粒度，使得产品在需求分析阶段能够极大地节约时间，并且使产品和研发人员始终把注意力集中在关键点，避免他们过早地陷入
细节以及被细节所局限，同时给产品功能留出了讨论空间，从而使产品有机会在讨论过程中得到优化。
用户故事的构建一般来说有三个环节：
1. 简单描述用户需求；
2. 围绕简单描述进行讨论；
3. 明确如何验证。
分别对应用户故事的三个元素，也就是3C：Card(卡片)、Conversation(谈话)、Confirmation(验证)。
1.1.1 Card(卡片）
“卡片”就是指对用户故事的简述（传统上人们通过便利贴在白板上构建用户故事），一个好的用户故事卡片包括三个要素：
-
谁：谁需要这个功能；
-
需要什么：想通过系统完成什么事情；
-
为什么：为什么需要这个功能，这个功能带来什么样的价值。
1.1.2 Conversation（谈话）
谈话是指用户、领域专家、产品经理、研发之间围绕用户故事进行的讨论，谈话是明确需求细节的必要环节。可以用文字对谈话进行简要记录，此外，也可以基于图形或
其他工具进行讨论。稍后我们会介绍相关工具可以对用户故事进行挖掘和细化([使用Domain Storytelling挖掘用户故事](# 2. 使用Domain Storytelling挖掘用户故事))。
1.1.3 Confirmation（验证）
验证代表了验收测试，描述了客户或者产品owner怎样确定用户故事已经被实现，且能够满足需求。一般可以用如下模板写Confirmation:
假设我是<角色>，在xxx情况下，
当我<操作>，
那么<结果>。