Scrum

Scrum是用於開發、交付和維持錯綜複雜產品 (complex products) 的敏捷框架 (framework) 。最初著重於軟體開發，之後已被用應用於其他領域，包括研究、銷售、營銷和其他先進技術領域。

一個 Scrum 團隊建議為十名成員的團隊而設計的，他們以迭代 （iterative）與增量 （incremental）式的方式交付工作，每個迭代稱作 Sprint。一個 Sprint 的時間不超過一個月，通常是兩星期。Scrum 團隊在每個 Sprint 都專注在唯一一個共同的目標 （Sprint Goal），每天會有稱為Daily Scrum的站會，團隊中的開發人員（Developers）會檢視朝向共同目標的進度，和調適當下的計畫。在 Sprint 結束時，團隊會進行 Sprint 審查 (Sprint Review) 跟利害關係人 (Stakeholders) 一起檢視當下的結果與調適計畫，這是互相資訊交流的機會。最後，團隊會進行 Sprint 回顧（Sprint Retrospective）來持續改善。

歷史

• 1986年，竹內弘高 (Hirotaka Takeuchi) 和野中郁次郎 (Ikujiro Nonaka) 在其1986年的《哈佛商業評論》文章「The New New Product Development Game」中，闡述了一種新的整體性的方法 ，該方法能夠提高商業新產品開發的速度和靈活性：
  • 文章中在產品開發的背景下引入了術語 scrum，他們將這種新的整體性方法與橄欖球相比較，前者各階段相互重疊，並且由一個跨職能團隊在不同的階段完成整個過程，而團隊「作為一個整體前進，把球傳來傳去」。
  • 他們對來自汽車，照片機器，計算機和打印機等產業的案例進行了研究。
• 1991年，Peter DeGrace 和 Leslie Hulet Stahl 在《Wicked Problems, Righteous Solutions》一書中將這種方法稱為scrum，引用在竹內弘高和 野中郁次郎的文章中提到的 scrum 術語。

• 1990年代初，
  • 肯·施瓦伯 (Ken Schwaber) 在其公司 Advanced Development Methods 使用了一種方法，這種方法後來發展為 Scrum。
  • 同時，傑夫·薩瑟蘭 (Jeff Sutherland) 在 Easel 公司開發了一種類似的方法，並使用單個詞 scrum 來代表這方法。
• 1995年，在奧斯汀舉辦的OOPSLA '95上，薩瑟蘭和施瓦伯聯合發表了論文首次提出了Scrum概念。施瓦伯和薩瑟蘭在接下的幾年裡合作，將上述的文章，他們的經驗，以及業界的最佳實踐融合起來，形成我們現在所知的Scrum。
• 2001年，肯·施瓦伯 (Ken Schwaber) 與麥克·比竇（Mike Beedle）合著了《敏捷軟體開發-使用Scrum過程》一書，介紹了Scrum方法。

• 2002年, 肯·施瓦伯 (Ken Schwaber) 與 Mike Cohn 、Esther Derby 共同建立了 Scrum 聯盟 (Scrum Alliance) 並建立了 Certified Scrum 認證系列。
• 2009年末，肯·施瓦伯 (Ken Schwaber) 離開了Scrum 聯盟 (Scrum Alliance), 創立了 Scrum.org , 該機構負責監督並行的 Professional Scrum 認證系列。

• 自2009年以來，肯·施瓦伯 (Ken Schwaber) 和 傑夫·薩瑟蘭 (Jeff Sutherland) 已發布並更新了名為 《Scrum 指南》(Scrum Guide)的公共文件。該版本已被修訂6次，當前版本為2020年11月。

• 2020年5月，傑夫·薩瑟蘭 (Jeff Sutherland) 在2006年創立的 ScrumInc 公司，開始教授 'Scrum Inc 認證系列『

Scrum的特性

Scrum過程

Scrum是一個包括了一系列實踐和預定義角色的過程骨架。 Scrum中的主要角色包括：

1. Scrum Master是Scrum教練和團隊帶頭人，確保團隊合理的運作Scrum，並幫助團隊掃除實施中的障礙；
2. 產品負責人，確定產品的方向和願景，定義產品發布的內容、優先級及交付時間，為產品投資報酬率負責；
3. 開發團隊，一個跨職能的小團隊，人數5-9人，團隊擁有交付可用軟件需要的各種技能。

