三條各自完成的水平線，疊不出一套能用的系統；一條從畫面通到金流、再回到畫面的細路，才是第一個可以驗收的進度。

又是三張 Ticket

昨天把「怎樣算完成」寫成了五條 Acceptance Criteria，貼在牆上。下一個問題馬上來：怎麼動工？

PM 打開看板，手指幾乎是自動的：「那就開三張票——前端畫面一張、後端 API 一張、金流串接一張，大家平行做。」

開到第二張的時候，他自己停住了。

這三張票，跟上次翻車前開的那三張，一模一樣。

會議室安靜了幾秒。年輕的後端工程師開口——就是當初想約三方對齊會議、被一句「先做再說」擋回去的那位：

「這次不要拆三條線。切一條細的，三個人一起把它走通。」

當時我們怎麼理解「平行做比較快」

先誠實面對一件事：三張票的開法，不是誰的錯，是所有人的直覺。

理由每一條單獨看都成立。術業有專攻，前端不必懂金流；三個人平行做，理論上三倍速；先各自完成，最後整合一下就好；整合有問題再處理，軟體不都這樣做的。

合在一起，就是上次的整合日。

Day 17 已經把結局演過一遍：前端等 boolean、後端回狀態字串、webhook 三方都以為不歸自己；單元測試全綠，端到端一路紅；三個人異口同聲說「我這邊是好的」，而整套系統不能用。

水平分工的「快」，是把整合成本記在最後一天的帳上。帳單到期那天，有個名字，叫整合日。

第一刀：一條最細的路

所以這次換一種切法。第一刀，切到不能再細：

一筆測試訂單：信用卡、未出貨、七天內
一種操作：客服對它發動全額退款
走真的路：金流商的測試環境，不是 mock
含非同步：webhook 回來，把「處理中」改成「成功」
畫面誠實：UI 只有三態——處理中、成功、失敗

這一刀刻意不含的東西同樣重要：失敗路徑先不細做、重送防護先不做、對帳檔先不看、畫面醜沒關係。

第一天，三個人先花一小時把交界填完。上次翻車後留下的那張介面與責任對照表，這次在動工前填：狀態就用先前定案的狀態機——申請、處理中、成功、失敗——前端不再等一個是非題；webhook 端點誰負責，這一行第一次在動工前就有名字。然後各自動工：後端立一支最薄的 API，前端畫一個最醜的三態畫面，金流串接工程師把 webhook 端點立起來。

第二天下午，第一次串接。webhook 進來，查不到對應的退款單——單號欄位對應寫錯了。當天發現，當天修掉。同一個 bug 如果放在上次的做法裡，會安安靜靜埋兩週，等到整合日才爆。

第三天傍晚，整條路第一次走通：按下退款，畫面轉為「處理中」；幾分鐘後，金流測試環境的通知送達，狀態翻成「成功」，畫面跟著變。牆上五條 AC，前兩條第一次有了可以現場示範的證據。

第二刀才加寬，又花了兩天：金流退款失敗，狀態轉「失敗」、可以重試；同一筆通知來兩次，只退一次。第三、四條 AC 勾掉。

注意一件事：每一刀結束的時候，那條路都還是通的。

整合不是最後一步，是每一步

把這條路抽象出來，就是這個系列案例的最小流程：

UI → API → Gateway → State → UI

Vertical Slice 的意思是：每次完成的不是「某一層」，而是這條鏈的一小段完整縱切——範圍窄到只有一種情境，但從畫面出發、穿過每一層、回到畫面，整段可以被真的操作、真的驗證。這就是一小段可驗證的 End-to-End Increment。

跟水平分工擺在一起看：

水平分工：
前端 100%＋後端 100%＋金流 100%
＝三個「完成」，零個可驗收
整合集中在最後一天，風險也是

垂直切片：
一種情境，走通全部的層
＝範圍最小，但每一片可驗收
整合攤平在每一天，風險也是

