2020 Scrum Guide 的更改與更新說明 (Part 1)
閱讀時間約 10 分鐘
本文已取得 Scrum Inc. 官方授權翻譯，原文為：2020 Scrum Guide Changes and Updates Explained https://www.scruminc.com/2020-scrum-guide-changes-updates-explained/
2020 Scrum Guide 包含許多更新和更改，這讓它成為目前最佳的指南。如果你還沒有看過，你可以在這邊找到 2020 Scrum 指南的 pdf、翻譯和線上版本。
你也能透過看官方的《2020 Scrum Guide Launch event》影片，來了解更多的更改。
這個最新的迭代，更乾淨、更清晰、更普遍適用。 2020 Scrum Guide 的更新，目的在於推動創新、創造和成功所需的文化、焦點和一致性。
每天，全世界有數以千萬的人們為了 15 分鐘 Daily Scrum 而聚集在一起。這是一個令人謙卑的需要思考的事實。我們要感謝每一個人，謝謝你們當中的許多人，他們幫助提供了有助於 2020 Scrum Guide 更新的深入見解、數據和真實世界的經驗。
為什麼我們更新了 Scrum Guide
從 2010 年首次發布 Scrum Guide 以來，它一直是一份不段更新的文件。我們運用經驗主義週期性地 Scrum 這份 Scrum Guide。正如這份指南提到的：
Empiricism asserts that knowledge comes from experience and making decisions based on what is observed.（經驗主義斷言：知識由經驗而來，並依據觀察到的情況做出決定。
就真的狀況而言，Scrum 沒有改變，我們對它的描述變得更好了，僅僅是因為我們得到了有關人們如何使用它的回饋。迭代以獲得更好的結果
2020 Scrum Guide 處理了隨著框架的使用而增長的我們與許多其他人觀察到的常見誤譯和誤解。
2020 Scrum Guide：更改概述
你將在下方內容中，找到說明 2020 Scrum Guide 裡隱藏在確切更改和更新後的「更改的內容」和「更改的原因」。讓我們先從指南中的制高點概述來開始說明：
較少的規範語言
更新後的 2020 Scrum Guide 只有 13 頁，在保持最低可行框架的標準的同時，規範的比以往更少。目的在於賦權於 Scrum 團隊和組織，讓他們能夠按預期的運用指南；它是一本描述規則的書，而不是劇本。較少規範的方法，能在如何實施 Scrum 上，同時保持對框架的如實運用，引領出更多的創新和適應。
更清晰、更普遍通用的 Scrum Guide
Scrum 在 Scrum 團隊和組織看到框架如何為他們所用時，是最容易的，無論是哪個產業、領域、產品或功能。這就是為什麼我們讓更新後的 2020 Scrum Guide 更容易為每個人取得和理解的原因，它遠遠超出了技術事務。
Scrum Artifacts 和他對應的承諾
在這三個 Artifacts 中的每一個，現在都有其對應的「承諾」。它們是為了帶來透明度和焦點，並以此衡量進展。 Product Backlog 的承諾是 Product Goal、Sprint Backlog 的則是 Sprint Goal，而 Increment 則為 Definition of Done。
2020 Scrum Guide 帶出 Product Goal 的概念，為 Scrum 團隊提供了長期要關注的點。每個 Sprint 都應該使產品更靠近整體的 Product Goal。Sprint Goal 和 Definition of Done 在前一個版本的 Scrum Guide 中均存在。而現在他們則有了更清晰的位置和目的。
Scrum Master：由「僕人領導者（Servant Leader）」到「助於實現目標的領導者（A Leader Who Serves）」
這項更改無庸置疑地會讓許多人感到驚訝。但別被耍了，這些字的重新排序更佳描繪了 Scrum Master 一直以來的目的和職責。
備註：此處我將「A Leader Who Serves」翻譯成「助於實現目標的領導者」，考量點之一為若直譯成「服務」會失去原本強調 Scrum Master 為「True Leader」的意涵，考量點其二， serve 有另一層意思為 「to help achieve something or to be useful as something」，故以此為原則，將「A Leader Who Serves」翻譯成「助於實現目標的領導者」更接近原意與改版目的。
專注於一個產品的統合為一的團隊
較早期的 Scrum Guide 提到了兩個團隊，指「開發團隊」（完成工作的人）和「Scrum 團隊」（包括開發團隊、 Scrum Master 和 Product Owner）。團隊中「單獨團隊的概念（this concept of a separate team）」，有時會導致「我們和他們」的關係，出現在 Product Owner 和 Development Team 之間。現在只有一個團隊，即 Scrum Team，這團隊專注於相同目標，並且在其中的 Product Owner、Scrum Master 和 Developers 這三種角色，各自都擔負不同系列的責任。
「自我管理」優於「自我組織」
先前的 Scrum Guide 將 Development Teams 稱為自我組織，這意指他們選擇了誰來執行工作與如何執行工作。 2020 版本的 Scrum Guide 更關注在 Scrum Team 上，強調「自我管理的 Scrum Team」能選擇要做什麼、誰來做，以及如何完成。
Sprint Planning 的三個主題
除了先前版本提到的「做什麼」和「如何做」的 Sprint Planning 主題外，2020 Scrum Guide 還新增了一項新主題「為什麼要做」，此即為 Sprint Goal。
在 Scrum Guide 上，已永久消失的內容
為了保持最小可行框架的標準，一些內容已從 2020 Scrum Guide 中刪除。然而，這並非指其在 Scrum 中失去位置或不應該被使用。與 Yesterday’s Weather 和其他未在 Scrum Guide 中被未明確包含的 Scrum Patterns 一樣，這些是可以選擇用來幫助打造高績效 Scrum Team 的實踐方式。
下方是 2020 Scrum Guide 中，不再包含的主要概念及其原因：
1. 在 Daily Scrum 時的那三個問題：
你可能記得很清楚：你昨天做了什麼來幫助 Development Team 實現 Sprint Goal、你今天將做什麼來幫助 Development Team 實現 Sprint Goal、你是否看到任何阻礙自己或 Developemt Team 實現 Sprint Goal 的障礙？這三個問題雖然有效，但過度規範和限制。正如 2020 Scrum Guide 所述：
Daily Scrum 的目的在於檢查 Sprint Goal 的進展，並依照需要調整 Sprint Backlog，調整即將到來的計劃好要做的工作。
有很多方法能達成這個目的。
2. Daily Scrum 後的「停車場（Parking Lot」
有時 Daily Scrum 要辨識出需要在此Event的 15 分鐘的時間限制之外的對談。先前的指南提到，這些對談通常被稱為「停車場」，並發生在 Daily Scrum 之後。 2020 Scrum Guide 讓 Scrum Team 決定何時要進行這些重要的對談。
3. 描述 Scrum Master、Product Owner 和 Developers 時用的「角色」一詞
在部份情況，「角色」這個詞被誤解了。 Scrum 從來都不是關於創造標題分類學的事。角色從未想成為一個頭銜（或職稱）。重點在於明確界定誰對什麼事負責任。因此，2020 年 Scrum Guide 包括了這段話：
整個 Scrum Team 負責在每個 Sprint 中創建有價值且有用的 Increment。 Scrum 在 Scrum Team 中，定義了三個具體的職責：Developers、Product Owner 和 Scrum Master。
這項變化將重點放於它實際的歸屬，即具體的當責（accountability）。如果你喜歡，你仍然可稱它們為「角色」。我們喜歡這樣，但我們也強調這些角色具備其明確的當責責任。
4. 只由 Product Owner 帶領 Sprint Review
先前的指南讓 Product Owner 領導 Sprint Review。Scrum Team 的其他成員扮演更多支持性的角色。 2020 Scrum Guide 現在則以整個 Scrum Team、顧客和利害關係人為主。
5. 不再有「團隊中的團隊」
如前面所述，Scrum Team 內部的「Development Team」的概念已經被解釋、處理完成了。
6. Sprint Retrospective 中過度規範/規定的用語
這個 Scrum Event 的整體描述已縮減，改為著重真正重要的「流程改善」、「團隊幸福感/開心感」以及「凝聚力」。這提供各 Scrum Team 在如何進行 Sprint Retrospective 上，更具彈性。
7. Backlog Refinement 的時間限制（timebox）
先前的指南提到「通常不超過團隊一個 Sprint 的 10% 的時間，應該用於精煉 Product Backlog」。2020 Scrum Guide 刪除這個數字，賦權於 Scrum Team，讓他們決定需要多少時間，來精煉和理解 Product Backlog。
其他 Scrum Guide 更新，請期待：2020 Scrum Guide 的更改與更新說明 (Part 2)
9會員
28內容數
一生懸命在「改善臺灣職場與職人能力」的使命，有十餘年產品和團隊管理經驗。期待透過推廣產品管理知識與管理實務，改善對臺灣職人能力，讓企業因此而更有競爭力，因此創立臺灣產品人學會 （POA) 。
現任：
- 臺灣產品人學會 (POA) 理事長
- 生活和職涯教練
- 臺灣百大企業 Agile Coach
留言0
查看全部
你可能也想看
Google News 追蹤
徵的就是你 🫵 超ㄅㄧㄤˋ 獎品搭配超瞎趴的四大主題，等你踹共啦！還有機會獲得經典的「偉士牌樂高」喔！馬上來參加本次的活動吧！
隨著理財資訊的普及，越來越多台灣人不再將資產侷限於台股，而是將視野拓展到國際市場。特別是美國市場，其豐富的理財選擇，讓不少人開始思考將資金配置於海外市場的可能性。
然而，要參與美國市場並不只是盲目跟隨標的這麼簡單，而是需要策略和方式，尤其對新手而言，除了選股以外還會遇到語言、開戶流程、Ap
「Scrum的用意是為科技業設想一套更快速，更可靠，更有效的軟體開發手法。」
「Scrum源自於 Toyota生產系統，以及空戰的OODA循環。」
「設定為期一週至一個月的“衝刺 Sprint"，以維持動能，讓每個成員承擔應有的責任。」
「進行簡短的"每日立會 Daily St
敏捷開發的實踐方式有很多，其中以簡單、易懂的 Scrum 框架最廣為大家接受。 2024年7月 LeSS 網站發布了新一版的《Scrum 指南》，其中調整的內容我覺得讓這個框架更符合實務上的應用，因此就其內容並結合個人經驗與見解撰寫這篇短文，希望幫助大家快速了解這套能幫助團隊適應變化的敏捷開發方法。
如何有效運用Scrum的船舶理論來主持專案檢討會。船舶理論將專案比作船，通過風帆、礁石、錨等元素可視化檢討內容。會議前的準備、進行步驟及專案經理的主持技巧，幫助團隊在輕鬆愉快的氛圍中總結經驗、識別問題、制定改進計劃，從而提升未來專案的成功率。
在數位時代，Scrum已成為專案管理的利器。本文介紹Scrum的核心角色、工件和事件，並結合我開發CDP的實際經驗，分享如何通過產品待辦清單管理、Sprint計劃與執行、每日站會和Sprint回顧來提升專案靈活性與效率。希望能啟發更多專案經理運用Scrum，優化專案流程。
當企業協作不順暢、組織僵化、工作模式老舊時，本書告訴你如何透過OGSM重塑高敏捷的團隊。
我認為高敏捷團隊有三大重點：
全員有共識，朝著共同目標前進
定期審視成效，進行調整與改進
塑造更有價值的團隊
一、什麼是OGSM？
書中解釋，OGSM變革領導以一頁表格的方
敏捷開發方法已成為現代軟體開發領域的一個關鍵趨勢。其主要目的是通過快速和增量的開發過程，提高開發效率和應對變化的能力。本文將深入探討Scrum和Kanban這兩種流行的敏捷方法的基本原理，實際應用案例，以及實施過程中可能遇到的挑戰和解決策略。
在瞬息萬變的商業環境中，如何引領團隊從被動執行轉為主動思考？這篇文章分享了一個部門營業目標的轉型實例，包括轉型契機與挑戰、設定績效目標的關鍵步驟、轉型後的成果與反思，並給予其他主管的建議。透過明確的目標、可量化的指標、有效的溝通與回饋，成功實現了從被動到主動、從執行到創新的轉變。
本文介紹了在公司專案中採用敏捷(Agile)方法，並分享了Scrum的好處、成員負責工作以及工作流程。希望可以掌握Scrum的核心：透明度、檢視和調整的核心，來推動敏捷工作。
本文探討專案管理的真正意義，以及專案經理真正的價值是什麼。同時討論專案經理必修的最重要技能。
徵的就是你 🫵 超ㄅㄧㄤˋ 獎品搭配超瞎趴的四大主題，等你踹共啦！還有機會獲得經典的「偉士牌樂高」喔！馬上來參加本次的活動吧！
隨著理財資訊的普及，越來越多台灣人不再將資產侷限於台股，而是將視野拓展到國際市場。特別是美國市場，其豐富的理財選擇，讓不少人開始思考將資金配置於海外市場的可能性。
然而，要參與美國市場並不只是盲目跟隨標的這麼簡單，而是需要策略和方式，尤其對新手而言，除了選股以外還會遇到語言、開戶流程、Ap
「Scrum的用意是為科技業設想一套更快速，更可靠，更有效的軟體開發手法。」
「Scrum源自於 Toyota生產系統，以及空戰的OODA循環。」
「設定為期一週至一個月的“衝刺 Sprint"，以維持動能，讓每個成員承擔應有的責任。」
「進行簡短的"每日立會 Daily St
敏捷開發的實踐方式有很多，其中以簡單、易懂的 Scrum 框架最廣為大家接受。 2024年7月 LeSS 網站發布了新一版的《Scrum 指南》，其中調整的內容我覺得讓這個框架更符合實務上的應用，因此就其內容並結合個人經驗與見解撰寫這篇短文，希望幫助大家快速了解這套能幫助團隊適應變化的敏捷開發方法。
如何有效運用Scrum的船舶理論來主持專案檢討會。船舶理論將專案比作船，通過風帆、礁石、錨等元素可視化檢討內容。會議前的準備、進行步驟及專案經理的主持技巧，幫助團隊在輕鬆愉快的氛圍中總結經驗、識別問題、制定改進計劃，從而提升未來專案的成功率。
在數位時代，Scrum已成為專案管理的利器。本文介紹Scrum的核心角色、工件和事件，並結合我開發CDP的實際經驗，分享如何通過產品待辦清單管理、Sprint計劃與執行、每日站會和Sprint回顧來提升專案靈活性與效率。希望能啟發更多專案經理運用Scrum，優化專案流程。
當企業協作不順暢、組織僵化、工作模式老舊時，本書告訴你如何透過OGSM重塑高敏捷的團隊。
我認為高敏捷團隊有三大重點：
全員有共識，朝著共同目標前進
定期審視成效，進行調整與改進
塑造更有價值的團隊
一、什麼是OGSM？
書中解釋，OGSM變革領導以一頁表格的方
敏捷開發方法已成為現代軟體開發領域的一個關鍵趨勢。其主要目的是通過快速和增量的開發過程，提高開發效率和應對變化的能力。本文將深入探討Scrum和Kanban這兩種流行的敏捷方法的基本原理，實際應用案例，以及實施過程中可能遇到的挑戰和解決策略。
在瞬息萬變的商業環境中，如何引領團隊從被動執行轉為主動思考？這篇文章分享了一個部門營業目標的轉型實例，包括轉型契機與挑戰、設定績效目標的關鍵步驟、轉型後的成果與反思，並給予其他主管的建議。透過明確的目標、可量化的指標、有效的溝通與回饋，成功實現了從被動到主動、從執行到創新的轉變。
本文介紹了在公司專案中採用敏捷(Agile)方法，並分享了Scrum的好處、成員負責工作以及工作流程。希望可以掌握Scrum的核心：透明度、檢視和調整的核心，來推動敏捷工作。
本文探討專案管理的真正意義，以及專案經理真正的價值是什麼。同時討論專案經理必修的最重要技能。