Scrum 指南

2021-10-06

Scrum在 1990 年代初期開發, 2010 年編寫了第一版 Scrum 指南。

Scrum 定義

Scrum 是一個輕量級框架，可幫助人員、團隊和組織通過針對複雜問題的自適應解決方案創造價值。

簡而言之，Scrum 需要一個 Scrum Master 來營造這樣一個環境：

產品負責人 (Product Owner) 將復雜問題的工作安排到產品待辦列表中 (Product Backlog)。
Scrum 團隊在 Sprint 期間將選擇的工作轉化為價值增量 (Increment of Value)。
Scrum 團隊 (Scrum Team) 及其利益相關者 (Stakeholder) 檢查結果並為下一個 Sprint 進行調整。
重複

Scrum 很簡單。按原樣嘗試並確定其哲學、理論和結構是否有助於實現目標和創造價值。Scrum 框架故意不完整，只定義了實現 Scrum 理論所需的部分。Scrum 建立在使用它的人們的集體智慧之上。Scrum 規則不是為人們提供詳細的說明，而是指導他們的關係和互動。

可以在該框架內採用各種過程、技術和方法。Scrum 圍繞現有實踐或使其變得不必要。Scrum 使當前管理、環境和工作技術的相對效率可見，以便進行改進。

Scrum 理論

Scrum 建立在經驗主義和精益思想之上。經驗主義斷言，知識來自經驗，並根據觀察到的東西做出決定。精益思想減少浪費並專注於基本要素。
Scrum 採用迭代的、增量的方法來優化可預測性和控制風險。Scrum 讓一群人共同擁有完成工作的所有技能和專業知識，並根據需要分享或獲得這些技能。
Scrum 結合了四個正式事件，以便在一個包含事件（Sprint）中進行檢查和調整。這些事件之所以有效，是因為它們實現了透明、檢查和適應的經驗 Scrum 支柱。

透明度 (Transparency)

緊急過程和工作必須對執行工作的人和接受工作的人可見。使用 Scrum，重要的決策是基於其三個正式工件的感知狀態。透明度低的工件可能會導致做出降低價值和增加風險的決策。

透明度使檢查成為可能。不透明的檢查是誤導和浪費的。

檢查 (Inspection)

Scrum 工件和達成一致目標的進度必須經常和勤奮地檢查，以發現潛在的不受歡迎的差異或問題。為了幫助檢查，Scrum 以五個事件的形式提供了節奏。

檢查使適應成為可能。沒有適應的檢查被認為是沒有意義的。Scrum 事件旨在激髮變革。

適應 (Adaptation)

如果過程的任何方面超出可接受的範圍，或者如果產生的產品不可接受，則必須調整正在應用的過程或正在生產的材料。必須盡快進行調整，以盡量減少進一步的偏差。

當相關人員沒有被授權或自我管理時，適應變得更加困難。Scrum 團隊應該在通過檢查學習任何新事物的那一刻進行調整。

Scrum 價值觀

Scrum 的成功使用取決於人們更加精通以下五個價值觀：

承諾 (Commitment)、專注 (Focus)、開放 (Openness)、尊重 (Respect)和勇氣 (Courage)

Scrum 團隊致力於實現其目標並相互支持。他們的主要重點是 Sprint 的工作，以盡可能實現這些目標。Scrum 團隊及其利益相關者對工作和挑戰持開放態度。Scrum 團隊成員相互尊重，成為有能力、獨立的人，並受到與他們一起工作的人的尊重。Scrum 團隊成員有勇氣做正確的事情，解決棘手的問題。

這些價值觀為 Scrum 團隊的工作、行動和行為指明了方向。做出的決定、採取的步驟和使用 Scrum 的方式應該加強這些價值觀，而不是削弱或削弱它們。Scrum 團隊成員在處理 Scrum 事件和工件時學習和探索價值。當這些價值觀被 Scrum 團隊和與他們一起工作的人體現時，透明度、檢查和適應的經驗性 Scrum 支柱就會建立信任。

