敏捷开发方法 - aqHi的博客
敏捷软件开发（英语：Agile software development），又称敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的 ...
1]
SCRUM已经出现很久了，像前面所论及的方法一样，该方法强调这样一个事实，即明确定义了的可重复的方法过程只限于在明确定义了的可重复的环境中，为明确定义了的可重复的人员所用，去解决明确定义了的可重复的问题。 Scrum 是用于开发、交付和维持错综复杂产品 (complex products) 的敏捷框架 (framework) [ <anchor>1]</anchor> 。最初着重于软件开发，之后已被用应用于其他领域，包括研究、销售、营销和其他先进技术领域。 一个 Scrum 团队建议为十名成员的团队而设计的，他们以迭代[ 2] (iterative) 与增量[ 3] (incremental) 式的方式交付工作，每个迭代称作 Sprint。一个 Sprint 的时间不超过一个月，通常是两星期。Scrum 团队在每个 Sprint 都专注在唯一一个共同的目标 (Sprint Goal)，每天的 Daily Scrum 团队中的开发人员 (Developers) 都检视朝向这共同目标的进度，和调适当下的计划。在 Sprint 结束时，团队会进行 Sprint 审查 (Sprint Review) 跟利害关系人 (Stakeholders) 一起检视当下的结果与调适计划，这是互相资讯交流的机会。最后，团队会进行 Sprint 回顾 (Sprint Retrospective) 来持续改善。
Scrum - 维基百科，自由的百科全书
主菜单

主菜单

移至侧栏隐藏

导航

帮助

搜索

外观

个人工具

## 目录

移至侧栏隐藏

开关目录

# Scrum

36种语言

不转换

工具

工具

移至侧栏隐藏

操作

常规

打印/导出

在其他项目中

外观

移至侧栏隐藏

维基百科，自由的百科全书

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過程

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

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

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

管理Scrum過程有很多實施方法，如即時貼、白板、甚至軟件包。 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会议

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

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

### Scrum用作营销项目管理方法

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

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

- 查

- 论

- 编

领域

概念

導向

模型

开发模型

其他模型

建模语言

软件

相关领域

隐藏分类：​

Wikipedia®和维基百科标志是 维基媒体基金会 的注册商标；维基™是维基媒体基金会的商标。

维基媒体基金会是按美国国內稅收法501(c)(3)登记的 非营利慈善机构。