译者体会：
DoD是Scrum里决定交付质量以及沟通效率方面重要的一环。很多团队在持续改进中都会发现DoD逐渐成为了潜在风险点，并且也是提升的难点。DoD就像合同中的条款，强调沟通的敏捷最终要把一致的交付目标落在PBI中，而承诺履行的质量就体现交付物与DoD之间的差距。倘若PO因为自己对产品最终形态不清晰而忽略DoD，那在挑战团队交付效率的时候就会被团队以此来博弈Scrum系统，最终大家会觉得Scrum无效，因为谁都没有做错。从度量的角度看，DoD完全能反映出团队敏捷的成熟度，好的DoD一定是技术工程团队和市场产品团队共同的结晶，也是大家相互学习共同成长的最佳实践场。打磨产品，请从DoD开始吧。
由团队中的一名成员给PO演示代办列表中已经“完成”的一个条目。当PO问开发团队从用户角度功能何时准备就绪时，开发团队会告诉他们已经完成了所有工作，但是非常有必要去做更多的测试，并且将系统迁移到客户机环境中，而这又取决于另一个任务。继续往下讨论，另一名成员说因为这块是系统的重要基本部分，开发团队和PO应该在发布之前对它进行检查。“那么什么时候完工呢?”这位绝望的PO问。“你仅仅去演示它是可以的，但仍有一些事情需要做。”
对于团队的交付物，可能每一个团队成员对“工作完成”都有着不同的理解。
在冲刺评审期间，PO需要了解开发所处的进度，以便根据了解的情况决定在下一个冲刺中进行什么工作。PO需要知道哪些问题需要被关注，并需要相关输入信息来帮助他们完成汇报，以使利益相关者了解情况。规律的产品增量越透明，PO和利益相关者就越容易检视产品，并做出适当的决策。
对于某个人来说，“完成”可能是当工作被记录、审查，并且没有已知的bug时；对于另一个人来说，软件在轻度试探性测试中没有中断就算是“完成”的。这种差异可能会在交付的工作中造成不同程度的质量问题。
团队应该能够在Sprint结束时交付常规的产品增量。如果质量低于利益相关者的期望，团队就不应该把这部分增量视为是可发布的。因此，团队可能需要更多的时间来稳定、调试和测试系统。但如果Sprint结束了，时间就到了，这次迭代就必须结束。
不均衡的工作质量和意外的延迟可能会给团队带来指责，也会在团队内部造成紧张。开发人员要成为一个团队，大家必须在质量方面保持一致，这样才能朝着同一个方向工作。
不仅仅关于外部可见的东西，更确切说是关于那些对于利益相关者来说任何有价值的东西，包括开发团队本身。例如，遵循编码标准的软件源代码将使开发人员在将来使用它时减少挫败感，甚至提高效率。
团队很容易无意识地(甚至有意识地)隐藏这样一个事实：它已经跳过了一致性或质量的约定。这样做会产生技术债务：人们欠系统一些工作，而那些迟早要去偿还。然而，这些工作项在所有的代办列表中都是不存在的。虽然外部产品属性将在Sprint评审中变得可见，但它们仍然是隐藏的。为这些内部项制定一个标准很重要，即使你相信团队能把工作做到最好。
因此:
所有由Scrum团队完成的工作都必须遵循由开发团队和PO所达成一致的验收标准，这些验收标准共同形成了完成的定义。完成意味着开发团队已经验证了关于这些验收标准方面，不再有已知的剩余工作。如果工作不符合已完成的定义，那么根据定义工作就不能被认为完成，团队可能就没有交付相应的产品待办事项列表项(PBI)。
在“完成”的定义中，那些不能为任何利益相关者增加价值的事项都是浪费——记住，开发团队成员也是利益相关者。
一个完美的完成定义要涵盖团队必须完成的所有工作，以便将产品发布到客户手中。Scrum团队根据当前能力开始履行完成的定义，然后随着时间的推移不断强化它。更完整的DoD可以让团队更准确地洞察开发进度，提升开发效率，并确保在持续的开发过程中团队经历更少的意外。
DoD通常会捕获那些对于产品待办事项列表来说太小，和容易反复的工作项。人们往往只是在良好职业行为上有着良好的习惯：在编写一个软件模块之后检入提交所有的版本管理分支; 对于设计变更去更新工程文件; 更新所使用零件的库存记录; 清洁车间或桌面，或测量部件是否符合制造标准。团队可以从将其中一些这类事项放到产品待办事项列表中开始，但是这种方法往往会使待办事项列表中有很多相同任务的实例而变得臃肿。如果这些任务既没有出现在backlog上，也没有出现在Done的定义中，那么产品是否完成就只能听命于开发人员的专注、专业和良好的记忆力了。最好是从当前实际的流程中用已知内部任务去创建DoD，且当团队发现缺少项的时候对其进行扩展。
是回顾和增强“完成”定义的好时机，但是团队可以在任何时候重新审视定义。应该挑战团队，让他们周期性地去强化“完成”；参见（改善脉搏）这有助于团队的成长，因为它提高了自身的标准。
Scrum团队有属于自己的DoD，而这个标准总是在开发团队的能力和控制范围内。ScrumMaster强制执行DoD——通常是在团队将要交付未完成的工作时，把它给大家再看一下。Scrum团队通常根据他们当前的操作方式来创建他们的“完成”的初始定义，并仔细审查哪些是明确有价值的。
一个好理解的、清晰的和强制的DoD在PO和开发团队之间创建了一个共享的理解和共同的协议。这减少了开发团队和PO之间发生冲突的风险。开发团队可以向PO保证，在Sprint结束时交付产出时不需要做额外的工作(例如额外的稳定期)。Scrum团队应该不定期地探索是否应该在DoD中添加一些还没有被列出来的工作。
Done定义中的每个标准都应该是客观的和可测试的。每个家长都知道下面这个故事。一位父亲问孩子：“你打扫你的房间了吗？”孩子回答:“是的”父亲接着问:“玩具收好了吗?衣服挂好了吗?床整理好了吗?地板用吸尘器清扫过了吗?”孩子说:“没”。因此，不是检查活动，而是检查具体的结果状态。一种值得称赞的做法是将DoD列成清单，这也很容易。对照（¶87 Testable Improvements可测试改进）第101页中，更多地应用于流程Kaizen和Kaikaku；Done大部分元素其实是产品的属性。
当开发团队遇到不符合当前DoD的旧工作时，应该移除或减少技术债务。通常，团队只清理紧挨着所修改部分的旧问题（团队只会在做修改的同时顺带清理一些老问题），以将更改的范围限制到合理的大小。从长远来看，DoD有助于消除技术债务。
在更大的组织中，一个跨团队的共享DoD可能会建立一个共同的质量水平。平衡那些一想到共享DoD就从团队自治需要来反对的情况。如果多个开发团队在一个产品上工作，那么他们在Sprint结束时交付单个集成的常规产品增量时，就都共享相同的Done定义。
团队不会为每个PBI创建订制的DoD，而是用一组通用的标准。然而，一组通用标准可能并不总是能够很好地匹配所有工作项。例如，文档、计算和代码的标准可能不同。如果您有大量不同类型的工作项，而单个集合不能充分覆盖这些工作项，那么您可能需要为每种类型的工作项分别定义Done。这很常见。
有了这样一个任务完成的纪律，Scrum团队就可以交付质量可知的定期产品增量。只是通过练习就可以避免团队陷入技术债务的麻烦。作为每个PBI在每个Sprint中的完成结果，没有“高质量的PBI”、“高质量的Sprint”或“强化的Sprint”这类东西。关注已完成的工作可以减少在以后的开发过程中出现令人不快的意外发生的可能性，并且知道了之前的工作确实是完成了，可以使进度预测更加靠谱。有了完成的硬定义，就不需要为客户配置运维团队(DevOps了，这就以一种符合良好精益实践的方式消除了交接。最终完成的工作是为最终用户的消费或应用做好准备。
一个好的DoD可以捕获那些在多个PBI和多个Sprint中的重复出现且的需要的任务。当固化出一个验收标准的公共列表，就不必将这些条目在每个PBI期望的内容或者活动中重复了。
有一个好的DoD，团队将避免技术债务。将DoD添加到PO用于在Sprint评审中批准产品待办事项列表项的标准中。优秀的ScrumMaster向开发团队发出挑战，要求他们坚持商定好的DoD；PO强制遵循面向外部的需求，并在产品待办事项列表项中以实施规范的形式进行交流。PO将允许组织只交付已完成的PBI，并且应该选择只让已完成的PBI进入Sprint评审。有一些灰色区域，例如用户界面指南(想想苹果的人机界面指南)，它们本是面向功能开发外部的需求，但由于开发者最懂怎么使用，因此它们的DoD就自然而然的属于开发团队的管辖范围之内了。
——译者:Adam
校对:Leo
参考资料：
（1）A Scrum Book：82 Definition of Done
