Scrum

继以前关于Scrum培训的总结之后，有人提出总结不够全面。所以依据自己更深入的了解与实践之后，进行一个更全面的总结。

什么是Scrum？

Scrum是一个敏捷开发框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发周期包括若干个小的跌代周期，每个小的的跌代周期称为一个Sprint，每个Sprint的建议长度2到4周。在Scrum中，使用产品Backlog来管理产品或项目的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum的开发团队总是先开发的是对客户具有较高价值的需求。在每个Sprint中，Scrum开发团队从产品Backlog中挑选最有价值的需求进行开发。Sprint中挑选的需求经过Sprint计划会议上的分析、讨论和估算得到一个Sprint的任务列表，我们称它为Sprint backlog 。  在每个迭代结束时，Scrum团队将交付潜在可交付的产品增量。

一个简单的框架


Scrum由三个角色，六个时间箱，四个工件组成：

三个角色

1. 产品负责人（Product Owner）

2. Scrum Master

3. Scrum团队

六个时间箱

1. Sprint

2. 发布计划会议（Release Planning Meeting）

3. Sprint计划会议（Sprint Planning Meeting）

4. 每日站会（Daily Scrum Meeting）

5. Sprint评审会议（Sprint Review Meeting）

6. Sprint回顾会议（Sprint Retrospective Meeting）

四个工件

1. 产品Backlog（Product Backlog）

2. 发布燃尽图（Release Burndown Chart）

3. SprintBacklog（Sprint Backlog）

4. Sprint燃尽图（Sprint Burndown Chart）

SCRUM理论基础

Agile is NOT a methodology, process or framework. It's a thought to deal with the challenges faced by software developing.

 challenges:

1) unstable requirements

2) uncertainity

3) unacceptable quality

4) demoralized team

To resolve the problems. Agile has the famous manifesto:

Individual and interactions        Over        process and tools

Working software                        Over        comprehensive documentation

Customer collaboration             Over        contract negotiation

Responding to change              Over         following a plan

Please pay attention that it is "Over", but not "replace". Agile trys to emphasis some key points but do not reject documentation, plan, contract those kinds of things. :-)

 应用Scrum不要死记框架，更重要的是理解背后的Aigle思想和对应的Scrum理论基础。

Scrum是以经验过程控制理论作为理论基础，通过迭代、增量的方法来增强产品开发的可预见性，并控制风险。Scrum经验过程控制理论的实施由三大支柱支撑：

第一：透明性（Transparency）

透明性要确保生产过程中影响工作成果的各个方面对管理工作成果的人来说是透明的。管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容。也就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于他们对完成定义。

第二：检验（Inspection）

开发过程中的各方面必须做到足够频繁地的检验，确保能够及时发现过程中的重大偏差。

第三：适应（Adaptation）

如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么检验员就必须对过程或是材料进行调整。调整工作必须尽快实施以减少进一步的偏差。

Scrum中通过三个活动进行检验和适应：每日站会是用来检验完成Sprint目标的工作进展，调整以优化次日的工作价值。另外，Sprint评审和计划会议是用来检验完成发布目标的工作进展，调整以优化下一个Sprint的工作价值。最后，Sprint回顾会议是用来评审已经完成的Sprint，并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意，并且工作更快乐。

Scrum的特点
Scrum规定了一个非常简单的开发流程。
Scrum是现有设计流程的总结。
Scrum以团队为基础，是一种在需求迅速变化情况下迭代地、增量地开发系统和产品的方法。
Scrum是一个控制由利益和需求冲突导致的混乱的流程。
Scrum是改善交流并最优化合作的方式。
Scrum是一种检测产品开发和生产过程中障碍并将其去除的方式。
Scrum是最大化生产率的一种方法。
Scrum适用于单一的项目到整个组织。Scrum可以控制并组织多个具有相关性的产品开发以及拥有超过千名开发者和执行者的项目实施过程。
Scrum能让每个参与者都对自己所做的工作以及自己做出的贡献感到骄傲，并让他们发挥到最佳水平。

