唐巧的博客

适合码农工作时玩的游戏:Scrum

字数统计: 5.5k阅读时长: 18 min
2014/09/13

前言

昨天遇到一个来自微软的面试者,在面试的最后,我简单介绍了一下我们团队使用一周一次的 Scrum 来做项目管理。他回答说:” 我在微软也用 Scrum,不过我们一周两次,时间在周二和周四上午,每次 15 分钟 “。我听了就笑了,我说:“同学,你说的这个应该是 Scrum 的站立会议,Scrum 实际上有 4 个会议,站立会议只是其中一个。另外,标准的站立会议应该每天一次,不是每周两次。” 接着我给他介绍了 Scrum 的 4 个会议,每个会议的意义是什么,他若有所思。

今天和同事吃饭说起这件事情,同事 pw 说:在他所了解到的使用 Scrum 的公司里面,我们应该是执行 Scrum 做得最规范的,同时我们从 Scrum 实践中,收获了非常多。

大约在 3 年前(当时我们团队还在网易),我们团队开始尝试用 Scrum 来进行软件开发的项目管理。在经过了 3 年的摸索和调整后,我们不但多次保证了项目的顺利上线,而且建立起了适合自己团队的工作方式。

正如 Scrum 官方指南所说,“Scrum 是易于理解,但难以精通的”,在此向大家分享我们实践的心得体会,希望更多的开发团队能够运用 Scrum 来流化自己的开发流程。

Scrum 是游戏规则

Scrum 官方网站 上,提供了中文版本的 《Scrum 指南》,这份只有 14 页的文档的封面上,写下了其最核心原则:游戏规则。

什么是游戏规则?游戏规则是玩游戏的人为了更好地娱乐而制定的规则。所以 Scrum 的规则是为了让大家更开心,更有效地工作,而不是约束大家。事实上由于 Scrum 只是一个框架,所以在实践 Scrum 时,更多的规则需要团队成员共同制定,这更加体现了游戏规则的思想——大家自己制定的规则,必定是得到大家一致同意的、能让大家舒服工作的规则。

Scrum 是基于经验的

Scrum 强调经验的重要性,但是经验又是需要不断调整的,所以 Scrum 通过迭代增量的开发方式,来每次调整整个团队的经验,从而来优化可预测性。

例如,我们在开发猿题库时,在每轮 Scrum 的结束时,我们会开回顾会议,将大家每天处理待办事项的速度(我们称做日均 Story Point)总结在 Wiki 中,如下图所示。这样当我们估计一个新一轮的迭代工作是否能够完成时,就可以参考前面几十次的经验,做出更加理性地判断。

Scrum 的三大支柱

透明性、检视、调整是 Scrum 的三大支柱。

  • 透明性是指:团队成员要达到对信息的完全共享,以便对观察到的信息有相同的理解。
  • 检视是指:团队成员要不停地检查自己的状态,类似汽车的定期检查一样,通过检视了解当前项目的状态。
  • 调整是指:团队成员发现出现了会影响项目进度的事件后,要及时寻找对策。

以上的说法有些学术化,我们可以这样理解:

群体智商常常会出现低于个体智商的现象,这是因为个体之间的信息通常不一致,每个人的信息都是片面的,所以造成了观点的片面,而通常情况下团队领导由于接受到的信息更全面,所以他的决策考虑会更周到一些。

但是 Scrum 又强调团队需要是 “自组织” 的,这就需要群体进行决策而不是领导。为了群体更好的决策,所以 Scrum 特别强调信息的透明,这样大家的信息都是充分共享的,而检视是一种保证信息透明的方法,即定期地查看自己和团队的状态,有了信息的透明,这样团队成员就能共同发现项目执行中的问题,进而一起寻找解决办法,从而达到 “自组织” 的团队。

Scrum 的基础游戏规则

Scrum 定义了基础的游戏规则,在基础的游戏规则之上,团队可以依据自己的经验,制定更细致的规则。但更细致的规则不应该违背基础的规则。这就像国家的宪法一样,其它法律不能与宪法违背。

那我们来看看 Scrum 有哪些基础的游戏规则。

角色定义

玩三国杀的同学都知道,玩之前大家会抽身份:主公、反賊、忠臣、内奸。而 Scrum 的游戏规则里面,有以下几种身份角色:

  • 产品负责人:产品负责人是管理产品待办列表的唯一责任人,也是产品最终的责任人。(稍后我们在介绍计划会议时,解释什么是产品待办列表。)简单来说,最终如果产品没做好,应该扣产品负责人的工资。

  • 开发团队:开发团队是负责将每轮 Scrum 迭代中计划的功能(可能是产品稿 + 美术稿的形式),交付成可发布的产品的各种专业人员。这里的各种专业人员包括:服务器端开发、Javascript 前端开发、客户端开发、测试人员等。开发团队是真正在玩这个 Scrum 游戏的人,其他人(例如产品负责人都只是部分参与)。

  • Scrum Master:Scrum Master 类似于杀人游戏中的法官,即游戏组织者。Scrum Master 并不是团队的领导,他仅仅是做一些组织工作,而对于一个 “自组织” 的团队来说,其实真正需要组织的事情也不太多,所以他常常由开发团队中的某一个人兼任。

