在我上一篇关于“专业软件团队创建工作软件”的文章中，David Corbin提出了一个很好的观点。您如何确定“无故障或缺陷”的含义？由于其因产品而不同，且可能随时间变化，因此您需要关注质量，并体现在完工标准（Definition of Done，DoD）定义中。
太长不看版本：
开发人员最终负责创建可工作软件的已完成增量，已完成的增量，已完成的。
开发人员需要决定在组织环境和产品领域中“已完成”意味着什么。他们需要坐下来创建一个清单，清单上的每一项对于要交付的每个产品增量来说都是真实必须的。工作软件不特定于某个产品待办事项而是适用于整个交付。不仅仅是用于每个单独的产品待办事项。
完工标准（DoD）通过使所有人对于作为产品增量的一部分，什么样的工作算是已完成的工作有一个共同的理解来创建透明度。如果一个产品待办事项不符合“已完成”定义，则不能被发布，甚至不能在冲刺评审中进行展示。相反，它将重返产品待办列表以作后续斟酌。”
—— 2020版Scrum指南
如果你不能至少每30天发布一次工作的软件，那么根据定义你还没有在实施Scrum。因为“专业的Scrum团队构建的软件是可工作的”，所以请停下来，先创建一个符合你的“完工标准”的可工作软件增量，然后开始冲刺，并持续审查你赋予“可工作”的含义，最后至少有一个较为规律的交付节奏。
什么是完工标准（DoD）？
你需要从某个地方开始，通常我们没有从零开始的产品。要么我们交接了一个现有的产品，要么我们是创建产品的团队，正在转型到Scrum。无论您的产品起源于何处，代码以及产品当前都不会是可工作软件。如果你对什么是“可工作的”没有确切的定义，它如何能成为可工作的软件？但是你怎么可能对可工作的含义没有一个定义？那么你是怎么做的呢？
在砍掉一行代码之前，你需要决定“已完成”对你的产品和公司意味着什么。如果你正在为起搏器构建固件，或者是创建电子商务门户，则完工标准的定义将非常不同。以下是完工标准的一些特征：
一份简短、可衡量的检查表 —— 尝试在DoD中设置可测量的内容，以便测试结果，最好是以自动化的方式。 可发布的镜像—— 在你的产品可能还没有发布的时候，虽然我们推荐这样，你应该可以有这样的选择。你的产品负责人应该能够在冲刺评审中说：“太棒了……让我们来发布吧。” - 无需进一步的工作 —— 开发人员无需其它工作即可将产品交付生产。任何额外的工作都意味着没有完成，这会占用下一个迭代的开发容量。理想情况下，你有一个完全自动化的软件交付流程，并且永远不要跨迭代进行交付。
你需要定义一个简短的、可测量的检查表，它反映了产品的可用性，并且发布产品不需要额外的工作。我发现做到这一点最好的方法是让Scrum团队（产品负责人加上开发人员和任何干系人）参加一个有人引导的DoD定义研讨会。没有DoD我们就不会理解可工作软件意味着什么，而如果没有可工作的软件，我们就无法获得可预测的交付。你的产品负责人不能拒绝待办事项，只能判断产品增量是否可工作。
我的第一个完工标准（DoD）
以下是一些可以纳入DoD定义的例子：
- 增量通过SonarCube检查，无严重错误 —— 你可以随着时间的推移逐渐提升标准，因此你可能需要说“代码通过Sonar Cube检查且不超过50个严重错误”，然后随着时间推移而努力。
- 增量的代码覆盖率保持不变或更高 —— 查看一个特定的衡量标准，比如90%的代码覆盖是一个熟悉的说法，但不会告诉你任何关于代码质量的信息。然而，监控和测量代码覆盖率的不利变化可能是有好处的，我们始终倡导TDD实践。
- 增量符合一致认可的工程标准 —— 你应决定方法、测试、变量以及其间所有事项的命名规则，从小处着手，随着时间推移而增加。在Wiki链接更新您商定的标准，并不断改进和扩展您的规则。尽可能自动化。
- 增量通过产品验收标准 —— 确保至少满足规定的标准是一个值得称赞的目标，基于ATDD实践将其自动化则更好。
- 增量验收测试是自动化的 —— 确保所有测试都自动化。如果你认为有些东西会有问题，那么你应该对它进行测试。
- 增量通过安全检查 —— 使用自动化工具作为构建的一部分，并检查已知的安全漏洞。你不会发现所有的安全问题，但至少不要做我们知道的那些安全性匮乏的事情。
- 增量符合一致认同的用户体验标准 —— 同样，要有一个Wiki页面并确保你复核过。如果您没有使用自动的完工标准门闸，那么就需要团队来同意是否符合标准。
增量符合一致认同的架构指南 —— Wiki非常棒，但尽可能把它自动化。
无论你想出的完工标准如何定义，都不太可能整个产品目前就已经符合标准。你还没有实施Scrum，在开始冲刺之前，需要集中精力确保当前增量满足新定义的完工标准。专注于质量是开发人员的责任，在开始之前确保你的目标增量满足新的质量标准，达到所有定义的质量标准则是下一个增量“完成”的前提。
创建一个符合完工标准定义的可用增量，然后开始冲刺。保持你的软件处于工作状态将需要一个现代化的源代码控制系统，该系统为你提供良好实现DevOps实践的工具。
发展你的完工标准（DoD）
始终改善质量是非常重要的，这意味着你至少需要定期对完工标准进行思考和改进。在Scrum中，这种节奏是由冲刺的长度决定的，在冲刺回顾会中有一个改善时刻。这并不意味着你不需要一直考虑完工标准，恰恰相反。你不断地思考你的增量目前是否符合完工标准的要求，以及你需要做什么才能实现。你应该一直思考你的完工标准是否符合你的需要。如果开发人员在冲刺过程中发现完工标准缺少一些东西，那么他们应该继续添加以确保不会危及冲刺目标。
正如David Corbin在我之前的文章中指出的那样，你可能会发现产品存在性能问题。我们如何确保解决这个问题？在我看来，遇到这个情况你有两个方面可以考虑。你可以Scrumble（因为质量差而停止冲刺）并修复它，或者你可以将这些新知识整合到你的产品周期中。
如果这是一个导致你无法得到可用软件的重大问题，那么则需要中止并修复它。在Scrum中，这被称为Scrumble，这反映了开发人员由于缺少某些东西而陷入困境。在继续冲刺之前，应该停止添加新功能，并在继续冲刺和添加新功能之前创建一个可用的增量。一旦问题被修复，你就可以完善完工标准的定义，以确保将来的所有增量都满足新的要求。
如果问题不太严重，你可能希望继续工作，并将需要的内容添加到产品待办事项列表中。然后，你可以在接下来的几个冲刺中提交改进，以缓解并解决识别出的问题。一旦解决了这个问题，你就可以通过向完工标准中增加相应的内容来巩固效果。
我们应该始终寻找提高质量的方法。今天你对“完工标准”的定义是什么样的？欢迎在评论区留言。
【作者】Martin Hinshelwood
Martin Hinshelwood是一位专业Scrum培训师，专业看板培训师，以及微软开发技术MVP。他2000年开始从事软件交付工作，并于2010年开始从事DevOps和敏捷方面的咨询、辅导和培训工作。自2008年以来，Martin帮助了许多机构，并在全球37个国家培训了1000多名人员。
原文地址：https://www.scrum.org/resources/blog/getting-started-definition-done-dod
