这是一篇敏捷实践者对 Scrum 的吐槽

众所周知，Scrum 是一种敏捷实践，很多团队在敏捷转型时都采用了它，但是在我看来，Scrum 并不那么敏捷，甚至它提倡的有些价值观和做法是有悖于敏捷原则的，所以本文我会讲讲 Scrum 到底存在哪些问题？

首先需要说明的是，我在本文中提到的 Scrum 是由 Ken Schwaber 和 Jeff Sutherland 定义的，并遵循“ Scrum 指南”方法论。

最近，我所在的团队开始采用 Scrum，并以两周为一个周期安排工作。亲身实践之后，我觉得 Scrum 本身就是个问题，在我看来，Scrum 在实践中并不敏捷，也不灵活，有些人是 Scrum 的忠实追随者，在实践中坚持按照他们认为的 Scrum 字面意思去做，严格遵守“两周”这个时间。

“每日 Scrum”和“冲刺”

Scrum 是什么？“Scrum 是轻量级的、易于理解的、难以掌握的。”我觉得难以掌握就是 Scrum 最大的槽点。我们来看一下它的基础术语：“每日 Scrum”和“冲刺”。

在我看来，每日 Scrum 上，都是一群职场老油条在互相推诿，希望对方能够完成工作。相比来说，我更喜欢每日站立会，同样是同步每天的工作以及之后计划，但是方式却没有那么激烈、咄咄逼人。

当你加班加到怀疑人生的时候，你的领导可能会告诉你“我们需要更快地冲刺”，然后以两周为周期，安排工作计划，希望产出更多的产品。在我看来，这真的是一种伟大的管理方法，能够最大限度地提高员工的加班时间，而更令人惊奇的是，我们并没有任何一个联盟来反对这个情况。我自己认为，需要在一周 40 个小时的工作时间之外处理的事情都应该是罕见的紧急情况。

Done

“Done”也是 Scrum 中的一个关键术语。首先，“Done”的要求是“执行工作的人和检查增量结果的人必须对‘Done’有一个达成共识的定义”。这个过程就会引发长时间的讨论，而且“Done”的增量也是不好界定的。

“Done”和两周冲刺结合在一起，常会发生这样的对话：

“生一个孩子需要 9 个月时间。”

“你必须把这个过程分成两周的增量，这样我们就可以在每两周的 sprint 评审会中展示那些‘Done’的。”

更经典的是：

“起草这份文档需要 3 个月的时间，因为我们需要在设计就绪时把它们加进去。”

“那么你必须把整个文档分成两周的增量，以表明我们始终有一个完成的文档，随时可以交付。”

“但它要到最后才能交付，为什么要假装？”

我完全同意每个任务都应该有一个“Done”的定义，但是定义应该是与任务相关的，确定实际做成什么样算是“Done”可能是需要完成的第一个任务。弄清楚什么是“Done”并不容易，因为可能客户也不知道“Done”是什么样子。

Time Box

在 Scrum 实践中，大家总是试图想把所有的事情放在一个时间框中，以便能够一起完成。虽然时间框的长度是可以更改的，但是大家普遍是会选择两周。这个阶段遇到的问题是，事情完成的时间并不一定，以两周为周期可能并不适合，应该随时发布已完成的特性。

依我之见，Scrum 不是敏捷，它是一个为期两周的地狱瀑布。

Scrum Master

什么是“Scrum Master”？Scrum Master 是 Scrum 团队的领导者。在我看来，Scrum Master 实际上是剥夺了项目管理能力的项目经理。好的领导应该放权给团队，但是当我们需要完成一些紧急的、意料之外的事情，项目经理有权力做出改变，把这些事情搞定。

而 Scrum Master，他只能“温柔”地向管理层解释，这个 Sprint 的工作已经确定了，不能改了，拯救这条船的机会将会出现在一周半后的 Sprint Review 会议上，在此之前，你的双脚必须得忍受这些不舒服的海水。

Formal Events

