“满身漏洞”的Scrum

Posted 2021-04-25 敏捷传习录

虽然每次我们都说“敏捷没有银弹”，但奇怪的是，Scrum 在一定程度上却成为了敏捷银弹的代名词。甚至在某些场合Scrum 已经和敏捷画上了等号。当别人问你是否在用敏捷的时候，潜台词是你是否在用Scrum。

这种“嘴上说不要，身体却很诚实”的割裂行为，让我产生了一点兴趣来聊一下Scrum 这个框架，并稍稍就Scrum 这个框架的现状做一些有趣的讨论。

在开始这个话题之前，我想请大家看一下这张图，基本上是针对Scrum 展示最到位的一张图。

1-1 Scrum At a Glance

对于Scrum 到底是什么，怎么用，我在这里就不做赘述了。如果大家有兴趣，可以去下载Scrum Guide，然后自行阅读。在下面的内容中，我默认大家都已经对Scrum Guide有过阅读。

Scrum 被诟病的几个点

Scrum 被诟病的还挺多，我大概总结了一下，有这么几个点：

1. 需要新的角色出现。不论是SM还是PO，亦或是没有title的研发人员，都跟现有组织架构不太一样；

2. Scrum 限制太多（这里主要是时间盒），导致没有办法放开手脚去做，在遇到紧急情况时，无法快速响应；

3. 用户故事很难写很难拆，且有很多时候研发人员不理解用户故事，且也无法进行详细的时间估算，无法排期；

4. 我们每次迭代都不能做完所有的工作，导致下次继续做

5. 跨职能团队、T型人才可遇不可求，团队工作还是各自做各自的；

6. 站会根本不能解决问题，会后再也没有人追踪会议上的那些问题；

7. 计划会很难开，且开完计划会后，依然有很多不确定性，团队都很吃力；

8. 敏捷嘛，想变就变，连流程都不需要了

9. 评审会客户对我们不满意，领导很不爽，要求我们尽善尽美完成后再给客户演示

10. 回顾会浪费时间

当然，实际的槽点肯定不止这10条，这只是我精挑细选出来的10条，但是已经能足够表达出大多数团队对Scrum的不满，其中包括了领导、团队以及团队之外的人对Scrum 的评价。要不是我对敏捷略懂，真的是可以劝退我使用Scrum 的想法。

Scrum 真的如此不堪？

真相 VS 槽点

与上面槽点相对应，我们来分别针对槽点做一些回应。

1. 新角色出现的目的很简单，希望可以在流程中分工明确，确保适当的人做适当的事情。这个过程中必然会出现水土不服的情况，这是从瀑布转型到Scrum 中必然会经历的。这点没有办法反驳，因为的确存在。这点确实一定程度上增加了实施Scrum 的难度，主要是组织接受度。

2. Scrum 约束是有的，与Kanban比确实多了不少，但比RUP、XP等是少了不少，具体可以见图1-2。这里有个有趣的点，即使Scrum 约束比XP 更少，但是吐槽Scrum 的还是远比 XP 的多。这点后面说一下我的观点。

3. 用户故事并非Scrum 必选部分。虽然用户故事已经成了敏捷的标配，但是如何编写用户故事本身是游离在所有敏捷框架、流程之外，这个锅并非Scrum的问题。你换个流程也大概率会遇到；

4. 迭代工作完成不了，请严格遵照Scrum 的标准做法；

5. T型人才基本上只能靠自己培养，与Scrum 本身无关；

6. 团队成员参与度问题，仓筒效应严重，各自做各自的事儿，没有互相帮助的意识

7. 计划会中会后也会残留部分不确定性，以实现渐进明细。不能接受不确定性还是来自于过去的管理方式的问题；

8. 这个是典型的“中华田园敏捷Chinese Garden Agile”的锅

9. 管理水平以及与客户立场不对等所导致，大概率是销售的锅；

10. 回顾会做不到，99.99%是团队信任度不足，导致回顾会都是废话

1-2 规范性对比

回顾上面10个问题，你会发现，基本上没有槽点是吐在了Scrum 流程上，更多的是在“如何落地”上，这说明了什么？

Scrum 的真相

如果你对照敏捷软件开发宣言（以下简称宣言），与其对应的十二项原则，你会发现Scrum 是可以契合绝大多数的条目，包括但不限于：

个人互动 高于 流程和工具

可用的软件 高于 详尽的文档

https://agilemanifesto.org/iso/zhchs/manifesto.html

我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。

欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。