Scrum三个角色及其职责介绍

每个Scrum团队包括3个角色： 产品负责人（Product Owner）, ScrumMaster和 Scrum 团队。

产品负责人--作为产品的owner，代表客户决定产品需求以及优先级，是Team对于需求的唯一诉求人，帮助团队屏蔽传统的需求纠纷干扰。迅速的需求解释反馈，提高团队的效率。

产品负责人的职责：

 确定产品的功能，负责维护产品Backlog。
 决定产品的发布日期和发布内容。
 为产品的投资回报率(ROI)负责。
 根据市场价值确定功能优先级。
 在每个Sprint开始前调整功能和调整功能优先级。
 在Sprint结束时接受或拒绝接受开发团队的工作成果。

产品负责人是一个人，而不是一个委员会。可能会有一些委员会向产品负责人提出建议或影响他的决策，但要想改变某条目的优先级必须先说服产品负责人。实施Scrum的企业可能发现这样会影响他们制定优先级和需求的方法。

为保证产品负责人的工作取得成功，企业中的所有人员都必须尊重他的决定。任何人都不得要求团队按照另一套优先级开展工作，团队也不允许听从任何人带有威胁恐吓性的指令。产品负责人所作的决定需要通过产品Backlog内容和优先级使其可视化。这种可视化要求产品负责人全力以赴，同时也使其成为一个费心费力但又值得去做的角色。

ScrumMaster--帮助团队屏蔽外接干扰，热别是team内外的管理干扰。使团队focus在开发生产中。

ScrumMaster 作为Team Leader和Product owner紧密地工作在一起，他可以及时地为团队成员提供帮助。他必须:

保证团队资源完全可被利用并且全部是高产出的。
保证各个角色及职责的良好协作。
解决团队开发中的障碍。
做为团队和外部的接口，屏蔽外界对团队成员的干扰。
保证开发过程按计划进行，组织每日站会、Sprint计划会议、Sprint评审会议和Sprint回顾会议。
ScrumMaster 除了主持每日站会（Daily Scrum Meeting）之外，还有三个主要职责：

ScrumMaster 需要知道什么任务已经完成，哪些任务已经开始，哪些新的任务已发现，和哪些估算可能已经发生变化。ScrumMaster 需要根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的燃尽图（Burndown Chart）。
ScrumMaster 还必须仔细考虑同时在进行开发的任务数，同时进行的工作需要做到最小化，以实现精益生产率的收益。

该ScrumMaster 需要找出阻碍团队的障碍和依赖。他们需要的优先次序和跟踪。根据优先级指定计划解决这些障碍。其中有些问题可以在团队内部解决，有些则要团队之间的协调，还有的要管理层的介入来解决，甚至有些是公司的问题阻碍了团队达到他们的生产力。比如：一个电信公司最近实施了Scrum，但后来发现只有两个问题和Scrum Team有关，其他的全是公司的问题需要管理层关注。

最后但并非最不重要， ScrumMaster 可能会注意到，个人问题或冲突在Scrum里是需要解决的。这些都需要被澄清，或通过内部的沟通解决，或向管理层和HR寻求帮助解决。ScrumMaster 必须注意去确保团队资源完全可被利用并且全部是高产出的。

Scrum 团队--专注的，心无杂念的开发团队

Scrum团队的职责是在每个Sprint中将产品Backlog中的条目转化成为潜在可交付的功能增量。

Scrum团队的一些特点：

1. Scrum团队的规模控制在5-9个人。
如果成员少于5人，那么相互交流就减少了，团队的生产力也会下降。更重要的是，团队在Sprint中可能会受到技能限制，从而导致无法交付可发布的产品模块。如果成员多于9人，那么成员之间就需要太多的协调沟通工作。大型团队会产生太多复杂性，不便于经验过程控制。对于大型项目来说，可以采用多个小的Scrum团队，通过Scrum of Scrums解决团队间的沟通协调问题。

