Scrum 方法論：角色、事件和工件

Scrum 方法的開發是為了應對僵化的項目管理方法，例如瀑布方法，它不適應敏捷產品和軟件開發團隊的需求。 我們將深入探討 scrum 方法，但在此之前，讓我們從一個簡單的 scrum 定義開始。

什麼是 Scrum 方法論？

Scrum 是一個項目管理框架，可促進複雜產品和軟件開發項目的團隊協作。 好消息是 Scrum 很容易理解。 壞消息是它很難掌握。

Scrum 方法強調項目管理中的團隊合作。 它強調問責制，是朝著明確目標的迭代進展。 Scrum 是敏捷軟件開發的一部分，團隊實踐敏捷。 該名稱來自橄欖球運動，其中 Scrum 是一種每個人都扮演特定角色的陣型，但每個人都在努力快速採用策略。

ProjectManager 促進了成功 Scrum 所需的必要協作，ProjectManager 是一種基於雲的工作和項目管理軟件，可將 Scrum 團隊連接到他們工作的任何地方。 我們的平台與核心協作，提供實時數據，允許 Scrum 團隊在 sprint 期間評論任務、共享文件等等。 從今天開始免費。

Scrum 框架

Scrum 是一個由價值觀、角色、事件和工件組成的框架。 這些元素共同提供了一種敏捷的項目管理方法，幫助團隊更好地管理他們的工作。 Scrum 框架應該很簡單。 它不是傳統的項目管理方法，而是產品和軟件開發的框架。

Scrum 價值觀

術語 scrum 值實際上是指應用於 scrum 框架的敏捷值。 它們是作為敏捷最佳實踐的簡單陳述。 敏捷價值觀來自敏捷宣言，這是一份包含敏捷方法指導原則的文件。 讓我們快速解釋一下它們的含義。

• 個人和交互優於流程和工具：流程和工具在軟件開發中很重要，但個人以及他們如何與這些流程和工具交互更為重要。
• 工作軟件優於綜合文檔：在敏捷宣言之前，軟件開發人員主要關注文檔。 該值表明，雖然文檔很重要，但專注於開發軟件應該是 Scrum 團隊的主要目標。
• 客戶合作優於合同談判：這個價值說明與客戶合作創造高質量的產品比起草限制產品開發的嚴格合同重要得多，就像過去在舊軟件開發時代所做的那樣。
• 響應變化而不是遵循計劃：這個價值表明敏捷是一種項目管理方法，它基於迭代的產品開發週期而不是僵化的項目計劃無縫適應變化。

Scrum 角色

與項目管理中的任何事情一樣，Scrum 方法需要人來執行。 為此，它定義了三個 Scrum 角色，即 Scrum Master、產品負責人和開發團隊，由幾個團隊成員組成。

顧名思義，Scrum Master 是 Scrum 方法論專家。 他保證 Scrum 團隊中的每個人都了解框架的工作原理，並幫助他們適應敏捷環境。 他領導 Scrum 會議。

Scrum 產品負責人管理產品日誌並監督 sprint 計劃並積極參與 Scrum 會議。 從某種意義上說，他們充當項目經理，因為他們領導積壓工作並優先考慮用戶故事以幫助更好地團隊合作。

Scrum 開發團隊只是由開發軟件或產品的所有團隊成員組成。 他們必須與產品負責人密切合作，並遵守 Scrum Master 的建議。

Scrum 事件

這些 Scrum 事件或 Scrum 儀式促進了團隊協作，並確保 Scrum 團隊成員之間在產品或軟件開發生命週期中保持持續的溝通。

衝刺計劃

使用產品待辦事項，團隊從最高優先級的項目開始，並確定如何實現這一目標。 衝刺計劃的一個很好的提示是進行盡職調查，並且只從準備好的項目開始。 另外，請記住，計劃是一個短暫的過程，所以不要陷入細節中。 只需努力實現目標即可。 保持計劃協作。 團隊還應該向產品所有者和利益相關者提問。

每日 Scrum 會議

這些是 15 分鐘的會議，Scrum 團隊中的每個人都會討論他們將在白天工作的任務，並分享他們面臨的任何障礙或困難。 沒有必要讓這個每日 Scrum 會議變得更長，因為還有其他會議，例如 sprint 審查和 sprint 回顧會議來探索更複雜的主題。

衝刺回顧

你想回顧一下衝刺，看看什麼有效，什麼無效。 然後，您可以獲取信息並將其應用於未來的 sprint 以復制積極因素並減少消極因素。 通過感謝參與者、提供簡短介紹並為討論制定基本規則來開始 sprint 審查過程。

衝刺回顧

