敏捷祛魅：别再把敏捷当成教条

2023年夏天，我拜访了一家国内头部的在线教育公司，他们的产品总监小周拉着我吐槽了一下午：“我们去年全面推行Scrum，站会、迭代、回顾会一个不落，Jira里每个任务都拆到颗粒度不超过8小时，结果呢？用户投诉率涨了30%，核心功能上线时间比之前还晚了20%，老板问起来就是‘敏捷落地不够彻底’，你说我们冤不冤？”这样的场景并不罕见。过去十年，敏捷几乎成了互联网行业的“政治正确”：提敏捷就是先进，不推敏捷就是落后，但很少有人愿意停下来问一句：我们到底为什么要做敏捷？敏捷真的能解决所有问题吗？

要回答这个问题，我们得先把贴在敏捷身上的各种标签撕掉——它不是“快”的代名词，也不是“不用写文档”的借口，更不是一套必须严格遵守的教条。敏捷的本质，是一套人类面对不确定性时总结出的生存策略，它的出现有非常具体的时代背景，它的适用边界也非常清晰，把它当成万能药，最后只会吃出病来。

1.1 敏捷诞生的前夜：瀑布模型的黄昏与软件行业的至暗时刻

要理解敏捷，得先回到20世纪90年代的软件行业，那是瀑布模型的黄昏，也是整个行业的至暗时刻。

彼时的软件开发行业，瀑布模型是绝对的主流。这种线性流程的逻辑非常简单：先做完整的需求调研，再做系统设计，然后进入开发阶段，开发完进入测试，测试通过后上线，每个环节都有明确的交付物和准入准出标准，就像瀑布的水流一样从上到下不可逆。这种模式在20世纪70到80年代非常适用——当时的软件项目大多是To B的大型系统，比如银行的 core 系统、航空公司的票务系统，需求非常稳定，变更成本极高：给银行做个核心交易系统，改一个逻辑bug可能需要经过层层审批，成本高达数十万，甚至可能影响资金安全，所以前期把需求定死是最优选择。

但到了90年代，整个行业的天变了。互联网泡沫的兴起让软件项目的复杂度呈指数级上升，需求从“稳定”变成了“爆炸式变化”：你做一个门户网站，今天老板说要加个论坛板块，明天运营说要加个会员体系，后天产品说要接第三方支付，每个需求的变更都意味着前期的设计要推倒重来。根据全球知名的软件研发咨询机构Standish Group发布的1994年CHAOS报告¹，当时美国软件项目的成功率仅为28%，超过一半的项目会彻底失败，剩下20%的项目要么超支、要么延期、要么交付后无法使用，总损失高达上千亿美元。

瀑布模型的问题在这种环境下暴露无遗：它的核心假设是“需求可以在前期被完整定义”，但面对快速变化的市场，这个假设根本不成立。你花了6个月做需求调研，等开发了3个月，市场已经变了，当初定好的需求早就没人要了。更讽刺的是，当时很多公司为了“符合瀑布规范”，硬逼着团队在需求阶段写几百页的PRD，哪怕明知道需求会变，也要走完流程，最后做出来的东西完全是废品。

这种困境催生了行业里的各种“地下实践”：很多聪明的团队开始偷偷砍流程，不做 exhaustive 的需求调研，先做个最小可用版本扔给用户试，根据反馈快速调整，这种“野路子”的效果反而比按瀑布流程走好得多。2001年2月，17位来自不同公司的敏捷方法实践者——包括极限编程（XP）的创始人Kent Beck、Scrum的联合创始人Jeff Sutherland、设计模式的提出者Erich Gamma等——在犹他州雪鸟滑雪胜地凑在一起，本来是想滑雪放松，结果聊着聊着发现大家都在用类似的轻量方法应对瀑布的失效，干脆一起写了那篇被后世嚼烂了的《敏捷软件开发宣言》。

很多人把这份宣言当成敏捷的“圣经”，但它的诞生其实非常随意：没有学术委员会的评审，没有行业标准的流程，就是一群被瀑布折磨得够呛的从业者，把自己实践出来的经验总结成了四条价值观和十二条原则。它的初衷从来不是制定一套必须遵守的规则，而是给那些被瀑布困住的团队提供一个“另一种选择”。

