綜合 Scrum 指南

2021-09-13

Scrum是一個項目管理框架，它強調團隊合作、問責制和朝著明確定義目標的迭代進展。該框架從一個簡單的前提開始：從可以看到或知道的開始。之後，跟踪進度並根據需要進行調整。

Scrum的三大支柱

Scrum 的基礎是經驗主義，它指出知識來自經驗，我們應該根據已知的知識做出決定。將 Scrum 結合在一起的三大支柱。

Scrum的三大支柱

為什麼是 Scrum？

Scrum 一次交付功能，而瀑布式只是交付階段。典型的瀑布式開發是基於階段和順序的過程，直到項目結束才會產生價值。Scrum 顛覆了這種模式，每隔幾週就會推出新功能，而不是專注於未來的大版本發布。

Scrum 將復雜的工作劃分為簡單的部分，將大型組織劃分為小團隊，將影響深遠的項目劃分為一系列稱為衝刺的短時間範圍。

瀑布 vs Scrum

通過迭代和增量構建，公司能夠更快、更有效地為客戶提供他們真正需要的產品和服務。使用 Scrum，您可以在每個小開發週期結束時接收並整合客戶反饋，這意味著您的結果是由實際使用而不是您的假設決定的。這使得讓客戶和主要利益相關者密切參與和參與變得更加容易。

敏捷 vs Scrum

敏捷方法論是一種有助於在 SDLC 過程中持續迭代開發和測試的實踐。敏捷將產品分解為更小的構建。Scrum 只是眾多迭代和增量敏捷軟件開發過程之一，它使我們能夠專注於在最短的時間內交付業務價值。

敏捷 vs Scrum

Scrum 框架通常處理這樣一個事實，即需求可能會改變，或者大部分時間在項目開始時是未知的。Scrum的特點是：

輕的
簡單易懂
難以掌握

Scrum 的好處

以下是 Scrum 為組織、團隊、產品和個人提供的好處。

更好的質量：項目的存在是為了實現願景或目標。Scrum 提供了持續反饋和曝光的框架，以確保質量盡可能高。Scrum 通過以下實踐幫助確保質量
縮短上市時間：Scrum 已被證明可以比傳統方法快 30% 到 40% 的速度向最終客戶交付價值。
增加投資回報：上市時間的縮短是 Scrum 項目實現更高投資回報 (ROI) 的一個關鍵原因。因為收入和其他有針對性的收益來得更早，所以更早的積累意味著隨著時間的推移總回報更高。這是淨現值 (NPV) 計算的基本原則。
更高的團隊士氣：與喜歡工作的快樂的人一起工作會讓人感到滿足和回報。自我管理將通常由經理或組織做出的決定交給Scrum 團隊成員。
增強團隊協作：當 Scrum 團隊對項目和產品負責時，他們可以產生很好的結果。Scrum 團隊通過增強團隊參與和溝通進行協作並掌握質量和項目績效。

Scrum 框架

Scrum 很簡單。它與大量交織的強制性組件相反。Scrum 不是一種方法論。Scrum 實施了經驗主義的科學方法。Scrum 用啟發式算法取代了編程算法方法，尊重人和自組織來處理不可預測性和解決複雜問題。下圖代表了 Scrum in Action，正如 Ken Schwaber 和 Jeff Sutherland 在他們的書 Software in 30 Days 中描述的那樣，帶領我們從計劃到軟件交付。

Scrum 框架

Scrum流程的組成部分

Scrum 框架本身非常簡單。它只定義了一些通用的指導方針，只有一些規則、角色、工件和事件。然而，這些組件中的每一個都很重要，服務於特定目的，對於成功使用框架至關重要。

Scrum 框架的主要組件是：

Scrum 角色：Scrum Master、Scrum 產品負責人和 Scrum 團隊
工件：Sprint backlog、product backlog、燃盡圖、日誌等……
Scrum 活動： Sprint 計劃、春季回顧、每日站會、Sprint 復古等……
短跑

下圖顯示了 SCRUM 框架的關鍵元素。該流程已被敏捷軟件工具——Scrum Process Canvas 應用。

Scrum 框架

Scrum 角色

當組織決定採用 Scrum 時，首先要了解的事情之一是 Scrum 角色與傳統項目執行角色有何不同。雖然 Scrum 中只有三個主要角色，但它們不會自動與我們大多數人熟悉的頭銜保持一致。讓我們從每個的簡要定義開始：

產品擁有者

產品負責人是代表業務或用戶社區並負責與用戶組合作以確定產品版本中將包含哪些功能的人員的 Scrum 開發角色。產品負責人的主要職責是：

