对于Scrum团队来说，“完成的定义”已经成为一件近乎标准的事情。“完成”的定义（通常称为“DoD”）为要完成的项目确定了每个产品待办项必须是正确的。
典型的 DoD 类似于：
代码编写得很好。（也就是说，我们对此感到满意，并不觉得它需要立即重写。）
代码已签入。（当然是一种“当然”的声明，但仍然值得一提。）
代码成对编程或同行评审。
代码附带所有适当级别的测试。（即单元，服务和用户界面。）
代码实现的功能已记录在任何最终用户文档中，例如手册或帮助系统。
许多团队将随着时间的推移改进他们的“完成定义”。
例如，使用上述示例的团队在首次启动时，可能无法进行如此多的自动化测试。但是，过一段时候后，他们会将其添加到他们对完成的定义中。
对绝大多数团队来说，这就足够了。但我曾经参与了一些项目，这些项目的团队受益于已完成的「多个定义」。团队将产品待办项目定义为第一个sprint中完成的Level 1，定义后续sprint中完成的Level 2，依此类推。
我绝对不是说他们在第一个sprint中编写代码，并在第二个sprint中测试它。“完成”仍然意味着测试，但它可能意味着测试到不同但恰当的水平。
让我们看一个例子：
游戏工作室的一个例子
我在与游戏工作室合作时非常喜欢的一件事是，他们明白并非所有的工作都会成为完成的游戏。
有时，例如，游戏团队尝试使用新角色试图让角色变得有趣。如果他们不能，则角色不会添加到游戏中。
因此，对于游戏团队来说，需要完成所有艺术要求完美，所有音频都要录制，并且当他们仅仅试图决定新角色是否有趣时，刷新率会很高，这将是非常浪费的。团队应该做的只是足够的回答这个问题。
在许多游戏工作室中，这导致了四个完成的定义：
D1意味着新功能可以开始做并做出决定。
对于动画来说，这通常是“角色在白色房间中动画化。”对友好用户（通常是内部用户）来说，它可以“发送”，可以评论新功能是否符合其目标。
D2：这个东西被集成到游戏中，用户可以玩它/与之互动。
D3：这个功能真的可以交付。它足以包含在主要的公开发布中。团队可能不想发布它们 - 他们可能首先想要提高帧速率，添加一些多边形，增亮颜色等等。但是，如果必要的话，这个功能可以在这个状态下随附在一起。
D4：这个功能是经过调整、打磨，每个人都喜欢它。团队不会改变什么。典型的公开发布将包括d4和d3项目的组合。总有一些领域是团队想要回到并进一步改进的。但是，他们会将产品交付出去。所以d3是完全可以交付的，你不会为D3感到尴尬，只有你最努力的核心用户才会注意到它可能会变得更好的方式。
是否有适合您的多重定义？
很可能不会。大多数团队都非常擅长完成一个定义。但上述观点不仅仅局限于游戏开发。我在许多其他应用程序领域使用了相同的方法，特别是硬件开发。在这种情况下，相关团队正在为家庭自动化产品的集成套件，开发数十个新的小工具。
他们使用了这些定义：
D1：新硬件在办公室的测试台上工作。
D2：新硬件与套件中的其他产品集成。
D3：新硬件在至少一个用于此类beta测试的模型房中安装并运行。
D4：产品已准备好销售（例如，它符合UL认证的所有要求）。
在这家公司中，一直有几十个组件在开发中，在每个成熟度级别上都可以找到一些组件。例如，一个用于提高和降低遮光度的产品可能正在模型库中进行测试，而一个用于打开和关闭门的新组件刚刚启动，并且只在一个开发人员的测试台上工作。
大多数项目永远不需要这个。如果你认为这对你来说是合适的，在尝试之前，一定要确保你没有把这项技术作为跳过测试之类的事情的借口。
每个级别都应该作为一种对产品做出决策的方式存在。
一个很好的测试是看看是否在每个级别上都有一些特性被丢弃。例如，这是一个很好的迹象，有时某个特性达到了某个成熟度级别，并且产品所有者决定不再需要该特性，可能是因为它的成本或交付时间。
来源：