game-sprint-plan

AlterLab GameForge——冲刺规划工作流

游戏开发冲刺失败的原因与软件开发冲刺不同。SaaS 团队面临的是需求不明确和优先级不断变化的问题。游戏团队面临的则是跨专业依赖，以及“好玩”这一概念本身难以预测的问题。你可以完美地规划一套库存系统，并按计划完成开发，却在试玩测试中发现它让游戏变得更糟。Supergiant 在 GDC 演讲中介绍的冲刺模式考虑到了这一点：每个冲刺都明确预留“探索时间”——用来检验已开发的内容实际体验是否出色，而不只是确认它能否运行。

游戏冲刺规划必须纳入结构化的探索时间、可灵活调整且不会陷入混乱的明确范围层级，以及尊重美术到集成流程顺序性的依赖模型。此工作流将产出一份具体的冲刺计划文档，供团队据此执行。

目的与触发条件

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

• 团队即将开始新一轮开发冲刺
• 独立开发者想规划接下来 1-2 周的工作
• 冲刺回顾之后，规划下一轮迭代时
• 临近里程碑，需要拆分工作时
• 用户完成了 game-brainstorm 或 game-design-review，需要将设计决策转化为可执行任务

此工作流可解决的问题：

• 冲刺目标含糊不清，无法判断是否完成
• 估计“几天”就能完成的任务，实际却耗时两周
• 美术任务必须先完成，却与代码任务被安排为并行工作
• 团队每个冲刺承诺的工作量都超出自身产能
• 事后看来显而易见、规划时却未被发现的风险
• 没有速度跟踪，因此每个冲刺的估算都只是猜测
• 以小幅追加为名逐渐扩大的范围，最终导致错过截止日期

关键规则

1. 每个冲刺只设一个目标。 冲刺目标应是一句定义成功标准的话。如果冲刺实现了这个目标，即便没有完成其他任何事项，也算成功。如果冲刺完成了任务清单上的所有事项，却没有实现目标，那就是失败。Hades 在抢先体验期间的冲刺目标聚焦于玩家体验：「即使玩家死亡，也能感受到叙事在推进。」这样的清晰度能避免「做了很多事，但没有一件感觉完成了」这种反模式。

2. 任务最长不超过 1 天。 任何预估超过 1 天的任务都必须进一步拆分。大任务会掩盖复杂性，让估算产生虚假的把握。如果一个任务看起来无法拆分，但预计耗时超过 1 天，那它要么描述得太含糊，要么开发者还不够了解这项工作（这本身就是一项探索任务）。Motion Twin 开发 Dead Cells 时，所有工作都采用按天划分的任务——即使是新生物群系这样的重大功能，也拆分成数十个有明确完成标准的单日任务。

3. 20% 缓冲时间不可妥协。 计算出原始产能后，减去 20%。这部分时间用于会议、代码审查、意外漏洞、构建问题、硬件故障，以及协作工作中的各种摩擦。跳过缓冲时间的团队总是会过度承诺，也总是无法兑现承诺。独立开发者也不例外；上下文切换、偏离主题的调研，以及「我只要重构这一处」都会占用时间。

4. 依赖关系必须优先考虑。 被其他任务阻塞的任务尚未准备好开始。明确梳理依赖关系，找出关键路径，并确保优先安排阻塞其他任务的工作。游戏开发中最常见的依赖链是： 设计规格 --> 美术／音频资源制作 --> 代码集成 --> QA 验证。

5. 范围分级让计划更灵活。 冲刺中的事项并非优先级都相同。使用 Must／Should／Could／Won’t 分级，让团队清楚现实情况出现时应优先砍掉什么。周三砍掉一项 Could-Have 属于健康的范围管理；周五砍掉一项 Must-Have 则是危机。

6. 如实看待速度，不要抱有不切实际的期待。 如果团队过去 3 个冲刺平均完成了 30 个故事点，那么这个冲刺计划完成 45 个故事点就不是有雄心，而是自欺欺人。根据实际历史速度规划，不要根据期望速度规划。Larian 为 BG3 采用基于里程碑的开发之所以奏效，是因为他们持续严密跟踪速度，并据此调整范围，而不是因为他们更拼命地加班。

