用户故事
大约 4 分钟
用户故事
定义
描述了对用户，系统或者软件购买者有价值的功能，是敏捷开发方法中用来定义系统需要提供的功能和作为需求管理条目化的基础。总体思想就是将需求细化之后像一段故事讲出来，这和代码整洁之道说的理念有异曲同工之妙。
结构：
- 是一份书面的故事描述卡片用来做计划和作为提示
- 有关故事的交流，用户具体化故事细节
- 测试，用户记录和确认故事细节且可用于确定故事何时完成
具体使用
作为X [用户角色] 我希望Y [系统提供什么功能] 以便Z [达到什么目的或者实现什么价值]
或者是
为了X[达到什么目的或者实现什么价值] 作为Y[什么角色] 我希望Z[系统提供什么功能]
总结起来就是Who,What,why
角色的创建
首先针对一个模糊的问题进行头脑风暴，在这里不需要思考细节，只需要思考在这个问题中参与的角色有谁，直接创造，当想的差不多时，整合这些角色的集合，把这些创造角色归纳起来，自顶向下，由粗到细，划分角色的权责边界，之后提炼角色，将其的特征凸显出来。特征提炼完之后，用户模型就创建好了。
故事
收集故事是为了确定需求，收集故事有一下几种方法
- 用户访谈
- 问卷调查
- 观察
- 故事编写 以用户访谈为基础，产生一个固定的判定基准，利用问卷调查扩散判别案例，然后再根据观察和故事编写补充细节。 一个单元用故事要符合INVEST原则
- Independent(独立的)
- Negotiable(可讨论的)
- Valuable(有价值的)
- Estimable(可估计的)
- Small(足够小)
- Testable(可测试的)
层级关系
用户故事有以下层级:
- 史诗
- 特性
- 故事
- 任务 整体成一个树结构，各个节点不存在与其他同级节点相互连接的情况。各节点优先级首先根据实际业务所确定。其次考虑实现成本，然后是实现风险，最后是实现过程中是否需要新的知识做支撑(学习成本)。具体操作可参考渴望度Kano模型
特点
用户故事强调口头沟通而不是文档沟通，所以相较其他方式要便于理解一点，而且大小适中，特别适用于迭代开发，在使用过程中鼓励延迟细节，以便于将细节集中一起去讨论，提升细节准确率，并且适应需求的变化。
存在的问题
用户故事在使用中可能存在的问题
- 故事太小
- 故事之间相互依赖
- 不愿或很难排优先级
- 细节太多
- 过早考虑具体细节
- 过于长远
故事的具体估算
故事本身的实现过程前是需要估算实现的时间和成本，有以下估算方法可供参考
- 相对估算 根据单独或者几个确定时间的故事来映射整个需求所要花费的时间。因为其故事足够小，所以映射的时间与实际花费的时间差距不大
- 讨论表决 将成员集中一起，讨论需要实现的时间，每个成员给予一个时间点数，在表决阶段展示时间点数，根据时间点数算出均值，若时间点数差距过大，则询问最大值和最小值的看法、讨论，然后继续表决。
- 询问专家意见
- 分解故事本身 当故事太大或者迭代时间不够时，可对故事本身分解成更小的一部分。分解操作可根据数据边界和操作进行分解。
- 类比
速度估算
开发速度的估算可参考一下几点：
- 使用历史工作时间
- 预测 首先估算出个人可用小时数，其次估算迭代可用时间，最后选择故事填充时长
- DoR和DoD
整体使用流程
首先项目开始后进行创建角色工作，接着编写出第一个用户故事，编写完之后进行整理，并确定优先级，然后对整个用户故事进行评估，针对过大的故事进行拆分，之后估算开发速度，最后确定迭代计划。