Issue #8 - Scrum is a Cancer

很多年前一位经验丰富的前辈给我介绍了敏捷开发，让我开始了解 Scrum，后来的工作中也一直是在使用 Scrum 来开发产品。Scrum 有很多规则和会议，每天有站会、每隔几周有 Retrospective 会议，然后还有 Sprint planning 和 grooming。有时候这些会议确实需要花费不少时间，也有人会觉得这些事情都是在浪费时间，还不如多写几行代码。我也会有这样的疑问，Scrum 是否真的需要严格按照这些规则来执行呢？

TL;DR

形式主义的 Scrum 或者敏捷开发确实是 Cancer，它会降低团队的效率。
Scrum 的核心在「验证产品价值。」
因为产品价值存在风险，所以要尽可能的降低成本（工时），所以要「快速交付」。
为了快速，我们要控制开发成本，于是有了 Sprint（最小交付周期）。
为了了解能否在 Sprint 内交付，我们需要评估成本，单位就是故事点。
为了评估故事点，团队成员都需要了解「需求」。
需求根源是问题，团队成员一起设计方案才能更好的理解交付物。
开发过程中总是充满变数，确保问题可以及时的提出。
当成本发生变动时，需要动态的调整需求范围。
记住，目的是为了验证产品价值，不是为了交付代码。

交付价值

简单来说 Scrum 只是一种软件开发的流程，「流程」显然不如「目的」重要，所以我们先抛开 “Scrum” 来谈谈软件开发本身。就软件开发的目的而言，显然不是为了「交付代码」给客户（如果是外包公司那就另说），而是交付「有价值的产品」。这里的关键是「有价值」的产品。

价值源于「交换」。软件的价值同样如此，从表面上来看，客户付钱给公司，对公司来说获得了商业价值；公司交付软件给客户，对客户来说获得了使用价值。那么问题就变成了如何界定这次的交付物是「有价值」的？这个价值应该由谁来界定？虽然交付什么产品/功能是由产品经理决定的，但产品经理实际上只是用户的代言人，最终决定交付物是否有价值的只能是「用户」（或者某些情况下是客户，在这里我们将其视为相同的意思）。

产品经理（或者是 Product Onwer，这里认为是同一个人）决定了交付物，即使产品经理很理解用户，但不能 100% 确定这个交付物就是满足用户需求的，也就是我们说的有价值，所以产品的价值在真正交付给用户之前，就像是薛定谔的猫一样，是不确定的。这种不确定性的风险，哪怕是产品经理在前期花了很长的时间，拉上设计师给客户演示设计，甚至可交互的 mockup 让用户亲自上手尝试，这种风险依然存在。Mockup 的问题在于用户并不是真正的在使用产品，而是再尝试，看起来可以解决问题，但当产品真正交付出去，用户每天都开始使用的时候，很多问题才会显现。

也就是说有一定的几率我们的交付物没有价值的，或者价值很低，而这种风险又无法完全避免，那么当风险发生时，我们应该尽可能的降低成本。这里的成本，就是软件开发的时长。降低开发成本并不意味着我们要交付一个半成品给用户，这虽然降低了成本，但实际上也增加了风险。我们需要做的是在风险几乎不变的情况下降低成本。

这就要提到产品开发中的另外一个概念 MVP（Minimum Viable Product，最小可行性产品），或者说 MVF（F for Feature）。显然用户并不是想要一个功能，而是要解决一个问题，这些问题可大可小，小问题直接解决就行了，基本上也没什么风险可谈，但是「大问题」往往很复杂，这种复杂的问题也不是一个两个功能就可以解决的，问题通常会涉及到上下游以及各种 Stakeholders，通常是一个完整的解决方案。这么说是没错，但请把它当作是「最终」要交付的产品。最终我们确实是要交付一个完整的解决方案，但没有人说我们只能交付一次。

假设我们最终要交付一个 120 分的产品，有两种交付方式，第一种是一次性交付（在我们辛辛苦苦开发了一年之后），风险自然是有可能用户觉得我们交付的产品就是一坨狗屎，只给了我们 0 分，那就不得不返工再来一次，但即便是返工，在花了一年调整，我们也很难保证第二次的交付就是 120 分；另外一种方式是我们分成 12 次交付，每个月交付 10 分，第一个月的交付同样可能会被用户认为是狗屎，但是没关系，只浪费了 1 个月，我们可以持续改进，那么怕是推到重来也都可以。（但你大概率不会真的交付一个 0 分的产品吧。）

