SCRUM是一个用于开发和维持复杂产品的框架.docx

SCRUM是一个用于开发和维持复杂产品的框架.docx

《SCRUM是一个用于开发和维持复杂产品的框架.docx》由会员分享，可在线阅读，更多相关《SCRUM是一个用于开发和维持复杂产品的框架.docx（41页珍藏版）》请在冰豆网上搜索。

SCRUM是一个用于开发和维持复杂产品的框架

SCRUM

Scrum是一个用于开发和维持复杂产品的框架，是一个增量的、迭代的开发过程。

在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周（互联网产品研发可以使用1周的Sprint）。

在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。

Scrum团队总是先开发对客户具有较高价值的需求。

在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。

挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprintbacklog。

在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。

Scrum起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。

Scrum流程如下图：

SCRUM框架包括3个角色、3个工件、5个活动、5个价值

3个角色

1.产品负责人（ProductOwner）

2.ScrumMaster

3.Scrum团队

3个工件

1.产品Backlog（ProductBacklog）

2.SprintBacklog

3.燃尽图（Burn-downChart）

5个活动

1.Sprint计划会议（SprintPlanningMeeting）

2.每日站会（DailyScrumMeeting）

3.Sprint评审会议（SprintReviewMeeting）

4.Sprint回顾会议（SprintRetrospectiveMeeting）

5.产品Backlog梳理会议（ProductBacklogRefinement）

5个价值

1.承诺–愿意对目标做出承诺

2.专注–把你的心思和能力都用到你承诺的工作上去

3.开放–Scrum把项目中的一切开放给每个人看

4.尊重–每个人都有他独特的背景和经验

5.勇气–有勇气做出承诺，履行承诺，接受别人的尊重

SCRUM理论基础

Scrum以经验性过程控制理论（经验主义）做为理论基础的过程。

经验主义主张知识源于经验,以及基于已知的东西做决定。

Scrum采用迭代、增量的方法来优化可预见性并控制风险。

Scrum的三大支柱支撑起每个经验性过程控制的实现:

透明性、检验和适应。

Scrum的三大支柱如下：

第一：

透明性（Transparency）

透明度是指，在软件开发过程的各个环节保持高度的可见性，影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。

管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容。

也就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于他们对完成的定义。

第二：

检验（Inspection）

开发过程中的各方面必须做到足够频繁地检验，确保能够及时发现过程中的重大偏差。

在确定检验频率时，需要考虑到检验会引起所有过程发生变化。

当规定的检验频率超出了过程检验所能容许的程度，那么就会出现问题。

幸运的是，软件开发并不会出现这种情况。

另一个因素就是检验工作成果人员的技能水平和积极性。

第三：

适应（Adaptation）

如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么便需要对过程或是材料进行调整。

调整工作必须尽快实施，以减少进一步的偏差。

Scrum中通过三个活动进行检验和适应：

每日例会检验Sprint目标的进展，做出调整，从而优化次日的工作价值；Sprint评审和计划会议检验发布目标的进展，做出调整，从而优化下一个Sprint的工作价值；Sprint回顾会议是用来回顾已经完成的Sprint，并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意，并且工作更快乐。

SCRUM术语

Scrum：

Scrum无对应中文翻译

Agile：

敏捷

Lean：

精益

Iterative：

迭代式的

Iteration：

迭代

AgileManifesto：

敏捷宣言

Empirical：

经验性的

EmpiricalProcess：

经验性过程

Transparency：

透明性

InspectandAdapt：

检视与调整

Sprint：

原意为冲刺，Scrum中的Sprint无对应中文翻译，指一个迭代

SprintGoal：

Sprint目标

ProductOwner：

产品负责人简称PO

ScrumMaster：

简称SM,一般不翻译

DevelopmentTeam：

Scrum开发团队

ScrumTeam：

指PO,SM和开发团队

ScrumRoles：

Scrum角色，指PO,SM和开发团队

Emergent：

涌现的

ProductBacklog：

产品待办列表，指需求清单

SprintBacklog：

Sprint待办列表，指Sprint任务清单

SprintBurn-downChart：

Sprint燃尽图，团队用于做Sprint内的进展跟踪

ReleaseBurn-downChart:

 发布燃尽图，产品负责人做发布进展跟踪

SprintPlanningMeeting:

Sprint计划会议

DailyScrumMeeting：