Scrum 團隊

Scrum 的基本單位是一個小團隊，一個 Scrum 團隊。Scrum 團隊由一名 Scrum Master、一名產品負責人和開發人員組成。在 Scrum 團隊中，沒有子團隊或層次結構。它是一個由專業人士組成的有凝聚力的單位，一次專注於一個目標，即產品目標。

Scrum 團隊是跨職能的，這意味著成員擁有在每個 Sprint 中創造價值所需的所有技能。他們也是自我管理的，這意味著他們在內部決定誰做什麼、什麼時候做什麼以及如何做。

Scrum 團隊小到可以保持敏捷，大到可以在 Sprint 中完成重要工作，通常為 10 人或更少。總的來說，我們發現較小的團隊溝通更好，效率更高。如果 Scrum 團隊變得太大，他們應該考慮重組為多個有凝聚力的 Scrum 團隊，每個團隊都專注於相同的產品。因此，他們應該共享相同的產品目標、產品待辦列表和產品負責人。

Scrum 團隊負責所有與產品相關的活動，包括利益相關者協作、驗證、維護、運營、實驗、研究和開發，以及任何其他可能需要的活動。他們由組織構建並授權來管理自己的工作。以可持續的速度在 Sprint 中工作可以提高 Scrum 團隊的注意力和一致性。

整個 Scrum 團隊負責在每個 Sprint 中創建有價值的、有用的增量。Scrum 在 Scrum 團隊中定義了三個特定的職責：開發人員、產品負責人和 Scrum 主管。

開發人員 (Developers)

開發人員是 Scrum 團隊中致力於在每個 Sprint 中創建可用增量的任何方面的人員。

開發人員所需的特定技能通常很廣泛，並且會因工作領域而異。但是，開發人員始終負責：

為 Sprint 制定計劃，即 Sprint Backlog；
通過堅持完成的定義 (Definition of Done) 來灌輸質量；
每天根據 Sprint 目標 (Sprint Goal) 調整他們的計劃；和，
作為專業人士相互問責。

產品擁有者 (Product Owner)

產品負責人負責最大化由 Scrum 團隊工作產生的產品價值。如何做到這一點可能因組織、Scrum 團隊和個人而異。

產品負責人還負責有效的產品待辦列表管理，其中包括：

制定並明確傳達產品目標；
創建並清楚地傳達產品待辦事項列表項；
訂購產品待辦列表項；和，
確保產品待辦列表透明、可見和理解。

產品負責人可以完成上述工作，也可以將責任委託給其他人。無論如何，產品負責人仍然負責。

產品負責人要取得成功，整個組織都必須尊重他們的決定。這些決定在產品待辦列表的內容和順序中是可見的，並且通過 Sprint 評審中的可檢查增量可見。

產品負責人是一個人，而不是一個委員會。產品負責人可能代表產品待辦列表中許多利益相關者的需求。那些想要更改產品待辦列表的人可以通過嘗試說服產品負責人來實現。

Scrum大師 (Scrum Master)

Scrum Master 負責建立 Scrum 指南中定義的 Scrum。他們通過幫助 Scrum 團隊和組織內的每個人了解 Scrum 理論和實踐來做到這一點。

Scrum Master 對 Scrum 團隊的有效性負責。他們通過讓 Scrum 團隊在 Scrum 框架內改進其實踐來做到這一點。

Scrum Master 是真正的領導者，為 Scrum 團隊和更大的組織服務。

Scrum Master 以多種方式為 Scrum 團隊服務，包括：

指導團隊成員進行自我管理和跨職能；
幫助 Scrum 團隊專注於創造滿足完成定義的高價值增量；
消除阻礙 Scrum 團隊進展的障礙；和，
確保所有 Scrum 事件發生並且是積極的、富有成效的，並保持在時間範圍內。

Scrum Master 以多種方式為產品負責人服務，包括：

