每隔几个月，就会有人宣布敏捷死了——这次的理由换成了 AI 和 Spec-Driven Development。另一种说法则更客气一点：SDD 才是「真正的敏捷」。两种说法都犯了同一个错：把不同层次的东西，硬塞进同一张对立表里比较。

我更愿意把它们画成一张分层坐标系。坐标系不会替你做选型，但它能阻止一场本来就不必发生的争论。

先把问题说清楚

「敏捷」这个词被用滥了。它有时指价值观，有时指 Scrum 仪式，有时指「我们用 Jira」。Lean 也一样：有人指丰田式思维，有人指一块看板上的 WIP 限制。SDD 出现后，混乱又多了一层——有人把它当成新的项目管理框架，有人以为它要求你回到大而全的前期设计。

一旦术语挤在同一平面上，结论几乎注定失真。更有用的做法是问：这句话在回答哪一层的问题？

三层坐标系

层主要回答的问题典型成员
价值层我们看重什么？用什么原则取舍？Agile、Lean
活动框架层团队如何协作？工作如何流动与同步？Scrum、Kanban、Scrumban
工作项交付层单个需求如何被精确表达、实现与验收？SDD（以及 TDD、结对等工程实践）

这不是严格的谱系学，而是一张工作用地图。Agile 与 Lean 有历史纠缠，Kanban 明显带着 Lean 血统，Scrumban 也不是第三方「官方标准」。分层的用处不在于划清血统，而在于：换一层，问题就变了。

它也和站内的 AI4SE 分层技术模型 相容：活动框架偏 Process，SDD 偏 Methods；价值层则是两者之上的取舍语言。

价值层：Agile 与 Lean

Agile Manifesto 首先是四句价值观和十二条原则。它告诉你：在不确定里，更偏向可工作的软件、人与人的协作、对变化的响应。它并不规定你必须开 Sprint Planning。

Lean 同样首先是一套思维方式：从客户价值看整条流，减少浪费，尊重人，持续改进。软件语境里，它还带出一批可操作的机制——价值流、拉动、限制在制品、缩短反馈。把 Lean 说成「只是价值观」并不完整；但把 Lean 等同于「我们用了看板工具」，同样过窄。

两者的共同点是：它们提供判断好坏的语言，而不是排班表。团队可以同时敏捷且精益；也可以口头引用宣言，却用瀑布式治理把价值流堵死。价值观不会自动变成流程。

活动框架层：Scrum、Kanban、Scrumban

到了这一层，关注点变成：人如何一起工作，以及工作项如何在系统里流动。 框架既管人，也管事儿。

Scrum 偏节奏与承诺。角色、事件、工件提供一套固定的同步结构：在时间盒里计划、检视、调整。它回答的是——在复杂工作里，我们如何定期对齐并形成可检视的增量。

Kanban 偏流动与约束。可视化工作、显式策略、限制 WIP、管理流动。它回答的是——如何让工作以与能力匹配的速度穿过系统，并暴露瓶颈。Kanban 常常是 Lean thinking 在知识工作中的落地点，但它仍然是一套活动与策略框架，而不是价值层本身。

Scrumban 是杂交，不是第三套价值观。常见形态是保留 Scrum 的部分节奏或仪式，同时引入看板的可视化与 WIP 纪律；比例因队而异，也没有单一「正统」定义。Agile Alliance 与行业实践都把它当作演进路径或定制组合，而不是新的教派。

三者差异很大，但共享同一层职责：组织协作与流动。它们通常不规定单个工作项内部必须用什么精度的规格来驱动实现——那是下一层的事。

ScrumKanbanScrumban
主旋钮时间盒、角色、检视节奏流动、WIP、显式策略节奏与流动的组合
人明确账号与事件通过策略与协作改进按需借用哪边的结构
事儿Sprint 内的承诺与增量卡在价值流上的拉动两者兼取

工作项交付层：SDD

Spec-Driven Development 回答的是另一类问题：对单个工作项（一个需求、一个变更、一次可验收的切片），我们如何让意图足够清楚，以至于人类和 Agent 都能据此实现与验收？

核心习惯很简单：规格优先；规格过门禁再动手；变更先改规格；规格要对人和机器都可读。Thoughtworks 把 SDD 放在 AI 辅助工程实践光谱里讨论时，也强调它不必变成瀑布——规格可以小步演进，反馈仍然要短。

这里有两点常被混进框架层，需要拆开：

  1. 兼容，而非替代。 Sprint Backlog 里的条目、看板上的卡片，都可以（也应该）在拉取或开工前经过 Spec 门禁。你换不换 Scrum，和你要不要 SDD，基本正交。
  2. 颗粒度变硬了。 传统敏捷时代，一张用户故事加上口头补充，人往往还能凑合交付。Agent 对模糊的容忍度更低。「作为用户，我想要……」若止步于此，更像在喂一台高速复印机，而不是在做 SDD。工作项的边界可以仍然小——小批量没有过时——但边界内的意图需要写到可评审、可验证的程度。

SDD 管的是事儿如何被说清楚并交付；它不负责定义 Scrum Master 是否存在，也不负责规定看板有几列。那是活动框架层的设计选择。

如何叠在一起

一张可用的叠法是：

价值层：   Agile / Lean 提供取舍语言
              ↓ 指导
框架层：   Scrum / Kanban / Scrumban 组织协作与流动
              ↓ 承载
交付层：   卡片/Backlog 项 → Spec 门禁 → 实现 → 对照 Spec 验收

在 Scrum 里，Spec 评审可以落在 Sprint Planning 之前或之中；未过门禁的项不进承诺。在 Kanban 里，Spec 就绪可以是显式列策略或拉取条件——WIP 限制仍然约束「同时开工多少」，SDD 约束「开工的那一项够不够清楚」。在 Scrumban 里，两者并用：保留你需要的同步点，同时用流动纪律和规格门禁防止「忙而无效」。

对 Lead 来说，分层的实际好处是沟通成本下降：有人抱怨「仪式太多」，那是框架层问题；有人抱怨「Agent 乱写」，先查工作项层的规格是否过关；有人抱怨「我们很快但客户没感到价值」，回到价值层与价值流，而不是再买一个 AI 插件。

对实践者来说，分层意味着你不必为了做 SDD 而推翻现有看板。先让进入「进行中」的每一项带上可验收的 Spec，往往比争论「我们到底算不算敏捷」更有杠杆。

反模式

  • 用 SDD 拆掉 Scrum（或任何框架）。 规格精度解决不了跨人同步与流动可见性的问题；拆掉框架，通常只是把混乱上移。
  • 把 Kanban 理解成「不做计划」。 限制 WIP 和管理流动，恰恰是一种纪律；没有策略的看板只是贴纸墙。
  • 把 Scrumban 当成第三套价值观。 它是框架层的杂交配置，不额外发明信仰。
  • 用故事点粒度喂 Agent。 点数量度的是相对规模，不是可执行意图；规模估算替代不了规格。
  • 把大而全的 Spec 当成「更敏捷」。 规格批次过大，反馈变长，那是瀑布穿着 markdown 的衣服。小批量仍然适用——变的是批次内部的清晰度，不是批次必须变大。

收束

Agile 与 Lean 帮你判断什么叫更好。Scrum、Kanban、Scrumban 帮你把人和工作项放进可持续的协作与流动结构。SDD 帮你把结构里流动的每一项，说到足以交付——在 AI 大量参与实现时，这一点从「好习惯」变成了结构性需要。

它们不在同一层打架。把层画清楚，争论会少很多；留下的，才是真正值得做的设计选择。

参考