每日站会

SprintReviewMeeting：

Sprint评审会议

SprintRetrospectiveMeeting:

Sprint回顾会议

ProductBacklogRefinement:

产品待办列表梳理

ProductBacklogItem:

产品待办清单条目，简称PBI

UserStory:

用户故事，指一条需求

StoryPoint：

衡量用户故事的工作量大小的计量单位

Velocity:

团队速度

SprintTask:

实现一条需求需要做的一个技术任务

DefinitionofDone:

DoD，完成的定义

Stakeholders：

干系人

Backlog：

待办列表

Artifact：

工件

Estimation：

估算

Collaboration：

协作

ScalingScrum：

大规模Scrum

SCRUM起源

Scrum的原始含义

Scrum原始含义是指英式橄榄球次要犯规时在犯规地点对阵争球。

争球双方各有8个队员参与，各方出3名前锋队员，并肩各站成一横排，面对面躬身互相顶肩，中间形成一条通道，其他前锋队员分别站在后面，后排队员用肩顶住前锋队员的臀部，组成3、2、3或3、4、1阵形。

然后，由犯规队的对方队员在对阵一侧1码外，用双手低手将球抛入通道，不得有利于本队。

当球抛入通道时，前排的3对前锋队员互相抗挤，争相踢球给本方前卫或后卫队员，前卫和后卫队员必须等候前锋将球踢回后，方可移动。

1986Scrum这个词汇首次应用于产品开发

1986年，竹内弘高和野中郁次郎在NewNewProductDevelopment Game文章首次提到将Scrum应用与产品开发，他们指出：

传统的“接力式”的开发模式已经不能满足快速灵活的市场需求，而整体或“橄榄球式”的方法——团队作为一个整体前进，在团队的内部传球并保持前进，这也许可以更好的满足当前激烈的市场竞争。

 1993年JeffSutherland首次将Scrum用于软件开发

敏捷思想深受日本工业界最佳实践的影响，尤其是丰田和本田公司推行的精益原则，以及竹内弘高和野中郁次郎开发的知识管理策略。

受到以上思想的影响，以及对世界范围内软件项目的研究，JeffSutherland在1993年首次在Easel公司定义了用于了软件开发行业的Scrum流程，并开始实施。

1995年JeffSutherland和KenSchwaber规范化了Scrum框架，并在OOPSLA95上公开发布。

2001年敏捷宣言及原则发布、敏捷联盟成立，Scrum是其中一种敏捷方法。

2001年，KenSchwaber和MikeBeedle推出第一本Scrum书籍《Scrum敏捷软件开发》。

2002年KenSchwaber和MikeCohn共同创办了Scrum联盟。

经验性过程

软件开发是一个复杂的活动，在软件产品开发的过程中不仅存在着需求的不确定性，也存在着技术的不确定性，再加上参与软件开发的主体通常是由多人组成的软件开发团队，加上人的因素，就让整个软件开发的活动变得非常复杂。

如下图所示，软件开发活动通常处在下图的很复杂的区域。

图-01

为了管理软件开发的活动，我们会引入过程控制来管理它。

过程控制通常有两种方式，第一种方式是预定义的过程，第二种方式是经验性过程。

我们所熟知的是预定义的过程，它通常是使用已知的方法解决已知的问题。

制造业的生产线就是典型的预定义过程，例如生产饼干、啤酒、汽车的生产线等。

预定义的过程的特点是给予固定的输入，得到固定的输出，过程可重复。

它的优势在于可以大规模批量生产。

预定义过程的缺点在于一旦过程定义出现错误，或产品设计上存在瑕疵，会造成比较大的损失。

图－02

如果我们期望解决的问题比较复杂，并且存在着较大的不确定性的时候，我们需要使用经验性过程。

经验性过程的特点是过程是不能够完全预先定义好，结果是不可预知的，生产过程是不可重复的。

比如研究一项新技术，下一盘棋，踢一场球赛，在过程运行当中，我们需要通过不断的获得真实的反馈，然后进行适应和调整，使得过程能够产出我们需要的结果。

“在过程运行机制相当简单易懂的情况下，典型的做法是采用预定义的建模方式。

如果过程复杂程度超出预定义方式的能力范围，便应用经验性方式。

”

                               ——B.A.OgunnaikeandW.H.Ray

《过程动态学、建模与控制》