Scrum 定义了四个正式的活动：“冲刺计划”、“每日 Scrum”、“冲刺评审”和“冲刺回顾”。虽然我很喜欢这些基本概念，但我不喜欢大家同时花费大量的时间来进行这些活动。我不喜欢开会，更不喜欢无效率的会议。

为了直接确定时间框，“冲刺计划”提供了各种各样的方法来计算某件事需要多长时间。这简直就是在浪费时间，在事情还没开始的时候，就在猜想未来两周的工作计划，而且还要为了适应这两周的时间框做出调整，实在是荒谬。我甚至听说过，有些团队为了配平冲刺计划会往里面增加一些不太重要的任务。我认为任务应该按照轻重缓急来安排，而不是按照时间来安排。

每天站立会真的是个好主意。但“每日 Scrum”则不是。

按既定的时间去评审正在做的事情是一个非常好的主意，但是要求每件事情在每次评审时都已“Done”不是一件好事情。

冲刺回顾，并不需要每次冲刺都做。当有一些事情想要特别弄清楚，决定下一步如何改善时，才需要做冲刺回顾。

Team

在 Scrum 中到处充满着“团队”的概念：一切都要由团队掌控，团队要同甘共苦。

我一直认为应该要承认个人努力，做出努力的个人应该得到赞扬，而 Scrum 在很大程度上违背了这一信念。我相信团队成员应该互相帮助，我也相信一个团队作为一个团队是成功的。但是我不喜欢用表现好的团队成员为表现差的团队成员遮羞。这么做，无非是让那些表现出色的团队成员很快到另一家公司工作，而你手里只剩下那些不思进取的团队成员。

必须为了降低团队成员离开的风险（将总线因子增加到 1 以上）做些什么，交叉培训是种很好的方式，但它带来的帮助也很有限。很多组织把细节塞进看板中，我听说这么做是出于这样的原因是新人来了，他们可以知道该怎么做。但把备注写得清清楚楚也是要花费的时间的，你需要在两者之间做出权衡，我个人就经常弄不清两周前自己写的一些备注。

我也反对每个团队成员对所有事情都应该具有平等的投票权。如果我雇佣了一个有三十年工作经验的专家和五个刚从大学毕业的人，我希望这个专家能提供专业的指导，而不是按那些新手的投票来做。我想我的结论已经很明显了，我真的不喜欢“自组织”，因为我看到“自组织”带来了无休止的争论。无论我在哪里，看到的只是团队以相当快的速度拆分重组，却从未看到“自组织”带来任何投资回报。

另外，我还想到了一点，Scrum 被刻意创立为无领导的，因为他们当时遇到的领导都很无能，没有很好地发挥作用。我认为我们只需要培养更好的领导者，而不是完全放弃这个概念。军队的建立完全基于领导者和领导力，在需要灵活的时候可以非常灵活，只要给予自主权就可以当场做出决定。或许作为一个行业，我们应该更多地研究怎样是一个好的领导者，而不是试图发明一种方法，故意把领导者和领导力作为一种要剔除的特性。对于我来说，这似乎完全就是抛弃了舵手。

可工作的软件

Scrum 是基于每两周发布可工作的软件。对于一些项目（Web 前端）来说，简短、一致的节奏很有效。对于其他项目（如航空电子设备），它根本就行不通。我参与过的大多数项目都不符合这种模式。通常，每周展示一下进度是可以做到的，但我做过的项目却极少有每两周就可以交付的。“看，这是起落架，它现在已经能用了，你要交付吗？”请注意，我喜欢尽早就有一版可工作的子系统，然后进行成熟完善，以及添加更多的子系统。而我认为可工作的软件模型的真正问题是，它忽略了计划和文档。充其量，也不过是有个类似于计划冲刺的东西。如此，你会有两周的时间来做计划，然后你就可以把这些苦差事抛在脑后了。两周后，没什么计划，没什么文档，只有编码，编码，编码。虽然我坚信编码是 最终 的设计步骤，但我并不认为编码是 唯一 的设计步骤。几乎每个任务，我都希望在编码之前看到一些设计。

