Scrum是一种兼顾计划性与灵活性的敏捷开发过程，原词来自于橄榄球中的“带球过人”。在橄榄球比赛的每次冲刺前，都将有一个计划安排的过程，但冲刺开始后则由队员在原计划的基础上随机应变。不同于瀑布模型将开发过程划分为需求、设计、编码、测试等阶段，Scrum将整个开发过程分为多次迭代（称为Sprint，冲刺），一般为期2～4周。
在日常工作时，产品负责人会维护一个按优先级排序的“产品待开发项”（Product Backlog），即从客户价值理解和描述的产品功能条目，通常产品经理承担这一角色。 在每次迭代的第一天，召开Sprint计划会(Sprint Planning Meeting)。产品负责人会逐一挑选最高优先级的部分进行讲解。团队可就需求细节、完成标准等进行询问，并逐条估算，放入本次迭代的开发任务中，直至任务量饱和。一旦迭代开始，这些任务将不会发生大的发化。
在迭代期内，团队将决定任务分配、所需的技术等，逐一完成任务。每天团队会进行一个简短的站立会议即每日站会 Daily Stand-up Meeting，沟通当前进度、下一步任务和当前存在的问题，以借助团队的力量解决。团队还维护一张“燃烧图”（Burn Down Chart），即所有任务的累积剩余时间随开发进程与日递减的图形，以观察和预测所有任务是否会按期完成。
在每个迭代的最后一天，团队会召集评审会(Review Meeting)，邀请产品负责人等参加，对已经完成的产品功能条目进行评审，后者做出判断并给出改进反馈。当天还会召开回顾会 (Retrospective Meeting)，对本次迭代的成功与失败之处做出总结，并在以后迭代中进行改进。
Scrum中的三个角色
产品负责人(Product Owner)
主要由产品经理担任，其为确定产品的方向和愿景，定义产品发布的内容、优先级及交付时间，为产品ROI（profitability of product）负责。主要职责包括：确定产品的功能；决定发布的日期和 发布内容；为产品的ROI负责；根据市场价值确定功能优先级；每个sprint中，根据需要调整功能和优先级（每个sprint开始前调整）；接受或拒绝开发团队的工作成果；参与Scrum Planning Meetings（Sprint计划会议），Sprint Review Meeting（Sprint评审会）和 Sprint Retrospective Meeting（Sprint回顾会）。
Scrum Master
担当团队leader，可以是开发Leader或者Team Leader, 和Product owner紧密合作，及时为团队成员提供帮助。主要职责包括：保证团队资源合理利用；保证各个角色及职责良好协作；解决团队开发中的障碍；作为团队和团队外部的接口，协调解决沟通中的问题；保证开发过程按计划进行，组织Scrum Planning Meetings（Sprint计划会议）, Daily Stand-up Meeting（每日站会）, Sprint Review Meeting（Sprint评审会）和 Sprint Retrospective Meeting（Sprint回顾会） 。
团队（Team）
一般情况人数在5-9人。团队成员包括产品经理、开发人员、测试人员、前端开发、UED等。团队成员最好都是在项目的一个sprint中是全职的， 在一个Sprint中成员不容许更换。在项目范围内有权利做任何事情已确保达到sprint的目标；向Product owner演示产品功能。
Scrum的四个会议
Sprint计划会议
在每个Sprint之初，由产品负责人讲解需求，并由开发团队进行估算的计划会议。 在会议上需要： 排列需求优先级；分析和评估产品Backlog并确定Sprint目标；计划会议上还需要制定Sprint计划，包括： 根据产品Backlog（User story或功能点）创建Sprint Backlog（即任务）；然后为Sprint backlog中的任务做估算，以小时计算；团队成员从产品Backlog中挑选他们承诺完成的条目。
每日站会（Daily Stand-up Meeting）
团队每天进行沟通的内部短会，因一般只有15分钟且站立进行而得名，Team成员通常会在会议上讲述如下3点内容：
1) 昨天我做了什么
2) 今天我计划要做什么
3) 我遇到了什么问题，妨碍了我尽可能有效地工作
ScrumMaster记录会议上提出的问题，但是不要在会议上讨论和解决问题，而是要会后在找相关人员进行讨论和解决。
Sprint评审会议
在Sprint结束前给产品负责人及客户演示并接受评价的会议。
Sprint回顾会议
在Sprint结束后召开的关于自我持续改进的会议,围绕如下三个问题进行讨论：
1) 本次迭代有哪些做得好
2) 本次迭代我们在哪些方面还能做得更好
3) 我们在下次迭代准备在哪些方面改进
团队确定问题优先级，并根据优先级确定Team能够解决的Top问题；团队讨论Top问题的措施，并选择在下一个迭代可以完成措施，分配责任人进行跟踪
Scrum的三个关键WorkItem
产品Backlog
产品Backlog是从客户价值角度理解的产品功能列表。
1) 功能、缺陷、增强等都可以是待开发项。
2) 一般以条目化的方式描述。
3) 客户和用户必须能够理览。
4) 描述怎样使用而非怎样制造。
5) 整体上从客户价值优先级排序。
6) 总工作量一般需要0.5～10人天。
7) 高优先级的条目应有较详尽的描述，低优先级的条目可只有一个名称。
冲刺（Sprint）Backlog
Sprint Backlog是从开发技术角度理解的迭代开发仸务。在简单的纯软件环境，可以直接把产品Backlog当作冲刺待开发项分配到迭代中。在复杂的开发环境中，可以把一个产品Backlog分览为Web/后台……软件/硬件……程序/美工……等开发任务。
燃尽图（Burndown Chart）
图形化的方式展现了剩余的工作量（y轴）与时间（x轴）的关系。剩下的工作量应该有节奏的增加或减少，并最终显现下降的趋势。
个人感觉要是真的敏捷起来的话是非常有好处的，这对于产品经理来说也是一个考验，需要将所有业务需求清单梳理清楚，排定优先级，预估工作量，迭代验证，之前也在创意马拉松ideathon2012上看到过国外的敏捷团队如何做汽车，真正的产品敏捷确实效果非常好，不过国外的模式是否适合国内的产品研发环境，是否应该照搬，还是应该有自己特色的敏捷，需要根据实际情况来衡量，为了敏捷而敏捷反而会打乱整个产品流程，工具或者方法都得找到适合成长的土壤才能生根发芽，想要敏捷起来，首先得让整个产品团队都有敏捷的意识，否则就容易形式主义。个人观点仅供参考，结合之前的《敏捷开发培训分享》，相信大家能对敏捷有一个初步的了解了。感觉有点像先进的SAP ERP系统，却不是每个国内企业都能用起来的。
