# 软件工程开发流程 · 自动选择与执行

> **加载场景**：开始新项目/新模块/大改动；用户问「用什么开发流程」；需要排期、拆分、评审、门禁；或现有流程明显不适配时。
>
> **目标**：根据项目约束**自动选择**合适的开发流程，而不是先让用户选「Scrum 还是瀑布」。选完给出理由、节奏、产物与门禁，然后直接按流程执行。

## 一、三条原则

1. **先约束，后偏好**：合规、合同、安全、交付日期是硬约束；团队喜好、流行方法论是软偏好。硬约束决定流程大类，软偏好只影响实践组合。
2. **流程是风险控制，不是仪式**：每个流程环节都要回答「它在降低什么风险」。不能降低风险的会议、文档、看板列，删掉。
3. **轻量可执行**：一个人/小团队不要搬全套 Scrum/SAFe；大团队也不要只靠口头同步。流程颗粒度与团队规模、风险匹配。

## 二、先读项目画像（自动收集，不先问方法论）

按顺序读：`README` / `docs/` / `AGENTS.md` / issue 与需求文档 / `git log` / CI 配置 / 测试 / 部署脚本 / 合规材料 / 现有团队约定。能推断的就不要问。

需要判断的信号：

| 信号 | 取值 | 影响 |
|---|---|---|
| 需求稳定性 | 高 / 中 / 低 | 低 → 迭代、原型、滚动规划 |
| 不确定性与技术风险 | 高 / 中 / 低 | 高 → Spiral、探针、原型 |
| 合规/安全等级 | 高 / 中 / 低 | 高 → V-Model、阶段门禁、可追溯 |
| 合同/范围 | 固定总价 / 固定日期 / 持续产品 | 固定 → 基线、变更控制、增量交付 |
| 团队规模与分布 | 1–3 / 4–9 / 10+ / 多供应商 | 大 → 域拆分、接口契约、同步机制 |
| 存量系统占比 | 新建 / 混合 / 维护为主 | 维护 → Kanban、特征测试、绞杀者 |
| 客户反馈通道 | 连续 / 周期 / 无 | 无 → 阶段评审、验收标准前置 |
| 变更成本/架构耦合 | 低 / 中 / 高 | 高 → 架构评审、ADR、演进式设计 |
| 上线频率 | 持续 / 周期 / 一次性 | 持续 → DevOps、主干开发、自动化门禁 |
| AI Agent 参与度 | 辅助 / 主导编码 / 自主执行 | 高 → 小垂直切片、测试先行、人工复核 |

**只问缺失的关键项**，最多 3 个问题，且问事实不问方法论：
- 「交付是固定总价/固定日期，还是持续迭代？」
- 「有没有合规/安全/审计要求？具体标准是什么？」
- 「需求变化频率、客户能否持续反馈？」

## 三、自动选择算法（硬约束优先）

### 第 1 步：硬约束一票决定

| 条件（满足即优先） | 主流程 | 必配 |
|---|---|---|
| 安全/医疗/航空/汽车/金融审计等高合规 | **V-Model / 阶段门禁瀑布** | 需求追溯矩阵、V&V、评审记录、变更控制；阶段内部允许迭代 |
| 固定总价/固定范围合同，验收标准明确 | **增量交付 + 基线管理** | WBS、基线、变更单、阶段验收；避免一次性大爆炸 |
| 高不确定性/未验证技术/新市场 | **Spiral / 迭代式发现** | 风险清单、原型/探针、每个螺旋的退出标准 |
| 持续产品、需求常变、反馈连续 | **Scrum** | 产品待办、Sprint、评审、回顾、DoR/DoD |
| 运维/存量维护/持续流入的缺陷 | **Kanban** | WIP 限制、流动指标、阻塞可视化、发布策略 |
| 1–3 人、一次性/内部小工具 | **轻量迭代** | 短周期、可运行增量、测试与文档按风险裁剪 |
| 多团队/多供应商 | **按业务域拆分 + Scrum/Kanban** | 接口契约、跨团队同步、集成门禁；不要默认上重型 scaling 框架 |
| 生产事故/紧急修复 | **事件响应流程** | 先止血、再根因、回归测试、复盘；不走完整需求流程 |