在每一次衝刺或迭代（一個15到30天的周期，其長度由開發團隊決定）當中，開發團隊創建可用的（可以隨時推出）軟件的一個增量。每一個迭代所要實現的功能來自產品訂單。產品訂單按照優先級排列工作需求。在迭代計劃會議中，產品負責人告訴開發團隊需要完成產品訂單中的哪些訂單項。開發團隊決定在下一次迭代中他們能夠承諾完成多少訂單項。在迭代的過程中，沒有人能夠變更迭代訂單，這意味著在一個迭代中需求是被凍結的。

管理Scrum過程有很多實施方法，如即時貼、白板、甚至軟件包。 Scrum最大的好處之一是它非常容易學習，而且啟動Scrum應用並不需要太多的投入。

Scrum中的角色

參見：豬與雞

Scrum當中定義了許多角色。按照對開發過程的參與情況，這些角色被分為兩組，即豬組和雞組。這個分組方法的由來是一個關於豬和雞合夥開餐館的笑話：

一天，一頭豬和一隻雞在路上散步。
雞對豬說：「嗨，我們合夥開一家餐館怎麼樣？」
豬回頭看了一下雞說：「好主意，那你準備給餐館起什麼名字呢？」
雞想了想說：「叫『火腿和雞蛋』怎麼樣？」
「那可不行」，豬說：「我把自己全搭進去了，而你只是參與而已。」

豬組的成員

豬是在Scrum過程中全身投入專案的各種人物，他們在專案中承擔實際工作。他們有些像上邊那個笑話裡的豬，要把自己身上的肉貢獻出來。

產品負責人（product owner）

產品負責人代表了客戶的意願。這保證了Scrum團隊在做從業務角度來說正確的事情。產品負責人編寫用戶故事，排出優先級，並放入產品訂單（product backlog）。產品負責人決定團隊每個衝刺（sprint）要完成哪些任務。產品負責人負責最大化產品以及開發團隊工作的價值。產品負責人通過在每個衝刺統一完整地執行Scrum流程，來保持合理開發節奏，從而保障產品的質量。

Scrum主管（或促進者）（scrum master）

Scrum主管促進Scrum過程，他的主要工作是去除那些影響團隊交付沖刺目標的障礙。 Scrum主管並非團隊的領導/項目經理（因為團隊是自我組織的），而是一個負責屏蔽外界對開發團隊的干擾（例如某位領導對開發團隊的指手畫腳）的角色。 Scrum主管確保Scrum過程被按照初衷使用，即維護每個衝刺的流程，確保每個衝刺能夠順利實施。 Scrum主管是規則的執行者。Scrum主管負責團隊建設，通過對士氣積極主動的調節和鼓舞，來保持團隊的凝聚力和戰鬥力。

開發團隊（dev team）

負責交付產品的團隊。一個團隊通常由5至9名具有跨職能技能的人（設計者，開發者等）組成，承擔實際的開發工作。

雞組的成員

雞並不是實際Scrum過程的一部分，但是必須考慮他們。 敏捷方法的一個重要方面是使得用戶和利益相關者參與到過程中的實踐。參與每一個衝刺的評審和計劃，並提供反饋對於這些人來說是非常重要的。

用戶

軟件是為了人而開發的。有人說，「假如森林裡有一棵樹倒下了，但沒有被人聽到，那麼它算是發出了聲音嗎？」同樣地，人們可以說，「假如軟件沒有被使用，那麼它算是被開發出來了麼？」

利益相關者（客戶，提供商）

影響項目成功的人，但只直接參與衝刺評審過程。

經理

為產品開發團體搭建環境的人。

Scrum會議

參見：站會

在辦公室中間進行的「每日站立會議」，會議的位置有助於會議準時開始

在衝刺中，每一天都會舉行項目狀況會議，被稱為「scrum」或「每日站立會議」。每日站立會議有一些具體的指導原則：

• 會議準時開始。
• 歡迎所有人參加，但只有「豬」可以發言。
• 不論團隊規模大小，會議被限制在15分鐘。
• 所有出席者都應站立。（有助於保持會議簡短）
• 會議應在固定地點和每天的同一時間舉行。

在會議上，每個團隊成員需要回答三個問題：

1. 昨天你完成了哪些有助於推進Sprint目標的工作？
2. 今天你打算做什麼與自身Sprint目標相關的事？
3. 完成你的目標是否存在什麼障礙？（Scrum主管需要記下這些障礙）

