CSM(Certified Scrum Master)敏捷大师培训总结

2011年4月14-15日，有幸参加全球敏捷联盟的CSM(Certified Scrum Master)培训，虽然我们在平时工作中一直使用Scrum开发模式，但是对Scrum的理论我还不是十分的清楚，两天全英文的培训使我全面了解了Scrum的基本流程，总结一下培训重点，希望和更多使用Scrum模式的人共同交流探讨，某些术语翻译的不准确，希望批评指正。

 

 

1.Scrum简介：

Scrum一词来自橄榄球运动，在软件工程中，Scrum是以经验过程为依据，采用迭代、增量的方法来提高产品开发的可预见性并控制风险的理论，Scrum不是一种过程，也不是一项构建产品的技术，而是一个框架，在Scrum框架中可以应用各种过程和技术，Scrum的作用是让开发实践方法的相对功效显现出来以便随时改进。

2.敏捷开发中的Scrum模式：

Scrum是敏捷(Agile)开发的一种实践模式，敏捷开发强调拥抱需求变化，快速响应不断变化的需求，并尽可能快地提供可以工作的软件产品，敏捷最强调的是可以正常工作的软件产品，文档等不是非常的强调（并非不要文档，只是需要必要的文档），敏捷理论认为面对面的沟通交流远比文档更有效。

敏捷开发的Scrum模式是以价值驱动(Value-Driven)的开发模式，即认为用户的需求并不一定需要100%实现，最重要的是将对用户最有价值的功能实现并交付.

敏捷开发中Scrum开发流程如下：

3.Scrum框架元素：

Scrum框架的主要元素有：

(1).3种角色：

a.Scrum Master。

b.Scrum团队。

c.产品负责人(Product Owner)。

(2).4种会议：

a. Sprint规划会(Sprint Planning Meeting)。

b．每日站会(Daily Scrum Meeting)。

c．Sprint评审会(Sprint Review Meeting)。

d．Sprint回顾会(Sprint Retrospective Meeting)。

 

(3).2个Backlog列表：

a.产品需求Backlog列表(Product Backlog list)。

b.Sprint Backlog列表。

(4).2个燃点图：

a.产品发布燃点图(Product release burndown chart)。

b.Sprint燃点图(Sprint buirndown chart)。

4.Scrum角色介绍：

(1).Scrum Master:

Scrum Master的主要职责是：

a.排除产品开发和产品负责人之间的障碍，确保产品负责人直接推动开发工作；

b.教授产品负责人如何实现投资回报最大化，以及如何利用Scrum达成目标；

c.激发创造力和放权，从而改善开发团队的环境；

d.千方百计实践和工具，确保每个功能增量都具备潜在可交付行；

e.向各方确保团队工作进展实时更新并高度可视；

(2).Scrum团队：

Scrum团队是Scrum框架的核心，Scrum团队是一个自我管理的组织(Self Organize Team)，Scrum团队不需要命令，成员根据自己的兴趣任意选取Sprint Backlog中分解的任务，整个团队为了在Sprint迭代开发周期中提交可工作的软件产品目标而相互合作，Scrum团队的特性：

a.具有不同特长的团队成员，人数控制在5-9个左右。

一个Scrum团队中，开发，测试等人员都需要有，人数不能太多，否则沟通成本太高。

b.确定Sprint目标和具体说明的工作成果。

c.在项目向导范围内有权利做任何事情已确保达到Sprint的目标。

d.高度的自我管理能力。

e.向Product Owner演示产品功能。

Scrum团队的成员们必须有这样一个意识：整个团队要么一起成功，要么一起灭亡，没有个体的概念，每个成员只要为了Sprint目标，可以做什么事情。

(3).产品负责人(Product Owner)：

产品负责人(PO)负责收集客户需求，并根据产品功能点对用户需求的价值，将客户需求排列优先级形成产品Backlog作为Scrum团队Sprint开发周期的输入。产品负责人的特性如下：

a.确定产品的功能。

b.决定发布的日期和发布内容。

c.根据市场价值确定功能优先级。

即Value-Driven，根据功能客户的价值/投资回报率对来确定优先级。

d.在Sprint周期内调整功能和调整功能优先级。

e.接受或拒绝接受开发团队的工作成果。

5. Scrum4种会议介绍：

在介绍Scrum4种会议之前，首先介绍Scrum中一个很重要的概念——Sprint.

Sprint是一个固定时间段的迭代开发周期，一般为2-4周，最长不要超过一个月，Sprint太长风险不易控制，太短则Sprint会议会占用大量时间。一个Sprint由Sprint规划会、每日站会、Sprint评审会和Sprint回顾会组成，Sprint的输入是产品Backlog，输出是包含了Sprint提交的可运行的软件。

(1).Sprint规划会(Sprint Planning Meeting)：

Sprint规划会议制定迭代计划，Sprint计划会议的内容包括以下两个部分：

a.产品负责人告诉Scrum团队决定Sprint做什么：

产品负责人把具有最高优先级的产品Backlog呈现给Scrum团队，并一起决定接下来的Sprint中开发什么功能。

b.Scrum团队研究如何实现功能：

Scrum团队根据Sprint规划会议第一部分的产品Backlog，将产品Backlog分解成具体的开发任务，即Sprint Backlog，并估算完成每个任务所需要的大概时间。

