被捧上天的Scrum敏捷管理为何不受大厂欢迎了？

Posted 2022-06-16 朱小厮

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了被捧上天的Scrum敏捷管理为何不受大厂欢迎了？相关的知识，希望对你有一定的参考价值。

点击上方“朱小厮的博客”，选择“设为星标”

后台回复"书"，获取

后台回复“k8s”，可领取k8s资料

项目管理是大家非常关注的话题。最近，总能得到一些不错的内幕消息的 Gergely 做了一项调查，探寻科技巨头们是怎么运营技术项目的，涉及了 100 多家科技企业，他意外地发现 Scrum 在大多数大型科技企业里“奇怪”地缺席了。

Scrum 是一个轻量级项目管理框架，它将团队化繁为简，分为产品负责人、Scrum Master 和开发团队三种角色，同时强调产品梳理会、迭代计划会、每日站会、迭代评审会、迭代回顾会。在过去十多年里，备受推崇并得到广泛应用。

为什么 Big Tech 反而不用这些流行的 Scrum 框架？那他们是如何进行项目管理的？我们翻译了 Gergely 的文章（有删节），或许我们能从他的调查分析中得到一些启示：

曾经备受关注的 Scrum

我 2012 年加入 Skype 的时候，公司已经开始全力推进 Scrum。当时，所有工程师和产品人员都接受了先进的 Scrum 技能培训，咨询顾问甚至包括敏捷宣言的拟定者之一。可以看到，Skype 打算在 Scrum 上倾尽全力，决意要用几个季度把这种敏捷方法推广到所有团队。

Scrum 转型被 Skype 视为成功的标志。之前我们最快也只能每个季度对旗舰版 Windows 应用进行一次更新，但转型后计划每月发布一次，大多数团队的交付周期变成了 2 到 4 周。各团队开始轮换 Scrum Master 角色，同时有敏捷教练驻扎进来、为大家提供及时反馈。作为刚刚收购 Skype 的新东家，微软也在饶有兴趣地关注这一切，希望从交付加速中汲取值得借鉴的灵感。

然而，就在 Skype 推进 Scrum 转型的同时，另一位竞争对手却用无情而高效的组合拳打得我们难以招架——这就是 WhatsApp。虽然他们的组织规模要小得多，但 WhatsApp 却每个月稳定吞食着市场份额，成为行业领先的沟通平台。

与 Skype 不同，WhatsApp 从来不把时间和精力耗费在 Scrum 这样的敏捷框架身上。早期员工也提到，他们压根不关心这种热门趋势，甚至故意忽略需要额外学习的新流程。结果就是，WhatsApp 超越了 Skype，带来了比 Skype 更可靠的交流体验，并最终成为消息收发与通信应用中的王者。

可以看到，企业的成功有时候跟项目管理方法并没有多大关系，Skype 和 WhatsApp 的故事就再次证明了这一点。大家别误会，我不是说项目管理不重要——当然重要，但其他一些因素也许会对结果产生更大的影响，例如重心定位、领导方法、人们在没有流程指引时如何工作等等。

项目管理只是业务成功这个复杂且不断变化的重大难题中的一小部分。没错，项目管理不是、也不该成为最终目标，它最大的意义就是以驱动因素的方式为业务成功保驾护航。

行业中的项目管理方法

企业们到底是怎么管理项目的？我收集了 100 多条回复，调查结果其实相当有趣。总结来讲，企业的项目管理方法要“视情况而定”。其实也能理解，毕竟只有 5 个人的初创公司，跟拥有上千员工、成长速度已经大为放缓的传统企业相比，获得成功的道路当然不可能相同。即使是在同样的大规模非科技企业之内，也有一些愿意尝试新方式，而另一些更倾向于坚持不那么“酷”、但在多年实践中被证明有效的老办法。

企业是怎么运行项目的？调查结果概览在此。

先从调查中发现的方法论说起：

无“正式”方法：这种情况在已上市和风投支持的科技公司中很常见。
规划、构建、交付：这种情况在已上市和风投支持的科技公司中很常见。
Scrum：在大型非技术企业、非风险投资支持公司和咨询公司中很常见。
Kanban：在各类企业中都有使用。
SAFe（规模化敏捷框架）：只存在于大型非技术公司和非风险投资支持的公司中。
Shape Up：只在少数风投支持的公司中出现。

科技巨头是怎么运行项目的？

下面重头戏来了。跟其他从业企业相比，科技巨头们在技术项目的执行上往往有所不同。为此，我跟多位知名上市科技公司的内部人士交流，掌握了他们的日常工作思路：

科技巨头是怎么运行工程项目的？常规方法：各个团队可以灵活选择自己的工作方式，所以即使是在同一个项目之内，各工程团队使用的方法仍然千差万别。

