完成就是完成：打造一份有牙齿的“完成的定义”
在Scrum中，“完成的定义”是对一个“增量”必须达到何种状态才算可用的、共享且正式的描述。2020版《Scrum指南》说得很直白：当一个产品待办列表项满足“完成的定义”时，一个“增量”便诞生了；而不满足它的工作既不能发布，甚至不能在冲刺评审中展示。麻烦在于，许多团队写出的“完成的定义”软弱到什么都证明不了。“代码已完成”和“已测试”听起来很严谨，直到你追问它们究竟要求了什么。这份清单帮你打造一份有牙齿的定义——并诚实地使用它。
一份真正的“完成的定义”要求什么
有牙齿的“完成的定义”是可验证的，而非一厢情愿。每一条都应是开发者可以指着说“对，这件事发生了”、无须解释的事实。用下面这些检查来给你的定义施压测试。
每一条都是二元的。 “已测试”是一种看法；“所有验收测试在构建流水线中通过”是一个事实。把每条标准改写到拥有明确的“是”或“否”答案为止。
它覆盖整个增量，而非单个任务。 “完成”针对的是可用的“增量”，所以要包含集成，而不只是孤立的编码。一个功能若只在某位开发者的笔记本上能跑，它就没有完成。
质量是内建的，不是事后加上的。 明确写出各项标准——代码评审、自动化测试阈值、安全与无障碍检查——让质量成为一道关卡，而非一种期望。
它反映真实的发布路径。 如果受监管或公共部门的部署需要文档、签批或审计轨迹，这些都属于“完成的定义”，因为没有它们，工作实际上无法交付。
它归整个Scrum团队所有。 开发者对它做出承诺，但产品负责人和Scrum Master必须理解它，因为它决定了哪些工作可被评审和发布。
没有半成品离开冲刺。 不满足“完成的定义”的工作要退回产品待办列表；它绝不会在“增量”中被记为部分完成。
在本个冲刺就用起来
“完成的定义”只有在团队把它当作冲刺期间的一道关卡来用、而不是事后才想起的记忆时，才有牙齿。具体动作很小，却能改变行为。在2022年，分布式和混合办公已成常态，一份成文且共享的“完成的定义”还默默承担着过去走廊交谈所做的工作——它让一支远程团队对“完成”的含义保持一致，而无须任何人开口去问。
在梳理待办项时把“完成的定义”朗读出来，让团队估算“完成”的真实成本。
在某个产品待办列表项被宣称完成的那一刻，把它当作检查清单来核对，然后它才计入“增量”。
在冲刺评审上，只展示真正满足它的工作——不要演示一厢情愿的设想。
在回顾会上检视并调整“定义”本身；随着团队能力增长，把它收得更紧。
当门槛暂时还够不着时
有时团队还无法满足组织所需的每一条标准——也许自动化部署或完整的安全测试尚未到位。《Scrum指南》的建议不是降低门槛，而是让差距可见：“完成的定义”记录下组织要求的标准，而团队暂时无法满足的任何标准，便成为为建立该能力而明确列出的工作。较弱的“完成的定义”会掩盖风险；一份诚实、团队仍在向其成长的定义则会让风险浮现。目标从来不是一份容易通过的定义，而是一份在被通过的那一刻就意味着实实在在东西的定义。
如果你的团队需要帮助，把一份含糊的“完成的定义”变成可验证的质量关卡，并把它接入工作评审与发布的流程，XNM的项目群与项目交付咨询服务可以帮你让“完成”真正意味着完成。