【敏捷】1.0 待办事项列表

PO和团队讨论用户故事，细分并提供细节信息和验收标准等；

PO对用户故事排优先级；

团队估算出用户故事的规模（故事点数）

故事地图：

根据用户故事的商业价值和用户通常对它们的执行顺序来进行排序，以便团队能够对将要构建的内容有共同的理解

MVP最小可行性产品

MMF最少可售特性

估算技术（不同团队故事点基数及总量不同）

相对估算

估算扑克
- 是一种协作式的的相对估算技术。
- 采用修正的斐波那契数列：0,1,2,3,5,8,13,20,40,100
- 不同的团队故事点
亲和估算
- 将产品待办事项规模相近的放在一起，组成一组
宽度德尔菲
- 德尔菲法的变型，包含更多的沟通和人际协作
举手表决

优先级排序技术

模型法：
- MoSCow（重点）
  - Must Have 基本的：解决方案的必要基础
  - Should Have 重要的：增加重要价值
  - Could Have 可以有：可以较容易实现的
  - Won't Have 不会有：这次不会有
单指标法：
- 价值（多票制/购买特性）
  - 多票制：向每人提供规定数量的彩色点，然后他们将彩色点放在其认为最重要的需求上，然后汇总每个功能的所有选票
  - 购买功能：一定数量的模拟货币，来购买所选择的功能，计算每个特性所获得的总金额，以此来排序
- 时间盒
  - 通过设置严格的时间限制，并且对团队在这段时间内可完成的工作进行排序
  - 往往和其它参数一起使用
多指标法：
- 优先矩阵：
  - 价值-时间矩阵
  - 价值-风险矩阵（价值高风险大-先做，价值小风险大-避免）
  - 价值-成本矩阵
- 加权最短优先左右WSJF
  - WSJF = （商业价值+时间临界+风险减少或机会启用） / 工作量
  - 常用修正的斐波那契数列：0,1,2,3,5,8,13,20,40,100
  - 有时也简化为 “价值/成本”

准备就绪定义 DoR

用户故事被认为是充分理解并能开始构建，整个团队一致同意所需完成的一系列条件或质量验收标准

就绪的定义（DoR)

清楚表达业务价值

有开发团队能够理解的足够多的细节，这样就能针对是否能够完成 PBI 做出明智的决策

已经识别出依赖关系，不存在阻碍 PBI 完成的外部依赖关系

为了完成 PBI ，团队人手配备齐全

PBI 做过估算、足够小、很容易在一个迭代中完成

接受标准清晰且是可以测试的（或者 INVEST 原则)

如果有性能标准的话，性能标准是已经定义并且可测试的

团队清楚在迭代评审中如何演示PBI

完成定义 DoD

DoD 是在待办项被认为已充分开发以被商业干系人接收之前/开发之前，整个团队一致同意完成的一系列条件/验收标准

DoD 可在许多细节层面上创建，通常在用户故事级别、迭代级别、发布级别和产品级别上定义

完成的定义（DoD)

设计评审完成

代码完成

代码重构完成

代码是标准格式

代码已加注释

代码已提交

代码已检查

最终用户文档已更新

完成测试

完成单元测试

完成集成测试

完成回归测试

完成平台测试

零已知缺陷

完成接收测试

已在生产服务器上线