两位日本教授描述了本田、佳能、富士施乐等公司的团队如何像一支橄榄球队那样开发产品：不是通过一连串按顺序交接的接力赛，而是让整个团队一起带球向前推进。那篇论文里没有软件，没有 Sprint，也没有故事点。它的隐喻是一个正在运动的身体，而不是一张会议日历。
此时此刻，在世界的某个地方，一名软件工程师正盯着 Jira 看板参加早上 9 点的站会，向六个人汇报她昨天做了什么。
其中三个人根本没在听。两个人在看 Slack。还有一个人是 Scrum Master，正用力点头，同时起草下一个 Sprint 的"仪式"。
等这场会终于结束时，一位队友终端里的 AI agent 已经交付了两个 pull request，重构了一个服务，并更新了文档。
我们正在用 1995 年的流程，驱动 2026 年的机器。
这不是热评。这是尸检。
我们会沿着 Scrum 的源流追溯下去：从一篇《哈佛商业评论》论文开始，穿过它壮观的崛起、中年期的硬化与僵化，最终抵达此刻——它已经变成一套"看上去在动"的戏服，披在那些再也跟不上工具速度的团队身上。
要明白一件东西为什么正在死，你得先明白它当初是为什么活的。
点开任意一条看详情。请留意它的诞生与巅峰之间那段距离——错误就是在那段距离里悄悄积起来、滚成复利的。
两位日本教授描述了本田、佳能、富士施乐等公司的团队如何像一支橄榄球队那样开发产品：不是通过一连串按顺序交接的接力赛，而是让整个团队一起带球向前推进。那篇论文里没有软件，没有 Sprint，也没有故事点。它的隐喻是一个正在运动的身体，而不是一张会议日历。
Jeff Sutherland 和 Ken Schwaber 引入了一个以橄榄球阵型命名的框架。他们的目标，是替代死亡行军式的瀑布项目：这些项目会产出价值数百万美元的 PDF 规格说明，却连续多年什么都交付不了。Scrum 允许团队只规划接下来的三十天。在当时，这是一件很激进的事。
"个体和互动高于流程和工具。"很难想象，还有哪一句话比这句更彻底地被后来发生的事情背叛。敏捷宣言本来是一场反对仪式的叛乱。十年之内，Scrum 却成了仪式本身。
软件行业出现了一个新角色：Scrum Master——既不是经理，也不是工程师，而是一位"仆人式领导者"，其职责是捍卫这些仪式。它背后的管线非常庞大：培训公司、咨询顾问、框架之上的框架（SAFe、LeSS、Nexus）。一个原本为了帮助团队交付软件的框架，最终长成了一门巡回大会和认证培训的生意。
到了 2010 年代中期，Scrum 已经不再只是一种方法论，而更像企业软件组织的默认底座。招聘 JD 把它列为要求。工具链默认假设它存在（Jira、Azure DevOps、Rally）。新员工还没学会部署一个服务，就先被教会了用斐波那契数列做估算。
Basecamp 发布《Shape Up》——一本无 Sprint、无估算、无站会流程的书。Linear 作为一款 issue tracker，从一开始就有意识地站在 Jira 的反面。尝试这些方法的团队反馈出一件让其他人有点尴尬的事：他们交付更多，开会更少，而且似乎更快乐。
软件生产的单位第一次不再是"开发者天"——它变成了"开发者一秒钟的判断"，再乘以一个模型。产出开始与人头数脱钩。两周 Sprint 原本是为"一个功能需要两周完成"的世界设计的，如今看起来，简直像上一个时代的旧制服。
AI agent 开始在它们的人类"所有者"坐在 Sprint Review 里时，自己打开 pull request、运行测试、重构代码。站会变得荒诞：一个人正在描述某项工作，而那项工作其实是一个自治流程在前一夜完成的。估算就此停止正常工作。瓶颈不再是打字。
Scrum 仍然在组织架构图、日历、墙上的彩色便利贴里。但它赖以承重的假设——工作可以按两周增量规划、人类是瓶颈、估算有意义、可见性需要会议——都已经在经验上被证明是错误的。我们现在进入了晚期。身体靠惯性和认证保存着。尸检可以开始了。
埋它之前，它值得一次公平的听证。Scrum 解决过真实的、痛苦的、昂贵的问题——只是它现在声称能解决的，已经不是当年那些问题了。
在 1990 年代末，一个软件项目常常要动用数百人、花数年时间编写需求文档。那个年代的主要病灶并不是工程师工作太慢，而是组织看不见工作、引导不了工作、也完成不了工作。Scrum 用六种方式回应了这些痛点。
这些问题，每一个都真实存在过。但它们不是软件本身的问题——它们属于那个年代的软件、那个年代的团队、那个年代的基础设施。
任挑一根轴。轻点，把视角翻过来。
Scrum 的承重假设是：人类是开发流水线里最慢的部分；要看见他们的工作，就必须用同步会议来换取可见性。这句话的前后两半，都已经在不知不觉中不再成立。
每个团队每年的部署次数
看着曲线断裂。两周 Sprint 大约诞生在这张图的原点附近，此后再未更新。
对数刻度。线性刻度会让早期年份完全消失成一根贴底线。把鼠标移到任意圆点上，可看到当年部署次数与时代标签。
一个 Scrum Sprint，按真实比例画出来
每一根刻度，都是一场会。两根刻度之间的空隙，是一个搭着 agent 的工程师能交出零到二十个 PR 的时间。
10 个工作日里 14 场仪式。鼠标悬停每个标记可看会议名。三种颜色区分仪式类型——你能一眼看出 8 场站会几乎吃掉了整张图。
一份你给自己做的诊断书。勾选你认得出的项。诚实一点——除了这页，没人在看。
六个结构性原因，按严重程度递增。
Scrum 假设"两周一拍"是有用工作的自然节奏。并非如此——而且从来都不是。
归根到底，Sprint 是一场工厂 cosplay。它来自制造业——在那里，物理换线成本真实存在，批量大小至关重要，规划周期本身就是一种物理约束。软件没有这些约束，从来就没有。
人为的节奏，制造人为的工作。故事被裁剪成"刚好装进盒子"的尺寸；功能被拆开塞进不同周期；Bug 被往后推一个周期再说。最终，是容器在塑造内容。
在一个"一只 agent 一个下午就能交出五个 PR"的世界里，两周这个容器，宽松得只剩下一张会议日历的功能。
故事点过去预测的，是一个人在熟悉的问题上敲键盘的时间。而这个变量，今天已经不再是决定一项工作完成时间的主因。
2010 年，一名资深工程师估一个 3 点的工单，本质上是在预测自己的打字速度，加上一点搜索与重构的常数。估算之所以有效，是因为底层过程稳定。
2026 年，同一个 3 点的工单，实际完成时间的方差巨大。它取决于：LLM 当天的状态好不好，代码库是否处在"模型容易读懂"的状态，测试套件是否够快，以及上下文里有没有好文档。
在如此宽的分布上，你算不出有意义的平均数。故事点今天是一种仪式数字——它被报出来，是为了满足某套系统，不是为了预测未来。
当每小时工作的产出很低时，一笔"站会形状"的税还能忍；当每小时产出抬升两个数量级时，它会变成毁灭性的。
15 分钟的站会之所以听起来"只是 15 分钟"，只能在一个"15 分钟专注时间不值钱"的星球上成立。当 15 分钟专注时间已经等于两个 pull request 加一次重构时，站会就成了一种没收。
对一个使用 AI 工具的工程师来说，一小时不被打断的时间，其边际价值已经抬升一个数量级。但是"团队同步对齐"这件事本身的边际收益，并没有按同样的速度抬升——对齐当然必要，可它的价格并没有下降。
结果是：大量在 2015 年还能算"净收益为正"的例会，今天已经悄悄滑到了"净收益为负"。算术已经反转——而大多数团队，还没注意到。
看板、仪式、Sprint 评审，它们存在的理由是"让管理者看见工作"。这条理由，今天已经不复存在了。
一个想知道团队在做什么的工程经理，今天可以看到每一个 PR diff、每一次 commit、每一次 CI run、每一条 Slack 讨论、每一次 Linear/Jira/GitHub 状态变化——并且，可以让一个 LLM 把这一切，总结成一段话。
读一段团队真实产出的周报摘要，比每周开 50 分钟站会，能让一位管理者学到的多得多。2026 年的站会，是一种"为传递数据而设计"的仪式；而这些数据，其他系统已经可以以更准确、零人力成本的方式传递。
站会真正还擅长的一件事，是社交——它是一次每日的 check-in。这很好，也值得保留。只是，不要把它和项目管理混为一谈。
一个"为了捍卫流程"而存在的角色，本身就说明：这个流程无法为自己证明价值。
Scrum Master 最初的销售话术很高尚——一位"仆人式领导者"，负责移除障碍，让团队能够交付。但在大多数公司的实践里，这个角色已经退化成：主持会议的人，以及在团队想跳过会议时出面反对的人。
一个有用的流程，应该让"需要为它辩护的人"减少，而不是让这群人成倍增加。
实质上，Scrum Master 是团队为了"让 Scrum 活下去"而缴的一笔税。当流程能够交付成果时，这笔税是隐形的；当流程不再交付时，它就成了团队身上最显眼的那块伤疤。
你的一半贡献者，今天已经不是人类。流程是为"还是人类的那一半"设计的，并且把他们当成了瓶颈——可他们已经不是了。
在现代团队里，相当一部分代码提交，是由自治或半自治的 agent 写出来的。它们不需要每日站会，不需要故事点，不会"结转"，也不会因为 Sprint 被重新规划而士气低落。
现在表现最好的团队，已经学会了：如何定义任务、如何分派任务、如何验证 agent 的产出。这项能力更接近"系统设计 + 产品写作"，而不是"工单梳理"。
一个把人类当作吞吐量单位的流程，已经错过了一支现代团队中超过一半的吞吐量。
拖动滑块。看着计价器变化。
流程的成本，本应是每个领导团队年度预算里的一行。它几乎从来不是。下面这组数字，按全口径工程小时计算，只计入反复发生、已排期的仪式——打断、ticket 梳理、关于站会的 Slack 讨论，一概不算。这已经是相当宽厚的算法。
这是这支 8 人团队，每年花在已排期仪式上的钱。仅此而已。
这笔预算够你多雇大半名高级工程师，或买下约 7,700 小时前沿大模型推理，或资助 11,600 次用户研究访谈。换种说法：四分之三个工程师，全年都可以真正用来构建东西。
Loaded cost = 薪资 × 1.4，再除以每年 2,000 小时。这仍是保守估计——打断、上下文切换、"关于会议的会议"，统统未计入。
2026 年，至少有四种团队既不是 Scrum，也不假装是 Scrum，而且它们看起来用更少的会议交付了更多软件。
这四种里没有"唯一答案"——这恰恰是重点。Scrum 的错误，是声称自己是普遍答案。今天赢的人，会从下面这份菜单里挑选、然后改造。它们共享的只有一条信念：流程，应该是把工作做完所需要的最小那一份。
六周一个周期，没有任何每日仪式。工作在"被下注"之前，先经过一道"塑形"——也就是在正确的抽象高度上，先把它定义清楚。
一个小组写出一份"pitch"，说明要做什么。它的抽象层级，高于实现细节，但低于模糊意图。Pitch 同时定义两件事：解决方案的形状，以及 appetite——你愿意为它花多少时间。
领导层把一个六周周期"下注"到少数几个 pitch 上。没有优先级会议，没有 backlog grooming。一个 pitch 要么足够好、值得下注，要么不值得——只有这两种结果。
团队拥有这个六周周期。没有站会，没有故事点。进度通过"hill chart"呈现：我还在弄清楚这个问题，还是已经进入执行？
两个周期之间，留出两周冷却期。没有新的大赌注。工程师修补东西、打磨工具、把状态找回来。这是写进流程里的缓冲，而不是假装自己还有余裕。
由那家"工程师真的乐意用"的 issue tracker 背后的团队提出。它对"速度"有非常明确的立场。
系统是给做事的人用的，不是给汇报工作的人用的。如果一个功能只服务于管理者，它就不会被纳入。
用的是 cycle，不是 sprint。未完成的工作不需要任何仪式，直接向前滚到下一个周期。velocity 无关紧要——吞吐量才是一切。
同时进行的项目更少，没关掉的 issue 更少，工单上的字段更少。系统会主动把你推向"小而聚焦、可以在合理时间内做完"的工作。
键盘优先，所有操作低于 100 毫秒，没有任何加载 spinner。工具本身就是一种论证：流程，不应该让人感觉缓慢。
从一个小队列里拉取工作，限制在制品（WIP），持续交付，永远没有"迭代"这件事。
看板上的某一列，只能容纳 N 个条目，且 N 很小。工程师只在容量释放时才拉取新的工作。系统会自我限流。
核心指标是："一个典型 issue 从打开到关闭，需要多久。"你希望这个数字很短，并且持续下降——不管谁、给它估了多少点。
每一次 merge 都是一次部署。分支以"天"为单位合并消亡，而不是拖几周。"发布"是一个运行时事件，不是日历事件。
站会变成每周一次的书面摘要。决策变成文档。同步时间，只留给那些"文档解决不了"的问题。
一支由资深工程师组成的小团队，指挥一支 agent 舰队。管理的单位，是规格说明——不是站会。
工程师把更多时间花在写规格上，把更少时间花在敲代码上。规格是 agent 的输入，代码是输出。瓶颈上移了。
你不需要看着 agent 工作。你定义边界、跑测试、读 diff，然后做出"信任"或"拒绝"的判断。这份工作，更接近代码评审，而不是打字。
一名高级工程师，可能同时让 4 到 8 个 agent 在不同分支上工作。对此，没有任何一种"每日站会"还能起作用——站会的计量单位（一个人 / 一天）已经无法对应工作的颗粒度。
所有协调，都通过 PR、设计文档和录屏完成。同步时间稀少而昂贵，只留给真正的不确定性。
同步时间是团队最昂贵的资源。把它花在高度模糊的地方，而不是状态更新。
能快速完成事情的团队不需要估算。Cycle time 替代故事点。
模型能读懂的规格，新员工也能读懂。文档现在是杠杆。
雇佣你信任的人。如果流程是为了弥补不信任，那就修复招聘。
定义任务，分派执行，验证结果。把 AI 当作以机器速度工作的初级工程师。
跳过它六周会有什么坏掉？如果答案是"没有"，那它就是开销。
一篇这样的文章，如果最后没给出一个干净的抓手，就什么也不值得。下面就是那个抓手。
Scrum 曾经是一个关于慢速时代真实问题的有用想法。它值得一场体面的葬礼，也值得一篇像样的悼词。它不值得被防腐处理之后，再支在你的日历里站十年。
替换它最难的，不是找到一个新框架。最难的是信念——你必须先说服自己、再说服你的团队、再说服你的经理，最后还要说服审计部门里的某个人：你周一上午 9 点正在做的事，是你选的，不是你继承的。
下面这些都不是"有空了再做"的事。
没有"有空"。只有你拿手里的时间去做什么。
至少，挑一项。
停止表演，开始交付。
"Scrum 长眠于此。
生于善意。死于自己的仪式。"
读它，与它争辩，然后去交付一些东西。