2.3 螺旋与V模型：带检修坑位的线路

2.3 螺旋与V模型：带检修坑位的线路

切段让反馈提前了，但两种新风险跟着冒头：技术不确定性高的项目，每段该跑多远心里没底；验证环节靠后的项目，错误还是发现得太迟。本节的两种线路各修一个毛病——螺旋用风险分析决定每圈跑多远，V 模型给每一级开发配上对位的验证站台。

给线路装上检修坑位

螺旋模型（Boehm，1988）把项目看成绕圈：每圈都依次经过四个象限——定目标、辨风险、开发验证、计划下一圈。它的精髓在第二象限：每一圈开工前先专门回答"这一圈最大的不确定是什么、用什么便宜的办法把它消掉"。风险高就少写点代码多做多做验证，风险低就快跑。圈数不定、每圈行程不定，全由风险指挥。

V 模型则把瀑布展开成字母 V：左翼从需求分析下到编码，右翼按严格的对应关系逐级爬升——单元测试对位详细设计、集成测试对位架构设计、系统测试对位系统设计、验收测试对位需求规格。它强调：每一级设计写下的每句承诺，都必须有一级测试来兑现；写设计文档的同时就该起草对位的测试用例。

图 2-2：螺旋的一圈怎么转

两张图摆在一起，两种线路的气质就分开了：螺旋的每一圈都在问"往哪跑、敢跑多远"，V 的每一级都在问"这级写下的承诺谁来验收"。

两条线路的适用诊断

选螺旋的信号：技术路线本身没把握——比如结算引擎要在三种计费方案里赌一种，先花小代价各做一个原型跑真实数据，赌错也只亏一圈。选 V 的信号：验证深度本身是合规要求——适航或车规审计会逐级检查"这个设计对应哪些测试用例、跑过没有"，V 的对位关系天然就是审计材料的骨架。

落地时的三个提醒

• 螺旋不是流程图是决策纪律。它没有规定每圈干什么活，只规定每圈必须先过风险象限。跳过风险分析直接进入开发验证的"螺旋"，只是画得圆一点的瀑布。
• V 模型的用例要和设计同时生。右翼不是左翼干完再补的，设计评审通过的那天，对位测试用例的初稿就应该存在。事后补的用例只会验证实现，验证不了设计意图。
• 两者都能与切段叠加。螺旋的圈可以是增量批，V 的右翼可以拆给每批的验收——工程实践中很少有纯种模型，选型选的是主心骨，不是全套仪式。

⚠️ 一个常见的误用：把螺旋的风险象限做成每月例会的固定议程，风险列表常年原样复述。风险条目必须随圈更新——上一圈花实验消掉的条目要销项，新冒头的要补进下一圈。列表不变，说明没人真的在做风险分析。

案例复盘：云梯平台的两段线路

云梯结算引擎选了螺旋：计费规则引擎存在三种可行设计，团队用第一圈做了规则拦截方案的纸面推演，第二圈用两周做出简化原型跑历史账单，数据否决了方案二，最终方案在第三圈才进入正式开发——三轮的总成本低于直接开发后推倒重来。而对接行业数据上报的模块走了 V：上报格式由国标冻结，团队把国标条文逐条映射成系统测试用例，设计评审与用例评审同场进行，验收时审计方逐条核对映射表，一次通过。

同一项目、两种线路、各得其所——这比"全公司统一敏捷"或"统一瀑布"都更接近选型的本义。

把一圈螺旋排成日程

螺旋容易停留在概念图，落到日程才有约束力。看云梯计费引擎第二圈的实际排法：

螺旋第二圈 · 规则引擎 · 为期两周
  第1日   定目标：本轮要裁决"规则拦截式 vs 决策表式"哪条路线
  第2日   辨风险：列出本轮四个不确定点——
          规则冲突的判定顺序 · 执行性能 · 规则可视化成本 · 税则映射完整性
          按影响排序，锁定前两项为本圈必消项
  第3-8日 开发验证：只做覆盖两个风险点的简化原型
          拦截式半天可跑通；决策表式第四天卡在嵌套优先级
  第9日   用三年历史账单回放对比两版的命中与耗时
  第10日  计划下一圈：路线定为拦截式，决策表降级为规则编排的前端
          本圈结论写进决策记录，标注依据与失效条件
​

注意两个细节：风险条目在圈首集中识别、圈末逐条销项——这正是前面强调的"列表随圈更新"；以及第几日做什么完全服务于本圈要消掉的不确定性，而不是按固定模板走完四个格子。螺旋给的是决策纪律，日程表给的是执行压力，两者合用才不空转。

V 模型的对位映射表

V 的落地载体是一张映射表，把每级设计与对位测试钉在一起。节选云梯国标上报模块的两行：

对位映射 · 国标上报模块（节选）
  设计级        设计条目                     对位测试
  ─────────────────────────────────────────────────────────
  系统设计      上报批处理采用幂等设计，      系统测试 ST-12：
               重跑不产生重复上报             同一批次连续上报两遍，
                                             服务端仅落一份数据
  详细设计      金额字段按国标取整规则：       单元测试 UT-88：
               四舍六入五成双                 构造 0.005 与 0.015
                                             两个边界值断言取整结果
​

这张表有两个用途：设计评审时逐行检查"每条承诺有测试接住"；审计时直接当证据链——条目、测试、结果三向可追溯。它也是 V 区别于"普通瀑布加测试"的实感所在：对位关系是设计活动的一部分，不是测试团队的事后功课。

两个高频疑问

问：螺旋的"圈"跟迭代的"轮"是不是一回事？ 形似神不同。迭代的每轮产出增量、以交付推进认知；螺旋的每圈产出决策、以消风险决定下圈投入。工程实践里常把螺旋的圈套在增量的批上跑，但要记得每圈开头那格"辨风险"是螺旋的身份证明——省掉它，剩下的只是迭代换了名字。

问：小项目用 V 会不会太重？ V 的重量是可调的：两三个人的小系统不需要纸面映射表，但"写设计时同步想验证"的习惯一样适用。可以把映射表简化成设计文档里的两列批注，轻量地保住"每条承诺有验收"的内核。

本节要点回顾

• 螺旋以风险分析驱动，每圈走"定目标、辨风险、开发验证、计划下圈"，圈数与行程不预设。
• V 模型把开发与验证逐级对位，用例与设计同时起草，对位表本身就是强审计材料。
• 选螺旋看技术不确定性，选 V 看验证深度合规要求，两者都可与切段叠加。
• 风险列表随圈更新是螺旋的真实性检查；事后补用例是 V 的常见变质。
• 工程实践中模型是拼装的，选型选主心骨，不必追求纯种。

两种"重流程"的线路讲完了，下一节把节奏彻底拉开——公交化小班次的敏捷。