目录
敏捷开发Scrum方法的简介
Scrum是迭代式增量软件开发过程，是敏捷方法论中的重要框架之一，通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架，是一种流程、计划、模式，用于有效率地开发软件。
Scrum 是当前最流行的敏捷软件开发方法论和实施框架。Scrum 是一种团队管理工作的方式，其将工作分解为较小的工作单元，并在周期性固定的时间段内持续地交付工作单元。
名词解释 |
周期性固定的时间段：称为迭代(Iteration)或者冲刺(Sprint)。 较小的工作单元：称为用户故事(us)。用户故事可以使用特定的格式来描述，其描述了一个对于客户有价值的工作，而且可以在一个迭代周期内完成。 |
Scrum的一个关键原则是承认客户可以在项目过程中改变主意，变更他们的需求，而预测式和计划式的方法并不能轻易地解决这种不可预见的需求变化。同样，Scrum采用了经验方法-承认问题无法完全理解或定义，而是关注于如何使得开发团队快速推出和响应不断出现的需求的能力最大化。
Scrum作为一个极佳的敏捷项目开发管理方法，让过程项目管理变得更加有形，而可控软件的自我组织和自我管理工作方式，也能让所有成员积极配合并参与到全过程当中。
虽然Scrum最初只应用于软件开发，它也可以被成功地应用于其他产业。当前Scrum通常被认为是一种用于开发任何产品或管理人和工作的迭代式的，增量的过程。
1、Scrum发展历程
1993年，Sutherland与Easel公司的John Scumniotales和Jeff McKenna一起开发了一套方法，取名为Scrum(来源于橄榄球术语，不是缩写)。
1995年，OOPSLA大会上Sutherland和Schwaber第一次向世人介绍了Scrum。
2001年，Schwaber与Mike Beedle合著了《敏捷软件开发-使用Scrum过程》一书，介绍了Scrum方法。
进入新世纪，互联网带来的巨变使敏捷方法受到了更多开发团队的欢迎，而其中Scrum以其扩展性、门槛低、名字和术语更容易被项目经理接受等因素，逐渐成为最受欢迎的敏捷流派。
2、Scrum敏捷开发流程334
冲刺(Sprint)：可理解为迭代，一个时间周期(通常在2周到1个月之间)，开发团队会在此期间内完成所承诺的一组订单项的开发。
冲刺订单(sprint backlog)
用户故事(user story，us)
产品负责人/产品经理(Product Owner)
敏捷教练(Scrum Master)
开发团队(Scrum Team)
产品订单(product backlog)
产品负责人PO负责整理用户故事us，形成左侧的product backlog。
The Agile：Scrum Framework at a glance Inputs from Executives,Team,Stakeholders,Customers,Users 敏捷：Scrum框架概览 来自高管、团队、利益相关者、客户、用户 |
Scrum Master, Burndown/up Chars, Daily Scrum Meeting 敏捷教练，每日Scrum立会 |
Product Owner, The Team Product Backlog, Sprint Planning Meeting Sprint backlog Sprint end date and team deliverable do not change 产品经理，开发团队 产品订单，冲刺计划会 冲刺订单 冲刺结束日期和团队可交付成果不变 |
Sprint Review Finished Work Sprint Retrospective 冲刺评审 完成的工作 冲刺回顾 |
3角
三个角色 |
具体工作内容 |
产品经理 (Product Owner) |
主要负责确定产品功能和达到要求标准，指定软件的发布日期和交付内容，同时有权力接受或拒绝开发团队的工作成果。 |
敏捷教练 (Scrum Master) |
主要负责保证整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。 |
开发团队 (Scrum Team) |
主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右。 |
3物—文档
文档 |
过程产出文档说明 |
产品订单 |
产品订单(product backlog)是整个项目的概要文档。 产品订单包括所有所需特性的粗略的描述。产品订单是关于将要创建的什么产品。根据初始需求分解出的任务列表，包括功能性和非功能性的所有功能。 |
冲刺订单 |
冲刺订单(sprint backlog)是大大细化了的文档，包含团队如何实现下一个冲刺的需求的信息。 这是一个迭代计划会议的输出，包含开发团队在迭代周期内所要完成的工作列表。 (1)、任务被分解为以小时为单位，没有任务可以超过16个小时。如果一个任务超过16个小时，那么它就应该被进一步分解。 (2)、冲刺订单上的任务不会被分派，而是由团队成员签名认领他们喜爱的任务。 |
燃尽图 |
燃尽图(burn down chart)是一个公开展示的图表，向项目组成员和企业主提供工作进展的一个公共视图。显示当前冲刺中未完成的任务数目，或在冲刺订单上未完成的订单项的数目。在项目完成之前，对需要完成的工作的一种可视化表示。 (1)、燃尽图有一个Y轴(工作)和X轴(时间)。理想情况下，该图表是一个向下的曲线，随着剩余工作的完成，“烧尽”至零。 |
4会—scrum基本流程
四个会议 |
具体内容 |
产品发布计划会议 |
产品负责人负责讲解us，对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog。 |
冲刺计划会 |
Sprint Planning Meeting，在每个冲刺/迭代之初，由产品负责人PO讲解需求(要完成的工作的内容)，并由开发团队进行估算的计划会议。 |
每日立会 |
Daily Standup Meeting，每日站立会议，经常被称为“scrum”，即项目状况会议。团队每天进行沟通的内部短会，因一般只有15分钟且站立进行而得名。 周期：每天，所有出席者都应站立； 会议时间限制：15分钟。 目的：开发团队和产品负责人都要进行一个短暂的沟通。 团队成员，回答昨天做了什么？ 今天计划做什么？ 遇到了什么问题？即完成你的目标是否存在什么障碍，Scrum主管需要记下这些障碍。 |
评审会 |
Review Meeting，在冲刺结束前给产品负责人演示并接受评价的会议。 在迭代周期结束时，开发团队向产品负责人及所有干系人进行演示，并接受反馈。 |
回顾会议 |
Retrospective Meeting，在冲刺结束后召开的关于自我持续改进的会议。 周期：迭代周期结束时，每一个冲刺完成后，都会举行一次冲刺回顾会议； 会议时间限制：4小时； 目的：通过会议来对迭代的过程进行总结，促使团队自我持续改进。提倡所有团队成员坐在一起工作，进行口头交流，以及强调项目有关的规范(disciplines)。 |
3、极限编程(XP)和 Scrum区别
对比指标 |
XP |
Scrum |
迭代长度的不同 |
XP的一个Sprint的迭代长度大致为1~2周 |
Scrum的迭代长度一般为 2~ 4周 |
在一个迭代中—是否允许修改需求 |
在XP在一个迭代中，如果一个us(用户素材, 也就是一个需求)还没有实现， 则可以考虑用另外的需求将其替换， 替换的原则是需求实现的时间量是相等的。 |
Scrum是不允许这样做的，一旦迭代开工会完毕, 任何需求都不允许添加进来，并有Scrum Master严格把关，不允许开发团队受到干扰。 |
迭代中—us是否严格按照优先级别来实现 |
XP是务必要遵守优先级别的。 |
Scrum比较灵活，可以不按照优先级别来做。 (1)、因为如果优先问题的解决者，由于其它事情耽搁，不能认领任务，那么整个进度就耽误了。 (2)、如果按优先级排序的User Story #6和#10，虽然#6优先级高，但是如果#6的实现要依赖于#10，则不得不优先做#10。 |
软件实施过程中—是否采用严格的工程方法—保证进度或者质量 |
XP对整个流程方法定义非常严格，规定需要采用TDD、自动测试、结对编程、简单设计、重构等约束团队的行为。 |
Scrum没有对软件的整个实施过程开出工程实践的处方，要求开发者自觉保证。 |
