给「改」立规矩 — 变更控制与产品保证
这一章讲四件事: 为什么变更必须当成常态来设防(两条定律式观察); 一条变更请求从提出到入档的完整一生(主走查,每步带具体记录); 配置管理这个组织的独立性与人员从哪来;以及验证与确认——用一列传话的孩子讲清两者差别。 下一章处理「长期改下去会发生什么」。
1. 先看现象:改出来的故障比写出来的多
上线后的系统,每个月都在被改:修缺陷、加功能、调性能。直觉是「改点小东西,能出什么事」。
书里两条观察先把这个直觉拆了:
- 看到越多,需要越多:给用户的功能越多,用户想要的功能就越多——所以每个文档都要按「利于更改」来组织, 配置管理流程必须在交付前很久就就位,因为「用户看到产品后想要更多」是必然事件,不是意外1;
- 开发中变化不可避免:系统工程第一定律(Bersoff 等)——无论你处在生命周期何处,系统都将变化, 而且想变的愿望会持续存在2。变化在需求、设计、代码、测试计划上都会发生;预算和工期必须留出变化的余地。
变化本身不是敌人,不受控的变化才是——第 12 章会用雷曼定律证明「变化让软件变糟」。 本章先立防线:软件配置管理(SCM,管理软件的每一次变更的规矩与工具的总和)。
2. 顶层全景
变更涌来(用户投诉/新需求/开发者发现)
│
▼
① 提出变更请求(CR):谁、何时、要什么、为什么
│
▼
② 配置控制委员会(CCB):定优先级、定排期
│
▼
③ 从基线拉出 → 修改 → 交叉引用 CR → 回归测试
│
▼
④ 新基线 + 更新「部件列表」(谁由哪些版本组成)
│
▼
⑤ 审计轨迹:任何时候能答「谁、何时、为什么改了什么」
图说:①~⑤ 就是「给改立规矩」的全部。
另有两个组织级前提:SCM 独立于项目管理;产品保证不是奢侈品。
3. 核心原理
3.1 先说清防的是什么:三条「变更版」事故
原则 181 列了变更引出的三个经典问题,SCM 的每个设计都对着它们3:
- 变更没有解决预期要解决的问题(改了,但白改);
- 变更解决了问题,却导致其他问题(按下葫芦浮起瓢);
- 将来的某天没人能弄清为什么改(或谁改的)——三个月后对着一行看不懂的代码面面相觑。
三个问题的共同预防措施:跟踪每一个变更——记下最初的请求、批准流程(谁/何时/为什么/进哪个版本)、 实际改动(谁/什么/何时),并让请求、批准、改动三者互相引用。书里给这套记录起了名字:审计追踪3。
3.2 主走查:一条变更请 求的一生
把 3.1 的骨架走成一件具体的事(CR 编号、版本号、日期为演示编的,流程与记录要求来自原书各原则):
① 提出变更请求
客户投诉:「订单导出偶尔少一行」(现象+复现步骤:导出含 501 行订单时)
→ 记为 CR#412,提交人:客户成功组小林,2026-08-03 14:20
② CCB 周会分级排期
配置控制委员会(CCB,定期评审所有变更请求的委员会)判定:
严重度=高(数据错误),优先级=P2,排入 v2.3 发布
→ 理由记录:影响对账,但不阻塞交易
③ 从基线拉出、修改、交叉引用
当前基线 v2.2.1(基线:定稿冻结、改动必须走流程的版本点,第 04 章定义)
→ 开发者小周拉出修复分支,改 2 个文件,提交说明写明「fix CR#412」
→ 顺手发现另一个可疑点?不许顺手修(第 12 章 12.2),另提 CR#413
④ 回归+入档
修复通过测试;回归测试(把改动之前就正常的功能重新测一遍)
确认导出 501 行、5010 行都完整,
之前正常的 8 项功能照旧正常 → 新基线 v2.3.0
→ 更新部件列表:哪次发布由哪些组件的哪些版本组成
⑤ 审计轨迹闭环
半年后有人问「为什么导出逻辑变了」
→ CR#412 → CCB 记录 → 提交 fix CR#412 → v2.3.0, 四环相扣,一分钟答完
图说:五步走完,3.1 的三个问题各被堵住一个:
②防白改,④防浮起瓢,⑤防没人说得清。
3.3 支柱细节:命名、基线、保存一切
一切中间产物要有名字和版本(原则 178):需求规格说明、设计文档、代码、测试计划、用户手册—— 每样都要有唯一名称、版本/修订号、日期;内部可独立演化的部件也一样; 发布产品时发一份部件列表(哪个版本的产品由哪些部件的哪些版本组成)4。 书里点破它的用途:「只有通过这样的命名,你才能控制对产品不可避免的更改」4。
控制基线(原则 179):基线封版后,工程师在修复 A 时「顺手」修了没报告的缺陷 B、 或加了「快手小功能」C——这种不受控的变化不能容忍:B 和 C 没经过评审,没进任何人的计划, 出了事没人认账。正解:提出变更请求,进 CCB 排队5。
保存一切(原则 180):作者引了 Ehrlich 的话——「明智修补的首要原则是保存所有的零件」。 软件天然是不断修补的产物,而修补会引入错误(第 12 章 12.3 给出 20%~50% 的数), 所以任何更改都可能需要回滚——回滚的前提是改之前所有东西的副本都在6。
别绕过(原则 182):绕过变更控制最常见的方式很日常——客户和开发者熟,直接说「帮我改一下这个」。 书里的定性是灾难性的:它让项目失控、成本上升、需求文档失真;并特意澄清: 「控制」不意味着「阻止」——走的还是同一条 CCB 流程,只是快慢由优先级决定7。
3.4 组织位:SCM 为什么必须独立
独立于项目管理(原则 176):排期吃紧时,项目经理的天然冲动是绕过控制—— 比如「先把新版本收进来当基线,补记录的事以后再说」。如果 SCM 向项目经理汇报,它只能服从; 只有组织上独立,SCM 才能实施对所有人都最好的规则8。
人是换岗进去的,不是流放的(原则 177):很多组织把新人第一份工作、或干得差的人丢去产品保证—— 书里反对这个惯例:产品保证对工程质量的要求不亚于设计编码。正解:每个优秀工程师每隔两到三年, 投入六个月到产品保证,并且明说这是对优秀者的奖励——访问期间期待他们把产品保证本身改进一点9。
按项目定制(原则 175):美国联邦航空局的空管系统用七层配置控制看板——小项目照搬就是自杀; 一次性原型没有配置管理也能活,大规模开发不行。「不是所有情况都适用同一模式」10。
三件套别砍(原则 173):产品保证=配置管理、质量保证、验证确认、测试。预算紧张时, 测试最常被保留,另外几样被当奢侈品砍掉——书里的立场:分权制衡显著提高「满足客户期望、 贴近排期成本」的可能性;关键是按项目规模与内容定制,不是按心情砍11。
3.5 验证与确认:一列传话的孩子
大项目还需要一道独立复核,原则 184 用了全书最好的教具——传话游戏: 一群孩子排队耳语传递一句话,队尾说出来的话极少和队头相同12。
把每个开发阶段看成一个孩子:需求 → 设计 → 编码 → 测试。传话游戏里的两个纠错动作12:
- 问前一个孩子:「你说的是 x 吗?」——检查这一步的产物是否符合上一步的产物 (代码实现的是设计、设计覆盖的是需求);
- 问第一个孩子:「你说的是 x 吗?」——检查这一步的产物是否还满足最初的需求与客户意图。
这两个动作合称验证与确认(V&V),由独立于开发团队的组织来执行;计划要早做, 大约与需求规格说明同时得到批准12。
判断(我们的,不是书里的): 这两个词的名字要提醒一句——本书中文版把「确认(Validation)」 对应「问前一个孩子」、「验证(Verification)」对应「问第一个孩子」,这与英文业界通行用法 (verification 问上一环:「我们把产品做对了吗?」;validation 问最初意图:「我们做的是对的产品吗?」) 正好相反。机制是清楚的,名字的对应读时留意即可;真要对外交流,以「问上一环/问源头」来解释最稳妥。 如果错,会错在: 如果英文原版 1995 年的用词本就与中文版一致(即作者当年就用 了与 IEEE 相反的对应), 那这不是翻译问题而是作者个人的用语习惯——我们的判断只在「翻译调换了对应关系」这个假设下成立, 手头没有英文原版可核,两说并存。
4. 作者的判断与证据
| 说法 | 谁的 | 证据 |
|---|---|---|
| 系统将变化,愿望持续存在 | 作者引 Bersoff「第一定律」2 | 定律式概括(带幽默的命名),背后是大样本项目观察 |
| 看到越多需要越多 | 作者(原则 15)1 | 行业观察;与雷曼定律(第 12 章)互证 |
| 82% 由审查发现/SCM 的五条存在意义 | 前者见第 07 章;后者作者(原则 174)13 | 流程归纳 |
| SCM 必须独立 | 作者引 Bersoff8 | 案例论证(排期压力下绕过的诱惑) |
| V&V 用传话游戏讲清 | 作者(原则 184)12 | 教具;两个名字的对应与业界惯例有出入(见 3.5 判断块) |
5. 边界与局限
- 工具把 3.3 的一半自动化了。 版本库(记录每次代码改动的仓库,如 git)让「保存一切」「跟踪每个变更」 近乎免费;「部件列表」的等价物是依赖清单与镜像指纹。书里的原则过时为零,操作成本大降—— 但「谁批准的、为什么」依然要靠流程纪律,工具不会替你开会。
- 作者 2021 年的两处降级与一处升级:原则 176(SCM 独立)与 177(人才换岗)「可能不再那么重要」; 同时他提议了一条新原则——版本控制应跟踪「每个组件的每个版本、哪些版本组合构成可用系统、 哪个客户持有哪个版本」,起因是他托运自行车丢了零件、厂家竟无法告诉他该补哪几件14。
- CCB 对小团队太重。书里的 CCB 是大型项目的委员会;小团队的等价物可以是「每周一次的 issue 分诊」, 机制不变(分级、排期、记录),人数减到一两个。
- 「独立组织做 V&V」的成本只有大项目付得起12;小项目的低配版是「由非实现者评审」, 独立性弱一档,但保留了「问上一环/问源头」两个动作。
6. 可带走的
- 变更是常态不是例外:上线前就要把「谁有权改、怎么改、怎么记」立好,晚立就是事故后立;
- 一切中间产物有名字、版本、日期;发布带「部件列表」——你才答得出「这个版本里装的是什么」;
- 基线之后没有「顺手修」:再小的改动也走变更请求,进委员会排队——控制不是阻止;
- 每条变更留审计轨迹:请求、批准、改动三者互相引用,半年后一分钟答完「谁为什么改了什么」;
- 改之前保存一切——回滚的能力是改动的底气;
- 配置管理组织上要独立于项目经理,否则排期压力一来它第一个被绕过;
- 产品保证岗位是奖励不是流放地:让最好的工程师隔两年进去干半年,他们还会把流程改好;
- V&V 记两个动作就够:问上一环(做对了吗)、问源头(做的是对的东西吗)——名字的对应,交流时说动作。
7. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 开发中变化不可避免(第一定律) | 第2章 一般原则 | text/14-ch02.txt:153(搜「第一定律」) |
| 看到越多需要越多(提前就位) | 第2章 一般原则 | text/14-ch02.txt:145(搜「就位」) |
| 产品保证定义(分权制衡) | 第8章 产品保证原则 | text/20-ch08.txt:7(搜「分权制衡」) |
| 产品保证不是奢侈品 | 第8章 产品保证原则 | text/20-ch08.txt:21(搜「奢侈品」) |
| 尽早建立 SCM(看板/五条存在意义) | 第8章 产品保证原则 | text/20-ch08.txt:37(搜「看板」) |
| 按项目定制(七层看板) | 第8章 产品保证原则 | text/20-ch08.txt:51(搜「七层」) |
| SCM 独立于项目管理 | 第8章 产品保证原则 | text/20-ch08.txt:59(搜「绕过」) |
| 换岗优秀工程师(六个月) | 第8章 产品保证原则 | text/20-ch08.txt:67(搜「六个月」) |
| 命名+版本+部件列表 | 第8章 产品保证原则 | text/20-ch08.txt:75(搜「部件列表」) |
| 控制基线(变更请求) | 第8章 产品保证原则 | text/20-ch08.txt:37(搜「变更请求」) |
| 保存一切(零件) | 第8章 产品保证原则 | text/20-ch08.txt:97(搜「零件」) |
| 跟踪每个变更(审计追踪) | 第8章 产品保证原则 | text/20-ch08.txt:125(搜「审计」) |
| 别绕过变更控制 | 第8章 产品保证原则 | text/20-ch08.txt:133(搜「灾难」) · text/20-ch08.txt:133(搜「阻止」) |
| CCB 分级排期 | 第8章 产品保证原则 | text/20-ch08.txt:89(搜「配置控制委员会」) |
| V&V 与传话游戏 | 第8章 产品保证原则 | text/20-ch08.txt:151(搜「电话」) · text/20-ch08.txt:149(搜「之前产品」) |
| 2021:自行车故事与新原则提议 | 作者序 | text/08-fm.txt:69(搜「自行车」) |
| 2021:176/177 降级 | 作者序 | text/08-fm.txt:71(搜「176」) |