完成定义

DoD 或“完成的定义”取决于已商定的标准，项目团队必须完成这些标准才能确定项目元素是否可交付或已完成。

DoD 在团队中创建了共同的视图，即要完成哪些工作才能将用户故事、功能或产品视为完整。

“完成”的含义是什么？

如果你正在寻找字典含义，它是一个形容词，意思是“完成的；结束的；通过的”（我们的任务已完成）。但你到底如何理解何时达到可以称任何事情已完成的程度？

每当你跑一场比赛，比如长跑比赛时，你都知道当你跑完终点线（42 公里或 26.2 英里后），你就完成了。计量单位可以帮助确定终点线在哪里，以及何时可以宣布自己已完成。

然而，你设定的标准越多，你就越能理解你是否真正完成了。马拉松运动员可能希望跑过终点线来完成比赛，但他们还必须满足以下额外要求才能将工作视为“完成”：

• 在 2 小时内完成比赛。
• 获得前三名。

如果运动员只跑了 42 公里，但没有达到其他标准，他们很可能会继续跑马拉松，直到达到。当他们达到所有三个要求并可以继续执行下一个任务时，他们就完成了。

这在项目中意味着什么？

每个项目都应该设定一个目标。一旦设定了该目标，它应该指导团队所完成的每一项工作都朝着最终目标前进。建立 KPI 或标准，以此衡量项目的有效完成情况，以确保参与项目的团队清楚地了解他们需要努力实现的目标。

对于项目经理来说，仅仅设定或表达项目目标和相关的成功指标是远远不够的，因为项目通常太大，团队难以轻易理解为实现目标必须采取哪些措施。

“完成的定义”（DoD）使项目经理、Scrum Master 或项目负责人能够在团队中生成一个准确的视图，说明必须满足哪些标准才能将项目元素视为完整。

实际上，它是一个清单，团队可以使用它来验证所有工作（以及相关的组件，如审查等）都已完成。

这适用于项目目标或项目分解结构的每个元素。

重要的是要注意，项目组无法完成“未完成的工作”，这消除了项目后期或投入生产后可能出现问题并造成风险的可能性。

谁来制定“完成的定义”？

整个项目组必须共同参与定义项目、增量（例如 Sprint）、特性、产品或用户故事的“完成”。项目经理必须验证所有利益相关者都已就 DoD 中的标准达成一致。

回到我们的体育场景，如果接力赛的参与者无法就以获得金牌为目标的 4x100 米冲刺接力赛的 DoD 达成一致，那会怎样？

对于跑者来说，“完成”意味着尽快跑完 100 米路段。对于另一个人来说，“完成”意味着成功地传递接力棒并确保最后一个跑者冲过终点线。团队负责人需要与每个团队成员沟通，检查“完成”在目标（赢得金牌）方面意味着什么，并协调所有跑者，以确保所有这些标准都一致同意必须成功实现。

团队的每个成员都需要共同努力，将所有关于“完成”所需标准的想法汇集在一起，并互相监督，共同完成这些标准。

“完成的定义”仅适用于敏捷项目吗？

在所有项目中，都应应用“完成的定义”或 DoD。项目任务的截止日期和时间是判断完成度的一种方法。然而，了解何时真正完成一项工作将有助于项目经理在时间框架内管理时间和质量。

传统的或瀑布式程序可能缺乏迭代、“可交付产品”以及自主团队等概念，但它们仍然包含具有完成日期和截止日期的任务，这些任务定义了完成度。

项目经理不应仅仅依靠时间来确定一项工作是否完成；相反，他或她应设定其他标准来控制和限制未完成的工作推迟项目完成截止日期的风险。

DoD 可以更容易地应用于敏捷，并且一些技术，如 Scrum，依赖于它并将它的使用纳入许多重复的流程中。这可能是一个巧合，但英语中“done”一词的使用从 20 世纪初开始缓慢下降，直到 20 世纪 90 年代有所回升，而这恰好是敏捷变得更受欢迎的时候。

DoD 经常用于敏捷项目中，以验证所提供的产品是否“可交付”。项目团队（与产品负责人合作）将为功能和质量标准创建一份清单，这些标准必须在工作执行前得到满足。必要时，组织标准可以记录在单独的“完成定义”中，从而允许产品负责人评估团队和公司必须满足的标准。这也有助于提高透明度并为利益相关者提供更广阔的视角。

“完成的定义”的示例

应执行以下操作来设置当前任务的 DoD（如前所述，它可以在项目的多个层级完成）：

• 项目主管或产品负责人与团队合作定义完成的标准。
• 团队决定标准并创建一份清单，用于在进行过程中确认完成情况。
• 团队对项目的每个部分都遵循相同的方法，确保用户故事和 Sprint 都有“完成的定义”。团队还确保所有故事或任务都有接受标准，以帮助进行项目质量保证。
• 产品负责人调查 DoD 组织标准，例如安全性、合规性以及品牌标准。

“完成的定义”应包括所有必须勾选的项目，才能将产品视为可交付。这些可以处于团队选择的任何阶段，但理想情况下应包含以下关键项目：

• 设计文档已完成并批准。
• 已完成代码创建的用户指南/操作说明。
• 测试已结束。
• 所有缺陷都已修复。
• 发布说明已完成。
• 验收标准已满足，产品已批准。
• 变更管理已完成。
• 已部署到生产环境。

处理“未完成”工作的影响与满足“完成的定义”同样重要。鉴于所有未完成的工作都将返回到待办事项列表，在每次迭代中发生这种情况越频繁，携带的风险就越大，最终将发布置于危险之中。为了降低这种风险，请验证所有标准以及满足这些标准的时间表都是合理的。产品负责人、项目经理或 Scrum Master 必须验证是否已完成最低限度的检查，以获得可交付的产品。

