用户故事的基本理解
用户故事：从用户角度描述用户渴望得到的功能。
一般句式：作为一名<角色>，我可以<活动>，使得<业务价值>。
<角色>说明由谁执行动作，或者谁从相关活动收到价值，甚至可以代表发起相关活动的另一个系统；
<活动>说明在系统中执行的动作；
<业务价值>说明相关活动实现的价值。
用户故事的特点
良好用户故事的INVEST
- Independent（独立性）
可以被单独地开发、测试甚至交付。
有些故事之间会有自然的顺序依赖，但每个部分仍具备单独交付价值。
有些无价值的依赖，我们需要寻找和消除依赖（通常是和其他依赖的故事结合起来取交集，形成一个新的用户故事）。
- Negotiable（可协商）
允许、且需要经过协商。
- Valuable（有价值）
用户故事必须向用户、客户或产品干系人提供一定的价值。
- Estimable（可估算）
可估算的用户故事能够提取任何隐藏的假定和欠缺的验收标准，并且澄清团队对用户故事的共同理解。
- Small（小型）
用户故事应该小到能够在一次迭代中完成。
- Testable（可测试）
可测试的用户故事能够避免造成结构不良、过于复杂或是依赖于其他故事等问题，导致迭代失败。
为了保证无法离开迭代（通过测试）的故事不进入迭代，可以采用“先写测试”的方式。
分割用户故事
分割用户故事
分割用户故事
故事穿刺
故事穿刺是一种特殊类型的故事，用于消除在用户故事或其他项目方面的风险和不确定性。
故事穿刺的基本作用包含：
- 故事穿刺可以用于基本研究，从而使团队熟悉新技术或新领域；
- 如果故事过大难以适当地估算，团队可以利用故事穿刺来分析其隐含行为，从而把故事分割到一些可估算的部分；
- 故事可能包含重大的技术风险，团队必须做一些研究或原型化来获取对技术方案的信心，使他们能够在未来时间盒中做出对用户故事的承诺；
- 故事可能包含重大的功能风险，其中的故事意图可能已经理解，但是系统如何与用户交互以实现蕴含收益却并不明确。
技术穿刺：
技术穿刺被用于研究在解答域的各种技术方式。例如，技术穿刺可以用于做出构建或是购买的决定，计算新用户故事的潜在性能或负载影响，评估对解决方案采取的特定技术或者在时间盒中做出新功能承诺之前，出于某种原因，团队需要加强对理想方式更具信心的理解而使用它。
功能穿刺：
功能穿刺一般用于对用户与系统的交互方式有较大不确定性时。功能穿刺经常是通过一定程度的原型化进行评估，对此可以采取用户交互实体模型、线框、页面流或者是适于从客户或干系人取得反馈的任何其他技术。
指导原则：
- 可估算、可演示而且可验收
- 例外，而非规则
特别说明
- 用户故事不是需求说明书；
- 故事不是详尽的需求说明书（系统应该完成的事），而是可协商的意向表达（系统需要完成诸如此类之事）。