经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。

业务人员和开发人员必须相互合作，项目中的每一天都不例外。

激发个体的斗志，以他们为核心搭建项目。

提供所需的环境和支援，辅以信任，从而达成目标。

不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。

可工作的软件是进度的首要度量标准。

敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。（这条无法看出来）

以简洁为本，它是极力减少不必要工作量的艺术。

最好的架构、需求和设计出自自组织团队。

团队定期地反思如何能提高成效，并依此调整自身的举止表现。

https://agilemanifesto.org/iso/zhchs/principles.html

因此你会发现，Scrum 可以说是最能体现出宣言的敏捷开发框架。宣言太过于抽象，而其配套的十二项原则太过于松散，而Scrum 通过一套流程将其串联起来，在整个流程中逐步体现，从而帮助我们更好的践行宣言和其原则所要求的做法。

当然你可以说Scrum 出现在前（1995正式通过论文的方式面世）而宣言（2001雪鸟滑雪场）出现在后，这么说是否有点牵强。

嗯，有点。但是你不能否认Scrum 的确是在宣言与原则的各个方面，近似完美的进行了诠释，这点是客观事实，无法改变。

因此，我们可以自豪的说，如果你真的将Scrum 用起来了，那么你就已经满足了绝大多数的宣言和原则的要求，你已经在进行敏捷了。

那，问题出现在哪里？

既然Scrum 这么好，那么为什么依然有人对Scrum 充满了那么多的怨言和槽点？问题到底出现在哪里？

还是让我们回到Scrum Guide这份官方白皮书中，明明白白写了Scrum的三个特点：

Scrum is:

· Lightweight

· Simple to understand

· Difficult to master

https://www.scrumguides.org/scrum-guide.html#definition

看到没有，人家官方都说了这玩意是“难以驾驭”的。所有难以驾驭的工作，难免都会被各种吐槽，不是么？毕竟

世上只有两种东西，

一种是被骂的，

一种是没有人用的

本文作者说

当然我们的目的不是要将这个槽吐回去，而是希望可以更加根植于实际场景，找到具体的难点，然后才能更好的改进某项事物。

所以下面，让我们来好好分析，到底是Scrum 哪些特征，导致其难以驾驭呢？

真正导致Scrum 难以驾驭的原因

人的问题

虽然并不想把它列为第一项，但是实在找不到其他可以放在第一项的了。

敏捷从那句“个人与互动 高于 流程和工具”开始，人员能力就已经注定成为最核心的因素，没有之一。也直接奠定了敏捷需要高级人才的基调。

在绝大多数的情况下，这个说法是对的。敏捷本身就是“利用更复杂的系统（人员与团队）来对抗复杂系统（产品研发）”，人员能力的重要性不言而喻。这里面的能力包括硬技能与软技能两块。

硬技能不谈，所有与完成工作直接相关的、具有输出物的都属于硬技能。软技能相对而言不明显，但是对敏捷成败也至关重要。包括但不限于沟通、协作、创造力、主观能动性等各方面。

恐怕到这里你也就看出来了，人的问题一般不会是硬技能的问题（这部分可以通过流程或者工程实践来弥补），而更多是在人的软技能方面，这决定了如何配合、协调、从而达到1+1>2 的要求。

很多团队，就栽在了人的问题上。

信任的问题

这个本身也是人的问题，但是我还是喜欢把它单独拎出来。因为实在是太重要了。

信任这东西，是一种很奇妙的东西，它可以直接击破你所谓的理性思考，让你可以义无反顾相信一个人，甚至不惜损害自身的利益。

这在理性上是不可理解的，但是在敏捷中是一定需要的。这决定了你是否可以形成所谓的自组织团队，并与这个团队一起前进，变得更加美好。

人性本就是趋利避害，信任却告诉我们不要相信你暂时看到的，而是需要相信你的队友是为了大家都好。这是什么精神？这本质是个人性挑战问题。很难。

真的很难。

但我们依然需要想尽一切办法让团队信任我们、让团队互相信任。只有这样子，我才能相信“队友可以做的跟我一样好”，才能相信“我向队友求救，他们会救我”，才能相信“我告诉队友我的缺点，他们会帮我改进”。如果这点都做不到，就不要谈所谓的自组织团队，也不要谈所谓的透明化。成天都想着如何防着别人，这种环境下的敏捷，闻所未闻。

一次性交付 VS 持续交付

