开发方法选择：判断依据清单
开发方法的选择要在预测型、迭代型、增量型、敏捷型与混合型之间做判断，依据包括需求确定性、交付能否切分、合规与评审约束、团队与客户协作能力、合同与验收模式、运维与回滚能力。结论要写入项目管理计划并说明理由，便于后续复核与调整。
基本信息
| 可选方法 | 预测型、迭代型、增量型、敏捷型、混合型 |
|---|---|
| 判断维度 | 需求确定性、交付可切分性、合规约束、团队能力、合同模式 |
| 决策产出 | 生命周期与开发方法选择说明，写入项目管理计划 |
| 复核时点 | 阶段关口或重大变更时复核方法是否仍适用 |
| 常见冲突 | 合同与治理不支持迭代却强行做敏捷 |
典型使用场景
- 新项目启动：根据需求确定性决定是前期冻结范围还是边做边探索
- 交付可分批上线时：采用增量或敏捷方式，先交付高价值部分
- 强合规行业：采用预测型主体加迭代式的需求澄清，兼顾文档与灵活性
- 合同为固定总价时：用预测型范围管理配合里程碑验收，避免迭代与付款冲突
- 混合项目：硬件部分预测型、软件部分迭代型，需明确两段的接口与节奏
判断依据清单
判断依据清单
需求：可前期冻结 / 需探索验证
交付：整体一次切换 / 可分批上线
合规：评审节点刚性程度、文档与留痕要求
团队：与客户协作紧密度、跨职能能力
合同：固定总价或开口合同、验收与付款方式
运维：上线窗口与回滚能力
结论：写明所选方法与理由，并列出不适用选项的原因方法适用对照
| 方法 | 适用条件 | 主要风险 |
|---|---|---|
| 预测型 | 需求稳定、范围可前期冻结 | 变更代价高，响应慢 |
| 迭代型 | 需求需逐步澄清 | 迭代节奏与外部评审冲突 |
| 增量型 | 交付可分批上线 | 分批集成带来额外协调成本 |
| 敏捷型 | 需求不确定、客户可深度参与 | 合同与治理不支持时易失控 |
| 混合型 | 不同部分特征差异明显 | 两段节奏衔接不当造成等待 |
开发方法不是二选一：同一个项目可以在需求澄清阶段用迭代、在交付阶段用预测型，关键是明确各阶段的规则与接口。
合同与治理不支持迭代时强行做敏捷，会在验收与付款环节出现结构性冲突，团队做得再好也无法顺利结算。