7. 与设计支柱保持一致。 每个冲刺目标都应对应某个设计支柱。如果冲刺目标与任何支柱都无关，团队要么是在做基础设施工作（可以接受，但要明确说明），要么偏离了愿景（应提出来讨论）。Supergiant 的冲刺目标始终以玩家体验来表述，而不是列出功能清单——例如「玩家能感受到武器选择的分量」，而非「实现武器系统」。请参阅 docs/game-design-theory.md 了解设计支柱方法，并参阅 docs/collaboration-protocol.md 了解跨学科协作规则。

Sprint 背景（自动填充）

这些值会在技能内容传递给 Claude 之前，通过 shell 预处理自动注入。 它们提供实时项目数据，确保 Sprint 规划基于代码库的实际状态，而非记忆或假设。

• 最近的提交：!git log --oneline -20 2>/dev/null || echo "No git history"
• 未解决的问题：!gh issue list --limit 10 --state open 2>/dev/null || echo "No GitHub issues accessible"
• 上个 Sprint：!cat production/session-state/last-sprint.json 2>/dev/null || echo "No previous sprint data"
• 团队速度：!cat production/session-state/velocity.json 2>/dev/null || echo "No velocity data"
• 活跃分支：!git branch --list 2>/dev/null | head -10 || echo "No branches detected"
• 未提交的更改：!git status --short 2>/dev/null | wc -l || echo "0"
• 距离上次打标签的天数：!git log --tags --simplify-by-decoration --pretty="format:%ar" 2>/dev/null | head -1 || echo "No tags — no milestone history"
• 当前里程碑文件：!ls production/milestones/ 2>/dev/null | tail -3 || echo "No milestone directory"

使用这些自动填充的数据来辅助 Sprint 规划决策。最近的提交能显示最近完成了哪些工作，以及代码库中哪些区域较为活跃。未解决的问题可作为待办事项候选。上个 Sprint 的数据和速度 JSON 有助于根据数据规划产能（参见步骤 5 和步骤 7）。活跃分支显示正在进行、可能延续到本 Sprint 的工作。距上次打标签的天数表明距离上个正式里程碑已有多久，可帮助调整 Sprint 范围。

如果没有速度数据（首次 Sprint），请保守规划，并利用本 Sprint 建立基准。如果有上个 Sprint 的数据，请比较计划与完成情况，据此调整本 Sprint 的承诺。

工作流程

步骤 1：定义 Sprint 目标

Sprint 目标不是任务清单的摘要，而是 Sprint 的战略目的，应与游戏的设计支柱和当前里程碑相关联。

SPRINT GOAL FRAMEWORK
-------------------------------------------------
Format: "By the end of this sprint, [specific deliverable] is [specific state]
         so that [specific value to the project]."

GOOD EXAMPLES:
- "By the end of this sprint, the core combat loop is playable with 3 enemy
   types so that we can run our first combat-focused playtest."
- "By the end of this sprint, the save/load system handles all current game
   state so that playtesters can resume sessions."
- "By the end of this sprint, the tutorial sequence covers movement, combat,
   and inventory so that new players can learn without external instructions."

BAD EXAMPLES:
- "Work on combat stuff." (vague, not evaluable)
- "Fix bugs and add features." (two goals, not one)
- "Make the game better." (not falsifiable)

PILLAR ALIGNMENT:
Sprint goal: [goal statement]
Serves pillar: [which pillar this advances]
Milestone: [which milestone this contributes to]
-------------------------------------------------

步骤 2：分解任务

将 Sprint 目标拆分为可实施的任务。每项任务都应足够小，以便一个人能在一天或更短时间内完成。

TASK DECOMPOSITION PROCESS
-------------------------------------------------
Step 2.1: List features needed to achieve the sprint goal
Step 2.2: For each feature, list the technical tasks
Step 2.3: For each technical task, break into sub-tasks until each is <= 1 day
Step 2.4: Add non-feature tasks (bug fixes, tech debt, reviews, meetings)
Step 2.5: Identify tasks that require discovery/research (estimate separately)