幫助找到有效的產品目標定義和產品待辦列表管理的技術；
幫助 Scrum 團隊理解清晰簡潔的產品待辦列表項的必要性；
幫助建立復雜環境的經驗性產品規劃；和，
根據要求或需要促進利益相關者的協作。

Scrum Master 以多種方式為組織服務，包括：

領導、培訓和指導組織採用 Scrum；
計劃和建議組織內的 Scrum 實施；
幫助員工和利益相關者理解和製定複雜工作的經驗方法；和，
消除利益相關者和 Scrum 團隊之間的障礙。

Scrum 事件 (Scrum Events)

Sprint 是所有其他事件的容器。Scrum 中的每個事件都是檢查和調整 Scrum 工件的正式機會。這些事件專門設計用於實現所需的透明度。未能按規定操作任何事件會導致失去檢查和適應的機會。在 Scrum 中使用事件來創建規律性並最小化 Scrum 中未定義的會議的需求。

最理想的是，所有活動都在同一時間和地點舉行，以降低複雜性。

衝刺 (Sprint)

Sprint 是 Scrum 的心跳，在這裡將想法轉化為價值。

它們是一個月或更短的固定長度事件，以創建一致性。新的 Sprint 在上一個 Sprint 結束後立即開始。

實現產品目標所需的所有工作，包括 Sprint 計劃 (Sprint Planning)、每日 Scrums (Daily Scrum)、Sprint 審查 (Sprint Review) 和 Sprint 回顧 (Sprint Restrospective)，都在 Sprint 中進行。

在 Sprint 期間：

沒有進行會危及 Sprint 目標 (Sprint Goal) 的更改；
質量不下降；
產品待辦列 (Product Backlog) 表根據需要進行細化；和，
隨著了解的更多，範圍可能會被澄清並與產品負責人重新協商。

衝刺通過確保至少每個日曆月檢查和調整產品目標的進度來實現可預測性。當 Sprint 的期限太長時，Sprint 目標可能會失效，複雜性可能會增加，風險可能會增加。可以採用更短的 Sprint 來產生更多的學習週期，並將成本和努力的風險限制在更短的時間範圍內。每個 Sprint 都可以被視為一個短期項目。

存在各種用於預測進度的實踐，例如燃盡、燃盡或累積流量。雖然被證明是有用的，但這些並不能取代經驗主義的重要性。在復雜的環境中，會發生什麼是未知的。只有已經發生的事情才能用於前瞻性決策。

如果 Sprint 目標過時，則 Sprint 可能會被取消。只有產品負責人有權取消 Sprint。

衝刺計劃 (Sprint Planning)

Sprint 計劃通過佈置要為 Sprint 執行的工作來啟動 Sprint。這個最終計劃是由整個 Scrum 團隊的協作工作創建的。

產品負責人確保與會者準備好討論最重要的產品待辦事項列表項目以及它們如何映射到產品目標。Scrum 團隊還可以邀請其他人參加 Sprint 計劃以提供建議。

Sprint 計劃涉及以下主題：

主題一：為什麼這個 Sprint 有價值？

產品負責人提議產品如何在當前 Sprint 中增加其價值和效用。然後，整個 Scrum 團隊協作定義一個 Sprint 目標，以傳達為什麼 Sprint 對利益相關者有價值。Sprint 目標必須在 Sprint 計劃結束之前完成。

主題二：這個 Sprint 可以做什麼？

通過與產品負責人的討論，開發人員從產品待辦列表中選擇要包含在當前 Sprint 中的項目。Scrum 團隊可能會在此過程中細化這些項目，從而增加理解和信心。

選擇在 Sprint 中可以完成多少可能具有挑戰性。然而，開發人員對他們過去的表現、即將到來的容量以及他們的完成定義了解得越多，他們對 Sprint 的預測就越有信心。

主題三：選擇的工作將如何完成？

對於每個選定的產品待辦列表項，開發人員計劃創建滿足完成定義的增量所需的工作。這通常是通過將產品待辦列表項分解為一天或更短的更小的工作項來完成的。如何做到這一點由開發人員自行決定。沒有人告訴他們如何將產品待辦列表項轉化為價值增量。

