2020 Scrum Guide 的更改與更新說明 (Part 1)

2023/06/10閱讀時間約 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 中均存在。而現在他們則有了更清晰的位置和目的。

Photo by/on Scrum Inc.

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

查看全部

發表第一個留言支持創作者！

KKtalks 的其他內容

價值流管理與價值流圖：機會與陷阱

價值流管理(Value Stream Management) 能讓你決定可衡量的價值流、價值交付在哪裡慢下來，以及為團隊更好的協調和合作而創造機會。這是精實運作上很關鍵的觀念，它促成敏捷產品開發和交付的成功。但你如何知道你是否有影響？若你不管理價值流，會發生什麼事情？...

#流程 #管理 #團隊

Backlog Refinement 帶領你把願景兌現成價值

Backlog Refinement 能為開發而準備好你所需的 Backlog 。投資此事，能幫助你更快的交付價值、倍增你的生產力，以及建立強大的協作 —即高績效團隊的支柱。我們發現 Product Owner 在 Backlog Refinement上，需要更進一步的訓練...

#產品 #開發 #流程

幫助 Scrum Team 更了解Acceptance Criteria（AC）的一篇文

在我們實踐 Scrum 的過程中，總有許多機會能接觸到 User Story ，而在觸及 User Story 時，又經常能談論到 Acceptance Criteria（AC），AC 的常見中譯名為「驗收準則」，顧名思義為「驗收某種東西的標準原則」，然而，這項名詞卻時常讓我們感到混淆，到底驗收..

#Scrum #Agile #敏捷開發

Product Owner 如何跟 Scrum Master 密切工作

共同作者：Shalom Chin 與 KK；譯者：KK 你的 Product Owner (PO) 和 Scrum Master (SM) 能良好合作嗎？你的 SM 和開發人員是否將 PO 視為 Scrum 團隊的一份子？ Scrum 是以強大團隊合作為基礎的工作方式，尤其是 PO 和 SM 之間的

#Agile #Scrum #敏捷