开发方法谱系是什么
开发方法按需求确定性与交付节奏形成一个谱系：预测型一次规划到底，迭代型反复细化方案，增量型分批交付可用功能，敏捷型用短周期持续反馈，混合型则在不同部分组合使用。它不是立场之争，而是匹配问题：需求越不确定、试错越便宜，就越适合往迭代与敏捷方向走。
基本信息
| 适用过程 | 开发生命周期与方法的确定（PMBOK 第 6 版 2.5 及相关章节） |
|---|---|
| 五大类型 | 预测型、迭代型、增量型、敏捷型、混合型 |
| 选择变量 | 需求确定性、变更成本、交付节奏、合规强度 |
| 常见组合 | 硬件预测加软件敏捷，前段探索加后段交付 |
典型使用场景
- 项目启动阶段选型：确定生命周期形态，影响合同、预算与评审方式
- 招投标说明：在采购文件中写明交付节奏，避免与合同模式错配
- 合规类项目：在刚性评审节点之间嵌入迭代开发，兼顾留痕与响应
- 平台与产品混合交付：底层平台用预测型，上层应用用敏捷型
- 试错成本高的场景：硬件或产线相关部分先做原型验证再定稿
方法谱系
| 方法 | 需求特征 | 适用场景 |
|---|---|---|
| 预测型 Predictive | 需求稳定、可前期定义 | 合规严格、变更成本高的工程 |
| 迭代型 Iterative | 需求早期不清 | 方案验证与技术探索 |
| 增量型 Incremental | 可拆分功能块 | 按业务模块分批上线 |
| 敏捷型 Agile | 需求高频变化 | 市场反馈驱动的产品 |
| 混合型 Hybrid | 部分稳定、部分探索 | 硬件预测加软件敏捷 |
选择依据
| 判断维度 | 倾向预测型 | 倾向敏捷型 |
|---|---|---|
| 需求确定性 | 需求可前期定义清楚 | 需求随市场快速变化 |
| 变更成本 | 后期变更代价极高 | 变更可低成本吸收 |
| 交付节奏 | 一次或分阶段交付 | 短周期持续交付 |
| 合规与评审 | 强制阶段门控与审批 | 评审可嵌入迭代内 |
| 客户参与 | 客户按节点验收 | 客户可高频参与反馈 |
选择思路
选择思路
需求不确定性高 + 交付可切分 -> 敏捷或增量
合规与安全评审刚性 + 集成依赖多 -> 预测型或混合型
试错成本高（硬件、产线、法规） -> 前期验证与阶段门控
# 同一项目内可分段选择：探索段用迭代，交付段用预测落地要点
- 方法与合同匹配：合同按一次交付、执行按迭代交付会造成严重错配
- 评审与门控写进计划：告诉团队什么时候必须停下来做合规检查
- 度量口径随之调整：预测型看偏差，敏捷型看增量与流动效率
- 团队成熟度决定可选项：缺少自组织能力的团队直接上敏捷风险很高
方法选择要与组织治理和合同模式匹配，否则会出现合同按一次交付、执行按迭代交付的错配，责任与验收口径都说不清。
预测型不等于僵化：在预测型项目中同样可以用原型降低不确定性，只是变更与验收仍按阶段门控执行。
生命周期形态会影响合同结构、团队编制与预算节奏，因此选型应当在立项阶段完成，开工后再改的代价远高于前期讨论。