2天的SCRUM培训学习笔记

2012年10月27日至28日参加了优普丰组织的在北京为期2天的Certified(不是Certificated) Scrum Master培训，收获多多。参加培训前邮件中介绍Vernon老师是个精通中文的美国人，一开始以为这场培训注定是一个老外讲上一堆英文，然后有个中国人在旁边翻译的讲座了，没想到这个vernon中文水平真是好，正常的语速的中国话他听得一点问题也没有，汉语说的也是相当清楚，只有少数的字有点口音。vernon老师浑身散发着巨大的热量（他自称的Passion），当热到一定程度后，vernon就把鞋拖掉，一双白袜子开始在会议室里走来走去。

敏捷宣言与Scrum

以前对敏捷开发有一些了解，最早接触的是极限编程XP，知道有17位爱好滑雪的软件人士琢磨出了著名的敏捷宣言，对一些传统的庞大的软件开发提出了挑战。

敏捷Agile就像一把大伞，Scrum、XP、FDD等等都是其中的一员，Scrum是一种框架，更注重于一些过程，XP更注重于实践。

为了明白敏捷的几个要点，Vernon老师专门设计了一个传递纸球的小游戏，准备一堆用报纸揉成的小球，参加培训的8人为一组，围成一圈站立，规则很简单，只能用手传球，球从一个人手到另一个人手之间必须有空中时间，球必须传递给不相邻的人，一个球经过所有成员后才算1分，1分钟之内传递小球的个数为总成绩。游戏进行了5-7轮，每轮中间有1分钟的讨论时间。

游戏虽简单，但却能深刻地体会以下要点：

1）每轮的讨论都能提高下一次的成绩，第一轮好像只传了6个，最后一轮传了100多个，最后的改进幅度之大让我们自己都无法想像

2）设计再周密的方案不如马上动手，只有实践起来才能提出有针对性的改进建议

3）短时间内的决策也是相当有作用的，1分钟虽短，但短时间也同样能激发出的大脑无穷的创造力。

4）减少每个人空闲等待的时间，并行作业让球不停地在多个人之间快速流动，大大减少了等待的时间

5）当成绩提高到一定水平后，如果不在方法或工具上出现革命性的变革，成绩就不会再有多大的提高

6）把30分钟的总时间分解为多次迭代，每个迭代中进行实践和总结，远远比进行29分钟的周密设计讨论和1分钟的实践要有效得多。

 

Scrum总结起来就是3355，实际上应该称为3455：3种角色，3种工件，4种仪式（活动）和5个价值观。2天的课程实际上就是围绕着334来介绍的，当然讲解的过程不断地涉及到5种价值观的讨论。

 

 

 

三个角色

Scrum Team由三种角色构成。

关于三种角色与龙舟比赛的类比：PO相当于舵手，把握团队前进的方向；TEAM相当于划桨运动员；SM相当于鼓手，负责协调团队。

1）Product Owner

