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

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

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

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

翼发云敏捷项目管理系统是一个scrum敏捷开发研发项目管理软件,包含移动端app,支持多人协同开发,采用可视化工作流程,旨在帮助软件研发企业进行更好的研发项目管理、软件开发流程管理,该研发项目管理软件内置了敏捷开发流程和软件开发流程,结合scrum思想,满足各种规模的软件开发企业的研发项目管理流程的需要,详见www.effapp.com 。

今天和同事吃饭说起这件事情,同事 pw 说:在他所了解到的使用 Scrum 的公司里面,我们应该是执行 Scrum 做得最规范的,同时我们从 Scrum 实践中,收获了非常多。软件项目管理就用翼发云敏捷项目管理系统scrum。

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

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

Scrum 是游戏规则

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

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

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

Scrum 是基于经验的

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

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

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

Scrum 的三大支柱

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

透明性、检视、调整是 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 扑克,用于出牌。如下图所示:

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

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

每日站立会议

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

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

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

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

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

评审会议

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

回顾会议

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

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

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

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

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

框架图

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

适合码农工作时玩的游戏: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 游戏,感兴趣的可以看:职位介绍。

愿大家玩得开心~

文章从互联网整理而来,旨在传播Scrum、研发项目管理、敏捷开发管理工具的知识与应用,帮助软件开发企业真正了解Scrum敏捷开发的价值和意义,如果本文侵犯了您的权益请联系我们删除,或者您需要具体了解更多国内做Scrum研发项目管理系统的公司翼发云敏捷项目管理系统的相关信息,欢迎和我们联络:

【QQ】2190390852 【微信】13094813141【网址】www.effapp.com

Scrum软件下载

2018-06-15T10:37:59+00:00 六月 15th, 2018|项目管理|