软件产品的研发通常存在多很多的不确定性，并且生产的过程非常的复杂，所以更适合使用经验性过程来管理。

Scrum以经验性过程控制理论做为理论基础的过程。

Scrum采用迭代、增量的方法来优化可预见性并控制风险。

Scrum过程框架的基石包括如下三个方面：

第一：

透明性（Transparency）

透明度是指，在软件开发过程的各个环节保持高度的可见性，影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。

管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容。

也就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于他们对完成的定义。

第二：

检验（Inspection）

开发过程中的各方面必须做到足够频繁地检验，确保能够及时发现过程中的重大偏差。

在确定检验频率时，需要考虑到检验会引起所有过程发生变化。

当规定的检验频率超出了过程检验所能容许的程度，那么就会出现问题。

幸运的是，软件开发并不会出现这种情况。

另一个因素就是检验工作成果人员的技能水平和积极性。

第三：

适应（Adaptation）

如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么便需要对过程或是材料进行调整。

调整工作必须尽快实施，以减少进一步的偏差。

Scrum中通过三个活动进行检验和适应：

每日例会检验Sprint目标的进展，做出调整，从而优化次日的工作价值；Sprint评审和计划会议检验发布目标的进展，做出调整，从而优化下一个Sprint的工作价值；Sprint回顾会议是用来回顾已经完成的Sprint，并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意，并且工作更快乐。

SCRUM团队的三个角色

Scrum团队中包括三个角色，他们分别是产品负责人、开发团队和ScrumMaster。

Scrum团队是自组织、跨职能的完整团队。

自组织团队决定如何最好地完成他们的工作,而不是由团队外的其他人来指挥他们。

跨职能的团队拥有完成工作所需要的全部技能,不需要依赖团队外部的人。

Scrum团队模式的目的是最大限度地优化适应性、创造性和生产力。

Scrum团队通过迭代和增量交付产品功能的方法最大化反馈的机会。

增量交付潜在可交付的产品增量保证了每个迭代都有潜在可发布的版本。

Scrum角色之：

产品负责人

产品负责人负责最大化产品以及开发团队工作的价值。

实现这一点的方式会随着组织、Scrum团队以及单个团队成员的不同而不同。

产品负责人是管理产品待办事项列表的唯一责任人。

产品待办事项列表的管理包括:

∙清晰地表达产品代办事项列表条目

∙对产品代办事项列表中的条目进行排序,最好地实现目标和使命

∙确保开发团队所执行工作的价值

∙确保产品代办事项列表对所有人可见、透明、清晰,并且显示Scrum团队的下一步工作

∙确保开发团队对产品代办事项列表中的条目达到一定程度的理解

产品负责人可以亲自完成上述工作,也可以让开发团队来完成。

然而,产品负责人是负责任者。

产品负责人是一个人,而不是一个委员会。

产品负责人可能会在产品代办事项列表中体现一个委员会的需求,但要想改变某条目的优先级必须先说服产品负责人。

为保证产品负责人的工作取得成功,组织中的所有人员都必须尊重他的决定。

产品负责人所作的决定在产品待办事项列表的内容和排序中要清晰可见。

任何人都不得要求开发团队按照另一套需求开展工作,开发团队也不允许听从任何其他人的指令。

Scrum角色之：

开发团队

开发团队包含了专业人员,负责在每个Sprint的结尾交付潜在可发布的“完成”产品增量。

只有开发团队的成员才能创造增量。

开发团队由组织构建并授权,来组织和管理他们的工作。

所产生的协同工作能最大化开发团队的整体效率和效力。

开发团队有以下几个特点:

∙他们是自组织的,没有人（即使是ScrumMaster都不可以）告诉开发团队如何把产品代办事项列表变成潜在可发布的功能。

∙开发团队是跨职能的,团队作为一个整体拥有创造产品增量所需要的全部技能。

∙Scrum不认可开发团队成员的头衔,无论承担哪种工作他们都是开发者。

此规则无一例外。

∙开发团队中的每个成员可以有特长和专注领域,但是责任归属于整个开发团队

∙开发团队不包含如测试或业务分析等负责特定领域的子团队。

开发团队的规模

开发团队最佳规模是小到足以保持敏捷性,大到足以完成重要工作。

少于3人的开发团队没有足够的交互,因而所获得的生产力增长也不会很大。

