准备就绪的定义 Done of Ready（DoR）

  • 产品负责人和团队需要对“准备就绪”有一致的定义，本质：进入标准
  • 一个Sprint能完成的：PBI做过估算、足够小、很容易在一个冲刺中完成
  • 清楚表达业务价值
  • 有开发团队能够理解的足够多的细节，这样就能针对是否能够完成PBI做出明智的决策
  • 已经识别出依赖关系，不存在阻碍PBI完成的外部依赖关系
  • 为了完成PBI，团队人手配备齐全
  • 验收标准清晰并且是可测试的
  • 如果有性能标准的话，性能标准是己经定义并且可测试的
  • Scrum团队很清楚在冲刺评审中如何演示PBI

DoR举例：

  1. 如果一个故事有外部依赖，那么它们必须已经被解决。
  2. 如果一个故事需要开发一个用户界面，那么原型就已经完全设计好了，并评审通过。
  3. 故事的大小应该小于一个阈值，以便足够理解。

完成的定义 Definition of Done （DoD）

Scrum团队应该提前确定sprint backlog中的工作项何时可以被标记为完成（何谓完成）。这也可以看作是“退出标准”，它由需要作为工作项目的一部分完成的活动清单组成。

  • 产品负责人和团队需要对“完成”有一致的定义，本质是：验收标准、退出标准
  • DoD可以是组织既定的模板、标准、流程
  • 如果常常对怎样定义完成感到困惑，或许应该在每个故事上都添加一个字段，起名为“何谓完成”
  • 团队自协商
  • 团队根据项目的实际情况来定义完成定义，一旦确定，就严格遵守

  • 一个敏捷项目有多少团队时，各个团队都要就本项目的DoD达成共识

    交付对象的DoD

    • 对象1：Story Done
    • 对象2：Feature Done / Epic Done
    • 对象3：Release Done

      DoD列子：

  1. 完成代码审查并合并所有更改
  2. 代码签入到版本控制的右分支中
  3. 代码是完全集成和构建的，没有错误
  4. 代码覆盖测试已经完成
  5. 代码顺利通过回归测试套件
  6. 代码通过了客户制定的验收标准 | 阶段 | 各阶段完成定义 | 备注 | | —- | —- | —- | | Story Done | 代码合入SVN | 由TS和BA明确story 的 DOD 要求，则可以通过移交下游；尽量考虑用户故事对用户的价值。 | |
    | CI通过 |
    | |
    | pclint通过静态检查0警告 |
    | |
    | 完成代码走查 |
    | |
    | FT应该覆盖关键场景，已经合入CI |
    | |
    | Story功能通过每日构建版本的验收标准 |
    | | Epic Done | Epic下面的所有Story都达到Story Done | 由APO、测试Cop负责人明确Epic 的 DOD 要求，则可以移交到下游。 | |
    | Epic下所有领域测试用例通过验收 |
    | |
    | Epic下领域的所有自动化测试的用例，全部实现自动化开发并部署 |
    | |
    | 输出史诗故事测试报告、特征测试方案（包含测试点） |
    | |
    | Epic相关的需求体系化内容更新已经完成 |
    | | Release Done | 特性测试通过 | 版本发布决策会判断 | |
    | 需求测试通过 |
    | |
    | 完成发布测试，输出系统测试报告 |
    | |
    | 通过版本发布决策，软件版本上ECC |
    | |
    | 输出FG文档，并通过评审 |
    | |
    | 输出升级指导、版本发布说明书 |
    |