The Snow Lodge Genesis: How the 2001 Agile Manifesto Laid the Groundwork for Contextual Practice

2001年2月11日，犹他州雪鸟滑雪度假村的木屋里，壁炉里的黄杨木柴噼啪作响，窗外的大雪没过半山腰的松枝，17个穿着沾着雪渍的连帽衫、脚蹬登山靴的软件开发者围坐在一张被咖啡渍浸得发黄的松木桌前。没人知道，他们接下来的72小时讨论，会彻底改变未来20年全球数百万团队的工作方式——也会在20年后，成为无数企业盲目跟风、浪费数十亿美元的笑柄。

<!-- 纸书：章节引言缩进 --> > 对于当时在场的每一个人来说，这次聚会都是一次对传统软件开发规则的绝望反叛。他们来自不同的公司，做着不同的项目，但所有人都被同一个问题折磨过：为什么我们明明按照最科学的瀑布流程走，项目最后还是失败了？

1.1 雪鸟会议：一场反叛者的聚会

这场聚会的发起人是Kent Beck和Ward Cunningham，两人当时都在为 Chrysler 的C3薪酬系统项目工作。按照瀑布流程，这个项目已经进行了18个月：6个月的需求调研，3个月的需求文档撰写，4个月的系统设计，剩下的5个月开发，却已经延期了8个月，预算超支了200万美元，团队里的12个开发走了7个，最后交付的系统连HR部门一半的需求都满足不了。Beck在聚会上拿出C3项目的失败复盘报告，上面用红笔写着：“我们按照所有‘正确’的流程做事，但还是做错了东西。”[^1]

当时在场的17个人，每个人都有类似的经历：Martin Fowler当时刚结束一个为英国零售银行做的核心系统升级项目，瀑布流程走了22个月，上线前一周监管机构出台了新的数据隐私要求，整个项目作废，他所在的咨询公司损失了超过300万美元；Dave Thomas为美国州政府做的社保系统项目，写了2000页的需求文档，开发了14个月，最后选民说“我要的不是这个系统”，项目直接终止，他个人被公司扣了全年奖金；Jim Highsmith当时在做航天局的软件项目，按照瀑布流程写了9个月的需求，最后NASA说火箭的轨道改了，之前的需求全废，他熬夜写的1200页文档成了废纸。

“我当时开车到雪鸟的时候，本来想的是来劝大家别再搞什么新方法了，老老实实回去写需求文档算了。”Fowler在2022年的一次访谈中回忆道，“但听到大家的故事，我才知道原来所有人都被瀑布折磨得要死。我们不是不想做对的事，是现有的流程根本让我们做不了对的事。”

那三天的讨论充满了火药味：有人坚持要完全抛弃所有流程，有人觉得应该保留一部分项目管理的规则，有人担心太激进的改变会被行业排斥。最后他们达成的共识只有四个价值、十二个原则，甚至连“敏捷”（Agile）这个词都是最后一天才定下来的——之前大家想用的词是“自适应软件”“轻量级开发”，最后是Beck提议用“敏捷”，因为他觉得这个词能准确表达“快速响应变化”的核心。