1.2 被误读的敏捷内核：四大价值观与十二条原则的真实诉求

过去二十年，无数培训机构把敏捷宣言的条文掰开了揉碎了讲，但大部分讲法都走入了两个极端：要么把它当成神圣的教条，要求团队逐字逐句遵守；要么把它当成“反流程”的工具，用来给团队偷懒找借口。实际上，敏捷四大价值观和十二条原则的每一句话，背后都有非常具体的现实诉求，我们逐条拆解，你会发现它们和你平时听到的解读完全不一样。

1.2.1 四大价值观：不是非此即彼，而是权衡取舍

宣言的四条价值观是：“个体和互动高于流程和工具；可工作的软件高于详尽的文档；客户合作高于合同谈判；响应变化高于遵循计划。”很多人把“高于”理解成“替代”，这是最大的误解。

> 📌 电子版侧边栏：关于“高于”的正确理解 > “高于”不是“不要”，而是“优先级排序”：当两者冲突时，优先选前者，但后者并不是完全没用。 > 比如“个体和互动高于流程和工具”，不是让你废除所有流程和工具，而是别为了流程工具把人搞僵：如果你的团队用Jira必须填10个字段才能提交任务，填不完就不让开工，那流程就变成了阻碍，这时候应该优先考虑人的效率，而不是流程的完整性。

举个例子，“可工作的软件高于详尽的文档”的真实诉求是什么？是90年代很多团队为了符合瀑布规范，花了半年写几百页的PRD，最后做出来的软件根本没人用，文档写得再好看也没价值。但这句话从来不是让你不写文档——你做一个ToB的客户管理系统，用户操作手册、运维手册、接口文档该写还是要写，不然出了问题没人能解决。敏捷文档的核心原则是“刚好够用”：能口头说清楚的就不用写，必须写的就写最简版本，别为了文档而文档。

再比如“响应变化高于遵循计划”，很多人理解为“不用做计划”，这完全是歪解。它的真实诉求是：在需求不确定的场景下，死守前期做的计划只会导致更大的损失。比如你做一个电商大促的活动，计划了所有环节，结果大促前一天平台出了个bug，你还非要按原计划上线，最后只会造成更大的损失。敏捷要的不是没有计划，而是计划要有弹性，能跟着变化快速调整。

1.2.2 十二条原则：不是行为规范，而是问题导向

十二条原则是宣言的补充，每一条都是为了解决当时软件行业的具体问题，而不是给团队套枷锁。我们挑几个被误解最多的原则讲：

• **“我们最优先的任务是通过尽早地、持续地交付有价值的软件来使客户满意”**：很多人把“尽早持续交付”理解成“不停加班赶功能”，但它的核心是“有价值的软件”——你交付10个没人用的功能，不如交付1个用户真正需要的功能。敏捷反对的是“憋大招”：花半年做一堆功能，上线才发现用户不需要，不如每两周交付一个小版本，快速拿用户反馈。
• **“业务人员和开发人员必须在整个项目期间每天共同工作”**：这不是要求产品经理天天坐在研发旁边，而是强调沟通的效率：很多项目失败就是因为业务和研发信息不对称，业务觉得研发做的东西没用，研发觉得业务提的需求不合理，每天共同工作的核心是减少信息差，而不是搞形式主义。
• **“简单——使未完成的工作最大化的艺术是根本”**：这不是让你偷懒，而是反对“镀金”：很多团队为了凑KPI，硬加一堆没用的功能，反而增加了系统的复杂度，后面改bug的成本更高。敏捷要的是做“刚好够用”的功能，别做多余的事。

你会发现，敏捷的所有原则，本质上都是在解决“不确定性”带来的问题：需求不确定怎么办？那就快速交付、快速拿反馈；沟通成本高怎么办？那就让业务和研发天天聊；变更成本高怎么办？那就把变更的成本降到最低，别攒到最后一起改。它不是一套“必须这样做”的规则，而是一套“遇到这类问题可以这样解决”的工具箱。

1.3 敏捷的适用边界：不是所有项目都适合敏捷

