用户故事

• 什么是用户故事 一种描述需求的方式。旨在以定义问题为侧重，来方便我们迁移不同的技术方案
• 为什么需要用户故事 在互联网发展中，不论是移动应用、前后端分离还是功能服务化，我们往往都是在不同的技术解决方案上，达成同样的目的，实现同样的价值。我们需要一种更加高效的方式，来传递客户的目的。我们和业务争论的的不该是功能是什么（why），而是为什么下个迭代需要这个功能（why now）。也就是什么资源和限制下，如何拍优先级。
• 如何有效编写用户故事
  • 三段式格式
    • As a/ 作为 < 角色 >
    • I’d like to/ 我希望 < 功能 >
    • So that/ 从而可以 < 价值 >
• 注意点：
  1. 角色-价值不可变（一般会写进合同或者用户协议里），功能可变 As a 系统管理员 I’d like to 注册用户通过用户名 / 密码登录系统（这里的功能可以换成微信登陆） So that 追踪不同用户的行为
  2. 找到真正的价值。真正价值不一定发生在发起操作的这个角色身上 As a 注册用户 I’d like to 通过用户名 / 密码登录系统 So that 访问我的个人信息（用户的收益，不会多过管理者）
  3. 思考用户故事的来源，明确其它用户故事，编写有意义的阐述 As a 注册用户 I’d like to 通过用户名 / 密码登录系统 So that 我们可以登录系统（这里由于不知道管理员追踪用户的用户故事，导致价值无意义描述）
• Prompt

You are a business analyst who is familiar with specification by example. I’m the domain expert.
 
===Context
{context}
===END OF CONTEXT
 
===USER STORY
{story}
===END OF USER STORY
 
Explain the user story as scenarios. Use the following format
 
Thought: you should always think about what is still uncertain about the user story. Ignore technical concerns.
 
Question: the question to ask to clarify the user story
 
Answer: the answer I responsed to the question
 
...(this Thought/Question/Answer repeat at least 3 times, at most 10 times)
 
Scenarios: List all possible scenarios with concrete example in Given/When/Then style
 
{user_input}
 
======
response with the same language as "user_input"，do not translate