什么是DoD

 文章出处:  http://www.scrumalliance.org/articles/105-what-is-definition-of-done-dod

对于运作良好的Scrum团队来说，DOD是关键之一。 你可以参照以下几点来对照你的团队的DOD。  确保你团队的DOD符合这些标准，将确保你的团队不仅在功能方面，同时在质量方面，都能够交付真正完成的feature。

DOD是对软件有价值的活动的清单

DOD是一个简单的清单，包含了一系列的活动。例如：编码，加注释，单元测试，集成测试，发行声明，设计文档等等。所有这些活动都能够给产品带来实际的价值。使用DOD，可以让团队集中在那些必须完成的事情上，同时让那些无用的，仅仅使软件开发变得复杂的活动被消除掉。

DOD是团队成员的主要状态参考依据

最简单形式的汇报就只有一句话：“这个feature完成了”。毕竟，一个feature或者一个product Backlog Item的状态只有两种：要么成了， 要么就是没有完成。DOD是对“feature完成了”这句话的最佳补充。使用DOD作为参考标准，团队成员可以迅速有效地让其他团队成员或PO了解状态。

DOD是由现实情况决定的

Scrum要求团队在每个sprint结束时交付潜在可应用软件。对于我来说， 潜在可应用软件是一个可交付的feature， 已经可以交给终端用户使用，只是还遗留了一些在PO允许范围内的注意事项.。一项产品如果只需要再多两天的时间就可以交给终端用户使用，那么完全可以认为这个产品处于潜在可应用状态。理想情况下，潜在可应用等同于DOD。

实际情况中，许多团队仍旧只是朝着潜在可应用状态努力，还不能达到。这些团队会在不同的级别上的DOD

• 对应于一个feature的DOD（用户故事或者product backlog 项目）
• 对应于一个sprint的DOD（一个sprint中的feature集合）
• 对应于一个版本（潜在可应用软件）

有很多因素影响到一项活动是否应当成为DOD的一部分。最终，这个决定可以依据对以下问题的回答来做：

1. 这个活动是不是每做一个feature都要做？ 如果不是，那么：
2. 这个活动是不是每个sprint都要做?如果不是，那么：
3. 这个活动对于我们的release来说是必须的

Chris Sterling推荐说对于那些不能成为sprint或者feature的一部分的活动，团队应当“讨论这些项目，是否是团队在每个sprint进行提交的障碍”

通常障碍产生的根本原因有：

• 团队没有能力来将一项活动合并到DOD里面
• 团队没有合适的工具集（比如：： 持续集成测试的环境，自动编译，服务器等等）
• 团队成员实际上在做小的瀑布式开发

DOD不是不变的

DOD随着时间会改变。组织的帮助和团队能力的增加可以移除掉更多障碍，使得更多的活动可以包含到sprint或者feature的DOD中来

DOD是一个可以被审视的列表

feature/用户故事在sprint计划会议和sprint中都可以被拆分成task。DOD可以用来衡量是不是所有的主要工作都被计划在内的（剩余的时间）。而且，在一个feature或者sprint结束的时候，DOD可以用来考查是不是所有的必须的增值活动都已经完成了。

必须引起注意的一条是DOD本身也是存在缺陷的。并不是所有的增值活动都可以应用到每一个feature上面，而DOD本身是一个大而全的检查事项的稽核。团队需要基于一个一个feature来审视每项增值活动是否适用于这个feature。

比如说，追求用户体验对于web服务这样的feature来说可以加分，但是对于其他的一些feature来说就是不必要的了

总结

对于一个feature来说，DOD和用户接收标准（功能接收）是正交的，不相关的。它是一个大而全的集合，涵盖了必须的增值活动，这些活动决定了一个feature的质量，而不是feature的功能。哪些活动应当包含在DOD中，是由团队实际在各个level能完成的情况而定的。