从客户角度来说，一次性交付一定是更好的，因为可以让客户在一瞬间拥有诸多的能力。但也许是真的太“满足客户要求”，现在的客户是被宠坏的，他们希望可以一次性获得所有他们“真正”想要的功能。一旦没有满足，立马就会对这个产品展开嘲讽、吐槽，甚至会带动新一轮的抵制活动。

这一方面是因为我们与客户的信任度没有建立起来，我们无法用刷脸的方式来让客户相信我们可以逐步的交付好的东西，另一方面也是因为客户被宠坏了，无法接受“延迟满足”这种交付方式。因此这就形成了一个怪异的反馈环，我们每次都希望一次性满足客户需求，但是每次大发布后客户都不满意，进而加强了客户对我们的不信任，然后下一次发布前，客户又给我们更苛刻的要求，而后我们会在更大的压力下搞砸，然后又一次加强了客户心中“你们不行”的认知。

1-3 恶性循环

如何破局就颇具意味。

一般我们会认为一次性给客户很多东西，这里面一定会有“一部分工作”客户会满意的。但殊不知这种做法，有以下几个肉眼可见的问题：

1. 成本过高。这个不谈了，太明显。开发100个给用户挑出来10个可用的，另外90个成本需要平摊到10个客户满意的交付物中；

2. 客户信任度下降。试想“你给我2个东西中，有1个可用”和“给我100个东西，10个可用”两种情况，如果你是客户你会觉得哪种更好？别忘记了，对于客户的初始期待而言，“满足”要求是基本期待，如果你“不满足”我反而会记很长时间，因为这不是我的预期。所以当你给了用户一大堆东西，客户只能挑出来寥寥几件可用的时候，客户的反应不大可能是“还不错，还有几个能用的”，较大概率是“这么多东西，就这么几个可用？你们在搞什么？”

3. 团队信心下降。做了一堆被用户评为垃圾、不可用的东西，给谁也不好受。

4. 客户参与度降低，前期无法建立正确的预期，且无法得到尊重的感觉。进一步又降低了满意度。

因此增量交付就成了破局的工具。从前期将客户作为开发的一部分，将过去“我为你服务”转变成“我们一起完成交付”的方式，尽早让客户参与到产品的设计、反馈工作中，并且进行持续反馈，从而做到一个“大家都满意”的产品。只有这样我们才可以更好向着对客户有价值的方向前进，降低我们研发成本的同时，也提高客户满意度。

但这里有一个破局点需要找到，那就是“如何改变客户对分批次交付”的接受度。就我们过去的经验看来，所谓客户不接受分批次交付，绝大多数是脑补出来，另一部分是真的交付出来的结果客户无法使用。对于前者，我们需要尝试的是通过沟通、展示的方式，让客户建立分步骤交付的信心；对于后者，我们能做的，就是下一节需要说的，PO 技能问题。

PO 技能不过关

被我放到第二位的，是PO 技能不过关。

我一直将需求管理视作能否实现敏捷的重要因素之一。需求管理不仅仅确保了需求的全生命周期的管理，也包含了敏捷交付重要的概念——增量、迭代、适应性。

当PO 业务能力不过关，无法将业务进行原子化拆分，并统合成MMF这种概念时，基本上就注定了需求拆分的不确定性。需求过大、牵扯较多、边界不清晰，直接导致了“迭代结束无法交付可用功能”的结果，更不要说在这个基础上再通过适应性来进行迭代改良等工作。这又进一步的削弱了Scrum 可以带来的优势，最终“Scrum 毫无作用”继续喧嚣尘上。

这里至少包含了用户故事、用户故事地图、用户故事拆分、优先级排序、MMF 设计等方面，当然还必须包含专门的行业知识，否则上述所有的内容，PO 都不可能处理，毕竟这是PO 的基本要求。如果做不到这一点，PO 连如何将“相关方需求”写成“用户故事”或者其他形式都做不到，无法产生合理的Product Backlog（简称PBL），也就更不要说后续步骤了。

工程实践

工程实践我放到这里，主要原因是工程实践本身是一个锦上添花的工作。

先说一句很多做工程化敏捷工作的人不太喜欢听的。工程实践做不到的最大结果就是需要投入额外的人力进行测试、bug修复，进而导致交付速度慢。抛开是否敏捷、是否Scrum 而言，这并非不能接受，只是会慢一点。有了工程化，本质是从自动化、流程化来减少重复劳动以及尽早的暴露问题，从而可以在交付的过程中提升质量与速度，交付更多。