没有子团队

在 Scrum 的官方文档中,这样说道:

Scrum 不认可开发团队中的所谓 “子团队”, 无论是测试还是业务分析的成员都不能划分为 “子团队”。此规则无一例外。

所以我们看到,Scrum 在定义角色的时候,强调开发团队中一个整体,包含把产品发布出来的所有相关的专业技术人员,并且开发团队共同承担开发的责任,只有这样,大家才能形成利益共同体,共同努力把产品做好。

这一点也解释了为什么很多大公司玩不好 Scrum。拿百度举例,百度的一个项目就有很多 “子团队”。在百度,前端开发人员属于前端组,移动端开发人员属于移动端组,测试有专门的 QA 组,PM 也有专门的组。这样的划分,进而造成大家的绩效评估并不是完全由项目执行的好坏来决定,而 PM 也需要花很大精力去推动大家,这样的团队没有共同的利益,是很难做到 “自组织” 的。

强调平等

Scrum 中仅定义了 “开发团队” 这个整体的角色,在 “开发团队” 内部,大家都是平等的。因为只有这样,大家才能更加自由的共享信息,共同决策,否则决策权仍然掌握在少部分人手里。在 Scrum 的官方文档中,是这样说的:

Scrum 不认可开发团队成员的头衔,无论承担哪种工作他们都叫做开发人员。此规则无一例外。

游戏人数规则

开发团队还有一个不能不说的特点,就是他的规模必须足够小,因为他强调信息的透明,如果人数过大,光沟通的成本就大到无法承受了,所以官方文档上推荐的人数是 10 人以内(不包括产品负责人和 Scrum Master,除非他们也参与开发)。

但是在实际执行中,由于业务的增长,团队人数很容易就超过 10 人。比如我们猿题库在创业时只有不到 10 人,现在已经成长到几十人了。这个时候,比较好的做法是进行团队的切分,比如我们试过将猿题库的服务器端和客户端进行拆分,这样保证每个团队还是在 10 人以内。如果以后再增长,可能客户端会再进行拆分成 iOS 团队和 Android 团队。

游戏时间

Scrum 对每一轮的迭代时间并没有严格的规定,但它要求是小于一个月。对于每一轮的迭代,Scrum 把它称作 Sprint(冲刺)。

作为创业公司,我们在最近两年都实践着一周一次 Sprint 的方式来工作。一周一次 Sprint 能够保证调整足够快,Sprint 执行中是不鼓励需求改动的。所以一周一次的 Sprint 能够做到,对于比较急迫的需求改动,在下次 Sprint 时(下周)就可以执行。

一周一次的 Sprint 也有不少问题,由于偏离本文主题,所以就不展开介绍了。现在我们的猿题库直播课项目组也在尝试进行 2 周一次的 Sprint。总之,Sprint 多长是由开发团队根据项目的具体特点来决定的,只要不超过一个月即可。

游戏玩法

讲了半天,终于讲到核心了,到底怎么玩这个游戏啊!为了更好的理解,我们先看看杀人游戏的玩法,杀人游戏定义了如下几个事件:

  1. 天黑请闭眼,这个时候大家都闭上眼睛
  2. 杀手睁眼,杀手杀人,杀手闭眼
  3. 警察睁眼,警察检查,警察闭眼
  4. 天亮了,宣布谁死了,大家讨论并投票谁是杀手,投出的嫌疑人被杀死。如果警察或杀手死了,宣布游戏结束,否则跳到第 1 步。

刚好,Scrum 也定义了 4 个事件,分别是:

  1. 计划会议
  2. 每日站立会议
  3. 评审会议
  4. 回顾会议

以下我们来详细介绍一下这 4 个会议到底要具体怎么做。

计划会议

计划会议主要通过讨论,完成两件事情:做什么、怎么做。

关于 “做什么”:产品负责人会给出一个产品待办列表,然后由团队成员来根据预计的工作量以及以往的表现,来挑选接下来的 Sprint 需要完成的待办项。这里的特点是:由开发团队成员自己来挑选待办项,而不是由传统意义上的 Tech Leader 或产品负责人来挑选。这样保证了开发任务是由团队成员自己决定的,他更有责任心把事情完成。同时作为产品负责人,有必要非常明确地告诉开发团队每一个待办项的意义和重要性,这样开发团队才能做出有利于产品的挑选工作。

