2.2 瀑布、V 模型、增量、螺旋与原型
如果把经典过程模型当作思考工具,而不是教条,它们今天仍然有用。每个模型都强调一种不同的风险。
正在加载交互实验...
正在加载概念检查...
一页看懂这些模型
| 模型 | 适合什么时候 | 危险在什么时候 |
|---|---|---|
| 瀑布 | 需求稳定,交接必须明确 | 团队假装不确定性不存在 |
| V 模型 | 验证证据必须映射到需求和设计 | 文档只是事后补出来 |
| 增量 | 价值可以分片交付 | 分片没有集成为一致系统 |
| 螺旋 | 技术或业务风险占主导 | 风险评审变成模糊仪式 |
| 原型 | 用户或团队还没真正理解问题 | 原型代码悄悄变成生产代码 |
瀑布不天然愚蠢。敏捷也不天然智慧。任何模型的坏版本,都会忽略它自己的失败模式。
瀑布与 V 模型
瀑布把工作按阶段顺序推进。当需求稳定、合同正式、后期变更昂贵时,它可能合适。它的弱点是反馈较晚。
V 模型把验证显式化。需求对应验收测试,系统设计对应系统测试,模块设计对应单元测试。需要证据时它很有价值,但如果团队只是在决策锁定后补证据,就很危险。
上面的选择练习已经覆盖不同场景下的模型判断;这里重点看瀑布和 V 模型为什么会强调阶段、交接和验证证据。
正在加载概念检查...
增量、螺旋与原型
增量开发交付可用切片。当增量是真正集成并测试过的,而不是藏在分支上的半成品代码时,它能降低集成风险。
螺旋开发是风险驱动的。每一轮都应该识别、降低、复查最高风险。如果没有说清楚风险,螺旋图只是装饰。
原型帮助团队学习到底要构建什么。原型可以探索用户流程、技术可行性或集成行为。陷阱是忘记决定这个原型要丢掉,还是要被加固成生产系统。
注意
真实项目常常混合模型。例如团队可以用原型探索用户流程,用螺旋思想处理技术风险,用增量方式交付,同时对受监管部分保持 V 模型式可追溯性。
正在加载本节练习...