Scrum是迭代式增量软件开发过程，通常用于敏捷软件开发
用7句话概括一下：[出自《知行合一：实现价值驱动的敏捷和精益开发》一书]
- 产品经理(Product Owner)负责建立并维护一个按优先级次序排列的、反映客户期望的产品需求列表(Product backlog)
- 在迭代(sprint)计划时，团队从需求列表中优先级高的需求项中选取一小部分，放入迭代需求列表(sprint backlog)中，并决定如何开发这些需求功能
- 团队在固定的时间周期内完成一个迭代，通常是2-4周，团队每天会在一起评估项目进展情况(daily scrum)
- 在这个过程中，Scrum过程经理(Scrum Master)会让团队关注迭代目标的实现并遵循Scrum实践
- 在每次迭代结束时，团队完成的代码是可以提交的：可以直接让客户使用，或者可以展示给客户或用户代表
- 迭代的最后两个活动是迭代评审(sprint review)和迭代回顾(sprint retrospective)，根据反馈，对产品及团队工作方式(过程)做优化调整
- 在下个迭代开始时，Scrum团队(Scrum team)又会从产品需求列表中选取一部分优先级高的需求项，开始新一轮的开发工作
有人把Scrum简单解释为3个角色，3个文档和5个会议：
Scrum管理框架中的3个角色是产品经理，Scrum Master(Scrum 过程经理)和Scrum团队(Scrum team)
产品经理最主要的责任是保证团队开发的功能特性对客户是有价值的，具体来说，他需要做以下5件事：
- 建立产品的愿景，也就是产品给客户带来的价值
- 建立维护产品的发布计划/版本计划(release plan)
- 及时收集用户反馈、优化产品需求
- 确定每条需求项（User Story）的价值及优先级
- 明确每个需求项的验收通过标准
Scrum Master比较特殊，在传统方法中是没有这个角色的，所以这个是经常被误解的角色。一个称职的SM(过程经理)能在3个方面起到重要作用：
- 让团队关注点始终在实现客户价值上；
- 让团队在每个迭代中不受干扰（大家都知道封闭式开发能保证效率，Scrum的每一次迭代就是不需要团队成员住酒店的封闭式开发）；
- 帮助产品经理和团队在Scrum的框架下做好各自的工作，并做到有效的沟通。
SM[Scrum Master]为了实现上面3个目标，SM需求做好以下一些工作：
- 建立、改进适用于团队的Scrum过程
- 推动敏捷实践及有效开发实践在开发中的有效应用
- 推动团队问题障碍的解决
- 帮助培养团队的自我管理开成良好的团队文化
- 协调各方的沟通
SM不是真正意义上的经理，不是传统的项目经理，他和团队成员之间不是管理与被管理的关系。SM更像是团队的过程教练。
我个人作为SM时，实际需要做的事：
- 修改各特性小组名称，以作知会
- 信使会之前与相关产品、技术人员确定本迭代的大致需求范围；（产品需求不需要了解太过细节。但技术类的需要仔细与相关人员确认）
- 参加信使会，积极参与讨论，发表自己看法，了解需求背景、目的等信息，记录其他特性小组的需求；（包括父需求、阶段目标等）
- IPM前，提前过一遍下个迭代的用户需求，和产品沟通User Story的可行性和注意点[主要是如何在现有系统的基础上快速实现用户需求，比如哪些是可实现的，哪些是可能需要增加额外工作量的]
- 参加本特性小组IPM时，在开会之前作其他特性小组的关键需求介绍，并回答其他成员的提问
- 迭代中，在晨会、讨论会、工作群中关注迭代进度，及时发现潜在风险（如技术、资源、沟通等问题），尤其是在进度方面的问题。对于能够解决的问题进行跟进或组织讨论
- 在迭代快结束的时候，提醒团队成员及时扭转需求和产品的封版时间
- 迭代封版后，针对规模是3或者某些重点需求，如果尚未流转，则需要跟负责人进行沟通，了解是否能正常流转，并将之反馈在信使群中
- 在迭代结束后，组织迭代评审和迭代回顾
Scrum框架下的最后一个角色是开发团队(Scrum team)，开发团队是Scrum过程的核心。这是个规模小(5-9人)的团队，一般是一个Feature Team，团队应具备的软件开发所需要的所有技能：需求分析、设计、编码、测试、技术资料编写等。它的主要责任是通过迭代，不断开发提交对客户有价值的功能特性，同时持续改进提升团队能力，将其潜能最大化。团队主要工作包括：
- 估计产品需求列表中用户故事的复杂度，考虑用户故事的优先级、依赖关系、实现难度等，选择下个迭代的范围，形成迭代需求列表[这个形成迭代需求列表一般由产品经理来规划，开发只在IPM上估算需求规模工作量]
- 遵循团队达成的工程实践共识，完成每个用户故事的需求澄清、设计、编码、评审、测试、资料编写等相关工作，不断提交对客户有价值的需求功能
- 不断总结开发过程中的得与失，持续改进个人能力及团队能力
Scrum管理框架中的3个文档：
- 产品需求列表，产品需求列表是Scrum中最重要的文档，它是一个动态的，产品经理可以随时对其进行调整的，包含了客户期望的需求列表清单。大部分敏捷团队用“用户故事”的形式来表示每一个需求项，产品经理会对它们按价值高低排序
- 迭代需求列表，是由团队负责管理，它定义了Scrum团队某次迭代承诺实现的用户故事或任务。在迭代中，它一般是不变的，偶尔会在IPM上有所调整，比如视成员数的增减，休假情况来调整
- 燃尽图是Scrum中的第三个文档，它主要是用来监控版本及迭代开发进展情况。版本燃尽图显示本次版本未开发的需求项或剩余的工作，而迭代燃尽图则显示一次迭代中未完成的工作。
燃尽图可以清晰的展示版本实现情况和迭代完成情况
Scrum管理框架中的5个会议：
- 产品需求列表的细化会议：团队和产品经理一起会细化列在需求列表前面的需求项，为近几次的迭代做好准备，这个在我所在团队由产品经理完成
- 迭代计划会议(IPM)：团队从产品需求列表前面被细化的需求项中选择本次迭代要完成的用户故事或任务，形成迭代需求列表，IPM上一般开发团队一起来就用户故事估算故事规模点/工作量
- 每日站会
- 迭代评审会议：showcase 本次迭代中团队完成的需求功能，让产品经理、客户及其他利益相关人加深对产品的理解，调整产品需求列表，逐步识别聚焦到真正对客户有价值的需求特性。
- 迭代回顾会议：会列出本迭代或是近期迭代中团队的well和less well
Scrum中的一个重要时间盒体现在固定的迭代周期(一般2-4周)，固定时长的产品需求列表细化会议(2-4小时)，固定时长的迭代计划会议(半天时长)，固定时长的每日站会(5-10分钟)，固定时长的迭代评审会议(2-4个钟)和固定时长的迭代回顾会议(2-4个钟)。时间盒是使团队专注、发挥潜能，及早发现问题并做出解决决策的有效手段。
以上为Scrum的主要内容，Scrum和XP是常见的敏捷开发方法