关于 “怎么做”:开发团队从待办列表中挑选完需要完成的待办项之后,就需要对每个要做的待办项进行评估。评估的工作就是讨论具体怎么做,这包括技术架构、实现细节的讨论。只有讨论得非常清楚之后,这项工作的工作量才会比较清楚。

在讨论怎么做之后,一些敏捷公司推荐使用 “出牌” 的方式来评估工作量,我们也采用了这种方式,我们还专门做了一套 Scrum 扑克,用于出牌。如下图所示:

出牌的规则是每个人出一张牌,用牌上的数字表示当前工作的工作量。通常大家还会事先约定好数字 2 代表的工作量,以保证大家的标准相同。为了避免相互影响,大家先把要出的牌扣着,然后同时翻开。之后,出最高分的和出最低分的同学要表达意见,说明为什么自己估计成这样,大家讨论,这样的过程可以保证大家的信息都是透明的,即没有忽略掉的技术实现难度或细节,在信息充分共享的情况下,通常大家第二次出牌时就可以达成一致了。

每日站立会议

每日站立会议是进行检视的方法。通常选择固定时间(我们是每天早上 10 点 10 分开),以养成团队工作习惯来避免组织成本。站立会议要尽量的短,通常控制在 15 分钟以内,选择站着开会,也是让大家有更大的预期快速结束。

站立会议主要是为了沟通,以及发现潜在可能的问题,在站立会议上,团队成员每个人要讲 3 句话:

  1. 我昨天做了什么
  2. 我今天打算做什么
  3. 我遇到了什么问题

通过这 3 句话来达到高效沟通的目的,对于会上提到的问题,通常是下来相关人员自行解决。

站立会议通常能够发现项目进展的状态是否顺利,从而尽早采取相应的措施。时间较长的 Sprint 可以配合燃尽图,更方便地审视项目进展速度。

评审会议

Sprint 评审会议在 Sprint 结束时举行,用于检查计划中的工作,哪些完成了,哪些没有完成。在我们的实践中,我们会让开发的同事演示自己所做的功能,然后 PM 会看这个功能是否达到了要求。

回顾会议

回顾会议是开发团队检视自己,发现团队运转中的问题,并且定制游戏规则的过程。通过对前一个 Sprint 中的人、关系、过程、工具进行检视,团队成员能够总结出做得好的,和做得不好的。进而制定一个改进的方案。

回顾会议是 Scrum 创建 “自组织” 团队的关键,它将团队自我改进变成了一个例行的会议,在这个会议中,讨论的都是大家对该游戏的感受,包括好的和不好的,最终大家为了玩得更爽,就会发扬好的,努力避免不好的,成为一个能够自我进化的集体。

需要注意的是,回顾会议不应该成为吐槽大会,大家应该本着发现问题,解决问题的态度来讨论。例如:如果在回顾会议仅仅是抱怨产品老是改需求,或者抱怨时间不够,而不提出解决方案的话,是非常不好的。

提出问题是容易的,麻烦的是提出解决方案。我们的老大郭常圳提出了一个办法,即我们思考:“如果再来一次,我们能不能做得更好”?如果我们发现,如果再来一次,由于客观原则,我们可能仍然无法避免同样的问题,那么我们就选择坦然接受而不是抱怨。

因为很多时候本来就没有完美的、没有任何问题的解决方案,这就像软件都有 Bug 一样,如果 Bug 不可避免,我们就选择发现的时候尽量修复而不是编码的时候避免。

框架图

下图介绍了 Scrum 的整个框架:

一些问题

有什么辅助 Scrum 的工具?

我们使用的是 Redmine 的 Scrum 插件来开相关的 Scrum 会议。我们 Scrum 的回顾会议总结放在内部的 Wiki 上。也有团队喜欢直接用白板 + 便签来完成 Scrum 的相关会议。像 JIRA 一类的专业项目管理软件,也都支持 Scrum。

游戏超时怎么办?

游戏超时通常就意味着游戏结束。在 Scrum 这个游戏中,团队成员不接受 Sprint 延期。所以不管有没有完成所有任务,评审会议和回顾会议都需要按时开,没有完成的任务需要进行仔细讨论,分析其原因到底是什么,从而在下一轮 Sprint 中尽量避免出现同样的问题。

开发团队自己挑任务,会不会造成项目进度很慢?

通常情况下不会。如果我们真正把 Scrum 做好,大家能享受到 Scrum 带来的各种好处,例如团队每个人都能参与决策团队做事方式,每个人都能积极的追求效率,而一次次成功的 Scrum,带给大家的成就感也是巨大的。

好的 Scrum 执行还能保证团队不会随意加班,我们已经很久没有周末加班了,平时晚上大部分时间也都能做到按时下班,这对于互联网公司来说,几乎是不可想像的。