客户代表，决定产品的发展方向vision，对ROI负责（投资回报率return on investment），本身最好就是个customer，PO是一个人，负责给PBI(Product Backlog Increments）排序，负责维护Backlog，确认Sprint的结果（Accept Sprint Results），PO有权利决定是否产品可以发布，PO不一定写全部的用户故事，PO要不断与团队沟通，PO有决定权Authority。

2）SCRUM Master

这个名称相当有份量，参加2天的培训，还没有Scrum的实践经验，通过了认证考试，就可以称为Scrum Master了。

我们普遍认为这个SM最没有事情可做，但老师一再强调这个角色很忙，特别对于不成熟的团队以及在项目的前期，我们把以前项目经理负责的事情一一写下来，贴在这个白板上，发现这个SM好像就是事情不多，他在整个过程中就是一个教练、一个咨询师的角色，他实际上就是辅导你如何开始正确的Scrum各个过程、会议等等。

SM在整个团队中起到一种老师、教练、促进的作用，要保证团队不受干扰、保证团队高效地开展工作，移除一些障碍。他几乎没有什么权利，但要有影响力。

Vernon关于在一些会议上ScrumMaster为什么可选参加的注解：

While the ScrumMaster is optional at many meetings they are responsible for assuring the Scrum framework is being effectively applied, so as you note in the area discussing the ScrumMaster role they are likely to be quite involved in all meetings, especially initially as the team needs to be trained and coached to understand how to effectively conduct the meetings: to understand their structure and purpose.

3）DEV Team

软件还是要由一群程序员一行一行写出来，这就是Team的任务了，这里Team中每个人的技能要掌握得全面（有专长，但不能只擅长的事），要会自我组织管理、跨职能、人数控制在5-9人之间、最好全职（可能有少量例外）、No Title（没有严格的分工，没有需求、编码和测试的分工）。

 

Scrum中没有项目经理的角色，没有上下级的关系，vernon打了一个比喻，说Scrum有点共产主义，但共产主义中最常见的是上下级领导关系。感觉根据我们当前的现状，三个角色最难找的是Product Owner，这个角色代表着用户利益，但要经常与开发团队混在一起。

 

三个工件

1）Product Backlog

Product Backlog = a dynamic list of features that might appear in our product.

Vernon老师的注解：

PBI=feature, A bunch of PBIs = product Backlog

It might also be worth noting that PBIs don't have to be software. The Scrum framework can be applied to areas outside of software, so PBIs could be other product features as well; for example the introduction in a book, or a chapter in a book.

值得注意的是：PBIs并不一定专指软件。Scrum框架可以应用于软件之外的其它领域，因此PBIs也可以是其它产品特性，例如在出版业，可以是书的一个章节。

这个Product Backlog就是软件产品的功能列表，由许多PBI（Product Backlog Item）组织，一个PBI又由许多SBI（Sprint Backlog Item）组成，这个Backlog要贴在一面大墙上，上课时曾经问了vernon老师，这个东西全用工具放在开发团队的网站首页上行不行？vernon说可以，但只用电子的backlog会影响开发效率，所以他们公司还是用大墙和便利贴，一些内容会录入到电子backlog中。

25个小星星积木的游戏让人明白了优先级的重要作用，要在最短的时间内得到的最大的收益，就是要先完成那些黑星星。

2）Sprint Backlog

这个Backlog感觉可以称为任务了，通常PBI颗粒太大，无法执行，只有分解为SBI（小于2天的工作量）才能开始动手做。感觉这东西好像GTD里将Project分解为Action的过程，不过任何项目也都是这样来分解的。

 

3）Tracking/Increment

这个东西在以前就是指燃尽图，现在好像说也不是必须的了，实际上Backlog也完全可以体现出项目的进展情况。

四个活动

Scrum就是由一堆的Sprint组成的，这个Sprint实际上就是迭代，每个Sprint最少为1天，最长为4周，由4个活动组成。

Vernon的注解：

In theory there is no minimum sprint duration, one day is just the shortest I've seen in a production environment. Sometimes in training we use 1/2 day sprints. A key concept, however, is that for a sprint to be a sprint, it must include the 4 meetings.

理论上没有最小的sprint长度限制，一天的sprint长度是我在产品开发中看到过的最小的长度，在培训时有时可以用1/2天作为sprint的长度。然后，一个sprint可以称为sprint的关键是它必须包含4个会议。

Sprint是固定长短的，有可能第一次迭代之后，周期有点调整，但后来采用一个稳定的天数，这就是Scrum的rythym节奏。

在Sprint期间，功能范围不再变化，即PBI从左侧拿到Sprint Backlog区后，不再接受新的SBI。

Vernon的注解：

SBIs are emergent, and defined by the team, so it is quite possible that new SBIs will be added during the sprint. This is just to say that the team has developed a deeper understanding of how they will complete the PBI. So, during a sprint the SBIs can change, but the PBIs that the team has committed to cannot change. "No change" during the sprint refers to PBIs.

SBIs具有涌现性，是由团队来定义的，因此在sprint之间会出现新的SBI。也就是说，团队对于如何完成PBI已经有了深刻的理解，因此在sprint期间SBI是可以变化的，但团队已经承诺的PBI不能变化。在sprint中的"No Change”是指PBI而言的。

 

1）Sprint Planning

这个过程有点需求分析的作用，实际上也是一种承诺Commitment。这个会议又由2个阶段组成，第一阶段称为Selection，第二阶段称为Planning。

第一阶段由PO、TEAM参加，SM可选。对于1周的sprint，这个阶段不超过1小时。

在这一步是根据PBI的优先级拿到Sprint backlog中，对于较大的粒度，还要分解。

第二阶段由TEAM参加，PO和SM可选，但PO要随叫随到。对于1周的sprint，这个阶段不超过1小时。

 

2）Daily Scrum

这就是著名的站立会议，要在每天相同的时间、相同的地点举行，少于15分钟。

Scrum(由于它不是一个缩写单词，所以一般不用大写所有字母)的术语也是来源于橄榄球中的碰头开球仪式，在rugby这种运动中，每个运动员都是自组织的、跨职能的，需要根据场上的动态地调整计划。

会上要回答3个问题：

What did I get done in the last work period?

What will I get done in the next period?

Any impediment（障碍）?

通过这三个问题，团队进行广播式的沟通，跟踪项目的进度，分享一些知识，更重要的是给团队做出一种承诺Commitment。

3）Sprint Review

这种回顾对于长度为1周的sprint，不超过1小时，不需要PPT，非正式的交流。整个过程也是TEAM和PO参加，SM可选。最好还要请一些stakeholder参加。

Vernon的注解：

PO and team are required, ScrumMaster is optional. Stakeholders are encouraged to attend this meeting. Since this meeting is a key means of the PO soliciting feedback from stakeholders, their participation in this meeting is essential. The PO might even be the host/driver in this meeting.

4）Sprint Retrospective

这个会议对于长度为1周的sprint，不超过45分钟。整个过程TEAM参加，SM和PO可选。

这个过程是为了将来的持续改进，不讲坏消息，提出1-3个改进建议，然后就是celebrate。

Vernon的注解：

The Sprint Review is the meeting where the working results of the team are shared with the stakeholders and the PO. The Sprint Retrospective is the meeting where the team considers how they can continuously improve.

The Sprint Retrospective is the meeting where the team considers how they can continuously improve. The team is required and the PO and ScrumMaster are optional (at the discretion of the team). Typically the team would encourage their participation unless the PO or ScrumMaster themselves are in some way an impediment to the team improving.

用户故事

User Story并不是SCRUM中的内容，但可以用于SCRUM中。

PBI相当于User Story，而SBI相当于任务Task，SBI的颗粒度要小于0.5天。

Vernon的注解：

1/2 SBIs are a practice my company uses, but not a formal definition included anywhere related to either User Stories or Scrum. As you correctly note earlier in your blog, SBIs are typically 1 - 16 hours (less than 2 days) in duration. 1/2 day is just our practice.

PBI要写到什么程度？DEEP原则：

Detailed Appropritly 比较清晰的

Emergent 涌现性

Estimated 被估算的（以团队的方式来估算）

Prioritized / Order 被排序的

估算

vernon老师由于散发着巨大的热量，所以需要不停地补充水份，每天带着一大瓶（搞不清楚2升还是3升）基本上都喝得差不多。一个游戏就是估算他喝剩下的水的体积，8个人的估算从400ml到1600ml不等，相差如此巨大，说明了人不擅长使用绝对的数量来评估事物，而使用百分比来估算时，范围就统一在55-65%之间。

优普丰的计划扑克可以用于团队对任务工作量进行评估。