敏捷開發是什麼？Scrum、Kanban 怎麼選與 Sprint 實戰指南

「這個專案說好三個月，現在第七個月了，還是沒有東西可以給客戶看。」這是很多老闆對研發部門最深的不安。工程師也有委屈：需求一直改、插件不斷、每個人同時掛五個專案，最後每件事都做一半。問題常常不在人，而在工作方式：一次把一年的規格寫完、最後才整合測試，任何一個假設錯了，都要到最後才發現。

敏捷開發要解決的，就是這種「做很久才知道做錯」的風險。本文從管理者角度說明敏捷開發的核心精神、Scrum 與 Kanban 怎麼選、Sprint 的實際運作節奏、軟硬體與製造業如何調整，以及老闆該看哪些指標，幫你判斷敏捷開發是否適合自己的團隊、又該從哪裡開始。

敏捷開發是什麼？為什麼傳統瀑布式開發越來越吃力？

敏捷開發（Agile Development）不是單一方法，而是一組價值觀與原則的總稱。2001 年，十七位軟體開發者發表《敏捷軟體開發宣言》，提出四項價值：

• 個人與互動 重於 流程與工具
• 可用的軟體 重於 詳盡的文件
• 與客戶合作 重於 合約協商
• 回應變化 重於 遵循計劃

宣言特別說明：右側項目仍有價值，但更重視左側項目。換句話說，敏捷不是「不寫文件、不做計畫」，而是當兩者衝突時，優先選擇能更快產生價值、更快取得回饋的那一邊。

傳統的瀑布式開發依序走過需求、設計、開發、測試、上線，每一階段完成才進入下一階段。在需求穩定、技術成熟的情況下，瀑布式非常有效率；但當市場變化快、客戶自己也說不清楚要什麼時，瀑布式的風險就是所有問題都堆到最後才爆發。

實務上，很多企業不是二選一，而是在整體專案用階段關卡管控投資決策，在每個階段內用敏捷方式執行。這種混合做法對有硬體、模具或認證的產品特別重要，後文會再說明。

Scrum 是什麼？角色、事件與產出物一次看懂

Scrum 是最廣為採用的敏捷框架之一。依 2020 年版《Scrum 指南》（The Scrum Guide），Scrum 團隊通常不超過 10 人，由三種當責組成，透過固定的事件節奏產出三種產出物。

三種當責（角色）

• 產品負責人（Product Owner）：對產品價值負責，管理產品待辦清單、決定優先順序。一個產品只能有一位產品負責人，不能是一個委員會。
• Scrum Master：對團隊的 Scrum 實踐成效負責，協助排除障礙、引導事件、教練團隊，不是傳統的專案經理或監工。
• 開發者（Developers）：每個 Sprint 負責產出可用增量的人，不限於寫程式，也包含設計、測試、機構、電子等專業。

五個事件與時間盒

Sprint 較短時，各會議的時間通常也會相應縮短。

三種產出物與承諾

• 產品待辦清單（Product Backlog）：對應的承諾是「產品目標」，說明產品長期要達成什麼。
• Sprint 待辦清單（Sprint Backlog）：對應的承諾是「Sprint 目標」，說明這個 Sprint 為什麼值得做。
• 增量（Increment）：對應的承諾是「完成定義（Definition of Done）」，明確規定什麼狀態才算真正完成。

Scrum 指南也提出五項價值：承諾、專注、開放、尊重、勇氣。很多團隊只學會開會形式，卻忽略這五項價值，最後變成「每天站著報告進度給主管聽」，這就失去了 Scrum 的意義。

Kanban 看板怎麼用？什麼團隊比較適合？

Kanban 源自精實生產中的看板拉式系統，被引入知識工作後，成為管理工作流程的方法。依 Kanban 指南的說明，Kanban 由三項實踐組成：定義並視覺化工作流程、主動管理流程中的工作項目、持續改善流動。

Kanban 的三個關鍵做法