不加班只是一个附属品,最重要的是按时发布产品,我们创业 2 年多来从来没有延期发布过产品。这样使得我们的运营推广计划能够非常有序地执行。

需要强调的是,不加班并不是代表我们的工作轻松,通常情况下我们的 Scrum 安排还是比较紧张的,因为我们都想创业时跑得快一些。不加班也不是我们的原则,我们的原则是按时发布产品,所以当有一些特殊情况产生时,我们也会适当的加班。我们只是不把加班当作一个常态的工作方式,因为我们认为工作效率比工作时长更为重要。另一方面我们认为创业是长跑,保持良好的发布节奏已经非常好了,长期加班造成的身体懈怠可能会造成工作效率的损失。

Scrum 适合所有团队吗?

首先 Scrum 是非常适合程序员的,因为程序员天生就不喜欢约束。Scrum 的 “自组织” 团队的思想很容易让程序员感觉到自己是团队的主人。另外 Scrum 是非常反会议的,4 个会议都严格地规定了时间长度,所以可以让程序员有充足的时间花在编码上。Scrum 也是比较反需求临时变更的,由于 Sprint 周期短(我们才一周),所以变更可以根据重要程度放到下一个 Sprint 中。

Scrum 非常强调团队作为一个整体来做事情,所以并没有刻意地去评估每个人具体的工作量。这需要团队每个人都比较自觉。当然,由于强调透明和检视,所以团队内如果有人懈怠的话,团队里其他人是很容易发现的。

所以,如果你的团队人数在 10 人左右,又能保证团队是一个整体为项目负责,那就有了尝试 Scrum 的基础。

为什么很多公司用不好 Scrum?

Scrum 指南里面也提到,Scrum 是 “易于学习,难于精通的”。所以 Scrum 本来就比较难做好。我感觉到几个比较容易出现的问题是:

  1. 团队里面有人不信 Scrum 能比以前的软件开发方式更好。游戏规则使终是游戏规则,如果有人不想玩游戏的话,游戏玩起来就没有那么愉快了。真正想做好 Scrum 就得认真学习 Scrum 指南,然后努力遵守 Scrum 的规则。只有当大家都努力玩这个游戏时,才能享受游戏的乐趣。

  2. 随意更改 Scrum 的规则。例如我以前在有道的团队就把 Scrum 的每日站会改成了每周二,周四开一个坐会,开会的方式也变成产品经理询问进度,各个技术人员汇报的方式,会议一次要开半个多小时。这一下子就把每日站会做得变味了。

  3. 难以组建团队。之前说过像百度这类大公司,其公司文化不是一朝一夕形成的。Scrum 的工作方式要求大家都为项目完全负责,而很多传统公司按职能来划分团队,例如 PM 团队、客户端团队、前端团队等,这会影响 Scrum 的执行。

Scrum 是终极大招吗

Scrum 不是银弹,它并不能解决所有问题,实际上,很多时候它根本不提供解决问题的方法。Scrum 本身只是一个框架,通过这个框架,我们更容易发现项目运行中的问题,通过定期的回顾会议来解决问题。

结束语

本文旨在通过介绍 Scrum 的核心思想和基本框架,吸引大家了解 Scrum。要实践 Scrum,还是需要进一步的学习才行。欢迎大家详细阅读 《Scrum 指南》,然后尝试使用 Scrum 来让自己每天的工作变得轻松愉快。

PS:我们的公司猿题库创业两年,做在线教育方向,不久前顺利拿到了 1500 万美元的 C 轮融资。我们现在很缺人,也欢迎大家加入我们,和我们一起玩 Scrum 游戏,感兴趣的可以看:职位介绍

愿大家玩得开心~

CATALOG
  1. 1. 前言
  2. 2. Scrum 是游戏规则
  3. 3. Scrum 是基于经验的
  4. 4. Scrum 的三大支柱
  5. 5. Scrum 的基础游戏规则
    1. 5.1. 角色定义
      1. 5.1.1. 没有子团队
      2. 5.1.2. 强调平等
      3. 5.1.3. 游戏人数规则
      4. 5.1.4. 游戏时间
    2. 5.2. 游戏玩法
      1. 5.2.1. 计划会议
      2. 5.2.2. 每日站立会议
      3. 5.2.3. 评审会议
      4. 5.2.4. 回顾会议
      5. 5.2.5. 框架图
    3. 5.3. 一些问题
      1. 5.3.1. 有什么辅助 Scrum 的工具?
      2. 5.3.2. 游戏超时怎么办?
      3. 5.3.3. 开发团队自己挑任务,会不会造成项目进度很慢?
      4. 5.3.4. Scrum 适合所有团队吗?
      5. 5.3.5. 为什么很多公司用不好 Scrum?
      6. 5.3.6. Scrum 是终极大招吗
  6. 6. 结束语