sprint 回顧會議為 Scrum 團隊提供了一個空間來反思上一個 sprint 並確定什麼是好的和錯誤的。 還收集利益相關者和客戶的反饋，以便確定用戶故事的優先級並提高產品性能。

積壓梳理

一旦通過這個循環，它會通過返回積壓並在優先級列表頂部獲取下一個準備好的項目來重新開始。 待辦事項梳理包括通過基於先前經驗的工作優先級來改進 Scrum 流程，並繼續改進工作以使其盡可能高效。

Scrum 工件

在 Scrum 方法論中，術語工件是指 Scrum 團隊用於在敏捷環境中開發產品的關鍵概念。 我們將介紹每個 Scrum 團隊需要的最關鍵的工件：產品 backlog、sprint backlog 和產品增量。

• 產品待辦事項：產品負責人會列出需要完成的工作清單，他們會按照優先級進行排序。 這是建立你的項目積壓。 他們通過確定什麼是必備物品來做到這一點，這些物品不太重要以及那些不適合分配的時間範圍的物品。 這意味著每個項目的價值必須明確。 它們的影響、風險是什麼，以及該項目對學習過程有何幫助？
• Sprint Backlog： sprint backlog 可以簡單地定義為一組用戶故事，其中 Scrum 團隊將在單個 sprint 中工作。 重要的是要確保最關鍵的用戶故事始終是正在處理的用戶故事，並且沒有一個會落空。
• 產品增量：術語產品增量是指在一個 sprint 期間已完成的所有產品待辦事項，也可以用來描述所有已完成的待辦事項和用戶故事的總和。

Scrum 方法論理論隨著時間的推移而發展。 Scrum 專家建議實際上有 7 個 Scrum 工件。 這種擴展的願景對於進一步定義 Scrum 團隊的目標非常有幫助。

Scrum 歷史

起源

Scrum 流程起源於 1990 年代初期。 Jeff Sutherland 和 Ken Schwaber 提出了這個過程，他們於 1995 年在德克薩斯州奧斯汀舉行的面向對象編程、系統、語言和應用程序 (OOPSLA) 會議上提出了該過程。然後，他們在一篇名為“SCRUM 軟件”的已發表論文中將該方法正式化發展過程。”

然而，scrum 這個名稱是從管理專家 Hirotaka Takeuchi 和 Ikujiro Nonaka 於 1986 年發表的一篇名為“新產品開發遊戲”的論文中繼承而來的。 他們使用 scrum 這個詞，因為它與橄欖球有關，以此來強調團隊協作對項目成功的重要性。

該論文報導的研究表明，開發新的、複雜的項目的績效如何受益於小型、自組織的團隊被賦予目標而不是任務。 優秀的團隊是給定方向的團隊，但有自主權來製定自己的策略來實現這些目標

Scrum 和軟件開發

然後，Scrum 框架將這項關於自適應實踐的研究應用於軟件開發。 在此過程中，Schwaber 聘請了過程控制研究工程師 Babatunde A. Ogunnaike Tunde 教授來了解 scrum 如何與其他方法一起工作。

確定瀑布和其他傳統結構化流程等方法與 Scrum 框架不一致。 Tunde 教授總結說，經驗方法是最適合 Scrum 的過程。

到 2001 年，Sutherland 和 Schwaber 以及其他 15 位軟件開發領導者創建了敏捷軟件開發宣言。 不久之後，敏捷聯盟成立，施瓦伯成為其第一任主席。 Schwaber 與 Mike Beedle 合著了第一本關於 Scrum 的書，Agile Software Development with Scrum，於 2001 年。

2000 年代的 Scrum

Scrum 聯盟由主席 Schwaber 與 Mike Cohn 和 Esther Derry 於 2002 年創立。 後來，他們為該組織增加了一個認證部門，通過認證的 ScrumMaster 計劃。 2006 年，Sutherland 創建了 Scrum, Inc.，並繼續教授認證 Scrum 課程。

2009 年，施瓦伯離開 Scrum 聯盟創辦了提供專業 Scrum 系列的 Scrum.org，Scrum 社區的變化仍在繼續。

從那時起，Scrum 在項目管理中發揮了全球作用，2010 年首次發布了 Scrum 指南，並在 2011 年和 2013 年進行了更新。它今天被稱為管理項目中最常用的敏捷框架之一。

它甚至可以與大型團隊合作。 Scrum of Scrums 適用於使用該技術將 Scrum 擴展到大型團隊。

Scrum 如何融入敏捷？

Scrum 是敏捷過程的一部分，但肯定不是唯一的部分。 敏捷是一個大帳篷，但 Scrum 是一個重要的支柱。 將 scrum 視為一個框架，您可以通過它實施敏捷開發。