1. 視覺化：把工作從開始到完成的每個階段畫成看板欄位，例如「待處理、分析中、開發中、測試中、完成」，每張卡片代表一個工作項目。
2. 限制在製品（WIP）：每個欄位設定同時進行的上限。例如測試中最多 3 件，超過就不能再往裡放，必須先把手上的做完。這是 Kanban 最重要、也最常被忽略的規則。
3. 管理流動：追蹤每張卡片停留多久、每週完成多少件，找出卡住的瓶頸並改善。

Kanban 的基本流動指標

• 在製品數（WIP）：已開始但尚未完成的工作項目數量。
• 產出量（Throughput）：單位時間內完成的工作項目數量。
• 週期時間（Cycle Time）：工作項目從開始到完成經過的時間。
• 項目年齡（Work Item Age）：尚未完成的工作項目已經開始了多久。

這幾個指標之間有一個常被引用的關係（Little’s Law）：在系統穩定的前提下，平均週期時間 ≒ 平均在製品數 ÷ 平均產出量。假設某研發團隊平均同時有 12 件工作在進行、每週完成 4 件，平均每件需要約 3 週。若要縮短交期，最直接的方法往往不是加班，而是減少同時開工的數量。

Scrum 和 Kanban 怎麼選？敏捷開發框架比較

Scrum 和 Kanban 沒有誰比較高級，差別在於工作的性質。下表可以幫助你初步判斷：

很多團隊最後會走向混合：用 Scrum 的 Sprint 節奏規劃新產品開發，同時用看板管理 Sprint 內的工作流動與 WIP 上限。對同時要做新產品又要支援現有客戶的中小企業研發部門，一個常見做法是保留固定比例的產能給插件，例如每個 Sprint 預留兩成工時，避免計畫天天被打亂。

一個 Sprint 實際怎麼跑？兩週節奏範例

以下以「兩週 Sprint」為例，示範一個中小企業研發團隊可以如何安排。實際長度可以是一到四週，關鍵是固定下來，讓團隊建立節奏感。

第 1 天：Sprint 規劃

產品負責人說明本 Sprint 想達成的目標，例如「讓業務可以帶著可操作的新版報價介面去拜訪兩家客戶」。開發者根據過去幾個 Sprint 的實際完成量，從產品待辦清單挑選項目、拆解成一天以內可完成的任務。規劃會議結束時，團隊要能用一句話說出 Sprint 目標。

第 2～9 天：每日站會與開發

每天固定時間 15 分鐘，開發者圍著看板同步：離 Sprint 目標還有多遠、今天要做什麼、遇到什麼障礙。技術細節討論在站會後由相關的人另外進行，不要讓 15 分鐘變成一小時。

第 10 天上午：Sprint 審查

團隊向老闆、業務、甚至客戶實際展示可運作的成果，而不是簡報。利害關係人提出回饋，產品負責人據此調整待辦清單順序。這是老闆最該出席的會議。

第 10 天下午：Sprint 回顧

團隊檢討這兩週的合作方式：哪些做得好要保留、哪些卡住要改善，並挑一到兩項改善行動放入下一個 Sprint。回顧會議最重要的是心理安全，主管若在場要避免追究個人責任。

完成定義範例

完成定義是團隊對「做完」的共同標準。一個軟體功能的完成定義可能包括：

• 程式碼已經過同儕審查
• 自動化測試通過
• 已部署到測試環境並由產品負責人驗收
• 使用說明已更新

硬體或機構類項目的完成定義則可能是：圖面已審核、樣品已組裝、功能測試紀錄已存檔。完成定義越清楚，「90% 完成」的假象就越少。

硬體與製造業也能用敏捷開發嗎？

敏捷開發最早在軟體業發展，但它的精神：小批量、早回饋、持續改善，與精實生產本是同源。硬體與製造業導入時，需要針對幾個現實限制做調整：

限制一：實體零件有交期