小团队在Sprint中可能会受到技能限制,从而导致无法交付可发布的产品增量。

大于9人的团队需要过多的协调沟通工作。

大型团队会产生太多复杂性,不便于经验过程管理。

产品负责人和ScrumMaster的角色不包含在此数字中,除非他们也参与执行Sprint代表事项列表中的工作。

Scrum角色之：

ScrumMaster

ScrumMaster负责确保Scrum被理解并实施。

为了达到这个目的,ScrumMaster要确保Scrum团队遵循Scrum的理论、实践和规则。

ScrumMaster是Scrum团队中的服务式领导。

ScrumMaster帮助Scrum团队外的人员了解他们如何与Scrum团队交互是有益的。

ScrumMaster通过改变这些交互来最大化Scrum团队所创造的价值。

ScrumMaster服务于产品负责人

ScrumMaster以各种方式服务于产品负责人,包括:

∙找到有效管理产品代办事项列表的技巧

∙清晰地和开发团队沟通愿景、目标和产品代表事项列表条目

∙教导开发团队创建清晰简明的产品代表事项列表条目

∙在经验主义环境中理解长期的产品规划

∙理解并实践敏捷

∙按需推动Scrum活动

ScrumMaster服务于开发团队

ScrumMaster以各种方式服务于开发团队,包括:

∙指导开发团队自组织和跨职能

∙教导并领导开发团队创造高价值的产品

∙移除开发团队进展过程中的障碍

∙按需推动Scrum活动

∙在Scrum还未完全被采纳和理解的组织环境下指导开发团队

ScrumMaster以各种方式服务于组织,包括:

∙领导并指导组织采用Scrum

∙在组织范围内计划Scrum的实施

∙帮助员工及干系人理解并实施Scrum和经验性产品开发

∙发起能提升Scrum团队生产力的变革

∙与其他ScrumMaster一起工作,帮助组织更有效的应用Scrum

SCRUM的三个工件

Scrum的工件以不同的方式展现工作和价值,可以用来提供透明性以及检验和适应的机会。

Scrum中所定义的工件能最大化关键信息的透明性,来保证Scrum团队成功地交付完成的增量。

ProductBacklog–产品待办事项列表

产品待办事项列表是一个排序的列表,包含所有产品需要的东西,也是产品需求变动的唯一来源。

产品负责人负责产品待办事项列表的内容、可用性和优先级。

产品待办事项列表是一个持续完善的清单,最初的版本只列出最初始的和众所周知的需求。

产品待办事项列表根据产品和开发环境的变化而演进。

待办事项列表是动态的,它经常发生变化以识别使产品合理、有竞争力和有用所必需的东西。

只要产品存在,产品待办事项列表就存在。

产品待办事项列表列出了所有的特性、功能、需求、改进方法和缺陷修复等对未来发布产品进行的改变。

产品待办事项列表条目包含描述、次序和估算的特征。

产品待办事项列表通常以价值、风险、优先级和必须性排序。

它是一个按照优先级由高到低排列的一个序列，每个条目有唯一的顺序。

排在顶部的产品待办事项列表条目需要立即进行开发。

排序越高,产品待办事项列表条目越紧急,就越需要仔细斟酌,并且对其价值的意见越一致。

排序越高的产品待办事项列表条目比排序低的更清晰、更具体。

根据更清晰的内容和更详尽的信息就能做出更准确的估算。

优先级越低,细节信息越少。

开发团队在接下来的Sprint中将要进行开发的产品待办事项列表条目是细粒度的,已经被分解过,因此,任何一个条目在Sprint的时间盒内都可以被“完成”。

开发团队在一个Sprint中可以“完成”的产品待办事项列表条目被认为是“准备好的”或者“可执行的”,能在Sprint计划会议中被选择。

随着产品的使用、价值的获取以及市场的反馈,产品待办事项列表变成了更大、更详尽的列表。

因为需求永远不会停止改变,所以产品待办事项列表是个不断更新的工件。

业务需求、市场形势和技术的变化都会引起产品待办事项列表的变化。

若干个Scrum团队常常会一起开发某个产品。

但描述下一步产品开发工作的产品待办事项列表只能有一个。

那么这就需要使用对产品待办事项列表条目进行分组的属性。

通过产品Backlog地梳理来增添细节、估算和排序。