这个阶段的会议不要超过4个小时。

(2).每日站会(Daily Scrum Meeting)：

一旦Sprint计划阶段结束，2-4周的Sprint就开始了。Scrum Master需要组织团队成员每天开站会. 这个会议是用最多15分钟的时间来让大家过一下scrum的状态。在会上，每个团队成员需要问3个问题：

a.我昨天做了什么.

b.今天做什么.

c.遇到哪些障碍。

谁都可以参加这个会议，但只有Scrum团队成员有发言权。这个会议的目标是得到一个项目的全局观，用于发现任何新的依赖，定位Scrum成员的要求，实时的调整当天开发计划.

注意：每日站会时，只通报进展情况，不做讨论，深入具体的讨论在会议结束之后找时间进行。

(3).Sprint评审会(Sprint Review Meeting)：

在Sprint结束的时候召开Sprint评审会，这个会议最多不超过4个小时.Scrum团队演示在这个Sprint中开发的产品功能给产品负责人.产品负责人会组织这阶段的会议并且邀请相关的利益相关者参加。业务，市场，技术都要做相关的评审。由产品负责人来决定Product Backlog中的哪些功能已经开发完成 。

(4).Sprint回顾会(Sprint Retrospective Meeting)：

由Scrum Master和Scrum 团队一起回顾当前的Sprint。团队评估大家在一起的工作方式，找出好的方式以后继续发扬，找出需要做的更好的地方，想办法提升。Sprint评审会结束后，新一轮的迭代又继续开始（中间最好修整半天或者隔个周末），迭代会一直继续，直到开发了足够多的功能去交付一个产品。

Sprint回顾会时，汇报经理和产品负责人一般不被邀请参加，主要是为了给Scrum团队一个安全的、畅所欲言的开放环境，毫无顾虑地提出意见帮助Scrum团队更好地工作。

Sprint回顾会时，最好Scrum选择一个好的方面，一个不好的方面讨论，容易在有限时间里充分讨论形成一致意见，并确定责任人执行。

6.Scrum的Backlog：

Sprint中有两种Backlog：产品Backlog和Sprint Backlog.

(1).产品Backlog：

在产品/项目开始的时候，产品负责人要准备一个根据商业价值排好序的客户需求列表。这个列表就是Prodct Backlog，一个最终会交付给客户的产品特性列表，它们根据商业价值来排列优先级，是Scrum团队每个Sprint的输入。

Scrum团队会根据Product backlog来做工作量的估计。Product backlog应该涵盖所有用来构建满足客户需要的产品特性，包括技术上的需求。高优先级的一些产品特性需要足够的细化以便于我们做工作量估计和做测试。

产品Backlog列表中的最小单位为用户故事(User story)，用户故事的需要必须独立、可评估大小(用户故事的相对大小)，对于用户故事的估计方法如下：

a.选择用户故事大小参照物。

b.Scrum团队使用扑克牌估计用户故事的大小，尽可能意见比较一致或相近。

c.使用菲伯纳西数列：1，2，3，5，8，13，21……表示用户故事的相对大小。

d.对于过大的用户故事需要拆分成小的用户故事。

(2).Sprint Backlog：

当Scrum团队选择并承诺了产品Backlog中要递交的一些高优先级的产品功能点后，这些功能点就会被细化成为Sprint Backlog：一个完成Product Backlog功能点的必需的任务列表.这些点会被细化为更小的任务，工作量小于2天。Sprint backlog完成后，Scrum团队会根据它重新估计工作量，如果这些工作量和原始估计的工作量有较大差异，Scrum团队和产品负责人协商，调整合理得工作量到Sprint中，以确保Sprint的成功实施。

7.2个燃点图：

(1).产品发布燃点图：

产品发布燃点图记录在一段时间内产品Backlog的总剩余估算工作量，估算工作量是以Scrum团队和组织决定的单位为标准，时间是以Sprint为单位。产品发布燃点图是产品剩余工作量趋势图。

(2).Sprint燃点图：

Sprint燃点图展现的是当前Sprint内剩余的Sprint backlog工作量，创建该图需要通过累计Sprint中没人Backlog估算来确定剩余工作量，Sprint内剩余工作量就是所有Sprint Backlog的剩余工作总量，Scrum团队在每日站会过当前Sprint工作状态时，会同步更新Sprint燃点图，时刻显示剩余工作量。用线将图上的点连接起来，团队就可以控制完成Sprint工作的进程，所耗时长并不属于Scrum的关注范围，剩余工作量和完成日期才是利益相关因素。

Sprint燃点图以及Sprint任务分解的重点不是关注是否精确，而是确保Scrum团队可以保持一个稳定的开发速度和产出效率，Scrum团队通过长期对Sprint燃点图的统计分析可以估算出团队的乐观速度，悲观速度和平均速度，在Sprint规划会时可以给出Sprint可以完成的Product Backlog乐观的、悲观的和平均的估计。

8.定义完成(Definition of Done)：

Scrum要求团队在每个Sprint内构建可交付的软件产品功能增量，因为对于产品Baclog的功能是否完成每个人的理解可能不同，因此需要定义完成的含义，定义完成由Scrum团队和产品负责人一起讨论决定，只有所完成所规定的工作全部完成时，产品Backlog才算完成，未完成的产品Backlog导入到产品Backlog中，继续下一个Sprint迭代。