🏃 独立游戏团队 Scrum 实施指南：从混乱到有序
文档目标：为 Vampirefall 团队定制一套轻量级、低内耗的敏捷开发流程。拒绝形式主义，专注于“持续交付价值”。
1. 为什么需要 Scrum？
独立开发容易陷入两个陷阱：
- 无尽打磨 (Perfectionism)：一个功能做三个月，还是觉得不够好，不敢发布。
- 需求蔓延 (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分钟)。
- 形式：站着开，禁止坐下（逼大家讲快点）。
- 回答三个问题：
- 昨天我完成了什么？(Done)
- 今天我打算做什么？(To Do)
- 我遇到了什么阻碍？(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. 结论
敏捷不是为了快，而是为了方向正确。
宁可快步小跑调整方向，也不要蒙眼狂奔直到撞墙。