一、生命周期：软件的一生

教材的六阶段：规划（想清楚做什么）→ 需求分析 → 设计 → 编码 → 测试 → 运行维护（退役也是环节——数据迁移、下线清理）。维护期通常占软件总成本的大头——写代码只是开始，改代码才是日常。

工业界有标准框架：ISO/IEC/IEEE 12207:2017《软件生存周期过程》，我国对应国标 GB/T 8566-2022（2023 年 5 月 1 日实施，与国际标准等同采用，定义了 4 个过程组 30 个过程）。名字不必背，知道【生命周期是标准化过的事】即可。

二、三代模型：对变化的态度演进

• 瀑布模型：一阶段干完再下一阶段，像瀑布只往下流。优点是文档齐全、责任清晰；致命伤是改需求代价巨大——适合需求极其稳定的领域（航天、医疗）。
• 迭代／螺旋模型：把大项目切成多轮，每轮都走一遍【设计→编码→测试】，风险早暴露。
• 敏捷（Agile）：小步快跑，每 1~4 周交付可用版本，拥抱需求变化（1-8 已核实：2026 年 86% 以上的组织在用某种形式的敏捷）。代价：文档容易被压缩，靠自动化测试和工具补位。

三、DevOps：拆墙

传统分工：开发写完扔给运维上线——出了事故互相甩锅，发布又慢又怕。DevOps＝开发（Development）＋运维（Operations）合体：共同对【从提交到上线】全流程负责，靠自动化（5-10 的 CI/CD）把发布频率从【一个月一次心惊胆战】变成【一天多次家常便饭】。

Google 的 DORA 报告（已连续调查十年、2025 年覆盖近 5000 名从业者）给出量化标杆：精英团队按需部署（一天多次）、故障恢复不到一小时、变更失败率低于 5%。2025 年报告还有个新发现：90% 的开发者用上了 AI，但 AI 提升产量的同时，交付稳定性反而承压——工具越快，流程的短板越显形。

四、动手 Demo：三分钟感受瀑布 vs 敏捷

# 同一个需求【做成绩单】：瀑布＝一次性做完所有功能再给用户
# 敏捷＝每轮交付最小可用版本，用户反馈决定下一轮
import copy

requirements = ["成绩列表", "平均分", "排名", "导出"]

# 瀑布：憋大招
def waterfall_all(reqs):
    print("瀑布：第 8 周一次性交付 ->", "、".join(reqs))
    return reqs

# 敏捷：每轮交最小可用，按反馈调整
def agile_sprints(reqs):
    done = []
    for i, r in enumerate(reqs, 1):
        done.append(r)
        print(f"敏捷：第 {i} 周交付 -> {'、'.join(done)}")
    return done

# 第 2 周用户发话：排名改成【按分数降序】而不是名次表
requirements[2] = "按分数降序排名"

print("瀑布版（第 8 周才发现做错）:", waterfall_all(["成绩列表", "平均分", "名次表", "导出"]))
print()
agile_sprints(copy.copy(requirements))

沙箱实跑输出：

瀑布：第 8 周一次性交付 -> 成绩列表、平均分、名次表、导出
瀑布版（第 8 周才发现做错）: ['成绩列表', '平均分', '名次表', '导出']
敏捷：第 1 周交付 -> 成绩列表
敏捷：第 2 周交付 -> 成绩列表、平均分
敏捷：第 3 周交付 -> 成绩列表、平均分、按分数降序排名
敏捷：第 4 周交付 -> 成绩列表、平均分、按分数降序排名、导出

看到什么算成功：瀑布版交付的还是【名次表】（需求变了它没跟），敏捷版第 3 周已切换为【按分数降序排名】。

读结果：需求在第 2 周变——瀑布要到第 8 周才暴露错误；敏捷每周都有【可用的东西】在手，方向错了最多错一周。这就是敏捷的全部账本：把发现错误的周期压短。

五、30 秒实验

把敏捷版的需求列表在第 1 轮后就插入一个新需求【班级对比】——重新跑，看它如何自然排进后续迭代。变化被吸收而不是被抵抗。

六、常见误区

• ☐ 5-9 学习完成

相关笔记

• CI 与 CD —— DevOps 的流水线引擎
• 三代开发流程 —— 敏捷采用率 86% 的出处
• ⌨️ 编程原理 · 索引 —— 全课路线图