如果敏捷是万能药，那瀑布早就该被淘汰了，但事实是，直到现在，瀑布模型在很多领域依然是主流。原因很简单：敏捷有非常明确的适用边界，超出了这个边界，敏捷的效率还不如瀑布。

要理解这个边界，我们得先搞清楚一个核心概念：项目的需求确定性。需求确定性越高，变更成本越高，越适合用瀑布；需求确定性越低，变更成本越低，越适合用敏捷。

我们可以用一个表格来直观对比不同项目的适用方法论： | 项目类型 | 需求确定性 | 变更成本 | 推荐方法论 | 典型案例 | | --- | --- | --- | --- | --- | | 航天发射系统 | 极高 | 极高（涉及生命安全，改一个参数可能造成火箭爆炸） | 瀑布 | 阿波罗登月计划 | | 核电建设 | 极高 | 极高（改一个设计可能造成核泄漏） | 瀑布 | 华龙一号核电站建设 | | 固定需求外包项目 | 中高 | 中高（合同锁定需求，变更需要额外付费） | 瀑布/混合 | 政府政务系统定制 | | 互联网C端产品 | 低 | 低（改个功能只需要上线个版本） | 敏捷（Scrum/看板） | 抖音、微信的功能迭代 | | 企业级SaaS | 中 | 中（客户需求相对明确，但需要持续迭代） | 混合/看板 | 飞书、Salesforce | | 消费电子硬件研发 | 中高 | 高（硬件开模成本极高，改一个设计需要几十万） | 混合（瀑布+敏捷） | 新能源汽车研发 |

举几个典型的例子：

• **航天、核电、基建类项目**：这类项目的需求几乎100%确定，变更成本高到无法承受，用敏捷反而会出问题。比如阿波罗登月计划，总共涉及400多万人、几万个零件，每个环节的参数都必须精确到小数点后几位，任何一个小的变更都可能造成 mission failure，这种情况下，按流程一步步走，每个环节留痕、验收，才是最高效的选择。你要是跟登月项目的工程师说“我们敏捷一点，先做个最小版本扔上去试试”，人家只会觉得你疯了。
• **固定需求的外包项目**：很多外包合同会明确写明需求范围，变更需要额外付费，这种情况下如果用敏捷，客户提个需求你就改，最后只会导致项目范围无限扩大，双方扯皮。比如某地方政府做一个政务系统，合同里写死了所有功能，要是你用敏捷，每两周就给客户看个半成品，客户只会觉得你能力不行，连个完整系统都做不出来。
• **团队能力不足的场景**：敏捷要求团队有较高的自组织能力和业务理解能力，如果你的团队都是刚入行的新人，连需求都理不清，你上敏捷只会让团队更混乱。比如我之前接触过一个创业团队，总共3个开发，产品经理刚毕业，什么都不懂，非要上Scrum，每天站会就是开发跟产品吵架，最后项目黄了。

还有一种常见的误区是“大公司必须敏捷，小公司必须快”，其实也不对：比如某银行的核心交易系统，涉及上亿用户的资金安全，需求非常稳定，变更成本极高，就算公司再大，用瀑布也是最安全的选择；而一个只有5个人的创业团队，做的是一个全新的产品，需求完全不确定，就算公司再小，用敏捷也能更快找到方向。

1.4 敏捷的最大敌人：教条主义与“为了敏捷而敏捷”的荒诞剧

如果说瀑布的失效是敏捷诞生的土壤，那现在敏捷领域最大的毒瘤，就是教条主义。过去十年，我见过太多团队把敏捷的实践当成了不可违背的规则，完全不管自己的业务场景，最后落得“为了敏捷而敏捷”的下场，甚至比不用敏捷还惨。

教条主义的本质，是把“手段”当成了“目的”：敏捷本来是为了解决业务问题，结果大家为了“符合敏捷规范”，把敏捷的仪式、实践当成了KPI，完全忘了最初的目的是把事做成。

1.4.1 教条主义的四大典型表现