制定產品和服務的方向和戰略，包括短期和長期目標；
提供或獲得有關產品或服務的知識；
為開發團隊理解和解釋客戶需求；
收集、優先排序和管理產品或服務需求；
接管與產品或服務預算相關的任何責任，包括其盈利能力；
確定產品或服務功能的發布日期；
每天與開發團隊一起回答問題並做出決定；
接受或拒絕與 Sprint 相關的已完成功能；
在每個 Sprint 結束時展示開發團隊的主要實現；
負責產品Backlog

Scrum大師

Scrum Master 是敏捷開發團隊的推動者。Scrum 是一種方法，它允許團隊根據敏捷原則自組織并快速進行更改。Scrum Master 管理信息交換的過程。Scrum Master 的主要職責是：

作為教練，幫助團隊遵循 Scrum 價值觀和實踐；
幫助排除障礙，保護團隊免受外部干擾；
促進團隊和利益相關者之間的良好合作；
促進團隊內的常識；
保護團隊免受組織干擾；

Scrum團隊

Scrum 團隊（又名開發團隊）由 3 到 9 人組成，他們必須滿足交付產品或服務的所有技術需求。他們將由 Scrum Master 直接指導，但不會直接管理。他們必須是自組織的、多才多藝的，並且有足夠的責任感來完成所有必需的任務。

開發團隊負責從分析、設計、開發、測試到技術寫作等每個 sprint 交付潛在可交付的產品增量。 Scrum 團隊具有以下特徵非常重要：

團隊必須是自組織的。所有團隊成員都必須管理自己的努力以完成已分配的任務。在敏捷 Scrum 中，沒有團隊領導或直線經理的形象。每個人都必須有足夠的承諾來開展自己的活動並為團隊的成功做出貢獻。如果一個失敗，每個人都會失敗。
團隊必須是跨職能的。所有團隊成員都必須具備所有必需的知識和技能，才能提供完善且隨時可用的服務或產品。在必要的情況下可以使用專家，但只能作為教練將知識傳遞給團隊以彌補特定的差距。
成為產品負責人需要有商業遠見。產品負責人代表客戶的聲音，需要將他們的需求傳達給 Scrum Master 和開發團隊。這通常是一份全職工作。
Scrum Master 不是直線經理。他們幫助為開發團隊提供所需的教練，並幫助消除團隊面臨的任何障礙。

Scrum 工件

SCRUM 工件用於幫助定義進入團隊和當前正在團隊中工作的工作量。還有更多的工件，例如，用戶故事、發布積壓、燃盡圖等，但我們將專注於核心三個：

產品積壓

產品待辦列表是用戶故事的集合，它展示了產品團隊需要/想要的功能。通常產品負責人負責這個列表。

衝刺積壓

Sprint backlogs 包含一系列可以包含在當前 sprint 中的故事。關於 sprint backlog 和將項目包含到 sprint 之間的關係，需要注意兩個要點。1) 團隊決定將什麼添加到 sprint。因此，團隊對這些項目的交付負有所有權和責任。2) 在將項目從 sprint backlog 中刪除並添加到 sprint 之前，團隊必須確保他們擁有 backlog 中所需的所有信息。通常，團隊會定義一個項目清單，在添加項目之前必須存在這些項目清單。

產品待辦列表與 Sprint 待辦列表

在衝刺積壓是Scrum的衝刺過程中完成了由Scrum團隊確定的任務列表。在衝刺計劃會議期間，團隊選擇一定數量的產品待辦事項，通常以用戶故事的形式，並確定完成每個用戶故事所需的任務，如下圖所示：

產品待辦事項與 Scrum 待辦事項

燃盡圖

燃盡圖是剩餘工作隨時間變化的圖形表示。未完成的工作（或積壓工作）通常在縱軸上，時間在橫軸上。也就是說，它是一個傑出工作的運行圖。它可用於預測所有工作何時完成。它通常用於敏捷軟件開發方法，例如 Scrum。但是，燃盡圖可以應用於包含隨時間推移可衡量的進度的任何項目。傑出的作品可以用時間或故事點來表示。

燃盡圖

Scrum 事件

溝通是關鍵！SCRUM 依賴於團隊的所有方面都透明地工作（Scrum 支柱 #1）。考慮到這一核心精神，該方法圍繞一些關鍵事件構建，以確保其他兩個支柱：檢查和適應，如下表所示：

事件	檢查	適應
衝刺計劃	產品積壓（承諾回顧）（完成的定義）	衝刺目標預報衝刺積壓
每日站會	朝著衝刺目標的進展	衝刺積壓每日計劃
衝刺回顧	產品增量產品積壓（發布）市場-商業條件	產品積壓
衝刺回顧	團隊與協作技術與工程完成的定義	可操作的改進