每日 Scrum 限時 15 分鐘，詳細討論可於Scrum之後，另開會議討論。

每一個衝刺完成後，都會舉行一次衝刺回顧會議，在會議上所有團隊成員都要反思這個衝刺。舉行衝刺回顧會議是為了進行持續過程改進。會議的時間限制在4小時。

Scrum提倡所有團隊成員坐在一起工作，進行口頭交流，以及強調項目有關的規範（disciplines），這些有助於創造自我組織的團隊。

Scrum的一個關鍵原則是承認客戶可以在項目過程中改變主意，變更他們的需求，而預測式和計劃式的方法並不能輕易地解決這種不可預見的需求變化。同樣，Scrum採用了經驗方法– 承認問題無法完全理解或定義，而是關注於如何使得開發團隊快速推出和響應不斷出現的需求的能力最大化。

Scrum會議一共包含以下四種：

1. 衝刺計劃會議
2. 每日站立會議
3. 評審會議
4. 回顧會議。

文檔

產品訂單

產品訂單（product backlog）是整個專案的概要文檔。產品訂單包括所有所需特性的粗略的描述。產品訂單是關於將要生產什麼樣的產品。產品訂單是開放的，每個人都可以編輯。產品訂單包括粗略的估算，通常以天為單位。估算將幫助產品負責人衡量時程表和優先順序（例如，如果"增加拼寫檢查"特性的估計需要花3天或3個月，將影響產品負責人對該特性的渴望）。

衝刺訂單

衝刺訂單（sprint backlog）是大大細化了的文檔，包含團隊如何實現下一個衝刺的需求的信息。任務被分解為以小時為單位，沒有任務可以超過16個小時。如果一個任務超過16個小時，那麼它就應該被進一步分解。衝刺訂單上的任務不會被分派，而是由團隊成員簽名認領他們喜愛的任務。

燃盡圖

燃盡圖（burn down chart）是一個公開展示的圖表，顯示當前衝刺中未完成的任務數目，或在衝刺訂單上未完成的訂單項的數目。不要把燃盡圖與掙值圖相混淆。燃盡圖可能在一次衝刺的大部分時間內都維持平坦，但計畫仍然可以按照既定時間進行。

自適應的項目管理

以下是一些Scrum的通用實踐：

• 客戶成為開發團隊中的一部分。（例如客戶肯定對開發的結果真正感興趣。）
• 和所有其他形式的敏捷軟件過程一樣，Scrum有頻繁的包含可以工作的功能的中間可交付成果。這使得客戶可以更早的得到可以工作的軟件，同時使得項目可以變更項目需求以適應不斷變化的需求。
• 開發團隊經常評估風險並制定緩解計劃。在每一個階段根據承諾進行風險緩解，監測和管理（風險分析）。
• 計劃和模塊開發要保持透明，讓每一個人知道誰負責什麼，以及什麼時候完成。
• 參與者要經常開會以跟蹤項目進展 – 平衡的（發布，客戶，員工，過程）儀錶板更新 – 利益所有者更新。你必須擁有預警機制，例如在可能延期交付時提出警告。
• 不要隱藏問題。認識到或說出任何沒有預見到的問題並不會受到懲罰。
• 在工作場所和工作時間內必須全身心投入。– 完成更多的工作並不意味着需要工作更長時間。

Scrum在其他領域的應用

雖然Scrum最初只應用於軟件開發，它也可以被成功地應用於其他產業。現在Scrum通常被認為是一種用於開發任何產品或管理人和工作的迭代式的，增量的過程。

Scrum用於產品開發

將Scrum應用於產品開發是在《新新產品開發遊戲》 第一次提出，之後野中郁次郎和竹內弘高合著的《創造知識的企業》（牛津大學出版社，1995年）進行了詳細的闡述。今天Scrum被用於開發金融產品，互聯網產品，以及醫藥產品。

Scrum用作營銷項目管理方法

由於市場營銷通常以專案的方式運作，許多一般專案管理的原則應用在市場營銷上。市場營銷也可以像專案管理技術那樣進行優化。以Scrum方法進行市場營銷被認為有助於克服市場營銷經理們所遇到的問題。短時和固定的會議對於小的市場營銷團隊來說很重要，這是因為團隊的每一個成員都可以了解其他人在做些什麼，以及整個團隊在朝着什麼方向前進。Scrum在市場營銷中應用可以：

