Scrum 敏捷開發實戰：AI coding 時代的新做法

2026 年線下課程第二梯次
開課時間: 8 月 29 日(星期六) 09:00-17:00
報名網址: https://forms.gle/D1M8mtSrUpi7xf5x6

課程說明

AI coding 讓「寫程式」變快了，但交付並沒有跟著變快。程式碼寫完了，卻卡在審查、驗證、整合，Sprint 結束時一堆「技術上寫完、實際上沒 Done」的工作。當寫程式不再是價值流上最貴的一段，團隊的瓶頸、估算的那把尺、甚至角色的價值主張，全都在改變。傳統瀑布式開發無法因應快速變遷，而市佔率最高的 Scrum 敏捷方法，也必須用新的方式來實踐。

雖然如此，但在你學習或實踐 Scrum 的過程，是否對以下狀況感到困惑：

人家說用 Scrum 會比較快？真的有嗎？
書上都只是講解流程，並沒有實際實作的細節
需求要怎麼拆解，才能夠在迭代中完成？AI 時代切故事的標準還一樣嗎？
怎麼每個講師講的 Scrum 做法都不同，到底要聽誰的？
如果過程遇到很多隕石，Scrum 要如何處理
AI 幫忙寫程式之後，故事點還準嗎？Velocity 還能拿來規劃嗎？
AI agent 說「做完了」，算不算數？它的產出誰要掛名負責？
程式生得快、審查跟不上，code review 變成新瓶頸，該怎麼辦？

這門課，不只是教你「Scrum 是什麼」，而是告訴你「在 AI 時代怎麼真的把 Scrum 做起來」。

我們不是照書講課、不是拿 PMP 外皮來賣敏捷，而是用大量來自真實企業導入實戰經驗的案例，加上 2026 年最新的業界數據（如 Acceleration Whiplash 研究），帶你避開那些「看起來像敏捷、實際只是換流程名稱」的假象。

你將會學到：

✅ 為什麼 Scrum 真正的威力，不在流程，而在思維 — 從受害者思維走向成長思維

✅ 如何拆解需求，讓每個 Sprint 都有可交付成果 — 以及 AI 時代切story的修正與新 pattern

✅ 團隊怎麼一起估算工作量 — 以及當 AI 把估算弄壞後，業界的應對做法

✅ PO、SM 在 AI 時代的新挑戰與新定位 — 在每個會議各自要盯什麼

✅ AI agent 進入團隊後的關鍵問題 — 產出歸屬、Done 的認定、權限邊界、junior 的養成

✅ 重新設計「做完的定義」(DoD)，讓 AI 產出的程式碼不再是未爆彈

✅ Code Review 太久要如何找出系統性對策

上課花絮

課程特色

動手操作: 課程中約一半時間需要學員動手操作, 或是進行分組討論
圖像記憶: 大量利用手繪圖像來輔助記憶, 讓讓學員能加速學習印象
引導思考: 引導學員討論自己的觀點, 進而達成共識和經驗交流, 而非直接給答案
業界案例: 大量的業界實施經驗分享, 讓你不只了解理論, 還能知道業界狀態

適合對象

Scrum Master、PM、Tech Lead，想讓團隊脫離「偽敏捷」的泥沼
想搞懂Scrum 背後真正設計邏輯的人
軟體開發新手，想掌握團隊合作的節奏
在 AI coding 時代，想重新定位自己角色的開發者
任何對 Scrum 開發方法有興趣的人

課程大綱

主題	你會做什麼	AI 時代有什麼不同
敏捷觀念與思維	• 理解敏捷的由來、宣言，以及和傳統專案管理的差異 • 討論練習：寫下受害者 / 知者會說的話，檢視自己團隊的思維慣性	• 敏捷的本質沒變 — 但當需求和技術變動更快，為什麼經驗性流程控制反而更重要
Scrum 框架與角色	• 認識 PO / SM / Team 三個角色的職責與團隊組成 • 釐清直屬主管該做什麼、哪些行為會踩雷 • 小組討論：SM 在 AI coding 時代可以幫上什麼	• PO 的新挑戰（PBI 把關、排序、價值驗證跟不上生成速度） • SM 在各個會議的新關注點 • AI agent 算不算團隊成員：產出誰掛名、說「做完了」算不算數、能碰什麼、junior 的練習場會不會消失
如何組織需求	• User Story • User Story Mapping • Story 拆解 • 實際案例練習（高鐵訂票系統）：親手列出 user story、動手拆解、整理 user story mapping、寫出驗收條件	• 切故事的標準換了：依業務規則切成為核心、 Spike 變成 AI Probe、依驗證階梯切、先影子後切換
任務評估	• Playing Poker • Story vs Velocity • 實際估算練習：用 Playing Poker 和故事點，對真實故事排出相對大小、估出時程	• AI 把如何把估算弄壞了：基準飄移、Velocity 失真 • 業界應對方法：重新校準、#NoEstimates、只估人要花的時間、量測等待、改看流動指標
做完的定義 (DoD)	• DoD 定義	• AI 產出不穩定，帶來 DoD 的新麻煩 • 業界做法：用四層結構重新設計 DoD，讓 AI 寫的程式不再是未爆彈
Scrum 會議	• Sprint Planning • Daily Scrum • Sprint Review • Sprint Retrospective • Product Backlog Refinement • 分組演練：Sprint Planning 完整走一遍 • 燃盡圖判讀練習	• 要不要拆 Task 的考量變了 • Daily Scrum 的狀態回報會被 dashboard 取代嗎 • Code Review 太久要如何處理：小批量、三層審查管線、Ship/Show/Ask 與 12 週導入計劃

上課時數

一天課程, 共 7 小時. (上午九點到下午五點, 中間休息一小時)