昨天遇到一个来自微软的面试者，在面试的最后，我简单介绍了一下我们团队使用一周一次的 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 游戏，感兴趣的可以看：职位介绍。

愿大家玩得开心～