2020 Scrum Guide 的更改與更新說明 (Part 2)
2023/06/17閱讀時間約 23 分鐘
本文已取得 Scrum Inc. 官方授權翻譯，原文為：2020 Scrum Guide Changes and Updates Explained https://www.scruminc.com/2020-scrum-guide-changes-updates-explained/
上一篇ˊ Scrum Guide 更新，歡迎閱讀 2020 Scrum Guide 的更改與更新說明 (Part 1)
現在，讓我們詳細檢查 2020 Scrum Guide中的主要更新和更改。
2020 Scrum Guide 更新：Scrum Artifact 和承諾
可能 2020 Scrum Guide 中最大的變化在於 Scrum Artifact。 Scrum 中仍然只有三個 Artifact ，即 Product Backlog、Sprint Backlog 和 Increment。每個都代表著工作或價值，其目的在於最大化地提高關鍵資訊的透明度。
現在，每一個 Artifact 都有一個新對應的承諾：
- 對於 Product Backlog ，它的承諾是 Product Goal
- 對於 Sprint Backlog ，它的承諾是 Sprint Goal
- 對於 Increment，它的承諾是 Definition of Done
正如 2020 Scrum Guide 中提到的：
這些承諾的存在，是為了加強 Scrum Team 和利害關係人的經驗主義和 Scrum Values。（These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders.）
當然，承諾是 Scrum Values 之一。在這裡使用這個字，跟每一個 Artifact 的目的都一樣，都是經過深思熟慮的。
想知道更多這些新承諾與它們如何推動關注點、對齊點和價值交付的資訊，請閱讀 Scrum Inc. CEO JJ Sutherland 的《Scrum Guide 2020 Insight》。
為什麼更新這些：更新來自於培訓師的回饋和我們的觀察。這兩者都指出需要關注更多在 Scrum Guide 的目標上。具體而言，是有關如何使團隊在目標與實現目標所需的具體步驟上保持一致。
此外，我們長久以來已知道，專注於明確和具體目標的團隊，會做得更好。
Sprint Goal 對 Scrum Guide 而言並不陌生。然而，迭代為 Sprint Goal 提供了一個家和一個更明確定義的目的。下方提到 2020 Scrum Guide 中 Sprint Goal 的定義方式：
Sprint Goal 是 Sprint 的單一目標。即便 Sprint Goal 是 Developers 的承諾，但它在實現目標所需的確切工作上，提供了彈性。 Sprint Goal 也創造了一致性和關注點、鼓勵 Scrum Team 一起工作，而非獨立作業。（The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.）
Product Goal 是 2020 Scrum Guide 的新內容。新增的原因是我們想帶入更高層級的關注點和對齊點。Product Goal 是實現渴望的產品未來樣貌的具體步驟。 2020 Scrum Guide 是這麼說的：
Product Goal 描述了渴望的產品未來樣貌，可以作為 Scrum Team 進行規劃時會用於聚焦的目標。Product Goal 存在於 Product Backlog 中。Product Backlog 的其他部分用於定義「什麼東西」會實現 Product Goal。（The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.）
最後的新承諾是 Definition of Done。和 Sprint Goal 一樣，它在 Scrum Guide 上也並不陌生。更準確地說，我們給 Definition of Done 一個家和一個更明確定義的目的。但是，在這種脈絡中，它的意涵有些微的變化。 2020 Scrum Guide 這麼描述：
Definition of Done 是滿足產品所需的品質時的 Increment 的正式描述。Product Backlog item 滿足 Definition of Done 的那一刻，一個 Increment 就誕生了。（The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. The moment a Product Backlog item meets the Definition of Done, an Increment is born.）
2020 Scrum Guide 更新：將 Scrum Master 從「僕人領導者（Servant Leader）」提升為「助於實現目標的領導者（A Leader Who Serves）」
另一項需要注意的重要變化有關 Scrum Master 的描述和職責。
從一開始，Scrum Master 的首要目的就是顯著地提高團隊績效。這不只是一項以團隊為中心的活動。這是為什麼 2020 Scrum Guide 中，提到 Scrum Master 時會這樣開頭：
Scrum Master 負責（accountable）按照 Scrum Guide 中的定義建立 Scrum。他們透過幫助每個人了解 Scrum Team 和組織內的 Scrum 理論與實踐來達成這點。（The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.）
2020 Scrum Guide 透過詳細說明 Scrum Master 為組織服務的一些方式，促進對 Scrum Master 角色的更廣泛認識，包括：
在 Scrum 採用上，領導、培訓和教練（coach）組織。（Leading, training, and coaching the organization in its Scrum adoption）
理解 Scrum Master 的這個擴展角色，是理解為什麼我們以「助於實現目標的領導者（A Leader Who Serves）」取代「僕人領導者（Servant Leader）」的關鍵。
透過從「僕人領導者（Servant Leader）」到「助於實現目標的領導者（A Leader Who Serves），我們強調了 Scrum Master 的領導面向。我們無意在 Scrum Team 內創造階級，也不是指 Scrum Master 現在是經理（manager）。
我們所說的是，有效的 Scrum Master 所做的不只是促進 Scrum Event 和表面障礙。他們會是主動，而非被動的。卓越的 Scrum Master 會做必須做的事，以便幫助 Scrum Team 和組織取得卓越的成果。
為什麼更新這些：是時候澄清一個誤解了，這是指一個導致許多組織質疑為什麼需要 Scrum Master 的問題。
在 1986 年，《哈佛商業評論（Harvard Business Review）》發表了 Hirotaka Takeuchi 和 Ikujiro Nonaka 的《The New New Product Development Game》。這篇文章是他們常被稱為 Scrum 教父的主要原因。
在具有深遠影響的這篇著作中，Takeuchi 和 Nonaka 描述了促進類型的團隊領導者如何向上與向下管理（即組織和團隊）。這是他們管理流程的方式。事實上，這是 Scrum Master 的原型。這個人對齊管理層，並且幫助和支持 Scrum Team 把工作做好。
有些人誤解了「僕人領導者（Servant Leader）」這個詞，使我們遠離了真正的領導。所以我們將術語改為「助於實現目標的領導者（A Leader Who Serves）」。
2020 Scrum Guide 更新：從自組織到自我管理 的 Scrum Team
這是一項微妙但重要的變化，因為它進一步賦權了 Scrum Team，同時也明確了他們對實現目標的責任。
先前的 Scrum Guide 提到：「Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.」
2020 Scrum Guide 現在則是這樣描述 Scrum Team：
他們也自我管理，這是指他們能內部決定誰做什麼、何時做，以及如何做。（They are also self-managing, meaning they internally decide who does what, when, and how.）
團隊自我管理，以兌現承諾，並實現目標。
為什麼更新這些：實際上，Scrum 術語和概念可能在工作場所被當成武器。有時由管理層進行。有時由 Scrum Team 自己執行。
許多敏捷開發人員認為，自組織是指「他們能做任何他們想做的事」。這是一個需要被解決的誤解。當智慧系統在環境中找到實現目標的最佳方法時，就會發生自組織。
因此，2020 Scrum Guide 現在使用「自我管理」來闡明概念，並且停止將自組織當成武器，以作為避免實現目標或承諾的藉口。
你可以在 Dr. Jeff Sutherland 寫的有關細胞和團隊的文章中，了解有關為什麼進行這些更改的更多資訊，它與新的 Scrum Guide 習習相關。
2020 Scrum Guide 更新：一個 Scrum Team 專注於一項產品
如前面提到的，早期的 Scrum Guide 提到了兩個團隊，「development team」指的是要完成工作的人，而「Scrum Team」則包含 development team 以及 Scrum Master 和 Product Owner。
團隊中「單獨團隊的概念（this concept of a separate team）」，有時會導致「我們和他們」的關係，出現在 Product Owner 和 Development Team 之間。現在只有一個團隊，即 Scrum Team，這團隊專注於相同目標，並且在其中的 Product Owner、Scrum Master 和 Developers 這三種角色，各自都擔負不同系列的責任。
為什麼更新這些：我們上述的描述，已經涵蓋許多內容了。然而，還有一個值得注意的原因，即讓 Scrum 更容易接觸和理解。
無論是哪種產業、領域、產品或功能，當 Scrum Team 和組織看到框架（framework）如何為他們所用時，Scrum 最能簡單被運用。以「一個團隊概念」中的團隊，可能會讓許多開始實作該框架的人感到困惑。
2020 Scrum Guide 更新：五個 Scrum Event 的更改
2020 Scrum Guide 至少對五個 Scrum Event 有其各自的微小更改。因此，我們將逐一進行介紹。
Sprint Planning：先前的 Scrum Guide 列出了 Scrum Team 應該在此 Event 中討論的兩項主題，即「在即將到來的 Sprint 中，Increment 可以交付什麼，以及如何完成工作」。對這兩項主題的討論，產生了重要的資訊和共同理解，有助於 Scrum Team 實現他們的 Sprint Goal。儘管是為了提供清晰的說明而改寫，但它們仍保留在 2020 Scrum Guide 中。然而，Scrum Team 無法透過只了解「它是什麼」與「如何做」來了解全貌。他們還必須理解「為什麼要做」。因此，一個新的討論主題，就被加入了 Sprint Planning 中。 2020 Scrum Guide 這樣描述：
主題一：為什麼這個 Sprint 有價值？
Product Owner 提出產品如何在當前 Sprint 中，增加價值和實用性。接著，整個 Scrum Team 合作定義一個能傳達出「為什麼 Sprint 對利害關係人有價值」的 Sprint Goal。（Topic One: Why is this Sprint valuable?The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders.）
對「為什麼提供 Scrum Team 前後脈絡的原因」的討論，現實上可能缺乏。我們發現了解 Product Owner 目的的 Scrum Team 能交付更好的結果和更高的品質。
Sprint：2020 Scrum Guide 現在明確指出只有 Product Owner 才能中止 Sprint。這實際上更像是一種闡明，而非更改，因為它是一直以來的既有實作方法。
Daily Scrum：Daily Scrum 的目的維持不變，即檢查 Sprint Goal 的進展，並視情況做出調整與重新規劃 Sprint Backlog。 2020 Scrum Guide 中更改的是方法。先前指南列出的三個問題已在 2020 版本中被刪掉了，取而代之的是下方的較少規範的描述：
Developer 能選擇他們想要的任何結構和技術，只要他們的 Daily Scrum 專注朝向 Sprint Goal 發展，並能為隔天的工作制定可進行的計劃。這創造了關注點，以及改善了自我管理。（The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.）
的確，有很多方法能達到 Daily Scrum 的目的。
例如，歐洲一位 Scrum 教練舉辦的 Daily Scrum 只問一個問題：「為什麼 Backlog 上方的 User Story沒有完成？」這種關注點，使績效提高了 500%。
我們希望讓所有 Scrum Team 能夠靈活有彈性地使用最適合他們的方法。
Sprint Review：在 Scrum 中，工作由團隊完成。我們希望 Sprint Review 能被包含在工作內。在 2020 Scrum Guide 中，Sprint Review 不再由 Product Owner 主導，而是由整個 Scrum Team 領導：
在這個 Event 期間，Scrum Team 和利害關係人檢查 Sprint 中完成的內容以及在他們的環境中發生的變化。依照這資訊，參與者協作決定下一步該做什麼。Product Backlog 也可能會因此調整以滿足新的機會。 Sprint Review 是一個工作會議，Scrum Team 應該避免把它局限在展演/演示。（During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.）
Sprint Review 是顧客、利害關係人和 Scrum Team 討論他們如何實現 Sprint Goal、朝向 Product Goal 前進、哪些問題已經被克服，以及在他們的道路上還有什麼問題存在的場所。
Sprint Retrospective：每一個 Sprint Retrospective 實際上只做兩件事，即尊重人，以及持續改善。如果對話是開放、誠實，並且專注於改進流程和互動，那麼 Retrospective 會是成功的。有許多方法能實現這個。
So we’ve removed the overly prescriptive language to encourage the Scrum Master and the whole Scrum Team to be flexible in finding creative ways to solve problems by first find their root cause. Sometimes these solutions are the removal of impediments. Others are potential process improvements identified by the Scrum Team. As the 2020 Scrum Guide states:
因此，我們刪除了過度規範的語言，以便鼓勵 Scrum Master 和整個 Scrum Team 透過先找到問題的根本原因，來有彈性的找到創造性的方法，以便解決問題。有時，這些解決方案是用來消除障礙。其他的則是由 Scrum Team 發現潛在的流程改善。 如同 2020 Scrum Guide 提到的：
盡快地解決最具影響力的改善。它們甚至可能被加入下個 Sprint 的 Sprint Backlog 中。（The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.）
這也是對先前指南的更改，先前的指南提到這些改善將在下一個 Sprint 中實施。雖然我們認為這仍然是一種引領的實務，但並非必要。所以我們在彈性上犯了錯誤。
結語
我們花費大量生命在工作上。對很多人來說，工作很糟糕。在創造 Scrum 的過程中，我們的願景始終是「讓工作變得快速、簡單和有趣」。如果不好玩，那你就做錯了。
在 Scrum Guide 的最新版本中，我們試圖澄清被誤解的術語。簡化過於複雜的地方。並使框架更易於理解接觸，以便任何組織中的任何團隊，無論是業務或人力資源團隊、無論是從事行銷或財務、開發或策略的團隊，都能拿起 Scrum Guide 並開始使用它。
這一直都是重點。 Scrum 成為 open source 是有原因的。我們希望它的用途能廣為流傳。我們希望幫助人們解決複雜的問題，並完成豐功偉業/成就大事。
We look forward to seeing what the Scrum community achieves next. And we’re proud of what we have already accomplished together.
我們期待看到 Scrum 社群接下來的成就。並且，我們為我們已共同取得的成就感到自豪。
留言0
查看全部