【敏捷】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)

设计评审完成

代码完成

代码重构完成

代码是标准格式

代码已加注释

代码已提交

代码已检查

最终用户文档已更新

完成测试

完成单元测试

完成集成测试

完成回归测试

完成平台测试

零已知缺陷

完成接收测试

已在生产服务器上线