{
  "slug": "mckinsey-agile-obsolete",
  "url": "https://kelewrites.com/posts/mckinsey-agile-obsolete/",
  "title": "麦肯锡：让你最累的不是 AI，是还在跑的那套敏捷",
  "subtitle": "AI 让代码廉价，但旧 Sprint 节奏正在反过来吃掉团队的整体效率",
  "summary": "麦肯锡发现，企业上完 AI 工具后整体生产率只提升了 5%-15%，问题不在工具，而在还在用十几年前为「人写代码」设计的敏捷操作模型去套一个 AI 深度参与的新世界。真正该升级的，是规范、价值流和人的工作重心。",
  "date": "2025-12-17",
  "updated": "",
  "tags": [
    "AI",
    "工程方法",
    "行业洞察"
  ],
  "series": "",
  "source": {
    "title": "麦肯锡：AI 时代，旧的敏捷开发方式正在拖累个人效率",
    "url": "https://www.bilibili.com/video/BV1bMq3BTEhX/"
  },
  "ai": {
    "summary": "麦肯锡发现，企业上完 AI 工具后整体生产率只提升了 5%-15%，问题不在工具，而在还在用十几年前为「人写代码」设计的敏捷操作模型去套一个 AI 深度参与的新世界。真正该升级的，是规范、价值流和人的工作重心。",
    "takeaways": [
      "麦肯锡发现，企业上完 AI 工具后整体生产率只提升了 5%-15%，问题不在工具，而在还在用十几年前为「人写代码」设计的敏捷操作模型去套一个 AI 深度参与的新世界。真正该升级的，是规范、价值流和人的工作重心。",
      "开场：爽文体验 vs 系统数据",
      "一、敏捷的物理定律变了：人不再是瓶颈",
      "二、新的优化方向：从 Sprint 跑得快，到价值流跑得顺"
    ],
    "audience": [
      "关心工程落地与系统设计的人",
      "关注 AI 行业演化的从业者"
    ],
    "quote": "一句话总结：敏捷没死，死的是它那套为「人写代码」设计的操作模型——AI 把代码变廉价了，旧的 Sprint 节奏、Story Point 度量、PO/Dev/QA 分工正在反过来拖累整体效率，真正要重写的是规范、价值流和人的工作重心。",
    "questions": [
      "这篇文章的核心结论是什么？",
      "开场：爽文体验 vs 系统数据到底讲了什么？",
      "敏捷的物理定律变了：人不再是瓶颈是什么意思？",
      "新的优化方向：从 Sprint 跑得快，到价值流跑得顺到底讲了什么？"
    ],
    "citation": {
      "title": "麦肯锡：让你最累的不是 AI，是还在跑的那套敏捷",
      "conclusion": "麦肯锡发现，企业上完 AI 工具后整体生产率只提升了 5%-15%，问题不在工具，而在还在用十几年前为「人写代码」设计的敏捷操作模型去套一个 AI 深度参与的新世界。真正该升级的，是规范、价值流和人的工作重心。",
      "points": [
        "开场：爽文体验 vs 系统数据",
        "一、敏捷的物理定律变了：人不再是瓶颈",
        "二、新的优化方向：从 Sprint 跑得快，到价值流跑得顺"
      ],
      "quote": "一句话总结：敏捷没死，死的是它那套为「人写代码」设计的操作模型——AI 把代码变廉价了，旧的 Sprint 节奏、Story Point 度量、PO/Dev/QA 分工正在反过来拖累整体效率，真正要重写的是规范、价值流和人的工作重心。",
      "url": "https://kelewrites.com/posts/mckinsey-agile-obsolete/",
      "attribution": "kele · Article Share"
    }
  },
  "headings": [
    {
      "depth": 2,
      "text": "开场：爽文体验 vs 系统数据"
    },
    {
      "depth": 2,
      "text": "金字塔总览"
    },
    {
      "depth": 2,
      "text": "一、敏捷的物理定律变了：人不再是瓶颈"
    },
    {
      "depth": 2,
      "text": "二、新的优化方向：从 Sprint 跑得快，到价值流跑得顺"
    },
    {
      "depth": 2,
      "text": "三、规范驱动开发（SDD）：给 AI 套上施工图"
    },
    {
      "depth": 2,
      "text": "四、角色重心整体上移：当代码变廉价"
    },
    {
      "depth": 2,
      "text": "五、四个实战样本：从 Netflix 到 Browser Company"
    },
    {
      "depth": 2,
      "text": "六、度量三层：J 曲线、采用度与业务结果"
    },
    {
      "depth": 2,
      "text": "一页速览"
    },
    {
      "depth": 2,
      "text": "一句话收束"
    }
  ],
  "text": "> **一句话总结**：敏捷没死，死的是它那套为「人写代码」设计的操作模型——AI 把代码变廉价了，旧的 Sprint 节奏、Story Point 度量、PO/Dev/QA 分工正在反过来拖累整体效率，真正要重写的是规范、价值流和人的工作重心。\n\n---\n\n## 开场：爽文体验 vs 系统数据\n\n如果你已经用上 Copilot、接触大模型开发，却总觉得「效率提升和预期完全对不上」，那这份观察就是为你准备的。\n\n个体开发者能讲出一堆爽文故事：本来要干几天的活，现在半小时搞定。但拉长到团队、组织节奏、交付周期、质量指标，变化不大。麦肯锡在三百多家企业的调研里给出一个很扎心的结论：**大多数企业上了 AI 开发工具之后，整体生产率只提升了 5%-15%**。\n\n问题不在你有没有用 Copilot、有没有上大模型，而在于你还在用十几年前为「人写代码」设计的敏捷操作模型，去套一个 AI 已经深度参与的新世界。AI 介入之后，旧的工作方式在系统层面已经失效了。\n\n注意是**远离那套敏捷操作模型，不是把敏捷价值观一脚踢开**。快速反馈、拥抱变化、跨职能协作、持续交付价值，在 AI 时代不但没过期，反而更刚需。错的是：我们继续用旧时代的度量和节奏，去管理一个完全不同物理属性的开发过程。\n\n---\n\n## 金字塔总览\n\n---\n\n## 一、敏捷的物理定律变了：人不再是瓶颈\n\n经典敏捷有几个默认前提：**人是主要瓶颈**、**写代码是最贵最慢的环节**、**需求变化主要来自业务，系统本身相对稳定**、**按 Sprint 节奏演进就行**。这套假设在 AI 介入之后被逐条打穿。\n\n代码不再稀缺，原型几乎即时生成。需求、实现、验证三件事开始压缩到同一条时间线里。模型、数据、Prompt 每天都在变，系统本身变成「活的」。\n\n在这个世界里，你还拿 Sprint 速度、Story Point 吞吐量当核心指标，就有点像在量一辆电动车「今天吃了几捆草」。\n\n很多团队的真实体验大概是这个画面：**AI 像高压水龙头一样在喷代码，而你还在用人工 Code Review 加模糊需求的纸杯接水**。麦肯锡在客户里看到的几个典型新瓶颈：\n\n| 新瓶颈 | 具体表现 |\n\n| 工作分配 | AI 在不同任务上效果差异巨大，有人会用、有人不会用，团队负责人不知道怎么最优分配 |\n| 需求与验收 | 给 Agent 的还是模糊的自然语言故事，验收标准写得很虚，唯一兜底就是加人肉 Review |\n| 质量控制 | 生成速度上来了，但测试、Review、合并流程没重写，PR 堆积、测试排队 |\n\n更隐蔽但杀伤力更大的副作用是**技术债在被静悄悄放大**。短期交付爽、长期维护惨：AI 为了完成当前需求，很容易复制粘贴式产生更多分支逻辑、配置开关；不同时间不同人用不同提示生成出来的风格、抽象层次、边界划分都不一样，看起来每一块都能跑，组合在一起越来越难懂。\n\n> **金句**：AI 让局部环节快得离谱，但端到端只换来了一个字——堵。你以为省下的是今天写代码的时间，实际上很可能在未来几年的重构和迁移里，用更高的利息还回去。\n\n---\n\n## 二、新的优化方向：从 Sprint 跑得快，到价值流跑得顺\n\n在传统敏捷语境下，最熟悉的目标是：Sprint 要跑满、吞吐量要稳定向上、每个人的 Story Point 要尽量打高。在 AI 时代，这套优化方向开始变得危险：\n代码产出更快，不等于价值更快落地。\n交付更多需求，不等于系统朝正确方向演化。\nSprint 跑得满，不等于组织真的在学习和升级。\n\n麦肯锡给出的转向是：**从团队级节奏管理，升级到系统级价值流设计**。不再只看某个 Squad 的 Velocity 漂不漂亮，而是看从一个想法被提出，到真正在用户侧创造可观测的价值，中间所有环节是否形成一条顺畅、可度量、可优化的价值流。\n\n与之配套的是看待产品的方式。传统项目思维里，产品是一个「做完就能收工的工程」：立项、开发、上线、运维，节奏分阶段，像盖一栋楼。AI 上线之后，你手里不再是一块静态软件，而是一个由模型、数据、Prompt 组成的**活系统**——模型要不断训练，数据要持续清洗标注，Prompt 和业务策略要跟着反馈调优。\n\n落到 AI 从业者身上，这有一个非常现实的含义：你的工作重点不是「如何按期交付这个版本」，而是**如何设计一套能长期托住模型、数据、Prompt 持续演化的机制**。\n\n> **金句**：你不只是在交付一个模型，而是在交付一个能让模型自己不断进化的生态。\n\n---\n\n## 三、规范驱动开发（SDD）：给 AI 套上施工图\n\n如果说价值流回答了「优化什么」，那 SDD（Spec-Driven Development）回答的就是「日常怎么干」。GitHub 开源的 Spec Kit 把一整条开发链拆成四个阶段：\n\n| 阶段 | 谁主导 | 干什么 |\n\n| Specify | 人 + AI | 把功能目标、边界条件、非功能要求、验收标准沉淀成机器可理解的规范 |\n| Plan | AI 起草 / 架构师定稿 | 草拟架构方案、关键设计决策、依赖关系 |\n| Tasks | AI 自动生成 | 拆出任务清单、子模块、接口、测试项，按人或 Agent 小组分配 |\n| Implement | AI 写 / 人 Review | 生成代码、测试、文档；有问题回到上游规范修正，而不是裸改代码 |\n\n它替换掉的是大家熟悉的 Vibe Coding：打开 IDE、拉起大模型、一句「帮我写个 XX 服务」、看着模型接龙、哪里不对再补一句提示，全程靠感觉。短期爽，但有三个硬伤：\n**不可观测**：没人能说清这一坨功能到底满足了哪些约束、安全、性能、边界条件——还是只是「看起来能跑」。\n**不可复制**：同一个需求、换个人换一次提示，AI 生成出来的实现完全不一样，你连为什么这次是对的都说不清。\n**不可维护**：完全跟着感觉让 AI 写，最后连原作者都看不懂那堆代码在干嘛。\n\nSDD 的三个关键转变：从代码中心变成**规范中心**——代码只是 Spec 的一个实现视图；从「人写 AI 帮」到「**AI 写人审**」——人类主要精力放在写规范、审规范、审生成物；从 Freestyle 到**工业化生产线**——规范可以复用、版本化、对比，在组织层面沉淀成模板和库。\n\n更进一步，当流程被结构化之后，每个阶段都可以接入专门的 Agent：Specify 阶段有规范助手 Agent 盯一致性，Plan 阶段有 Agent 提方案备选，Tasks 阶段有 Agent 做拆解和依赖分析，Implement 阶段有 Agent 轮流写代码、写测试、查回归——人类退到更高一层做编排和裁决。\n\n> **金句**：让 AI 负责搬砖，人类负责画图和验收。未来最贵的开发者不是键盘敲得最快的那个人，而是那个能把一群 Agent 和一堆工具指挥得最干净的人。\n\n---\n\n## 四、角色重心整体上移：当代码变廉价\n\n麦肯锡这份报告有一个非常清晰的结论：**当代码变得廉价，角色的重心必须整体上移**。\n\n**开发者**要从「码农」升级成「AI 管弦乐指挥」，补三层底层能力：\n提示与规范：把业务语言翻译成机器能执行的 Specification、结构化 Prompt、明确边界条件，而不是一句「帮我写个服务先跑起来」。\n审查与裁决：AI 负责演奏，你负责听是不是跑偏——逻辑、性能、安全、与既有架构规范是否对齐。\n系统思维：不是只盯一个 PR，而是看这个改动放进整个系统会不会放大复杂度、制造新的技术债、让未来的 Agent 协作更难。\n\n**产品经理**要从「写 PRD 的项目秘书」变成「能自己拉原型的产品设计者」。两个升级方向：第一，原型直接用 AI 起草——UI 初稿、交互流、简单后端 Mock 都可以靠大模型和 Agent 拉起来，再拿给用户验证，而不是先写 30 页 PRD；第二，需求挖掘变成数据加 AI 驱动——AI 扫评论、工单、使用轨迹，几天之内抽出模式、痛点和机会窗口，把自己的时间留给判断和取舍。\n\n**架构师**反而比以前更稀缺。AI 在局部实现上很猛，但**对全局约束天然无感**——如果没人站在系统视角做长期约束，AI 会帮你把架构慢慢拖成一团意大利面。架构师的核心动作变成三件：把隐性规则显性化写进 Spec 和工具（代码模板、Lint 规则、CI/CD 检查）；用自动化做架构治理而不是纯手工 Review（复杂度阈值、依赖方向、分层边界变成可检测规则挂在流水线上）；和安全、合规、数据团队一起定义 AI 使用红线（哪些组件可引、哪些数据可喂）。\n\n旁边还在长出一批新岗位：提示工程师（AI 流程设计师）、AI 审核员/评估师（为模型输出负责，必要时一键拉闸）、数据策划师（定义「我们要用哪些数据来理解世界」）、AI Ops / Model Ops / AI 伦理负责人。共同点只有一个：**不再直接写业务代码，而是负责让人 + AI + 流程这台大机器长期安全可控地跑下去**。\n\n> **金句**：AI 时代的人不再是「代码工」，而是问题定义者 + 规范制定者 + 系统裁判。\n\n---\n\n## 五、四个实战样本：从 Netflix 到 Browser Company\n\n光讲范式还是悬，看四家公司具体改了什么。\n\n**Netflix · Shift Left**。AI 写码之后，他们立刻撞上典型的新坑——代码生成速度起飞，测试和质量环节跟不上，结果是「写得飞快、卡在测试门口排长队」。Netflix 的做法很简单但杀伤力极强：把测试和质量检查**整体向开发左移**——代码一由 AI 生成，就自动挂上 AI 辅助的单测、集成测试，质量门槛前置到提交时就跑掉。人类 QA 更多变成「设计测试策略 + 观察质量信号」，而不是手动一条条点回归。结果是 AI 没有制造新的测试拥堵，发布节奏反而更稳。\n\n**高盛 · 内部大模型平台**。这家对安全合规要求几乎是地狱难度的金融机构，没走「买个现成工具就完了」，而是用自家几十年的代码和文档对模型做定制微调，做出一个「高盛方言版 Copilot」——它懂内部架构规范、命名习惯、安全要求、部署脚本套路。结果：从需求到上线的周期缩短 20%-30%，人均产能整体抬高一档，缺陷率保持稳定甚至小幅改善。**真正值钱的不是会用几个热门 SaaS 工具，而是能不能把企业的代码资产和文档资产沉淀成一个专属的大模型开发平台**。\n\n**Cursor 与宝洁 · 以少胜多**。Cursor 核心工程团队大概十来个人，不到一年把产品做到年经常性收入 500 万美金级别、估值接近 10 亿，秘密武器不是超人程序员，而是极致的 AI 原生工作流——大部分代码由自己的模型生成，人类工程师主攻规范设计、Review 和自动测试体系。宝洁和高校做的对照实验则给出另一面证据：少数开发者 + AI 工具 vs 大团队不用 AI，做同样复杂的项目，小团队加 AI 不止按时交付，方案质量达到大团队同档，整体完成时间还快了约 16%。\n\n**Browser Company · 漂移过弯**。原本做 Arc 浏览器的他们在 2024 年底做了一个激进决定：暂停主线，全员转向新 AI 产品 Dia。这种级别的战略转向通常要几个月，很多公司在过程中被自己拖垮。Browser Company 把原有团队拆成多个 AI 小分队，每队配 AI 设计助手和原型开发 Agent，很短时间内就拉出了智能总结网页、对话式浏览的核心功能雏形。**小团队 + AI 原型能力，让战略试错成本极低**——你敢于做大转向，因为验证一条新赛道不再需要巨量时间和人力。\n\n---\n\n## 六、度量三层：J 曲线、采用度与业务结果\n\n不少严谨的对照实验发现：**有经验的程序员刚开始用现有 AI 工具时，会整体变慢 10%-20%**。不是 AI 没用，而是典型的 **J 曲线效应**——一开始要学工具、调提示、改自己的工作方式，效率曲线先掉一截再慢慢往上爬。问题是很多公司只看上线那一刻的效率，看到曲线一折就下结论「AI 没那么神」，AI 落地十有八九会在刚刚要起飞的时刻被掐断。\n\n要走出 J 曲线，度量必须分三层：\n\n| 层级 | 关注什么 | 关键指标 |\n\n| 一·采用度 | 你的人真的在用吗 | 日活、AI 参与的提交占比、深度工作流覆盖率 |\n| 二·过程 | 端到端节奏有没有变顺 | DORA 四大指标、PR 排队时间、测试队列、严重 Bug 修复时间 |\n| 三·业务结果 | 真的赚了多少、踩了多少坑 | 缺陷密度、关键功能从想法到见到钱的时间、开发者 NPS |\n\n麦肯锡在 300 家企业调研里看到一个非常硬的相关性：**只有当 80%-100% 的开发者把 AI 工具融进日常开发流，生产率提升才有机会到翻倍这个级别**。零星几个人在那玩玩，整体曲线几乎不动。\n\n第二层的关键在于**别只盯「快」**，要看快的那一段是不是把别的环节堵死了。AI 让局部环节变快，反而可能在 PR 排队、测试队列、严重 Bug 修复时间上制造新的瓶颈。先用统一口径画出上 AI 之前的基线，再用同样的口径追踪 AI 引入之后每个阶段的变化，看清瓶颈从哪挪到了哪。\n\n第三层是最难也最重要的：把故事拉到业务结果——缺陷率有没有下降、重大事故恢复时间有没有缩短、关键功能从想法到见到钱的时间压缩了多少。**只有当这三层能连成一条因果链——改流程 → AI 深度采用 → 过程效率提升 → 质量、收入、体验一起抬头——你的 AI 转型才算走出工具试点，开始变成公司级战略**。\n\n---\n\n## 一页速览\n\n| 维度 | 旧敏捷模型 | AI 原生新模型 |\n\n| 核心瓶颈 | 人写代码慢 | 局部太快、端到端堵 |\n| 优化目标 | Sprint 跑满、Story Point 高 | 价值流顺、可观测的业务价值 |\n| 产品观 | 项目盖完就收工 | 活系统：模型+数据+Prompt 持续演化 |\n| 开发方式 | Vibe Coding 即兴 | SDD 规范驱动 + Agent 小组 |\n| 人的工作 | 实现细节、写代码 | 写规范、做决策、当裁判 |\n| 度量重心 | 速度、吞吐量 | 采用度 + 过程 + 业务结果三层闭环 |\n| 团队形态 | 大团队铺人头 | 小团队 + AI 原生工作流 |\n\n---\n\n## 一句话收束\n\n> AI 让代码变廉价了，但描述意图、设计系统、做高质量决策的难度只会越来越高。要么继续在旧流程里给马车装喷气发动机，要么主动站到新范式的前排，去设计 AI 原生的规范、团队和度量体系——这就是后敏捷时代真正的分水岭。"
}