这是一个持续不断的过程,产品负责人和开发团队协作讨论产品代表事项列表条目的细节。

在产品待办事项列表梳理的时候,条目会被评审和修改。

然而,产品负责人可以随时更新产品代办事项列表条目或酌情决定。

梳理在Sprint中是一项兼职活动,在产品负责人和开发团队之间展开。

通常,开发团队有自行优化的领域知识。

然而,何时如何完成优化是Scrum团队的决定。

优化通常占用不超过开发团队10%的时间。

开发团队负责所有的估算工作。

产品负责人可以通过协助团队权衡取舍来影响他们的决定。

但是,最后的估算是由执行工作的人来决定的。

监控向目标前进的进度

在任何时间,达成目标的剩余工作量是可以被累计的。

产品负责人至少在每个Sprint评审的时候追踪剩余工作总量。

产品负责人把这个数量与之前Sprint评审时的剩余工作量做比较,来评估在希望的时间点完成预计工作达成目标的进度。

这份信息对所有的干系人都透明。

Scrum不考虑已经花在产品代办事项列表条目上的工作时间。

我们只关心剩余工作和日期这两个变量。

各种趋势燃尽图、燃烧图和其他计划实践都能用来预测进度。

它们已经被证实有用。

然而,这并不能代替经验主义的重要性。

在复杂的环境下,将要发生的东西是未知的,只有已经发生的事情才能用来做前瞻式的决策。

SPRINTBACKLOG

Sprint代办事项列表是一组为当前Sprint选出的产品代办事项列表条目,外加交付产品增量和实现Sprint目标的计划。

Sprint代办事项列表是开发团队对于哪些功能要包含在下个增量中,以及交付那些功能所需工作的预计。

Sprint代办事项列表定义了开发团队把产品代办事项列表条目转换成“完成”的增量所需要执行的工作。

Sprint代办事项列表使开发团队确定的、达到Sprint目标所需的工作清晰可见。

Sprint代办事项列表是一份足够具体的计划,使得进度上的改变能在每日例会中得到理解。

开发团队在整个Sprint中都会修改Sprint代办事项列表,Sprint代办事项列表也会在Sprint的进程中慢慢显现,比如开发团队按照计划工作并对完成Sprint目标所需的工作有更多的了解。

当出现新工作时,开发团队需要将其追加到Sprint待办事项列表中去。

随着任务进行或者被完成,需要更新每项任务的估算剩余工作量。

如果计划中某个部分失去开发的意义,就可以将其除去。

在Sprint内只有开发团队可以对Sprint待办事项列表进行修改。

Sprint待办事项列表是高度可见的,是对团队计划在当前Sprint内完成工作的实时反映,并且,该列表只属于开发团队。

ProductBacklog功能点被放到Sprint的固定周期中，SprintBacklog会因为如下原因发生变化:

1.随着时间的变化，开发团队对于需求有了更好的理解，有可能发现需要增加一些新的任务到SprintBacklog中。

2.程序缺陷做为新的任务加进来，这个都做为承诺提交任务中未完成的工作。

ProductOwner也许会和Scrumteam一起工作，以帮助team更好的理解Sprint的目标，ScrumMaster和team也许会觉得小的调整不会影响sprint的进度，但会给客户带来更多商业价值。

监控Sprint进度

在Sprint中的任意时间点,Sprint待办事项列表的所有剩余工作总和都可以被计算。

开发团队至少在每日例会时追踪所有的剩余工作。

开发团队每天追踪剩余总和并预测达成Sprint目标的可能性。

通过在Sprint中不断追踪剩余工作,开发团队可以管理自己的进度。

Scrum不考虑已经花在Sprint待办事项列表上的工作时间。

我们只关心剩余工作和日期这两个变量。

燃尽图（BURN-DOWNCHART）

Sprint燃尽图（SprintBurn-downChart）

SprintBurndownChart显示了Sprint中累积剩余的工作量，它是一个反映工作量完成状况的趋势图。

图中Y轴代表的是剩余工作量，X轴代表的是Sprint的工作日。

在Sprint开始的时候，ScrumTeam会标示和估计在这个Sprint需要完成的详细的任务。

所有这个Sprint中需要完成，但没有完成的任务的工作量是累积工作量，团队会根据进展情况每天更新累积工作量，如果在Sprint结束时，累积工作量降低到0，Sprin