Scrum

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

一個 Scrum 團隊建議為十名成員的團隊而設計的，他們以迭代^[2] （iterative）與增量^[3] （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”中，闡述了一種新的整體性的方法 ，該方法能夠提高商業新產品開發的速度和靈活性：^[4]
  • 文章中在產品開發的背景下引入了術語 scrum，他們將這種新的整體性方法與橄欖球相比較，前者各階段相互重疊，並且由一個跨職能團隊在不同的階段完成整個過程，而團隊「作為一個整體前進，把球傳來傳去」。
  • 他們對來自汽車，影印機，計算機和印表機等產業的案例進行了研究。
• 1991年，Peter DeGrace 和 Leslie Hulet Stahl 在《Wicked Problems, Righteous Solutions》^[5]一書中將這種方法稱為scrum，引用在竹內弘高和 野中郁次郎的文章中提到的 scrum 術語。

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

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

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

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

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

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

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

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

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

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

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

產品負責人（product owner）

產品負責人代表了客戶的意願。這保證了Scrum團隊在做從業務角度來說正確的事情。產品負責人編寫用戶故事，排出優先級，並放入產品訂單（product backlog）。产品负责人决定团队每个冲刺（sprint）要完成哪些任务。产品负责人负责最大化产品以及开发团队工作的价值。产品负责人通过在每个冲刺统一完整地执行Scrum流程，来保持合理开发节奏，从而保障产品的质量。^[17]

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

Scrum主管促進Scrum過程，他的主要工作是去除那些影響團隊交付沖刺目標的障礙。 Scrum主管並非團隊的領導/项目经理（因為團隊是自我組織的），而是一個負責屏蔽外界對開發團隊的干擾（例如某位领导对开发团队的指手画脚）的角色。 Scrum主管確保Scrum過程被按照初衷使用，即维护每个冲刺的流程，确保每个冲刺能够顺利实施。 Scrum主管是規則的執行者。Scrum主管负责团队建设，通过对士气积极主动的调节和鼓舞，来保持团队的凝聚力和战斗力。^[17]

開發團隊（dev team）

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

雞並不是實際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应用于产品开发是在《新新产品开发游戏》^[4] 第一次提出，之后野中郁次郎和竹内弘高合著的《创造知识的企业》（牛津大学出版社，1995年）进行了详细的阐述。今天Scrum被用于开发金融产品，互联网产品，以及医药产品。

由于市场营销通常以專案的方式运作，许多一般專案管理的原则应用在市场营销上。市场营销也可以像專案管理技术那样进行优化。以Scrum方法进行市场营销被认为有助于克服市场营销经理们所遇到的问题。短时和固定的会议对于小的市场营销团队来说很重要，这是因为团队的每一个成员都可以了解其他人在做些什么，以及整个团队在朝着什么方向前进。Scrum在市场营销中应用可以：

• 在早期发现可能的问题，可以更快地，最小损失地应对问题。 根据Scrum的主要原则 “没有问题被扫入地毯下”，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.

• 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）.