第2章 运行图：生命周期模型选型

第 2 章 · 运行图：生命周期模型选型

章节摘要：同一套站点（需求、设计、编码、测试、发布），可以按完全不同的节奏串起来：一张时刻表跑到底，或者切成小段公交化发车。本章把六种主流生命周期模型当作六张运行图逐一拆解——瀑布的单程直达、迭代与增量的区间接续、螺旋与 V 模型的带检修位线路、敏捷的公交化小班次、DevOps 的信号联锁一体化。每种模型我们都回答同样的问题：它假设需求有多稳定？风险什么时候暴露？适合什么规模与什么团队？读完你应当能为手头的项目选出运行图，并说清为什么不是另外几张。

学习目标

读完本章，你应当能够：

1. 说出瀑布、迭代增量、螺旋、V、敏捷、DevOps 各自的核心假设与适用前提。
2. 用"需求稳定度、风险暴露时机、交付节奏"三个维度对比任意两种模型。
3. 判断一个项目何时适合瀑布——并说清这不算落后。
4. 解释增量与迭代的差别，避免在排期时把两者混用。
5. 看懂一个 Scrum 团队的迭代仪式清单，知道每个仪式在防哪类事故。
6. 描述 DevOps 与敏捷的接续关系：它改的是开发段还是全线路。

核心概念速览

生命周期模型回答的是"阶段怎么串、反馈多快回来"。第 1 章的阶段序列是标准站点，本章的六张运行图都是对这些站点的不同调度方式。下面这张演进脉络图按时间与思路展开：从严格串行，到加入风险与验证环节，再到缩短反馈周期、打通开发与运营。

金句：运行图没有优劣，只有合不合线路——把高铁时刻表套在乡间便线上，才是事故的开始。

选择模型的三个判断维度贯穿全章：一是需求稳定度，需求是否可能在中途大改；二是风险暴露时机，技术不确定性能不能被推迟；三是交付节奏，业务能否接受大版本集中交付。任何模型的选择争议，最终都会落到这三个问题上。

子章节导航

• 2.1 瀑布模型：单程直达列车——阶段一次走完、文档逐段冻结，适合需求稳定、合规严格的线路。
• 2.2 迭代与增量：区间接续发车——把大旅程切段，厘清"迭代"与"增量"这对常被混用的词。
• 2.3 螺旋与 V 模型：带检修坑位的线路——前者用风险分析决定下一圈跑多远，后者让每级开发都有对位的验证站台。
• 2.4 敏捷开发：公交化小班次——短周期、可交付增量加固定仪式，以及它对团队成熟度的隐性要求。
• 2.5 DevOps：信号联锁一体化——把反馈回路延长到线上运营，让"开发完"与"跑得稳"变成一件事。

子章节之间的逻辑关系

六节不是并列菜单，而是一条演进链：瀑布暴露"反馈太晚"，迭代增量缩短回路；螺旋与 V 分别补上风险与验证两个短板；敏捷把短回路变成制度；DevOps 把回路延伸到线上。理解每一张图补了前一张的什么缺口，比背定义有用得多。

  瀑布 ──反馈太晚──► 迭代增量 ──风险与验证缺口──► 螺旋 / V
    ▲                                                  │
    │                                              流程落制度
    │                                                  ▼
  DevOps ◄──回路再延长到线上运营──── 敏捷（小班次制度）
​

选型速查卡

为方便查阅，把全章的选型逻辑压成一张速查卡：需求由法规或行业标准冻结、验证一次代价极高——瀑布；规模大可分块、每块能独立验收——迭代与增量打底，技术路线没把握叠螺旋、验证有合规要求叠 V；需求多变、要靠使用逼近真相、团队有自动化底盘——敏捷小班次；发车间隔还想再压缩、开发与运营隔着一堵墙——DevOps 联锁。判断时先过"团队规模与自动化底盘"这道资格审查，再谈模型偏好——底盘不匹配的模型，再先进也是负资产。

本章演练任务

两道题检验本章收获。其一，为你当前的项目按"需求稳定度、风险暴露时机、交付节奏"三个维度打分，对照速查卡选出运行图，并写一段"为什么不选另外两张"的说明——排除项写不清楚，说明模型还没读懂。其二，观察一次你所在团队最近的发布争议，判断它实质上是哪一类"前一张图补的缺口"没有被补上。

前置知识与后续延伸

需要第 1 章的生命周期阶段图作底子，再无其他硬前置。本章选定的运行图将在第 3 章展开成一趟列车的完整旅程；第 4 章调度台的燃尽图与挣值演算，则假定你至少见过敏捷与 DevOps 的节奏。若你只想解决眼前的选型之争，先读 2.1 与 2.4 的对比段落，再回头补全其余模型。