不清晰的完成-敏捷坑人系列
摘要： 本文主要描述Scrum中完成的定义（Definition of Done，DoD）以及验收标准（Acceptance Criteria，AC）的用法。
“坑”的描述 完成的定义，即DoD不清晰，不仅仅是概念本身可能存在误解，常常由深层次的原因引起的。
完成的定义 与 验收标准 实际可能的例子 每日站会上，团队成员A：“昨天我完成了条目1！今天我将开始工作于条目2上。”
两天后，产品负责人找到团队，“条目1怎么回事，这个流程和我想要的并不一样……”
上面这个场景，每天都在不同的团队上演着。为什么会发生这样一幕？有可能他们缺少完成的定义与验收标准
完成的定义（摘录自Scrum指南） “完成”的定义
当产品待办列表项或增量被描述为“完成”时，每个人都必须理解“完成”意味着什么。虽然在不同Scrum团队之间或许会存在显著差异，但是每个团队成员必须对完成工作意味着什么有相同的理解；以便确保透明化。这就是 Scrum 团队的“完成”定义，用来评估产品增量是否完成。
这一定义也同时被用来指导开发团队了解在Sprint计划会议时能够选择多少产品待办列表项。每个 Sprint 的目标在于交付符合 Scrum 团队当前“完成”的定义的潜在可交付功能增量。 开发团队在每个 Sprint 都交付产品功能增量。这一增量是可用的，所以产品负责人可以选择立即发布它。
如果“完成”的定义对增量来说是开发组织的惯例、标准或指南，那么所有Scrum团队都必须遵守它，以此为最低标准。 如果增量“完成”的定义不是开发组织的惯例，那么 Scrum 团队中的开发团队就必须制定适合于产品的“完成”的定义。如果系统或产品发布由多个 Scrum 团队一起开发，那么所有 Scrum 团队中的开发团队必须一起参与制定“完成”的定义。 每个增量都添加至之前的所有增量上，并且经过彻底地测试，以此确保整合在一起的所有增量都能工作。
随着团队的成熟，“完成”的定义会扩展，包含更为严格的标准来保证更高的质量。当使用新定义时，在先前“完成”增量中可能会发现尚需完成的工作。任何产品或系统都应该对其上面开发的工作有“完成”的定义。
在Scrum指南中我们可以看出：
整个产品有统一的完成的定义 完成的定义是Scrum团队制定的，并共同理解的 每个团队可以定制自己的完成的定义 完成的定义可以扩展（当团队成熟之后） 完成的定义一个例子（有下划线的内容为当前产品的完成的定义，随着团队成熟，其他未有下划线的部分，可以逐步加入到完成的定义中）： 验收标准 验收标准（AC）是针对单个条目（如用户故事）而言的，如何验收（或确保）单个条目是满足客户要求的。验收标准具有如下的作用： - 定义用户故事或特性的边界 - 帮助厘清客户要求 - 团队与客户（以及产品负责人）达成共同理解 - 根据验收标准可以有效的产生测试用例
验收标准的一个例子： 用户故事：
作为一个互联网银行用户，
我想要看到每日交易明细，
以便我很清楚每笔交易之后自己的账务情况。
验收标准的例子如下：
- 默认显示最近一周的每笔交易明细 - 显示当前账户余额 - 显示指定日期时间段的交易明细 ###完成的定义与验收标准