SCRUM实践之DOD

Posted 2021-04-25 敏捷魔镜

我们先来做一个小游戏
“今天做糖醋排骨，你能帮忙去买点食材吗？”
你会买什么回家呢？
大家的回答会是一模一样的吗？

那工作中，你有没有遇到过类似的情景呢？
比如
现在问问你钉钉里聊天列表的第一个人
“什么情况下，一个迭代就算可以结束了？”
再比如
当接到一个开发任务时
不同的开发小哥哥们对于什么时机可以提测会有什么看法呢 …

你被这些不确定完成标准的任务困扰过吗？
你被上游工序完成不充分导致返工，而你的工作时间被挤压导致加班的情况折磨过吗？

如果没有遇到过，请后台留言分享你的看法~

如果有，那接下来我们就来解决这些问题~

该如何应对这些没有准确答案又随处可见的问题，才能减少返工、准时下班、和团队里的帅哥美女们继续相亲（ai）相爱（sha）地工作呢？
 

很简单！
问问准确答案是什么就好啦！

在敏捷开发中，常用Definition of Done“完成的定义”来表示工作是否已完成，不同的活动有不同的完成定义。

什么是DoD

当产品待办列表项或者增量被描述为“完成”的时候，每个人都必须理解“完成”意味着什么。 虽然这在不同的 Scrum 团队之间会有巨大的差别，但是团队成员必须对完成工作意味着什么有相同的理解，这样才能保证透明性。 这就是 Scrum 团队的“完成”定义，用来评估产品增量是否完成。

看看SCRUM-GUIDE里是怎么说的

When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this may vary significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of“Done” for the Scrum Team and is used to assess when work is complete on the product Increment.

为什么要有DoD

1、明确对完成的预期，确保项目中的内外部的干系人对完成的含义达成理解一致；

2、承诺的可视化，隐藏的、内部的质量投入对外暴露出来，增强团队的透明性；

3、避免快而脏的开发模式，不留技术债务，不遗留问题给后续迭代；

4、作为迭代策划的前提与约束条件，帮助我们合理估算工作量，制定切实可行的计划；

5、聚焦目标，减少不必要的活动，定义完成任务的最小活动集合；

6、在做计划时判断是否有遗漏的活动；

7、在验收时检查是否有遗漏的活动；

DoD的不同类型

迭代DoD

最典型的是迭代DoD，这也是最初DoD应用的地方，常见的一些规则有：

1. 所有代码通过静态检测，严重问题都已修改，静态分析的规则参见……

2. 所有新增代码得到人工评审；

3. 所有完成的用户故事都有对应的测试用例；

4. 测试用例都已执行；

5. 所有完成的用户故事得到Product Owner的验证。

发布DoD

对于发布，一般就有更加严格的要求，发布DoD的典型条款有：

1. 完成发布规划所要求的重点需求；

2. 至少通过一次全量回归测试；

3. 修复所有等级为1、2的缺陷；3、4级缺陷不超过20个。

版本DoD

版本DoD就是针对每个版本上线前后的一些规则，比如：

1. 产品文档已全部更新；

2. 代码已部署到产品服务器上；

3. 运维在验收测试环境上冒烟通过；

4. 原始需求提交人对功能已经验收通过；

5. 对运维、市场、客服的新功能培训已完成。

每日DoD

其他典型的DoD有每日DoD，典型条款有：搭建每日构建环境，晚上自动静态代码检查、编译、部署和测试，每日修复前一日构建和测试发现的缺陷和问题等，例如：

1. 下班前必须检入当天编写的代码，check in的backlog要填写清晰；

2. 当天的代码必须在当天或者第2天邀请同伴进行代码评审；

3. 检入的功能代码必须要有对应的单元测试（严格采用TDD）；

4. 每天晚上触发静态代码检查、自动化回归测试；

5. 当天持续集成、构建环境中的问题，请当天解决。

如何制定DoD

    DoD明确了团队对于“完成”的预期，可以⽤来作为迭代review的检查项，那么如何定义DoD呢？
    1、DoD应该由团队成员协商得出一致结论；
    2、迭代过程中不同的活动应区别对待，设置不同的DoD，参照上一节"DoD的不同类型"；

     3、DoD越弱，欠债越多，后期风险越大。建议对需求流转的各个状态进行DoD设定，会更加严密的保证产品交付质量。

具体制定方式参考

••••

方式一： 召集团队全体成员，讨论各个需求流转状态下的DoD，把最终达成 一致的DoD在团队知识库留存；

方式二： 让各个流转状态的下游角色为上游角色制定准入条件，比如“开发中-->待测试”的流转DoD，可以由测试同学来写。 最后召集团队全体成员，讨论下游角色制定的DoD的合理性，把最终达成一致的DoD在团队知识库留存；

方式三： 参考下面的DoD表，召集团队全体成员，讨论筛选和增加适合自己团队的DoD，把最终达成一致的DoD在团队知识库留存；

DoD注意事项

1、DoD就是完成准则，DoD就是100%完成，⽽不是99%，95%，90%的完成。

2、DoD必须是团队在项⽬启动时共同讨论出来的，团队愿意共同遵守的原则，⼀旦确定，团队就应共同遵守。

3、DoD不是⼀成不变的，在随着时间的推移、经验的积累、成员的变更、项⽬目的变更，我们的DoD也会有很⼤的不同，所以我们也需要定期地检查和改进。

4、DoD越弱，⽋债越多，后期风险越⼤，不同的活动有不同的完成定义，要区别对待。

5、不要把DoD和Accept criteria混淆了，Accept criteria是针对于需求定义的，是我们写在userstory卡⽚背后的验收标准，AC是站在最终用户的角度，定义产品的外部质量，满⾜AC确保了我们做正确的事情；而满⾜DoD确保了我们采⽤正确的⽅法做事，它定义的是产品内部质量，保证产品长久的适应性。

优秀实践展示之学术创新

                             

                             

  

欢迎小伙伴们后台留言，留言内容包含但不限于：
就本文的知识分享内容、形式或质量的看法
期待的知识分享内容和形式
你的团队在团队管理方面的优秀实践
当前困扰
等等...
感恩图报 恩同再造 感激涕零 感恩戴德........