企业官网建设流程全解析

第 2 章 软件生命周期与过程模型

学习目标

• 理解软件过程的基本元素(活动、任务、工件、角色)与过程描述方法
• 掌握瀑布、原型、增量、螺旋模型的适用条件与风险
• 理解敏捷宣言、Scrum、XP 的核心实践
• 掌握 DevOps 对传统生命周期的延伸
• 掌握过程选型方法,并能为具体项目写出选型论证
• 理解过程本身的度量与改进

2.1 软件过程:过程模型的基本元素

软件过程(software process):软件开发中执行的活动、任务、动作的集合,以及它们的时序关系与产出工件。

基本元素:

过程模型(process model)是对过程的抽象模板。选择模型没有"银弹",只有"适配度"。

过程描述:一个过程要说明什么

一个可执行的过程定义,至少回答六个问题(可用作团队过程文档的模板):

1. 做什么:活动与任务的完整清单;
2. 谁来做:角色与责任矩阵(RACI:谁负责 R、谁批准 A、咨询谁 C、告知谁 I);
3. 何时做:时序、触发条件、前置/后置条件;
4. 产出什么:工件清单与质量标准(DoD);
5. 怎么验证:评审、测试、门禁;
6. 怎么度量:过程健康指标(见 2.10)。

缺少第 4、6 问的"过程"只是口号。OOS 的过程定义文档就按这六问组织,每问一页,共六页——过程文档应该短到能被记住,完整到无人可推诿。

过程适配(裁剪)

过程模型是模板,项目必须裁剪。裁剪维度:

裁剪纪律:裁剪是显式、记录、可回滚的决策。"因为赶进度跳过了评审"不是裁剪,是事故隐患。

2.2 瀑布模型(Waterfall)

经典线性阶段:需求 → 设计 → 实现 → 测试 → 维护,每阶段完成后"落下"下一阶段,前一阶段的产出是后一阶段的输入。

需求分析 ──评审──> 设计 ──评审──> 编码 ──> 测试 ──> 交付 ──> 维护

各阶段门禁检查点(实操清单)

优点

• 阶段清晰、文档完备,里程碑便于管理;
• 评审门禁让问题在阶段切换时被拦截;
• 适合需求稳定、变更昂贵、强监管的场景。

缺点

• 客户直到很晚才看到可运行系统,需求理解偏差代价高;
• 变更沿链路传导,牵一发动全身;
• 对"边做边学"型项目不友好。

适用:嵌入式/安全关键系统、合同驱动外包、需求高度稳定且经专家确认的领域。

实践提示:严格瀑布已罕见,但"带文档门禁的线性流程"以阶段化迭代形式广泛存在(见 2.5)。

OOS 中"瀑布纪律"的保留点

OOS 整体敏捷,但支付对账模块保留瀑布式纪律:正式 SRS + 需求评审 + 设计评审 + 专项审计测试。原因:资金合规要求"可证明的正确性",审计方需要带版本与签名的文档链。这是"混合过程"最典型的形态。

2.3 原型模型(Prototyping)

在正式开发前先快速构建可交互原型(抛弃型或演进型),用于:

• 澄清模糊需求(尤其 UI/交互、业务流程);
• 技术预研(feasibility,如验证某算法性能)。

两类原型的处理

风险与对策:客户误把原型当成品(原型代码质量差却直接演进);跳过需求分析直接"拍脑袋"。
对策:明确原型定位(抛弃型写清楚"不进入生产代码");原型仍需评审与范围冻结;演进型原型的架构决策仍需走 ADR。

2.4 增量模型与螺旋模型

增量(Incremental)

将系统拆分为可独立交付的增量包,每个增量走一遍"需求-设计-编码-测试"的完整循环:

核心下单 ──> 支付集成 ──> 退货售后 ──> 数据看板 (增量1) (增量2) (增量3) (增量4)

优点:早期可用、风险分散、客户持续反馈。
要求:第一个增量必须是"最小但完整"的骨架(含架构级能力,而非仅一个功能孤岛)。
反模式:第一个增量做成"功能孤岛"(只有下单、没有用户体系、没有配置),后续每个增量都在补地基,总成本反超一次性骨架。

增量拆分检查表:

1. 每个增量可独立部署并被用户使用?
2. 增量 1 是否包含横切能力(账号、权限、日志、监控)?
3. 增量顺序是否让"风险最高"的先落地(外部集成、性能瓶颈)?
4. 每个增量是否有独立的回滚边界?

螺旋模型(Spiral,Boehm)

每圈螺旋经过四个象限:

1. 目标确定:本圈目标与备选方案;
2. 风险分析:识别并评估风险,必要时用原型/预研消除;
3. 工程开发:本圈的工程活动(需求/设计/编码/测试);
4. 客户评审:评审结果,决定下一圈。

