定义
“完成定义”（Definition of Done）是Scrum团队共同商定的一套标准，用以确认何时一个产品待办项（Product Backlog Item）或增量（Increment）真正完成。这个定义不仅涉及产品特性的实现，还包括质量控制、文档编写等多个方面，确保交付的工作项满足团队和利益相关者的预期。
为何需要
统一理解：不同团队成员对“完成”可能有不同理解，比如一些人可能认为文档完善、经过复审且无已知缺陷即为完成，而另一些人可能认为通过初步测试不出错即可。这种理解差异可能导致交付工作的质量参差不齐。
提高透明度：产品负责人需要了解开发进度，以便做出明智的决策。完成定义的透明度使得产品负责人和利益相关者能更好地检查工作成果并做出适当的决策。
质量控制：不均匀的工作质量和意外的延误可能导致团队间的指责和紧张。开发团队必须就质量标准达成一致，以保证朝同一方向努力。
避免技术债务：团队可能无意（或有意）忽略一致性和质量的约定，从而产生技术债务。这些被忽略的工作项并未出现在任何待办列表中，但最终需要还清。
何时使用
当Scrum团队需要明确和量化他们的工作成果是否真正“完成”时，就应该使用完成定义。特别是在产品待办项进入Sprint并且在Sprint结束时需要评审和交付时，完成定义显得尤为重要。
如何使用
制定标准：Scrum团队需共同制定一套完成标准，涵盖开发、测试、文档等各方面，并确保这些标准是具体、可测量的。
实施和遵守：团队成员在完成每个产品待办项时，都必须遵守这些标准。例如，程序编写后需检查所有版本管理分支，更新设计变更的工程文档等。
周期性审查：在Sprint回顾会中，团队应定期审查和强化完成定义，以提升标准并促进团队成长。
注意事项
- 保持灵活性：完成定义应与团队的当前能力相匹配，并随团队能力的提升而加强。
- 避免过度要求：不应包括对任何利益相关者增值不大的条目。
- 平衡共享与自主性：在大型组织中，跨团队共享的完成定义可以建立公共质量水平，但也需要考虑到团队自主性的需求。
- 适应不同类型的工作：单一的完成定义可能不适用于所有类型的工作。在工作项类型多样时，可以考虑为不同类型的工作制定不同的完成定义。
- 与验收标准的区别：“完成定义”是对所有用户故事通用的标准，更侧重于质量方面的要求；而验收标准是针对特定用户故事的一组测试场景，用以确认软件是否按预期工作，更侧重于功能方面的要求。
案例研究
一个软件开发团队，他们正在开发一个新的移动应用。在项目早期，团队成员对何时一个功能算是“完成”有不同的理解。比如，一位开发人员认为功能在通过初步测试后即为完成，而另一位可能认为需要完成所有文档和细致的测试才算完成。
这导致在Sprint评审会上，产品负责人难以判断哪些功能真正完成，而哪些还需要额外的工作。结果，产品上线后出现了多个重大的缺陷，客户投诉频频，团队士气受到严重打击。
为了解决这个问题，团队决定制定一个明确的完成定义。他们一起讨论并确定了以下的标准，包括代码质量、测试覆盖率、文档完整性等。
- 持续集成通过
- 自动化单元测试的覆盖率达90%以上
- 静态检查没有严重以上程度的问题
- 代码通过评审
- 功能测试和系统测试通过
- 安全性测试通过
- 重要文档已更新
- 已发布到验收环境
实施这个完成定义后，团队发现他们能更有效地协作，减少了误解和沟通成本。产品质量显著提升，客户满意度也随之增加。通过这个过程，团队不仅解决了立即的质量问题，还提升了他们的工作标准和专业水平。
