AI時代下的敏捷開發

核心觀念

快一點 != 敏捷

快一點：把事情「順暢地做完」
敏捷：在不確定性中持續調整方向並創造價值

👉 AI 時代的特點：

不確定性大幅提升（需求、技術、解法都不穩定）
因此「計畫式開發」效果下降，「假設驅動」變得更重要

為什麼需要敏捷？

世界沒有完美解法
所有決策都是在「不完整資訊」下做的
AI 讓變動更快 → 不確定性更高

👉 結論：

敏捷 = 管理不確定性的能力

假設思維（Hypothesis Driven Development, HDD）

核心概念

不追求一次做對
先建立「假設」，再透過驗證修正

為什麼重要？

面對不確定性最有效的方法
降低試錯成本
聚焦真正有價值的事情

實務流程

建立假設
設計驗證方法
收集數據
做出決策（採用 / 修正 / 放棄）

四大原則（補完）

開發節奏（Flow）
- 持續、小步前進
- 避免長時間無回饋
假設思維
- 所有需求都是假設
- 驗證比實作更重要
團隊共治
- 不是單一角色決策（PO / Dev / QA）
- 團隊共同對成果負責
快速回饋（補充）
- 越早知道錯誤越好
- 減少後期成本

AI 協作守則

1. 永遠邀請 AI 入局

用於：
- 釐清問題
- 蒐集資料
- 發想解法

2. 成為「人在回路中的那個人」（Human-in-the-loop）

👉 核心：AI 負責產出，人負責判斷

(1) 語言標準化

使用結構化 Prompt
降低溝通成本

(2) 判斷力（Critical Thinking）

重點不是「怎麼寫」
而是「寫的對不對」

👉 方法：

透過 Log / Observability
用結果反推問題（而非人工 code review）

(3) 責任釐清

誰對錯誤負責？
BDD 規格 = 契約

(4) Spec Coding

用結構化方式描述需求
AI 根據 Spec 產出程式

3. 設定 AI 角色

明確告訴 AI：
- 是什麼角色（例如：資深工程師、產品經理）
- 負責什麼任務

4. 假設 AI 很爛

不信任輸出
強化驗證機制
建立 fallback

Flow → AI-Augmented 開發模式

心流（Flow）條件

能力（Skill） vs 挑戰（Challenge）平衡

狀態	說明
焦慮	挑戰 > 能力
無聊	能力 > 挑戰
心流	剛好匹配

如何進入 AI 時代的心流？

認知轉移
- 從「語法」→「系統設計」
- AI 負責細節，人負責架構
即時回饋
- 快速測試
- 快速驗證
半人馬模式（Human + AI）
- AI 加速產出
- 人維持節奏與方向
- 避免中斷 Flow

AI 時代的 Debug 方法

Debug 流程（補完）

Prompt（輸入）
Debug（HDD 思維）
觀測 Log（保留完整資訊）
Decision
- 採用
- 修正
- 放棄
Knowledge Base（知識資產化）
Re-Prompt（再次優化）

👉 目的：

減少 AI 幻覺
建立可復用經驗

Sprint 設計（OKR 導向）

Objective

本 Sprint 最重要的價值是什麼？

Key Results（可量化）

0.3：基本完成
0.5：努力可達
0.7：具挑戰
1.0：突破性成果

Planned Work

預計工作項目

Risk / Challenge

可能遇到的問題
- 例如：Legacy code 太亂

Support Needed

需要的支援（主管 / 團隊）

激勵（補充）

成功後的最大收穫是什麼？

假設思維在 Agile 中的實踐

原則

每個 User Story 都要有假設
沒有假設 → 不進 PBI
小增量 + 多迭代 + 快速回饋

假設的好處

避免資訊過載
提升決策效率
聚焦真正重要的問題

空・雨・傘（決策模型）

空（事實）

只觀察，不解釋
例：
- 天空有烏雲
- 營收下滑

雨（解釋）

最可能原因
例：
- 可能會下雨
- 轉換率下降

傘（行動）

對應策略
例：
- 帶傘
- 優化轉換流程

User Story 的本質

Story = 一個「待驗證的假設」
真正的驗證來自：
- 真實使用者（User Feedback）

迷霧法則（Fog Rule）

當腦中出現解法： 👉 立刻停下來記錄
避免：
- 靈感消失
- 回到錯誤方向

如何撰寫假設（模板）

我們相信「某個改變」
對「某個對象」
會造成「可觀察的效果」
因為「某個洞察」

範例

我們相信「優化登入流程」
對「新使用者」
會提升「註冊完成率」
因為「目前流程過於複雜」

練習題（補完）

如何縮短與 AI 來回溝通時間？

👉 方法：結構化 Prompt

範例結構

目標（Goal）
背景（Context）
限制（Constraints）
輸出格式（Format）
評估標準（Criteria）

範例 Prompt

你是一位資深後端工程師

目標：
優化 API 效能

背景：
目前 response time 約 800ms

限制：
不可改 DB schema

輸出：
- 問題分析
- 可行方案（3個）
- 建議優先順序

評估標準：
效能提升幅度 + 實作成本

總結

👉 AI 時代的敏捷本質：

不追求完美 → 追求可驗證
不依賴經驗 → 依賴假設
不怕錯誤 → 快速修正
人不是寫 code → 是做決策，專注在提升【判斷力】

👉 最重要的能力：

在不確定性中做出高品質決策的能力