从精益、敏捷到 DevOps：软件开发的方法论，为什么总在"打补丁"？

“It works on my machine.”（在我电脑上跑得好好的。）

这句话每个程序员都说过，也都听过。它是软件开发里最经典的一句甩锅台词：代码在我本地没问题，出了事，是你们环境不行。

这六个字背后，藏着软件开发方法整整半个世纪的挣扎。这篇文章想回答一个问题：为什么会有"精益"“敏捷”"DevOps"这一连串名字，它们是不同的人各说各话，还是在接力解决同一个古老的问题？

我的答案是后者。它们是一条因果链上的节，每一环都在填上一环留下的坑。

1
2
3
4
5
精益     →  "能不能少浪费一点？"
瀑布     →  "一次想清楚，赌不赌得起？"
敏捷     →  "需求会变，能不能别一次性赌全盘？"
DevOps  →  "代码写快了，但为什么上线还是慢？"
AIOps   →  "人管不过来了，让算法上。"（这是后话）

一、精益：一切演进的底色

讲敏捷之前，得先讲精益。后面所有的思想，基因里都刻着精益的四个字：消除浪费。

精益（Lean）源自制造业，最典型的是丰田。它的核心朴素得有点不起眼：用最少的资源创造最大的价值；凡是不产生价值的动作，都是浪费，都要被干掉。

戴明（W. Edwards Deming）的全面质量管理，给这套思想加了一个关键机制：持续改进。不指望一步到位，而是小步、循环、不断优化。这里藏着一个伏笔：精益从来不追求"完美地规划"，它追求的是"持续地变好"。

理解到这里就够了。不用记 PDCA、改善这些词，它们只是"持续改进"这套动作的不同叫法。

精益为什么重要？它提供了一个后来被反复套用的判断坐标：任何流程里，谁在创造价值，谁在空转。这个坐标，是敏捷和 DevOps 共同的原点。

二、瀑布：一个曾经完美、今天人人喊打的方案

在精益进入软件之前，软件工程的主角是"瀑布模型"。

1970 年，Winston Royce 在论文里系统描述了这套流程：

1
2
flowchart LR
  A[需求] --> B[分析] --> C[设计] --> D[实现] --> E[测试] --> F[维护]

像水一样，自上而下，不可逆。前一阶段不结束，后一阶段不开始。

今天我们提起瀑布，几乎都当反面教材。但瀑布在当时是合理的，甚至今天在某些场景下依然是最稳的打法。

它的假设是：需求是确定的、能一次性说清楚的。如果真能满足，比如给银行重写一套几十年前就定死的清算系统，瀑布反而是最稳妥的选择。

问题在于，软件行业最大的事实恰恰相反：需求几乎永远在变。用户自己都不知道自己要什么，直到他看见第一版。瀑布的致命伤也就暴露了：它把所有"验证"都压到了最后。分析错了、设计偏了，当时没人发现，一路闷头做到测试阶段才炸出来，而那时返工的代价已经是天价。

一句话：瀑布赌的是"我能一次想清楚"，可现实是，没人能一次想清楚。

三、敏捷：把验证提前，小步快跑

既然赌不起"一次想清楚"，那能不能反过来，走一步看一步？

这就是敏捷（Agile）的核心逻辑：把一个大项目拆成一堆短周期（迭代），每个周期都走完"设计 → 开发 → 测试"的完整闭环，产出一个能跑的版本，快速扔到用户面前收反馈。

1
2
3
flowchart LR
  A[分析] --> B[计划] --> C[设计] --> D[开发] --> E[测试] --> F[部署]
  E -->|反馈调整| C

对比瀑布，本质区别就一个：验证被提前了。风险不再是"最后一起炸"，而是"每个短周期都炸一次，但每次都便宜、都好修"。

2001 年的《敏捷宣言》背后有 12 条原则，我不全背，挑三条真正改变规则的点透：

  1. "可工作的软件"是唯一真实的进度标准。进度条、文档、周报都不算数，代码真的能跑起来才叫进度。这是对瀑布"文档即进度"最彻底的反叛。

  2. 拥抱变化，哪怕在开发后期。瀑布把变化当敌人，敏捷把变化当资源：需求变了不是坏事，说明你对用户的理解更准了一点。

  3. 自组织团队。最好的方案不来自上面拍板，而来自被充分信任、能自己做主的团队。

