1.1 软件工程的目标与基本原则

1.1 软件工程的目标与基本原则

本节是全书的地基：先给软件工程下定义，再拆开它真正要守住的几样东西——质量、成本、进度——最后把抽象原则翻译成你在项目里能直接用的检查项。读完本节，第 2 章讨论"按哪种时刻表跑"时，你才有判断好坏的标尺。

一、软件工程到底要达成什么

先看定义。IEEE 给出的经典版本是：将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护。这句翻译过来就是三个动作——把开发拆成有先后依赖的阶段（系统化）、让每个阶段有名字确定的产物和进出条件（规范）、让进度和质量可以被数字描述而不是靠感觉汇报（可量化）。

车站视角更直白：**软件工程是给"写代码"这件事修建车站、铺设轨道、制定行车规程的过程。**会编程只说明你会开机车；软件工程关心的是整趟列车怎么编组、几点发车、出了故障怎么救援、明年怎么扩运力。

它的目标可以压成一句话：**在可接受的成本与期限内，交付满足需求且能长期维护的软件。**这句话里藏着一个出了名难缠的三角约束：

• 质量：功能正确、性能够用、缺陷少、能演进；
• 成本：人月、机器、外包费用要控制在预算内；
• 进度：承诺的发布日期要兑现。

三者互相牵制。压缩进度最省事的办法是砍测试，于是质量滑坡；提高质量最直接的手段是加评审加自动化，于是成本上涨；砍预算往往意味着减人，进度立刻拉长。工程决策本质上是在这个三角上选择往哪个角倾斜，并且为倾斜付出可控的代价，而不是幻想三个角同时拉满。

图 1-1：质量、成本、进度三角约束

二、基本原则：把"经验"变成"检查项"

教科书里常引用 Boehm 提出的软件工程七原则：分阶段的生命周期计划、坚持阶段评审、严格的产品控制、使用现代程序设计技术、结果可度量、开发团队与任务匹配、持续改进。这些词看起来像口号，实际每一条都能翻成车站里的一道闸口。

值得单独说的是产品控制（需求与范围控制）。多数延期项目的第一因不是技术，而是范围在无人审批的情况下悄悄长大——客户一句话、领导一个念头，就变成两周工作量。产品控制要求所有变更走同一条通道：提出、评估影响、排优先级、更新计划，哪怕变更来自最高层。

度量这条原则常被小团队嫌麻烦，其实起步门槛很低。下面这段演算会话演示了怎么用两条最朴素的数据判断一个项目的健康度——人均产出与返工占比：

[演算] 云梯货运平台 · 迭代七 生产率与返工占比

输入：
  迭代周期            = 10 个工作日
  团队规模            = 6 人
  本迭代完成的用户故事点 = 42 点
  本迭代返工（缺陷修复+返做）= 11 点

计算：
  团队产能   = 6 人 × 10 日 = 60 人日
  单点成本   = 60 人日 ÷ 42 点 ≈ 1.43 人日/点
  返工占比   = 11 ÷ 42 ≈ 26.2%

解读：
  返工占比超过两成，说明相当一部分产能花在"重做"上。
  追溯发现 11 点返工里有 7 点源自需求理解偏差，
  对策不是催开发，而是在下一迭代把需求评审提前半天。
​

同样的数字，换个团队可能结论完全不同：如果返工集中在某个人经手的模块，那是技能问题；如果集中在跨团队接口，那是沟通协议问题。度量本身不解决问题，它负责把"感觉不对"变成"哪里不对"。

三、原则落到岗位上是什么样

原则不是给管理者独享的，每个角色手里都有自己的一段：

• 开发人员的版本：提交前自查、不绕过代码评审、不私自改接口契约；
• 测试人员的版本：缺陷有复现步骤才算立案、发布前测试报告有明确结论；
• 产品人员的版本：需求有验收标准、变更有记录可查；
• 管理者的版本：不绕过流程口头加需求、用数据而非感觉汇报进度。

⚠️ 最常见的翻车姿势是"原则只约束基层"。领导绕过评审直接拍板上线，比开发跳过单元测试危险得多——因为前者的破坏力没有闸口能拦住。判断一个团队工程化水平，看它对"谁必须遵守规则"这个问题的答案就行。

三个高频疑问

问：软件工程与"会编程"的差别，能不能再具体一点？ 三点最实在。其一，时间尺度不同——编程面对的是"此刻让程序跑对"，工程面对的是"未来三年它还能被安全地改"；其二，协作对象不同——编程可以只和机器打交道，工程必须和需求方、测试、运维以及半年后接手的陌生人打交道；其三，判定标准不同——程序的终点是"能跑"，工程的终点是"验收单上的数字"。三个差别指向同一点：工程能力是编程能力之外的另一层肌肉，本册练的全是它。

问：原则之间打架了怎么办？ 常见的冲突是"产品控制"对上"响应变化"：客户急着要变更，走闸口评估影响需要半天。处置的准绳是区分"变更决策的快"与"变更记录的全"——评估可以限时几小时内给出结论（快），但任何变更必须留痕进基线（全）。原则冲突时保住的是各自的底线性要求，牺牲的是各自的便利性要求；反过来只图便利，两头的好处都会失去。

问：小团队要不要上全套原则？ 全套不必，底线必须有。人再少的团队也绕不开三件事：变更要有记录（哪怕是一条共享文档里的变更日志）、交付前要有验证（哪怕只是人工过一遍核心路径）、复盘要有产出（哪怕只是三条写下来的教训）。形式可以极简，缺了记录的团队等于把第 1.2 节的历史事故剧本重新排演一遍。

本节要点回顾

• 定义：系统化、规范化、可量化地开发、运行和维护软件，核心是把个人技艺变成组织能力。
• 目标：在成本与进度约束内交付满足需求、可长期维护的软件。
• 三角约束：质量、成本、进度互相牵制，工程决策是选择倾斜方向并控制代价。
• 七原则：分阶段计划、阶段评审、产品控制、现代技术、可度量、人员匹配、持续改进。
• 产品控制最容易被忽视也最常致祸：所有需求变更必须走同一条审批通道。
• 度量起步：人均产出与返工占比两条数据，就足以暴露大部分协作问题。

下一节我们回到上个世纪六十年代，看这些原则是在什么样的废墟上被总结出来的。