科技巨头的项目执行思路拥有以下几个基本特征：

工程师主导大部分项目：牵头的要么是技术主管，要么是团队中的工程师。
团队可以自由选择项目管理方法。多数团队采用类似于 RFC 的规划流程，持续迭代 build，并在几周内完成所有内容的交付。也有一些团队使用 Kanban 那类流程，即先从优先级最高的工作入手。
团队层面不设专门的项目经理。这类科技巨头中，大多只设置技术项目经理（TPM），他们同时介入多个团队或跨部门运行的大型项目。以 Uber 为例，TPM 与工程师的比例约为 1：50。
项目管理工件和流程往往因团队而异，即使在同一企业内也是如此。大多数团队都面临项目积压问题，所以他们会在合适的时候举办“站”谈会，并时不时对现状进行集体评估。
提供一流的开发者工具，而且强调更短的迭代周期。很多团队专注于处理主分支，从 CI/CD（快速集成 / 快速部署）系统中获取反馈，并立即与其他团队成员共享手头的功能。

如果大家也在科技大厂工作过，那对以上提到的情况应该都很熟悉。但千万别想着直接把这些照搬到传统企业当中——大概率要彻底失败。毕竟科技巨头中的团队运作方式是由其组织结构决定的，没有这样的底层依托，后续执行根本就无从谈起。

科技大厂的组织结构如何影响项目运行

为了理解科技大厂如何管理项目，我们不妨后退一步，聊聊他们的常规运营环境是什么样子。

软件工程师和团队拥有自主权。传统企业的开发人员只需要完成分配到的工作，但在技术大厂里，开发者的任务是主动解决业务中存在的问题。这就是巨大的差异，也让两种工程师有了完全不同的日常工作体验。
工程师是好奇的解决者，而不是麻木被动的人力资源。积极上进的工程师能够产生数倍于“普通工人”的价值，二者的区别就是前者能主动发现问题、而后者只会按指令办事。所以如果企业中的工程师大多是后一种状态，那重量级项目管理方法更适合，也就是削减灵活空间、多提明确要求。
内部数据、代码和文档的高透明度。包括工程师在内，大厂的所有员工往往都能随时访问业务指标和数据源，编写自己感兴趣的查询指令并创建自定义报告。
接触业务和业务指标。鼓励工程师们跟其他部门的同事开展互动，特别是与非工程师建立联系。相比之下，传统企业往往只关注开发者与开发者、业务人士与业务人士间的沟通。
通过三角沟通实现工程师间的交流。传统企业更强调同层级沟通，这会减慢信息传播速度、降低决策效率。
愿意花钱改善开发者体验。技术巨头往往愿意帮工程师们解决问题，因此会迅速建立各种平台团队，尽可能提供更好的开发者体验。
薪酬更高，人才更得施展。因为能充分运用工程师们的聪明才智，所以技术大厂一般能开出等同、甚至超过行业顶尖水平的用人成本。
人才素质更强。以上因素结合起来，体现为科技巨头坚持雇用素质强、更有上进心的人才。因为求职者众多，所以大厂可以用丰厚的薪酬和广阔的职业发展机会优先选择。

放权和自主，已经成为科技巨头们的发展基石，也成为科技行业中决定孰强孰弱的关键所在。虽然科技大厂里也有一些团队没那么宽松的授权空间，但总体来看，他们都更强调从需要解决的问题出发、让执行团队拥有充足的施展舞台。

团队归属性明确是科技巨头的另一大特征。在这里，每个由 5 到 10 人组成的团队都有清晰的愿景和使命，也掌握着必要的技能和自主权。如果产品团队的任务是开发酒店服务，那他们就可以将目标设定成“为老年群体提供全球最佳的预订体验”；对于产品平台团队来说，任务则可能是“以几乎零成本方式帮助其他团队整合评级体验”。

以产品为中心的团队，往往由跨职能部门的多位成员组成，具体涵盖后端、前端和 / 或移动工程师。团队中还经常有产品经理、数据科学家和设计师的身影。但与之对应，以平台为中心的团队往往不是跨职能团队，或者跨越范围没那么广泛。

请注意，尽管工程师们拥有更高级别的专业知识，但在科技大厂中，多数经验丰富的软件工程师其实是有挑选工作方向的自由的。大厂面试已经反映了这种对于通才的高度重视。

放弃“不切实际”的 Scrum

我曾亲眼见证 Scrum 团队是怎么在 Skype 项目中一步步放弃 Scrum 框架的。当初刚加入 Skype for Web 的工作时，我们进行过为期两周的冲刺，遵循的也是常规的 Scrum 流程。团队里也有软件工程师和 QA 工程师（在微软叫测试中软件开发工程师，简称 SDET）。但是，我们的发布速度只能做到每两周一次，再难寸进。