2. Scrum团队是跨职能的团队。
团队成员必须具备交付产品增量所需要的各种技能。团队成员常常具备如编程、质量控制、业务分析、架构、用户界面设计或数据库设计等的专业技能。在Scrum团队中没有头衔的概念，每个人都必须尽心尽力完成Sprint目标。团队中不允许包括测试或业务分析等在特定领域工作的子团队。

3. Scrum团队是自组织的。
任何人，包括ScrumMaster都没有权利规定团队如何将产品Backlog转化成可交付的功能增量，而是由团队自己确定。每个团队成员利用自己的专业技能，解决遇到的问题。这种协同配合提高了团队整体效率。

团队的构成在Sprint结束时可能会发生变化，每次团队成员的变化，都会降低通过自组织而获取的生产力。因此，改变团队构成时务必要谨慎。

什么是用户故事？
用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：

1.     角色：谁要使用这个功能。

2.     活动：需要完成什么样的功能。

3.     商业价值：为什么需要这个功能，这个功能带来什么样的价值。

用户故事通常按照如下的格式来表达：

英文：

As a <Role>, I want to <Activity>, so that <Business Value>.

中文：

作为一个<角色>, 我想要<活动>, 以便于<商业价值>

举例：

作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”

需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。

用户故事的六个特性- INVEST

INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable

一个好的用户故事应该遵循INVEST原则。

独立性（Independent）— 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。

可协商性（Negotiable）— 一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。

有价值（Valuable）— 每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。

可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。

短小（Small）— 一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。

可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。

任务板（墙）Task Boards

任务板（墙）展现了我们在Sprint过程中所有要完成的任务。在Sprint过程中我们要不断的更新它。–如果某个开发人员想到了一个任务他就可以把这个任务写下来放在任务墙上。 无论每日站会过程中或者之后，如果估计发生了变化，任务会根据变化在任务墙上做相应的调整。
通常的任务板是下面这个样子:

任务墙被横竖分割成许多格子，每一行代表一个Prouct backlog项也可以称作一个用户故事，在Sprint计划会议期间，Scrum团队会分解每个用户故事得到许多的Sprint backlog项，每一项作为一个任务卡放到任务墙上。

每个任务卡从To Do这一列开始。常用的列如下：
        用户故事–根据产品需求分解出的一个个用户故事.
        To Do–需要完成的，但还未开始的任务。
        Doing–刚刚开始，或正在进行中的任务。
                   doing这一栏还是可以细分的，如下是可选的一些栏：
                   Coding: 正在编码
                   Testing: 正在进行测试
        Done–所有已经完成的任务卡都会放在这里，Sprint结束的时候可以拿掉它们。

Scrum的四个工件

Sprint燃尽图（Sprint Burndown Chart）

Sprint Burndown Chart 显示了Sprint中累积剩余的工作量，它是一个反映工作量完成状况的趋势图。 图中Y轴代表的是剩余工作量，X轴代表的是Sprint的工作日。


在Sprint开始的时候，Scrum Team会标示和估计在这个Sprint需要完成的详细的任务。所有这个Sprint中需要完成，但没有完成的任务的工作量是累积工作量，Scrum master 会根据进展情况每天更新累积工作量，如果在Sprint结束时，累积工作量降低到0，Sprint就成功结束。
Product Backlog 功能点被放到Sprint的固定周期中，Sprint Backlog 会因为如下原因发生变化:
1. 随着时间的变化，开发团队对于需求有了更好的理解，有可能发现需要增加一些新的任务到Sprint Backlog中。
2. 程序缺陷做为新的任务加进来，这个都做为承诺提交任务中未完成的工作，这些也许可以分开进行跟踪。

Product Owner也许会和Scrum team一起工作，以帮助team更好的理解Sprint的目标，ScrumMaster和team也许会觉得小的调整不会影响sprint的进度，但会给客户带来更多商业价值。

由于在Sprint的刚开始的时候，增加的任务工作量可能大于完成的任务工作量，所以燃尽图有可能呈上升趋势。