> 硬约束冲突时：**合规/安全 > 合同 > 不确定性 > 交付节奏 > 团队偏好**。例如「高合规 + 需求常变」→ V-Model 的阶段门禁 + 阶段内短迭代，而不是纯 Scrum。

### 第 2 步：没有硬约束时打分

对 6 个维度各打 0–2 分（0 低、1 中、2 高）：

| 维度 | 高分为哪边 |
|---|---|
| 需求变化 | 高 → 敏捷/迭代 |
| 技术不确定性 | 高 → Spiral/原型 |
| 交付连续性 | 高 → Kanban/DevOps |
| 合规/审计 | 高 → V-Model/门禁 |
| 团队规模 | 高 → 域拆分/契约 |
| 存量维护占比 | 高 → Kanban/绞杀者 |

选择分数最高的流程；接近时用「主流程 + 叠加实践」，不要同时套两套完整流程。

### 第 3 步：输出选择结果（然后直接执行）

```md
流程选择：<主流程> + <叠加实践>
依据：<2–4 条项目事实，不写方法论口号>
节奏：<迭代长度/看板策略/阶段门禁>
产物：<需求/设计/测试/发布/复盘>
门禁：<进入下一阶段或上线的条件>
何时重选：<约束变化时，例如合规升级、需求转稳定、团队扩张>
```

除非缺少关键事实，**不要停下来问「这个流程可以吗」**；先按最合理的流程开工，把假设写进 `PROCESS.md`，在第一个评审点校正。

### 三个快速示例

| 项目画像 | 选择 | 依据与门禁 |
|---|---|---|
| 5 人产品团队、需求常变、可持续反馈、无强合规 | **Scrum + XP + CI/CD** | 两周 Sprint、DoR/DoD、每 Sprint 可运行增量；CI 绿 + 评审通过才合并 |
| 银行/医疗项目、强审计、需求相对稳定 | **V-Model + 阶段门禁**（阶段内短迭代） | 需求追溯矩阵、V&V、评审记录；每个 gate 有 evidence 才进入下一阶段 |
| 10 年单体、缺陷与需求持续流入、不能停机重写 | **Kanban + 绞杀者 + 特征测试** | WIP 限制、流动指标、按风险排优先级；先补特征测试再改，禁止大爆炸重写 |

## 四、流程库（按需读，不要全用）

### 1. Waterfall（瀑布）

- 适用：需求稳定、范围明确、变更成本高、合同要求阶段验收。
- 节奏：需求 → 设计 → 实现 → 测试 → 交付，阶段间门禁。
- 产物：需求规格、设计说明、测试计划、验收记录。
- 风险：反馈晚；需求一变返工大。
- 反模式：需求没冻结就开工；测试阶段才第一次集成。

### 2. V-Model（V 模型）

- 适用：高合规、安全关键、需要验证与确认对应关系。
- 核心：左侧每层需求/设计，右侧都有对应的验证/确认活动；需求可追溯。
- 产物：追溯矩阵、验证计划、确认计划、评审与审计记录。
- 注意：不是「瀑布的另一种叫法」；阶段内可以做原型与迭代，但门禁与证据不能省。

### 3. Incremental（增量）

- 适用：固定日期/固定范围，但可以按功能分批交付；希望尽早拿到价值。
- 做法：先做可运行骨架，再按优先级增量；每增量可独立验收。
- 产物：增量计划、基线、验收标准、变更记录。
- 风险：架构没留扩展点，增量变成补丁堆叠。

### 4. Iterative（迭代）

- 适用：需求不完全清楚，但可以在短周期内获得反馈。
- 做法：固定短周期，每周期交付可运行增量；根据反馈调整下一周期。
- 与 Scrum 区别：迭代是底层节奏，Scrum 是带角色/会议/待办的完整框架；小团队可以只用迭代，不必上全套 Scrum。

