👉 不要靠加人解決問題，更不是有 AI 就天下無敵，要靠限制讓流程更順暢。

貝老闆（手裡拿手機一臉著急）：「小可小可！政府案子剛改需求，馬上要加一個報表，還要跟之前的 API 串起來，這禮拜就要交！」

小可（右手拿摺扇、滿臉憔悴）：「老闆，上禮拜你才說要做上線典禮的頁面，現在又要插單？我們任務都塞不進去了啦！」

工程師 King（眼神死盯著看板）：「現在板上 12 張卡都在進行中，誰要先做誰要後做？沒人講清楚。」

AI 實習生（舉著小手）：「我全部都完成了，等人 Review 和測試!？」

小可（敲貝老闆頭）：「不是 人多 + AI 就快，現在流程才是卡住的根本！」

貝老闆：「那怎麼辦？Scrum 還是 Kanban？我只知道 Scrum 要每天站會，Kanban 好像是貼便利貼？」

電話另一端好威（冷笑）：「你不都隕石流，你有聽過 Scrumban。不然光開會就卡死了！」

踩坑情境

公司接到臨時需求，貝老闆以為「人多 + AI 就能加快」能補救一切，結果任務全都同時進行，沒有優先順序，大家疲於奔命，AI 雖然產的快，也是需要有人 Review 和測試，避免出錯。
Scrum 的節奏讓臨時需求難以插入，Kanban 又缺乏週期檢視，團隊就像一條被塞滿的水管，什麼都在「進行中」，卻什麼也出不來。

好威科普

• Scrum 適合有明確週期（Sprint）的任務，像蓋房子要先設計再施工，有節拍。
• Kanban 像便利商店補貨，看哪個貨架缺就補，不一定要等下個 Sprint。
• Scrumban 就是混合流派：保留 Scrum 的週會節奏，但用 Kanban 的可視化與 WIP 限制來防塞車。

「說白話啦，你們現在就是『進行中的東西太多』。看板上設 WIP 限制（同時進行數量上限），讓流程像水管一樣，保持流動，不會全塞住。」

概念拆解

1. Scrumban：取長補短

• Scrum 提供節奏，適合專案有「版本節拍」；Kanban 提供彈性，適合應付插單需求。
• Scrumban 的精神就是「穩定節奏下的彈性應變」。例如：保持兩週一次的檢視週會，但日常任務流動用看板管理。
• 跟 AI 協作時，你可以要求 AI 幫忙生成「任務看板的自動分類」：哪些是 Feature、Bug、Hotfix，並標出「預估時間」。AI 幫你先過一輪分類，團隊再確認。

2. WIP 限制：限制就是加速

• 傳產老闆常覺得「人越多、同時做越多就越快」，但實際上這會導致 Context Switching，大家效率下降。
• 設定 WIP 限制，例如「開發中最多 3 張卡」，確保大家專注完成再拉新任務。
• 如果不懂怎麼問 AI，可以直接問：「幫我分析目前看板，每個人同時進行幾張卡？給我圖表顯示。」AI 能把隱藏的塞車點挖出來。

3. 緊急泳道（Emergency Lane）

• 真正的 Hotfix 需求不能等到 Sprint 結束，這時候就開「緊急泳道」處理，讓它不擠壓正常開發。
• 就像高速公路上救護車專用道，確保緊急狀況處理時不會整條路癱瘓。
• 你可以叫 AI 幫你「自動標記高優先需求，丟到 Emergency Lane」，讓團隊不用每天吵「誰的比較急」。

4. Flow 效率 vs 人數

• 人多不一定快，因為溝通成本上升。
• 真正要看的指標是 Cycle Time（單張卡完成時間） 和 Throughput（週完成數量），這才是交付速度。
• 問 AI 的時候，可以下 prompt：「請幫我分析 Cycle Time 趨勢，判斷這兩週交付效率是否變快。」讓 AI 做數據佐證，不再靠感覺爭辯。

Takeaways

1. 人多不等於快，流暢才是快

• 把流程想像水管，不要一次把所有水都倒進去。
• 給 AI 一份看板數據，請它幫忙標記「卡在哪裡」，你會比靠感覺快得多。

2. Scrumban：穩定節奏 + 彈性應變

• 保留 Scrum 的週期檢視，確保團隊有檢討與計畫。
• 用 Kanban 的 WIP 限制與看板可視化，避免工作無限堆積。

3. 用數據說話，不用嘴巴爭辯

• Flow 效率靠 Cycle Time 與 Throughput 衡量。
• 不懂數據怎麼跑？問 AI：「幫我算過去三週的 Cycle Time 平均值，畫出趨勢圖。」

今日提問

你們團隊目前的「進行中」項目有幾個？

下次試著問 AI：
「幫我分析目前任務數量，推薦一個合理的 WIP 限制。」