Home 敏捷中的以终为始
Post
Cancel

敏捷中的以终为始

DoR 和 DoD 是敏捷中两个最基本也是最有用的概念,是“以终为始”落实的关键。

循环迭代

为了把产品做的更好,我们需要不停地迭代和改进产品。在每个迭代中我们关注两件事:

  1. 什么样的需求才可以开始做(准入条件,DoR)
  2. 做成什么样子需求才算做完(准出条件,DoD)

把没有完成或没有细化的用户需求放到迭代中,会在开发阶段产生各种问题,因为它遵循一个古老的原则:“进去的是垃圾,出来的也是垃圾”。如果开发基于没有充分细化或定义的用户故事来开发,不太可能产出高质量的代码。

一个“准备好”放入迭代的需求应该是清晰的,可行的,可测试的:

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

DoR 是什么

DoR: Definition of Ready

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

DoR 的一些例子

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

DoD 是什么

DoD: Definition of Done

“DoD” 是开发团队在交付用户需求需要达到的最低验收条件,是产品负责人 PO 对开发团队的要求或者共同协商的约定,以保证交付质量。

“DoD”通常会说明:

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

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 必须是团队共同讨论出来的,团队愿意共同遵守的原则,一旦确定,团队就应共同遵守。

DoD 和 DoR 应该上墙

无论是用物理的 Kanban、TaskBoard,还是电子的,建议将定义清晰的 DOD,显式的张贴出来,便于所有人对齐想法。

并且在板子上进行挪动时,无论是挪到 Done 的专题,还是拉到下一个状态,都可以随时看到 DoD 的标准,提醒所有人遵守并检查。保证每个人对一件工作是否完成有一个统一的认识,交付和接纳时时也保持清晰的交接界面。

DoR 和 DoD 另外的用法

DoR 和 DoD 的本意是创建一份简明的文档,用于在项目干系人,PO 和开发团队间达成一致。但是,随着越来越多的工作被外包或分包, DoR 和 DoD 也更多的用于合同协议和 SOW,用以清楚、准确阐述对于需完成工作的期望。

DoR 和 DoD 是很实用的项目范围商议工具,因为它们定义了期望和双方的职责;DoR 帮助客户产出良好的用户故事,为开发团队所用;DoD 帮助交付伙伴根据整体项目需求产出可工作的产品增量,而不仅仅是特定的用户故事功能。

小结

DoR 和 DoD 就像流水线上的两道关,一个管进,一个管出。我们不像牛那么厉害,吃的是草,挤出的是奶。

对团队来说,第一道关更加重要,正如前面所说的,进去的是垃圾,出来的也是垃圾。没有 DoR 的把关,后面的持续改进,工程实践效果都不会太好。

This post is licensed under CC BY 4.0 by the author.

2020年,再见

Jenkins Pipeline 一点通