核心贡献:把"风险驱动"显式化——风险最高的部分最先被验证。

OOS 中的螺旋应用:支付网关联调是最高风险项(R1)。OOS 在项目第 2 周就用 spike(技术预研)完成"最小联调":一笔 1 元真实支付走通"下单→扣款→回调→对账"四步,把 R1 从"高"降为"低",再进入完整开发。这就是螺旋第一圈"风险分析"象限的落地。

适用:大型、高风险、一次性(不可重来)的项目,如航天、金融核心系统。

2.5 敏捷(Agile)

敏捷宣言(2001)四条价值观

• 个体和互动高于流程和工具
• 可工作的软件高于详尽的文档
• 客户协作高于合同谈判
• 响应变化高于遵循计划

(右列也有价值——"高于"意为左列更重要,而非否定右列。)

Scrum 框架

• 角色:Product Owner(产品负责人,管"做什么、优先级")、Scrum Master(过程教练)、开发团队(自组织);
• 事件:Sprint(1–4 周固定迭代)、Sprint 计划会、每日站会(15 分钟)、Sprint 评审会、回顾会;
• 工件:Product Backlog(产品待办列表)、Sprint Backlog、增量(Increment);
• 三条经验主义支柱:透明、检视、适应。

DoD(完成的定义):每个故事共享同一验收标准(如"代码合入主干 + 单测通过 + 集成测试通过 + 可演示"),防止"我这边写完了"式的伪完成。

Scrum 常见失效(对照自查)

XP(极限编程)关键实践

• 结对编程(pair programming);
• 测试驱动开发(TDD,详见第 5 章);
• 持续集成(每天多次合入主干并自动构建测试);
• 小步重构(refactoring,详见第 5 章);
• 规划游戏(估算与承诺);
• 简单设计(满足当前需求的最简设计,靠重构应对未来)。

敏捷的风险与适用边界

• 团队必须自组织且高技能,PO 必须随时可用;
• 强监管/合同里程碑型项目需要"敏捷外壳 + 阶段门禁"的混合过程;
• 大团队需要规模化框架,勿过度堆叠。

敏捷规模化框架速览(团队 >3 个时考虑)

警惕:规模化框架的复杂度是"团队数量 × 协调开销",团队少于 3 个就上 SAFe 是典型的"过度工程"。

2.6 DevOps:生命周期的闭环化

传统流程在"交付"处断裂,运维是下游接收方。DevOps 将运维纳入过程:

• 持续集成/持续交付(CI/CD):见第 11 章;
• 反馈回路:生产监控数据回流为需求输入,生命周期从"线"变成"环";
• 文化:打破开发/运维的部门墙,“你构建,你运行”(You build it, you run it)。

对过程模型的影响:

1. "测试"从阶段变成持续活动(每次合入即测试);
2. "发布"从大事件变成小步高频(金丝雀,第 11 章);
3. "运维反馈"成为需求来源(线上错误 → 新故事);
4. 过程度量从"阶段交付物"扩展到DORA 四指标(第 11 章)。

概念上,DevOps 不是一种"新过程模型",而是把生命周期接成环、并用自动化压缩反馈时延的工程文化。第 12 章的 OOS 时间线展示它与传统阶段的融合方式。

2.7 过程选型:决策指南

常见实践:混合过程。例如 OOS 项目:整体按月度迭代交付(敏捷),但支付网关集成模块采用增量+专项风险评审(螺旋思想),审计需求则维护带版本与评审记录的正式 SRS(瀑布纪律)。

选型练习模板(可直接抄用)

项目:______ 1. 需求可预测性:高/中/低,依据:______ 2. 变更成本:高/中/低,依据:______ 3. 主要风险:技术/需求/合规,最危险的一项:______ 4. 客户参与度:高/中/低,PO 是否专职:是/否 5. 团队:规模______,经验水平______,是否自组织 6. 合规:是否有审计/认证要求:______ 结论:选用______,保留______纪律(混合点),理由三条: ① ______ ② ______ ③ ______ 复审条件:当______发生时重新选型。

选型结论:没有最优模型,只有对当前风险结构的最适配过程。且过程本身需要随项目演进而检视(回顾会)与调整。选型不是一次性决定,模板末行"复审条件"是纪律。

2.8 OOS 的过程选择(含理由)

OOS 的特征:Web 系统(变更成本低)、需求随业务快速演化(电商促销玩法多变)、客户(产品部)可深度参与、强外部集成(支付/ERP)。

选择:Scrum 双周迭代 + 持续集成 + 关键集成点(支付网关)设技术预研 spike + 每月向业务方演示评审。合规相关的对账功能单独维护带评审记录的规格文档。

理由三条(对照 2.7 决策表):

1. 变更成本低(纯软件 + 可回滚)+ 需求风险高(玩法多变)→ 迭代适配;
2. PO 专职且产品部深度参与 → 满足敏捷硬条件;
3. 支付/资金合规 → 局部保留瀑布式文档纪律(混合点)。

