敏捷方法和Scrum方法论
本帖最后由 测试积点老人 于 2018-12-21 17:08 编辑行业对下一代开发技术的恐惧随处可见，它出现在饮水机上、出现在杂志中，人们在游戏开发者大会和《游戏开发者》杂志上讨论这个话题。随着硬件性能的不断增强，游戏逐渐变得更加昂贵和拟真化，所有的东西都在增加：团队大小、资产需求、时间投入和需要投资者提供的支持资金。用户也期望能获得更好的产品。他们想要更多有着更好功能和技术深度的机制，更密集的多边形艺术，更高的分辨率纹理，更复杂的AI以及更多的测试和QA等。
这种对下一代的恐惧不仅限于行业从业者。这种压力来源于用户，也在用户中蔓延。游戏站点FiringSquad.com说道：“行业内众多游戏发行商和开发商都在抱怨开发成本的攀升，主要原因在于需要大幅扩张美术团队来制作出所有可行的内容。”行业面对的多数问题的本质是他们采用了不当的产品方法论。近百人的团队还在使用10人团队的开发方法。我们其实可以更改和替换开发方法。
传统游戏开发使用的产品方法论是，花大量前端时间来确定意向功能，通常会同时执行机制和关卡等重要元素，最后进行润色。这种通常称为“瀑布”的方法论类似于生产线，前端负责将产品的各个部分拼接起来，后端等待对拼接完成的产品进行润色。这种等待便会产生问题。设计师和发行商无法得知游戏的真正感觉，比如他们最初对机制的评估是否准确，或者功能的执行与原计划是否存在偏差。这样的因素会影响到产品质量。
有个替代方案可以处理传统游戏开发方法论带来的这些问题。这种产品R&D过程和团队管理方式称为“敏捷方法论”。敏捷强调直接将游戏的可论证迭代融入制作过程中，将最关键的元素和功能的迭代优化提前。这种方法还强调了团队的组成和关系，以及团队必须计划和实现项目目标的循环。游戏开发团队会面对许多挑战，美术、工程和设计等不同层面面对的挑战也各不相同，他们需要合作。通向游戏项目完结的道路也非常漫长，较小的游戏需要开发1到2年时间，较大的游戏需要3年或更多的时间。
页:
[1]