TASK FORMAT:
- ID: [SPRINT-001]
- Title: [clear, action-oriented name]
- Description: [what "done" looks like for this task]
- Estimate: [hours, max 8 for a full day]
- Owner: [person responsible]
- Discipline: [code / art / audio / design / QA]
- Dependencies: [list of task IDs this is blocked by]
- Scope tier: [Must / Should / Could]

ESTIMATION GUIDELINES:
- 1-2 hours: small, well-understood change (fix a known bug, add a config value)
- 3-4 hours: moderate task with clear requirements (implement a simple system)
- 5-6 hours: significant task with some unknowns (new feature with defined spec)
- 7-8 hours: full-day task at the complexity ceiling (decompose further if possible)
- > 8 hours: must be broken down into smaller tasks

DISCOVERY TASKS:
When a task involves unknown technology or untested approaches, create a
discovery task first: "Spike: determine if [approach] is feasible (max 4h)."
The spike produces information, not features. Schedule it before the
implementation task it informs.
-------------------------------------------------

步骤 3：梳理依赖关系

游戏开发中的依赖关系比大多数软件项目更复杂，因为一项功能需要多个专业领域协同完成。

DEPENDENCY CHAIN ANALYSIS
-------------------------------------------------
TYPICAL GAME DEV DEPENDENCY CHAINS:

Design --> Art:
  Game designer defines enemy behavior --> Artist creates enemy sprite/model
  Level designer creates layout --> Environment artist builds the space

Art --> Code:
  Artist delivers character sprites --> Programmer integrates animations
  UI artist creates mockups --> Programmer implements interactive UI

Design --> Code:
  Designer specifies mechanic --> Programmer implements system
  Designer tunes values --> Programmer exposes tuning parameters

Code --> QA:
  Programmer completes feature --> QA verifies correct behavior
  Programmer fixes bug --> QA confirms fix and checks for regressions

Audio --> Code:
  Audio designer creates sounds --> Programmer integrates audio triggers

MAPPING FORMAT:
[SPRINT-001] Design enemy patrol pattern
  |
  v (blocks)
[SPRINT-005] Create enemy patrol animation
  |
  v (blocks)
[SPRINT-009] Implement enemy patrol AI
  |
  v (blocks)
[SPRINT-012] QA: verify enemy patrol behavior

CRITICAL PATH:
The longest dependency chain determines the minimum sprint duration for
that feature. If the critical path is longer than the sprint, the feature
cannot be completed this sprint. Either rescope or split across sprints.
-------------------------------------------------

步骤 4：划分范围层级

为每项任务分配一个范围层级。当现实情况偏离计划时，这是防止 Sprint 失败的减压阀。

SCOPE TIER DEFINITIONS
-------------------------------------------------
MUST-HAVE (sprint goal depends on this)
- If these tasks are not done, the sprint goal is not met
- These are scheduled first and protected from cuts
- Estimated effort for Must-Haves should not exceed 60% of capacity

SHOULD-HAVE (significantly enhances the sprint goal)
- The sprint goal is technically met without these, but weakened
- These are scheduled second and cut only under real pressure
- Estimated effort: up to 25% of remaining capacity after Must-Haves

COULD-HAVE (polish, nice-to-have, opportunistic improvements)
- Scheduled last, cut first, no guilt
- These are stretch goals for productive sprints
- Estimated effort: fills remaining capacity

WON'T-HAVE (explicitly deferred)
- Tasks that were considered and deliberately rejected for this sprint
- Writing these down prevents relitigating scope decisions mid-sprint
- "We already decided not to do that this sprint" is a powerful sentence
-------------------------------------------------

步骤 5：计算产能

确定团队实际能完成多少工作，而不是你希望他们能完成多少。