我总结了教条主义的四个常见表现，几乎每个被敏捷折磨过的团队都中过招： 1. 仪式教条：把敏捷的仪式当成必须完成的KPI。比如有的团队不管成员是不是在同一个时区，非要每天开站会，跨国的团队凌晨三点爬起来开会，白天根本没精力干活；还有的团队必须双周迭代，哪怕项目下周就要上线，非要拆成两周，硬拖进度；更有甚者，站会必须卡15分钟，超时就罚做俯卧撑，大家为了不超时，不敢说真问题，站会变成了汇报会。 2. 角色教条：硬凑敏捷的三个角色。Scrum要求有产品负责人、Scrum Master、开发团队三个角色，很多公司不管自己有没有这个条件，硬要设这三个岗：没有懂业务的产品经理，就找个刚毕业的产品当“产品负责人”，结果连需求都理不清；没有合适的Scrum Master，就找个老研发兼任，结果Scrum Master变成了“催更专员”，每天只会催站会、催迭代，完全没起到移除团队障碍的作用。 3. 工具教条：把工具当成敏捷本身。比如很多团队觉得“用Jira就是敏捷，用物理看板就是不够敏捷”，非要给3个人的小团队配复杂的Jira系统，每个任务必须填10个字段，每周花5个小时维护Jira，真正干活的时间反而少了；还有的团队觉得“必须用故事点估算才是敏捷”，哪怕需求根本不清晰，估出来的点数完全不准，还要硬套，最后为了凑点数，大家把1天的工作拆成3天，反而拖慢了进度。 4. 实践教条：硬套不适合自己的实践。比如很多团队不管项目类型，非要搞测试驱动开发（TDD）、持续集成，哪怕是一个两周就结束的外包项目，非要写单元测试，最后交付时间推迟，客户不满意；还有的团队非要写用户故事，哪怕需求非常简单，写用户故事的时间都比开发时间长。

1.4.2 教条主义的真实案例：上亿损失的敏捷闹剧

2019年，国内某头部电商平台为了“全面落地敏捷”，要求所有业务线必须100%按Scrum规范执行：所有团队必须设专职Scrum Master，必须双周迭代，所有任务必须进Jira，每个任务的颗粒度不能超过8小时，迭代结束必须开评审会和回顾会。听起来很完美，但执行起来完全变味：

他们的支付团队当时正在修一个核心支付的漏洞，这个漏洞如果爆发，会导致大促期间用户支付失败，损失至少上亿。但团队为了符合“双周迭代”的规范，硬是把漏洞修复拆成了两个迭代，第一个迭代修了80%，剩下20%要等下一个迭代。结果漏洞在迭代结束前爆发，大促期间支付失败率高达15%，直接损失超过2亿，后续用户流失带来的损失更是不可估量。

事后复盘的时候，团队负责人说：“我们知道漏洞必须马上修，但公司规定必须按迭代走，不能随便改迭代范围，我们也没办法。”这就是教条主义的典型后果：为了符合规则，忘了做事的初衷。敏捷本来是为了更快响应变化，结果被规则绑住，反而错过了最好的应对时机。

1.4.3 教条主义的根源：把敏捷当成了“政治正确”

为什么这么多团队会陷入教条主义？最根本的原因是，过去十年，敏捷被太多培训机构、咨询公司包装成了“解决所有问题的灵丹妙药”，甚至成了很多公司判断团队“先进与否”的标准：你上了敏捷就是好团队，没上就是落后，至于敏捷能不能解决你的问题，没人关心。

很多公司的老板和管理者，并不懂敏捷的本质，

很多公司的老板和管理者，并不懂敏捷的本质，只看重表面的仪式和工具，把“有没有站会、有没有用Jira、有没有做迭代”当成衡量敏捷落地的标准，完全不关心这些实践能不能解决业务问题。这种认知偏差的来源有两部分：一部分是过去十年敏捷培训市场的过度包装，把敏捷塑造成了一个“只要照着做就能成功”的标准化产品，忽略了场景适配的核心；另一部分是管理层的“懒政”——比起花时间理解团队的实际问题，直接套用一套现成的规则显然轻松得多，哪怕这套规则根本不适合自己的业务。

