DoD 与 DoR

DoD: Definition of Done / DoR: Definition of Ready

一个迭代是固定时间的循环,依次把迭代 backlog 上高优先级的任务变成产品增量。但是,要把事项顺利拉到当前的迭代中,如何定义用户故事“已经准备好”是很重要的——把没有完成或没有细化的用户故事放到迭代中,会在开发阶段产生问题,因为它遵循一个古老的原则:“进去的是垃圾,出来的也是垃圾”。如果开发基于没有充分细化或定义的用户故事来开发,他们不太可能产出高质量的代码。

一个“准备好”的 backlog 事项应该是清晰的,可行的,可测试的:

  • “清晰的”意味着所有的 Scrum 团队成员对该条目达成了共识。通过协同编写用户故事,对高优先级事项添加验收标准,有利于需求的澄清。
  • “可测试的”意味着能通过有效的办法决定该条目是否符合期望。验收标准可确保每个故事都能被测试。
  • “可行的”意味着根据 DoD,该条目能够在一个迭代中完成。否则,条目需要进一步的分解。

简单的讲,DoR 定义了一些标准,用户故事在开始估算或者进入迭代前,必须先符合这些标准。

“DoR”关注用户故事级别的特性,“DoD”的关注点则在迭代或者发布层面。本质上,“DoD”代表着迭代或者发布的验收标准。它清楚的列出了为完成产品增量,开发团队必须要达到的要求。

DoR 是什么

DoR 是一个待办(backlog)是否能够被团队接受,认为可以作为开发候选所需要达到的最小要求,是团队针对 PO 的要求。

一个 DoR 的例子:

  • Clear,用户故事描述清晰;
  • Feasible,用户故事可以放入一个迭代;
  • Testable,验收条件得到定义 。

需要注意的是,DoR 只需要针对产品待办列表 PBL 中高优先级的需求进行,通常是准备能够满足两个迭代的即可。PBL 越是近期会做的,需求越清晰,越是符合 INVEST 原则;越是暂时不会做的,越不需要花太多精力去澄清和拆解。

而 DoD 则相反,是 PO 针对团队的产出进行验收的最低验收标准,文中已经给出了样例。

最初 DoD 只有一级,即研发迭代完成,用户故事可以被视为完成的标准。逐渐出现了多级的 DoD,针对每一个研发阶段,出现了这一阶段的 DoD 标准,例如从 Henrik Kniberg 的 Kanban kick-start example 图中,分析阶段的 DoD、开发阶段的 DoD、验收测试阶段的 DoD 等;典型的 Kanban 是拉动的过程,后一阶段拉取上一阶段完成(Done)的工作时,会检查相应的 DoD 是否完成,因此上一阶段的 DoD 事实上就是下一阶段的 DoR。

越往前的 DoD 越偏业务,然后是偏技术实现,越往后的越要加入运维和非功能性要求。

DoR 的一些例子

  • 用户故事是清晰的
  • 用户故事是可测试的
  • 用户故事是可行的
  • 用户故事已定义
  • 用户故事验收标准已定义
  • 用户故事依赖已明确
  • 用户故事已由开发团队做过粒度划分
  • Scrum 团队已接受 UI 原型设计
  • 指定场景下的性能指标已明确
  • 指定场景下的可扩展性指标已明确
  • 指定场景下的安全指标已明确
  • 验收用户故事的人已明确
  • 团队都清楚用户故事所表达的意思

DoD 是什么

“DoD”是开发团队和 PO 对每个用户故事需要做什么的协定 – 通常在公司层面统一标准,以保证交付质量一致。 “DoD”通常会说明:

  • 用户故事所处的系统环境(哪个版本的 Linux、Android、iOS 或者浏览器)?
  • 需要输出什么样的文档(自动生成的 Javadoc,还是完整的终端用户手册)?
  • 有什么质量要求(用于演示的基本功能,还是一个功能完整,健壮的 APP)?
  • 有什么安全要求(无安全要求,还是从代码评审、代码扫描到网络安全配等各方面都要求做安全审查)?
  • 有什么扩展性要求(10 个并发,还是 10 万个并发)?