開模、打樣、採購零件可能需要數週，無法在兩週內完成。對策是把「學習」而非「完成品」當作 Sprint 的產出，例如用 3D 列印、手工樣品、模擬分析或開發板驗證關鍵假設，把長交期項目提前排入待辦清單。

限制二：法規認證與安全測試不能省

醫療器材、車用、電器安規等產品，有既定的驗證與文件要求。敏捷不是跳過這些程序，而是讓設計在送驗前就經過更多次內部驗證，降低送驗失敗重來的風險。

限制三：軟硬體與機構要同步

可以讓軟體以兩週 Sprint 運作，硬體以較長的週期運作，但在固定的整合點（例如每兩個 Sprint）進行一次系統整合展示。這需要產品負責人跨團隊協調，也是產品經理最能發揮價值的地方。

和階段關卡、PLM 如何並存

許多製造業已經有新產品開發的階段關卡，用來決定是否繼續投資。敏捷可以在每個階段內運作，讓關卡審查看到的是實際可運作的成果，而不是一份進度報告。工程變更與物料清單的版本控管，則仍需要嚴謹的管理機制，可以延伸閱讀PLM 產品生命週期管理。

老闆該怎麼看敏捷開發的成效？關鍵指標與常見錯誤

導入敏捷開發後，老闆最常犯的錯誤是用舊的指標管新的方法，例如要求每個 Sprint 交出固定數量的功能、或拿團隊之間的速度互相比較。比較好的做法是從價值、流動、品質、團隊四個面向看：

• 價值：每個 Sprint 目標的達成率；客戶或業務在審查會議中的回饋是否被採納進產品。
• 流動：平均週期時間、每週產出量、在製品數，看交期是否越來越可預測。
• 品質：上線或出貨後發現的缺陷數、重工比例。
• 團隊：回顧會議提出的改善行動實際完成率、人員流動率。

Sprint 目標達成率可以用「達成 Sprint 目標的 Sprint 數 ÷ 總 Sprint 數 × 100%」計算。注意這是用來觀察趨勢，不是用來懲罰團隊；一旦指標變成考核工具，團隊就會傾向少承諾、多保留。研發人員的個人績效設計，可以參考研發團隊績效管理與 OKR。

導入敏捷開發的 7 個常見錯誤

1. 只改會議、不改決策方式：每天站會，但需求仍由老闆一句話臨時決定，產品負責人形同虛設。
2. 產品負責人由多人兼任：業務、研發主管、老闆都在下指令，待辦清單沒有唯一的排序者。
3. Sprint 中途一直插件：計畫失去意義。對策是預留插件產能，超過就等下一個 Sprint。
4. 不限制在製品：每個人同時做五件事，什麼都做不完。
5. 沒有完成定義：「做完了，只差測試」成為常態，問題累積到後面爆發。
6. 省略回顧會議：團隊太忙而跳過回顧，等於放棄了持續改善的機會。
7. 期待導入第一個月就變快：導入初期反而會因學習與調整而變慢，通常需要數個 Sprint 才能建立穩定節奏。

中小企業導入敏捷開發的五個步驟

1. 選一個試點團隊與產品：挑一個需求變動大、老闆重視、團隊人數 3～9 人的專案，不要一開始就全公司推行。
2. 指定唯一的產品負責人：需要有權決定優先順序的人，並讓所有需求都透過他進入待辦清單。
3. 建立看板與待辦清單：把現有工作全部列出來、排出優先順序，光是這一步就會讓很多人第一次看見「原來我們同時在做這麼多事」。
4. 固定節奏跑三到五個 Sprint：規劃、站會、審查、回顧都照表操課，期間不要頻繁改規則。
5. 回顧試點成效再擴大：比較試點前後的週期時間、客戶回饋與團隊感受，再決定是否推廣到其他團隊。

如果新產品的方向本身還不明確，建議先用設計思考釐清使用者真正的問題，再交給敏捷團隊開發，避免「很有效率地做出錯的東西」。

用管理王系統落實敏捷開發的待辦、Sprint 與會議紀錄

