Scrum是迭代式增量
软件开发过程
，是敏捷方法论中的重要框架之一，通常用于
敏捷软件开发
。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责
维护过程
和任务，产品负责人代表利益
所有者
，开发团队包括了所有开发人员。虽然Scrum是为管理
软件开发项目
而开发的，它同样可以用于运行
软件维护
团队，或者作为
计划管理方法
：Scrum of Scrums.
Scrum创始人之一Jeff Sutherland
Jeff Sutherland的第一份工作居然是
美国空军
战斗机飞行员，还曾于1967年获得了“壮志凌云”称号，完成过100次飞越北部
越南
的
作战任务
。服役后期，他到
斯坦福大学
拿下统计学硕士学位，并在
美国空军学院
教授数学统计学和
概率学
。11年军旅生涯结束后，他成为了科罗拉多
医学院
的教师并获得了博士学位。在
诺贝尔化学奖
得主莱纳斯·鲍林的赞助下，他以
放射学
、生物学及预防医学助理教授的身份参与了维生素与
癌症
研究中心的创立，担任八年
国家癌症中心
的主要研究员，负责科罗拉多地区所有癌症患者的数据统计和IT方案与研究，整合了国家注册、临床试验、
流行病学
研究和癌变的
超级计算机
数学模型
。1983年，他进入了一家遍及
北美
、经营着150家银行的公司，职务为先进系统副总裁及ATM业务部总经理。此后，Sutherland先后担任了11家软件公司的CEO、
CTO
或者工程副总裁，积累了丰富的
软件开发
经验。
Ken Schwaber
Ken Schwaber最初的职业也很特别——商船经理。在随后40多年开发生涯的前10年中，他曾经编写过操作系统，搞过嵌入式，为
IBM大型机
开发系统软件；先后在
芝加哥大学
、
伊利诺伊理工学院
、王安公司实验室工作，并逐渐展现出在
软件开发方法
上的天赋。在CASE工具和
结构化方法
热门的时候，他自己创办了
ADM公司
，从事软件开发方法
培训服务
。期间，公司开发了
软件方法
自动化工具MATE，用来生成各种软件流程所需的模板、计划等，生意很好。
Sutherland和Schwaber相识于1980年代早期。1987年，两人开始合作。一天，Sutherland问Schwaber：“你们开发MATE工具都用了当前流行的哪一种方法？”“当然什么都没用，”Schwaber回答，“要不然公司早就完蛋了。”他们意识到问题的
严重性
，开始与开发者交谈，研究新方法。
1993年，Sutherland读到了两位日本管理教授竹内弘高和
野中郁次郎
介绍制造业里出现的新的
产品开发
方法Rugby（
橄榄球
）的文章。这种方法的特点是整个流程都由一个高性能、跨功能的团队执行到底。他受到启发，结合自己多年的经验，与Easel公司的John Scumniotales和Jeff McKenna一起开发了一套方法，取名为Scrum（来源于橄榄球术语，不是缩写）。
而Schwaber则从
杜邦
公司一位化工过程控制专家那里取经，意识到项目分为两种：
确定性
项目，一切都已经确定，可以自动化
生产流程
；实验性项目，充满
不确定性
，哪怕一点微小的变化也会牵一发而动全身，因此只能用各种仪表不断监控，随时做出调整——这就是每日站会的由来。
两人在一个
IBM
项目合作，并做了更详尽的研究，Scrum诞生了。1995年
OOPSLA
大会上他们第一次向世人介绍了Scrum。可当时，两个人的公司都还在做千年虫和各种重型开发方法咨询方面的业务呢。
进入新世纪，互联网带来的巨变使
敏捷方法
受到了更多开发团队的欢迎，而其中Scrum以其扩展性、门槛低、名字和术语更容易被项目经理接受等因素，逐渐成为最受欢迎的敏捷流派。而推出
CSM
等系列认证，虽然争议颇大，但客观上对Scrum扩大影响力起到了重要作用。
当今，Scrum的影响已经远远超出
软件开发
，成为零售、军事、风险投资甚至学校里完成各种任务的创新方法，正在改变着世界。
Scrum敏捷方法在当前的
世界500强
企业当中得到了非常广泛的应用。
1986年，竹内弘高和
野中郁次郎
阐述了一种新的
整体性
的方法 ，该方法能够提高商业
新产品开发
的速度和灵活性：他们将这种新的'
整体性方法与
橄榄球
相比较，前者各阶段相互重叠，并且由一个
跨职能团队
在不同的阶段完成整个过程，而后者整个团队
"tries to go to the distance as a unit, passing the ball back and forth"
。他们对来自汽车，照片机器，计算机和打印机等产业的案例进行了研究。1991年，DeGrace和Stahl在《Wicked Problems, Righteous Solutions》一书中将这种方法称为Scrum，在竹内弘高和
野中郁次郎
的文章中提到的橄榄球术语。1990年代初，肯·施瓦伯在其公司使用了一种方法Advanced Development Methods（先进开发方法），这种方法后来发展为Scrum。同时，杰夫·萨瑟兰在Easel公司开发了一种类似的方法，并首次称之为Scrum。1995年，在奥斯汀举办的
OOPSLA
'95上，萨瑟兰和施瓦伯联合发表了论文首次提出了Scrum概念。施瓦伯和萨瑟兰在接下的几年里合作，将上述的文章，他们的经验，以及业界的
最佳实践
融合起来，形成我们当前所知的Scrum。2001年，施瓦伯与麦克·比窦（Mike Beedle）合著了《敏捷软件开发-使用Scrum过程》一书，介绍了Scrum方法。
Scrum过程
Scrum是一个包括了一系列的实践和预定义角色的过程骨架（是一种流程、计划、模式，用于有效率地开发软件）。
在每一次冲刺（一个15到30 天周期 ，长度由开发团队决定），开发团队创建可用的（可以随时推出）软件的一个增量。每一个冲刺所要实现的特性来自产品订单（product
backlog
，我觉得翻译成“
产品目标
”更恰当）， 产品订单（产品目标）是指按照优先级排列的需要完成的工作的概要的需求（目标）。哪些订单项（
目标项目
）会被加入一次冲刺，由冲刺计划会议决定。 在会议中，产品负责人告诉开发团队他需要完成产品订单中的哪些订单项。开发团队决定在下一次冲刺中他们能够承诺完成多少订单项。 在冲刺的过程中，没有人能够变更冲刺订单（sprint backlog），这意味着在一个冲刺中需求是被冻结的。
管理Scrum过程有很多实施方法，从白板上的
即时贴
到
软件包
。Scrum最大的好处是它非常容易学习，而且应用Scrum不需要太多的投入。
区别之一： 迭代长度的不同
XP的一个
Sprint
的迭代长度大致为1~2周, 而Scrum的迭代长度一般为 2~ 4周。
区别之二: 在迭代中, 是否允许修改需求
XP在一个迭代中，如果一个User Story(用户素材, 也就是一个需求)还没有实现， 则可以考虑用另外的需求将其替换， 替换的原则是需求实现的时间量是相等的。而Scrum是不允许这样做的，一旦迭代开工会完毕, 任何需求都不允许添加进来，并有Scrum Master严格把关，不允许开发团队受到干扰。
区别之三: 在迭代中，User Story是否严格按照优先级别来实现
XP是务必要遵守优先级别的。但Scrum在这点做得很灵活，可以不按照优先级别来做，Scrum这样处理的理由是：如果优先问题的解决者，由于其它事情耽搁，不能认领任务，那么整个进度就耽误了。另外一个原因是，如果按优先级排序的User Story #6和#10，虽然#6优先级高，但是如果#6的实现要依赖于#10，则不得不优先做#10。
区别之四:软件的
实施过程
中，是否采用严格的工程方法，保证进度或者质量
Scrum没有对软件的整个实施过程开出工程实践的处方，要求开发者自觉保证。但XP对整个流程方法定义非常严格，规定需要采用
TDD
、
自动测试
、
结对编程
、简单设计、重构等约束团队的行为。
Scrum
“猪”角色
猪是全身投入项目和Scrum过程的人； they are the ones with "their bacon on the line."
产品负责人代表了客户的意愿。这保证了Scrum团队在做从业务角度来说正确的事情。产品负责人编写
用户故事
，排出优先级，并放入产品订单。Scrum主管（或促进者）促进
Scrum
过程，他的主要工作是解决那些影响团队交付冲刺目标的障碍。Scrum主管并非团队的领导（由于他们是
自我组织
的），而是负责屏蔽外界对开发团队的干扰。Scrum主管确保Scrum过程按照初衷进行。Scrum主管是规则的执行者。开发团队是负责交付产品的团队。由5至9名具有跨职能技能的人（设计者，开发者等）组成小团队来完成实际的开发工作。
在冲刺中，每一天都会举行项目状况会议，被称为“scrum”或“
每日站立会议
”。每日站立会议有一些具体的指导原则：
会议准时开始。对于迟到者团队常常会制定惩罚措施（例如罚款，做
俯卧撑
，在脖子上挂橡胶鸡玩具）欢迎所有人参加，但只有"猪"可以发言。不论团队规模大小，会议被限制在15分钟。所有出席者都应站立。（有助于保持会议简短）会议应在固定地点和每天的同
一时间
举行。在会议上，每个团队成员需要回答三个问题：
你完成了哪些工作？以后你打算做什么？完成你的目标是否存在什么障碍？（Scrum主管需要记下这些障碍）
每一个冲刺完成后，都会举行一次冲刺回顾会议，在会议上所有团队成员都要反思这个冲刺。举行冲刺回顾会议是为了进行持续
过程改进
。会议的时间限制在4小时。
Scrum提倡所有团队成员坐在一起工作，进行
口头交流
，以及强调项目有关的规范（disciplines），这些有助于创造
自我组织
的团队。
Scrum的一个关键原则是承认客户可以在项目过程中改变主意，变更他们的需求，而预测式和计划式的方法并不能轻易地解决这种不可预见的需求变化。同样，Scrum采用了
经验方法
– 承认问题无法完全理解或定义，而是关注于如何使得开发团队快速推出和响应不断出现的需求的能力最大化。
以下是一些Scrum的通用实践：
客户成为开发团队中的一部分。（例如客户肯定对开发的结果真正感兴趣。）和所有其他形式的敏捷
软件过程
一样，Scrum有频繁的包含可以工作的功能的中间
可交付成果
。这使得客户可以更早的得到可以工作的软件，同时使得项目可以变更
项目需求
以适应不断变化的需求。频繁的风险和缓解计划是由开发团队自己制定。– 在每一个阶段根据承诺进行风险缓解，监测和管理（
风险分析
）。计划和模块开发的透明 – 让每一个人知道谁负责什么，以及什么时候完成。频繁的进行所有相关人员会议，以跟踪项目进展 – 平衡的（发布，客户，员工，过程）
仪表板
更新 – 所有相关人员的变更 – 你必须拥有
预警机制
，例如提前了解可能的延迟或偏差。没有问题会被藏在地毯下。认识到或说出任何没有预见到的问题并不会受到惩罚。在
工作场所
和
工作时间
内必须全身心投入。– 完成更多的工作并不意味着需要工作更长时间。
Scrum
项目管理方法
由于
市场营销
通常以项目的方式运作，许多一般
项目管理
的原则应用在市场营销上。市场营销也可以像项目管理技术那样进行优化。以Scrum方法进行市场营销被认为有助于克服市场营销经理们所遇到的问题。短时和固定的会议对于小的市场营销团队来说很重要，这是因为团队的每一个成员都可以了解其他人在做些什么，以及整个团队在朝着什么方向前进。Scrum在市场营销中应用可以：
在早期发现可能的问题，可以更快地，最小损失地应对问题。 根据Scrum的主要原则 “没有问题被扫入地毯下”，Scrum鼓励每一个团队成员描述他所遇到的困难，而这个困难可能会对整个团队的工作造成影响。降低
财务风险
。 在每一个冲刺周期的开始，企业所有者可以不付出任何代价的改变任何市场营销的因素：包括增加投资以夸大顾客数量，减少投资直至未知风险被减轻，或用于支持其他活动。使得
市场营销计划
更灵活。采用冲刺的短期市场营销计划可以更加有效。如果一种
促销方法
在冲刺过程中显示无效，市场营销经理
有机会
将其换成另一种促销方法。向每一个团队成员说明每一个小的，但重要的任务的交付时间也变得更容易。使得客户以不同的方式参与。
Scrum作为一个极佳的敏捷
项目开发
管理方法
，让过程项目管理变得更加有形，而可控软件的自我组织和自我管理工作方式，也能让所有成员积极配合并参与到全过程当中。在未来的工作实践环节，这些项目开发人员也需要在项目运行观念上进行调整，立足于项目实践工作进行优化和完善。
Schwaber K, Sutherland J.
． The Scrum Guide[M]
： Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, And Leave Competitors In the Dust. John Wiley & Sons, Inc..
， 2015
杨韶伟. 基于Scrum的项目管理过程优化研究与实现[D]. 华南理工大学, 2013.
王一舒, 蒋冬清, 李三雁. 基于Scrum框架的应用型大学科训项目管理初探[J]. 科教导刊(中旬刊), 2016(1).
林晓宇, 钟一文, 黄世国,等. 基于Scrum敏捷方法的软件工程实践教学探索[J]. 电脑知识与技术, 2011, 07(19):4762-4763.
张巍崴. Scrum软件开发方法在ROSS公司的应用研究[D]. 华东理工大学, 2014.
何晶.Scrum敏捷方法在软件项目管理中的应用[J].数字技术与应用,2021,39(3):87-89