Sprint 目標、為 Sprint 選擇的產品待辦列表項以及交付它們的計劃統稱為 Sprint 待辦列表。

Sprint 計劃的時間限制為一個月的 Sprint 最多 8 小時。對於較短的 Sprint，事件通常較短。

每日站會 (Daily Scrum)

Daily Scrum 的目的是檢查實現 Sprint 目標的進度並根據需要調整 Sprint Backlog，調整即將到來的計劃工作。

每日 Scrum 是 Scrum 團隊開發人員的 15 分鐘活動。為了降低複雜性，它在 Sprint 的每個工作日在同一時間和地點舉行。如果產品負責人或 Scrum Master 正在積極處理 Sprint 待辦列表中的項目，他們作為開發人員參與。

開發人員可以選擇他們想要的任何結構和技術，只要他們的 Daily Scrum 專注於實現 Sprint 目標的進展並為第二天的工作制定可操作的計劃。這創造了焦點並改善了自我管理。

每日 Scrums 改善溝通，識別障礙，促進快速決策，從而消除其他會議的需要。

Daily Scrum 並不是唯一一次允許開發人員調整他們的計劃。他們經常全天開會，就調整或重新規劃 Sprint 的其餘工作進行更詳細的討論。

衝刺回顧 (Sprint Review)

Sprint Review 的目的是檢查 Sprint 的結果並確定未來的調整。Scrum 團隊向主要利益相關者展示他們的工作結果，並討論實現產品目標的進展。

在活動期間，Scrum 團隊和利益相關者審查在 Sprint 中完成的內容以及他們的環境中發生了什麼變化。根據這些信息，與會者就下一步做什麼進行協作。產品待辦列表也可能會進行調整以迎接新的機會。Sprint Review 是一個工作會議，Scrum 團隊應避免將其限制為演示。

Sprint Review 是 Sprint 的倒數第二個事件，並且在為期一個月的 Sprint 中最多有四個小時的時間限制。對於較短的 Sprint，事件通常較短。

衝刺回顧 (Sprint Retrospective)

Sprint 回顧的目的是計劃提高質量和有效性的方法。

Scrum 團隊檢查上一個 Sprint 在個人、交互、流程、工具及其完成定義方面的進展情況。檢查的元素通常隨著工作領域的不同而變化。確定了導致他們誤入歧途的假設並探索了它們的起源。Scrum 團隊討論了 Sprint 中哪些方面做得好，遇到了哪些問題，以及這些問題是如何（或沒有）解決的。

Scrum 團隊確定最有幫助的更改以提高其有效性。盡快解決最具影響力的改進。它們甚至可能被添加到下一個 Sprint 的 Sprint Backlog 中。

Sprint 回顧會結束 Sprint。對於一個月的 Sprint，時間限制為最多三個小時。對於較短的 Sprint，事件通常較短。

Scrum 工件 (Scrum Artifacts)

Scrum 的工件代表工作或價值。它們旨在最大限度地提高關鍵信息的透明度。因此，每個檢查它們的人都有相同的適應基礎。

每個工件都包含一個承諾，以確保它提供的信息可以提高透明度和重點，可以衡量進度：

對於產品待辦列表，它是產品目標。
對於 Sprint Backlog，它是 Sprint 目標。
對於增量，它是完成的定義。

這些承諾的存在是為了加強 Scrum 團隊及其利益相關者的經驗主義和 Scrum 價值觀。

產品積壓 (Product Backlog)

產品待辦列表是一個緊急的、有序的清單，列出了改進產品所需的內容。它是 Scrum 團隊承擔的工作的唯一來源。

可以由 Scrum 團隊在一個 Sprint 內完成的產品待辦事項列表項目被視為已準備好在 Sprint 計劃活動中進行選擇。他們通常在提煉活動後獲得這種程度的透明度。產品待辦列表細化是將產品待辦列表項分解並進一步定義為更小更精確的項的行為。這是添加詳細信息（例如描述、訂單和尺寸）的持續活動。屬性通常因工作領域而異。