CAPACITY CALCULATION
-------------------------------------------------
For each team member:
  Available days in sprint:     [total days minus PTO, holidays, sick days]
  Minus overhead (20%):         [meetings, reviews, admin, build issues]
  Effective person-days:        [available * 0.8]
  Effective person-hours:       [person-days * productive hours per day]

  Note: productive hours per day is typically 5-6, not 8.
  The remaining 2-3 hours go to email, Slack, context switching,
  and the unavoidable friction of being a human with a job.

TEAM CAPACITY:
  Total effective hours: [sum of all team members]
  Must-Have tasks:       [total hours]  ([%] of capacity)
  Should-Have tasks:     [total hours]  ([%] of capacity)
  Could-Have tasks:      [total hours]  ([%] of capacity)
  Buffer (20%):          [hours reserved]
  Remaining:             [positive or negative]

  If remaining is negative: cut Could-Haves first, then Should-Haves
  If still negative after cuts: the sprint goal itself is too ambitious.
  Rescope the goal, do not just "try harder."

SOLO DEV ADJUSTMENTS:
  Solo developers face unique overhead:
  - No parallelism (all dependency chains are sequential)
  - Every discipline switch has context-switching cost
  - No rubber-ducking available (allocate more time for debugging)
  - Apply an additional 10% buffer (30% total instead of 20%)
-------------------------------------------------

步骤 6：识别风险

列出本 Sprint 的 3-5 个主要风险，并制定缓解措施。

RISK ASSESSMENT
-------------------------------------------------
COMMON GAME DEV SPRINT RISKS:

Technical risks:
- "We've never built [system X] before and don't know the real complexity"
  Mitigation: Schedule a spike task early in the sprint
- "The engine update might break existing functionality"
  Mitigation: Pin the engine version for the sprint duration
- "Performance on target hardware is unknown"
  Mitigation: Schedule a profiling session mid-sprint

Content risks:
- "The art assets won't be ready when code needs them"
  Mitigation: Establish placeholder assets, code against placeholders
- "Level design iteration may require multiple art passes"
  Mitigation: Use blocking geometry first, polish in a later sprint

Scope risks:
- "Stakeholder feedback mid-sprint could change requirements"
  Mitigation: Define a change freeze date within the sprint
- "A Must-Have task is harder than estimated"
  Mitigation: Identify which Should-Have to cut if Must-Have expands

Team risks:
- "Key person might be unavailable for part of the sprint"
  Mitigation: Ensure no single-person bottlenecks on critical path
- "New team member ramp-up time is unpredictable"
  Mitigation: Pair them with a senior member, reduce their capacity estimate

RISK FORMAT:
| Risk | Probability | Impact | Mitigation | Trigger (when to act) |
|------|------------|--------|------------|----------------------|
| [description] | H/M/L | H/M/L | [plan] | [observable signal] |
-------------------------------------------------

步骤 7：跟踪速度

将计划工作与以往 Sprint 的实际完成情况进行比较，以调整未来的估算。

VELOCITY TRACKING
-------------------------------------------------
PREVIOUS SPRINT DATA:
| Sprint | Planned (pts/hrs) | Completed | Completion Rate | Notes |
|--------|-------------------|-----------|-----------------|-------|
| N-3    | [amount]          | [amount]  | [%]             | [context] |
| N-2    | [amount]          | [amount]  | [%]             | [context] |
| N-1    | [amount]          | [amount]  | [%]             | [context] |
| Avg    |                   |           | [avg %]         |       |

CALIBRATION RULES:
- If average completion rate is below 80%: you are chronically overcommitting.
  Reduce this sprint's planned work by the gap percentage.
- If average completion rate is above 95%: you are undercommitting.
  You can safely add a Should-Have or Could-Have item.
- If completion rate swings wildly (50% one sprint, 95% the next):
  your estimation process is unreliable. Focus on improving estimates
  before increasing velocity.
- First sprint (no history): plan conservatively. It is always better
  to finish early and pull in stretch goals than to miss commitments.

ESTIMATION IMPROVEMENT:
After each sprint, compare estimated hours to actual hours for each task.
Track the ratio. Over time, you will learn your personal/team estimation
bias and can pre-correct for it.
-------------------------------------------------