本质上说,“DoD”是基于验收标准的协议,PO 在迭代结束时同它来验收产品增量。 请注意,针对迭代和发布阶段,DoD 标准可能会不一样。中间迭代的 DoD,比起临近发布的几个迭代,要求不会那么严格。

DoD 的一些例子

  • 代码已完成(所有代办事项已经完成编码)
  • 代码已注释、已提交。版本库当前版本能正常运行
  • 结对检视已完成(或者采用结对编程),代码符合开发标准
  • 构建没有错误
  • 单元测试全部通过
  • 部署到测试环境并通过系统测试
  • 通过 UAT(用户验收测试)并签字确认符合需求。
  • 任何编译/部署/配置变化都已实现/记录/沟通。
  • 相关文档/图表已完成或已更新
  • 任务剩余的小时数已设置为 0,任务已关闭

DoD,通常需要从几个维度考虑

为 Sprint 中任务给出明确的“Done”定义是非常重要的,但即使你遵循这个最佳实践,最终仍然会有集成问题,会存在 Bug,以及晚期的需求变更。所以,对于大型复杂产品,在正式发布前,单独计划 1 ~ 2 个 Sprint,专门做 Bug 修复,也是合理的。

关于 DoD 的例子,通常需要从几个维度考虑。

1)需求/用户故事 DoD

  • 用户故事的描述及拆解符合 INVEST;
  • 用户故事有验收标准 AC(Acceptance Criteria)。

2)开发任务 DoD

  • 代码已经提交到 Git;
  • 代码通过单元测试;
  • 代码经过 Code Review;
  • 代码通过集成测试。

3)迭代 DoD

  • 所有代码通过静态检测,严重问题都已修改;
  • 所有新增代码都经过 Code Review;
  • 所有完成的用户故事都通过测试;
  • 所有完成的用户故事得到 Product Owner 的验证。

4)发布 DoD

  • 完成发布规划所要求的必须具备的需求;
  • 至少完成一次全量回归测试;
  • 符合质量标准(Quality Gate),譬如所有等级为 1、2 的缺陷均已修复;3、4 级缺陷不超过 10 个;
  • 有 Release Notes;
  • 有用户手册;
  • 产品相关文档已全部更新;
  • 代码已部署到发布服务器上,并冒烟通过;
  • 原始需求提交人完成 UAT;
  • 对运维、市场、客服的新功能培训已完成。

Tips:DoD 及 WA 必须是团队共同讨论出来的,团队愿意共同遵守的原则,一旦确定,团队就应共同遵守。

DoD 和 DoR 应该上墙

无论是用物理的 Kanban、TaskBoard,还是电子的,建议将定义清晰的 DOD,显式的张贴出来。下图就是很好的例子,便于所有人对齐想法,并且在板子上进行挪动时,无论是挪到 Done 的专题,还是拉到下一个状态,都可以随时看到 DoD 的标准,提醒所有人遵守并检查。保证每个人对一件工作是否完成有一个统一的认识,交付和接纳时时也保持清晰的交接界面。

DoR 和 DoD 另外的用法

DoR 和 DoD 的本意是创建一份简明的文档,用于在项目干系人,PO 和开发团队间达成一致。但是,随着越来越多的工作被外包或分包, DoR 和 DoD 也更多的用于合同协议和 SOW,用以清楚、准确阐述对于需完成工作的期望。 DoR 和 DoD 是很实用的项目范围商议工具,因为它们定义了期望和双方的职责;DoR 帮助客户产出良好的用户故事,为开发团队所用;DoD 帮助交付伙伴根据整体项目需求产出可工作的产品增量,而不仅仅是特定的用户故事功能。

小结

DoR 和 DoD 就像流水线上的两道关,一个管进,一个管出。我们不像牛那么厉害,吃的是草,挤出的是奶。对团队来说,第一道关更加重要,正如作者说的,进去的是垃圾,出来的也是垃圾。没有 DoR 的把关,后面的持续改进,工程实践效果都不会太好。

Comments