但工程实践也有明显的问题，就是如何实施。现有各种DevOps 、CI/CD工具一定程度上可以自动化的工作，这部分并不难，甚至已经有成熟的解决方案。但越往底层去，越接近于代码层的工程实践，就会更加繁杂，比如如何编写TDD，这是所有自动化中基础的基础。而这个能力并非一朝一夕可以养成，需要长时间的训练，以及业务层面的功能拆分（参见上面PO的部分），所以见效极慢，且前期有可能产生负的生产力。而多少公司可以接受这种行为犹未可知，因此在推动这部分工作中，我们经常能看到“在高层级上，各种工具做的飞起，看似一片繁荣，但是在底层代码以及最小业务单元上，根本不能看”的冰火两重天。然后更进一步就导致满足于表层的形式，而继续忽略底层的实践，最终再次形成恶性循环。

SM 能力不足

这个原因不用说太多，弄不明白Scrum 到底是干什么的SM大有人在，尤其是某联盟将认证授权给个人后，国内神魔乱舞的情形，一度让人眼花缭乱。我见过一些认证的SM 搞不明白计划会怎么弄的，我也见过认证的SM 主动表示回顾会没用的，更不要说各种一小时站会的SM。

行政管理者阻碍

之所以将行政管理放到这么迟才说出来，一方面是因为这个部分我们能做的很有限，另一方面也是因为其实这种阻碍是可以跳过去的。

说我们能做的有限，你一定懂的。在大部分没有经过专业的管理训练的管理者中，对“不确定”的避讳是超出你的想象的。而敏捷却利用不确定性来争取更大的收益，这在部分管理者眼中是不能接受的，因为输出不可预期。如果相关管理者再是一个典型的风险规避型的话，在各种行政手段上给与约束也就是预期之内的了。这种行为典型代表有以下几种：

1. 对敏捷合同的抗拒，主要来源于财务岗、通用管理岗

2. 要求明确的交付时间节点，主要来自于销售岗、通用管理岗

3. 时间倒排，主要来自于销售岗

4. 严格的研发准入门槛，主要来自于研发管理岗

5. 还有许多，不一一列举

说这种阻碍是可以跳过去的，原因是在于，你可以通过自己的能力，将开发团队进行黑盒化处理，真正领导关心的，并非是你到底怎么做，而是“在表面，或者汇报方面有没有按照SOP来做”，这就给了我们一定的操作空间，可以在我们的权力天花板上形成一个真空，将管理与团队隔离开，为团队创造一个可以运行敏捷的环境。对这部分有兴趣的，可以参照我的偶像Mike Cohn 的《Succeeding with Agile》（国内译名《Scrum敏捷软件开发》相关章节。

结论时间

到这里，结论就比较明显了。大多数吐槽scrum的人，他们的槽点并非是scrum框架本身有问题，而是Scrum落地难的问题。

而落地这件事情，本就不是Scrum 框架能解决的问题，就好比你去买菜刀，卖菜刀的也不能保证你的刀工就能大幅上升一样。能保证的仅仅是“当你会使用菜刀的时候，你能在厨房中从这把锋利的菜刀中获益”。但如果你是一个小屁孩买了这把刀，在不合适的场合（比如KTV这种），用你自以为的方式挥舞菜刀，那就会伤到别人，也会伤害到自己了。

而现在的培训，更多的是从这把菜刀的本身出发，告诉你刀身多么锋利，刀柄多么符合人体工学、在厨房中你如何从这把菜刀获益之类。但有多少人会告诉你如何确定你是否在厨房，以及当你不在厨房的时候，你如何将现有的环境引导、改造成厨房或者类似场合。这恐怕才是目前Scrum 被黑的核心要素。

毕竟在错误的地方使用正确的东西，结果也必然是错误。

敏捷没有银弹

在本文结束之前，我还是要提醒各位，牢记这句话：

个体和互动 高于 流程和工具

敏捷软件开发宣言

这句话告诉我们，人是第一位的，而结合人的不确定性，一群人所组成的群体的不确定就更大，必然是一个复杂系统。针对任何一个复杂系统而言，一切现成的SOP也好，规章制度也好，都是大概率不可直接用的，而是需要通过实际情况酌情处理，找到那个最适合现有组织的方法，才是最可行的，任何试图找寻银弹，妄图通过Ctrl-C、Ctrl-V来实行敏捷、Scrum，失败都是必然的，区别只是早与迟罢了。

毕竟，你我都是Human Being，都有自己的想法，不是毫无想法Resource。