milestone-gate

name	milestone-gate
description	设计里程碑和交付门禁时使用。适用于阶段评审、上线前检查、重要节点验收。优先使用 Stage-Gate 方法 + 验收标准 + 强制门禁清单。

里程碑和交付门禁（Milestone Gates）

参考来源：Stage-Gate Process、PMBOK Phase Gates

适用场景

• 项目阶段划分
• 阶段评审检查点
• 上线前最后检查
• 重要节点的"通过/不通过"决策

核心原则

1. 里程碑 = 阶段性可验证的交付节点
   不是"做完一半"，而是"完成了某个完整产物"

2. 门禁 = 强制检查
   不通过门禁就不进入下一阶段
   即使时间紧张也不能跳过

3. 每个里程碑必须可独立验证
   不能"等下游说没问题才算通过"

4. 门禁是项目的"刹车系统"
   宁可暂停也不能让问题流到下游

好的里程碑 vs 坏的里程碑

好的里程碑：
  ✓ 有明确的验收标准
  ✓ 有具体的时间点
  ✓ 有负责工作流
  ✓ 可以独立验证（不依赖后续工作）

坏的里程碑：
  ✗ "开发完成 50%"（不可验证）
  ✗ "基本可用"（标准模糊）
  ✗ 没有时间点的里程碑
  ✗ "等所有人都觉得 OK"

标准门禁清单

需求门禁

□ PRD 已评审通过
□ 验收标准已定义（可测试）
□ 技术可行性已确认
□ 非目标范围已明确
□ 优先级已排序
□ 关键风险已识别

设计门禁

□ UI/UX 设计已完成（含状态说明）
□ API 契约已定义（OpenAPI）
□ 数据库设计已完成（DDL）
□ 关键决策已记录
□ 设计评审通过
□ 前后端能据此独立开发

开发门禁

□ 核心功能已完成
□ 单元测试通过
□ 接口联调通过
□ 代码评审完成
□ 没有阻塞性 Bug
□ 文档同步更新

测试门禁

□ 核心路径测试通过
□ 关键 Bug 已修复
□ 回归测试通过
□ 边界条件测试通过
□ 性能符合要求
□ 测试报告已输出

安全门禁

□ 代码安全评审通过
□ 依赖漏洞已修复
□ 敏感数据保护已检查
□ 鉴权权限已验证
□ OWASP Top 10 已检查
□ 安全报告已输出

上线门禁

□ 安全检查通过
□ 部署文档就绪
□ 回滚方案就绪（5 分钟内可回滚）
□ 监控告警配置完成
□ 健康检查端点正常
□ 相关方已通知
□ 上线时间窗口确认

门禁通过决策

通过：所有项打勾
  → 进入下一阶段

部分通过：核心项打勾，非核心项有 1~2 项不通过
  → 评估风险后决定：
    - 风险可控 → 通过 + 标注待办
    - 风险高 → 不通过

不通过：有核心项不打勾
  → 退回上游修复
  → 重新进入门禁

里程碑设计模板

## 项目里程碑计划

| 里程碑 | 时间点 | 验收标准 | 门禁类型 | 负责工作流 |
|--------|--------|---------|---------|----------|
| M1: 需求确认 | +15min | PRD + 验收标准已定义 | 需求门禁 | product-manager |
| M2: 接口就绪 | +50min | API 契约 + 数据库设计完成 | 设计门禁 | api-designer + database-engineer |
| M3: 开发完成 | +2h | 前后端联调通过 | 开发门禁 | backend + frontend |
| M4: 测试通过 | +2.5h | QA + 安全检查通过 | 测试 + 安全门禁 | qa + security |
| M5: 上线 | +3h | 服务上线，监控正常 | 上线门禁 | devops + sre |

### M1: 需求确认

**时间点**：项目开始 +15min
**负责工作流**：product-manager

**门禁清单**：
□ PRD 已输出（docs/prd.md）
□ 14 节结构完整
□ 至少 5 个用户故事 + 验收标准
□ 非目标范围已明确
□ 关键风险已列出（≥ 5 个）
□ 未决问题清单 ≤ 3 条

**通过后产出**：
- PRD 文档
- 风险清单
- 转交项目经理拆任务

**不通过处理**：
- 退回 product-manager 工作流
- 标注具体哪些项不通过
- 限定修复时间（不超过原计划 50%）

工作流程

1. 项目启动时：
   - 根据 WBS 和关键路径识别里程碑
   - 一般 5~7 个里程碑（XL 项目可以更多）
   ↓
2. 每个里程碑定义：
   - 时间点（基于关键路径）
   - 验收标准（可测试）
   - 门禁清单（标准 + 项目特定）
   - 负责工作流
   ↓
3. 项目执行中：
   - 每个里程碑前一步开始准备门禁检查
   - 到达里程碑时执行门禁检查
   - 通过 → 进入下一阶段
   - 不通过 → 退回 + 修复
   ↓
4. 里程碑数据沉淀：
   - 通过率
   - 平均门禁检查耗时
   - 不通过的常见原因
   - 沉淀到 field-journal

质量自检

□ 每个里程碑是否有时间点（不能"开发完成后"）
□ 每个验收标准是否可测试
□ 门禁清单是否覆盖了关键风险
□ 是否标注了负责工作流
□ 不通过处理路径是否明确
□ 是否有强制门禁（不能跳过）

常见坑

1. 里程碑太多——20 个里程碑 = 没有里程碑
2. 里程碑太少——只有"上线"一个，到了才发现一堆问题
3. 验收标准模糊——"开发完成" → 应该是"接口可调用 + 测试通过"
4. 门禁可选——"时间紧就跳过" → 失去了门禁的意义
5. 门禁清单不更新——上次的清单不适用本次项目
6. 不记录不通过原因——下次还踩同样的坑
7. "通过率 100%"——要么门禁太宽松，要么团队作弊

配套模板

• templates/milestone-plan-template.md — 里程碑计划模板
• templates/delivery-gate-checklist.md — 门禁检查清单 + 门禁评审记录模板

与其他 skill 的协作

上游：
  critical-path → 关键路径节点是天然的里程碑
  risk-management → 高风险点需要门禁拦截

下游：
  progress-tracking → 追踪门禁状态
  retrospective → 复盘门禁有效性