游戏生产生命周期与里程碑

生命周期与风险门控

里程碑不是日期承诺，而是风险承诺。每个 Gate 至少回答“已验证什么、尚未验证什么、谁负责关闭剩余风险”三件事。

里程碑设计方法

1. 以风险而非部门拆分：把玩法、性能、网络、内容产能、平台合规列为风险流；一个里程碑可以同时验收多个专业领域。
2. 以可玩构建为共同语言：文档、原型和自动化检查最终都要汇聚到可运行构建；不可运行的“完成”不能作为生产证据。
3. 固定 Definition of Done：包含代码审查、自动测试、性能预算、内容校验、变更说明和回滚路径。
4. 把范围当假设管理：用 MoSCoW 或风险排序决定砍什么，而不是把延期当作默认缓冲。
5. 短反馈循环：Agile Game Development with Scrum 强调跨职能团队、持续集成和短周期可玩增量；周期长度要服务于反馈速度，不应机械套用。

应用：从任务到可交付构建

flowchart LR
    A["产品假设"] --> B["风险原型"]
    B --> C["Vertical Slice"]
    C --> D["可重复生产"]
    D --> E["候选发布构建"]
    E --> F["平台验收"]
    F --> G["发布与监控"]
    G --> H["数据反馈"]
    H --> A

图中闭环表示发布后的数据会反过来影响下一轮假设；它不是要求所有项目都采用相同工具，而是要求每一跳都有可复核证据。

推荐把每个里程碑记录成一页：目标、范围、输入、验收证据、未决风险、owner、回滚/退出条件。生产页与 迭代与原型 负责的设计迭代互补：本页关注跨职能交付和风险门控，不替代玩法原型方法。

取舍与常见坑

• 阶段门过重：小团队若每个 Gate 都需要长文档，会减慢反馈；保留最小证据集即可。
• 只验收功能：没有性能、内容产能、平台和支持准备，功能完成仍不等于可发布。
• 把 Alpha/Beta 当日期：阶段名称必须由退出条件定义，否则会掩盖未关闭风险。
• 只做一次 Vertical Slice：切片应验证可复制的生产管线；若只是手工特制演示，不能证明量产能力。
• 发布后无人负责：运营指标、崩溃监控、客服和回滚同样需要明确 owner。