用户故事的颗粒度
定义：
- 数据：就是一组用户要操作的业务数据，比如一个用户管理系统肯定有“用户、角色、权限”
- 操作：就是对某组或多组数据的业务操作，比如查看所有用户数据，编辑用户，分配权限-角色
- 功能点：操作通常被计算为4个功能点
- 工作量：功能组*35，功能点规模和工作量规模呈现极佳的正比关系，很容易由功能点推算出工作量，进而完成报价、结算或计划活动。
- 用户：可以拆分为一个数据故事“用户”和“增删改查”五个操作故事（查看所有用户查看单个用户详情）
- 每个数据故事对应一个Controller
- 每个操作故事对应一个Action
- 故事有大小之分：大的叫“史诗故事”，小的叫“用户故事”
用户故事的分类
用户故事的模板：作为…，可以….，以便…
以上模板适用于操作故事，如：批量创建用户，查看所有用户
类似下面的需求：
- 如果把“保存”按钮统一放在页面上面而非下面，有些屏幕上的面控件的修改，就无须滚屏即可保存
- 所有xx字段，统一改为4000长度的nvarchar
分类涉及的词汇：史诗级故事、操作故事、重构、增强、缺陷、技术债务
场景一：用户查看产品概要功能，描述：此产品能管理用户、角色、权限
场景二：产品经理回顾产品功能
场景三：内部的迭代计划及情况，
场景四：外部的公告，
场景五：开发人员开发
分类语法
1. 数据故事：意向表WillingList
意向表用于产品经理在召开计划会前，对下一个或几个迭代中的用户故事进行规划、预估，以便形成潜在的“在计划会上待讲解的故事集合”。
2. 操作故事：查看意向表
作为一个产品经理，可以查看意向表，以便了解当前及前后迭代中规划过哪些用户故事。
作为一个系统管理员，可以对用户进行增删改查，以便维护系统的用户。
3. 增强：支持多产品（增强一个数据故事）
**实现后，**将能支持多个产品的讲解，并能查看多个产品的工作量、是否都讲完等信息。
4. 增强：突出显示本次/上次/下次意向表（增强一个操作故事）
实现后，作为一个产品经理可以在查看意向表时，突出地看到本次和上次迭代的意向表，以便连贯地思考本次迭代的需求规划。
5. 重构：重构界面及ViewModel
**实现前，**原来的蹭为树两为为迭代的展示方式较为占用空间，树的高度太大导致难以完整看到；**实现后，**以故事树为主体配合左侧的当前迭代故事，查看和操作更加快捷。
6. 缺陷：在加入故事时产品按钮不刷新
在加入或挪出故事时，顶端的产品按钮上人天数据不刷新，导致产品经理计划时对各产品的问题和比重的错误判断。
7. 债务：产品ID硬编码
当前链接中的产品ID是硬编码的（直接访问火星人），在部署到实际环境中后，将导致链接失效。