敏捷開發強調透明與節奏，工具本身不是重點，但一個大家都看得到、都會更新的地方非常關鍵。管理王是一站式企業 AI 管理系統，以下功能可以支援敏捷團隊的日常運作：

• 專案管理與任務管理：每個產品或 Sprint 建立專案，把待辦項目拆成任務、指定負責人與期限，團隊與主管都能即時看到進度，減少「進度報告會議」。
• 排程日曆：把 Sprint 規劃、每日站會、審查與回顧會議固定排入團隊行事曆，維持節奏感，也讓利害關係人提前預留審查會議時間。
• AI 會議記錄：Sprint 審查與回顧會議的回饋、決議與改善行動可由 AI 整理成紀錄，方便產品負責人更新待辦清單，也讓改善行動不會開完會就忘記。
• AI 知識庫：將完成定義、技術決策、回顧會議的經驗整理入庫，新成員加入時能快速了解團隊的工作約定。

敏捷開發常見問題

敏捷開發是不是就不用寫文件、不用做計畫？

不是。敏捷宣言明確說明右側的流程、文件、合約、計畫仍有價值，只是更重視互動、可用成果、合作與回應變化。敏捷團隊仍然有產品目標與待辦清單，只是用短週期滾動調整。

Sprint 要設定多長比較好？

依 Scrum 指南，Sprint 為一個月或更短。很多團隊從兩週開始，需求變化快的可以更短，硬體開發比例高的可能需要較長。重點是選定後保持固定，讓團隊建立可預測的節奏。

Scrum 和 Kanban 可以一起用嗎？

可以。常見做法是以 Scrum 的 Sprint 節奏做規劃與審查，同時用 Kanban 看板視覺化工作流程並設定在製品上限，兩者可以互補。

Scrum Master 可以由研發主管兼任嗎？

小團隊實務上常見兼任，但要注意角色衝突：Scrum Master 的任務是協助團隊排除障礙與改善流程，若同時是考核者，團隊可能不敢在回顧會議中說真話。兼任時要有意識地區分兩種角色。

敏捷開發適合外包或接案型的專案嗎？

可以，但合約設計要配合。固定範圍、固定價格的合約與敏捷精神衝突較大，可以考慮分階段簽約或以時程與團隊規模計價，並讓客戶參與每次的 Sprint 審查。合約條款細節建議諮詢律師。

導入敏捷開發要多久才看得到效果？

通常需要數個 Sprint 才能建立穩定的節奏，初期可能因學習成本而變慢。建議以三到五個 Sprint 為試點觀察期，比較週期時間、Sprint 目標達成率與客戶回饋的變化。

結論：敏捷開發是讓研發風險提早曝光的管理方式

敏捷開發的價值，不在於站會開得多整齊或看板多漂亮，而在於每兩到四週就逼團隊交出可以被檢視的成果，讓錯誤在還便宜的時候被發現。Scrum 適合有明確產品目標的新開發，Kanban 適合持續流入的維運與客製工作，兩者也能混合使用。對中小企業老闆來說，最重要的三件事是：指定唯一的產品負責人、出席 Sprint 審查會議、限制同時進行的工作數量。從一個試點團隊開始，用數據觀察成效，再逐步擴大。更多研發管理主題，可以參考中小企業研發管理總覽。

讓主管與團隊一起學會敏捷：戰國策戰勝學院企業內訓

敏捷開發最常卡關的不是工程師，而是主管與老闆的管理習慣。戰國策戰勝學院的企業內訓課程可以為研發主管、產品負責人與跨部門成員客製化敏捷實作課程，用企業自己的產品待辦清單演練 Sprint 規劃、看板設計與回顧會議，相關主題也可參考敏捷管理與創新思維課程。若企業需要重新設計研發流程、跨部門協作與績效制度，也可以搭配顧問輔導服務進行診斷與導入。

資料來源：敏捷軟體開發宣言（繁體中文）、The Scrum Guide 2020、The Kanban Guide