Agile 🏈 聊聊增量，PM：需求要擠牙膏地說還是一次全講完？
後設資料
- URL：https://medium.com/%E7%A8%8B%E5%BC%8F%E7%8C%BF%E5%90%83%E9%A6%99%E8%95%89/agile-%E8%81%8A%E8%81%8A%E5%A2%9E%E9%87%8F-pm-%E9%9C%80%E6%B1%82%E8%A6%81%E6%93%A0%E7%89%99%E8%86%8F%E5%9C%B0%E8%AA%AA%E9%82%84%E6%98%AF%E4%B8%80%E6%AC%A1%E5%85%A8%E8%AC%9B%E5%AE%8C-6b65c24afbfb
- 作者：Jayden Lin
- Publication：程式猿吃香蕉
- 發表日：2022-10-18
- 閱讀時間：8 min read
- 語言：繁體中文
- 擷取方式：Medium 頁面以 Codex web / Jina Reader 查核；原文正文保存於下方。
一句話濃縮
這篇文章用 敏捷增量 回答 PM 與工程師常見的需求溝通衝突：PM 不必一次補完所有細節，但必須先拉出大流程與里程碑，並針對工程不安全感補足關鍵細節；如果團隊仍無法把增量做小，問題往往不只在需求，而在開發環境、程式碼品質、測試、任務切換成本 與緩衝時間。
提取要點
- 文章起點是一位 PM 的困境：她想依敏捷精神增量規劃，但工程師希望一次知道所有需求；一旦她全講完，工程師又說全部都要做，工期變成好幾個月。
- Jayden Lin 引 Ron Jeffries 的定義說明：increment 是一段固定間隔後產出的 integrated、running、tested software，也就是可用的軟體，不是 backlog 裡的一條微觀項目。
- 增量是一次迭代後團隊共同產出的可釋出軟體，因此增量範圍必須是團隊共識；工程師的不安全感不是阻礙，而是需要被解決的資訊缺口。
- PM 不需要一開始就把細節全部補完；更合適的做法是先用 User Story Mapping、Event Storming 等方法拉出大流程 / 里程碑，再針對團隊疑慮逐步補細節。
- 「增量規劃」不是擠牙膏式不給資訊；而是先保留高層脈絡，再把細節投到最有不確定性、最會影響架構與估時的位置。
- 如果工程師說「全部都要做，沒辦法拆」，PM 除了反省需求怎麼開，更要檢查工程實踐是否足以支撐增量交付。
- 可檢查的工程實踐包含開發 / 測試部署環境、共用函式庫 / 元件、老舊系統封裝、程式碼品質與自動化測試。
- 測試若無效或難維護，團隊不敢釋出；靠人工測試則速度快不起來，增量交付自然只能停留在口號。
- 任務切換與臨時插件會拉長開發週期；PM 可以盤點工程師是否同時兼太多案子，或是否因業務端常插單而必須預留緩衝。
- 真正的敏捷不是宣稱兩週一個 sprint，而是把需求共識與工程實踐一起改善，讓三個月一次交付逐步降成一個月、再降成兩週一次可用軟體。
提取概念
連結到此來源衍生 / 更新的 wiki 頁：
新建頁
- 敏捷增量 — 一段迭代後可整合、可運行、已測試、可釋出的軟體；是團隊共識與工程實踐的共同產物。
- MOC-產品管理 — 本次消化觀察清單候選；產品管理 cluster 已累積 PM 職能、生命週期、需求拆分、優先級、文檔、指標與敏捷交付軸。
- Jayden-Lin — 本次由直接作者來源觸發升格；補足 程式猿吃香蕉 的 Jayden / PM 工程協作來源線。
更新 / 對位頁
- 拆分需求 — 補入「大流程先共識、細節按疑慮補」的需求溝通層；不是一次講完，也不是任意擠牙膏。
- 產品經理 — 補入 PM 在敏捷交付中也要檢視工程實踐：開發環境、程式碼品質、測試、任務切換與緩衝。
- 產品管理生命週期 — 補入 delivery 階段的增量成熟度：Scrum / sprint 只有在可用軟體能短週期釋出時才成立。
- 完成的定義 — 補入增量和 DoD 的關係：增量要 integrated / running / tested，DoD 是每個可納入增量項目的內部共識清單。
- 任務切換成本 — 補入工程團隊多案並行與臨時插件導致緩衝時間膨脹的 delivery 成本。
- 程式猿吃香蕉 — 補入 Jayden Lin Agile / PM 工程協作來源軸。
- MOC-UX — 維持產品需求文件與 UX discovery 的鄰接關係；本次主責 MOC 轉由 MOC-產品管理 承接。
不建頁 / 先觀察
- User Story Mapping、Event Storming、Ron Jeffries increment 定義、Scrum Guide、Jayden Lin 其他 Agile 系列文：本次先列入 觀察清單 的 敏捷增量與需求探索引用來源叢集，等待一手或專門來源再拆頁。
- Scrum / Sprint：既有頁面多處提及，但本篇只作流程背景；暫不獨立建頁。
Ingest 筆記
2026-05-07
本來源是 Medium 文章。Codex web / Jina Reader 查核 metadata：標題為「Agile 🏈 聊聊增量，PM：需求要擠牙膏地說還是一次全講完？」；作者 Jayden-Lin；publication 程式猿吃香蕉；發布時間 2022-10-18；Medium 顯示 8 min read。
建頁判斷：
- 新建 敏捷增量：文章主題不是一般「拆需求」，而是把 increment 定義成 integrated / running / tested working software，並連到工程實踐成熟度。這剛好補上既有 拆分需求、完成的定義、產品管理生命週期 之間缺少的「敏捷交付顆粒」頁。
- 新建 MOC-產品管理：觀察清單 先前已標示產品管理 cluster 名義來源 6+、概念 11+，但待 1-2 份 PM-first 獨立來源。本篇是 PM × 工程交付的獨立來源，補足 lifecycle / discovery / prioritization 之外的 delivery 實踐，因此消化 MOC 候選。
- 新建 Jayden-Lin：觀察清單已有 Jayden Lin entity 候選，觸發條件是個人來源 / 演講主題來源。本篇是 Jayden 直接作者來源，且文中與 Medium 作者 bio 提供足夠穩定 metadata；同時可連回既有 程式猿吃香蕉 publication 與 2026-05-01-盈秀-拆分需求 的 MOPCON 間接提及。
- 不拆 User Story Mapping / Event Storming：文章只用它們說明「大流程先拉出，細節按需補」的共同精神，未展開操作步驟；先放入觀察清單待一手來源或專門教學再拆頁。
觀察清單同步：
- 本期消化觀察清單：MOC-產品管理、Jayden-Lin。
- 新增 敏捷增量與需求探索引用來源叢集 為待 ingest 外部資源。
元命題：敏捷不是少寫文件或把需求切碎，而是讓團隊能以可用軟體作為共同進度單位；當增量做不小時，PM 要看見的不只是「需求沒講清楚」，也包括工程實踐、測試、切換成本與緩衝時間是否支撐得起真正的短週期交付。
原文
> 筆者曾任職 Yahoo，現在區塊鏈產業打滾，《軟體需求溝通 ─ 從外商公司學跨部門協作開發》線上課程講師，紛絲團《程式猿吃香蕉🍌》
前幾天到高雄參加 MOPCON 主講敏捷開發的主題《PM 說我全都要！工程師自救的 7 種拆分需求技巧》，在會後和社群的朋友有很多有趣的討論。當時和我聊天的是一位 PM ，她提到的情境是這樣的：
> 『 敏捷開發講求增量 (Increment)和迭代，所以開需求的時候我會先規劃一部分，但工程師卻希望我一次把所有需求講完。 』
在向她確認所開的需求都是 End to End 的形式之後，她又提到：
> 『 可是，當我把全部需求跟工程師講完，對方又說要做好幾個月。』
>
> 『 工程師要全部一次做？』
>
> 『 對，工程師說全部都要做，沒辦法拆。』
這情況讓她有些苦惱。聽完她的描述，我覺得有兩個地方可以討論，也因為這個題目實在很有趣，因此決定將當時我與她交流的內容一併記錄下來。
## ▍工程師的不安全感？談談增量是什麼？
> At regular intervals, preferably every week or two, the developers provide an integrated, running, tested version of the software, the “Increment”, containing all the features and capabilities which have been completed so far in the project.
>
> — Ron Jeffries
上述是敏捷開發大師 Ron Jeffries 對增量的定義，他談到「增量」是工程師在某時間區間後 (regular intervals) 所產生的軟體，並且是已整合的 (integrated)、可運行的 (running) 、已測試的 (tested) 軟體，以專有名詞來說：
> 增量就是一個「可用的軟體」 (Working Software)
上圖是敏捷開發中常用的 Scrum 的開發流程，增量它不是微觀上在產品清單 (Product Backlog) 裡的一個條目，而是應該宏觀地看，增量是在一次迭代後，可以釋出的軟體。又因為增量是在整個迭代過程後大家的最終產物，因此：
> 增量所涉及的範圍，必須要是團隊的共識。
了解增量的定義後，回到最開始的問題：PM 想要增量地規劃，但工程師希望把所有需求全講完。以過往的經驗來說，工程師會希望把需求講完整，通常是因為不安全感，擔心架構規劃沒有考慮周全。
> 因為增量必須是團隊的共識，工程師身為團隊的一員，他們的不安全感是需要被解決的。
那麼需求要全部一次講完嗎？
在敏捷開發中，有很多方法論可以協助我們釐清需求，例如：使用者故事對照 (User Story Mapping) 或是事件風暴 (Evenet Storming) 等等。這些方法在概念上來說，都是先把大流程或要完成的里程碑拉出來，細節「有必要時」再陸續補充進去。
舉例，下圖是使用者故事對照的模板，上方的使用者活動 (User Activity) 是粗略的大流程和里程碑，下方的使用者故事 (User Story) 是內容細節。在實作時先完成上半部在補充下半部。
事件風暴也是類似的概念，先把要發生的「事件」定位出來，再根據需要補上細節。
特別要注意的是，以上兩個方法在使用的時候：
> PM 對細節不用一次全部補完，只要針對團隊 (工程師等等) 有疑慮的地方補上細節即可。
這樣做就可以消弭工程師的不安全感，也能讓工程師做出更好的設計。
其實我們生活中做很多事情也是這樣的。舉個生活化的例子，假設我們規劃要去高雄玩，一開始只會把大流程或要完成的里程碑拉出來，例如要去駁二、逛瑞豐夜市、吃丹丹漢堡等等里程碑。如果對怎麼到達駁二或是怎麼逛駁二才有效率，有很多「不安全感」，可以針對這部分補上細節即可。
在解決增量的問題之後，我們來看看工程師提到需要「全部做」的問題。
## ▍工程師：我要打全部！但要花三個月
其實敏捷開發很常被人忽略的地方是：
> 要實現增量 Increment，需要紮實的技術實踐。
前面有提到，增量是一次軟體釋出，並且要做到已整合的 (integrated)、可運行的 (running) 、已測試的 (tested) 。這容易嗎？
因此我跟那位 PM 聊到：
> 除了糾結自己需求怎麼開之外，更應該去檢視工程師目前的工程實踐。
有以下幾點可以做：
### ❶ 開發環境 & 程式碼品質
- 目前可供測試部署的機器足夠嗎？工程師從「開發」到「驗證」的週期是不是太久？導致需求要做很久？如果是，PM 可以幫忙爭取資源。
- 要做的功能有現有的函式庫或元件可以套用嗎？如果沒有，需要建立共用函式庫等機制，才能讓下次開發更快速。
- 程式碼的品質怎麼樣？是不是有很老舊的系統，每次改每次痛？如果有，PM 需要安排時間讓工程師做封裝。
### ❷ 測試
- 目前工程師團隊有沒有寫自動化測試？
- 能不能寫出有效的、可維護的測試？如果不能，在無效的測試下，你也不敢釋出，另外，難維護的測試只會把程式碼搞得更複雜，增加維護成本。靠人工測，速度又快不起來了。
### ❸ 工作切換 Task Switching & 緩衝時間
- 盤點工程師目前手上的任務，是不是資源分配出了問題，同時兼很多案子？導致工作切換的開銷過大，因此開發時間較久？
- 業務端時常有臨時插件嗎？是不是因為常有插件，所以工程師想要預留緩衝時間？
這些議題都是 PM 可以建議或幫忙釐清的，這些問題都一一解決後，才能讓開發時間從一次迭代三個月降到一個月，最後做到兩週一次釋出，達到真正的敏捷。
## ▍後記
在技術社群裡，面對面的交流往往是最有趣的部分，如果你也對敏捷開發有興趣，可以閱讀我先前寫的其他文章或是訂閱我，在軟體開發的路上，一起交流，一起成長。