(此圖由 AI 生成)

今天來看常被搞混的敏捷、迭代與增量。

迭代式開發

重複進行多次迭代：每次迭代都進行需求分析、設計、實施和測試，逐步改進產品。

交付

不一定每次都交付完整可用的產品，但會有一個可評估的版本或功能原型。重點在逐步完善和改進產品，每次迭代後不一定能交付可用的產品，但每次都會更接近可用。

例子

以腳踏車的組裝，初始階段交付的是輪子，隨著進展，逐步交付加裝車架、鏈條、齒輪、坐墊等版本，最終到所有零件裝到一起，最終才形成一個可用的完整腳踏車。

增量式開發

交付

分階段交付。每次交付一部分完整可用的產品，逐步增加功能和改進。重點在每次增量交付的部分都是完整且可用的功能。

例子

以交通工具的升級為例，初始交付的是腳踏車，之後逐步增量交付變成電動腳踏車、125cc機車、最終交付一台哈雷機車。每個階段交付的產品都是可以獨立使用的。

敏捷開發

• 結合迭代和增量：每次迭代都交付可用的產品增量，並基於回饋進行持續改進
• 靈活和適應性強：強調快速響應變化，允許在開發過程中靈活調整需求和計劃。
• 持續回饋和改進：每次迭代結束後進行反思和改進，通過持續的客戶回饋來調整和改進產品。

例子

在軟體開發中，以兩週為一個週期來開發一個全新的APP，

在第一版 v1 的 MVP 最小可行性產品問世前，每次交付功能都增加一點，並且團隊隨著商業市場和需求方不斷調整功能。從 v0.1 → v0.2 → v0.3 → v0.xx → v1。

例如，v0.1 可能只有 UI、v0.2 可能只有某幾個頁面、v0.3 因為後端 API 好了加入商業邏輯…etc，之前的 0.xx 版不一定可以使用，但到了 v1 前後端都接上，是一個可用的最小可行性的 APP 產品了。

接著，上市後繼續更新產品，從 v1 → v2 → v3 不斷更新與追加功能，每次改版都是能用的版本。在 v1 之前的交付偏向迭代，在 v1 之後的交付偏向增量。

表格比較差異

再一次我會怎麼建議？

標題的「再一次我會怎麼建議」源自于我對公司某次 retro 會議的反應，該 retro 會議也是刺激我學習 PMP 的原因之一，先感謝部門同事們都是偏向價值取向，而不是形式主義，所以我才能反覆思考，再一次我會怎麼建議。(求生慾旺盛)

不少混合制公司標榜敏捷，但其實是小(功能)專案走敏捷、大(功能)專案變瀑布流，這很微妙，進入開發前花了公司 4/5 的時間在那邊討論，只留給開發團隊 1/5 時間，好像很合理，可你要說最後開發團隊 1/5 時間的規格很完整嗎？啊也沒有，規格也會變動。

也就是變成走瀑布式的事前需求斡旋與釐清 -> 設計 -> 開發 -> 測試 → 上線，可是 Deadline 又被部門主管或 PM Lead 先喊死，導致只要開發團隊一說啊因為怎麼了所以開發時間要增加，會導致測試時間被壓縮，QA 就要在剩的時間極限測試。

我們寫 JavaScript 和 TypeScript 並不代表我們人也真的是單執行序要同步一行一行執行。如果新功能開發周期能提早進入開發階段，我們可以用敏捷 (或者說..著重在其中的「迭代式開發」)，RD 可以隱藏新產品功能的路口，只要 Web 或 APP 不廣撒對外的正式路口，可以包在當前版本先上到 Prod 正式環境，例如 UI 刻好也 UI Review 沒問題，那直接 release 發佈到正式環境。

對，上線一個不能用的功能服務，但是前端只要路口隱藏好根本不用擔心一般使用者會碰到。若時光倒流再讓我回到當時，我會這麼建議：先側重迭代式開發，頻繁交付，先上一個不能用的功能也沒關係，後續不斷迭代至可用。

結語

希望今天的內容能幫助大家了解這三者差異，最後有一點要說，我在寫全真題時遇過，題目若出現迭代兩個中文字，答案不一定就是迭代式，千萬要小心陷阱。