「先做再說」有兩種：一種是先做一小段，拿去換 Feedback；一種是用動工逃避定義問題。看板分不出這兩種綠色。

一句話，擋掉一場會

昨天的故事停在一個提議：有人想在動工之前，先把三方拉在一起對齊一次。

提議的人是後端工程師，團隊裡最資淺的一位。他的理由很樸素：退款這條路會經過前端、後端跟金流，三段最後是要接在一起的，先講好比較保險。

PM 的回覆就是今天的標題：

「我們敏捷啊，先做再說。卡了再同步，不要為了開會而開會。」

會議沒有開成。那張「幫我加一個線上退款功能」的 Ticket，當天拆成三張：前端一張、後端一張、金流串接一張，各自認領，各自開工。

接下來兩週，一切看起來都非常健康。Standup 每天準時，每個人都講得出昨天做了什麼、今天要做什麼；沒有人喊 Blocked，所以那句「卡了再同步」承諾的同步，一次也沒有被觸發。看板上的卡片穩定往右移，滿版的綠。

前端回報：退款按鈕與結果畫面完成八成。後端回報：退款 API 主流程寫完。金流串接工程師回報：文件讀完，測試環境打通。

進度會議上，PM 對客服主管說：進展順利。

沒有人說謊。每一句回報都是真的。

當時團隊怎麼理解這件事

照慣例，把當時的想法攤開來，每句單獨看都有道理：

我們是敏捷團隊，敏捷就是行動優先，不要被會議跟文件拖住；東西做出來才有討論的基礎，對著空氣開需求會議是浪費時間；真的卡到再拉人同步，比事前開一堆會有效率；而且你看，看板一直在動，這就是專案健康的證明。

其中最有力的是「先做再說」這四個字——因為它聽起來就像敏捷本人。敏捷不是反對 Big Design Up Front 嗎？不是說 Working Software 勝過完整文件嗎？先動手做，哪裡錯了？

錯的不是「先做」。錯的是那個「說」——這個團隊把「先做再說」執行成了「先做，然後就不用說了」。

真敏捷的「先做」，跟這裡的「先做」

Day 03 講過真的把敏捷跑起來的樣子，那條鏈值得搬回來對照：

承認還不知道完整答案
        ↓
先做一小段——小到可以真的被使用
        ↓
拿給真實使用者，取得 Feedback
        ↓
根據 Feedback，重新決定下一步

注意「先做一小段」在鏈上的位置：前面是承認不知道，後面是取得 Feedback。先做，是因為有問題想拿去問真實世界；做出來的那一小段，是問問題用的。

再看這兩週實際發生的事：

真敏捷的「先做」
→ 做一小段，拿去換 Feedback
→ 有人看、有訊息回來、下一步因此改變

這裡的「先做」
→ 三個人各做各的一大段，沒有預計要給誰看
→ 唯一產生的訊息，是看板上的綠色

同樣叫「先做」，一個是實驗，一個是逃避。

逃避什麼？逃避昨天攤開過的那些問題：這個退款要給誰用、解決什麼問題、怎樣算成功、碰到誰的規則、誰說了算。這五問昨天沒人問，今天 Ticket 拆成三張之後，更不會有人問了——因為每個人手上那張卡，看起來都不需要這些答案也能動工。

於是問題還沒被定義，工作已經開始。開工不等於開始解決問題；那種「大家都動起來了」的安心感，是專案裡最貴的安慰劑——它止住的不是痛，是追問。

缺席的是動工的門檻

今天缺席的工程責任，兩套方法裡其實都有，而且都放在同一個位置：動工之前。

瀑布那邊，Day 02 的邏輯鏈第一步，就是把「要做什麼」寫下來凍成 Baseline；沒有 Baseline，估算與承諾都無從發生。換句話說，瀑布根本不允許你在不知道要做什麼的時候開工。這個團隊當然沒做這件事——不意外，他們本來就說自己不是瀑布。

