完成的定义

“完成定义”是对任何工作成果必须满足的条件的明确且共享的陈述，这些条件在被视为完成之前必须得到满足。与针对单个项目的验收标准不同，“完成定义”统一适用于团队的所有产出，并体现了团队自身所秉持的质量标准。

它的目的是使“完成”的定义客观且一致。如果没有这个标准，“完成”的含义取决于开发者个人的理解，而这种理解会随着时间压力和询问对象而变化。对某些人来说，“完成”包括测试、文档编写、可访问性检查和部署；而对另一些人来说，完成仅仅意味着代码能在他们的机器上编译通过。这种差异往往不易察觉，直到后果显现出来，通常是由于后期发现的缺陷，或是发布前需要返工。

典型的定义涵盖代码审查完成、自动化测试覆盖率达到既定标准、所有测试均通过、满足可访问性要求、文档已更新、安全问题已解决、性能在规定阈值范围内，以及至少部署到预发布环境。具体内容并不重要，重要的是这些内容必须达成一致、形成书面文件并实际执行，而不是仅仅停留在愿景层面。

最重要的功能是防止隐性工作悄然累积。那些未经测试、文档编写或无障碍修复就被标记为已完成的项目，表面上看起来进展顺利，实则暗藏着日后必须履行的义务，而且通常是在更糟糕的情况下。如果一个团队一边报告交付稳定，一边却不断累积这些积压工作，那只是在自欺欺人，几个月后，问题就会以莫名其妙的进度放缓的形式出现。

它还能在压力下保护质量，而压力恰恰是质量最重要、也最容易被忽视的时候。临近截止日期时，降低标准的压力巨大，而这种降低往往是隐性的；项目只是简单地标记为完成，但部分内容却被省略。将定义视为不可协商的原则，并在进度受到威胁时缩小范围，这种做法才是区分真正高效团队和那些虚报进度团队的关键所在。

该定义应随着能力的提升而不断演进，而非一成不变。尚未具备自动化部署能力的团队最初无法将其纳入定义，但应在具备该能力后添加。定期审查定义（通常在回顾会议上进行），并随着实践的成熟而提高标准，可使其转变为一种主动改进的机制，而非静态的检查清单。

定义也必须是可实现的，因为团队在正常情况下无法达到的标准会被悄悄忽略，而不是公开重新协商；而被忽略的定义比一个适度的定义更糟糕，因为它彻底消除了共同的参照标准。将标准设定在团队真正能够维持的水平，然后随着能力的提升而有意识地提高，这样才能形成一个真正能够规范行为的标准。

如果工作确实无法达到标准，诚实的做法是明确记录例外情况，而不是重新定义“完成”。如果某个项目因为明确的原因而未经过特定检查就交付，并且补救措施也得到跟踪，这属于管理决策。而如果同一个项目被标记为已完成，但遗漏之处却未被记录，那就成了技术债务，既无人认可，也无人会记得。

因为定义决定了质量在实践中的含义，所以它需要所有对结果负责的人的同意，而不仅仅是交付团队的同意。在实践中，它是在……内部确定的。 产品开发 遵循以下无障碍和体验标准 用户体验审核 来自以下方面的标准和性能阈值 网络性能 预算，以便该标准反映全部义务，而不仅仅是功能性义务。