refactoring - 哪些敏捷实践与游戏开发兼容？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

3年前关闭。




Improve this question




最近，我非常喜欢敏捷方法。我在 Martin Fowler 的网站上读到的一些论文至少在我看来完全没有缺陷，我想知道什么敏捷实践最适合游戏开发，特别适用于小预算、小规模和缺乏经验的团队项目 (大胆，因为它真的很重要)。

重构之类的概念看起来完全可以与一个小而缺乏经验的团队结合起来。 “拥抱变化”的理念也与缺乏经验的团队相结合，他们的想法一直在转折。但是像 TDD 这样的东西是有问题的。

例如，测试与 Direct3D 交互的类很困难，也不是最佳选择。这没有多大意义。

如果您能列出一系列对游戏开发有意义的实践，我将不胜感激。有助于组织艺术生产的那些是一个加分项。对真实案例的引用是另一个优点。

提前致谢。

编辑 -

另外，我的团队由 3 人组成:一名程序员、一名图形设计师和一名程序员/图形设计师组合。我们没有客户，所以我们必须独自做出所有决定。

我在 Fowler 的一篇文章中读到，敏捷某种程度上取决于开发人员与客户的交互，但他也提到，不愿意坚持敏捷的客户仍然可以通过敏捷开发得到很好的服务(这篇文章名为 New Methodology)。这如何适用于我的案例？

结论 --

我认为 StackOverflow 上的问题也可以帮助其他人，所以我将尝试在这里总结我对这个主题的想法。

通过使用模拟对象，甚至难以测试的元素(例如图形界面及其与客户端类的关系)也可能是可管理的。

例如，与其让界面的每个客户端在许多条件下真正测试其使用情况(例如，全屏/窗口模式切换，这会影响游戏中的几乎所有内容)，他们可以针对在他们看来似乎表现出与原始类相同，并另外测试该模拟对原始对象的保真度。

这样，缓慢的部分(实际上是打开窗口和其他东西)只在检查模拟对实现的保真度时完成一次，其他一切都在模拟上顺利运行。 [感谢Cameron ]

BDD mindset有助于缓解偏执 寻求对单元进行彻底测试，通过实际行为规范“代替”测试，而不是压缩单元，在许多情况下，最好让未经测试的单元(或仅间接测试，如果您愿意这样说)以避免过多的一对一测试与单元(类、方法、变量等)奇偶校验，这增加了测试(现在是“规范”)的脆弱性。 [感谢Kludge ]

Answer 1

我建议尝试使用 VersionOne (www.versionone.com)。 VersionOne 对从事单个项目的小团队免费，并且具有易于使用的工具，用于敏捷状态跟踪和项目规划。他们的网站还提供了对各种敏捷开发方法的解释的链接。

敏捷开发有不同的风格；我建议看看极限编程(XP)模型，作为一个很好的例子:
http://www.extremeprogramming.org/map/project.html

与实际编程实践一样，敏捷开发与项目规划和需求跟踪同样重要。

这个想法是确保你记录需要开发的游戏功能(作为“用户故事”)，给出(非常粗略的)每个需要多长时间的估计，并找出哪些是重要的。为每个版本留出少量时间，并安排您可以在那个时间发布的最重要、最便宜的功能。该系统可确保稳步前进，保护您免受持续的、不可预测的优先级变化的影响，并确保您不会开发一个无法正常工作的庞大单体代码库。

关于测试驱动开发，我认为 Cameron 和 Andrew Grimm 的评论都很有道理。如果您抽象出图形 API 调用之类的东西，您可以进行更多的单元测试。