> ## Documentation Index
> Fetch the complete documentation index at: https://docs.wanyouxi.online/llms.txt
> Use this file to discover all available pages before exploring further.

# 独立游戏团队 Scrum 实施指南：从混乱到有序

> **摘要**：本文聚焦「独立游戏团队 Scrum 实施指南：从混乱到有序」，梳理核心概念、关键方法与落地实践。

**文档目标**：为 *Vampirefall* 团队定制一套轻量级、低内耗的敏捷开发流程。拒绝形式主义，专注于“持续交付价值”。

## 1. 为什么需要 Scrum？

独立开发容易陷入两个陷阱：

1. **无尽打磨 (Perfectionism)**：一个功能做三个月，还是觉得不够好，不敢发布。
2. **需求蔓延 (Scope Creep)**：今天想做联机，明天想做 VR，核心玩法迟迟不闭环。

**Scrum 的解法**：

* 把大目标切碎成 2 周的小目标 (Sprint)。
* 每 2 周必须产出一个**可玩的版本** (Playable Build)。

***

## 2. 核心仪式 (The Rituals)

我们只保留最核心的三个会议，不浪费开发时间。

### 2.1 冲刺规划会 (Sprint Planning)

* **时间**：每双周的周一上午 (1小时)。
* **内容**：
  * 回顾 Product Backlog（需求池），挑选本周要做的卡片。
  * **关键动作**：全员估时。如果策划觉得这个功能很简单，但程序说要 5 天，必须当场对齐认知。
* **产出**：Sprint Backlog（本周任务板）。

### 2.2 每日站会 (Daily Stand-up)

* **时间**：每天上午 10:00 (15分钟)。
* **形式**：**站着开**，禁止坐下（逼大家讲快点）。
* **回答三个问题**：
  1. 昨天我完成了什么？(Done)

  2. 今天我打算做什么？(To Do)

  3. 我遇到了什么阻碍？(Blockers) -> **这是最重要的**，比如“美术资源没给，我写不了代码”。

### 2.3 评审与回顾 (Review & Retrospective)

* **时间**：每双周的周五下午 (1.5小时)。
* **Review (展示)**：所有人围在电脑前，试玩这个 Sprint 做出来的功能。**Bug 太多就视为未完成**。
* **Retro (吐槽)**：
  * Keep: 即使是很烂的 Sprint，也有做对的地方。
  * Problem: 那个功能为什么延期了？沟通哪里出了问题？
  * Try: 下个 Sprint 我们尝试改进的一点（比如：美术提需求前先给草图）。

***

## 3. 物理/数字看板 (The Board)

推荐使用 Notion, Trello 或 Jira。列分为：

| Backlog (需求池) | To Do (本周要做) | In Progress (进行中) | Verify (待验收) | Done (已完成) |
| :------------ | :----------- | :---------------- | :----------- | :--------- |
| 联机模式 (P2)     | 制作 Goblin 模型 | 编写 AI 行为树 (张三)    |              | 角色移动逻辑     |
| 新英雄 (P1)      | 技能图标 UI      |                   | 伤害公式测试       |            |

* **规则**：
  * **WIP 限制 (Work In Progress)**：每个人在 `In Progress` 里的卡片不能超过 2 张。做完一个再拉下一个，避免并行空转。
  * **定义 Done**：代码写完不是 Done，**合并进主分支且没有报错**才是 Done。

***

## 4. 角色分工 (Roles)

独立团队人少，一人分饰多角：

* **Product Owner (PO / 制作人)**：
  * 决定“做什么”。
  * 掌握 Backlog 的优先级。当美术和程序吵架时，PO 拍板听谁的。
* **Scrum Master (流程教练 / 主程或主策)**：
  * 决定“怎么做”。
  * 主持站会，负责清除障碍（比如去催外包美术交稿）。
* **Team (开发成员)**：
  * 负责把卡片从左边移到右边。

***

## 5. 常见病症与药方

### 病症 A：Sprint 结束了，功能都没做完。

* **原因**：估时太乐观，或者中途插入了临时需求。
* **药方**：
  * 下个 Sprint 减少 30% 的任务量。
  * **严禁插队**：除非服务器爆炸，否则任何新点子都必须等到下个 Sprint Planning 再讨论。

### 病症 B：站会变成了流水账。

* **现象**：大家都在说“昨天写代码，今天写代码”。
* **药方**：改为以**任务**为核心。指着看板上的卡片说：“这张卡片我昨天完成了 50%，今天能做完。”

### 病症 C：Retro 变成了批斗大会。

* **药方**：**对事不对人**。不是“小王代码写得烂”，而是“我们的代码审查流程缺失，导致烂代码进库了”。

***

## 6. 结论

敏捷不是为了快，而是为了**方向正确**。
宁可快步小跑调整方向，也不要蒙眼狂奔直到撞墙。