什么是用户故事，用户故事的要素及需求分析？
需求敏捷性
看板和Scrum的敏捷开发方法论解决不了需求敏捷；但是“用户故事”可以很好的解决。
用户故事是一种轻量级和敏捷的分析方法。
- 简述用户有价值的功能点。
- 用户故事不能用技术语言来描述，而是用用户可以理解的商业语言来描述
一个好的用户故事包括三个要素:
- 谁的角色
- 活动什么
- 商业价值为什么
5C用户故事的特征
“卡牌”用户故事通常写在故事贴/卡片上；也许写一个简短的故事描述/工作量估计，等等。
[/S2 「对话」"/s2/]用户故事的细节来自于与客户或产品负责人的交流。
[/S2〖确认〗通过验收测试用例，确认“用户故事”的验收。
“构建”团队通过技术手段实现这个用户故事的功能或需求。
[/S2 【后果】"/s2/]交付给用户实际使用并获得反馈。
用户故事的优势
- “用户故事”强调面对面的直接交流，而不是文档交流；因为文档难以应对用户需求的频繁变化；最后，没有人阅读那些文件。
- “用户故事”便于开发者和客户/用户一起理解(不用技术术语，而是用用户的语言来简单描述需求)。
- 用户故事可以划分为粒度相对较小的用户故事，非常适合迭代开发。
- 用户故事鼓励推迟对细节的考虑；可以快速编写独立的用户故事，非常适合时间有限的项目。
使用故事点进行工作负载评估。
在Sprint策划会中，有一个非常重要的技术环节“故事点的预估”:对要开发的用户故事做一个大概的预估，对用户故事的复杂程度有一个具体的了解。
- 传统软件团队在使用人工时通常会估算工作量:工时是一种绝对的估算方法；其估算方法通常依赖于历史经验信息；对于具有固定流程和稳定需求的团队，工时估算方法是适用的，但工时估算难以应对客户需求的频繁变化。
- 敏捷估算方法是一个相对估算的概念，没有绝对的估算日和小时；故事点是敏捷开发过程中常用的相对估值方法:根据不同的需求，你可以估算一个需求比另一个需求大多少倍；但不确定每个需求的确切工作量；一旦对某个故事点的相对规模达成共识，就可以快速分配，不需要对故事点进行过多的争论，让团队根据难度而不是时间来解决问题，这使得团队成员更加注重创造价值；而不是关注花了多少时间。
- 故事点估算软件scale 可以使用近似的斐波那契数列:“0，12，2，3，5，8，13”或者t恤尺寸:“XS，S，M，L”，帮助团队围绕工作规模做出更好的决策。
【温馨提示:在实际工作中，对工作时间或故事点尺度没有好坏的估计；只适合；总而言之，好的评估实践1: # xfe0f帮助团队掌握项目的成本和盈利能力2 ' E3； # xfe0f它还有助于团队就需求的规模、优先级和价值达成共识；以便做出更好的商业决策。"
用户情景分析的典型步骤
- 使用者:不仅是人的位置和角色，还有外围系统。
- 业务流程:用户与所实现的系统之间的交互过程；但不包括系统中组件之间的交互过程(系统与数据库之间的交互等。，在用户故事中无法感知；在实现用户故事的时候，如果系统之间有交互，也要想好自己想要什么样的旅程“用户故事地图”:点击跳转到新的，或者直接打开页面。而且作为一个产品，有时候有监控数据的需求，就要知道哪些信息是存储的，怎么存储的，或者存储不存储)
- 提取用户故事:根据用户故事的感知层次，从交互步骤中提取用户故事。
- 梳理用户故事:如果用户故事太大，需要进一步细分；如果用户故事太小，可以与其他用户故事合并。
用户故事的典型步骤
用户故事地图
优秀用户故事的六大特征(投资原则)
- “独立的独立性”一个用户故事尽可能独立于另一个用户故事；用户之间的依赖性使得难以确定计划、优先级和工作量估计。通常，通过合并或分解用户故事来降低用户故事的依赖性
- [/S2〖可议可议”一个用户故事的内容，如果可以议的话；一个用户的故事不是契约，而是需求的简短描述；不要包括太多的细节；具体细节在沟通阶段产生，如果一个用户故事有太多细节；其实是限制了和用户的交流。
- [/S2 「有价值的有价值的”每一个用户故事对客户来说都必须是有价值的；让用户故事有价值的一个好方法是让客户写下来；让用户意识到这是用户故事，不是合同；而且他们很乐意在可以协商的时候写用户故事。
- [/S2〖可评估的〗开发团队需要进行评估，以确定优先级、工作量和计划。
- “小短”一个好的用户故事应该越短越好，最好不要超过10人-天的工作量；至少保证一个冲刺就能完成；因为用户故事越大，安排计划工作量的风险就越大。
- [/S2 「可测试的可测试性”一个用户故事应该是可测试的，以便确认它可以被完成；如果不能测试，就不可能知道什么时候能完成[温馨提示:用户故事也是测试/验收驱动开发的实践]