📋 单人开发 / Kanban 模式

并非每个项目都需要 Scrum。对于单人开发者或两人团队，Sprint 仪式（规划会议、站会、与自己进行回顾）的开销往往超过其价值。Kanban 能以更低的流程摩擦提供同样的工作流程纪律。

适合使用 Kanban 而非 Scrum 的情况：

• 单人开发者或两人团队，Sprint 仪式无异于自言自语
• 任务规模难以预测的项目（创意工作、以研发为主的原型开发）
• 工作持续不断到来的维护阶段，而非按计划分批处理
• Sprint 规划的开销总是超过 Sprint 本身所需时间

Kanban 看板结构：

Backlog --> In Progress (WIP limit: 2-3) --> Testing --> Done

WIP（进行中工作）限制是关键约束。对于单人开发者，将 WIP 限制设为 2-3 可避免“启动 10 件事，却一件也没完成”的反模式。对于两人团队，WIP 限制设为 3-4 较为合适。如果你想提高 WIP 限制，那就是在逃避 Kanban 运作所需的纪律。 按职能划分泳道： 按职能设置横向泳道来组织看板：代码、美术、音频、设计、商务。这样可以直观地看到上下文切换。如果你的“In Progress”列中，代码、美术和商务各有一张卡片，就意味着你同时承受着三次上下文切换的成本。尽可能按职能批量处理工作。

每周评审节奏： 不要开冲刺回顾会，而是每周进行一次评审（即使是独立开发者，也可以只花 15 分钟自我反思）：

• 本周有哪些工作移至 Done？
• 哪些工作在 In Progress 中停滞了 3 天以上？为什么？
• 是否遵守了 WIP 限制，还是在钻空子？
• Backlog 是否仍反映实际优先级，还是已经偏离？

工具推荐：

• HacknPlan —— 专为游戏开发打造，了解职能类别
• Codecks —— 采用卡牌游戏的比喻，视觉效果吸引人，适合小团队
• GitHub Projects —— 免费，可与代码仓库集成，适合以代码为主的项目
• Notion —— 灵活，适合希望将看板和文档整合到一处的独立开发者

MoSCoW 强制执行比例

每个冲刺（或每周看板评审）都应检查计划中的工作分配是否符合以下比例：

优先级	目标比例	目的
Must	产能的 60%	决定冲刺是否成功的核心交付成果
Should	产能的 25%	强化冲刺目标的高价值改进
Could	产能的 15%	润色和延展目标，遇到压力时优先削减
Won't	产能的 0%	明确延期——不纳入本次冲刺，毫无例外

如果 Must-Have 任务超过产能的 60%，说明你对关键工作承诺过多，没有为意外情况留出余地。如果 Could-Have 任务超过 15%，说明在基础尚未稳固前，你把太多时间花在了润色上。在冲刺计划中明确跟踪这些比例，并在回顾会上进行检查。

范围检查集成

如果冲刺速度数据表明团队持续完成的工作少于计划（连续 3 次以上冲刺的完成率低于 75%），这就是范围蔓延的信号。在规划下一次冲刺前：

• 运行 /game-scope-check，评估整体项目范围是否已超出原始估算
• 将当前功能列表与最初的垂直切片定义进行比较
• 找出初始计划之后新增、但其他地方未相应缩减范围的功能
• 在下一次规划会议前，明确决定每项新增功能是保留还是删减

输出格式

此工作流会生成一份冲刺计划文档。完整模板请参阅 templates/sprint-plan.md。

# Sprint Plan

## Sprint Identity
- **Sprint Number:** [N]
- **Dates:** [start] to [end]
- **Duration:** [number of working days]
- **Sprint Goal:** [single sentence, pillar-aligned]
- **Milestone:** [which milestone this sprint serves]

## Team Capacity
| Team Member | Role | Available Days | Effective Hours |
|-------------|------|---------------|----------------|
| [name] | [discipline] | [days] | [hours] |
| **Total** | | | **[total hours]** |