这其实就是敏捷开发中所说的「持续交付」。除了能够降低风险发生时的成本，持续交付的另外一个好处是，在很短的时间内可以把产品交付给用户，虽然它很难用，只能解决非常有限的问题。而此时的一次交付还在开发中，对用户来说没有任何的交付物，也还不能解决任何问题。

持续交付表现出来的就是用户可以在很短的时间内使用产品，在完成第一次交付之后，用户就可以对产品提出改进意见，而正是用户的反馈，让产品的价值不断的提升。虽然大概率我们无法在 1 年内交付产品，但是 1 年之后，用户已经有一个还不错的产品在使用了。而一次性交付在会进行第一次交付，结果怎么还是未知数，而我们更喜欢确定性，不是吗。

总结来说：我们关注交付「有价值的产品」，而产品的价值由用户来界定，为此我们需要尽快将产品交付给用户，而要尽快交付，我们需要控制产品范围（MVP）。持续交付是为了尽快听取用户反馈，基于用户反馈来持续改进产品。无论你将这种流程称之为什么 Scrum、Lean、或者 Shape 都行，其核心都是一样，交付价值，而非代码。这里我们就继续称之为 Scrum 吧。

控制成本

这么来看 Scrum 可以理解为就是在控制成本，也确实如此，Scrum 并不能提升产品的价值，如果产品是一坨狗屎，使用 Scrum 并不能改变其狗屎的性质，最多变成了快速交付的狗屎。Scrum 能做的单纯的就是降低成本实现快速交付，因为快速交付，产品才能够快速的去验证「Product-Market Fit（PMF）」。

快速交付首先要定义什么是「快速」，一天、一周还是两周。实际上「快速」取决于你的开发 MVP 的周期是多少。Scrum 不仅仅要快速，还需要交付，理论上可以每天进行一个 Sprint，但如果没有实际交付，这种做法就失去了意义。我的经验是两三周是交付一个 MVP 比较合理的时间（Basecamp 内部的 Sprint 是 6 周）。对于新的团队，对于交付时间可能不好把握，因为 Sprint Velocity 还没有稳定，那么 2 周算是一个稳妥的选择吧，这个时间可以随着团队越来越熟悉，产品越来越清晰进行调整。

对 Sprint 的另一个误解是把 Sprint 等同于发布周期，虽然两周确实有关联性，但我更愿意将 Sprint 成为最小交付周期，即一个 Sprint 内至少要发版一次，你也可以多次发版，愿意的话每天发版都行。

软件开发中最大的成本就是开发的工时，限制 Sprint 的天数实际上就是在限制开发成本，准确来说是预算。Sprint 就好像规定了，开发预算只有 2 周，我们得看看 2 周后我们可以交付什么。也就是我们需要在每个 Sprint 开始之前就要做的 Planning。

Planning

Sprint Planning 实际上解决两个问题：

我们要交付什么？
我们能否在两周内交付？
如果不行，那么要缩小需求范围。

Planning 的一开始产品经理向团队宣布我们接下来一个 Sprint 的冲刺目标。如果是写 PRD 的产品经理，这个时候有点像是产品经理给团队阅读 PRD。我不喜欢 PRD（有人喜欢吗？），这个时候的重点就是对齐这个 Sprint 的交付物，也就是目标。产品经理对交付物有一个大概的定义，之后团队就要一起来 Shaping（细化）这个交付物。

定义范围

交付物是什么？它是一个解决方案。解决方案首先是从一个（用户提出的）「问题」而来，为了解决这个问题，产品经理给出了一个解决方案（也就是所谓的需求）。一开始我们之所以要快速交付，是因为我们无法 100% 确定我们的「解决方案」能否解决用户提出的「问题」，所以需要快速交付来获取用户反馈。言下之意，「需求就是有待验证的假设」。

条条大路通罗马。解决一个问题的方案可能不止一种，产品经理提出的方案未必是「最佳」的，这就是为什么团队需要对其进行「Shaping」。如果不考虑时间限制，那么永远都会存在一个「更好」的方案。所以我们需要一个时间限制，也就是在一个 Sprint 内，我们能交付的「最佳」方案是什么。

你可能听说过「第一性原理」，事实上这个过程就是我们寻找这个 original 的问题。如果你有用户和你一起参与方案设计，那么直接询问用户是最佳的方法，否则产品经理就是那个被询问的人。如果产品经理不理解这背后的问题，那么一切都免谈。

