游戏开发中的敏捷实践：用户故事与规划指南
1. 明确“完成”的定义
在游戏开发中，团队承诺从产品待办事项列表中完成一定数量的用户故事，并在冲刺评审中展示这些故事已完成。然而，明确“完成”的具体含义并非易事。如果团队认为某个功能只需临时资产，而利益相关者期望看到可发布质量的资产，那么利益相关者可能会对结果不满意。因此，在将每个故事分解为任务之前，必须就“完成”的含义达成一致。
1.1 标准定义
标准的“完成”定义适用于每个故事。以下是一些团队可能采用的标准定义列表：
- 游戏能在开发机器上运行。
- 游戏能在一个或所有目标平台上运行。
- 游戏能以可发布或目标帧率运行。
- 所有资产都符合命名和预算规范。
- 游戏在内存预算内运行，且没有内存泄漏。
1.2 额外定义
除了标准定义，还会为特定故事创建额外的“完成”定义，并在服务条款（CoS）中明确。例如：
- 作为设计师，我希望我的角色能跳过一个缺口，以确定该机制是否有趣。
- CoS：将使用姿势代替任何动画。
1.3 “完成”的词汇表
一些工作室会创建一个“完成的词汇表”来标记“完成”的定义，这对于在功能开发的不同阶段完成的故事很有用，如使用临时资产进行原型制作或使用打磨后的资产进行生产。这些标签在规划期间分配给每个故事，以确定利益相关者对该故事的期望。以下是一些示例：
| 阶段 | 描述 |
| ---- | ---- |
| 原型完成 | 展示潜在价值。资产用于演示目的，游戏仅在开发PC上运行。 |
| 预生产完成 | 展示功能
