這堂課會學到什麼
敏捷開發已經是軟體開發的基本功，越來越多數位產品 PM 職缺都要求這項技能。提到敏捷開發（Agile），你可能也會聽到 Scrum 這個詞。但 Scrum 究竟是什麼？它和 Agile 有什麼關係？什麼團隊適合導入 Scrum ？
身為擁有 CSM 敏捷證照、成功帶領團隊導入敏捷開發的產品經理，我在這邊規劃了上下兩堂課，來帶大家快速掌握敏捷開發 !
- 第八堂課 : 敏捷開發 (上) 敏捷核心價值以及基本框架與方法，聚焦敏捷的核心價值與基本框架，快速掌握敏捷開發的基礎方法。
- 第九堂課 : 敏捷開發 (下) 敏捷的進階框架與方法，探索敏捷的進階應用與進化框架，提升團隊效能。
即使你的公司主要採用傳統瀑布式流程，也能從敏捷精神中獲益。例如，利用 POC（概念驗證） 進行小規模試驗，或將專案拆解為階段性任務進行驗證，這些都是敏捷思維的體現。重點不在於名義上的流程，而在於如何用靈活高效的方式實現目標。這堂課將帶你從敏捷宣言與核心價值出發，並進一步了解實行敏捷開發的 Scrum 基本框架 如何運作，包括 Sprint 的迭代規劃、角色分工等。透過對敏捷精神的掌握，幫助你靈活應對挑戰，帶領團隊迎風而上，穩健抵達目標！
Agile vs. Scrum：核心差異一次搞懂
很多人以為 Agile 和 Scrum 是同一回事，但其實 Scrum 只是 Agile 眾多實踐方法之一。
- Agile 是一種價值觀與原則，強調靈活應變、持續改進、以人為本的開發方式。
- Scrum 則是實現 Agile 的框架，提供具體的方法來組織團隊工作。
簡單來說，Agile 是「理念」，Scrum 是「方法」。就像健康飲食是一種概念，而間歇性斷食、地中海飲食則是不同的具體做法。
Agile 介紹
2001 年，一群來自不同軟體開發背景的先驅們在美國猶他州雪鳥度假村聚首，討論如何應對軟體開發中常見的效率低下與變化挑戰。經過激烈的頭腦風暴，提出了「敏捷宣言」（Agile Manifesto）以及 12 項原則，強調靈活應對需求變更、快速交付價值，以及團隊與客戶的高效協作。
這些價值不僅改變了軟體開發的方式，也深刻影響了其他領域的工作方法，成為當今追求效率與適應性的企業重要指引。
敏捷宣言 4 大核心
這邊可以參考 www.agilemanifesto.org 的網站說明，也可以直接往下看進一步的中文列點介紹，
1. 個人與互動 重於 流程與工具 : 再厲害的工具也比不上人和人之間的默契！敏捷相信人是最重要的，好的團隊靠的是互動和協作，而不是死守流程與工具。這種價值觀鼓勵團隊自我管理，共同擁有成功的榮耀。
2. 可用的軟體 重於 詳盡的文件 : 客戶要的是能跑的軟體，不是壓死人的文檔！文檔是有用的，但如果產品不能用，那就毫無意義。敏捷強調把精力花在做出有價值的產品上，文檔只需簡單夠用。
3. 與客戶合作 重於 合約協商 : 合約寫得再長也不如跟客戶好好溝通合作！敏捷理解需求會變，所以不拘泥於一開始的約定，而是鼓勵團隊和客戶成為戰友，一起靈活應對變化，朝著共同目標邁進。
4. 回應變化 重於 遵循計劃 : 世界一直在變，計劃怎麼可能不變？敏捷推崇快速調整步伐，根據需求的改變優化產品。計劃不是用來束縛的，而是幫助我們更靈活地應對挑戰，走向成功的指南針！ 附註 : 以前學到這邊，很多人就誤解成「那我們就不用流程工具、不寫規格書，因為敏捷宣言說不用文件啊！」這可是大錯特錯！沒有基本框架的文件或流程，做好產品規劃和團隊溝通是非常困難的 XD。因此，敏捷的重點是不要執著於把流程和文件搞得繁瑣冗長，但基本功還是一定要有的！
敏捷 12 條原則
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
我們的最高優先級是透過早期且持續交付有價值的軟體來滿足客戶需求。
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
即使在開發後期，也歡迎需求變更，敏捷流程利用變更來提升客戶的競爭優勢。
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
頻繁交付可用的軟體，時間間隔為數週到數月，並偏向於較短的時間尺度。
4. Business people and developers must work together daily throughout the project.
商業人員與開發者需要在整個專案過程中每天協作。
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
團隊應以有動力的成員為核心，提供他們需要的環境和支持，並信任他們完成工作。
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
傳遞資訊給開發團隊或在團隊內部交流最有效的方式是面對面的交流。
7. Working software is the primary measure of progress.
可工作的軟體是衡量進展的主要標準。
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
敏捷流程促進可持續發展。贊助者、開發者和用戶應能夠以穩定的步調持續工作。
9. Continuous attention to technical excellence and good design enhances agility.
持續關注技術卓越與良好設計有助於提升敏捷性。
10. Simplicity—the art of maximizing the amount of work not done—is essential.
簡化——最大化減少未完成工作的藝術——是關鍵。
11. The best architectures, requirements, and designs emerge from self-organizing teams.
最佳的架構、需求和設計源自於自我組織的團隊。
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
團隊應定期反思如何變得更高效，並據此調整行為。
Scrum 介紹
Scrum 這個詞源自橄欖球（Rugby），指的是球員們肩並肩推進、相互配合前進的戰術。Scrum 這個框架就是這樣——團隊不依賴單打獨鬥，而是像橄欖球隊一樣，透過短期衝刺（Sprint）協作推進目標。
那 Scrum 到底是怎麼運作的呢？首先先來了解一下 Scrum 三本柱。
從侯鳥遷徙看 Scrum 的三本柱：透明、檢視、調整
你知道候鳥為什麼要遷徙嗎？遷徙是為了尋找更適合生存的環境。當繁殖地資源不足或氣候變冷時，牠們會遷往溫暖、食物豐富的地區過冬；到了春天，牠們再返回北方繁殖。這種周期性遷徙展現了候鳥適應環境變化的智慧，也與敏捷開發的精神不謀而合。
在遷徙的過程中，候鳥們以人字形或一字形編隊翱翔，不僅壯觀，還蘊含敏捷思維的精髓。牠們依靠 觀察（Inspection）與調整（Adaptation） 來應對環境變化，適時調整隊形、方向與速度，提高效率，確保順利抵達目的地，正如敏捷團隊需要持續檢視與調整來適應市場變化。
透明（Transparency） 是候鳥遷徙成功的關鍵。領飛的鳥引導方向並產生上升氣流，減少後方鳥群的能量消耗；跟隨的鳥則觀察並適時調整位置，保持隊伍穩定與效率。當領飛者疲憊時，隊形會迅速適應，由另一隻鳥接替領導角色，確保整體旅程順利進行。這與敏捷團隊中開發者、測試者與產品負責人之間的透明協作如出一轍。
候鳥的遷徙方式也呼應了敏捷開發中的 可交付增量（Potential Shippable Product Increment, PSPI） 理念。牠們在遷徙途中選擇適合的停留點補充能量，並評估環境是否適合作為下一階段的目標地，類似於敏捷開發中的每個 Sprint 迭代，確保每一步都能產出有價值的成果。
候鳥遷徙的智慧告訴我們，敏捷不僅是一種開發方法，更是一種應對變化的生存策略。無論是展翅翱翔的鳥群，還是快速變動的市場環境，觀察、適應與協作都是成功的關鍵。
Scrum 的三本柱就跟侯鳥遷徙的精神一樣：
- 透明（Transparency）：團隊的目標、進度、遇到的問題必須公開透明，讓所有成員都能掌握狀況。
- 檢視（Inspection）：定期回顧進度，確保正在做的事符合預期。
- 調整（Adaptation）：根據檢視結果，隨時調整策略，確保團隊能快速適應變化。
Scrum 運作方式
這裡附上 Scrum.org 推廣敏捷的組織撰寫的 Scrum 輕量框架手冊。市面上雖有許多敏捷書籍，但對初學者來說，這份 PDF 是最佳入門資料。想考證照的讀者也建議從這裡開始，快速掌握開發方法，避免被複雜框架困住。Scrum 的核心精神在於簡化，因此我們也僅保留最實用的原則與方法，幫助大家順利實踐 Scrum。
Scrum 的 Roles 角色
1. Product Owner（產品負責人：掌舵者）
Product Owner 是產品方向的掌舵者，負責確保團隊的努力能真正滿足用戶需求並帶來商業價值。他的核心任務包括明確產品目標、制定優先順序，並管理產品待辦清單（Product Backlog）。
雖然 Scrum 框架中的 PO 和傳統開發方式中的 Product Manager（產品經理）職責有所不同，但兩者都扮演關鍵角色。PO 更專注於產品價值的優化與方向掌控，而 Product Manager 通常涉及更廣泛的市場策略與用戶洞察。對外招募時，這兩個職稱可能會被混用，但可以理解為一種偏向產品專案管理、市場導向的領導角色。
2. Scrum Master（敏捷守護者：團隊的推動者）
Scrum Master 是團隊的敏捷教練，負責促進團隊高效運作，並確保 Scrum 流程順利進行。他的職責包括協助團隊克服障礙、提升溝通效率，以及避免外部干擾影響團隊專注。
在 Scrum 框架之外，Scrum Master 的角色可以類比於 Project Manager（專案經理），但重點不同：Scrum Master 專注於流程優化和團隊效能，而非直接管理項目進度。對外招募時，這兩個職稱可能也會有交叉，但 Scrum Master 更傾向於內部開發流程的推動角色。
3. Development Team（開發團隊：產品實現者）
開發團隊是產品的創造者，負責將 Product Owner 的構想轉化為具體可交付的產品。他們由跨功能的專業成員組成，包括開發、測試、設計等，具備實現產品需求的全部能力。
與傳統開發模式不同，Scrum 中的開發團隊強調自主管理。他們自行組織並承諾在每次 Sprint（短衝）內完成既定目標，確保產品開發過程高效而專注。
Scrum 的 Sprint Cycle 會議
若無法清楚看到圖片文字，請點擊下方連結預覽 or 下載查看清晰版本 :
在 Scrum 專案管理中，Sprint 是核心，也是整個團隊前進的節奏步調。一個 Sprint 通常為期 1 至 4 週，由一連串規律的 Event 組成，每個步驟環環相扣，確保專案穩步向前。以下是 Sprint Cycle 的簡單介紹：
- Sprint Planning（Spint 計畫會議） 每個 Sprint 的開場舞，團隊與 PO（產品負責人）一起決定這個週期的目標與工作範圍。重點是挑選有價值的工作，集中精神在優先順序高的產品事項，並確保每個人都清楚「我們要完成什麼」與「如何完成」。
- Daily Scrum（每日 Scrum 會議） 這是每天的熱身環節，時間短（15 分鐘內），但效率高。團隊成員分享昨天完成了什麼、今天計劃做什麼，以及遇到的困難。目標是保持資訊透明，快速解決問題。
- Sprint Review（Sprint 評審會議） 在 Sprint 結束時，團隊展示完成的功能或成果，讓 PO 和其他利害關係人檢視進度，並提供反饋。這是檢查產品價值是否符合需求的好機會，可能也可以透過一個展示會直接讓使用者操作的概念來進行，而非很多書面資料介紹，避免讓展示評審會議流於形式。
- Sprint Retrospective（Sprint 回顧會議） 這是反思檢討改善的時間。團隊一起討論 Sprint 的表現，找出哪些地方做得好、哪些地方需要改進，並決定如何在下一個 Sprint 中提升效率或團隊合作，持續改善、成長性思維就是 Scrum 很重要的精神 !
- Backlog Refinement（產品精煉優化） 雖然不一定是 Sprint 的固定活動，但定期整理產品待辦清單（Product Backlog）是保持任務清晰與優先順序正確的關鍵，並讓 Planning 可以減輕一些作業時間，透過小額 Refine 時間持續梳理 Product Backlog 產品待辦清單。
Sprint 的彈性魅力在於它是一個循環：計劃、執行、檢討、改善，快速迭代然後再開始下一個週期。 這種節奏讓團隊在快速變化的環境中，始終能適應與成長 !
Sprint Element 元素
Sprint 是敏捷開發的核心，而在這個短週期 1~4 周 (依照團隊商議決定固定衝刺的週期) 的魔法中，除了上述關鍵角色（Roles）扮演不同任務之外，還有幾個重要元素在背後默默發揮作用，讓 Sprint 高效運轉。
首先是 Product Backlog（產品待辦事項列表） 它就像一張大藍圖，列出了一切有價值的事情，從創新的點子到修 Bug 的需求，應有盡有。而在 Sprint 開始前，團隊會從 **Product Backlog（產品待辦事項列表）**藍圖中精挑細選出一些最重要的項目，這些項目就是拆得更小的 Product Backlog Items（PBI）。每個 PBI 都像是一顆拼圖，組成完整的產品畫面。
再來是 Definition of Done（完成的定義，簡稱 DoD） 這可不是隨便喊一聲「完成了」就行的。每個 PBI 都需要明確定義什麼樣的狀態才算真的「Done」，例如：程式碼完成後是否經過測試？介面是否符合設計規範？這不僅確保品質，也讓團隊在交付時更有底氣。
最後是 Acceptance Criteria（驗收標準，簡稱 AC） 這是每個 PBI 的驗收門檻，簡單來說，它回答了「我們做的東西能不能滿足需求？」的問題。具體標準越清晰，開發過程越順暢，讓客戶與團隊在交付後都能滿意點頭。
這些元素的協同作用，讓 Sprint 不只是開發過程，而是一場有計畫、有目標、有結果的高效旅行。當每個 Sprint 都充滿專注和品質，你的產品也會一步步更接近理想的樣子！
Component Team 和 Feature Team 分別是什麼概念?
在軟體開發中，Component Team 和 Feature Team 是兩種常見的團隊組織形式，各自有著不同的特性與適用場景。理解它們的差別能幫助我們在產品開發中更有效率地協作與資源配置。
什麼是 Component Team？
這種團隊就像專業工匠，只負責某一個特定的技術領域，譬如資料庫、後端 API，或者前端 UI，幫你打好基礎建設。
他們的厲害之處：
- 技術專精：技術深度絕對有！他們專攻一塊，解 bug、優化性能就靠他們。
- 跨項目支援：服務範圍廣，很多團隊都得靠他們的模組才能跑起來。
- 依賴性高：但這也可能是缺點，因為所有人都等著他們輸出，協作過程容易出現「卡住了，等進度」的狀況。
什麼時候用 Component Team？
當系統技術很複雜，比如有些核心算法或共用資料庫需要穩定性超高的時候，這類團隊就能派上用場！
什麼是 Feature Team？
Feature Team 就像全能選手，從需求到交付，一條龍包辦。這樣的團隊跨職能組成，裡面什麼角色都有：前端、後端、測試，搞定完整的功能沒問題！
他們的強項：
- 一條龍服務：團隊裡有所有技能，功能能快速上線，根本不需要等別人。
- 低依賴性：說走就走，說幹就幹，減少跨團隊協作的摩擦。
- 以用戶為中心：開發的目標很清楚，就是為了滿足用戶需求，快速交付價值。
什麼時候用 Feature Team？
如果你的產品需要快速迭代、快速上線，或者你的目標是用戶滿意度，那 Feature Team 就是你的最佳拍檔。
核心差別
差別比較表
| 維度 | Component Team | Feature Team |
|---|---|---|
| 核心目標 | 深入開發與維護技術模組 | 完整交付可用功能 |
| 工作範圍 | 系統的某一部分 | 從需求到交付的端到端功能 |
| 專業技能 | 技術領域的深度專精 | 跨領域的技能組合，專注功能落地 |
| 依賴性 | 高，需與其他團隊緊密協作 | 低，團隊內部具備完成功能的所有必要資源 |
| 適用場景 | 高技術複雜度或共用模組的場景 | 快速迭代功能、用戶價值導向的場景 |
為什麼 Scrum 偏愛 Feature Team？
- 快速交付用戶價值 敏捷的目標是縮短從需求到交付的路徑，而 Feature Team 是「一條龍服務」，可以在一個 Sprint 內從設計、開發到測試直接完成功能，縮短等待時間。相比之下，Component Team 必須依賴其他團隊來拼湊功能，容易因溝通和依賴造成延誤。
- 跨職能協作 Feature Team 包含了實現功能所需的各類角色，比如前端、後端、測試工程師等。這種組合可以在團隊內解決大部分問題，避免頻繁的跨團隊溝通，大大提高效率，這正符合 Scrum 推崇的自組織和自主性。
- 用戶需求為中心 Scrum 的一切開發活動都圍繞 Product Backlog，也就是以用戶需求為導向的待辦清單。Feature Team 直接對接用戶故事（User Story），目標清晰，開發的每一個功能都直指用戶價值，而不是技術模組本身。
- 減少依賴與瓶頸 在 Component Team 的模式下，團隊之間經常會因模組完成的優先級不同而卡住進度。相反，Feature Team 因為可以獨立運作，大大降低了依賴性和「等模組」的風險，讓 Scrum 的短迭代（Sprint）節奏更流暢。
- 更符合 Scrum 的框架設計
- Product Owner：可以直接與 Feature Team 溝通具體需求，專注於用戶價值的實現。
- Scrum Master：幫助團隊專注於解決功能開發中的障礙，而不用在跨團隊協作中浪費時間。
- Development Team：自包含所有技能，完全符合 Scrum 團隊設計的小而精、專注交付的理念。
當然，現實中也會有挑戰
即使 Feature Team 是敏捷和 Scrum 的最佳搭檔，但在大公司或技術架構高度複雜的場景中，有時候也不得不引入 Component Team 來支撐基礎技術模組。不過，如果能在基礎模組穩定後，盡量把業務功能的開發轉移到 Feature Team，整體效率會更高。
結論：Scrum 最愛 Feature Team，因為它最快速地把價值送到用戶手上！
左圖為 Component Team，右邊為 Feature Team 抓出各核心職能的人組成 Feature Team
抓出來變成 Feature Team 後，可以讓每個團隊實現端到端完整交付，更可以專注在產品待辦事項，每個成員還是可以在平衡的狀況下，選擇專業的項目優先認領，慢慢的從 80 % 做自己擅長的，20 % 學習其他的技能，並產生學習的動機，實現一個超強的全端團隊 !
Scrum 是為了更快、更靈活地響應用戶需求，而 Feature Team 的設計初衷就是為了端到端交付完整功能。這種團隊模式不僅符合敏捷的精神，也讓每個 Sprint 都更有價值感，讓用戶和開發團隊都更滿意！
書籍推薦
第二堂課也有推薦這本書給大家，這邊再推薦一次，
產品經理全方位敏捷實踐：從活用 Scrum 到強化 PM 心理素質， 成為 AI 無法取代的產品負責人
在高薪科技業中，產品經理（PM）不只是產品的推動者，更是連結市場、使用者與團隊的橋樑。然而，如何從零開始掌握產品思維？如何在充滿不確定性的開發環境中，以敏捷開發（Agile）提高專案成功率？這正是一本為解答這些問題而生的書。
本書由 iThome 鐵人賽 Agile 組優選系列文章改編而成，內容扎實且實用，適合轉職 PM、新手 PM、Scrum Master 以及想進入高薪科技業的讀者。書中不僅拆解了產品開發的核心通識，還以生動的案例帶領讀者深入理解敏捷開發與 Scrum 方法，即使沒有工程背景，也能輕鬆上手。
📌 本書精華：
✔ 實戰經驗豐富：透過大量實例與「敏捷災難現場錦囊」，讓你避開常見的敏捷開發陷阱。
✔ 完整涵蓋 PM 重要知識點：從市場機會評估、用戶研究，到產品規劃與團隊協作，全面提升你的 PM 能力。
✔ 敏捷心理素質養成：除了方法論，書中還結合心理學，幫助 PM 在高壓環境中保持靈活應對的心態。
✔ 不只限於工作：「一人敏捷術」讓你學會如何將敏捷思維應用於日常決策，提高效率與適應力。
這不僅是一本關於敏捷開發的工具書，更是一個幫助你培養「產品思維」與「敏捷體質」的指南。無論你是職場新鮮人，還是想提升產品管理能力的專業人士，這本書都能為你的職涯帶來關鍵的啟發與成長。
結論 Recap
這堂課學到了以下這些 :
- 敏捷宣言的 4 大核心與 12 原則：
- 核心價值：人際互動 > 工具流程；運行軟體 > 文檔；客戶合作 > 合約；應對變化 > 固守計劃。
- 12 原則：快速交付價值、擁抱變化、頻繁交互、高效團隊、持續改進等。
- 敏捷核心價值與實踐框架：
- Scrum 是敏捷價值與原則的具體實踐，包含角色分工 (PO, SM, 開發團隊) 和迭代流程 (Sprint Cycle)、Sprint Elements (包含 DoD、AC)、Product Backlog 的範例、Component Team VS. Feature Team。
下堂課 第九堂課 : 敏捷開發 (下) 敏捷的進階框架與方法 將深入探討 Scrum 的核心概念，並將其拆解得更加細緻。我們會聚焦於進階實踐與應用，帶大家逐步了解如何在團隊合作中最大化價值與效率，幫助大家更全面地掌握這個敏捷框架的精髓。
📩 歡迎交流！看完文章後，若有任何想法、建議或想一起討論的話，隨時歡迎來信交流！
Miss 六月奶茶聯絡信箱 : junemilktea6@gmail.com