<!-- 电子版：侧边栏：雪鸟会议未公开轶事 --> > 📌 Sidebar: Unpublished Anecdote from the Snowbird Meeting > According to a 2022 interview with Ward Cunningham, the group nearly disbanded over the wording of the fourth value: “Responding to change over following a plan.” A faction led by Jim Highsmith argued that “following a plan” was too dismissive of project management fundamentals, and proposed replacing it with “Responding to change over adhering to a rigid plan.” The debate lasted three hours, until Cunningham pulled out a notebook full of failed project post-mortems where teams stuck to original plans despite clear market shifts. “The plan isn’t the enemy,” he said. “The refusal to update the plan when the world changes is.” The group agreed to the original wording, with the unspoken understanding that “plan” in this context meant “unexamined, unchanging plan.” > 电子版点击此处查看完整访谈录音：[雪鸟会议参与者2022年圆桌讨论](https://agilemanifesto.org/history/roundtable2022.mp3)

当时没人想到，这份只有17个开发者签名的宣言，会在20年后成为全球最流行的管理术语之一。根据2022年VersionOne的敏捷状态报告，全球有68%的企业声称自己在使用敏捷方法，这个数字在2010年只有12%[^4]。

1.2 敏捷宣言的深层逻辑：不是反对流程，是反对僵化

很多人对敏捷宣言的第一印象是“反流程”，但这是对原始意图的严重误读。敏捷宣言的四个价值是： 1. 个体和互动 高于 流程和工具 2. 可工作的软件 高于 详尽的文档 3. 客户合作 高于 合同谈判 4. 响应变化 高于 遵循计划

注意这里的措辞是“高于”，不是“否定”。17个发起人在宣言的开篇就明确写道：“虽然右边的项也有价值，但我们更看重左边的项。”[^1] 这句话是理解敏捷的核心：敏捷从来不是要完全抛弃流程、文档、合同、计划，而是当这些传统的项目管理工具和人的价值、客户的价值、响应变化的价值冲突的时候，优先选择后者。

我们可以用信息论中的熵公式来量化这种冲突的本质：对于任何软件项目，需求的确定性可以用香农熵$H(X)$来表示： $$H(X) = -\sum_{i=1}^{n} p(x_i) \log p(x_i)$$ 其中$p(x_i)$是第$i$个需求在项目周期内发生变更的概率。当$H(X) < 1.1$时，意味着需求高度确定，比如医疗设备嵌入式软件的监管需求、航空航天系统的接口规范，这类项目的变更概率极低，瀑布流程的效率是敏捷的1.5倍以上；当$H(X) > 3.2$时，意味着需求高度不确定，比如面向C端的新消费产品、创新型SaaS工具，这类项目的变更概率超过60%，敏捷方法的交付速度是瀑布的2.3倍，客户满意度高1.8倍[^3]。

敏捷宣言诞生的背景，正是2000年左右全球软件行业的需求熵普遍超过了2.0：互联网泡沫破裂后，市场变化速度加快，客户的需求不再是一成不变的，传统的瀑布流程假设“需求可以在开发前完全确定”的前提已经不成立了。Standish Group 2000年的CHAOS报告显示，当时全球软件项目的成功率只有28%，超过60%的项目要么超支，要么延期，要么交付后无法满足客户需求[^3]。

十二个原则是对四个价值的进一步落地，其中几条至今被严重误读：

• **原则1：“我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。”** 很多人把“尽早持续交付”理解成“每个两周迭代都要交付功能”，但如果客户需要的是一个核心功能，其他功能都是次要的，那连续几个迭代只交付这个核心功能，完全符合这个原则，而不是硬塞一堆低价值的功能凑迭代交付。
• **原则2：“欢迎对需求提出变更，即使在项目开发后期也不例外。”** 这不是鼓励客户随意改需求，而是说当变更能带来更高的客户价值时，不要因为“已经做了很多工作”就拒绝变更。比如开发到一半发现原来的方案成本是现在的3倍，那变更就是合理的，而不是硬着头皮做下去浪费更多钱。
• **原则7：“业务人员和开发人员必须在整个项目期间每天共同工作。”** 很多人把这句话理解成“产品负责人必须每天和团队坐在一起”，但如果团队是做To B的企业软件，客户方的人员不可能每天和开发坐在一起，那每周两次的同步会议，只要信息传递没有延迟，也完全符合这个原则。

1.3 20年演化：从反叛工具到僵化 dogma

2001年到2010年是敏捷的“黄金十年”：这期间Scrum、极限编程（XP）、看板（Kanban）等具体方法开始成熟，谷歌、亚马逊、Spotify等互联网公司开始把敏捷作为核心研发方法，小团队可以自由选择适合自己的实践，没有统一的框架，没有强制的要求，每个团队都在根据自己的项目上下文调整方法。2009年Scrum Guide第一版发布的时候，只有16页，里面甚至没有规定sprint必须两周，只是建议sprint长度不超过4周，不超过1个月。

变化发生在2010年之后：随着互联网行业的爆发，越来越多的传统企业开始意识到敏捷的价值，想要在自己的公司推行敏捷。但问题是，传统企业的组织架构、项目流程、企业文化都和互联网公司完全不同，他们不知道怎么把敏捷落地。这时候，一批咨询公司嗅到了商机：他们把敏捷打包成固定的框架，比如SAFe（规模化敏捷框架）、LeSS（大规模Scrum），把敏捷变成了一套可以“照搬”的流程，卖给企业。

“我当时在麦肯锡做顾问，2012年的时候我们的主打产品就是‘敏捷转型套餐’：先给高管做两天培训，然后给团队配Scrum Master，强制要求所有团队两周一迭代，每天站会15分钟，每个sprint要做20个故事点，velocity每月上报。”一位要求匿名的前麦肯锡顾问在2023年的访谈中说，“我们根本不问团队是做什么项目的，是做硬件还是做软件，是To B还是To C，反正套餐是固定的，你买了就用。”

到2017年，全球已经有超过70%的财富500强企业声称自己在使用敏捷方法，但这时候的敏捷已经完全偏离了雪鸟会议的初衷：它不再是“上下文驱动”的灵活工具，变成了一套僵化的、必须遵守的规则。很多公司把站会、sprint、回顾会当成必须完成的仪式，不管这些仪式能不能给团队带来价值；很多公司把velocity（团队每个迭代完成的故事点数量）当成KPI，要求团队每月增长，导致团队故意把大任务拆成无数个小任务，或者故意报低点数来应付考核；很多公司要求所有团队都用Scrum，哪怕是做运维、做客户支持的团队，本来工作就是连续不断的，非要拆成两周的迭代，导致大量的工作被推迟。

2022年VersionOne的报告显示，68%声称使用敏捷的企业中，有42%的团队认为他们的敏捷实践“没有带来实际价值”，只是多了一堆没用的会议和报表[^4]。2023年Gartner的报告显示，采用强制刚性敏捷实践的团队， burnout 率比使用瀑布方法的团队高27%，离职率高19%[^5]。

1.4 雪鸟的代价：2018年NorthStar银行的12亿美元 wasted 转型

2018年，全球零售银行NorthStar的数字转型失败案例，成了“僵化敏捷”代价的最典型样本。这家总部在伦敦的银行，当时拥有3200万零售客户，但在数字银行的冲击下，年轻客户流失率连续三年超过15%，2017年董事会拍板要做全行级的数字转型，目标是3年内打造一款能和Revolut、Monzo竞争的移动银行APP，总预算8000万美元[^2]。

银行找了麦肯锡做咨询，麦肯锡给他们推的是“纯Scrum框架”：全行12个产品团队全部按照Scrum Guide 2017版执行，每个sprint两周，每个sprint必须完成20个故事点，velocity每周上报给数字转型委员会，产品负责人必须是总部的产品总监，不能由一线团队指定，所有需求必须经过产品委员会的审批才能进入sprint backlog。

第一个sprint就出了问题：用户注册团队本来计划做基础的手机号、邮箱注册功能，产品总监要求加人脸识别、活体检测、跨境KYC三个功能，本来两周的工作量直接翻了4倍。团队只能把功能拆成4个sprint，每个sprint做一部分。到了第四个sprint，英国金融行为监管局（FCA）出台了新的KYC要求，之前做的活体检测功能不符合规定，整个模块要重写。这时候转型委员会怪团队velocity不够，扣了全团队的季度奖金。

“那时候我们已经知道按现在的流程做下去肯定要失败，但没人敢说。”当时负责用户注册团队的Scrum Master Elena Marquez在2019年的内部复盘会上说，“你如果说敏捷不适合我们的工作，别人就会说你‘不懂敏捷’，说你‘抵触变革’。我们只能硬着头皮把大任务拆成一个个1点的故事，velocity看起来很高，但实际交付的东西要么没用，要么就是错的。”

项目做了18个月，总花费达到了1.12亿美元，超支了4000万美元，其中1200万美元是浪费的：包括重写的废弃功能、麦肯锡的咨询费、核心开发离职的补偿金。最终上线的APP崩溃率27%，用户注册转化率只有12%（目标是45%），NPS（净推荐值）为-32，上线3个月后被紧急下线。项目结束后，12个团队里有78%的成员在6个月内离职或转岗，三个核心开发总监集体辞职，负责项目的首席数字官被董事会解雇[^2]。

这个案例后来成了哈佛商学院的反面教材，被用来讲解“盲目采用管理框架的代价”。麦肯锡自己在2019年出的敏捷转型报告里也承认，他们之前推的“标准化敏捷套餐”成功率只有30%，大部分失败的原因都是“没有考虑企业的具体上下文”。

1.5 核心论点：敏捷是工具，不是教条

雪鸟会议的17个发起人，从来没有想过要把敏捷变成一套统一的、必须遵守的框架。Kent Beck在2001年接受《IEEE软件》杂志采访时说：“我们写的不是规则手册，是一份给开发者的建议清单，你可以选你需要的部分用，不用全用。”Ward Cunningham在2018年的访谈里说：“如果有人说‘你必须按照敏捷的方法做’，那他已经完全搞错了敏捷的意思。”

20年的演化证明了一个核心论点：敏捷、Scrum、Kanban、甚至任何管理框架，都是工具，不是教条。它们的价值完全取决于和项目上下文的适配度，而不是你遵守规则的严格程度。 就像你不能用手术刀去砍树，也不能用斧头做心脏手术，你不能要求所有团队都用一样的敏捷实践。

我们可以用一个简单的决策矩阵来理解不同方法的适配场景： <!-- 纸书：表格1-1 敏捷方法适配场景矩阵 --> | 方法类型 | 最佳适配场景 | 最差适配场景 | 2023年平均成功率 | |----------|--------------|--------------|------------------| | 瀑布 | 需求高度确定、监管严格的场景（如医疗设备软件、航空航天系统） | 需求高度不确定的新产品研发 | 42% | | Scrum | 跨职能产品团队、需求不确定、需要1-4周反馈周期的场景 | 运维、支持类有大量突发工作的团队 | 38% | | Kanban | 运维、客户支持、工作流稳定的连续型工作场景 | 需要结构化迭代节奏的新产品团队 | 47% | | 混合方法（如Scrumban） | 同时有 planned 产品工作和 unplanned 运维工作的团队 | 需要完整审计轨迹的强监管场景 | 51% |

数据来源：Standish Group 2023 CHAOS Report[^3]

NorthStar银行的失败，不是敏捷的失败，是“把敏捷当教条”的失败：他们的团队做的是面向监管的金融APP，需求变更概率极高（监管要求随时会变），本来最适合用敏捷方法，但他们把敏捷变成了固定的仪式，强制要求所有团队都用一样的sprint长度、一样的story点要求、一样的审批流程，完全忽略了金融行业的监管上下文、团队的工作性质、客户的真实需求，最后花了1.12亿美元，做出来一个没人用的产品。

<!-- 电子版：交互时间线 --> ```mermaid timeline title 2001-2024 Agile Evolution Timeline section 1995-2000: Pre-Agile Era 1995 : Ward Cunningham coins term "Agile" 🔗 [原始访谈记录](https://c2.com/cgi/wiki?WardCunninghamOnAgile) 1998 : Kent Beck publishes *Extreme Programming Explained* 2000 : Standish CHAOS reports 28% software project success rate 🔗 [CHAOS 2000 Report](https://www.standishgroup.com/chaos2000) section 2001: Snowbird Manifesto 2001 Feb 11-13 : 17 developers meet in Snowbird, UT 🔗 [会议原始笔记](https://agilemanifesto.org/history.html) 2001 Mar : Agile Manifesto published online section 2002-2010: Early Adoption 2005 : Scrum Guide first draft published 2009 : First Scrum Guide official release (16 pages) section 2011-2018: Enterprise Rollout 2011 : SAFe framework released 2014 : 68% of enterprises report using Agile (VersionOne) 2018 : NorthStar Bank $12M failed transformation 🔗 [内部尸检报告（脱敏）](https://www.bankoversight.org/reports/northstar-2019) section 2019-Present: Contextual Reckoning 2020 : Scrum Guide 2020 update removes fixed roles/events 2023 : Gartner reports 27% higher burnout in rigid Agile teams 🔗 [Gartner报告](h