• 在早期發現可能的問題，可以更快地，最小損失地應對問題。 根據Scrum的主要原則 「沒有問題被掃入地毯下」，Scrum鼓勵每一個團隊成員描述他所遇到的困難，而這個困難可能會對整個團隊的工作造成影響。
• 降低財務風險。 在每一個衝刺周期的開始，企業所有者可以不付出任何代價的改變任何市場營銷的因素：包括增加投資以擴大顧客數量，減少投資直至未知風險被減輕，或用於支持其他活動。
• 使得市場營銷計劃更靈活。採用衝刺的短期市場營銷計劃可以更加有效。如果一種促銷方法在衝刺過程中顯示無效，市場營銷經理有機會將其換成另一種促銷方法。向每一個團隊成員說明每一個小的，但重要的任務的交付時間也變得更容易。
• 使得客戶以不同的方式參與。

參見

• 改善法
• 用戶故事
• 特性驅動開發
• 極限編程 (XP) - 通常由Scrum驅動
• 燃盡圖
• 看板 (軟件開發)
• 精益軟件開發
• 項目管理
• Unified Process
• 規範敏捷交付
• 基於大規模的敏捷框架（SAFe）
• Scrum度量和關鍵績效指標 （頁面存檔備份，存於網際網路檔案館）

外部連結

• 捷伴行Agile（頁面存檔備份，存於網際網路檔案館）
• Scrum精髓中文網站（頁面存檔備份，存於網際網路檔案館）
• Scrum中文交流社區（頁面存檔備份，存於網際網路檔案館）
• Scrum in five minutes
• Scrum Alliance
• Scrum.org（頁面存檔備份，存於網際網路檔案館）
• Scrum and XP from the Trenches
• Scrum articles directory
• Agile Alliance's Scrum library
• InfoQ.com / Agile（頁面存檔備份，存於網際網路檔案館） - Tracking change and innovation in the enterprise software development community (News, Articles, Books, Video)
• Agilo for Scrum (Open Source Scrum Tool, Scrum Software)
• Scrum and XP from the Trenches（頁面存檔備份，存於網際網路檔案館） by Henrik Kniberg. A 130-page PDF book describing in detail how Scrum and XP can be implemented from a practical perspective

• The New New Product Development Game（頁面存檔備份，存於網際網路檔案館） by Takeuchi and Nonaka. The paper that started it all.
• Scrum Delivers or Scrum and the Toyota Way by Boris Gloger. This paper maps the principles of Toyota explained by Liker, with the practices of Scrum.

參考文獻

• (PDF) Rising, L., Janoff, N.S. (2000). The Scrum Software Development Process for Small Teams Retrieved March 15，2007
• (PDF) Schwaber, K. Advanced Development Methods. SCRUM Development Process（頁面存檔備份，存於網際網路檔案館） Retrieved August 15，2006
• (video) Jeff Sutherland in Scrum Tuning: Lessons learned from Scrum implementation at Google（頁面存檔備份，存於網際網路檔案館） Retrieved 2007-12-15
• (video) Ken Schwaber in Scrum et al.（頁面存檔備份，存於網際網路檔案館） Retrieved 2008-01-19

延伸閱讀

• Vacaniti, Daniel. The Kanban Guide for Scrum Teams (PDF). scrum.org. February 2018 [2018-03-12]. （原始內容 (PDF)存檔於2021-11-19）. 
• Sutherland, Jeff; Schwaber, Ken. Scrum Guides. ScrumGuides.org. 2013 [2017-07-26]. （原始內容存檔於2017-07-25）. 
• Verheyen, Gunther (2013). Scrum - A Pocket Guide (A Smart Travel Companion) ISBN 978-9087537203.
• Münch, Jürgen; Armbrust, Ove; Soto, Martín; Kowalczyk, Martin. Software Process Definition and Management. 2012. ISBN 978-3-642-24291-5. 
• Deemer, Pete; Benefield, Gabrielle; Larman, Craig; Vodde, Bas. The Scrum Primer. 2009 [2009-06-01]. （原始內容存檔於2011-06-27）. 
• Janoff, N.S.; Rising, L. The Scrum Software Development Process for Small Teams (PDF). 2000 [2015-02-26]. （原始內容存檔 (PDF)於2015-11-06）.