版权声明：欢迎转载，注明出处就好！如果不喜欢请留言说明原因再踩哦，谢谢，我也可以知道原因，不断进步！！ https://blog.csdn.net/wzhqazcscs/article/details/85218966
用户故事描述了对用户、客户有价值的功能的简短描述，并不是具体需求本身。
用户故事的模型
3C：card（卡片），conversation（交谈），confirmation（确认）。
- card（卡片）
- 一份书面的故事描述，用来做计划和作为提示。
- 用户故事最明显的表现，但它不是最重要的。
- 代表了用户需求，而不是记录需求。
- 模板：作为（角色），我想要（功能），已实现（商业价值）。
- conversation（交谈）
- 故事的需求细节，用于具体化故事细节。
- 模板：一两句重要细节的短语或注释，提醒后续进行讨论
- confirmation（确认）
- 测试要求，用于表达故事细节，且可用于确定故事何时完成。
- 用户的期望，最好以验收测试的形式被记录下来。
- 模板：用XX功能测试通过，用XXX功能测试失败。
用户故事的六大特征
- 独立的（independent）
尽量避免故事间的相互依赖。 - 可讨论的（negotiable）
- 故事卡的作用是提醒客户团队和开发团队在以后要进行关于需求的对话，它并不是具体的需求本身。
- 对应用户故事的conversation。
- 对用户或客户有价值的（valuable to purchasers or users）
- 避免那些只对开发人员有价值的故事。
- 避免在故事中出现用户界面和技术方面的定义。
- 可估计的（estimatable）
- 对开发人员来说，能估算故事的大小。
- 小的（small）
- 故事太大或太小，都无助于制定计划。
- 可测试的（testable）
- 通常，不可测试的故事发生在一些非功能性的需求上。
- 要争取99%都自动化测试，而不是10%。
要求
- 理想情况，一个用户故事最好是让一两个程序员花啊？半天到两周时间完成代码和测试。
- 避免将需求和解决方案混在一起。典型的为在userstory中出现用户界面的定义。