复审条件:若团队扩到 3 个以上小队且集成复杂度上升,引入 Scrum of Scrums;若监管要求升级,扩展正式文档范围。

2.9 过程的反模式(跨模型通用)

2.10 过程健康度量

过程本身也需要度量(数据用于检视与调整,不用于考核):

用法:每 2–3 个迭代看一次趋势;某指标连续恶化 → 回顾会专项讨论;改进走第 9 章 PDCA。

2.11 本章 FAQ

Q1:"敏捷就是没有文档"对吗?
不对。敏捷降低的是"文档的体量与形式要求",提高的是"文档必须驱动决策"。架构决策(ADR)、合规需求、接口契约在任何过程下都该书面化。

Q2:小项目要不要走过程模型?
要,但裁剪到最小集:明确范围(故事清单)、可运行的完成标准(DoD)、版本管理、变更记录。过程的价值与项目风险成正比,小项目风险低 → 过程轻。

Q3:螺旋模型和"分阶段敏捷"有什么区别?
螺旋的核心是风险驱动排序(每圈先消除最大风险),阶段敏捷的核心是价值驱动排序(每迭代交付最高价值)。OOS 的支付 spike 是螺旋,双周迭代是价值驱动——两者在同一项目并存,分工不同。

Q4:团队坚持"我们就是敏捷的",但交付一直延期,可能原因?
对照 2.5 失效表逐项查:PO 缺位、范围不冻结、估算失真、DoD 缺失、技术债无偿还窗口。多数"伪敏捷"是硬条件不满足仍套用框架。

Q5:过程选型后多久该复审一次?
建议绑定自然节奏:每个发布周期(季度)或每次组织结构变化(扩编、合并、换 PO)时复审;2.8 模板末行的"复审条件"是硬触发。没有触发条件的选型等于把决定做成了信仰。

Q6:为什么过程文档要"短到能被记住"?
因为过程失效的主因不是"定义错误"而是"没人遵守"。六页的过程文档(2.1 六问)可以在入职第一天读完、在评审会上直接引用;60 页的过程手册的实际覆盖率接近零。文档长度与执行率成反比。

Q7:同一个公司里,不同项目可以用不同过程模型吗?
可以,而且常见。过程按项目选择(2.7 决策表),组织层面保留"过程资产库"(模板、检查单、度量口径),各项目从资产库裁剪。多模型并存的唯一前提:度量口径统一,否则跨项目比较失去意义,管理层看板变成数字游戏。

Q8:一个人做的独立项目,"过程"长什么样?
最小过程 = 三个动作:开工前用一句话写下目标与非目标;进行中版本管理 + 记录关键决策(README 里写也行);收尾时写一份验收自查清单并执行。这是 Scrum 对个体的极限裁剪,不是"跳过过程"的借口——过程的价值与规模无关,与风险有关。

Q9:过程模型会不会过时?
模型描述的是"如何组织反馈",这个本质不变;变的是反馈时延的工具(CI/CD、AI 辅助)。当新工具把某类反馈时延压缩一个量级,过程节奏应随之调整(如评审从周变日),但"六问"(2.1)仍然成立。判断模型是否过时的标准:它描述的反馈路径是否还与现实一致。

2.12 小结

• 过程模型 = 活动/任务/工件/角色/检查点的模板化组合;过程定义要回答六问;
• 瀑布重文档门禁,增量重早期交付,螺旋重风险驱动,敏捷重反馈与适应;
• 敏捷是价值观+框架+实践的体系,对团队与客户参与度有硬要求;
• 规模化框架按团队数量选用,警惕过度工程;
• DevOps 把运维并入过程,生命周期闭环化,度量延伸到 DORA;
• 选型看风险结构与变更成本,混合过程是常态;选型需复审;
• 过程本身要度量:节奏、质量、流动、参与、适应五维。

思考题

1. 为什么"可工作的软件高于详尽的文档"不等于"不需要文档"?OOS 的支付对账模块为什么仍需要正式文档?
2. 螺旋模型与增量模型都分阶段,本质区别是什么?
3. Scrum 的 DoD 缺失时,典型会出现哪些"伪完成"现象?
4. 为一个"医疗设备嵌入式固件"项目与一个"内部 OA 工具"项目各推荐一种过程模型,并给出三条理由。
5. 用 2.7 的选型模板,为你当前(或假设的)项目完成一次正式选型,并写出复审条件。
6. 你的团队是否存在 2.9 中的某个反模式?给出一个可执行的整改行动(含 Owner 与期限)。
7. "迭代承诺完成率 70–90% 稳定"为什么不是越高越好?100% 持续三个月说明什么?
8. 设计一次"过程审计":列出你会检查的 8 个工件与 5 个行为信号。