国内某头部敏捷咨询公司2022年发布的《敏捷落地白皮书》中，甚至把“Scrum实践覆盖率”当成核心考核指标，要求客户团队的站会出勤率、Jira任务填写率、回顾会召开率都要达到100%，完全没提业务场景的差异。他们曾给一家做轨道交通信号系统的传统企业推这套方案，要求双周迭代、用户故事、故事点估算，结果这个项目的需求是国家标准规定的，任何一个参数的变更都要经过层层审批，成本高达百万，双周迭代根本跑不起来，团队花了半年时间，交付的版本比之前用瀑布模式做的还慢30%，最后客户终止了合作，咨询公司反而甩锅说“客户的变革意愿不足”，完全没反思自己的方案是否适配。

教条主义的危害远不止耽误进度、造成损失这么简单，它还会从根本上摧毁团队的信任和积极性。当敏捷的实践变成了KPI和惩罚工具，团队就会开始“表演敏捷”：站会只说好消息，不敢说问题，因为说问题会被认为“迭代进度落后”；回顾会只提不痛不痒的问题，不敢说真话，因为提了真问题也不会改，反而会被穿小鞋；任务故意拆得很大，因为拆小了会被认为“工作量不饱和”。我之前接触过的一个电商团队，为了符合“任务颗粒度不超过8小时”的要求，开发人员把一个1天就能做完的任务拆成了3个8小时的小任务，每天站会都同步“还在做第一个任务”，结果本来3天能做完的功能，硬生生拖了10天，迭代延迟率高达60%，团队怨声载道，管理者反而觉得“敏捷落地还是不够彻底”，完全不知道问题出在自己身上。

我后来再拜访开头提到的在线教育公司小周的时候，他们已经彻底放弃了之前的教条式敏捷落地：不再强制要求所有团队统一双周迭代，内容团队因为要配合运营的营销节奏，改成2周迭代，技术团队因为要做底层架构优化，改成3周迭代；站会也不再强制每天开，改成异步站会，团队成员每天在群里同步进度，有问题再拉小会讨论，不用所有人凑在一起耗时间；Jira的任务字段也从10个砍到3个，只填任务名称、优先级、负责人就行，不用填一堆没用的信息。调整了半年之后，他们的用户投诉率降了15%，核心功能的上线时间比之前还提前了25%，老板再也没提过“敏捷落地不够彻底”的话。小周跟我说：“现在我们才知道，敏捷不是要符合什么规范，而是要真的能帮我们解决问题。”

1.5 敏捷的本质：面对不确定性的生存策略

把贴在敏捷身上的所有标签撕掉之后，我们会发现，敏捷的本质从来不是某一种具体的方法（比如Scrum或看板），也不是某几个仪式或工具，而是一套人类面对不确定性时总结出的响应策略。它的核心逻辑可以用一个简单的感知-响应循环来描述：

```mermaid graph LR A[感知环境变化<br>（用户反馈/市场变化/技术问题）] --> B[评估变化影响<br>（价值/成本/优先级）] B --> C[调整行动策略<br>（变更需求/调整优先级/修改计划）] C --> D[交付最小可行价值<br>（最小版本/最小功能）] D --> E[获取反馈<br>（用户数据/业务反馈/测试结果）] E --> A ```

这个循环的核心是“小步快跑，快速反馈”：不要试图一次性把所有事都做对，而是先做最小的可行版本，拿到反馈之后再调整，避免在不确定的方向上浪费太多资源。这和生物进化的逻辑一模一样：生物不会一次性进化出完美的特征，而是通过一代代的变异、选择、迭代，慢慢适应环境。敏捷的本质就是把这个进化逻辑用到了项目管理和产品研发中。

我们可以用信息熵来量化需求的不确定性，从而更清晰地判断什么时候该用敏捷，什么时候该用瀑布。假设一个项目的需求有$n$种可能的形态，每种形态的概率为$p_i$，那么需求的不确定性可以用以下公式计算： $$H(X) = -\sum_{i=1}^{n} p(x_i) \log p(x_i)$$ 当$H(X)$越高，说明需求的不确定性越大，越适合用敏捷方法；当$H(X)$越低，说明需求越确定，越适合用瀑布模型。比如做一个标准化的OA系统，需求的可能性只有3种：符合要求、不符合要求、需要小调整，$H(X)$非常低，适合瀑布；而做一个C端社交产品，需求的可能性有几十上百种，$H(X)$非常高，适合敏捷。

1.5.1 敏捷的三大常见误解澄清

过