注意：每個衝刺執行過程中，Scrum 有五個主要會議，如下圖所示：

衝刺執行

衝刺計劃

所有衝刺都從計劃開始。團隊需要確定並承諾哪些項目將作為衝刺的一部分交付。可能的項目總是取自 Sprint Backlog，如下圖所示：

衝刺計劃會議

這是 SCRUM 大師可以大放異彩的時候。產品負責人從業務/客戶的角度確定他們需要的方面，SCRUM 團隊確定他們認為他們可以交付哪些項目，而 SCRUM 主管會容納所有項目並確保滿足兩全其美的要求。

每日 Scrum 會議

一旦團隊確定了他們承諾作為衝刺一部分交付的項目。該團隊將每天舉行一次站立會議。本次會議的核心目標是確保團隊中的每個人（以及可能的觀察員）完全了解正在完成的任務的狀態和進展情況：

他們所做的
他們今天要做什麼
是什麼阻止了他們

每日Scrum會議

此每日更新向團隊提供實例反饋並提供。這些會議旨在簡短而快速，每人不超過 3 分鐘。

注意：

觀察員在那裡觀察，SCRUM 主管必須在可能的情況下減輕外部干擾和對團隊的干擾。

Sprint 評審會議

Sprint 評審/演示會議在 Sprint 結束時舉行，以檢查增量。團隊根據完成的定義展示增量，重點放在 Sprint 目標上。產品負責人審查並接受交付的增量。

衝刺回顧

衝刺回顧通常是衝刺中完成的最後一件事。許多團隊會在 sprint 評審後立即進行。整個團隊，包括 Scrum Master 和產品負責人都應該參與。您可以安排長達一個小時的 Scrum 回顧，這通常已經足夠了。回顧讓團隊有機會確定 3 個關鍵方面：

應該開始做什麼？
什麼事情進展不順利（然後又停止了）？
什麼進展順利（應該繼續做？）？

衝刺回顧

這種方法的目的是不斷提高團隊效率。

待辦事項細化會議

將積壓工作視為項目的路線圖。當團隊協作創建一個包含項目完成所需構建或完成的所有內容的列表時，可以修改此列表並將其添加到整個項目中，以確保滿足項目的所有必要需求。

短跑

在 Scrum 框架中，實現 Scrum 產品待辦列表條目所需的所有活動都在 Sprint（也稱為“迭代”）中執行。Sprint 總是很短：通常大約 2-4 週。每個 Sprint 都遵循一個定義的流程，如下所示：

敏捷 Scrum 衝刺

如前所述，產品待辦列表中的項目被優先考慮並被選擇到衝刺待辦列表中。一個 sprint 只包含幾個大項目，即使對單個項目低估工作的影響也會對 sprint 產生深遠的影響。而且由於較大的項目往往更難估計和理解，因此衝刺失敗的可能性進一步增加。有經驗的 Scrum 團隊花費時間和精力將復雜和較大的項目（即用戶功能或史詩）分解為較小的用戶故事（或隨後分解為任務或子任務）。

史詩

史詩捕捉了大量的工作。它本質上是一個“大用戶故事”，可以分解為許多較小的故事。完成一個史詩可能需要幾個衝刺。因此，當我們採用史詩進行開發時，必須將其分解為更小的用戶故事。

在項目週期的早期，我們提出了 Epics。這些是非常高級的、幾乎以營銷為中心的功能要點。

我們將大型故事稱為“史詩”以傳達有關它們的某些信息。我喜歡把這個和電影聯繫起來。如果我告訴你某部電影是一部“動作冒險電影”，它會告訴你關於這部電影的一些信息。可能會有一些汽車追逐，可能會有一些射擊等等。同樣，稱一個故事為“史詩”有時可以傳達額外的含義。

用戶的故事

故事是對產品要求或業務案例的簡要說明。通常，故事以通俗易懂的語言表達，以幫助讀者理解軟件應該完成的任務。產品負責人創造故事。Scrum 用戶然後將故事分成一個或多個 Scrum 任務。

用戶故事通常是最終用戶可見的功能。用戶故事遵循以下格式“我作為誰想要做什麼，所以為什麼。用戶故事為客戶/用戶提供價值。這是客戶/用戶的產品要求。

例如，“作為客戶，我希望能夠創建一個帳戶，以便我可以查看我去年購買的商品，以幫助我為明年做預算。”

任務

另一方面，任務更具有技術性質，任務通常類似於編碼、設計、為某某創建測試數據、自動化等等。這些往往是一個人完成的事情。任務不是以用戶故事格式編寫的。任務具有更多的技術性質。

例如“評估用戶界面的 Angular 材料設計”或“將應用提交到應用商店”。

Visual Paradigm International

回首頁

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

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