[转]scrum简介
Scrum是一种灵活的敏捷软件开发管理过程。这个名词来源于英式橄榄球。Scrum方法由Ken Schwaber和 Jeff Sutherland 提出，它将软件开发团队比作橄榄球队，全队有明确的最高目标：发布产品的重要性高于一切。团队高度自治，队员们熟悉开发过程中涉及到的各种技术，紧密合作，确保每个迭代都朝着最高目标推进。而且每隔2至4周，每个人都能看到能实际工作的软件，并且据此决定是发布这个版本还是继续开发以加强它的功能。
对于那些功能需求可能经常发生变化的项目来说，Scrum是它们最为理想的选择之一。在一个采用Scrum的项目中，首先要将所有需要完成的工作列在一个 Product Backlog中，项目开发过程中需求的改变也要写进去。在每个Sprint开始之前，要开一个Sprint计划会议，在会上，产品责任人Product Owner为 Product Backlog中的各功能需求确定优先级，随后Scrum开发团队按照优先级，从Product Backlog中挑选出他们认为能在这个Sprint中完成的任务，把它们从Product Backlog中挪到Sprint Backlog中来。在Sprint进行过程中，Scrum团队每一天都要举行一个简短的每日Scrum会议，以便团队成员了解开发进度。Sprint结束之后，需要开Sprint评审会议和Sprint回顾会议，开发团队在Sprint评审会议上把这个Sprint的开发成果展示给大家看；而在Sprint 回顾会议上，团队成员们会回顾过去的这个Sprint，从中总结经验和教训。
什么是产品backlog？什么是Sprint backlog？
产品Backlog：根据初始需求分解出的任务列表，包括功能性的和非功能性的所有功能；由Product Owner为Product Backlog中的任务确定优先级别；当开发团队开始做某个任务的时候，再精确定义和分解这个任务。
产品Backlog是产品所要具备的所有功能的总纲。当一个项目刚刚开始时，没人能够事先预见到所有的任务和需求，并为之做一个充分、详细而又包罗万象的计划。可行的方式是，先为一个项目写下所有它应该具备的显著特征和功能，数量不必很多，最好够让团队的第一个Sprint有活可干。随着Sprint的进行，生产出可发布的产品增量，客户对产品的直观认识也随之加深，他们可以据此建议更改或者添加产品Backlog中的任务。
在Sprint计划会议上，产品负责人人为产品Backlog中的任务确定优先级，并向Scrum团队描述这些任务。Scrum团队随后根据团队整体情况，确定他们能在这个即将到来的Sprint中完成哪些功能，并把它们挪到Sprint Backlog中去。
Sprint计划(Sprint Planning)-在每个Sprint开始之前，需要召开Sprint计划会议，一般为4至8个小时。参加人员有产品责任人、Scrum Master、Scrum团队和其他感兴趣的人，比如管理层人员和客户代表。Product Owner从产品Backlog中挑选优先度高的任务，并与Scrum团队一起决定在这个Sprint中需要完成多少功能；Scrum团队将这些任务分解成小的功能模块； Scrum团队成员详细讨论如何能按需求完成这些功能模块，并估计完成每个功能模块所需的大概时间。
每日Scrum会议（Daily Scrum）既团队每日例会，条件允许的话，每天都应该在同样的时间和地点，所有成员站立着举行。由于是站立的状态开会，因此时间比较短，一般为15分钟左右。这个会议最好是在每天的早晨开，有利于团队成员们安排好当天的工作计划。只有团队成员可以在每日Scrum会议上发言，其他人员如果对项目进度有兴趣也可以参加，但只能旁听而不能发言。
会议由Scrum Master主持，Scrum团队的所有成员轮流回答上图中的三个问题，即：
1，昨天我完成了什么工作；
2，今天我打算做什么；
3，我遇到了什么障碍。
通过每日Scrum会议，团队成员之间可以彼此相互熟悉工作内容，充分了解项目进度，相互帮助解决问题。Scrum Master除了倾听团队成员的发言外，他还有责任设法解决团队成员在会上提出的困难，尽快扫除阻碍他们工作的障碍。即使有的问题Scrum Master没有能力解决，例如某些技术细节问题等，他也应该找到团队中或其他团队的来帮助快速的解决问题。另外，还有两点需要注意的地方：其一，这是团队成员之间的交流，也是相互的承诺，并不是用来向老板汇报工作进度的；其二，这也不是一个专门用于解决各种问题的会议，成员们遇到的问题可以在会上提出来，而有能力解决这些问题的人可以在会后帮助他们解决问题。
Burndown Chart的横轴表示整个Sprint的总时间，纵轴表示Sprint中所有的任务，其单位可以是小时，人天等。一般来说，Burndown chat有Sprint Burndown chat和Release Burndown chat之分。
Sprint Burndown Chart可以体现Sprint的进度，如果图中的曲线一直是上升状态，或当Sprint进行一段时间之后，曲线上当前点的Y值仍然与Sprint刚开始时相差无几，那么说明这个Sprint中的Story过多，要拿掉一些Story以保证这个Sprint能顺利完成。如果曲线下降得很快，例如Sprint刚过半时，Y值已经接近0了，则说明为这个Sprint分配的任务太少，还要多加一些任务进来。在Sprint计划会议上，大家对即将要做的任务理解和认识不充分，很可能导致这两种情况的出现。
Release Burndown Chart
Release Burndown Chart用于记录整个Scrum项目的进度。它的横轴是这个项目的所有Sprint，纵轴是在各个Sprint开始前，所有尚未完成的工作，它的单位可以是Story数量，人天等等
Sprint评审会议：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并演示给大家看。
Scrum中有三种角色：产品负责人，Scrum Master和Scrum团队，他们的职责分别是：
1. 产品负责人(Product Owner)
确定产品的功能和完成时间；
来源：(http://blog.sina.com.cn/s/blog_4d8498800100iejs.html) - [转]scrum简介_紫榭蔷薇_新浪博客
对产品的收益负责；
根据市场需求确定产品功能的优先级；
在每个Sprint开始之前，可以修改功能需求和优先级；
有权决定接受或否决各Sprint的工作成果。
Product Owner的角色通常由市场部门的人员或开发部门内部主要使用该产品的人来担任，他的主要工作是根据市场需求，确定产品的功能，列入Product Backlog中，并为这些功能确定优先级别。
Scrum团队按照功能的优先级，将它们从高到低分配到各个Sprint中进行开发，这些被分配到一个Sprint中完成的功能就形成了Sprint Backlog。
在产品的整个开发过程中，Product Owner对于产品的需求可能会发生改变。他可以修改Product Backlog，增加某些功能需求、删除某些功能需求、修改优先级等等，但这些行为只能在各个Sprint之间进行。
2. Scrum Master
负责监督整个Scrum项目进程，调整项目计划
确保开发团队成员的能力能够胜任产品的开发；
促进团队中不同角色的成员间充分交流和沟通，并负责为项目的进行扫除障碍；
保证开发团队不受外力的干扰和阻挠；
掌握产品开发进度，参与每日Scrum会议、Sprint计划会议和Sprint评审会议。
Scrum Master最经常的情况就是由过去的项目组长(Team leader)来担当。
3. 开发团队
一般由5-10个能全职工作的成员组成较为理想；团队成员横跨各个职能，通常包含开发，测试，文档设计人员等等。
User Story
Sprint Backlog里的项目我们通常用User Story来描述，User Story，是从用户的角度，对系统的某个功能模块所做的简短描述。一个User Story描述了项目中一个小功能，以及这个功能完成之后，将会产生什么效果，或者说能为客户创造什么价值。
User Story要由Stakeholder来写。User Story的形式很简单，人们可以很容易就掌握写User Story的方式，这样可以保证让项目相关的领域专家们来写User Story，而不是开发人员。
通常把User Story写在一张小卡片上，同时在卡片上标明它的优先级和预计完成时间，以便于开发人员根据任务的优先级来制定Sprint Backlog。而且Stakeholder可以随时更改一个Story的优先级，那么开发人员就应该相应地调整Story的开发次序。
一个User Story的大小和复杂度应该以能在一个Sprint中开发完毕为宜。如果User Story太大，可能会导致对它的开发横跨几个Sprint，这种情况是应该避免的，此时就应该将这个User Story分解。
User Story有一个通用的格式公式，大家可以套用一下试试，很简单：
作为<某个角色>，我可以<做什么>，以完成<什么目的>。
例如：作为一个病人，我可以预约一个医生，让他给我看病。
这种表达方式清晰明了，提供了足够的信息以供测试。更详细的实现细节会在要完成这个User Story的Sprint开始之前确定下来并补充到Sprint Backlog中去。这是一种把客户需求分解为可测试的且有优先级的任务的有效方式。
为了能及时高效的完成每个Story，Scrum团队会把每个Story分解成若干个Task，每个Task都可以在明确的时间内完成的，而且这个时间是以小时为单位的，特别提示：每个Task的时间最好不要超过8小时，就是要保证在一个工作日里完成，如果你做计划时发现有些Task的时间超过了8小时，就说明Task划分有问题，需要你特别注意了
对于那些功能需求可能经常发生变化的项目来说，Scrum是它们最为理想的选择之一。在一个采用Scrum的项目中，首先要将所有需要完成的工作列在一个 Product Backlog中，项目开发过程中需求的改变也要写进去。在每个Sprint开始之前，要开一个Sprint计划会议，在会上，产品责任人Product Owner为 Product Backlog中的各功能需求确定优先级，随后Scrum开发团队按照优先级，从Product Backlog中挑选出他们认为能在这个Sprint中完成的任务，把它们从Product Backlog中挪到Sprint Backlog中来。在Sprint进行过程中，Scrum团队每一天都要举行一个简短的每日Scrum会议，以便团队成员了解开发进度。Sprint结束之后，需要开Sprint评审会议和Sprint回顾会议，开发团队在Sprint评审会议上把这个Sprint的开发成果展示给大家看；而在Sprint 回顾会议上，团队成员们会回顾过去的这个Sprint，从中总结经验和教训。
什么是产品backlog？什么是Sprint backlog？
产品Backlog：根据初始需求分解出的任务列表，包括功能性的和非功能性的所有功能；由Product Owner为Product Backlog中的任务确定优先级别；当开发团队开始做某个任务的时候，再精确定义和分解这个任务。
产品Backlog是产品所要具备的所有功能的总纲。当一个项目刚刚开始时，没人能够事先预见到所有的任务和需求，并为之做一个充分、详细而又包罗万象的计划。可行的方式是，先为一个项目写下所有它应该具备的显著特征和功能，数量不必很多，最好够让团队的第一个Sprint有活可干。随着Sprint的进行，生产出可发布的产品增量，客户对产品的直观认识也随之加深，他们可以据此建议更改或者添加产品Backlog中的任务。
在Sprint计划会议上，产品负责人人为产品Backlog中的任务确定优先级，并向Scrum团队描述这些任务。Scrum团队随后根据团队整体情况，确定他们能在这个即将到来的Sprint中完成哪些功能，并把它们挪到Sprint Backlog中去。
Sprint计划(Sprint Planning)-在每个Sprint开始之前，需要召开Sprint计划会议，一般为4至8个小时。参加人员有产品责任人、Scrum Master、Scrum团队和其他感兴趣的人，比如管理层人员和客户代表。Product Owner从产品Backlog中挑选优先度高的任务，并与Scrum团队一起决定在这个Sprint中需要完成多少功能；Scrum团队将这些任务分解成小的功能模块； Scrum团队成员详细讨论如何能按需求完成这些功能模块，并估计完成每个功能模块所需的大概时间。
每日Scrum会议（Daily Scrum）既团队每日例会，条件允许的话，每天都应该在同样的时间和地点，所有成员站立着举行。由于是站立的状态开会，因此时间比较短，一般为15分钟左右。这个会议最好是在每天的早晨开，有利于团队成员们安排好当天的工作计划。只有团队成员可以在每日Scrum会议上发言，其他人员如果对项目进度有兴趣也可以参加，但只能旁听而不能发言。
会议由Scrum Master主持，Scrum团队的所有成员轮流回答上图中的三个问题，即：
1，昨天我完成了什么工作；
2，今天我打算做什么；
3，我遇到了什么障碍。
通过每日Scrum会议，团队成员之间可以彼此相互熟悉工作内容，充分了解项目进度，相互帮助解决问题。Scrum Master除了倾听团队成员的发言外，他还有责任设法解决团队成员在会上提出的困难，尽快扫除阻碍他们工作的障碍。即使有的问题Scrum Master没有能力解决，例如某些技术细节问题等，他也应该找到团队中或其他团队的来帮助快速的解决问题。另外，还有两点需要注意的地方：其一，这是团队成员之间的交流，也是相互的承诺，并不是用来向老板汇报工作进度的；其二，这也不是一个专门用于解决各种问题的会议，成员们遇到的问题可以在会上提出来，而有能力解决这些问题的人可以在会后帮助他们解决问题。
Burndown Chart的横轴表示整个Sprint的总时间，纵轴表示Sprint中所有的任务，其单位可以是小时，人天等。一般来说，Burndown chat有Sprint Burndown chat和Release Burndown chat之分。
Sprint Burndown Chart可以体现Sprint的进度，如果图中的曲线一直是上升状态，或当Sprint进行一段时间之后，曲线上当前点的Y值仍然与Sprint刚开始时相差无几，那么说明这个Sprint中的Story过多，要拿掉一些Story以保证这个Sprint能顺利完成。如果曲线下降得很快，例如Sprint刚过半时，Y值已经接近0了，则说明为这个Sprint分配的任务太少，还要多加一些任务进来。在Sprint计划会议上，大家对即将要做的任务理解和认识不充分，很可能导致这两种情况的出现。
Release Burndown Chart
Release Burndown Chart用于记录整个Scrum项目的进度。它的横轴是这个项目的所有Sprint，纵轴是在各个Sprint开始前，所有尚未完成的工作，它的单位可以是Story数量，人天等等
Sprint评审会议：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并演示给大家看。
Scrum中有三种角色：产品负责人，Scrum Master和Scrum团队，他们的职责分别是：
1. 产品负责人(Product Owner)
确定产品的功能和完成时间；
来源：(http://blog.sina.com.cn/s/blog_4d8498800100iejs.html) - [转]scrum简介_紫榭蔷薇_新浪博客
对产品的收益负责；
根据市场需求确定产品功能的优先级；
在每个Sprint开始之前，可以修改功能需求和优先级；
有权决定接受或否决各Sprint的工作成果。
Product Owner的角色通常由市场部门的人员或开发部门内部主要使用该产品的人来担任，他的主要工作是根据市场需求，确定产品的功能，列入Product Backlog中，并为这些功能确定优先级别。
Scrum团队按照功能的优先级，将它们从高到低分配到各个Sprint中进行开发，这些被分配到一个Sprint中完成的功能就形成了Sprint Backlog。
在产品的整个开发过程中，Product Owner对于产品的需求可能会发生改变。他可以修改Product Backlog，增加某些功能需求、删除某些功能需求、修改优先级等等，但这些行为只能在各个Sprint之间进行。
2. Scrum Master
负责监督整个Scrum项目进程，调整项目计划
确保开发团队成员的能力能够胜任产品的开发；
促进团队中不同角色的成员间充分交流和沟通，并负责为项目的进行扫除障碍；
保证开发团队不受外力的干扰和阻挠；
掌握产品开发进度，参与每日Scrum会议、Sprint计划会议和Sprint评审会议。
Scrum Master最经常的情况就是由过去的项目组长(Team leader)来担当。
3. 开发团队
一般由5-10个能全职工作的成员组成较为理想；团队成员横跨各个职能，通常包含开发，测试，文档设计人员等等。
User Story
Sprint Backlog里的项目我们通常用User Story来描述，User Story，是从用户的角度，对系统的某个功能模块所做的简短描述。一个User Story描述了项目中一个小功能，以及这个功能完成之后，将会产生什么效果，或者说能为客户创造什么价值。
User Story要由Stakeholder来写。User Story的形式很简单，人们可以很容易就掌握写User Story的方式，这样可以保证让项目相关的领域专家们来写User Story，而不是开发人员。
通常把User Story写在一张小卡片上，同时在卡片上标明它的优先级和预计完成时间，以便于开发人员根据任务的优先级来制定Sprint Backlog。而且Stakeholder可以随时更改一个Story的优先级，那么开发人员就应该相应地调整Story的开发次序。
一个User Story的大小和复杂度应该以能在一个Sprint中开发完毕为宜。如果User Story太大，可能会导致对它的开发横跨几个Sprint，这种情况是应该避免的，此时就应该将这个User Story分解。
User Story有一个通用的格式公式，大家可以套用一下试试，很简单：
作为<某个角色>，我可以<做什么>，以完成<什么目的>。
例如：作为一个病人，我可以预约一个医生，让他给我看病。
这种表达方式清晰明了，提供了足够的信息以供测试。更详细的实现细节会在要完成这个User Story的Sprint开始之前确定下来并补充到Sprint Backlog中去。这是一种把客户需求分解为可测试的且有优先级的任务的有效方式。
为了能及时高效的完成每个Story，Scrum团队会把每个Story分解成若干个Task，每个Task都可以在明确的时间内完成的，而且这个时间是以小时为单位的，特别提示：每个Task的时间最好不要超过8小时，就是要保证在一个工作日里完成，如果你做计划时发现有些Task的时间超过了8小时，就说明Task划分有问题，需要你特别注意了