這堂課會學到什麼
在 上篇課程 : 敏捷開發 (上) 敏捷核心價值以及基本框架與方法，聚焦敏捷的核心價值與基本框架，快速掌握敏捷開發的基礎方法。我們聚焦於敏捷宣言與核心價值，並解析了 Scrum 的基本框架，包括 Sprint Cycle 的迭代規劃與 Scrum Roles 的角色分工等核心要素。
本堂課作為 下篇課程，將帶你更深入了解 Scrum 各類會議中角色應關注的細節，並進一步探索進階框架與應用實踐，幫助你在團隊合作與開發中更游刃有餘。
Sprint Planning（Sprint 計畫會議）
在敏捷開發的第一步，Sprint Planning（短衝規劃會議）是關鍵！它不僅決定了團隊在接下來的一段時間內要完成的工作內容，還能確保每個人都清楚自己的任務和目標。以下是 Sprint Planning 的核心要素，讓你的會議既高效又有方向感。
1. Sprint Planning 是什麼？
Sprint Planning（短衝規劃會議） 是敏捷開發的第一步，確保團隊在每個 Sprint 開始之前對接下來的工作內容和目標有清晰的認識。這不僅關乎選定需要完成的任務，也確保每位團隊成員清楚自己的角色和責任，從而在 Sprint 中協作順利。
2. Sprint Planning 誰參與？
- Scrum 團隊的所有成員
- 開發團隊（Developers）： 參與開發的所有成員，包括程式設計師、測試人員、UI/UX 設計師等，都應該參加 Sprint Planning 會議，因為每個人的意見和需求對於工作項目的理解至關重要。
- Scrum Master： Scrum Master 的角色是會議的主持人，負責引導討論並確保會議按照目標進行。確保會議進度流暢，協調各方意見，並協助團隊做出最有效的決策。
- Product Owner（PO）： PO 在會議中的主要職責是確定 Sprint 的目標、解釋 Product Backlog 中的項目，以及回答團隊的問題，幫助團隊理解任務的需求和期望結果。
- 誰不參與？ Sprint Planning 是一個團隊內部的會議，因此通常不會邀請外部利益相關者（如客戶或高層管理者）。這樣可以避免不必要的干擾，使團隊成員能夠自由地討論並專注於目標設定。
3. Sprint Planning 的核心步驟：
Step 1: 訂定 Sprint Goal
會議開始時，PO 需要明確確認此次 Sprint 的主要目標。例如，是否專注於完成某個新功能，還是解決技術債務？團隊需要對此有共同的理解，以確保大家朝著同一個方向努力。
- 舉例：「我們的目標是完成用戶註冊功能，並修復關鍵 Bug，提升用戶體驗。」
- 小技巧：用一句話描述目標，讓團隊馬上掌握方向。
Step 2: 挑選並拆解 Product Backlog 項目
PO 按照優先順序展示 Product Backlog 中的任務，這邊的任務是需要準備好已完成 DoR 的任務 (什麼是 DoR，跟 DoD 有什麼不一樣的可以參考這邊文章 : Agile Scrum中 DoR 和 DoD 的差別與介紹 )，並解釋每個項目的需求和期望結果。
大規模的需求（Epic）需要進一步拆解為可在一個 Sprint 內完成的小任務（User Story）。每個任務都應該附有明確的 定義完成標準（DoD）和驗收標準（AC），以確保交付物達到預期質量。
補充說明 : DoD (Definition Of Done ) 為完成標準的定義，例如定義「確保程式碼測試完備、設計符合規範、文件同步更新」都完成才是 Done。 AC (Acceptance Criteria ) 為明確驗收標準，確保交付物達到完全符合需求，QA 測試用戶操作流程，確保所有 AC 被覆蓋，且符合用戶體驗預期。
Step 3: 任務估點（工作量評估）
團隊使用費波納西數列或其他估算方式，對選定的任務進行工作量估點，並根據過往的速度（Velocity）確定能完成的任務數量。這個過程可以幫助團隊對工作量達成共識，從而避免後續過多的時間調整。
估點怎麼玩？用費波納西數列快速搞定
我們常用費波納西數列（1、2、3、5、8、13……）來估算任務的相對規模，因為這個數列自然反映了任務大小增加時的不確定性。操作方式很簡單，可以試試這個風趣又有效的流程：
1. 任務討論：PO（產品負責人）先簡述任務目標和細節，開發團隊確認需求是否清楚。如果有疑問，就直接討論，避免不明確的工作被低估或高估。
2. 三二一喊拳：在討論完畢後，所有開發人員同時比出自己心中的估點大小（手勢可以是數字，或者使用專業的估點撲克牌）。
3. 差異討論：如果有人給 3 分，有人給 8 分，那就來聊聊為什麼！通常差異來自經驗不同、對需求的理解不一致，透過討論後，大家再重新估點快速技巧：如果大家估點差距大，試著討論以下幾點 是否有人忽略技術挑戰？ 是否需求理解有分歧？
4. 達成共識：最後團隊會取中間或最接近共識的數字，並記錄下來作為該任務的估點。
Tips： 避免超載工作量！每個 Sprint 的工作內容要能在 Sprint 結束時完成。 估點不是在追求絕對精準，而是為了讓團隊對工作量有一致的理解。如果一開始估得不準，也沒關係，隨著實作經驗增加會越來越精確！
Step 4: 設定 Sprint Backlog
選定的任務會被轉移到 Sprint Backlog，並進一步拆解為具體的開發任務（Task），由各個開發人員負責完成。這些任務形成了團隊在 Sprint 中需要解決的具體工作清單。
- 範例場景：「新功能『優惠券系統』被拆解成以下任務：」
- 任務 1：後端 API 開發
- 任務 2：前端 UI 設計
- 任務 3：功能整合與測試
- 提醒：記得定義清晰的 DoD（完成標準）。
Step 5: 風險預測與資源分配
團隊需要在會議中討論可能的風險，例如技術挑戰、依賴性問題等，並提前擬定應對策略。如果有外部資源需求，也應該在此階段進行協調，確保有足夠支持來順利完成 Sprint。
範例：「API 設計可能依賴外部資料庫，我們需要提前確認架構是否兼容。」
4. Sprint Planning 的注意事項
1. 目標清晰且可衡量 PO 提出的 Sprint 目標必須具體、清晰，且與商業價值緊密相關。團隊必須知道完成任務後會對產品或用戶帶來何種實際價值。
2. 任務可交付且可驗證 所有選定的任務應當在 Sprint 結束時可交付並且能夠被驗證。團隊需要確保能夠逐步交付，並提前設計測試或分階段提交的策略。
3. 團隊承諾與共識 Sprint Planning 的目的是確保團隊對每個任務的需求、工作量和完成標準達成共識。每個團隊成員都應對自己的任務負責，而不是被動接受指派。
4. 保持彈性 雖然規劃至關重要，但也應該保留一定的空間來應對突發的需求變動或優先順序的調整。過度填充 Sprint 任務清單可能會導致負擔過重，影響團隊的執行效率。
5. Timebox 時間限制 一個 Sprint 的規劃會議不應該超過 2 小時（對於一週長度的 Sprint），兩週長度的 Sprint 會議則不宜超過 4 小時。避免過度討論細節，未解決的問題應該推遲至 Refinement 階段或開發過程中再解決。
6. 可視化工具輔助 使用如 Jira、白板工具等看板工具來協助規劃過程，能讓討論更有條理，並便於跟蹤每個任務的狀態和進度。
7. 學會取捨 PO 需要有勇氣拒絕低優先級的任務，並專注於高價值的工作。團隊應該避免接手需求不成熟或無法實現的任務。但還是要補充一下主管還是有裁量權可以決定要做什麼，切記身為 PO 不要硬碰硬，柔軟一點言之以理動之以情溝通說服，若是不成，就還是做吧 !!
延伸學習 :
產品待辦清單（Product Backlog）如何變成開發團隊的工作任務？以小型電商網站為範例
Daily Scrum（每日 Scrum 會議）
1. Daily Scrum 是什麼？
Daily Scrum，又稱每日站會，通常說是站會，就是怕大家坐著開會開太久，還可以嘗試棒式開會，這樣大家應該會超快就累於是很快結束 (開玩笑XD)，還是要把會議目的好好達成才是正解。是敏捷開發中不可或缺的日常節奏，短短 15 分鐘的會議，幫助團隊快速對齊進度，發現潛在問題，並保持目標一致。這個會議可以想像成每天的「行軍指引」，確保大家朝著同一方向邁進。
2. 誰參與 Daily Scrum？
- Scrum 團隊的所有成員：
- 開發團隊（Developers）：Daily Scrum 是開發團隊的核心會議，主要由開發成員進行分享，確保每個人對目標和進展有一致的理解。
- Scrum Master：Scrum Master 可以參加，但並非主持會議。他們的主要責任是確保會議高效進行，並解決阻礙團隊進展的問題。
- Product Owner（PO）：PO 的參與是 Optional 的，但如果參加，他們的角色應該是觀察和提供目標方向的補充，而非干預進行。
- 誰不參與？ Daily Scrum 是團隊內部的溝通會議，通常不會邀請外部利害關係人參與。這樣可以保持會議專注且高效。
3. Daily Scrum 的核心步驟：
Step 1: 確認會議時間與地點
- 時間： Daily Scrum 通常安排在每天的固定時間進行，例如每天上午 9 點。建議控制在 15 分鐘內完成，即使團隊規模較大也不例外。
- 地點： 可以是實體辦公室的一個開放空間（如看板前），也可以是線上會議（搭配共享的看板工具，如 Jira、Trello）。
Step 2: 每人回答三個關鍵問題
每位成員依次回答以下三個問題，簡潔扼要地說明進度與挑戰：
- 昨天完成了什麼？ 例如：「我昨天完成了功能 A 的單元測試。」
- 今天計劃完成什麼？ 例如：「今天我會開始功能 B 的開發，預計完成 50%。」
- 有沒有阻礙需要解決？ 例如：「目前資料庫設計有疑問，需要與架構師確認。」
Step 3: 團隊進行快速檢視
在每個成員分享後，團隊可以快速檢視：
- Sprint 目標是否保持清晰： Sprint Backlog 是否需要調整？
- 障礙是否有解決計劃： Scrum Master 需要介入處理的障礙是什麼？
- 優先事項是否一致： 確保團隊的資源集中在最重要的項目上。
4. Daily Scrum 的注意事項：
- 控制會議時間：Daily Scrum 必須嚴格限制在 15 分鐘內，討論過程中若有細節需深入探討，應安排會後再處理。例如大家有共識：技術細節只在站會後的小群組討論。
- 專注進度與目標：避免過多技術細節，會議的重點是「對齊進度與目標」，而非詳細的問題解決過程。
- 打造高效的溝通文化：使用可視化工具（如 Sprint 看板），幫助團隊快速理解進度與工作分配。
- 解決阻礙的後續行動：每次會議後，Scrum Master 或相關負責人應立即跟進，解決會議中提到的障礙。
5. Daily Scrum 的小技巧：
- 站立進行： 站立開會能讓會議更簡潔高效，避免冗長。
- 使用定時器： 每人發言時間不超過 1 分鐘，確保每位成員都有發言機會。
- 輪流主持： 每天由不同團隊成員主持，增加參與感與責任感。
- 結合心情檢查： 在會議開頭簡短分享個人狀態，增進團隊的互信與支持，例如：「用一個詞形容你今天的感受！」
Sprint Review（Sprint 評審會議）
1. Review 是什麼？
Sprint Review 是團隊在每次 Sprint 結束時舉行的成果展示會。它的目的是展示完成的工作成果，與利害關係人共同檢視交付功能是否符合預期，並根據反饋來優化未來的產品路線圖。
產品 Review 的最佳實踐：
為避免淪為形式，盡量以實際操作的方式展示功能，而非準備過多的文件。設置平板、筆電或手機，讓利害關係人直接體驗這次 Sprint 交付的功能，並給出實時反饋。
2. Review 的參與者
- Scrum 團隊全員：
- 開發團隊（Developers）： 演示實際完成的工作，展示成果價值。
- Product Owner（PO）： 引導會議，回顧 Sprint Goal，並解釋目標的完成情況和未完成的原因。
- Scrum Master： 確保會議流程順暢，並幫助團隊專注於收集反饋和下一步行動。
- 利害關係人： 包括客戶、業務代表或其他受產品影響的外部人員，為團隊提供寶貴的反饋意見。
3. Review 的流程
Step 1: 回顧 Sprint 目標
由 Product Owner 主持，簡述此次 Sprint 的目標，概括完成的工作和未完成的原因，讓所有人了解進展狀況：
- 哪些目標達成了？
- 哪些目標未完成？原因是什麼？
💡 小建議： 使用簡潔的圖表（如 Burn-down Chart）或白板展示目標完成情況，讓進展更加直觀。
Step 2: 開發團隊展示成果
開發團隊進行實際演示（Demo），聚焦於這次 Sprint 完成的具體功能：
- 功能的價值點： 為使用者解決了哪些問題？
- 實際操作： 讓參與者親自測試，體驗完成的功能是否符合預期。
🛠️ 小工具建議： 使用演示環境或模擬器，讓展示過程更流暢。
Step 3: 收集利害關係人的反饋
- 開放式提問： 鼓勵利害關係人提出改進意見，或探討交付成果是否滿足需求。
- 調整產品路線圖： 根據反饋更新 Product Backlog，並對未來的優先事項進行初步討論。
Step 4: 探討下一步改進方向
- 針對反饋，評估需要調整的部分，並預先規劃可能的後續步驟。
- 確保團隊和利害關係人對產品未來的目標達成共識。
4. Review 的注意事項
1. 聚焦成果價值： 避免單純展示功能，應強調功能為用戶或業務帶來的價值。
2. 鼓勵互動： 邀請利害關係人親自體驗功能並給出實時反饋。
3. 正視未完成的工作： 將未完成的工作透明化，並清楚說明原因。
4. 避免形式化： 目標是發現改進機會，而非流於形式的成果匯報。
5. Timebox 時間限制： 1 小時： 適用於 1 週長度的 Sprint。 2 小時： 適用於 2 週長度的 Sprint。
Sprint Retrospective（Sprint 回顧會議）
1. Retrospective 是什麼？
Sprint Retrospective 是團隊在每次 Sprint 結束後的「內部檢討會」，用來反思過程中的亮點與痛點，找出改進的具體行動方案。
2. Retrospective 誰參與 ?
- Scrum 團隊的所有成員
- 開發團隊（Developers）： 參與開發的所有成員，無論是程式設計師、測試人員、UI/UX 設計師，還是其他專業角色，都應該參加，因為每個人對於流程的觀察和感受都非常重要。
- Scrum Master： 作為會議的主持人，Scrum Master 的角色是引導討論、促進開放交流，並確保會議聚焦於改進，而非責備或抱怨。
- Product Owner（PO）： 雖然 PO 的主要職責在於管理產品價值，但他們的參與有助於提供商業層面的觀點，幫助團隊更好地對齊目標和優化流程。
- 誰不參與？ Sprint Retrospective 是一場團隊內部的會議，因此通常不會邀請外部的利害關係人（如客戶或高層管理者）。這樣可以確保團隊成員感到足夠的安全和信任，能夠坦誠分享自己的觀點。
3. Retrospective 的核心步驟：
Step 1: 打造開放的會議氛圍
在 Retro 中，開放和安全是最重要的基礎，畢竟沒有人喜歡在緊張的氣氛中交流。如何讓團隊放鬆、坦誠表達呢？以下是幾個關鍵原則：
- Don’t make it personal, don’t take it personally. 我們討論的是過程和問題，而非某個人。
- Listen with an open mind. 帶著好奇心傾聽，而不是急著反駁。
- Everyone’s experience is valid. 每個人感受到的問題都是真實的。
- Focus on improvement, not blame. 目標是進步，而不是揪出誰的錯。
🛠️ 小工具建議：試著從一個輕鬆的 Icebreaker 開始，例如分享這次 Sprint 的一句心情總結，讓氣氛更輕鬆。
Step 2: Safety Check 或 ESVP（探討安全感）
在進入正題前，先確認團隊對會議的心理安全感。可以用以下方式：
- Safety Check: 團隊成員用 1-5 分（1 = 超安全，5 = 完全不想說話）評估自己的心理安全感，主持人可以視情況調整後續討論的方式。
- ESVP（Explorer, Shopper, Vacationer, Prisoner）: 團隊成員匿名選擇自己目前的狀態：
- Explorer（探索者）: 積極參與，尋找改進方法。
- Shopper（購物者）: 希望吸收新資訊，選擇性參與。
- Vacationer（度假者）: 放鬆的心態參加，並不想深入參與。
- Prisoner（囚犯）: 感覺被迫參加，不情願發言。
👀 為什麼這麼重要？
了解團隊的心理狀態，有助於調整討論的深度和節奏，確保每個人都有參與感。
Step 3: 回顧 Sprint 目標和項目
回顧的第一步，就是對齊這次 Sprint 的目標和交付成果，幫助團隊聚焦在具體內容上：
- 這次 Sprint 設定的目標是什麼？
- 我們實現了哪些目標？還有哪些落空？
- 有哪些亮點或挑戰需要特別注意？
💡 小建議：用簡潔的數據或可視化圖表（如 Burn-down Chart 或是這次 Sprint Backlog 的看板）快速回顧進度，避免冗長的講解。
Step 4: 選擇 Retro 方法，進行討論
Retro 不應該千篇一律，嘗試不同的方法可以激發更多的創意和思考。這裡列舉幾種有趣的方法供參考：
- Start, Stop, Continue: 團隊列出應該開始做、停止做和繼續做的事情。
- 4Ls（Liked, Learned, Lacked, Longed for）: 探討 Sprint 中喜歡、學到、缺少和期待的內容。
- Sailboat Method: 把團隊比喻為一艘船，檢視推動我們前進的風（助力）、阻礙的錨（問題）和遠方的島嶼（目標）。
- 推薦找靈感的來源範例 : 非常推薦靈感枯竭時可以來這個 Retro 131 種方法網站 找尋靈感。另外也有這個 解放結構 討論方法可以參考。另外再推薦一個很棒的 ORID 探詢方法，可以幫助團隊在更客觀更有脈絡順序進行深入覺察洞悉的討論。
🎨 創意加分：用白板工具和有趣的主持方法來視覺創意化討論內容，提升參與感！
Step 5: 制定具體的行動計劃並追蹤
討論的重點不只是找到問題，而是制定有效的行動計劃：
- 好問題：維持下去！ 列出 Sprint 中成功的做法，確保這些亮點能延續到下一次工作中。
- 壞問題：立即改進！ 對每個問題，設定具體的解決措施、負責人（Owner）和完成期限（Deadline）。
- 追蹤 Action Items： 下一次 Retro 開始前，檢查這些行動計劃的落實情況。如果無法完成，找出原因並調整策略。
🚀 小提醒：行動計劃如果無法有效追蹤，團隊對 Retro 的信任度會逐漸下降。所以，保持透明和持續改進至關重要！
3. Retrospective 的注意事項
1. 創新互動方式： 例如利用白板工具、投票系統，讓成員更樂於參與。
2. 保持正向氛圍： 問題歸問題，避免過度批評影響士氣。
3. 定期回顧結果： 確保每次行動計劃都能落實，避免一提再提。
4. Timebox 時間限制：若 Sprint 為一週長度，Retrospective 約需 45 分鐘到 1 小時。兩週長度的 Sprint，會議約需 1.5 小時。
Backlog Refinement（產品精煉優化）
1. Refinement 是什麼？
Refinement（需求細化會議）是敏捷開發中持續進行的一項重要活動，通常在 Sprint 執行期間 進行。其目的是細化 Product Backlog 中的項目，讓團隊與 Product Owner（PO）共同理解需求，拆解任務，補充細節，確保下一個 Sprint 的工作能順利執行。
Refinement 的最佳實踐：
避免會議淪為單純討論需求的場合，PO 應提前準備高優先級項目，讓會議聚焦具體的內容，同時鼓勵團隊參與估點並確認完成標準（DoD 和 AC）。
2. Refinement 誰參與 ?
- Scrum 團隊全員：
- Product Owner（PO）： 負責準備需求，解釋業務背景，並回答團隊的疑問。
- 開發團隊（Developers）： 提出需求的技術實現方案，參與估點並討論完成標準。
- Scrum Master（選擇性參與）： 幫助保持會議專注並確保時間管理。
3. Refinement 的核心步驟：
Step 1: PO 準備需求
- PO 挑選 Product Backlog 中高優先級但不明確的項目，並提前整理相關資料，如需求描述、業務背景和目標。
- 提前補充需求細節，準備用於演示的圖表或範例，確保團隊能迅速理解。
- PO 也可以在 Refinement 中安排團隊對項目進行估點，為 Sprint Planning 提前做準備。
Step 2: 需求澄清
- PO 向開發團隊解釋需求內容，包括功能範疇、使用場景和預期效果。
- 團隊可就模糊或不清晰的部分進行提問，並與 PO 討論是否需要進一步拆分，例如將過大的需求（如 Epic）拆解為更小的 User Stories。
Step 3: 確認 DoD 和 AC
- 完成標準（DoD）： 討論交付項目完成的必要條件，例如程式碼品質、測試覆蓋率或文檔更新。
- 驗收標準（AC）： 明確需求的驗收條件，確保交付物符合業務目標和用戶需求。
Step 4: 任務估點
- 團隊根據需求細節和可能的技術實現方式，對任務進行估算。常用費波納西數列等方法達成共識。
- 任務的估點幫助 PO 評估開發負擔，並規劃近期 1-2 個 Sprint 的優先事項。
Step 5: 更新 Backlog
- PO 根據 Refinement 的結果，更新 Product Backlog：
- 增加細節描述、補充具體要求。
- 確保選定的需求具備充分準備，可在下一個 Sprint 順利執行。
4. Refinement 的注意事項
1. 提前準備： PO 應準備好需求資料，包括詳細描述、業務背景和相關圖表，避免會議臨時討論造成效率低下。
2. 聚焦高優先級項目： 避免一次會議覆蓋過多需求，應專注於高優先級且模糊的項目，逐步細化。
3. 確保需求清晰： 將需求拆解到適當大小，並讓團隊達成共識，避免模糊不清的任務進入 Sprint。
4. 控制會議時長： Refinement 的總時長建議每個 Sprint 不超過 1-2 小時，確保不影響衝刺效率。
5. 促進團隊參與： 鼓勵開發團隊積極參與，確保大家對需求有一致的理解，減少後續執行中的分歧。
6. 循環改進： Refinement 是持續進行的過程，無需一次性完成所有需求細化，可逐步處理。
大型團隊 Scrum 框架 : Less & Nexus Scrum
在前面，我們討論了單一團隊如何實行 Scrum 框架，當團隊規模較小時，Scrum 能夠有效推動敏捷開發。然而，隨著公司的規模擴大，若同一產品需要多個 Scrum 團隊協作，單一的 Scrum 框架已不足以應對跨團隊的協作需求。此時，擴展性的框架，如 LeSS（Large-Scale Scrum） 和 Nexus Scrum，成為了更好的選擇。
LeSS 與 Nexus 介紹
1. 大規模 Scrum（LeSS）
LeSS（Large-Scale Scrum）是一種旨在將 Scrum 應用於多個團隊的框架。由 Craig Larman 和 Bas Vodde 創建，LeSS 強調在多團隊環境中保持 Scrum 的簡單性和原則。其核心理念包括：
- 單一產品負責人（Product Owner）：即使有多個團隊，仍保持一位產品負責人，確保產品待辦清單的統一性和優先級。
- 跨功能團隊：每個團隊都具備完成從需求到交付所有工作的能力，減少跨團隊依賴。
- 同步衝刺：所有團隊同時進行衝刺，並在每個衝刺結束時交付一個集成的產品增量。
LeSS 的目標是通過簡化組織結構和流程，提升組織的敏捷性和適應性。
2. Nexus 框架
Nexus 是由 Ken Schwaber 和 Scrum.org 開發的框架，旨在協調 3 到 9 個 Scrum 團隊共同交付單一整合產品。Nexus 在 Scrum 的基礎上增加了以下元素：
- Nexus 整合團隊（Nexus Integration Team）：負責確保各團隊的工作順利整合，解決跨團隊的技術和整合問題。
- 新增事件：如 Nexus 每日 Scrum、Nexus 衝刺規劃會議等，促進團隊間的協作和溝通。
- 單一產品待辦清單：所有團隊共享一個產品待辦清單，確保工作的統一性和協調性。
Nexus 的設計目的是在不改變 Scrum 核心的前提下，提供一個簡單且有效的方法來擴展 Scrum，以應對更大規模的產品開發。
LeSS 與 Nexus 的主要差別及適用情境
- 框架設計的重點
- LeSS（Large-Scale Scrum）： LeSS 更注重簡化組織結構，幫助大型團隊維持敏捷的核心原則。LeSS 鼓勵通過減少層級、削減非必要流程來提升效率，適合希望在產品開發中減少複雜性的公司，並且對流程整合要求不高的情境。
- Nexus Scrum： Nexus 專注於多個團隊在技術層面的整合，並設計了專門的角色（Nexus Integration Team）來解決跨團隊間的協作與技術問題。因此，它特別適用於需要處理技術性挑戰、高整合需求的環境。
- 框架規模
- LeSS 適合 2 到 8 個團隊的中型到大型組織，但在實施上更具彈性，特別適合跨功能團隊的協作。
- Nexus 則針對 3 到 9 個團隊設計，並以更結構化的方式應對多團隊同步整合，適合技術密集型項目。
- 核心設計
- LeSS 保持單一產品負責人（PO）和統一產品待辦清單的簡單性，強調跨功能性與單點管理。
- Nexus 增加了專門事件和角色來解決多團隊之間的整合挑戰，尤其在代碼合併、持續交付和技術整合方面表現出色。
適用情境差別
- 如果公司希望通過簡化組織結構來提升效率，並且對跨團隊的技術整合需求不高，選擇 LeSS 是比較合適的。
- 如果公司涉及高技術整合、需要在短時間內多團隊協作完成高質量交付，則 Nexus 是更優的選擇。
通過根據實際需求選擇適合的框架，企業能更好地在規模化協作中保持敏捷的敏捷精神與高效運作。這兩個框架各有特點，組織可根據自身需求選擇最適合的擴展方法。
如需更深入的了解，建議參考以下資源，助你更深入地理解和選擇適合組織的Scale Scrum 框架：
- LeSS 官方網站：提供關於 LeSS 框架的詳細資訊和實施指南。
- Scrum.org 的 Nexus 介紹：詳細說明 Nexus 框架的結構和實施方法。
- Visual Paradigm 的擴展敏捷框架比較：對 LeSS、Nexus 等框架進行了比較和分析。
Scrum Myth 六大迷思
迷思 1：Scrum Master 是決策者
真相：
Scrum Master（簡稱 SM）不是決策者或專案經理，而是一位教練、觀察者與促進者。他們的職責在於支持團隊，幫助團隊實現 自組織、落實敏捷原則，並清除阻礙 (沒有實務上運作經歷，一般人可能很難理解這個角色到底在做什麼，但其實就可以理解 Scrum 團隊也是一隻球隊，好的球隊也是會有明星教練加持指導的，但若團隊都已經自行運作很好，最終目的團隊是不需要有 Scrum Master 存在的，只是再怎麼厲害的明星球團，是否都能達到自組織的境界，可能也真的不容易唷)。
- 舉例： 一位耐心的 SM 會運用像 DBA（Don’t Be Anxious，不要焦慮） 這樣的技巧，給予團隊成長空間，同時確保方向不偏離。他們的角色是引導而非指揮，鼓勵團隊自主決策並為結果負責。
迷思 2：Scrum 可以保證時程精準且開發速度加快
真相：
Scrum 無法保證精準的時間估算或立即提高開發速度，而是強調經驗驅動（Empirical Research）和迭代改善。
- 重新估算： Scrum 鼓勵在每次 Sprint 中根據學到的經驗重新評估估算，逐步提高準確性。
- 有行動力的洞察： 雖然 Scrum 不會瞬間加快開發速度，但透過頻繁的檢視，它能發現流程中的低效問題，進而幫助團隊逐步解決。
迷思 3：導入 Scrum 就能自動解決所有問題
真相：
Scrum 是用來揭示問題的框架，而非自動解決問題的工具。如果沒有積極行動，即便發現問題也無法解決。例如：
- 進行中的工作（WIP）是浪費： Scrum 鼓勵團隊專注於完成單一項目，而非同時進行多項工作，從而減少未完成的工作累積。
- 透明與對齊： 成功實施 Scrum 的前提是組織擁有清晰的目標和透明的績效指標（如 KPI）。若團隊缺乏一致的願景，即使最好的流程也難以取得成果。
迷思 4：Scrum 適用於所有情境
真相：
Scrum 並非萬能工具，它最適合應對需求變化快或不確定性高的環境。若是處於需求穩定、時程可預測的行業（例如壟斷市場），Scrum 的迭代方法可能會增加不必要的複雜性。
迷思 5：Scrum 更注重專案而非產品
真相：
Scrum 的核心是產品導向而非專案導向。它更注重透過迭代交付增量價值，而不是追求固定的專案期限。
- 專案 vs. 產品： 實施 Scrum 的團隊應致力於實現產品的長期願景，而非僅僅完成個別的專案任務。這需要團隊在各層面上保持目標一致與緊密合作。
迷思 6：Scrum 假設人性本善，人人都會自動進步
真相：
Scrum 的核心建立在信任、協作和人性潛力之上。它鼓勵跨領域學習與短周期檢視，以創造積極的組織影響。然而，成功仍取決於團隊成員是否展現：
- 信任： 對彼此和流程的信心。
- 誠實： 無懼地揭露挑戰和問題。
- 尊重： 對多元觀點的包容與接納。
- 關懷： 建立互相支持的文化。
Scrum 的核心哲學：在變化中前進
Scrum 的核心在於為應對變化提供結構化的框架，其目的是幫助團隊在複雜的環境中適應和持續改進。要成功實施 Scrum，關鍵不在於盲目套用，而在於深刻理解其原則並靈活應用於自己的情境。
破解這些迷思後，團隊將能以更務實的期待迎接 Scrum，進一步釋放其在產品開發與團隊合作中的真正潛力。
書籍推薦
如果你對 如何在大型團隊中成功導入 Scrum 框架 有更深入的興趣，除了本篇文章提到的核心概念，推薦閱讀 《多團隊高效協作密技：大規模敏捷開發方法 Large Scale Scrum 簡單學》。
這本書詳細介紹了 LeSS 的導入原則、團隊組織、跨團隊協作方式，並透過 實際案例分析，幫助你理解如何讓 多團隊開發保持高效並真正落實敏捷精神。不論你是 PM、ScrumMaster，或是負責推動敏捷轉型的管理者，這本書都能提供你寶貴的實戰指引！ 📖✨
結論 Recap
除了深入解析大型團隊的 Scrum 框架 LeSS & Nexus Scrum，我們還釐清了 Scrum Myth 六大迷思，打破常見誤解！接著，幫大家 Recap Sprint Cycle 的各項會議重點。現在，試著遮住下方欄位，自己測試一下是否掌握關鍵概念吧！💡🔥
| 會議 | Planning | Daily Scrum | Review | Retrospective | Refinement |
| 定義 | 設定新 Sprint 的目標與計劃，確認要完成的待辦項目（Sprint Backlog）。 | 每日短會，快速同步進度，解決阻礙。 | 檢視 Sprint 產出的成果，與利益相關者討論是否符合預期目標。 | 檢討上一個 Sprint 的執行情況，找出成功之處與可改進的地方，持續提升團隊效率與合作。 | 定期檢查與優化 Product Backlog 的項目，確保需求清晰、可執行，為未來的 Sprint 做好準備。 |
| 參與者 | – 開發團隊：提供技術預估- Scrum Master：引導討論 – PO：定義目標與優先級 | – 開發團隊：每位成員更新進度 – Scrum Master：引導流程 – PO : Optional，可以從旁補充需求 | – 開發團隊：展示完成的成果 – PO : 驗收成果，收集回饋 – 利益相關者：參與檢視並提出意見 | – 開發團隊：提供回饋與建議 – Scrum Master：主持會議，記錄行動項目 – PO : 從業務角度參與討論 | – 開發團隊：確認技術可行性 – PO : 明確需求細節、優先級 – Scrum Master：協助組織流程 |
| 會議目標 | – 設定 Sprint 的目標與範圍 – 分配 Sprint 期間的工作 | – 更新進度，發現並解決問題 | – 確認 Sprint 是否達到目標 – 收集利益相關者的回饋 | – 回顧 Sprint 成果，找出可以改進問題 – 訂定可執行的改進行動項目 | – 將模糊的需求細化為具體項目- 更新任務優先級 – 確保 Backlog 項目符合 DoR（Definition of Ready） |
| 時間 | – 每個 Sprint 開始時舉行 – 時間限制：2~4 小時（視 Sprint 長度而定） | – 每日進行 – 時間限制：15 分鐘 | – 每個 Sprint 結束時舉行 – 時間限制：1~2 小時（視 Sprint 長度而定） | – 每個 Sprint 結束時舉行 – 時間限制：45分鐘~1.5 小時內（視 Sprint 長度而定） | – 定期舉行（如每週一次） – 時間限制：1~2 小時 |
| 關鍵步驟 | Step 1: 訂定 Sprint Goal Step 2: 挑選並拆解Product Backlog 項目 Step 3: 任務估點（工作量評估） Step 4: 設定 Sprint Backlog Step 5: 風險預測與資源分配 | Step 1: 確認會議時間與地點 Step 2: 每人回答三個關鍵問題 Step 3: 團隊進行快速對齊 | Step 1: 回顧 Sprint 目標 Step 2: 開發團隊展示成果 Step 3: 收集利害關係人的反饋 Step 4: 探討下一步改進方向 | Step 1: 打造開放的會議氛圍 Step 2: Safety Check 或 ESVP（探討安全感） Step 3: 回顧 Sprint 目標和項目 Step 4: 選擇 Retro 方法，進行討論 Step 5: 制定具體的行動計劃並追蹤 | Step 1: PO 準備需求 Step 2: 需求澄清 Step 3: 確認 DoD 和 AC Step 4: 任務估點 Step 5: 更新 Backlog |
| 舉例 | – 目標：完成用戶註冊功能 – 任務拆解： 1. 設計前端界面 2. 開發後端 API 3. 測試整合流程 | – 進度更新：完成了介面設計，今天將測試 – 問題：測試工具使用上有問題 | – 成果展示：新增的註冊功能演示 – 回饋：建議在註冊過程中加入更多引導 | – 問題分析：測試階段經常超時，導致後續壓力增加 – 改進 Action：縮短開發周期，留更多測試時間；引入自動化測試 | – 需求提出：新增報告導出功能 – 細化規格： 1. 前端界面設計 2. 後端 API 開發 3. 整合與測試 – 優先級調整：因高業務價值而將某項目提至高優先級 |
Scrum 是輕量級框架，能幫助團隊快速回應變化，但它 不是萬靈丹，而是需要靈活調整的工具。每個團隊都有獨特挑戰，關鍵在於 持續優化、快速試錯、吸收經驗，才能真正落實 being agile，在變局中穩站不敗之地！🚀
敏捷開發讓團隊更靈活高效，但 決策若沒有數據支撐，一切只是憑感覺前進。作為產品經理，除了掌握開發流程，培養數據洞察力同樣關鍵！
因此，第十堂課我們要聊的就是 「產品經理數據分析四步驟」，帶你從 數據小白成長為能夠提煉有價值洞察的 PM。第十堂課 : 產品經理數據分析四步驟，從數據小白到胸有點墨的數據洞察 這堂課不會讓你馬上變成數據科學家，而是幫助你學會 拆解指標、判讀數據趨勢，並用數據驅動決策，讓你的產品優化不再是「憑感覺」，而是有理有據地前進！ 🚀
📩 歡迎交流！看完文章後，若有任何想法、建議或想一起討論的話，隨時歡迎來信交流！
Miss 六月奶茶聯絡信箱 : junemilktea6@gmail.com