所以我们首先想到的就是把 QA 纳入到工程中来。在传统流程中，工程师先完成自己的工作、检查分支成果、更新工单，再交给 QA 加以审查。QA 那边要过一、两天才能拿到工单并审查内容，如果发现问题，就再开一张新工单把情况反馈回来。总之，整个过程相当迟钝缓慢。

因此，我们悄悄做了一点非官方的调整，要求所有 SDET 都参与生产软件的构建，同时要求所有软件工程师都要负责测试自己编写的代码。现在，我们不需要在交付生产之前傻等好几天的代码审查结果了。然而，两周一次的冲刺和无数 Scrum 工作又带来了新的麻烦。

Scrum 每天都在阻碍交付。Scrum 的基本思路就是以冲刺为中心，在冲刺启动时做出任务承诺，在冲刺期间处理任务，并在冲刺结束时演示实际成果。

但这个过程相当别扭，感觉像是被一只无形的手赶着快速前进。所以我们很快转向了另一种更流畅的工作方式，这就是 Kanban 方法。我们不再关心冲刺、也放弃了 Scrum 提出的那些条条框框，转而专注于自己当前正在做什么、接下来又要实现什么。

基础设施和开发者工具也帮助我们摆脱了种种 Scrum 琐事。具体有哪些琐事？向产品负责人演示开发成果、签收确定再交付之类。但这里其实包含一些并不靠谱的假设：

产品负责人未必能准确验证出工作成果是否符合规范。
产品负责人负责编写验证规范，但因为第一条就不确定，所以他们编写的规范当然也未必可靠。
在等待签收的过程中，成果还是没法及时被纳入生产流程。

反正在 Skype，上面三个问题确实严重影响了功能发布。我们编写的所有代码都通过了单元测试，甚至在必要时接受了集成和端到端测试，那还要产品负责人再验证一遍干什么？我们的代码都附有功能标签，也用分段发布的方式逐一验证完成。所以，大部分由工程师自己编写的“规范”和工单压根没有必要。CI/CD、功能标签和实验工具已经带来了快得多的反馈周期，没必要让产品负责人这一环拖慢整个节奏。

不少科技大厂也意识到一流的基础设施和开发者工具，将给工程团队的生产力带来多么重大的影响。因此，30% 到 40% 的工程人员长期驻扎在平台团队，Uber 也在内部平台研发上投入巨资。

凭借这些随时可用的先进基础设施和平台，各团队能够专心完成自己的核心工作目标，完全不必分神于如何设置基础设施、或者保障服务兼容性。下面分享我个人对于平台团队的一点愚见：“平台团队的作用是提高组织效率。在规模快速扩大的过程中，平台团队将发挥不可或缺的作用。但问题是，平台的价值并不直观，平台团队在商业角度看似乎缺乏意义。确实，对于规模较小的组织，或者那些增长速度不快且原有结构运行顺畅的组织，平台团队确实没什么存在感。”

另外，团队全员都很清楚我们在构建什么。我们的最终目标是发布 Skype 的 Web 版本，整个项目由多个子工程组成，但过程中团队对大局方向一直非常明确。产品经理协助制定宏观战略，我们的工程师则接手有待完成的任务。我们主动清除了那些不利于工作效率的 Scrum 要求，并发现剩下的那些要求已经跟 Scrum 没什么关系了。

超越 Scrum

在与 Facebook、WhatsApp、Google、Netflix 等类似组织的工程师交流时，我发现大多数受访者压根没用过 Scrum。为什么会这样？原因有以下几点：

有能力、自主的人不用太多引导就能产出可靠、高质量的成果。科技大厂更倾向于招揽、雇用和用好这样的人才。
让有能力的团队以适合自己的方式自由选择运作方式。大部分工程项目都可以灵活放权，我们也能明确看到为什么 Skunk Works（https://en.wikipedia.org/wiki/Skunk_Works）这种自治模式能够减少官僚主义，吸引到更多高素质人才的支持。

脱离团队层级的管理，工程部门仍然可以顺畅发展。也正因为如此，多数科技大厂才不愿采取重量级管理流程。当然，大厂也面临着自己的生产效率挑战，但其中大部分问题即使是用重量级管理流程也解决不了。具体包括：

