大三《软件过程与管理》梳理：PSP、RUP、CMMI、敏捷，到底什么关系
以前我做项目全凭一股劲：打开 IDE 就写，写完就跑，能跑就上线。直到这门课把我按在座位上，告诉我——"能跑"和"管得好"是两码事。
大三这学期开了《软件过程与管理》。说实话，刚拿到课表时我心里是拒绝的：又要背一堆缩写？PSP、RUP、CMM、CMMI、XP、Scrum、COCOMO…… 光记全称就够呛。
但学着学着发现，这些"过程模型"其实是在回答同一个问题：一个软件团队，怎么把活干得既快又不出乱子？ 它们不是八竿子打不着的概念，而是从不同尺度（个人 → 团队 → 组织）在解题。
下面是我自己梳理的笔记，也是把这学期的东西串起来的一次尝试。
一、它们分别管哪一层的"过程"
先把视角拉直，这几个模型其实分属不同层级：
| 模型 | 全称 | 关注尺度 | 一句话理解 |
|---|---|---|---|
| PSP | Personal Software Process | 个人 | 我一个人写代码，怎么估计准、少加班 |
| CMM / CMMI | Capability Maturity Model | 组织 | 这家公司靠不靠谱，过程能力到几级了 |
| RUP | Rational Unified Process | 团队/项目 | 一个项目从立项到上线，分几个阶段走 |
| 敏捷 / Scrum | Agile | 团队 | 需求老变，我怎么小步快跑不掉队 |
| COCOMO II | Constructive Cost Model | 估算 | 这个项目到底要多少人月、几个月 |
看到没？PSP 管自己，CMMI 管公司，RUP 管项目流程，敏捷管团队协作，COCOMO 管预算。 它们不是互相替代，而是拼图的不同块。
二、CMMI：组织成熟度的"段位"
CMMI 最容易被误读成"一套开发方法"，其实它不规定你怎么写代码，只评估你"过程稳不稳定"。从低到高五个级别：
- 初始级（1级）：全靠个人英雄主义，项目成败看人。经典台词："上次能跑是因为小王加了个通宵。"
- 已管理级（2级）：有基本项目管理，需求、配置、质量有了规矩。
- 已定义级（3级）：组织有标准过程，项目在其上裁剪。新人来了照着流程也能干。
- 量化管理级（4级）：关键过程用数据量化控制，不再是"感觉差不多"。
- 优化级（5级）：持续用数据改进过程本身。
我之前的几个项目大概在 1 级和 2 级之间反复横跳——LiteMall 性能测试那会儿，连测试用例都是临时拍脑袋写的，纯纯的"初始级"既视感。
三、PSP：先管住自己再说
CMMI 是组织的理想，但组织由人组成。PSP（个人软件过程） 的思路很朴素：你连自己写一段代码要多久、会出多少 Bug 都估不准，谈什么团队协作？
PSP 核心做法是度量自己：
- 写每段代码前，先估工作量（计划阶段）
- 写的时候记实际耗时、缺陷数（开发阶段）
- 事后再比对：估的和实际差多少？哪类 Bug 最常犯？
我试了一周，发现自己最大的问题是低估调试时间——编码估 2 小时，实际调试花了 4 小时。后来我把"调试"单独列一行估算，计划准确率立刻上来了。PSP 的精髓就是：让估计从玄学变成有数据支撑的判断。
四、RUP：一个项目的"标准剧本"
相比 PSP 的个人视角，RUP（统一过程） 给整个项目一个剧本。它有两个经典维度：
四个阶段（横轴，按时间）：
- 初始（Inception）：这项目值不值得做？范围多大？
- 细化（Elaboration）：核心架构搭出来，主要风险排掉
- 构造（Construction）：按架构把功能填满
- 交付（Transition）：上线、迁移、培训
九大工作流（纵轴，贯穿全程）：业务建模、需求、分析设计、实现、测试、部署、配置管理、项目管理、环境。
它的精髓是"迭代 + 架构优先"：不是等到最后才交付，而是每个阶段都产出可运行的增量。我在做销售生产 ERP 系统时，如果早点用 RUP 的"细化阶段"把飞书机器人集成 DeepSeek 的接口契约定清楚，后面就不至于返工两次。
五、敏捷：需求会变，那就小步试
RUP 偏"先规划清楚再大干"，但现实是需求永远在变。敏捷（以 Scrum 为代表）选择拥抱变化：
- 把一个大项目切成 2~4 周的 Sprint（迭代）
- 每个 Sprint 选一批需求做完、演示、复盘
- 用 Product Backlog 管理待办，每日站会同步阻塞
一个最小的 Scrum 看板长这样：
┌──────────┬──────────┬──────────┬──────────┐
│ To Do │ Doing │ Review │ Done │
├──────────┼──────────┼──────────┼──────────┤
│ 登录接口 │ 报表导出 │ 库存同步 │ 用户管理 │
│ 权限重构 │ (小王) │ (小李) │ 订单列表 │
└──────────┴──────────┴──────────┴──────────┘
我现在的宿舍库存管理（HomeBox 那套）就用这种看板管，比原来"想到啥做啥"清爽太多。
六、COCOMO II：把"要多久"算出来
前面说了那么多过程，老板只问一句："这项目要多少人月？" 这时候上 COCOMO II。
基础公式（构造期模型）：
Effort（人月） = a × (KLOC) ^ b × EAF
Tdev（工期月） = 2.5 × (Effort) ^ 0.35
其中 a、b 由项目类型决定：
| 类型 | a | b | 场景 |
|---|---|---|---|
| Organic（简单） | 3.2 | 1.05 | 熟悉领域、需求清晰 |
| Semi-detached（中等） | 3.0 | 1.12 | 半生不熟，混合团队 |
| Embedded（复杂） | 2.8 | 1.20 | 强约束、硬实时 |
拿我做的 LiteMall 当例子：假设核心后端约 8 KLOC，团队半生不熟，取 Semi-detached：
import math
KLOC = 8.0 # 代码量（千行）
a, b = 3.0, 1.12 # Semi-detached 系数
EAF = 1.0 # 简化：先不计规模惩罚因子
effort = a * (KLOC ** b) * EAF # 工作量（人月）
tdev = 2.5 * (effort ** 0.35) # 工期（月）
print(f"工作量 ≈ {effort:.1f} 人月")
print(f"工期 ≈ {tdev:.1f} 月")
# 输出：工作量 ≈ 30.8 人月，工期 ≈ 8.3 月
算出来要 30.8 人月、8.3 个月。如果只是我一个人（1 人月 ≈ 1 个人干一个月），那得干两年半——瞬间明白为什么大作业要组队了。真实项目里还要乘 EAF（产品复杂度、可靠性、人员经验等因子），这里只是演示量级感知。
七、我的串接理解：不是选边站，是看场景
学完最大的收获，不是背下定义，而是明白了没有最好的过程，只有最合适的过程：
- 一个人做课程小作业 → PSP 就够，顺便练估算
- 给实验室做个内部系统 → 轻量 Scrum，两周一个迭代
- 接企业的 ERP / 数字人项目 → 得上 RUP 把架构和风险锁死
- 团队想拿资质、接政府单 → 奔着 CMMI 3 级 去建标准过程
- 立项前被问预算 → COCOMO II 先拍个数，别拍脑袋
这些模型不是考试的名词解释，而是我后面做项目时真能用上的"工具箱"。
小结
这门课最扎心的一课是：代码写得好，只是"能跑"；过程管得好，才是"能交付、能复制、能交接"。 大三快结束了，回头看自己做过的灵山数字人、ERP、HomeBox、LiteMall…… 如果早点有这些框架，应该能少熬好几个通宵。
笔记就记到这里。下个项目，我打算先开个 COCOMO 算笔账，再拉个 Scrum 看板——理论终于要落地了。
（写于 2026 年夏，大三即将收官）
浙公网安备 33010602011771号