7.3 团队落地手册：结对、dojo 与评审

7.3 团队落地手册：结对、dojo 与评审

本节摘要：个人练会循环只要几周，团队养成节律要靠机制。本册前面所有章节的手艺，都需要在组织里找到落脚点：志愿小队做示范、乒乓结对做传艺、TDD dojo 做刻意练习、评审四问做日常守住。本节给出这套机制的完整操作法与推广时间表，并附上对两类最常见质疑的证据式回应。读完你应能着手在团队里启动一次有章法的 TDD 落地。

推广 TDD 最失败的姿势是发一封全员邮件宣布"以后都测试先行"。三个月后你会得到：一套没人维护的测试目录、几句阴阳怪气的段子、以及"我早说过没用"的先知。失败的原因不在 TDD 本身，而在推广方式——没经历过红灯救命的人不会相信红灯。机制设计的全部出发点因此只有一条：制造体验，而不是下发规定。

先回答两个质疑

推广路上必然遭遇两类质疑，回应要带证据而不是热情。质疑一："没时间写测试，工期赶不上。"账要算全程：TDD 把缺陷发现时点从集成期提前到编码期，调试成本降一个数量级（1.3 的收益账本）；省下的排障、返工、救火时间远超写测试的时间。更硬的证据是试点的数据——志愿小队跑两个月，拿缺陷逃逸率与返工工时说话（7.2 的结果指标这时兑现价值）。质疑二："TDD 拖慢设计，需求总在变。"恰好相反：需求常变的项目最需要低成本响应变化的结构，而测试先行正是结构的持续进化机制（第 4 章）。真拖慢的情形也存在——探索性代码硬上循环——所以 1.3 的适用性判断要一起讲，讲清楚"哪里不用"反而增强"哪里该用"的说服力。

机制一：志愿小队做示范

不搞全员运动，先招三到五人的志愿小队，选一块规则密集、痛点明显的业务（灯塔小组选的是折扣计算）跑完整流程。小队的产出有两份：一是业务成果，二是可参观的过程——提交历史里一行行测试名就是最好的展品。其他同事来看时，小队讲的不是道理而是现场：现场跑一轮红绿重构，十分钟，胜过十页布道文。示范期的诀窍是"可见的挣扎"：卡住、重切、返工都如实展示——完美的表演没人信，真实的挣扎才有说服力。试点业务的挑选也有讲究，三条标准按序筛：规则密集（TDD 优势区）、同事都认识它的痛（历史故障多，共情基础好）、规模两周内可完成（快出成果）。三条齐备的业务通常就在团队嘴边——那个"谁碰谁倒霉"的老模块，往往就是最好的示范田。

机制二：乒乓结对做传艺

结对是节律传播最快的载体，"乒乓"是最经典的玩法：甲写一条失败测试，乙写最小实现让它转绿并写下一条测试，甲再实现——写测试与写实现的角色按轮次交换。妙处在于角色强制性：写测试的人站在需求侧，写实现的人站在克制侧，两边都被节律推着走对路。轮换周期以天为单位，两周内每个成员都会在两个位置上各坐过几轮——节律是肌肉记忆，坐过才会。

乒乓结对一轮（约十分钟）：
  甲：写一条失败测试 → 跑红 → 验证失败原因
  乙：写最小实现 → 跑绿 → 顺手重构 → 提交
  乙：接着写下一条失败测试 → …角色循环互换
​

常见反弹的三段对话

推广期会反复遭遇三种反弹，各自的接法不同。反弹一："这套东西对老手是浪费。"接法是请他当评审人——四问评审正是为资深成员设计的参与位：不动手写，但把关节律，权威感与贡献感都不受损。反弹二："我试过，测试老拖我后腿。"接法是把他的痛点当需求做翻译——十有八九是替身越界或切片过厚（他曾经的体验里没有 3.3 和 2.2 的解法），当场帮他修一个具体案例，比讲道理有用。反弹三："项目太急，下个迭代再说。"接法是缩小而非推迟——同意不搞全套，但坚持"修 bug 先写复现测试"这一条最小节律：一条规则、零额外工时、收益立现，下个迭代的话题自然重启。三段对话的共同底色：把反对者的具体处境当输入，而不是当障碍。

机制三：TDD dojo 做刻意练习

dojo（道场）是定期的限时演练：全员围观，两人在投影前结对解一道小型 kata（密码校验、购物车这类 2.3 式的题目），时间盒四十分钟，旁观者只在"卡住"时提示，其余时间只观察不指导。一轮结束做回顾：哪里红灯挂久了、哪次重构最值、哪步违反了三定律。 dojo 的价值不在题目而在公开的慢——日常开发里没人敢慢下来给你看节律，dojo 专门提供这个慢速回放。频率建议双周一次，一次一题，贵在持续。组织形式上有个小技巧：题目提前不公布，现场抽签决定谁上桌——不确定感让旁观者保持"我可能就是下一个"的专注，比通知式围观有效得多。

机制四：评审四问做日常守住

节律的日常防线的布防点是代码评审。把 3.1 的四柱体检固化为测试评审四问：**它快吗、单跑绿吗、重跑绿吗、红了能看懂吗？**外加两问锦上添花：红灯先于实现出现吗（看提交配对）、替身在边界内侧吗（看 3.3 的边界线）。四问写在评审清单里， reviewer 照单提问，一个月就能把团队的测试品位拉齐。注意四问的对象是代码不是人——评审话术是"这条测试重跑会绿吗"，不是"你怎么又写脆弱测试"。评审还有个进阶用法：把"本次改动的测试怎么写的"列为描述模板的固定栏目，作者在评审描述里先自答四问——一半的测试问题在这一步就被作者自己发现，评审本身反而变快了。

⚠️ 推广期最大的雷是双标：试点团队执行节律，重点项目豁免——豁免一次，"TDD 是理想主义"的结论就种下了。要么全团队适用（存量代码按 5.2 的织网工序平等对待），要么明确例外清单与退出条件，绝不留模糊地带。

💡 节律成文的收尾动作：把团队约定写成一页纸——三定律、十分钟节拍、四柱评审、跳过纪律——新成员入职当天读完即可上手。一页纸写不下的约定，多半是还没想清楚。

推广时间表

• 头两周：志愿小队立项，选业务、立环境、跑通第一批循环。
• 头两个月：乒乓结对轮换铺开，dojo 双周转，评审四问上线。
• 第三个月：拿数据说话——逃逸率、修复时长、测试集健康度抽查，公开复盘。
• 之后：一页纸团队约定固化，dojo 保持双周，反模式体检（7.1）按月抽查。
• 时间表是节奏参照不是军令状：各阶段提前或延后都正常，唯独顺序不能乱——没有体验就上纪律，没有数据就上考核，是推广失败的标准配方。
• 下一节是全册收官的 FAQ——十个最高频的疑问，一次性答完。