game-scope-check

AlterLab GameForge -- 范围检查工作流

范围蔓延是独立游戏的头号杀手。不是缺乏才华，不是创意不好，也不是引擎限制。游戏夭折，是因为项目规模不断膨胀，超出了团队完成它的能力。它每次都以一个“很小”的新增内容开始，单独看都合情合理，累积起来却足以致命。危险之处在于，范围蔓延让人觉得是在取得进展——添加功能让人觉得很有成效，删减却让人觉得像是失败。这个工作流旨在扭转这种心理：删减是一种技能，范围紧凑才是成就。

Team Cherry 以 3 人团队发布了 Hollow Knight。ConcernedApe 独自发布了 Stardew Valley。这两个项目的目标都不小——但他们对纳入和删减的内容都执行了毫不妥协的纪律。能够发布的游戏，并不是功能列表最长的那些，而是每项功能都经过诚实的范围核算，证明自己值得保留的那些。

核心原则：**一款包含 8 个出色功能的完整游戏，胜过一款有 20 个功能半途而废的弃作。**这个工作流通过具体工具而非一厢情愿的想法来贯彻这一原则。

目的与触发条件

在以下情况下使用此工作流：

• 自上次范围检查以来，功能列表有所增长
• 有人说“我们能把这个也加进去吗？”或“要不我们再加上……”
• 里程碑截止日期临近，但团队信心不足
• 团队感到不堪重负，却说不清原因
• 冲刺速度持续低于计划产能
• 任何利益相关者（包括你自己）都反对删减功能
• 项目从未进行过正式的范围检查

要解决的问题：

• 只增不减的功能列表
• “再加一项就好”的模式不断累积，最终导致错过截止日期
• 所有功能都被标为“必须有”，因为没人愿意确定优先级
• 功能与可用工时之间缺少明确关联
• 团队缺乏决定删减内容的框架，因此不敢删减功能
• 范围讨论演变成观点之争，而非以数据为依据的决策

关键规则

1. **加一项，减一项。**添加一项功能，就必须删掉一项工作量相当的功能。没有例外。不能说“我们会更努力”，也不能说“到时候再想办法”。预算是固定的。把一项功能从“不会有”提升到“应该有”，就意味着必须把另一项功能从“应该有”降到“不会有”。Team Cherry 为了按时发布 Hollow Knight，删掉了整个区域——而游戏也因此更出色，因为每个保留下来的区域都打磨得无比精致。

2. **百分比就是铁律。**MoSCoW 分配必须符合：必须有占总工作量的 60%，应该有占 25%，可以有占 15%。如果必须有超过 60%，无论每项功能单独看来有多重要，项目都面临风险。

3. **评分，不争论。**功能评分矩阵用算术取代观点。根据影响、可行性和风险为功能评分。由计算结果决定。如果团队成员有异议，应针对具体评分提出质疑，而不是质疑结果。

4. **缓冲时间不可或缺。**缓冲时间少于 20% 的计划，必然会错过截止日期。缓冲时间用于应对意外，而在游戏开发中，意外本就是意料之中的事。把缓冲时间视为不可侵犯——它不是“用于添加功能的额外时间”。

5. **冻结日期不容变通。**任何里程碑前 3 天，停止添加功能。冻结后，只允许修复 Bug 和打磨完善。要打破冻结，必须获得制作人级别的批准，并在其他地方相应删减内容。

6. **只做诚实估算。**如果你从未构建过类似系统，就把估算时间加倍。如果技术不熟悉，就加到三倍。乐观估算就是范围蔓延滋生的温床。

工作流

---

🧠 阶段 1：功能清单

目标：列出当前已规划、进行中或已提出的所有功能。

在评估范围之前，你需要全面了解情况。本阶段会生成一份详尽清单。暂时不要筛选——即使你觉得某些功能最终会被砍掉，也要先列出来。

FEATURE INVENTORY
-------------------------------------------------
ID   | Feature             | Status        | Requestor    | Est. Hours
-------------------------------------------------
F01  | [feature name]      | [planned/     | [who asked]  | [honest
F02  | [feature name]      |  in-progress/ |              |  estimate]
F03  | [feature name]      |  complete/    |              |
...  |                     |  requested]   |              |
-------------------------------------------------

