DoD实验：伪装的诊断工具
Source: Dev.to
这是关于 Definition of Done 实验的系列的第 2 部分。第 1 部分：在它毁掉我们之前修复 “Done”
两个冲刺后，假设仍基本未被检验
实验执行不足：
- 与 DoD 的一次细化会议，
- 一张受其显著影响的工单，
- 环境噪声过多，无法对交付时间得出结论。
出现的却是意外。DoD 并未主要改变估算——它迫使团队编写了一本手册。该手册现在正在重新塑造团队对代码的讨论方式，并暴露出 DoD 本身无法解决的问题。
六项变成了十四页
- DoD 本身很简洁：在 “always included”（始终包含）下有六项，几个有条件的，以及明确的 “never assumed”（从不假设）。→ 一页。
- 然而，执行需要共享的定义。
- “Errors are handled”（错误被处理）指向一页，描述 DomainError 模式以及错误如何在状态层中向上传递。
- “Styling uses prefixes”（样式使用前缀）需要具体示例。
- “Code follows existing patterns”（代码遵循现有模式）在这些模式并未以某种形式存在于人们的头脑之外时毫无意义。
因此，DoD 变成了 目录；手册则是它强制形成的系统。
这本来就是预料之中的——有文档记录的知识架构始终是前提。
未曾预料到的是 规模，以及之前有多少知识是隐式的。把它写下来并没有发明复杂性；它揭示了系统一直在运行且隐藏的隐式知识量。
今天是十四页——当 linter 不再是技术债务而开始强制执行本不需要文字说明的内容时，页数会更少。
让文档保持活力
十四页的文档如果仍然是 个人观点伪装成共识，就是一种负担。
缓解（结构性）:
- 手册存放在 monorepo 中，使用 Markdown 和 Mermaid 编写，可在依赖该手册的功能的同一 PR 中编辑。
- “更新手册” 本身就是一个 DoD 项目。
逻辑:
- 当你引入一种模式时，在同一次提交中对其进行文档化。
- 当你发现缺失的内容时，就地修补。
手册不是由某个人拥有的平行产物——它是代码库的一部分，遵循相同的审查流程。
到目前为止，这种结构运行良好。多个开发者在与功能工作同一 PR 中 主动 编辑了手册。这验证了所有权正在逐步分散。
尚未出现的情况是 反对——有人提议更改已有模式，而不是仅仅添加新内容。一个没有人挑战的手册可能意味着 被动遵从 而非真正的共享所有权。这个区别很重要，我现在正专门留意这一点。
文档让反馈去人格化
在手册出现之前，代码审查的反馈带有个人色彩：
“你应该给这个变量起个不同的名字。”
“这个错误处理不完整。”
每条评论都隐含着权威的主张。
现在有了一页文档。命名规范以书面形式存在；错误处理有流程图。当评论说：
“根据命名规范，这应该使用 hci‑ 前缀” (链接到文档)
对话就会转变。审查者不再是表达个人口味，而是引用了一项共识。纠正来自 系统，而不是个人。
在这两个冲刺中，大约 三分之一的 PR 明确引用了手册条目——用链接取代了主观评论。开发者在发现空白时提出了补充。手册创建了一种共享语言，但更重要的是，它在人员与反馈之间建立了距离。
一个工单，真实数字
Ticket: Document and consolidate error codes (technical‑debt ticket)
| 数值 | |
|---|---|
| 估计 | 1 天（在使用 DoD 进行细化后） |
| 实际时间 | 2–3 天 |
开发者开始工作后发现一团乱——错误码散落且没有统一的模式。自然的冲动是：在此期间顺手修复系统。于是他开始重构整个代码库中错误码的实现——这最终是必要的，但 不在本次范围 内。
- “重构相邻代码”在 DoD 中明确列为 “从未假设” 项目。
- 该工单在细化时已经考虑到了这一点。
重构并未计入估算，因为它不在约定范围内。干预发生在 重构进行中，而不是之前。回应很简单：DoD 刚刚上线，所以这一次算通过——但请注意这行文字。估算中不包括这项工作；如果不算这项工作，工单本可以准时完成。
没有任何阻力。在 Sprint Review 中，开发者自行提出了这段对话，作为 DoD 今后如何提供帮助的示例。DoD 并未阻止重构；它让本可能隐藏在“比预期花的时间更长”中的投入变得可见。正是这种可见性提供了杠杆作用。
产品看到的情况
产品团队没有抵制 DoD——他们 采纳 了它。细化变得有条不紊：
- 接手工单。
- 按 DoD 进行检查。
- “始终包含”——需要多长时间？
- “从不假设”——我们真的需要吗？
- 成本是多少？
他们的回应不仅仅是遵从。他们 提议将 DoD 项目直接嵌入工单模板。
真正的考验尚未到来：当 DoD 完成的估算远高于预期 时的工单。出现这种情况时，系统要么：
- 给出明确的取舍——把工作纳入进度或如文档所示推迟为技术债务，或者
- 在“只要上线”的压力下崩溃。
那一刻将揭示这到底是 流程还是表演。
在容量限制下的采用
在直接对话中，动机各不相同：
- 倡导者 看到系统运行良好并为之倡导。
- 怀疑者 更加谨慎——流程框架此起彼伏，而这个看起来像是更多的开销，却没有保证的回报。
对怀疑者产生影响的框架并非理想化的；它是 防御性的：
这不是为别人，而是为我们。
它阐明了我们同意构建的内容。
它明确跟踪技术债务。
如果出现差距并成为问题，我们会及早发现。
第 2 部分结束。
DoD 所揭示的内容
DoD 本来是要阐明“完成”在工单中意味着什么，结果却澄清了别的东西：范围。
手册记录了错误处理、WebComponent 模式、状态管理、样式约定、SSR 考量以及认证流程——十四页的技术决策，全部位于一个连贯的边界之内。
- 当手册中的模式需要在站会中讨论时，80 % 的与会者没有上下文。
- 当 Sprint Review 评估 DoD 合规性时，大多数参与者无法进行评估。
DoD 所要求的协作并不对应当前的仪式——这并不是因为仪式本身有错，而是因为它们服务于更广泛的群体。
回顾手册时，出现了一个问题：这实际上描述的是谁的工作？
答案并不是“全栈团队的前端部分”。更接近的说法是“消费 API 的产品团队”。我们的 monorepo 还有自己的后端关注点——认证、会话、SSR。我们与后端团队的接触点是合同性的：API 形状、响应格式、错误码。日常协作极少。
这并不是批评。团队会演进，结构会变动。但 DoD 强迫我们明确我们实际在构建什么——而这种明确暗示了一个可能需要自己协作节奏的边界。
至于这会是什么样子，我还不知道。下一步是具体的：
- 绘制实际的协作流。
- 评估专门的前端仪式选项。
- 测试不匹配是摩擦还是裂痕。
这就是 第 3 部分。
当前状态
估算假设仍未得到验证。要正确测试它需要受保护的细化、跟踪估算与实际值的对比以及更多样本。
现有的内容：
- monorepo 中的 14 页手册，由多位开发者编辑。
- 产品希望嵌入工单模板的完成定义（DoD）。
- 一个使反馈去人格化的共享语言。
- 现在无法忽视的结构性不匹配。
DoD 本意是修复估算问题，结果却暴露了估算一直在补偿的内容。
它最终是否能提升交付仍未可知。对团队而言，问题已经从 “为什么花了这么久？” 转变为 “我们到底同意构建什么？”——这是一 个不同的起点。
此处描述的观点和实验均为本人所有，不代表我的雇主。