DoD： Definition of Done
DoD的作用：
明确对完成的预期，确保项目中的内外部的干系人对完成的含义达成理解一致。
承诺的可视化，隐藏的、内部的质量投入对外暴露出来，增强团队的透明性。
避免快而脏的开发模式，不留技术债务，不遗留问题给后续迭代。
作为迭代策划的前提与约束条件，帮助我们合理估算工作量，制定切实可行的计划。
聚焦目标，减少不必要的活动，定义完成任务的最小活动集合 。
在做计划时判断是否有遗漏的活动。
在验收时检查是否有遗漏的活动，比如作为 Sprint Review的检查单的一部分。
借鉴：链接：https://www.jianshu.com/p/1664113cc5a6
DoD的制定过程：
制定场景：我们团队的DoD制定是回顾会议上制定完成。
背景：起因是因为在评审会议上产品经理与开发人员对需求完成与否存在争议，开发人员也不愿意更改代码，做重复的工作。
制定过程：
因为存在上述问题，在迭代回顾会议时我们邀请了团队的产品经理、团队成员，以此问题作为迭代回顾的主题。然后成员进行分组，团队成员和产品经理加起来达到了20人左右，组织成员4人一组，因为会议场地比较小，我们分组的规则是按照位置4人一组，给他们10分种的时间通过自由讨论来确定出现这种情况的原因。然后将原因进行归类，在用15分钟的时间来针对原因给出团队“完成”标准。将制定完成的标准跟团队成员确认，确保他们对完成标准的认可，会议结束后通过邮件方式发送给各位成员。
分析主要的原因如下：
1）需求未澄清明确：需求开发之前开发人员并不完全了解需求，需求是在开发过程中明确，开发人员根据自己的了解进行开发需求。
2）没有完整的“完成”定义：因开发与产品之间存在理解上的差异 ，所以最终交付产品为达到产品想要的效果，而开发人员也不愿意改，互相扯皮。
制定故事的DoR（在需求澄清会议之前）：
1）每个故事描述必须是完成的：按照INVEST拆分，单个故事粒度不超过5个工作日（迭代周期是10个工作日）
2）故事的优先级必须是明确的，不允许重复
3）故事涉及到功能点的原型图是完整的，需要有细节，比如如何交互，文本框字数限制
4）每个故事是具备完成标准的（一般是对应的产品编写），会在需求澄清会议时进行说明
DoD的执行过程:
1) 测试人员的测试用例必须覆盖完成的标准
2）测试人员的测试截图必须是包括完成标准的场景
3）需求评审时按照验收标准来验收需求，如果无法满足完成标准，需求不允许上线
这个流程在实际执行过程进行也在不断的完善，比如由于部分成员非现场办公，这些人的需求提测是通过邮件进行的，一个需求会涉及前后端、原生，提测邮件会比较论乱的问题，我们在后续的回顾会议上进行复盘优化，确定了一个需求只能有一个主邮件，其他人员的邮件在此邮件上进行追加，可以明显提升测试人员的效率。当然我们的流程还在不断的完善当中，个人觉得，完成的定义不应该由质量经理一个人决定（之前的项目遇到过这种情况，一锤定音），应该由团队一起制定，然后通过不断的实践进行复盘，完善，才能形成自己团队的定义。如果只是质量经理一个人决定，虽然能强推，但也只会流于形式，个人始终相信“三个臭皮匠，顶个诸葛亮”。
以上是我们团队的DoD希望能给大家一个参考。如果大家有更好的见解，欢迎共享。