將進行工作的開發人員負責調整大小。產品負責人可以通過幫助開發人員理解和選擇權衡來影響他們。

承諾：產品目標

產品目標描述了產品的未來狀態，可以作為 Scrum 團隊計劃的目標。產品目標在產品待辦列表中。產品待辦列表的其餘部分出現以定義“什麼”將實現產品目標。

產品是傳遞價值的載體。它有明確的邊界、已知的利益相關者、明確定義的用戶或客戶。產品可以是服務、實物產品或更抽象的東西。

產品目標是 Scrum 團隊的長期目標。他們必須先完成（或放棄）一個目標，然後才能開始下一個目標。

衝刺積壓 (Sprint Backlog)

Sprint Backlog 由 Sprint 目標（為什麼）、為 Sprint 選擇的產品待辦列表項集（什麼）以及交付增量的可操作計劃（如何）組成。

Sprint Backlog 是開發人員的計劃，也是為開發人員制定的計劃。它是開發人員計劃在 Sprint 期間完成以實現 Sprint 目標的工作的高度可見的實時圖片。因此，隨著學到的更多，Sprint Backlog 在整個 Sprint 中都會更新。它應該有足夠的細節，以便他們可以在 Daily Scrum 中檢查他們的進度。

承諾：衝刺目標

Sprint 目標是 Sprint 的唯一目標。儘管 Sprint 目標是開發人員的承諾，但它在實現它所需的確切工作方面提供了靈活性。Sprint 目標還創造了一致性和重點，鼓勵 Scrum 團隊一起工作而不是單獨的計劃。

Sprint 目標是在 Sprint 計劃活動期間創建的，然後添加到 Sprint 待辦事項列表中。當開發人員在 Sprint 期間工作時，他們牢記 Sprint 目標。如果工作結果與他們預期的不同，他們會與產品負責人合作，在不影響 Sprint 目標的情況下協商 Sprint 中 Sprint Backlog 的範圍。

增量 (Increment)

增量是實現產品目標的具體墊腳石。每個增量都是所有先前增量的相加並經過徹底驗證，確保所有增量協同工作。為了提供價值，增量必須是可用的。

可以在一個 Sprint 中創建多個增量。增量的總和在 Sprint Review 中呈現，從而支持經驗主義。但是，增量可能會在 Sprint 結束之前交付給利益相關者。Sprint Review 永遠不應被視為釋放價值的大門。

工作不能被視為增量的一部分，除非它符合完成的定義。

承諾：完成的定義 Commitment: Product Goal

完成的定義是當增量滿足產品要求的質量措施時對增量狀態的正式描述。

產品待辦列表項滿足完成定義的那一刻，增量就誕生了。

完成的定義通過為每個人提供對作為增量的一部分完成的工作的共同理解來創建透明度。如果一個產品待辦列表項不符合完成的定義，它就不能發布，甚至不能在 Sprint 評審中展示。相反，它返回到產品待辦列表以供將來考慮。

如果增量的完成定義是組織標準的一部分，則所有 Scrum 團隊必須至少遵循它。如果它不是組織標準，Scrum 團隊必須創建適合產品的完成定義。

開發人員必須符合完成的定義。如果有多個 Scrum 團隊一起開發一個產品，他們必須相互定義並遵守相同的完成定義。

尾註

Scrum 是免費的，並在本指南中提供。此處概述的 Scrum 框架是不可變的。雖然只實現 Scrum 的一部分是可能的，但結果不是 Scrum。Scrum 僅作為整體存在，並且作為其他技術、方法和實踐的容器發揮作用。

Visual Paradigm International

回首頁

學習 EA, Agile & UML 和使用 Visual Paradigm 技能

Creating UML Diagrams with Free UML Tool - Visual Paradigm Community Edition