敏捷开发在游戏项目中的应用与价值
敏捷开发的起源与理念
在 20 世纪 80 年代，对瀑布式开发方法的反对声日益高涨。大型国防和 IT 项目失败的频率越来越高，这促使众多书籍和文章开始探讨更好的开发实践。一些方法，如渐进交付，提倡通过迭代进行产品的增量开发。每次迭代都涵盖开发的各个阶段，而不是像瀑布式开发那样将各个阶段分散在整个周期中。迭代周期可以短至一周，在这个时间内完成分析、设计、编码、集成和测试，而不像瀑布式项目那样将这些阶段分散在数年中。
直到 2001 年，一群专家聚集在一起，决定将这些新兴的迭代和增量开发方法称为敏捷方法，并制定了“敏捷宣言”，总结了这些轻量级方法的价值观和原则。敏捷宣言内容如下：
我们通过实践并帮助他人实践，正在探寻更好的软件开发方法，由此我们形成以下价值观：
- 个体和互动 高于 流程和工具
- 可工作的软件 高于 详尽的文档
- 客户合作 高于 合同谈判
- 响应变化 高于 遵循计划
也就是说，尽管右项有其价值，但我们更重视左项。
这些简单的价值观使得 Scrum、Lean 和 XP 等敏捷框架拥有了共同的哲学和原则。接下来，我们将通过一个假设的游戏项目复盘，探讨游戏开发项目面临的典型问题，以及敏捷开发如何应对这些挑战。
从游戏项目复盘看开发难题
游戏开发者杂志自 1994 年创刊以来，其游戏项目复盘文章一直备受关注。这些文章不仅展示了不同工作室的工作方式，还让我们知道在开发中遇到的挑战并非个例。下面以一款名为《Quintessential》的科幻射击游戏为例，看看这个项目的复盘情况。