敏捷听起来很美，但接下来要说的问题更扎心：敏捷这么好，为什么绝大多数团队落地时都"念歪了经"？

四、伪敏捷：比不懂更糟的事情

这一章可能有点冒犯，但它是我认为整套内容里最有价值的部分。

敏捷的初衷是"信任 + 自主 + 快速反馈"。很多公司的落地，变成了下面这副样子：

第一，把仪式当成了敏捷本身。以为敏捷 = 早上开个站会 + 墙上贴个看板 + 每周来场例会。仪式照搬了，文化没跟来，俗称"照葫芦画瓢"，只学了个壳。

第二，把工具变成了监控。很多团队没有专职的敏捷教练，让项目经理（PM）兼着。PM 骨子里的思维是"自上而下管控"，于是站会变成了逼问进度的批斗会，看板变成了考勤监视器。

第三，“既要又要"的假敏捷。敏捷的本质是"固定节奏、灵活调整交付范围”。但管理者往往既卡死上线时间，又强塞全部需求，两个都要的结果是团队被活活逼死。

第四，砍质量换速度。只学"小步快跑"的表象，把单元测试、代码评审、重构的时间全砍了。短期看着快了，欠下的债会在几个月后连本带利要回来，后续迭代寸步难行。

你会看到一个讽刺的循环：企业发现敏捷"没用"，于是加码更严的管控，比如要求程序员每天手写日报。而这恰恰是最反敏捷的行为：它既浪费了时间（违背"消除浪费"），又用"日报"替代了"可工作的软件"这个唯一真实的进度标准。

这一章我想下一句自己的判断：

伪敏捷比不懂敏捷危害更大。不懂的人至少承认自己不懂；而伪敏捷让你误以为自己在"做敏捷"，于是把所有失败都归咎于"敏捷这方法不行"。

五、部门墙：敏捷解决不了的那堵墙

退一步假设：你的团队是真敏捷，两周一迭代，代码哗哗地往外冒。然后呢？

然后你会撞上一堵新的墙，那堵墙叫上线。

  • 开发者想要的是"快和变"：功能越快上线越好。
  • 运维的 KPI 是"稳"：每一次发布，在我眼里都是事故风险，所以我要审批、要流程、要慢一点。

这堵墙不是我编的，它有名字：部门墙。开发写完代码，往墙那边一扔就没我事了；运维接住这包代码，火就起来了。这才有了开头那句 “It works on my machine”，才有了那张经典表情包：

着火的房子前，一个小女孩狡黠地笑：“WORKED FINE IN DEV. OPS PROBLEM NOW.”

翻译过来就是：我本地跑得好好的，现在着火了，是运维的问题。

这堵墙不是谁坏，是 KPI 的目标冲突。开发被考核"交付速度"，运维被考核"系统稳定"，两个目标天然打架。所以在组织结构上，他们必然互相防守：墙是"长"出来的，不是谁故意砌的。

敏捷从头到尾，解决的都是研发端的效率。它让写代码变快了，却根本没碰"代码怎么上线、上线之后怎么稳定"这一段。这是敏捷的边界，也是 DevOps 登场的理由。

小结与预告

把这条线捋一遍：

  • 精益给了我们判断坐标：消除浪费。
  • 瀑布赌"一次想清楚"，输给了变化。
  • 敏捷用"小步快跑 + 提前验证"接住了变化，但只管到了研发端。
  • 伪敏捷是落地的现实，它提醒我们：改流程容易，改信任和考核难。
  • 部门墙是敏捷的地盘到头的地方，代码能写快，上线快不了。

下一篇讲 DevOps 是怎么敲掉这堵墙的，以及更讽刺的：当 DevOps 终于让发布快起来之后，运维自己反而被压垮了。这才有了最后一块拼图：AIOps。