理想情况下，每个用户故事的 DoD 应该意味着该用户故事的所有测试都通过了，并且所有自动化都已完成，作为整体自动化的一部分运行（而不是在一个人的机器上），并且没有错误地运行。

现实世界通常意味着妥协，因为很少有足够的时间或资源来涵盖任何给定用户故事的所有潜在影响。

国防部要考虑的因素是：

• 时间框架——你有一个“硬”的截止日期还是你能花你需要的时间？（或介于两者之间）。最后期限越难，你的国防部就越会转向钢线。在这种情况下，测试任何不是钢铁威胁的东西都会成为项目的一部分，有时还会成为开发积压的一部分。
• 外部依赖——你的工作越依赖第三方的表现或信息，你需要在 DoD 中留下更多的空间来弥补外部供应商在沟通或表现方面的失败。有时您需要明确声明，如果没有供应商 Y 的项目 X，国防部就无法实现。
• 用户故事的集成不会导致遗留功能的回归（您已经添加了一个新功能集作为 sprint 的一部分，但您没有破坏它过去的工作方式） - 我认为这可能是唯一的项目'没有明确在你的名单上。

房间里的大象：维护。

我们如何维护这个新功能：

• 哪些东西需要可配置？
• 我们可以轻松地推出这个（推出什么？）？
• 我们需要哪些支持工具来快速解决生产中的问题？

我担心有一天全人类都会维护我们祖先的代码……想想孩子们！

有几种有用的启发式方法可以停止测试。我能想到的几个

• '没有更多的时间' - 即我们因业务规定的最后期限而停止。
• 您是否开始了解您打算了解该功能的内容（您确实为测试课程设定了具体目标，对吗？）
• 发现的关键任务错误，此时记录和修复错误变得比测试功能更重要。

Michael Bolton 写了一篇很好的博客文章，比我更有说服力地列出了这些（以及一些额外内容）。

我对完成的定义通常是“为了发布代码，我们不必再次担心（例如触摸、测试、做任何事情）该功能。

我在这方面看到的更好的讨论之一是 Ken Schwaber 去年在一家名为 Pyxis 的加拿大公司的演讲，它在 U 型管上分为三个部分，第一部分在这里