scrum的起源
scrum这个词来自于英式橄榄球运动。要翻译的话，可以理解为“争球”。一般出现意外或者暴力情况的时候会进行scrum。
scrum表现形式为：双方队伍的前锋肩靠着肩战成一横排，面对面躬身，肩膀抵在一起，这样底下就形成了一个通道。犯规的那一队球员会把球抛进通道，这是双方的前锋互相对抗把球踢给自家的前卫或者后卫，前卫和后卫都只能等球踢回后才可以移动。
1986年的时候，竹内弘高和野中郁次郎在哈佛商业评论发表了《新新产品开发游戏（The New New Product Development Game）》文章，被引用为Scrum框架的灵感来源。在这篇文章中描述了一种新的整体性方法，该方法把开发新产品与橄榄球运动进行了类比。
后面就不得不提到2个人Ken Schwaber和Jeff Sutherland。
-
1990年代初，Ken Schwaber在他的公司使用了一种方法：Advanced Development Methods（先进开发方法）
-
1993年时，Jeff Sutherland首次在Easel公司定义了用于软件开发行业的scrum流程并开始实施。
这两个人都各自在自己的公司尝试了scrum的软件开发方式，然后在1995年时，奥斯汀举办的OOPSLA ’95上，它们联合发表了论文，提出了scrum的概念。后面几年他们一直不断的融合他们的经验和业界的最佳实践，形成了我们知道的scrum。
2001年，Ken Schwaber 与 Mike Beedle合著了第一本scrum书籍：《Agile Software Development with Scrum》，介绍了Scrum方法。
2001年，Jeff Sutherland和Ken Schwaber参与了犹他州的17人聚会，参与发布了《敏捷宣言和十二原则》。
2002年 Ken Schwaber和Mike Cohn共同创办了Scrum联盟, 开始发布Scrum Master认证体系及其衍生产品。
2010年 Jeff Sutherland和Ken Schwaber发布《Scrum指南》，随后对其逐步更新，建立了全球认可的Scrum知识体系。
Scrum中的角色
了解了历史后，来看一下scrum中涉及的三种角色：PO、scrum master和scrum团队。
PO全称product owner是产品负责人，他主要把控产品的方向，对产品的Why和What负责，也就是说他要知道为什么有这个产品，这个产品是什么。
Scrum master是团队中的教练角色，主要关注人和人之间的互动质量，排除外界对于团队的影响。
Scrum Team是完整的跨职能的自组织团队，这里提到了2个词，一个是跨职能，指的是团队具备了工作所需的所有技能，不需要依赖外部。一个是自组织，指的是团队内部自己运转，团队可以自己选择要完成的方式，同样不依赖于外部。
价值路线图
敏捷中的价值路线图如下：
这个V字形的右边就是常规上说的scrum核心，在讲scrum之前，先了解一下它有的一些先决活动和产出物（左边的step1到step3）
- 第一步是通过会议得出项目愿景，一般是产品负责人发起的，主要就是清晰的定义出符合公司战略的产品愿景。
- 第二步是通过会议得到产品路线图,同样也是产品负责人发起的，产品路线图是基于时间维度的产品规划。
- 第三步是发布计划会议，主要产品功能的发布计划，会定义出高优先级的功能模块和发布时间节点，也会指出可能存在的风险。 1-3步是scrum核心流程外的最佳实践。
产品愿景
产品愿景是产品负责人对产品未来前景和方向的一个高度概括描述，它应该要符合公司或组织的战略目标。 愿景的价值就是让团队了解产品的价值，能够建立共同的目标，激发团队士气。 好的愿景需要回答以下问题：
- 产品是什么？
- 产品将是什么？
- 产品应该是什么？
- 用户是谁？
- 竞争对手是谁？
- 如何满足用户需求并超越竞争对手？
可以用以下模板来进行描述愿景：
- 对于：（目标客户）
- 目前存在：（问题&需求描述）
- 我们提供：（产品名称）
- 这是一个：（产品品类名）
- 它能够：（满足需求&解决问题的方式描述）
- 不同于以往的：（产品品类名）
- 比如：（竞品名称）
- 我们的产品：（核心卖点&差异化特性）
- 而且符合：（公司愿景）
产品路线图/RoadMap
产品路线图是产品需求在时间轴上的概览，可以使用产品路线图来对需求进行分类、排定优先级，然后确定发布时间表。Roadmap是产品负责人推动项目发展的重要工具，清晰的表述了每个阶段应该做什么。有效的路线图不仅是一个强调产品发布和功能的时间表，也是一个动态的文档，在项目进行过程中根据实际情况不断更新，例如在早期，对需求、工作量、优先级、完成时间的估算不要求也无法很精确，都可以随着项目进行不断细化调整的。
以下是找的三种RoadMap方式：
发布计划
Scrum以Sprint的方式构建产品，每个Sprint中都会交付产品功能，通常价值最高、风险最大的部分功能先开发，当创造出足够多的有价值的、可供使用的产品功能时，产品就可以发布了。
所以发布计划需要确定整体发布目标、大致交付日期、发布所包含的全部特性和功能、具有最高优先级的产品Backlog条目、重大风险等。
发布计划不是固定不变的，团队可以根据开发进程，以每个Sprint为基础调整发布计划。
scrum的五个重要事件
Scrum 通过固定的事件来减少其他会议的必要。 Scrum的固定事件咋眼一看很多，但是所有事件都是有Timebox限定的，即每一个事件会议限制在最长的时间范围内。
Sprint 是 Scrum 的核心，它的长度一般不超过一个月，短的有一到二周。如果 Sprint 长度太长，复杂性和风险有可能会增加。Sprint 确保至少每月一次的频率来对进度进行检视和回顾，从而达到可预测性。
一个完整的 Sprint 会在这段时间内构建一个完成、可用的产品功能。在整个开发过程期间，Sprint 的长度保持一致。一个 Sprint 结束后，新的 Sprint 紧接着立即开始。
如上图，Sprint 五大重要事件为： Sprint 计划会议、每日 Scrum 站会、Sprint 评审会议、 Sprint 回顾会议和Sprint自身。Sprint 除了本身作为一个事件以外，它还是其他所有事件的容器，在 Scrum 中的每个事件都是用来进行检视和适应的机会。这些事件都是被特别设计用来确保达成透明和检视，如果不能包含这些事件中的任何一个事件，都会导致透明化的降低，也会丧失进行检视与适应的机会。
在 Sprint 期间：
- 不能做出有害于 Sprint 目标的改变
- 不能降低质量目标
- 随着对信息掌握的增加，产品负责人与开发团队之间对范围内要做的事可能会澄清和重新协商
Backlog Grooming Meeting
Backlog Grooming Meeting中文叫待办事项整理会议，它是个可选会议，一般在冲刺计划会议开始之前3天进行，大约30分钟。
参与人：PO与Scrum Master必须参加，关键开发者或架构师需要参加。
会议的目标：确保Product Backlog（产品代表事项列表）是完善整齐的。
一个整理好的Product Backlog有以下特点：
- 任务按照其优先程度进行排序，最需要优先实现的任务排在最上面
- 用户故事已经完善，包含验收条件，详细需求，可参考的原形图与任何可以辅助说明需求的文档
会议流程： （1）由PO将一批希望团队在下次Sprint实现的用户故事，按照实现顺序，描述给在场的团队成员。 （2）Scrum Master与在场成员分析用户故事，明确指出团队认为需求不明确的地方，PO现场记录，会后补全。 （3）Scrum Master与架构师&在场成员分析用户故事需要包含哪些技术任务，Scrum Master先把子任务建立，方便冲刺计划会议的时候团队可以更准确的预估任务故事点。 （4）会议结束，PO确保在冲刺计划会议开始之前团队提出的问题都能被解决。
Sprint Planning Meeting
Sprint Planning Meeting参与人是整个scrum 团队。 这个会议在实践过程中，极有可能会超时，所以Scrum Master 要确保会议顺利举行，并且每个参会者都理解会议的目的。Scrum Master 要教导 Scrum 团队遵守Timebox的规则。
Sprint Planning Meeting会议的输入是Product Backlog、最新的产品增量功能、开发团队在这个 Sprint 中能力的预测（能完成多少功能）。这其中Product Backlog里优先级是一个重要的视角，优先级越高的backlog需要越清晰，越详细。而对于优先级低的backlog，详细程度会越低，可能都不像是一个backlog项（非常低的优先级，只相当于一个占位符，来用做提醒）。
Sprint Planning Meeting主要回答2个问题：
话题一：这次 Sprint 能做什么？
话题二: 如何完成所选的工作？
Sprint Planning Meeting的主要形式：
产品负责人讲解 Sprint 目标以及达成该目标所需完成的产品待办列表项。整个 Scrum 团队协同工作来理解 Sprint 的工作。
在设定了 Sprint 目标并选出这个 Sprint 要完成的产品待办列表项之后，开发团队将决定如何在 Sprint 中把这些功能构建成“完成”的产品增量。这个 Sprint 中所选出的产品待办列表项加上交付它们的计划称之为 Sprint Backlog(Sprint 待办列表)。如果开发团队认为工作过多或过少，他们可以与产品负责人重新协商所选的产品待办列表项。
Sprint 目标
Sprint 目标指的是在这个 Sprint 通过实现产品待办列表要达到的目的，所选定的产品待办列表项会提供一个连贯一致的功能，从而促使开发团队一起工作而不是分开独自做。
Daily Stand Up Meeting
每日 Scrum 站会不超过 15 分钟，在 Sprint 的每一天都举行。在每日 Scrum 站会上，开发团队回顾过去一天完成的内容，并且为接下来的一天制定工作计划。如果有需要详细讨论的细节，开发团队或者开发团队成员通常会在每日 Scrum 站会后立即聚到一起进行更详细的讨论，或者为 Sprint 中剩余的工作进行调整或重新计划。
目标：
- 检视完成 Sprint 目标的进度，检视完成 Sprint 待办列表的工作进度趋势。
- 增进交流沟通
- 发现开发过程中需要移除的障碍
- 提高开发团队的认知程度
Scrum Master 要确保开发团队每日站会如期举行，但开发团队自己负责召开会议。Scrum Master 教导开发团队将每日 Scrum 会议时间控制在 15 分钟内。 每日 Scrum 站会是开发团队的内部会议。如果有开发团队之外的人出席会议，Scrum Master 必须确保他们不会干扰会议进行。
Review Meeting
Review Meeting指的是评审会议，一般在 Sprint 快结束时进行，目的是来检视所交付的产品增量并按需调整Product Backlog。在 Sprint 评审会议中，Scrum 团队和干系人会同步完成情况和 Sprint 期间产品待办列表的变化，所有参会人员一起讨论接下来可能要做的事情。
Sprint 评审会议：
- 产品负责人邀请 Scrum 团队和主要的干系人参加会议；
- 产品负责人说明哪些产品待办列表项已经“完成”和哪些没有“完成”；
- 开发团队讨论在 Sprint 期间哪些工作做的很好，遭遇到什么问题以及问题是如何解决的；
- 开发团队演示“完成”的工作并解答关于所交付增量的问题；
- 产品负责人讨论当前的产品待办列表的情况；
- 参会的所有人就下一步的工作进行探讨；
Restrospective Meeting
Restrospective Meeting 是 Scrum 团队检视自身并创建下一个 Sprint 改进计划的机会。
时机：
回顾会议发生在 Sprint 评审会议结束之后，下个 Sprint 计划会议之前。
时长：
对于长度为一个月的 Sprint 来说，回顾会议时间最长不超过 3 小时。对于较短的 Sprint 来说，会议时间通常会缩短。
目的：
- 检视前一个 Sprint 中关于人、关系、过程和工具的情况如何；
- 找出并加以排序做得好的和潜在需要改进的主要方面；
- 制定改进 Scrum 团队工作方式的计划；
Scrum Master 职责：
Scrum Master 确保会议举行，并且每个参会者都明白会议的目的，同时进行过程中要教导大家遵守时间盒的规则。Scrum Master 需要鼓励 Scrum 团队在 Scrum 的过程框架内改进开发过程和实践，使得团队能在下个 Sprint 中更高效&愉快。
Restrospective Meeting的形式不限制，可以自行选择。
尾言
以上就已经介绍了scrum的几个主要事件，在实际项目中要根据情况来进行。一个高效的scrum团队需要每一个人都遵守scrum的价值观才能持续运转。当团队践行了承诺、勇气、专注、开放和尊重五大价值观并且互相信用时，才能成功实践scrum。
期望每一个看了这篇文章的人都能对scrum有了一定的了解。
参考资料库：
scrum中文网：www.scrumcn.com/agile/scrum… 以上图片资料来自于网络。
