Scrum是一种灵活的敏捷软件开发管理过程。这个名词来源于英式橄榄球。Scrum方法由Ken Schwaber和 Jeff Sutherland 提出，它将软件开发团队比作橄榄球队，全队有明确的最高目标：发布产品的重要性高于一切。团队高度自治，队员们熟悉开发过程中涉及到的各种技术，紧密合作，确保每个迭代都朝着最高目标推进。而且每隔2至6周，每个人都能看到能实际工作的软件，并且据此决定是发布这个版本还是继续开发以加强它的功能。

       对于功能需求可能经常发生变化的项目来说，Scrum是它们最为理想的选择之一。在一个采用Scrum的项目中，首先要将所有需要完成的工作列在一个产品待开发项(Product Backlog)中，项目开发过程中需求的改变也要写进去。在每个迭代(Sprint)开始之前，要开一个迭代计划会议(Sprint Planning Meetting)。在会上，产品责任人(Product Owner)为 Product Backlog中的各功能需求确定优先级(或者是在会前完成)，随后Scrum开发团队按照优先级，从Product Backlog中挑选出他们认为能在本次迭代中完成的任务，把它们从Product Backlog中挪到Sprint Backlog中来。在Sprint进行过程中，Scrum团队每一天都要举行一个简短的每日立会(Daily Stand-up Meeting)，以便团队成员了解开发进度。Sprint结束之后，需要开评审会(Review Meeting)和反思会(Restrospective Meeting)。开发团队在评审会上把这个Sprint的开发成果展示给大家看；而在反思会上，团队成员们会回顾过去的这个Sprint，从中总结经验和教训。

       那么什么是Product Backlog？什么是Sprint Backlog？

       产品待开发项(Product Backlog)：根据初始需求分解出的任务列表，包括功能性的和非功能性的所有功能； 由Product Owner为Product Backlog中的任务确定优先级别；当开发团队开始做某个任务的时候，再精确定义和分解这个任务。

       Product Backlog是产品所要具备的所有功能的总纲。当一个项目刚刚开始时，没人能够事先预见到所有的任务和需求，并为之做一个充分、详细而又包罗万象的计划。可行的方式是，先为一个项目写下所有它应该具备的显著特征和功能，数量不必很多，最好够让团队的第一个Sprint有活可干。随着Sprint的进行，生产出可发布的产品增量，客户对产品的直观认识也随之加深，他们可以据此建议更改或者添加产品Backlog中的任务。

       在Sprint计划会议上，产品负责人人为产品Backlog中的任务确定优先级，并向Scrum团队描述这些任务。Scrum团队随后根据团队整体情况，确定他们能在这个即将到来的Sprint中完成哪些功能，并把它们挪到Sprint Backlog中去。

       迭代计划会(Sprint Planning Meeting) ：在每个Sprint开始之前，需要召开Sprint计划会议，一般为4至8个小时。参加人员有产品责任人、Scrum Master、Scrum团队和其他感兴趣的人，比如管理层人员和客户代表。Product Owner从产品Backlog中挑选优先度高的任务，并与Scrum团队一起决定在这个Sprint中需要完成多少功能；Scrum团队将这些任务分解成小的功能模块； Scrum团队成员详细讨论如何能按需求完成这些功能模块，并估计完成每个功能模块所需的大概时间。

       每日立会(Daily Stand-up Meeting)：既团队每日例会，条件允许的话，每天都应该在同样的时间和地点，所有成员站立着举行。由于是站立的状态开会，因此时间比较短，一般为15分钟左右。这个会议最好是在每天的早晨开，有利于团队成员们安排好当天的工作计划。只有团队成员可以在每日Scrum会议上发言，其他人员如果对项目进度有兴趣也可以参加，但只能旁听而不能发言。

       会议由Scrum Master主持，Scrum团队的所有成员轮流回答上图中的三个问题，即：

1. 1. 昨天我完成了什么工作；
   2. 今天我打算做什么；
   3. 我遇到了什么障碍。

      通过这三个问题，团队成员之间可以彼此相互熟悉工作内容，充分了解项目进度，相互帮助解决问题。Scrum Master除了倾听团队成员的发言外，他还有责任设法解决团队成员在会上提出的困难，尽快扫除阻碍他们工作的障碍。即使有的问题Scrum Master没有能力解决，例如某些技术细节问题等，他也应该找到团队中或其他团队的来帮助快速的解决问题。另外，还有两点需要注意的地方：其一，这是团队成员之间的交流，也是相互的承诺，并不是用来向老板汇报工作进度的；其二，这也不是一个专门用于解决各种问题的会议，成员们遇到的问题可以在会上提出来，而有能力解决这些问题的人可以在会后帮助他们解决问题。

       Sprint评审会(Review Meeting)：Sprint结束时召开；由开发团队展示这个Sprint中完成的功能；长度为两个小时左右；不需要PPT；一般是已完成的功能的Demo； 谁都可以参加：客户、管理层、Product Owner、其他开发人员等等。
       在每个Sprint结束时，应该组织一个Sprint评审会议。Scrum开发团队将在会上展示他们在这个Sprint中所做的工作。一般采用向大家演示产品新功能的方式来展示。
       相对来说，Sprint评审会议不必很正式。通常不需要用到PPT幻灯片，而且长度最好控制在两个小时之内。也就是说，不要让Sprint评审会议成为Scrum团队的负担，他们不必花太多时间来准备这个会议。
       Sprint评审会议的参与者，可以包括所有对该产品感兴趣的人：产品责任人，Scrum团队，利益相关者，管理层人员，客户，甚至来自其他项目的开发人员等等。

       在Sprint评审会议上，Scrum团队用Demo的形式展示产品的新功能之后，与会人员依据在Sprint计划会议上确定的本Sprint的目标来评审具备了这些新功能的产品。

       为什么一定要用Demo的形式来展示产品的新功能呢？因为这种方式有很多好处：
       首先，参与会议的人都能直观的看到Scrum团队的工作成果；其次，利益相关者们可以据此提出更切合实际的反馈意见；第三，为了完成Demo，团队会努力完成并发布那些功能，即使只是发布在测试环境下，也比没完成的好。如果不做Demo，也许不少功能会停留在“已完成99%”的阶段。相比较起来，在有Demo的情况下，也许“已完成”的功能数量会相对少一些，但它们是确确实实完成了的，否则，那些“99%”的貌似完成的功能势必还要拖到下个Sprint来解决。
       假如有一个刚从传统的开发模式转而采用Scrum的团队，由于不习惯这种自我约束、自组织的方式，在Sprint中并没做多少工作，那么在会上演示的时候，他们会觉得很尴尬。没准老板看到他们花了这么多时间只做了这么少的工作而感到很生气。发生这种情况当然是大家都不想看到的，但良药苦口，在下一个Sprint中，这个团队肯定会吸取教训，他们会明白无论什么情况下都必须Demo，那么他们必然会很好的完成这个Sprint并演示给大家看。