「可驗收」三個字，昨天已經鋪好了。AC 是寫給一條路的，不是寫給一層的——「按下退款後看到處理中」這句話，前端一層驗不了，後端一層也驗不了，只有整條路能驗。所以水平分工做得再乾淨，AC 一條都勾不掉；垂直切片每收一刀，就能勾掉幾條。

對照組不用另外找，就是 Day 17。同樣三個人、同一套系統、同一家金流商。上次，兩週看板全綠，整合日一路紅；這次，第三天就有一條真的通的路。差別不是人變強了，是切法變了：上次的每一天都在累積「未整合的存量」，這次的每一天都在延長「已驗證的路」。

順帶還一個公道：瀑布在這件事上其實比上次的團隊誠實。瀑布把整合當成一個正式階段——有計畫、有時程、有測試項目，它至少承認整合是工作、會失敗、要花時間。上次的團隊連這個都沒有，整合被當成「接一接就好」的下午。而敏捷不是取消整合，是把它搬進每一天：Working Software 的意思，是每一輪交出來的東西都真的 work，而要每一輪都 work，整合就不能是最後一步。

整合不是最後一步，是每一步。

那條路，以前住在誰腦裡

Day 17 說過，資深工程師在的時候，他自己就是那條路：整條流程的地圖在他腦裡，他被金流商炸過，開工第二天就會問出「webhook 誰接？」。

他現在仍然被借調在外，不在場。

但這次沒有人需要成為那條路。因為從第三天起，那條路就真的存在——測試環境裡有一筆真的退掉的訂單、一個真的被 webhook 翻過狀態的紀錄、一個誠實顯示三態的畫面。誰對交界有疑問，不用去問某個人的記憶，去走一遍那條路就好。

大神的整體感——那種「我知道這整條流程長什麼樣」的能力——在水平分工裡是稀缺的天賦，在垂直切片裡是每天運行的事實。地圖不再需要住在任何人的腦裡，因為它每天都被走一遍。

這次到底誰在吸收代價？

老規矩。金流非同步、三方交界、沒人熟的 webhook——這些不確定性上次炸掉了整合日，這次它們去哪了？

Scope       ■   每輪只做一片；薄是刻意的決策，不是偷工
Time        □   整合成本攤平到每天，不再有整合日
Cost        □
Quality     □   通了的部分是真的通——真金流、真 webhook
Risk        □   最不確定的非同步，第一刀就走掉了
人          □   沒有人在整合日加班，也沒有人需要通靈

把這張表跟 Day 17 那張擺在一起：那次是 Time ■ 加人 ■，這次只剩 Scope ■。同一個專案、同一批人，唯一的差別是，這次的「少做」是攤在桌上選的，不是最後被炸出來的。

不確定性沒有消失。它被切片吸收了——每一刀只咬一小口，咬不動就當天知道。

今日 Artifact｜切片計畫

動工前，把第一刀想清楚。三個問題：

□ 第一刀：切哪一條最細的路？
  （一種使用者、一種情境、一筆資料；從畫面出發、穿過每一層、回到畫面）
□ 這一刀要驗證什麼？走通的判準是哪幾條 AC？
  （把最不確定的那段放進第一刀：外部依賴／非同步／＿＿＿＿）
□ 下一刀加寬什麼？
  （失敗路徑、重送防護、更多情境、樣式——一次加一種寬）

最容易寫錯的是第一行：多數人切出來的第一刀還是太寬。檢驗方式很簡單——如果整個團隊沒辦法在幾天內一起把它走通，它就不是一刀，是三張票。

今日一句

進度不是三條各自百分之九十的線，是一條百分之百通的細路；路先通，再談寬。

第二刀收完那天，牆上五條 AC 勾掉了四條，剩下對帳那條排在下一刀。有人望著畫面上那個「成功」，問了一句：

「所以——這條路，要拿給誰看？」

好問題。明天來回答。先說結論：Review 不是成果簡報。