敏捷沒有一套可遵循的步驟，因此 scrum 提供了一種將敏捷應用於您的項目的方法。 你可以在敏捷開發中使用許多框架，例如極限編程或功能驅動開發，但 Scrum 的簡單性和自主性是賣點。

Scrum 也可以用作其他敏捷實踐的入口點。 它也不僅僅是一個軟件框架，還可以使許多其他類型的項目受益。

Scrum 術語表

在定義 scrum 的框架之前，這裡列出了在 scrum 環境中工作時使用的一些更常用的術語。

燃盡圖：燃盡圖顯示與時間相比還剩下多少努力。

燃盡圖：測量隨時間增加的度量值。

Daily Scrum：關於當天工作的簡短 Scrum 會議。

完成的定義：完成的定義（DOD）是七個 Scrum 工件之一。 這是 Scrum 團隊同意的驗收標準。

開發團隊：負責管理與每個 sprint 相關的工作。

工程標準：項目增量開發的共享標準。

產品待辦事項：產品待辦事項是按特定順序完成的工作。

產品待辦事項細化：當產品負責人和團隊向產品待辦事項添加細節時，也稱為待辦事項梳理。

產品負責人：負責產品和團隊的經理。

Scrum：複雜項目團隊協作的框架。

Scrum 板： Scrum 板幫助 Scrum 團隊管理他們的工作。

Scrumban： Scrumban 是一種混合方法，它結合了 Scrum 和看板項目管理。

Scrum Master： Scrum Master 角色類似於用他們的專業知識幫助團隊的教練。

Scrum 團隊：產品負責人、團隊和 Scrum 主管。 了解有關 Scrum 角色的更多信息。

自組織：項目目標範圍內的團隊自治。

Sprint：短任務，一個在完成另一個之後立即跟進。

Sprint Backlog：團隊完成 sprint 所需的內容。

衝刺目標：衝刺的目的。

衝刺計劃：衝刺計劃是春季活動，Scrum 團隊計劃即將到來的衝刺。

衝刺回顧：衝刺的簡短事後分析。

Sprint 審查：對 sprint 的簡短審查，以幫助對下一個進行改進。

利益相關者：通常是項目發起人的非團隊成員。

速度：產品積壓的平均數量在衝刺期間轉化為項目的增量。

ProjectManager 幫助 Scrum 團隊

Scrum 方法需要協作和靈活性。 ProjectManager 是一款基於雲的工作和項目管理軟件，它連接 Scrum 團隊並為他們提供在敏捷環境中工作所需的工具。 我們的工具提供實時數據，無論他們身在何處、如何工作或在項目中扮演什麼角色，都能讓每個人保持最新狀態並進行交流。

創建和管理 Scrum 板

我們的多個項目視圖意味著其他部門可以在甘特圖或我們的工作表視圖上進行協作。 但是 scrum 團隊將使用我們的 scrum 板視圖，這使他們能夠管理他們積壓的用戶故事，並在計劃 sprint 時一起工作。

Scrum 板還為產品所有者和 Scrum 主管提供了跟踪進度和發現潛在瓶頸的可見性，這些瓶頸可以通過重新分配資源來快速清除。

使用實時儀表板跟踪 Scrum 工作流程

你不想妨礙你的自主團隊，但你需要知道他們在做什麼。 我們的實時儀表板跟踪六個項目指標。 不需要像劣質產品那樣進行設置。 我們的自定義工作流程允許您應用自動設置操作的觸發器，讓您的團隊能夠專注於他們的工作。 此外，任務批准使您可以控制狀態更改。

與您的 Scrum 團隊合作

無論您的團隊是在同一屋簷下還是跨時區工作，我們基於雲的工具都可以讓他們一起工作。 團隊成員可以在任務級別發表評論，標記未分配給該任務的其他人以將他們帶入對話並共享圖像和文檔。 電子郵件通知和應用內提醒讓每個人都能即時了解最新信息。

我們的軟件不僅是 Scrum 的理想選擇，它還可以與更傳統的方法（如瀑布或多種項目管理方法的混合）一起使用。 我們的工具允許您與組織中不靈活的其他部門協作。 它是您取得成功所需的唯一工作和項目管理工具。

ProjectManager 是一個項目管理軟件，其獨特的定位是幫助項目經理完成工作的每個階段，無論他們選擇何種方法來構建它。 由於基於雲，它收集實時數據並擁有幫助團隊協作的工具，為他們提供 Scrum 所需的自主權，並通過監控和管理保持進度並在預算範圍內。 參加 30 天免費試用，了解它如何幫助您和您的團隊。