Scrum 的相关概念
4.1 Scrum 的起源
Scrum 是一种灵活的敏捷软件开发管理过程，这个名词来源于英式橄榄球。Scrum方法由Ken Schwaber和Jeff Sutherland提出，它将软件开发团队比作橄榄球队，全队有明确的最高目标----发布产品的重要性高于一切，团队高度自制，成员们熟悉开发过程中涉及的各种技术，紧密合作，确保每个迭代（Srpint）都朝着最高目标推进。而且每隔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，从中总结经验和教训。
4.2 Scrum 中的角色
Scrum中有3种角色，分别是产品负责人（Product Owner）、Scrum Master 和 Scrum 团队，他们各自的职责如下：
-
产品负责人（Product Owner）
Product Owner 需要确定产品的功能和完成时间，并对产品的收益负责，要根据市场需求确定产品功能的优先级。在每个Sprint开始之前，Product Owner可以修改功能需求和优先级。而且，Product Owner 有权决定接受或否决各个Sprint的工作成果。
Product Owner 的角色通常由市场部门的人员或开发部门门内部主要使用该产品的人员来担任，主要工作是根据市场需求确定产品功能，将其列入Product Backlog中，并为这些功能确定优先级。
Scrum团队按照功能的优先级，将它们从高到低分配到各个Sprint中进行开发，这些被分配到一个Sprint中完成的功能就形成了Sprint Backlog。
在产品的整个开发过程中，Product Owner对于产品的需求可能会发生改变。他可以修改Product Backlog，以及增加某些功能需求、删除某些功能需求、修改优先级等，但这些行为只能在各个Sprint之间进行。
-
Scrum Master
Scrum Master的职责是：负责监督整个Scrum项目进程，调整项目计划；确保开发团队成员的能力能够胜任产品的开发；促进团队中不同角色的成员间充分交流和沟通，并负责为项目的进行扫清障碍；保证开发团队不受外力的干扰和阻扰；掌握产品开发进度，参与每日Scrum会议、Sprint计划会议和 Sprint评审会议。
Scrum Master 通常由传统开发中的Team Leader 来担当。
-
Scrum 团队
一般由5~10个能全职工作的成员组成较为理想。
团队成员横跨各个职能，通常包括开发、测试、文档设计人员等。
4.3 什么是产品Backlog，什么是Sprint Backlog？
产品Backlog指根据初始需求分解出的任务列表，包括功能性和非功能性的所有功能，由Product Owner为Product Backlog中的任务确定优先级别，当开发团队开始某个任务的时候，再精确定义和分解这个任务。
产品Backlog是产品所要具备的所有功能的总纲。当一个项目刚刚开始时，没人能够事先预见到所有的任务和需求，并为之制定一个充分、详细而包罗万象的计划。可行的方式是，先为一个项目写下所有它该具备的显著特性和功能，数量不必很多，做好能保证团队的第一个Sprint有活可干。
随着Sprint的进行，生产出可发布的产品增量，客户对产品的直观认识也会随之加深，他们可以据此建议更改或者添加产品Backlog中的任务。
在Sprint计划会议上，产品负责人为产品Backlog中的任务确定优先级，并向Scrum团队描述这些任务。Scrum团队随后根据团队整体情况，确定他们能在这个即将到来的Sprint中完成哪些功能，并把它们挪到Sprint Backlog中去。
4.4 Scrum中如何实现一个Sprint？
- Scrum计划会议
在每个Sprint开始之前，需要召开Sprint计划会议，会议时间一般为4~8小时，参加人员有产品责任人、Scrum Master、Scrum团队和其他感兴趣的人，比如管理人员和客户代表。
Product Owner从产品Backlog中挑选高优先级的任务，并与Scrum团队一起决定在这个Sprint中需要完成多少功能。Scrum团队将这些任务分解成小的功能模块。Scrum团队成员详细讨论如何能按需求完成这些功能模块，并估计完成每个功能模块所需的大概时间。
- 每日Scrum会议
每日Scrum会议（Daily Scrum），即团队每日例会，条件允许的话，每天都应该在同样的时间和地点，组织所有成员站立举行。由于是以站立的状态开会，因此时间比较短，一般为 15分钟左右。这个会议最好是在每天的清晨开，有利于团队成员安排好当天的工作计划。只有团队成员可以在每日Scrum会议上发言，其他人员如果对项目进度有兴趣也可以参加，但只能旁听而不能发言。
- Scrum评审会议
Sprint评审会议在Sprint结束时召开，由开发团队展示这个Sprint中完成的功能，长度为两个小时左右，不需要PPT，一般是已经完成功能的Demo，而客户、管理层、Product Owner以及其他开发人员等都可以参加。
在Sprint评审会议上，Scrum团队用Demo的形式展示产品的功能之后，与会人员依据在Sprint计划会议上确定的这个Sprint的目标来评审具备了这些新功能的产品。
- Scrum回顾会议
Sprint回顾会议由产品责任人、Scrum团队和Scrum Master参见，会议中需要讨论：有哪些好的建议或方法应该被采纳；在Sprint中有什么做法不可取；有哪些做法效果很好，应该继续下去。
Sprint结束后，Scrum团队回顾刚结束的Sprint，对其进行总结和反思，使整个团队能持续成长。总之，Sprint回顾会议的宗旨就是：Scrum团队如何在下一个Sprint中做得更好！
4.5 Scrum中的User Story
我们通常用User Story来描述Backlog里的各个Backlog项，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小时，就是要保证1个工作日内完成，如果做计划时发现有些Task的时间超过了8小时，就说明Task的划分有问题，需要特别注意。
4.6 Scrum 中Burndown Chart
Burndown Chart 可以体现Sprint的进度。如果Sprint Burndown Chart一直是上升状态，或当Sprint进行一段时间之后，Sprint Burndown Chart上当前点的Y值仍然与Sprint刚开始时相差无几，就说明这个Sprint中的Story过多，要拿掉一些Story以保证这个Sprint 能顺利完成。如果Sprint Burndown Chart下降得很快，例如Sprint刚过半时Y值已经接近零了，则说明为这个Sprint分配的任务太少，还要多加一些任务近来。在Sprint计划会议上，如果团队即将要做的任务理解和认识不充分，就很可能导致这两种情况的出现。
注意：燃烧曲线是衡量团队进度的重要工具。但是不要过分依赖它作为监督和考核的依据，否则就会变味。因为这样会使团队把重点放在生成漂亮的曲线上，而不是项目本身。
4.7 参考资料
电子工业出版社 <<轻松Scrum之旅---敏捷开发故事>>