Capture rules:
- Include features already in progress (sunk cost does not protect them)
- Include features someone mentioned casually ("wouldn't it be cool if...")
- Include features assumed but never written down (save system, settings menu)
- Estimate in hours, not days. Hours force specificity.
- If you cannot estimate a feature, mark it [UNKNOWN] -- that is itself a red flag

请用户逐一介绍所有已规划的功能。深入询问可能遗漏的功能：“有设置菜单吗？有存档系统吗？有教程吗？有选项屏幕吗？支持控制器吗？”这些被默认认为理所当然的功能往往会耗费大量时间，却从未出现在清单上。

---

🎯 阶段 2：MoSCoW 分类

目标：将所有功能划分为四个优先级层级，并严格遵守百分比要求。

MoSCoW 不是愿望清单，而是一种资源分配框架。百分比是约束，而不是建议。

MoSCoW CLASSIFICATION
-------------------------------------------------
MUST HAVE (60% of total effort)
  The game literally does not function or ship without these.
  Test: "If this feature is missing, is the product broken?"
  - F01: [feature] -- [hours] -- Reason: [why it's essential]
  - F03: [feature] -- [hours] -- Reason: [why it's essential]
  Subtotal: [X hours] / Target: [60% of total hours]

SHOULD HAVE (25% of total effort)
  Significantly improves the game but it ships without them.
  Test: "Would a reviewer notice this is missing?"
  - F04: [feature] -- [hours] -- Reason: [why it matters]
  Subtotal: [X hours] / Target: [25% of total hours]

COULD HAVE (15% of total effort)
  Nice to have. First to be cut when time runs short.
  Test: "Would anyone outside the team notice this?"
  - F07: [feature] -- [hours] -- Reason: [what it adds]
  Subtotal: [X hours] / Target: [15% of total hours]

WON'T HAVE (0% -- explicitly deferred)
  Documented and deferred. Not forgotten, just not now.
  These protect the team from revisiting already-made decisions.
  - F09: [feature] -- Reason: [why it's deferred]
  - F10: [feature] -- Reason: [why it's deferred]
-------------------------------------------------

RED FLAGS:
- Won't Have is empty --> Every feature cannot be essential. Be honest.
- Must Have exceeds 60% --> Either the game is too ambitious or the
  classification is too generous. Demote features.
- All features are "Must Have" --> This is not prioritization. Start over.
  Force-rank the Must Haves against each other.

---

🚨 阶段 3：功能评分矩阵

目标：用量化评分取代主观争论，为每项功能打分。

对所有优先级高于“不会实现”的功能进行评分。公式为： 得分 =（影响 x 可行性）/ 风险

FEATURE SCORING MATRIX
-------------------------------------------------
Feature    | Impact | Feasibility | Risk  | Score  | Verdict
           | (1-5)  | (1-5)       | (1-5) |        |
-------------------------------------------------
[F01]      | [  ]   | [  ]        | [  ]  | [  ]   | [Keep/Evaluate/Cut]
[F02]      | [  ]   | [  ]        | [  ]  | [  ]   | [Keep/Evaluate/Cut]
...        |        |             |       |        |
-------------------------------------------------

SCORING GUIDE:
  Impact (1-5):
    5 = Core loop depends on it. Game is broken without it.
    4 = Major enhancement to player experience.
    3 = Noticeable improvement. Reviewers would mention it.
    2 = Minor polish. Players might notice if told.
    1 = Developer-facing. Players never see it directly.

  Feasibility (1-5):
    5 = Team has built this exact thing before. Hours are certain.
    4 = Similar to past work. Minor unknowns.
    3 = New territory but understood conceptually. Moderate unknowns.
    2 = Significant unknowns. Requires research or prototyping.
    1 = Nobody on the team has done this. Major technical risk.

  Risk (1-5):
    5 = Could derail the project if it goes wrong.
    4 = Could delay the milestone significantly.
    3 = Could cause a sprint to slip.
    2 = Might need rework but recoverable.
    1 = Low consequence if it fails.

VERDICT THRESHOLDS:
  Score >= 3.0  -->  KEEP. Feature earns its place.
  Score 2.0-3.0 -->  EVALUATE. Discuss. Can risk be reduced? Can scope shrink?
  Score < 2.0   -->  CUT. Move to Won't Have. Do not negotiate.

---

📋 阶段 4：时间线合理性检查

目标：比较剩余工作与剩余时间，并计算缓冲时间。

在这里，乐观会遇上算术。数字不在乎你的雄心壮志。

TIMELINE SANITY CHECK
-------------------------------------------------
CAPACITY CALCULATION:
  Team members:           [N]
  Available hours/week:   [X hours per person]
  Weeks remaining:        [Y weeks to milestone]
  Gross capacity:         [N x X x Y] hours
  Overhead deduction:     [-15% for meetings, admin, context switching]
  Net capacity:           [result] hours

WORK REMAINING:
  Must Have (incomplete):  [hours]
  Should Have (planned):   [hours]
  Could Have (planned):    [hours]
  Total planned work:      [hours]

BUFFER CALCULATION:
  Available buffer:        [Net capacity - Total planned work]
  Buffer percentage:       [buffer / net capacity x 100]%

  >= 30% buffer  🟢  HEALTHY. Room for surprises. Ship with confidence.
  20-30% buffer  🟡  CAUTION. Tight but manageable if no major surprises.
  10-20% buffer  🟠  WARNING. One surprise away from missing the deadline.
  < 10% buffer   🔴  CRITICAL. The deadline will be missed. Cut scope now.
  Negative buffer 💀  OVER-COMMITTED. The math says this is impossible.
                      Cut aggressively or extend the deadline.
-------------------------------------------------

REALITY ADJUSTMENTS:
  - Solo dev? Multiply estimates by 1.5 (context-switching overhead)
  - First game? Multiply estimates by 2.0 (learning curve)
  - Part-time team? Use actual committed hours, not aspirational hours
  - Unfamiliar engine? Add 15-25% to all estimates

---

📊 阶段 5：范围蔓延检测

目标：识别表明范围正在失控扩大的迹象。

范围蔓延有明显的征兆。请检查以下警示信号：

SCOPE CREEP DETECTION CHECKLIST
-------------------------------------------------
Signal                                          | Present?
-------------------------------------------------
Feature list has grown since last check         | [Y/N]
No items in Won't Have category                 | [Y/N]
All features are classified "Must Have"         | [Y/N]
"Just one more thing" has been said recently    | [Y/N]
Features added without equivalent cuts          | [Y/N]
Estimates trending upward on existing features  | [Y/N]
New features appearing from casual conversation | [Y/N]
Buffer percentage decreasing sprint over sprint | [Y/N]
Team morale declining despite "progress"        | [Y/N]
Milestone dates have shifted more than once     | [Y/N]
-------------------------------------------------

SEVERITY:
  0-2 signals  🟢  Healthy scope management.
  3-4 signals  🟡  Early warning. Address now before it compounds.
  5-7 signals  🟠  Active scope creep. Immediate intervention needed.
  8-10 signals 🔴  Project at risk. Full scope reset required.

---

🛠️ 阶段 6：变更冻结协议

目标：为里程碑截止日期设定严格界限。

任何里程碑开始前 3 天冻结功能新增。这是强制要求。

CHANGE FREEZE PROTOCOL
-------------------------------------------------
Milestone:          [name]
Milestone date:     [date]
Freeze date:        [milestone date - 3 days]

AFTER FREEZE, PERMITTED:
  - Bug fixes for existing features
  - Polish on existing features (animation, juice, audio)
  - Documentation and store page updates
  - Build and deployment pipeline work

AFTER FREEZE, PROHIBITED:
  - New features of any size
  - "Small" additions ("it'll only take an hour")
  - Scope changes to existing features
  - New art assets for unreleased features

FREEZE BREAK PROCEDURE (emergency only):
  1. Producer (or project lead) formally approves
  2. Equivalent-effort feature is cut simultaneously
  3. Decision is documented with rationale
  4. This counts as a scope creep signal in the next detection check
-------------------------------------------------

输出格式

此工作流会生成一份范围评估报告：

# Scope Assessment Report

## Traffic Light Status
[🟢 HEALTHY / 🟡 CAUTION / 🟠 WARNING / 🔴 CRITICAL]

## Summary
[2-3 sentences: overall assessment, key concern, recommended action]

## Feature Inventory
[Total features: N | Scored: N | Cut: N | Deferred: N]

## MoSCoW Breakdown
| Category    | Features | Hours | % of Total | Target % | Status |
|-------------|----------|-------|------------|----------|--------|
| Must Have   | [N]      | [X]   | [Y%]       | 60%      | [OK/OVER] |
| Should Have | [N]      | [X]   | [Y%]       | 25%      | [OK/OVER] |
| Could Have  | [N]      | [X]   | [Y%]       | 15%      | [OK/OVER] |
| Won't Have  | [N]      | --    | --         | --       | [populated/empty] |

## Feature Scores
[Sorted by score descending. Features below 2.0 marked for cut.]

## Timeline Assessment
- **Net capacity:** [hours]
- **Planned work:** [hours]
- **Buffer:** [hours] ([X%])
- **Buffer status:** [🟢/🟡/🟠/🔴]

## Scope Creep Signals
[N of 10 signals detected. List active signals.]

## Change Freeze
- **Next milestone:** [name] on [date]
- **Freeze date:** [date]
- **Days until freeze:** [N]

## Recommended Actions
1. [Most urgent action]
2. [Second priority]
3. [Third priority]

## Features to Cut (Recommended)
[List with rationale for each cut]

## Features to Keep (Confirmed)
[List with score and pillar alignment for each]

质量标准

成功的范围检查需满足以下所有条件：

• 每项已规划功能都有真实的工时估算
• MoSCoW 百分比与目标值（60/25/15）的偏差在 5% 以内
• “不会实现”类别至少包含 2 项（如果为空，说明检查不够诚实）
• 计算缓冲百分比，并报告红黄绿灯状态
• Must Have 或 Should Have 中不得保留得分低于 2.0 的功能
• 对会话期间新增的任何功能，都执行了“新增一项，移除一项”规则
• 已检查范围蔓延信号，并报告其数量
• 已为下一个里程碑确定变更冻结日期
• 报告具有可执行性——团队清楚知道具体要构建什么、跳过什么
• 所有范围决策都能追溯到评分和产能计算，而非主观意见

交叉引用

• @docs/game-design-theory.md -- 功能应与之保持一致的设计支柱
• @docs/collaboration-protocol.md -- 如何在不同角色之间沟通范围变更
• @docs/coordination-rules.md -- 发生范围冲突时的升级处理路径
• @templates/sprint-plan.md -- 使用范围检查结果的冲刺计划模板
• 工作流交接：接收来自 game-brainstorm 或 game-design-review 的输入， 并将结果交给 game-sprint-plan 进行执行规划

反模式

出现以下情况时，范围检查会失效：

• 盖章走过场： 所有内容都能通过，因为没人愿意起冲突。如果检查没有砍掉至少一项功能，那就说明检查不够严格。
• 挟持功能：“我们都已经开始做了，不能砍掉。”沉没成本不是继续开发的理由。如果剩余工作量超过功能的价值，就砍掉它。Supergiant 在《Hades》开发期间砍掉了原有的护盾机制，并用投射系统取而代之。护盾机制已经投入了数月的开发时间，而投射系统让游戏变得更好。
• 暗中添加： 功能未经 MoSCoW 分类便悄悄加入。每项功能，无论多小，都必须经过矩阵评估。
• 无穷无尽的必备项： 所有功能都是“必备项”，因为团队把“我想要这个”和“游戏需要这个”混为一谈。要果断地强制排序。
• 缺少缓冲：“我们不需要缓冲时间，只要更努力就行。”缓冲不是懒惰保险，而是现实保险。ConcernedApe 开发《Stardew Valley》时，计划了长达数年的开发时间，其中包含大量缓冲时间——而且他把每一小时都用上了。

属于 AlterLab GameForge 独立游戏开发技能套件。