在编写代码之后，你需要编写足够的文档，以便在需要更改或重用代码时，使修改者至少可以弄清楚从哪里开始入手。事实上，对于“我们需要写什么文档”，我有一个经典回答：如果你下次不能轻松地理解这段代码，那么就把你理解到的东西都写入文档。

事实上，我发现，没有高层设计或架构是许多开源项目都存在的一个主要问题，因为这一问题使用户几乎不可能弄清楚如何使用。文档可能对每个 API 都有充分介绍，但仅仅如此你是不知道什么时候为什么使用什么 API 的。

Hack and Hope

使用 Scrum 经常会出现缺乏书面设计的情况，我把这种软件开发方法称为“hack and hope”。它不是由一个预先想好的整体计划来指导工作，而是由一个“冲刺计划”来指导团队摸索着做，并寄希望于能这样走到最终。在这种工作方法中，你只需要考虑两周左右的工作，没有必要去思考几个月后的工作。但最终需要某些资源时（例如资金、服务器、软件、防火墙端口开放等等）你会突然发现，因为没有做充分的基础设计，正常的审批流程却成了阻碍。

替代方法：RAD Rapids 修订版

我喜欢使用自己的方法，称为快速应用开发急流（RAD Rapids) 。它源自于 20 世纪 90 年代末的多种技术，甚至比敏捷还要早。我在 2001 年写下了第二版论文。它稍晚于 Scrum 的提出，几乎与敏捷宣言的发布同时。

快速应用开发急流（RAD Rapids) :

https://gerhardb.org/paper-2001-rad-rapids

你可能会说，这篇论文实际上并没有给我提供一个方法论！这是我深思熟虑之后做出的选择。我希望人们从所有的方法中挑选出最好的策略、技术和程序（TTP），并将它们应用到你的具体环境中。我认为介绍一种单一的方法论是徒劳无益的，有两个原因：

第一，它很快就会过时，我不太可能让它永远跟得上时代。当时，我意识到以前含有实际方法论的论文过于局限，于是就有现在的 RAD Rapids。

第二，如果你介绍了一种方法论，追随者将专注于按照所规定的方法执行，而不是按照它的原则在当前项目中灵活应用。所以我抛弃了方法论，保留了原则。

自 2001 年以来，许多新的 TTP 在软件开发方面都很有帮助。在我目前的项目中，我发现以下几个带来的帮助最大：

• 每日站立会 ——从描述上来看非常像每日 Scrum。但 我们在召开产品的站立会时，产品所有者通常都会出席。首先，我们在项目的总体方向上得到了正确的指导。其次，我们的产品负责人成了障碍清除大总管。所以我们有着极高的透明度：每天！但是，每天的站立会必须有严格的时间限制（最好不要超过 15 分钟）和话题（只讨论影响两位以上参与者的事情，那些只涉及两个人的问题可以在会议之外处理）。

• 看板 ——有一个优先级列表是非常有用的。我们没有限定时间，大家在完成当前任务后就会把它从清单上拿掉，然后再去按优先级领取任务。对于这个 TTP，我还只是个新手，但到目前为止我很喜欢它。

• 每周展示和讲述 ——没有时间限制，我们每周评审的目的和冲刺评审是一样的。它的一个 重点是“展示和讲述”，成员在此展示显著成就。即使某些事情还没有最终完成 ，实际上也能充分地展示出当前的进展，让大家清楚项目正在向前推进，从而建立起自豪感和信心。团队成员自己进行展示和讲述，以所做的工作为自己赢得赞许。

原文链接：

https://dzone.com/articles/why-i-hate-scrum

译者简介：

冬雨，小小技术宅一枚，从事研发过程改进及质量改进方面的工作，关注编程、软件工程、敏捷、DevOps、云计算等领域，非常乐意将国外新鲜的 IT 资讯和深度技术文章翻译分享给大家，曾翻译出版《深入敏捷测试》、《持续交付实战》。