第 2 章 · 过程模型:从瀑布到敏捷

过程模型回答的问题:项目按什么节奏推进、每个阶段做什么、阶段之间怎么衔接。从瀑布到敏捷再到 DevOps,七十年的演化史其实就是对第 1 章那个「易变性」病灶的应对史。本章把主流模型各自讲透,最后给一张「什么场景选什么」的决策表,以及我对「 agile 是否万能」的看法。

2.1 瀑布:把工程纪律带给软件

瀑布模型(Waterfall,Royce 1970 提出,后被过度简化)把项目切成线性阶段:

需求 → 设计 → 实现 → 测试 → 部署 → 维护
      每阶段有明确的进入/退出条件,文档齐全

优点真实存在:计划清晰、里程碑可考核、文档完整(接手的人有据可查)。适用场景:需求极其稳定且明确——航天控制软件、医疗设备的嵌入式系统(改需求成本极高、要过认证)。缺点在 1.1 说过了:它假设「需求期就能想对」,而大多数商业软件做不到。用瀑布做互联网产品 = 把所有理解错误的成本攒到最后一次性爆发。

历史上瀑布被骂过头了。它的问题从来不是「阶段划分」本身,而是拒绝回溯(变更来了当敌人)和反馈太晚(用户两年后才见到东西)。

2.2 迭代与增量:把大风险切成小份

瀑布的修正案是一对概念:迭代(iterative,每轮把系统做深一点)和增量(incremental,每轮把系统做宽一点)。原型法(prototyping)是迭代的特例:快速做个「假系统」给用户看,验证理解,再扔掉或演化。这些思想共同奠定了敏捷的地基:小步快跑、快速反馈。

螺旋模型(Boehm)把「每轮迭代带一次风险评估」制度化,是风险驱动开发的祖师;RUP(Rational 统一过程)把瀑布的角色塞进迭代的框架(每轮都有一点需求、设计、实现、测试)。它们都是过渡形态,直到敏捷宣言。

2.3 敏捷:宣言与具体实践

2001 年,17 位方法论作者发布了敏捷宣言,四条价值观值得原文级别地记:

个体和互动高于流程和工具可工作的软件高于详尽的文档客户合作高于合同谈判响应变化高于遵循计划 (右项有其价值,左项更重要)

注意宣言的克制:右项「有其价值」,敏捷反对的是本末倒置,反对文档本身。具体的敏捷实践以 Scrum 为代表:

固定节奏的冲刺(Sprint,通常 2 周):每轮交付一个可用的增量;
冲刺工件:产品待办列表(Product Backlog,按价值排序的需求池)、冲刺待办、可交付增量;
三个角色:产品负责人(PO,定优先级)、Scrum Master(除障碍,不等于项目经理)、开发团队(跨职能自组织);
五个会议:计划会、每日站会(15 分钟,三句话:昨天干了啥/今天干啥/有啥障碍)、评审会(给用户演示)、回顾会(复盘流程本身)。

理解 Scrum 的正确姿势是问「每个仪式在解决什么问题」:站会解决「障碍暴露不及时」,回顾会解决「流程本身不变」,评审会解决「用户反馈太晚」。只抄仪式不解决问题,就是业界嘲笑的「形式敏捷」(Cargo Cult Agile):站会站了,障碍还是不说;冲刺排了,需求还是两周改一轮。

2.4 DevOps:交付环节的敏捷化

敏捷解决了「开发节奏」,但代码写完到上线还有一堵墙(开发与运维的部门墙)。DevOps 主张打通它,技术杠杆是 CI/CD(第 10 章详讲):提交即构建、即测试、即部署,「可工作的软件」以分钟级频率抵达用户。DevOps 是敏捷思想从开发环节向运维环节的延伸,实践标志是:部署频率高(天/小时级)、失败恢复快、变更失败率低。

2.5 选型:没有最好的模型,只有匹配的

你的项目	适合	理由
需求稳定、安全认证(航天/医疗)	瀑布(改良版)	变更成本 >> 反馈延迟成本
互联网产品、需求混沌	敏捷(Scrum 系)	快速反馈消化易变性
探索性研究、技术验证	原型/螺旋	目标是「学习」而非「交付」
运维重的长周期系统	DevOps + 精益	持续交付压低每次变更的风险

两个诚实的提醒。其一,敏捷需要纪律:小步提交、测试覆盖、持续集成,哪个都是硬功夫,团队没这些底盘时强推敏捷 = 每两周一次的混乱。其二,「大项目用瀑布、小项目用敏捷」是常见误解;规模不是分界线,需求稳定性才是。银行核心系统需求也稳定,一样能瀑布;三人的 App 需求天天变,照样敏捷。

常见错误

把 Scrum 当银弹照搬。仪式齐全,价值全无;先问「这个会解决什么问题」,答不上来的会砍掉。
冲刺里塞需求。冲刺中途 PO 往里加活,节奏崩坏;新需求进 backlog 排下一轮,这是纪律。
「敏捷 = 不要文档」。设计文档该写还得写(第 4 章),只是「为写而写」的文档被正当地淘汰了。
把每日站会开成汇报大会。站着、15 分钟、三句话、问题会后单聊,走样即失效。

练习

动手:给你正在做的课设写一份两轮 Sprint 计划:backlog(按价值排序的 10 条)、每轮 Sprint 的目标与验收标准。对比「想到哪写到哪」的原计划。
思考:你的团队若推行每日站会,第一天会发生什么?列出三个可能走样的点(参考 2.3),并给每个点写一条「防止走样」的约定。
手算:一个 6 个月的瀑布项目,需求理解错误在第 1 个月发生、第 6 个月被发现,修复成本按 10 倍每阶段涨。估算同样错误在「两周迭代 + 每轮用户评审」下的修复成本比。
思考:DevOps 号称消除开发与运维的墙。结合第 10 章将学的 CI/CD,思考「墙」的另一面:分离的运维团队保护了生产环境的稳定,合并后这个保护由什么机制接替(提示:自动化测试、灰度发布、回滚)。