考虑到可行的完成定义对于 Scrum 团队成功的重要性，我一直困惑的是，许多 Scrum 团队对于他们的完成定义是多么自满或无知。因此，让我与您分享这一关键 Scrum 成功因素的十大首要原则，以提高团队的效率、团队精神和声誉。
根据 Scrum 指南定义完成的目的
Scrum 指南将完成的定义描述如下：
“完成的定义是当增量满足产品所需的质量度量时对增量状态的正式描述。”
“当产品待办事项符合完成的定义时，增量就诞生了。”
“完成的定义通过让每个人都对作为增量的一部分完成的工作有共同的理解来创造透明度。如果产品待办列表项不符合完成的定义，则无法发布，甚至无法在 Sprint 评审中展示。相反，它会返回到 Product Backlog 以供将来考虑。”
“如果增量的完成定义是组织标准的一部分，那么所有 Scrum 团队都必须至少遵循它。如果它不是组织标准，Scrum 团队必须创建适合产品的完成定义。”
“开发人员必须遵守完成的定义。如果有多个 Scrum 团队在一个产品上一起工作，他们必须相互定义并遵守相同的完成定义。”
来源：Scrum 指南 2020。
Scrum 指南经常提到完成的定义，以强调广为人知和接受的质量标准对于成功的 Scrum 团队和组织的重要性。没有卓越的技术和高质量的产品，就没有业务敏捷性——这两者都得到了“完成的定义”的反映和支持。
对于以下 Scrum Guide 的引用，请注意各节开头的数字是指官方 Scrum Guide 的官方英文 PDF 中的页面：
第 5 页：但是，开发人员始终负责通过遵守完成的定义来灌输质量。
第 6 页：Scrum Master 以多种方式为 Scrum 团队服务，包括帮助 Scrum 团队专注于创建满足完成定义的高价值增量。
第 7 页：在 Sprint 期间，质量没有下降。
第 8 页：[Sprint 计划：这个 Sprint 可以做什么？] 选择在一个 Sprint 中可以完成多少可能具有挑战性。然而，开发人员对他们过去的表现、即将到来的容量和完成的定义了解得越多，他们对 Sprint 预测的信心就越大。
第 8 页：[Sprint 计划：选定的工作将如何完成？] 对于每个选定的 Product Backlog 项目，开发人员计划创建满足完成定义的增量所需的工作。
第 10 页：Scrum 团队检查上一个 Sprint 在个人、交互、流程、工具及其完成定义方面的进展情况。
第 10 页：[工件承诺：] 对于增量，它是完成的定义。
第 10 页：Scrum 团队可以在一个 Sprint 内完成的产品待办事项列表项目被视为已准备好在 Sprint 计划活动中进行选择。
第 12 页：工作不能被视为增量的一部分，除非它符合完成的定义。
第 12 页：完成的定义是对增量状态的正式描述，当它满足产品所需的质量测量时。
第 12 页：当产品待办列表项满足完成的定义时，增量就诞生了。
第 12 页：完成的定义通过让每个人都对作为增量的一部分完成的工作有一个共同的理解来创造透明度。
第 12 页：如果产品待办列表项不符合完成的定义，则无法发布，甚至无法在 Sprint 评审中展示。
第 12 页：相反，[未完成的 Product Backlog 项目] 返回到 Product Backlog 以供将来考虑。
第 12 页：如果增量的 Done 定义是组织标准的一部分，则所有 Scrum 团队都必须至少遵循它。
第 12 页：如果它不是组织标准，Scrum 团队必须为产品适当地创建完成的定义。
第 12 页：开发人员必须遵守完成的定义。
第 12 页：如果有多个 Scrum 团队在一个产品上一起工作，他们必须相互定义并遵守相同的完成定义。
来源：此引用汇总来自Scrum Guide 2020 - Reordered。
完成成功原则的定义
我对完成成功原则的十大定义（排名不分先后）如下：
完成有一个定义：这应该是显而易见的：如果没有定义什么构成可交付性的质量标准，您的 Scrum 团队将面临其技术基础缓慢而稳定的下降，不可避免地积累技术债务。如果您的组织的战略目标是成为敏捷组织并拥抱业务敏捷性，那么您已经在这个阶段迷失了方向。业务敏捷性需要卓越的技术，而完成的定义对于达到并保持这一水平至关重要。
完成意味着可交付：完成定义所定义的“完成”状态意味着我们可以向客户交付增量，而不会产生法律、财务或道德影响。一旦产品待办列表项符合完成的定义，它不需要任何其他形式的批准，不需要产品负责人，当然也不需要任何“质量门”来发布增量。
使（组织）完成的定义适应 Scrum 团队的需求：每当组织提供标准的完成定义时，将其视为质量的最小公分母。但是，然后根据您的客户或 Scrum 团队的需求调整此完成定义。
透明度：完成的定义只有在组织中的每个人都可以访问并理解它的情况下才能发挥其作为通用质量标准的潜力。隐藏完成的定义将阻止它在 Scrum 团队之外工作。使“完成的定义”透明化的一个好方法是将您的利益相关者包括在其创建中；见以下原则。
使创建或调整完成的定义成为一种协作努力：与流行的看法相反，创建完成的定义不是开发人员的任务，而是整个 Scrum 团队的任务。那么，既然已经建立，您为什么不通过邀请利益相关者和主题专家加入来进一步扩大小组呢？例如，进行练习以了解您的选民对“完成”和质量的理解。当然，最终确定完成的定义仍然是 Scrum 团队的责任。然而，让其他人参与这个过程将有助于建立信任。
定期检查和调整完成的定义：您的完成定义不是静态的，而是不断发展的。随着 Scrum 团队对问题和解决方案空间的了解越来越多，它会希望扩展并吸收之前完成定义的相邻领域，以减少依赖关系并提高其自我管理水平。（请注意，扩展需要首先在利益相关者之间建立信任。您的 Scrum 团队不能以闪电战的方式将自己置于该位置。）了解您的完成定义是否需要升级的有效方法是定期在团队成员和利益相关者之间进行匿名调查。
推销你对完成的定义：你需要向组织的其他人宣传自我管理质量标准的想法。当组织相信问答部门、质量门或“强化 Sprint”时，销售完成的定义尤其必要。一种行之有效的方法是邀请您的利益相关者参与创建 Scrum 团队的“完成定义”。
“足够好”适用于完成的定义：完成的定义并不是要从可用技术中挤出最高质量水平。您的团队的质量水平需要满足客户期望、治理要求以及共同的道德或道德标准。您构建的所有东西都不需要镀金或“劳斯莱斯”。
不要展示或交付未完成的工作：如果“完成意味着可交付”是每个 Scrum 团队成功的关键因素，那么我们会忽略我们正在做的任何事情，直到它在 Sprint Review 期间达到那个水平。这是一个坚定的信念，在绝大多数工作中都坚定不移。直到它不是，例如，在紧急情况下：想象需要立即修复的超级关键错误；一些即兴的解决方案可能没问题，直到您不久之后想出真实的东西。或者想想一个资金拮据的初创公司需要在下一轮融资中完成的关键里程碑——谁想死于美丽？然而，这些例子中的统一点是一样的：你提供一个蹩脚的版本来阻止潮流，然后尽快真正的“完成”版本。
永远不要放弃完成的定义：在 Scrum 中绝对没有刻意的偷工减料，例如，为了满足任意期限而放弃完成的定义；看上面。但是，如果您的利益相关者凭空提出交付日期，您必须在组织内解决这种协作反模式。不知何故，他们似乎不信任您的 Scrum 团队。找出原因并解决根本问题，而不是为了“让事情顺利进行”而违反团队对完成的定义。
结论
完成的定义是 Scrum 团队交付预期质量增量的重要垫脚石。从团队的角度来看，它提供了良好的投资回报，并应指导 Scrum 团队实现产品目标。忽视完成的定义将缓慢而稳定地削弱团队解决客户问题的能力、声誉以及对组织可持续性的贡献。
你如何处理完成的定义？请在评论中与我们分享您的学习成果。
,