### 5. Spiral（螺旋）

- 适用：高风险、新技术、长周期、需要先验证可行性。
- 做法：每圈先识别最大风险 → 原型/探针 → 评估 → 决定继续/调整/停止。
- 产物：风险清单、原型结论、每圈退出标准。
- 风险：只做原型不落地；把螺旋做成无限期调研。

### 6. Scrum

- 适用：产品型团队、需求常变、有稳定反馈通道、团队 4–9 人较合适。
- 角色：Product Owner、Scrum Master、开发团队（可兼任，但职责要清）。
- 事件：Sprint 规划、每日同步、评审、回顾；Sprint 内不随意插入新需求。
- 产物：产品待办、Sprint 待办、增量、DoR/DoD、回顾行动项。
- 反模式：没有 PO、Sprint 中途加需求、只开站会不改计划、把故事点当绩效考核。

### 7. Kanban

- 适用：运维、支持、存量维护、需求持续流入、优先级频繁变化。
- 核心：可视化工作流、WIP 限制、管理流动、显式策略。
- 指标：前置时间、周期时间、吞吐量、WIP、阻塞时长。
- 反模式：只画看板不限 WIP；列越加越多；把 Kanban 当「没有计划」。

### 8. XP（极限编程）

- 适用：需求变化快、质量要求高、团队能承受工程纪律。
- 实践：TDD、持续集成、重构、简单设计、结对/代码评审、小步发布、集体代码所有权。
- 与 Scrum 关系：XP 是工程实践，Scrum 是管理框架；可以 Scrum + XP，也可以 Kanban + XP。
- 反模式：只挂「敏捷」牌子，不写测试、不集成、不重构。

### 9. DevOps / 持续交付

- 适用：需要高频、可重复、可回滚的发布。
- 实践：主干开发/短分支、CI、自动化测试、制品管理、环境即代码、灰度/回滚、可观测性、事后复盘。
- 指标：部署频率、变更前置时间、变更失败率、MTTR。
- 注意：DevOps 是交付能力，不是替代需求/架构流程；没有测试与监控的「快」是负债。

### 10. Hybrid / Stage-Gate Agile

- 适用：既要合规门禁，又要迭代反馈；大型组织常见。
- 做法：阶段门禁保留（合规/架构/安全），阶段内用短迭代与可运行增量；每个 gate 的 evidence 自动收集。
- 反模式：门禁只盖章不检查；迭代交付物与门禁证据两张皮。

### 11. DDD / Event Storming（发现实践，不是完整流程）

- 适用：业务复杂、边界不清、多团队协作。
- 用法：事件风暴对齐领域事件与边界，再决定限界上下文；产出上下文映射与统一语言。
- 注意：不要为了 DDD 而 DDD；简单 CRUD 不需要全套战术模式。

## 五、按场景直接套用

### 0→1 新产品/新方向

1. 1 周 discovery：用户问题、约束、最大风险。
2. 2–3 个原型/探针验证最大风险（Spiral 一圈）。
3. 写一页 `PROCESS.md`：选择、假设、退出标准。
4. MVP 按垂直切片交付，每片可运行、可验收、可回滚。

### 持续产品

- 主流程：Scrum 或 Kanban（按需求稳定性选）。
- 工程实践：XP + CI/CD + 代码评审 + ADR。
- 每 4–6 个迭代做一次流程回顾：删掉不产生价值的仪式。

### 固定范围/固定日期交付

- 先基线：范围、验收标准、变更流程。
- 按增量交付，优先做端到端骨架与高风险项。
- 任何范围变更走变更单，不口头插入。

### 存量系统/维护

- 先补特征测试（characterization tests），再改。
- 用绞杀者模式逐步替换，不做大爆炸重写。
- 用 Kanban 管理流入，设 WIP 上限；按风险排优先级。

### 高合规/安全关键

