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