有用提示

查看“就绪定义”，它允许团队评估故事或 Sprint 中的工作是否值得一开始。这促使采取更严格的方法，仅在工作通过特定的“就绪”测试后才开始，这最终将降低 DoD 要求未被满足的可能性。

“完成的定义”的重要性

1. 提供清晰度和一致性：它在团队成员、利益相关者和消费者之间建立相互理解，确保每个人在完成标准上达成共识。
2. 质量保证：通过建立明确的标准，“完成的定义”有助于保持高质量的软件，同时降低缺陷、错误和功能问题的可能性。
3. 它促进高效的工作流程，因为一旦满足特定功能的“完成的定义”，团队成员就可以安全地进行后续任务。
4. 客户满意度：遵守“完成的定义”可确保客户获得可靠、功能齐全的软件，满足他们的需求和期望。
5. 持续改进：“完成的定义”为持续改进提供了基础，因为团队可以随着时间的推移审查和调整标准，以改进其开发技术。

“完成的定义”是软件开发的重要组成部分，因为它提供了一系列标准，用于确定何时完成任务或功能。通过定义明确的功能、代码质量、测试、记录和其他因素的标准，组织可以确保交付超出客户需求的高质量软件。

使用“完成的定义”作为指导原则可促进可行的开发流程，改善团队协作，并促成高效的软件项目。

“完成的定义”与验收标准

人们常常感到困惑，他们认为自己的“完成的定义”是一个质量保证问题，而不是项目管理问题。为什么不直接使用你的验收标准来决定项目何时“完成”呢？

尽管验收标准和你的“完成的定义”都有助于确定项目何时完成，但它们在使用方式和地点上存在显著差异。

两者之间的一个基本区别在于，“完成的定义”是通用的。它适用于你的工程团队在当前 Sprint 中发布的所有内容。

另一方面，验收标准是针对具体的用户故事、功能或问题。

这在实践中可能表现如下。

在交付用户故事时，这是你最常使用“完成的定义”的地方之一。用户故事是从你的用户和客户的角度编写的简短、直接的功能描述。例如：

“作为 [用户类型]，我希望 [特定功能] 以确保 [获得一些好处]。”

当以下项目被勾选时，用户故事被视为“完成”：

• 单元测试成功。
• 代码已审查。
• 每个问题的验收要求都已满足。
• 功能评估成功。
• 非功能性需求已满足。
• 用户故事已获得产品负责人批准。

只有当所有这些条件都已完成时，用户故事才能被视为“完成”。然而，为此，每个问题都必须满足其自己的一组验收标准。

将这些视为不同的具体级别。“完成的定义”适用于你 Sprint 中的所有用户故事，但每个用户故事都将有自己的一组验收标准，必须满足这些标准才能被视为准备好交付。

这同样适用于开发的其他阶段。例如，你的属性“完成的定义”几乎肯定会包含诸如集成和部署到干净构建等需求。

“完成的定义”的好处

使用“完成的定义”有多种好处：

1. 对质量和团队交付该水平的承诺有一个共同的理念。质量的概念更广阔，因为它不仅仅包含一项工作或一个用户故事。
2. 团队中的每个人都清楚对他们的期望以及团队作为一个整体必须实现的目标。
3. 团队提供高质量工作的需求正在增加。
4. DoD 是一种可操作的工具，可用于检查商定的标准。
5. DoD 可以针对多个因素建立，例如用户故事、功能、冲刺和发布。
6. 通过这种方式，可以为主题生成适当的 DoD，然后可以在团队中进一步协作开发。
7. 积压项目、功能或用户故事是否真正“完成”是显而易见的。

对“完成的定义”的承诺

“完成的定义”的好坏取决于团队的投入程度。它是团队承诺将商定标准付诸实施的声明。它是一项承诺，也是卓越产品开发的必要基础。至关重要的是，它必须通过协作方式产生，才能产生影响。仅由产品负责人制定的 DoD 不会产生这样的承诺。

为了产生最大的影响，“完成的定义”必须以易于所有参与方随时获取的方式共享，最好是打印出来贴在墙上。

这种清晰度也加强了团队对满足商定标准的承诺。

“完成的定义”的持续应用

在使用“完成的定义”时，企业面临许多挑战：

1. 持续使用“完成的定义”如何有效？
2. 多个 DoD 之间的联系如何组织？
3. 可以对“完成的定义”进行哪些修改或改进？

在使用“完成的定义”时，组织最终必须决定是否不总是满足所有要求是公平的。也许所列出的要求比预期更全面，也许在个别情况下同意技术债务是可以接受的？这个问题没有统一的解决方案；它是模糊的。

然而，对于一个组织来说，确定这是否是一次性违反，或者 DoD 是否应该永久更改，这一点至关重要。因此，标准细化可能导致标准的减少，或者相反，标准的增加。

在不同层级使用多个 DoD 可能会导致开销和透明度不足。如果满足单个故事的验收条件，则必须验证“完成的定义”。DoD 对于用户故事的构建是显而易见的。

此外，冲刺“完成的定义”以及可能的发布“完成的定义”也适用。

组织将关键信息存储在哪里？如果另一个阶段的条件未满足，用户故事如何获得批准？使用多个 DoD 不会导致更高级别的要求在用户故事过程中逐渐变化吗？这些问题也无法一概而论。换句话说，组织必须设计一种实用的方法来处理不同级别的 DoD，并且如果需要，不仅要定义单个“完成的定义”，还要定义多个 DoD 的相互作用。