- V-Model + 阶段门禁；需求、设计、代码、测试、发布全链路可追溯。
- 每个门禁有明确 evidence；变更影响分析必须更新追溯矩阵。
- 参考适用标准（如 ISO/IEC/IEEE 12207、ISO/IEC/IEEE 29119、IEC 62304、ISO 26262、DO-178C），按项目实际适用版本执行，不硬套。

### 生产事故/紧急修复

1. 止血（回滚/降级/开关）。
2. 复现与定位，保留证据。
3. 最小修复 + 回归测试。
4. 复盘：根因、检测、预防、行动项；不要把「临时绕过」当长期修复。

### AI Agent 主导编码

- 无论选什么流程，都按**小垂直切片**执行：一次一个可验证目标。
- 先写/补测试，再改代码；每片跑 CI；每片人工 review。
- 不一次性生成大模块；不跳过集成；不把「能编译」当验收。
- 关键决策写 ADR / `PROCESS.md`，让下一位 agent 能接续。

## 六、所有流程都适用的工程门禁

- **版本控制**：小提交、清晰信息、可回滚；不提交密钥与生成物。
- **测试**：单元 + 集成 + 关键端到端；修 bug 先补回归测试。
- **CI**：每次提交跑构建、测试、静态检查；失败阻断合并。
- **评审**：代码评审 + 架构/安全评审（按风险）；不用「我自己看过」代替。
- **文档**：README、ADR、接口契约、运行手册；只写会维护的。
- **安全**：输入校验、鉴权、依赖与密钥管理、威胁建模（高风险时）。
- **可观测性**：日志、指标、追踪、告警；上线前想好怎么发现失败。
- **发布**：灰度/回滚预案；数据库变更向前兼容。
- **复盘**：事故与迭代都复盘；行动项有负责人和期限。

### DoR / DoD 最小版

- **DoR**：目标清楚、验收标准可测、依赖已识别、风险有对策、大小可在一个周期内完成。
- **DoD**：代码评审通过、测试通过、CI 绿、文档/变更记录更新、可部署/可回滚、验收人确认。

## 七、度量：看流动与结果，不看忙碌

优先看：前置时间、周期时间、吞吐量、WIP、阻塞时长、部署频率、变更失败率、MTTR、逃逸缺陷。
不要用代码行数、故事点、提交次数做个人绩效；它们容易被 gaming，且不反映价值。

## 八、常见反模式

- 让用户先选方法论，而不是先看约束。
- 「敏捷」但没有可运行增量、没有测试、没有反馈。
- 「瀑布」但需求没冻结、阶段门禁只盖章。
- 看板不限 WIP，列越加越多。
- Scrum 中途插需求，Sprint 变成「两周一次的大瀑布」。
- 只做原型不落地，或只写文档不验证。
- 流程很重但没有 CI/测试/监控；流程很轻但高风险项目没有门禁。
- 把 AI 生成速度当交付速度，跳过评审与集成。

## 九、与其他技能的关系

- 代码怎么写：`alibaba-java-standards` / `f2e-spec`。
- 单体/微服务架构、技术栈、环境与门禁：`fullstack-monolith-dev` / `fullstack-microservice-dev`。
- 故障排查：`fullstack-monolith-debug` / `fullstack-microservice-debug`；排障本身按事件响应流程，不改项目主流程。
- 本技能是**横切流程层**：先选流程，再调用对应开发/排查技能。

## 十、交付前自检

- [ ] 已读项目上下文，列出硬约束（合规/合同/安全/日期）。
- [ ] 已选择主流程，并说明 2–4 条依据；没有让用户先选方法论。
- [ ] 已写出节奏、产物、门禁、重选条件（`PROCESS.md` 或对话摘要）。
- [ ] 工程门禁（测试/CI/评审/回滚/可观测性）没有被流程借口绕过。
- [ ] 高风险项目有原型/探针/阶段门禁；低风险项目没有过度流程。
- [ ] 约束变化时会重新评估流程，而不是一条路走到黑。