用户故事特征
- 独立的
- 可讨论的
- 对用户或客户有价值的
- 可估计的
- 小的
- 可测试的
用户角色建模
收集用户故事
用户代理
验收测试
优秀用户故事的准则
- 从目标故事开始
- 采用切蛋糕的方式,把大的故事分解
- 编写封闭的故事
- 对必须要遵守而不需要直接实现的故事,使用卡片约束
- 根据实现时间来确定故事规模,越远的故事精确度越低
- 不要过早涉及用户界面
- 有些需求并不是故事
- 在故事里包括用户角色
- 只为一个用户编写
- 以主动语态编写
- 由客户编写
- 向故事卡编号说“不”
- 不要忘记意图
估算用户故事
- 估算扑克
发布计划
- 确定发布日期
- 对用户故事排列优先级,优先级应该受到故事实现的成本的影响
注意:
1. 混合优先级:需要拆分
2. 高风险故事:提倡先做“油水”最多的部分
3. 根据架构需要安排优先级
- 根据历史经验确定能力点,选择迭代长度
迭代计划
- 讨论故事
- 分解任务:将故事拆分为任务可以让故事被多个开发人员并发处理,并且故事是对用户或者客户有价值的功能描述,并不是开发人员的待办事项
注意:
1. 如果故事中某个任务特别难估算,则最好将这个任务从故事的其它任务中分离出来;
2. 如果一个故事的任务可以很容易的分给多个开发人员,则分割他们;
3. 如果有必要让客户了解故事中某一部分的完成情况,则可以把这部分拿出来作为一个任务。
- 分担职责