瀑布模型及其失败

Source: Dev.to

概述

瀑布模型是一种线性、阶段门控的软件交付模型，工作按照固定阶段向下流动，每个阶段必须完成后才能进入下一个阶段。它的设计目标是可预测性，而非速度。反馈来得晚，变更成本高。

阶段

Requirements
    ↓
Design
    ↓
Development
    ↓
Testing
    ↓
Deployment
    ↓
Maintenance

阶段特征

• 只完成一次
• 在继续向前之前签字确认并锁定
• 没有正式变更请求就不能回退

瀑布模型适用的情况

• 软件需求稳定
• 发布频率低
• 系统简单
• 硬件成本高
• 变更风险大

大量使用瀑布模型的行业

• 政府
• 银行
• 国防
• 电信

这些行业更看重控制和文档，而不是速度。

典型流程细节

• 业务方编写大量需求文档，假设前期能够完全明确。
• 不鼓励变更。
• 架构师产出详细设计；决策在早期冻结，未来的假设已写入其中。
• 开发依据规格实现，用户反馈极少。
• 问题在后期才显现；测试在接近尾声时进行。
• 修复缺陷成本高，时间压力极大。
• 手动且风险高的回滚在数月或数年后才会发生，往往影响范围广。

问题

• 缺陷和设计缺陷出现得太晚。
• 大范围的影响使回滚困难。
• 开发者很少看到生产环境的问题。
• 按流程执行并不能保证用户满意度。

对比表

常见误解

• 瀑布模型是“邪恶的”。在合适的情境下它是一种有用的方法；问题在于误用。

瀑布模型失败的原因

• 它假设在不确定的世界中有确定性。
• 当与功能孤岛、手动操作以及频繁的业务变更相结合时，模型会崩溃。

DevOps 作为回应

DevOps 的出现是为了解决瀑布模型的不足：

• 持续的反馈循环
• 构建、测试和部署流水线的自动化
• 开发与运维之间的共享所有权

通过采用这些实践，团队可以降低严格线性、阶段门控方法固有的风险。