写一份真正能堵住工作渗漏的「完成的定义」
在Scrum中，「完成的定义」是对增量工作何为完成所达成的共同理解。《Scrum指南》直言其重要性：若某项工作不满足「完成的定义」，便不可发布，也不属于该增量。因此，一份薄弱的「完成的定义」并非文档问题，而是一处质量渗漏——它把未竟之功贴上「已完成」的标签发布出去。
然而许多团队写出的，无非是「代码写好并测过」之类的话。当团队同处一室时，疏漏会被隔壁工位捕捉到。2021年初团队散落于各自的家庭办公室，这类非正式的把关随之消失，一份有牙齿的「完成的定义」便成了支撑质量的支柱。下面讲讲怎样写好它。
让每一条都可核验
「完成的定义」唯有在任一开发者都能看着某项工作、无需争论便答出「是」或「否」时才有用。请把形容词换成可核验的检查项。
不要写「测试充分」，而要写明标准：单元测试已编写并通过，达到约定的覆盖率目标，且构建为绿色。
不要写「已评审」，而要写明由谁、如何：同行代码评审已完成，评论已解决。
不要写「已记录」，而要点明产出物：面向用户的变更说明，以及任何API变更已记录在案。
纳入总被略过的非功能性工作：无障碍性、安全检查，以及在约定阈值内的性能。
确认工作已集成并可部署至目标环境，而非仅在某台笔记本上能跑通。
共建它、认领它，并随时间收紧它
「完成的定义」归属于开发者，而非由某位经理颁下一张清单。请共同搭建它，团队才会真正去执行；随后将其视为一份不断演进的标准。
与全队一同起草。 开一场会，让开发者列出每一个曾经栽过跟头的环节。共同的作者身份，能把一张清单变成众人愿意捍卫的承诺。
尊重组织层面的标准。 若你的组织有一份更宽泛的「完成的定义」，你们这份必须达到或超过它。团队可以加入更严格的标准，绝不可更宽松。
在冲刺过程中执行，而非到末了才执行。 各项工作应持续向「完成」推进。把它当成最后一道关卡，只会堆出一摞几近完成、却在冲刺评审上过不了关的活儿。
在回顾会上检视并调整它。 当某个缺陷溜了过去，就问：「完成的定义」中哪一条本可拦住它？然后把那一条加进去。随着团队的学习，这份定义理应愈发坚实。
一份真正的「完成的定义」会改变每场对话的语气。「完成了吗？」不再是一种主观裁断，而成为人人都能逐项核对的清单。起初速率或许会下滑，因为被掩藏的工作显露了出来，但你交付的东西是真正可交付的——而这才是唯一值得计数的进展。对远程团队而言，这份明确而共享的标准，往往就是透明与悄然偏离之间的分水岭。
如果你的团队需要一套让「完成」在各处含义一致的交付标准，XNM的项目群与项目交付咨询服务 可以帮你定义并将其落地扎根。