开发者生产力。工程师们要如何把更多时间花在代码编写和团队目标实现上，而非分神于基础设施问题或者依赖问题？平台团队当然能帮上一把，但这还远远不够。
偿还技术和架构债务。科技大厂永远在快速行动，迅速对新机遇做出响应。在此期间，某些比较偷懒的选择会积累下技术和架构债务。如何以合理的方式偿还这笔债务，就成了日常工作的重要组成部分。毕竟“随借随还”，要比一口气还清友好得多、也可行得多。
让团队结构与组织目标相匹配。企业和子部门的目标总会定期变化，那么这种变化要如何反映在团队结构当中，又不致破坏团队自身的凝聚力？
腾出时间搞创新和应对意外工作。如果团队有创新的意愿，那就必须留出相应的时间。
随着工程团队的扩大，始终保持高效。企业拥有的工程师越多，那么工程师之间沟通和决策的日常开销就越沉重。在规模翻倍之后，组织要如何才能保持同样的工作速度？有没有哪些流程和结构选项，能够无视组织规模、始终保证团队敏捷和快速行动能力？
持久卓越。正如 Will Larson 在文章《先进在通往高效能团队的道路上》中所说，一时的卓越不是卓越，持久的卓越才是目标。必须想办法在提升业务吞吐量、保证工程师心态健康和长久持续这三个方向间找到平衡点。

难道 Scrum 毫无用处？当然不是

说了这么多，那企业是不是该像科技大厂那些完全放弃 Scrum？当然不是喽。在多数情况下，转为 Scrum 本身仍是个巨大的进步，而且会带来更高的生产力。Skype 就是一例，虽然我们及时摆脱了 Scrum 的束缚，但 Skype 仍然拼不过 WhatsApp。

下面来看看适合采用 Scrum 的几种理想场景：

“厨房水槽团队”：对于像厨房水槽一样什么活都得接的团队，Scrum 这类重量级流程甚至有助于做好工作。毕竟 Scrum 告诉其他相关方，当前进行的冲刺不能被随意打断，而且要给整理新的功能请求留下时间。于是乎，以冲刺为基础的工作结构就让团队有了不受干扰的自主空间，保证大家能按预设的优先级顺利推进开发。
“厨房水槽团队”在非技术企业中相当常见，这类企业往往不了解工程技术的底层原理。所以 Scrum 有助于引导其他相关方、让他们慢慢理解软件的开发流程，同时为工程团队提供执行空间。当然，如果产品团队需要承担的责任过多，“厨房水槽团队”在科技大厂中偶尔也会出现。但无论如何，Scrum 都能给这些团队保留一点喘息之机。但大厂团队更自主而且灵活性更高，所以他们可以更新团队章程，甚至直接向自己不认可的工作说不。
新团队的“组建”与“碰撞”阶段。心理学家 Bruce Tuckman 提出了“组建、碰撞、规范和执行”几个工作阶段。这个模型也非常适合大多数工程团队的发展曲线。
在组建新团队时，大家首先需要确定工作方式。而 Scrum 这类现成的方法当然是个好选择，至少要比相互还不熟悉的成员们各自提出意见要靠谱得多。如果成员们对于工作方式有所“碰撞”，那么 Scrum 也能带来有据可查的方法指导。
Scrum 的优势就是帮助团队成员反思自己的工作方式。而且随着时间推移，团队会逐渐摸清适合自己的自主工作路线、剔除不适用的重量级 Scrum 规则，最终找到个性化开发路线。
将交付速度提升至几周一次。Scrum 提出的冲刺周期概念，确实能够帮团队加快交付速度。而且只要冲刺周期比团队原本的交付周期更短，那 Scrum 就有实际价值。不跟科技大厂比较，单纯自己跟自己比，这样的提升对很多非数字优先的传统组织来说已经是天翻地覆式的提升。
加快交付速度，也是 Skype 在 2012 年决定推广 Scrum 的主要原因。在过渡之前，团队每隔几个月才能交付一次。过渡之后，各团队每月能交付一到两次。请注意，最终放弃 Scrum 的主要原因，是我们想要进一步把交付周期压缩到比冲刺周期更短的水平，其实大多数团队都没必要做得这么极限。
严格要求制定统一项目进度报告的公司。Scrum 的普及往往也伴随着 JIRA 的引入，而且我觉得再没有比 JIRA 更好的组织报告工具了。我发现很多组织在选择 Scrum 时，就是希望借 JIRA 之力让领导团队对一线开发者有更多了解，真正把握谁更累、谁更需要帮助。
统一报告和团队层级的优先事项划分，正是 Skype 在转向 Scrum 后迎来的主要收益之一。当时在 Skype 担任敏捷教练的 Chris Matts 就做出过这样的总结：“在 Scrum 和 JIRA 的帮助下，我们既能发现组织内积压工作最多的团队，也能发现项目实施顺序有误的团队。”
所以我的个人观点是，对于科技大厂中那些已经贯彻了自主授权、目标灵活且只需要依关键结果（OKR）工作的团队，直接指定 KPI 和业务目标往往效果更好。但对于自主性较差、权限空间有限的团队，Scrum 仍然要比传统流程方法有效得多。