Mind the Gap

即使我们定义了 Sprint Goal，Shape 了解决方案，我们依然可能在交付的过程中出现意外。例如未知的技术问题，为了解决某个问题需要引入一项新技术，工程师以为很了解这种技术，但实际上有很多的「坑」，这个过程中总不可避免的会出现意外，所以我们经常会有一个「study」的任务，即工程师提前去研究清楚这种技术，写一个简单的 demo 出来。这个过程可能是 1 天，也可能需要 1 周，很多时候 Sprint Goal 无法达成也都是因为这个缘故。

有一些团队会在 Sprint 中引入 Cool-down period，我喜欢这个想法，Linear 中也恰好提供了这个设定。Cool-down 显然不是什么也不做，我认为这段时间让团队来进行 study，并尝试着写一些 demo 可以降低我们在真正进入 sprint 之后的风险。

评估成本

了解清楚「交付什么」只是第一步，我们还不清楚成本。假设我们的 Sprint（预算）是两周，那么接下来的问题就是我们能否在两周内交付，或者说两周内我们能够交付什么？

那么接下来就要评估这个方案（Issue, Story, Task, whatever），这个是时候实际上就进入了工程的范围，工程师把需要做的 Task 拆解为 Subtask，然后评估每个 Subtask 需要消耗的故事点（Story Point），然后将所有的故事点加总就得到了整个方案需要消耗的点数。理想情况下，工程师在每个 Sprint 能够消耗的故事点是相同的，我们称之为 Sprint Velocity，就叫它总点数吧。

方案评估完成，如果方案的点数小于等于总点数，就意味着团队可以在这个 Sprint 交付方案（当然风险总是存在）；也可能出现方案的点数大于总点数，意味着无法在 Sprint 内交付。这个时候你有两种选择：1. 延长 Sprint 的天数，加到 3 周或者 4 周，要是你愿意你就可以无限延伸下去，但是别忘了快速交付；2. 缩小方案范围，也就是 MVP。显然我们更推荐后者，因为它也符合我们前面提到的快速交付和交付 MVP 的理念。

在评估的点数的时候工程师拆分了 Subtask，每个 Subtask 都是非常细粒度的任务，当我们在缩小范围的时候一方面可以从 subtask 入手，看看哪些 subtask 不做也不会影响用户「使用」，例如一些提升体验或者性能的 subtask，那么交付物可能体验并不好，但至少是可用的。将这些 subtask 移出 Sprint，直到整个方案的点数小于总点数。

这并不是一个简单的工作，从介绍需求（问题）到拆分 subtask 再到评估点数，整个团队可能花费半天的时间来完成。所以看起来确实是一件「浪费时间」的事情。所以我们还是回到核心，我们需要交付「有价值」的产品，如果我们可以非常确认现在做的东西就是有价值的，那么什么 Sprint, Standup, Story Point 都不重要，做就是了。

软件开发的核心是「交付价值」，而 Scrum 的大前提是「你无法 100% 确定你的交付物是有价值的」，于是你需要缩减成本来进行快速验证。如果你可以确定交付物 100% 有价值，那么就不需要 Scrum。当你确认需要 Scrum 之后再去思考 Scrum 的那些规则和形式是否「助于快速交付」。如果不理解这层核心，只是跟着 Scrum 形式来开发软件，那就和普通的「瀑布流」没有区别了，只不过是两周一个迭代的瀑布流。

站会、故事点这些工具都是用于控制成本，如果一切都很顺利，那么站会同样不需要，站会是用来主要是用于提出 Risk，如果一切都是顺利（On track），根本不需要开会，大家埋头写代码就好了，到期按时交付。现实却总是充满变数，而站会就是让所有人都知晓这种变数，尤其是「影响成本」的变数，如果成本超出预期，那么可能需要缩小需求范围，那么交付物与最初定义的可能会有所不同，而这些是 stakeholders 所关心的，这些问题也就是在站会上提出，让信息尽可能的透明。

Santiago 评价说 Scrum is a cancer，列出了 Scrum 几宗罪：

评估故事点是浪费时间；
Standup meeting 浪费时间；
同样的问题 PM, PO, SM 都会问一遍，浪费时间。

必须得承认，如果只是机械的遵循 Scrum 的规则，确实会出现这种情况，Scrum 里面的所有规则都是为其目的服务。