意外的是敏捷那邊。真的敏捷團隊把一張卡拉進 Sprint 之前，會先確認它準備好了：問題定義過、完成有判準、依賴點過名。這件事有個名字，叫 Definition of Ready。它可以只有三行，不需要任何厚重文件，但它守住一條底線：

敏捷省掉的是文件的重量，不是「知道自己在做什麼」這件事。

一張連「怎樣算完成」都寫不出來的卡，不是太敏捷，是還沒 Ready。硬拉進來動工，進度條會動，債也會動。

大神不在，連洞都沒人看見

第二部講過，這種洞平常是誰在補。Day 08 那位資深工程師，遇到一句話需求會順手把十件事問完——格式、量級、失敗、權限、邊界。如果他在，Ticket 拆成三張的那天，他大概會在走廊把三個人攔下來問幾個問題。會議不用開，洞就補掉一半。

但他被借調去救另一個專案了。這次，沒有人問。

更麻煩的是：他不在，連「有洞」這件事都沒有人看得見。洞的上面蓋著一層綠色的看板，每天 Standup 都在確認這層綠，沒有任何儀式負責往下看。

其實有一個人摸到了洞的邊緣——就是那位提議開會的後端工程師。他隱約覺得三段要接在一起、先講好比較保險，這個直覺完全正確。但「我們敏捷啊」這句話有個很陰險的效果：它把想先定義問題的人，變成不夠敏捷的人。被這樣定位過一次之後，資淺的成員通常不會再提第二次。

於是團隊失去的不只是一場會，是那個唯一還在追問的人。

這次到底誰在吸收代價？

老規矩。這兩週的帳，記在哪一格？

Scope       □   三張卡都在做，一項都沒少
Time        □   兩週過去，看不到任何延誤的跡象
Cost        □   沒加人、沒加預算
Quality     □   還沒有東西可以壞——目前
Risk        ■   沒被定義的問題全部堆在這格   ← 看板越綠，債越高
人          □   沒有人加班——目前

跟第一、二部不同，「人」那格暫時是空的，跟昨天一樣：帳單還在路上。

但看清楚 Risk 那格正在發生什麼。每一天的「進度」，都建立在三組沒被檢驗、也沒被寫下來的假設上：前端假設後端會回什麼、後端假設金流會怎麼表現、三個人各自假設交界的地帶歸別人管。程式碼每天在長，假設每天被寫得更深。假設彼此不相容的機率沒有變，但修正它的成本，每一天都在漲。

風險這種債的特性是：計息的時候無聲無息，催收的時候一次全到。

如果沒有大神，應該留下什麼

不是恢復動工前的審查會議，也不是把三方對齊變成常設儀式。只需要一個最小的門檻：任何一張卡開工之前，認領的人寫得出三行。

1. 問題定義過
   （這張卡要解決的問題是什麼——說得出問題，而不是只說得出功能名稱）

2. 完成有判準
   （做完的那天，拿什麼判斷它真的完成）

3. 依賴先點名
   （這張卡跟誰有交界？對方知道嗎？）

寫得出來，先做再說完全沒有問題——這時候的「先做」，才是 Day 03 那種先做。寫不出來，先補這三行再動工。補的過程通常不到半小時，而且常常會發現：需要的不是寫字，是去問一個沒有人問過的問題。

今日 Artifact｜Definition of Ready 最小版

□ 問題定義過：這張卡要解決的問題是＿＿＿＿
□ 完成有判準：做完時，用＿＿＿＿判斷它真的完成
□ 依賴先點名：這張卡與＿＿＿＿有交界，對方已知情

三格都填得出來，這張卡才叫 Ready；填不出來還硬要動工，那不叫敏捷，叫先欠著。

今日一句

開工不等於開始解決問題；動工的安心感是最貴的安慰劑——它讓所有人停止追問，債卻照常計息。

又過了幾天，三條線陸續回報完工：前端好了，後端好了，金流串接好了。整合日訂在下週。

三個「完成」加起來，會等於一個能用的退款功能嗎？

明天，整合日。大家都完成了——為什麼整套系統不能用？