一、Scrum的定义和目的
Scrum是一个用于开发和维护复杂产品的框架，是一个增量的、迭代的开发过程，目的是让开发人员像打橄榄球一样迅猛并充满激情，通过团队合作，提高工作效率。通过团队间的有效交互，为企业创造价值。
二、Scrum中的人员角色
Scrum中的人员分为3个角色：产品所有者（Product Owner）, Scrum Master，开发团队(Team)。
产品所有者：定义所有产品功能，决定产品发布的内容以及日期，对产品的投入产出负责，根据市场变化对需要开发的功能排列优先顺序，合理地调整产品功能和迭代顺序，认同或者拒绝迭代的交付。
ScrumMaster ：ScrumMaster不是项目经理，他没有分配任务的权力，没有考核的权力，没有下命令的权力，他指导项目组的成员按照Scrum的原则、方法做事情，领导团队完成Scrum的实践以及体现其价值，排除团队遇到的困难，确保团队胜任其工作，并保持高效的生产率，使得团队紧密合作，使得团队个人具有多方面职能的工作能力，保护团队不受到外来无端影响。
开发团队：经典团队拥有 5-9 人，团队成员包含程序员、测试员、用户体验设计等等，团队关系在一个迭代中应该是固定的，个人的职能可以在新迭代开始时发生调整，团队自我组织和管理（自组织，自驱动），团队成员都全职工作。
三、Scrum的开发流程
不同于瀑布模型将开发过程划分为需求、设计、编码、测试等阶段，Scrum将整个开发过程分为多次迭代（称为Sprint，冲刺），一般为期2～4周，最常见的为2周。Scrum并非以一段时间集中完成一个过程，而是将所有过程中必须的每一部分集中在这段时间内完成。需求、设计、编码、测试、上线都必须在一个迭代中完成，每个迭代必须产生一个可以工作的软件。
1）待办事项整理会议（Backlog Grooming Meeting）
迭代计划会议开始之前3天召开，Product Owner与Scrum Master必须参加，关键开发者或架构师需要参加；时间控制在30分钟到1小时。
由Product Owner将一批希望团队在下次迭代时实现的用户故事，按照实现顺序描述给在场的团队成员，Scrum Master与在场成员分析用户故事，明确指出团队认为需求不明确的地方，Product Owner现场记录，会后补全，Scrum Master与架构师，还有在场成员分析用户故事需要包含哪些技术任务，Scrum Master先把子任务建立，方便迭代计划会议的时候团队可以更准确地预估任务故事点。
会议结束时，Product Owner确保在迭代计划会议开始之前团队提出的问题都能被解决，会议重点如果团队发现需要加强或是完善的地方，Product Owner还有两到三天的时间可以补强，而不是浪费迭代计划会议的时间去做这件事情。
2）迭代计划会议（Sprint Planning Meeting）
产品负责人建立产品功能列表（Product Backlog）。产品功能列表是一组条目化需求，它必须从客户价值角度描述，并按优先级排序。
Scrum Master召集相关人员召开迭代计划会，迭代计划会在每个迭代第一天召开，目的是选择本次迭代的Backlog和估算本次迭代的工作量。
产品负责人逐条讲解最重要的产品功能，开发团队共同估算Backlog所需工作量，直到本迭代工作量达到饱和。产品负责人参与讨论并回答和需求相关的问题，但不干扰估算结果。队员认领任务（或由组长协商分发），独立或与别人一起完成任务；会议时间控制在1-2小时内
3)每日站会：只是一种每天在同一时间和地点举行的超短会议，以保持会议的简单性。许多团队试图在15分钟内完成会议，但这只是一个指导原则。每日Scrum的目标是让团队中的每个成员都保持同步，与Sprint目标保持一致，并为接下来的24小时制订计划。
每日站会让每个团队成员回答如下三个关于实现Sprint目标的问题：
1、我昨天做了什么？
2、我今天计划做什么？
3、有什么问题吗？
站会的目的，每天开会时，不会因为谈话让人分心，这样团队就可以一整天把注意力集中到工作中。
4)Sprint(冲刺):是Scrum团队一起完成增量工作的实际时间段。所有的事件————从计划到回顾————都发生在Sprint阶段。一旦一个Sprint的时长被确定，它就必须在整个开发期间保持一致。这有助于团队从过去的经验中学习，并将这种经验应用到未来的Sprint中。
四、敏捷软件开发方法的十二原则
1.我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
2.欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
3.要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
4.项目过程中，业务人员与开发人员必须在一起工作。
5.要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
6.无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
7.可用的软件是衡量进度的主要指标。
8.敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
9.对技术的精益求精以及对设计的不断完善将提升敏捷性。
10.要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
11.最佳的架构、需求和设计出自于自组织的团队。
12.团队要定期反省如何能够做到更有效，并相应地调整团队的行为。
五、Scrum所需要的工件
1.Scrum任务板
用户可以用Scrum任务板使Sprint任务清单形象化。任务板可以用不同的形式来呈现，比较传统的做法有索引卡、便利贴或白板。Scrum任务板通常分为三列：
待办事项、在办事项和完成事项。团队需要在整个Sprint过程中不断更新。
2.用户故事
用户故事是从用户角度对软件提出功能的描述。它包括用户类型细分，用户想要什么以及为什么需要它。它们遵循相似的结构：“作为<用户类型>，我希望<执行某项任务>以便我能<实现某个目标>"。团队根据这些用户故事进行研发来满足用户需求。好的用户故事应遵循INVEST原则（独立性、可协商性、有价值、可估算性、短小和可测试性）。
3.燃尽图
** 纵轴表示任务总量估计，横轴表示迭代时间**。剩余工作量可以通过不同的点位或其他指标来表示。当事情没有按照计划进行并且影响后续决策时，燃尽图可以在这个时候给团队提个醒。