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%之间。

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

============================================================

SCRUM的3355理论

 如果用一段话来简单明了的描述一下SCRUM，应该是这样的：
1、我们需要把人进行分割，所以我们建议会组建一些小的团队，人数最好是在3-7人。
2、我们需要把任务切小，拆分成故事卡。
3、团队在一个sprint周期内权利冲刺去完成计划的故事卡。
4、做持续集成去从整体上把握任务的完成情况和风险。
相比较而言，看板的具体实践就没有那么多的限制，看板主要强调以下几个方面：
1、流程的可视化。
2、限制并发。（在制品的数量）
3、优化交互时间。
    相对于一个需要转型的团队来讲，SCRUM是相对比较激进一些的，因为这个框架告诉了你说SCRUM需要在迭代周期内开几个会，且时间盒（迭代周期）内完成的故事卡尽可能在开了计划会承诺交互会，就在迭代周期内完成（否则团队响应变化的能力就会变弱），且迭代周期内要完成的事，在这一个迭代周期就尽可能保持不变，以免引发一起不必要的浪费。而看板是一个比较渐进式的变革，它一开始的时候可能没有那么多的条条框框，是一个更加轻量级的方法，但真正在现实的应用中，想要把看板方法实践得很好，反而是比SCRUM更加困难的一件事情。
    下面就着重的讲一下SCRUM相关的一些知识：
    从整体上来讲，SCRUM这个框架里面包含了这几个核心的要素：
1、3个角色：SM、PO、开发团队（自然包括了我们的开发人员和QA）。
2、3个产出物：Product Backlog、Sprint Backlog、交互的可用软件工件。
3、5个活动：计划会、sprint评审会、回顾会、每日立会、Product Backlog的梳理（发生在整个SCRUM周期的任何时间）。每一个会议都有自己的时间盒，其长短在SCRUM中都有比较明确的建议。当你召开某一个会议的时候，超出了这个时间盒或者召开某个会议的时候出现一些问题，也是一种有问题的信号。一个团队在冲刺的周期内，去充分的暴露问题，然后在回顾会上去分析问题，再进行改进。在每日立会上比较强调的是，根据昨天完成的情况来做出新的调整，我们每日立会上所描述的，一定是对有助于完成当前sprint目标的事情。同时，特别需要强调的是，在sprint评审会上，团队除了对当前sprint完成的故事进行show case还需要对剩余的任务卡进行梳理，可以让团队有机会去回顾和识别版本发布的风险。
4、5个价值观：公开、专注、勇气、承诺、尊重。
另外，还讲到了SCRUM最重要的时间盒，这个是我之前所理解的SCRUM里面，没有发现它竟然是如此重要的。还学到一个新的理论：番茄工作法是一个人的SCRUM，SCRUM是一群人的番茄工作法；理解到跨职能是团队层面的概念，而一专多能是每个团队成员层面的概念。现在回过头来看，发现曾经团队在尝试SCRUM的过程中，对有些方面是理解得不够的，包括为什么最终团队放弃了SCRUM转向看板，其缘由也不完全是曾经以为的迭代周期的问题，需要系统的来看待这个问题。不管一套理论是如何的完善，结合到实际的工作中的时候总会遇到这样和那样的问题，但抓住最本质的东西才是最重要的，抓住其精髓的部分，然后再加以灵活应用，以问题为出发点，能够真正的解决实际的问题才能给大家带来信心。
最后，分享一下SM的一些相关知识：
一、SM应该在团队承担的几种角色：
1、引导者，就像一个出租车司机，需要去哪儿，是由团队来决定的，作为引导者，带领团队到达他们想去的地方。引导团队建立团队规则，维护团队和指导团队外部成员遵守团队的规则。作为引导者需要特别注意的是，不能把自己的价值观强加于团队，让团队成员尽量表述自己的意见。
相信大众智慧---得到“最佳方案”
相信大众参与---得到“最佳执行力”
2、教练：指导团队和PO遵循SCRUM的价值观。教练作为一面镜子，在每日立会和回顾会等会议上，只陈述事实，在日常工作中尽量多去收集一些数据，通过陈述事实和提问让团队去思考，通过这种方式让问题的解决达成一致。（如果当前的陈述让团队意识不到问题的存在，那么建议继续守望，继续收集数据，再陈述事实，通过反射让团队去发现问题）
3、移除团队障碍。

二、SM的几个发展方向：
1、敏捷/教练：推荐《敏捷开发的艺术》和《用户故事与敏捷方法》。
2、技术（CI、TDD、重构等）：最重要是去做周计划，去与别人结对或者做练习。
3、业务（PO）：帮助团队的PO去切分故事，推荐《精益创业》和《用户故事与敏捷方法》。同时，建议QQ邮箱PO的千百十工作法：得到1千个用户反馈，选一百客户进行沟通，再从中选择10个沟通结果作为下一个迭代的故事。这样做，既有广度也有深度，能够持续不断地保证团队做对用户最后价值的事情。
4、转型：从A----B点，往往SM需要考虑，不止一种方法，需要多种方法，灵活运用。
5、教练：推荐《敏捷教练》，这一项要坚持实践PDCA，做周计划，比如：回顾会、心情曲线、跨团队指导等实践活动。
6、导师。
7、引导。
8、演讲。
后三者都是属于纯实践型的活动，需要多演练。大家可以基于目前的现状对上述8个维度进行一个打分，形成当前的雷达图，然后再做短中期计划，三个月后再去绘制新的雷达图，每一个短周期内，建议是集中精力对某一项进行实践和提高。做周计划是一个非常好的实践技巧，比如：阅读一本书，可以精细到每周阅读多少页。这样比起做月度计划，会让你的可操作性和跟踪性，能有更短的一个反馈周期，更容易实践下来。