## Task Board

### Must-Have
| ID | Task | Owner | Estimate | Dependencies | Status |
|----|------|-------|----------|-------------|--------|
| SPRINT-001 | [task] | [name] | [hours] | -- | Not Started |

### Should-Have
| ID | Task | Owner | Estimate | Dependencies | Status |
|----|------|-------|----------|-------------|--------|

### Could-Have
| ID | Task | Owner | Estimate | Dependencies | Status |
|----|------|-------|----------|-------------|--------|

### Won't-Have (Explicitly Deferred)
- [feature/task] -- deferred because [reason]

## Dependency Map
[Visual or textual representation of blocking chains]

## Capacity Summary
| Tier | Estimated Hours | % of Capacity |
|------|----------------|--------------|
| Must-Have | [hours] | [%] |
| Should-Have | [hours] | [%] |
| Could-Have | [hours] | [%] |
| Buffer (20%) | [hours] | 20% |
| **Total** | **[hours]** | **[%]** |

## Risk Register
| Risk | Prob | Impact | Mitigation | Trigger |
|------|------|--------|-----------|---------|
| [risk] | H/M/L | H/M/L | [plan] | [signal] |

## Definition of Done (Sprint Level)
- [ ] Sprint goal is achieved and demonstrable
- [ ] All Must-Have tasks are complete and verified
- [ ] No new Critical bugs introduced
- [ ] Updated tasks reflected in project tracking
- [ ] Sprint retrospective notes captured

## Definition of Done (Task Level)
- [ ] Code compiles and runs without errors
- [ ] Feature matches specification / acceptance criteria
- [ ] Tests pass (where testing infrastructure exists)
- [ ] Code reviewed by at least one other developer (teams of 2+)
- [ ] No hardcoded gameplay values (data-driven per coding standards)
- [ ] Known issues documented if task is completed with caveats

质量标准

成功的冲刺计划应满足以下所有条件：

• 冲刺目标只有一句话，并且可以明确判断是否完成
• 每项任务的预估工时不超过 8 小时
• 已梳理依赖关系，并将阻塞任务安排在依赖它的任务之前
• Must-Have 任务不超过有效产能的 60%
• 20% 的缓冲是在所有估算完成后再应用，而不是之前
• 至少识别出 3 项风险，并为每项制定具体的缓解计划
• 计划引用了前几次冲刺的速度数据（如有）
• 每项任务都已分配范围层级，而不仅仅是在类别上标注
• 完成定义针对本次冲刺制定，而非通用模板
• 独立开发者或任何团队成员查看计划后，都能明确知道自己 应该先做什么、再做什么、最后做什么

示例用例

1. “我们需要规划下一个为期 2 周的冲刺。” 完整的 7 步工作流。首先根据当前里程碑定义冲刺目标，然后分解任务、梳理依赖关系、计算产能、划分范围优先级、识别风险，并生成冲刺计划文档。

2. “我是独立开发者。帮我规划下周的工作。” 精简工作流：定义一个聚焦的目标，列出 5-8 项任务，预留独立开发者缓冲（30%），并识别 1-2 项风险。独立开发者的冲刺应该更短（1 周），以保持专注并便于频繁调整方向。

3. “我们总是无法完成冲刺承诺的工作。问题出在哪里？” 聚焦第 7 步（速度跟踪）。比较最近 3-5 个冲刺的计划与实际情况。规律会揭示问题究竟出在估算、范围蔓延、依赖阻塞，还是产能承诺过高。

4. “我们刚完成头脑风暴。如何把这个概念转化为工作？” 使用 game-brainstorm 的概念文档作为输入。垂直切片计划将成为第一个冲刺目标。概念中的功能优先级可直接对应冲刺范围优先级。

5. “我们的美术师本次冲刺只能参与 2 天。该如何据此规划？” 在资源受限的情况下计算产能。明确梳理美术依赖关系，将美术任务优先安排在美术师可参与的日期，确保依赖美术工作的代码任务安排在美术资源交付之后，并准备占位资源作为备用方案。