敏捷其实很简单3---敏捷方法之scrum
通过上图我们可以看到Scrum作为各种敏捷实践方法中最为常用的一种，今天我们也来聊一聊Scrum。
Scrum的历史可以追溯到1986年《哈佛商业评论》中的一篇文章《新型的新产品开发策略》（The New New Product Development Game，竹内弘高、野中郁次郎，1986）。这篇文章描述了像本田、佳能、富士施乐这样的公司是如何通过可伸缩、基于团队的并行产品开发方式开发出了世界一流的产品。文章同时强调了授权、自组织团队的重要性，并概要描述了管理在开发过程中发挥的作用。
当然，SCRUM这个词没有什么标准的中文解释，它是来源于橄榄球中的一个争球的动作，如下图。
竹内弘高和野中郁次郎在New New Product Development Game文章首次提到将Scrum应用与产品开发，他们指出：传统的“接力式”的开发模式已经不能满足快速灵活的市场需求，而整体或“橄榄球式”的方法——团队作为一个整体前进，在团队的内部传球并保持前进，这也许可以更好的满足当前激烈的市场竞争。
上图是SCRUM的一个典型架构图，我们可以看到里面有很多要素，下面我们一一介绍这些要素。
Scrum的3355
3个角色
Product Owner：产品负责人，清楚的知道产品的愿景，需要对产品待办列表的梳理，优化，优先级排序等负责。决定团队每个冲刺要完成哪些任务。对于团队非常重要，决定Why和What。一般可以对应为现有的产品经理和BA的角色。
Scrum Master：Scrum Master是Scrum教练和团队带头人，确保团队合理的运作Scrum，并帮助团队扫除实施中的障碍。
Team：可以认为是开发团队，但是一个跨职能的团队，能够交付一个端到端的真正对客户有价值的产品。
3个工件
Product Backlog：是指产品待办事项的集合，其中事务有优先级判断，先处理优先级高的事项。产品待办列表源自于Scrum方法。在Scrum中，产品主管（Product Owner）收集来自于各方的需要、期望、诉求等等到产品待办列表中，给定优先级；当冲刺计划会议上，团队从产品待办列表中挑选其中事项组成冲刺待办列表。常见的待办事项表达形式是用户故事。
Sprint Backlog：每个迭代的功能开发列表，PO会根据团队的能力并按照产品待办列表中的优先级来选取每个冲刺要做的事情。团队可以专注在每个迭冲刺要走的事情上而不被打断。
Burndown chart:燃尽图，在每个迭代显示剩余工作时间和任务完成情况。
5个价值观
专注：每个迭代只专注于迭代要完成的事情，团队和个人的能力和精力是有限的，在有限的时间内专注于最有价值的事情，以取得好的结果。
勇气：要有勇气去面对各种挑战。
公开：团队所有的进展，问题，阻碍都是对所有人可视化，透明的。这样的团队才是彼此尊重。同时也能暴露问题。
承诺：作为一个自组织团队，在迭代开始的时候做出承诺，并在迭代中全力完成。
尊重：团队是长期坐到一起，并且稳定的，有助于加深彼此的了解和沟通。
5种工件
Sprint:冲刺,一个固定的时间周期（通常为2w-4w）,团队要尽可能在这个周期内交付可以工作的软件给客户
sprint planning meeting:冲刺开始的时候，PO会和团队一起从PB中选择本次要做的任务/故事，并且会对团队提出的疑问进行解释和澄清。同时团队会估算故事并分解成任务，最后会形成本次的Sprint Backlog.
daily standupo meeting:每日站会，scrum为了加强团队沟通，每天团队都要选择一个时间站在一起，互相交流彼此的进展和问题,以便及时解决出现的问题，同时也能让团队随时了解我们离冲刺目标还有多远。
sprint review:在sprint周期最后，需要进行一次评审会议，让团队向产品负责人和利益相关者展示已完成的功能。sprint审核的大部分实践用于团队成员展示功能、回答利益相关者对展示的疑问并记录所期望的更改。评审会议可以吸引相关利益者的关注，让其他人了解团队在做些什么，并得到重要反馈。做演示也会迫使开发团队真正完成一些工作。
retrospective meeting:回顾会议，通常在reivew会议之后开始，有团队成员在冲刺结束之后对上个迭代进行总结，同时提出一些改进方案，这是一个持续改进的过程。
SCRUM的其他一些要素：
user story:用户故事，因为敏捷要求每个特性都是对客户有价值的，所以以用户故事的方式来设计特性，通常是作为客户，我要实现A功能，以至于我可以达到什么目的的结构。
task:每个迭代中为了开发一个user story,将其分解为一些task,比如说我要开发一个协议，其中需要几个task,包括搭建服务器，找一些开源代码，搭建自动化测试框架，编码，测试任务，便于更小粒度的track每个迭代的进展。
release planning:在某些大型组织，可能更关注release级别的产品交付，所以每个release之前要进行整个release的plan,决定这个release的PB。
points:故事点数，代表用户故事的大小，要记住，这里的大小不代表开发时间，只是一个相对的用户故事的复杂度，工作量大小。因为很难理解，所以scrum team要建立一个基准的user story，作为一个points，然后其他的user story和它进行相对比较。这个points大部分时间用来作为评估team的交付能力。
SCRUM开发流程：
Scrum 是一个用于开发和维持复杂产品的框架 ，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周(互联网产 品研发可以使用1周的Sprint)。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求 。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将递交 潜在可交付的产品增量。
SCRUM各个角色之间的关系和作用：
PO和team的关系：一个人拿到了客户的一个项目，开发一个产品，他就是ＰＯ，他想找一个团队开做这个产品，但是现在有Ａ团队和Ｂ团队，Ａ团队跟PO说，ok,交给我吧，3个月后你过来，我们把产品给你.而B团队说，我们每个月都可以让你看一下我们的产品，但是可能一开始功能不完善，但是可以工作的，然后你可以把我们的产品给客户看，如果运气好的话客户可能先给你点钱呢。
如果你作为PO，你会选择哪个团队呢？对了，A就是传统的开发团队，而B则是我们的scrum team.
scrum master和team还有PO的关系：
个人给SM有以下几个定义：
Team Coach: 不仅在在流程上辅导团队，还要帮助大家接受敏捷开发理念，推动团队按照敏捷价值观和原则所倡导的方法来做出决策。
Servant Leader：Scrum Master服务于团队，帮助团队解决工作中的困难，引导团队自组织的高效完成每日工作，但是并不是团队的管理者。
Team Protector: 作为团队保护者，SM7要敢于说不，尽量保证团队在每个冲刺中不被打扰，如果发现有影响团队工作的临时任务，一定要站出来保护团队。
SCRUM大事表：
Jeff Sutherland在 1993年首次在Easel公司定义了用于了软件开发行业的Scrum流程，并开始实施
1995年Jeff Sutherland和Ken Schwaber规范化了Scrum框架，并在OOPSLA 95上公开发布。
2001年 敏捷宣言及原则发布、敏捷联盟成立，Scrum是其中一种敏捷方法。
2001年，Ken Schwaber和Mike Beedle推出第一本Scrum书籍《Scrum敏捷软件开发》。
2002年Ken Schwaber 和Mike Cohn共同创办了Scrum联盟。