1、“.....并提供目录检索与阅览服务，在校园网上提供服务学校可以采用影印缩印数字化或其它复制手段保存论文因种特殊原因需要延迟发布学位论文电子版，授权学校年两年三年以后，在校园网上全文发布。保密论文在解密后遵守此规定论文作者签名导师签名日期年月日对于变更的处理方式有如下的描述是在个中，如果需求被确定，变更是无法进行的。这种方式的前提是我们在个前就确定这个计划内的工作，直到这个结束再做评审，但在游戏开发中的实际状况是，我们很可能在中因为策划案本身的冲突，美术外包的无法按时反馈，制作人突如其来的新的需求等等，这些情况是不可避免甚至的经常出现的，此时为了不允许变更的方法是非常不适宜的。极限编程虽然侧重于程序开发过程，但对于迭代周期内变更的处理是更为灵活的，极限编程要求在个迭代中，如果个还没有实现，则可以考虑用另外的需求将其替换，替换的原则是时间上的等量。有时变更对整体架构会产生影响，也可能改变与其他模块的依赖关系，或者产生逻辑上的冲突......”。

2、“.....我们可以整体上分为两种变更不影响迭代的变更。迭代周期中的变更。在游戏开发过程中，如果个变更需求还在设计阶段，还没有进入到迭代中，或是当前迭代周期内待处理的工作，对于这类变更经过评估后，可以直接进行，或寻找等量的不破坏依赖关系的工作来代替当前工作，例如如果原计划是在这批外包反馈回来后进行地编，但外包并没有及时返回，很可能的处理方式是，先从计划表中找出下个场景安排，进行下个场景的模型筛选，这类工作对其他模块均不产生影响，在时间上和地编也是等量的，这种变更是不影响迭代的。如果个变更所针对的对象已经进入迭代周期，这类变更会影响的原本计划安排，我们把这个归为第二类。这类变更的处理在流程上要更为复杂些，首先要在计划会议上讨论变更的必要性，对变更进行评价后，如果变更被允许，再把变更加入到下个迭代，同时对其影响的模块进行评估和修改，程序人员往往是反对这类变更的。但这些变更并不影响在迭代周期内的工作......”。

3、“.....上述所有的变更都需要在计划会议上提出，并在会议上进行评估。但如果受制作人或者其他外在因素需要在迭代过程中进行变更，这点是开发者最为反感的，在这种情况下，项目组需要取消当前的开发条目，完善新的需求，并把需求条目放到下轮迭代计划中。如果当个需求被完成后，需要对已经完成的内容进行变更，那么同样需要提出个新需求，将这个需求放入待办事项条目中，并要求项目经理安排到接下来的开发周期中，作为个新的条目来处理。这种处理方式是针对计划会议以外提出的变更，即在迭代周期中提出的。这种变更产生的影响是无法避免的，但项目需要上述的流程来减少可能出现的更大的混乱。开发过程中的变更是无法拒绝掉的，我们希望通过规划化的流程来进行变更处理，评估变更的性质，有效的实行变更。移动游戏开发进度控制游戏行业的项目管理中进度控制是非常困难的。不确定性从立项阶段就已经开始，如同上述的各类变更，新的需求和需求中断都会对游戏的进度进行定程度的冲击......”。

4、“.....为了配合的实施以及对上述变更处理的方式，确保项目的顺利进展，我们在的框架下进行进度的控制。需要说明的是，传统的项目跟踪方式在框架下也是合理有效的，问题的关键在于，如何建立有效的跟踪规划来配合迭代周期，配合现在项目管理工具来进行进度控制。对于项目的跟踪通常有两种表示方法，纯粹的时间表示法，把计划表按照时间来进行划分安排工作，衡量的标准是对照计划的时间和实际完成的时间。第二种是工作第三章实践与数据量衡量法，对任务进行工作量的估算，根据实际的工作量完成情况，来确定进度是否完成，例如两个场景的工作量大致相同，因为外包原因，优先进行了下个迭代计划的场景制作，而使本次计划的制作拖延了，但如果实际完成的工作量是相同的，那么此时认为进度没有被拖延。两种方法往往是同使用的，时间进度和实际的工作量进度需要同时跟进，再来总结进度的完成情况，预期完成效果并及时调整。我们需要在框架下制作进度控制表，意味着制定的计划是以迭代计划为基准的，时间表依据迭代的时间节点进行工作的安排，建立活动清单......”。

5、“.....从待办事项条目中，选择合适的条目放入计划表中，为每个活动制定时间节点，活动之间是衔接顺畅的，并列关系的要能够交换工作计划时间的工作需要标明关系，按时更新跟踪表，责任到人。明确的表示出任务的分配情况，识别任务的依赖关系，找出关键路径，获得任务可调整的范围。表进度跟踪表示例时间节点子任务实际完成情况描述跟进人依赖关系条目内容内容二对于表中的内容，我们对任务进行时间上划分，建立总体的时间规划，同时将任务量也用时间标注，给出总任务的划分和子任务之间的依赖关系，在变更处理过程中，我们可以根据变更的需要，给出等量任务，这里的等量是指完成任务的时间大致相等，且不影响依赖关系。项目经理和该任务的责任人共同制作并维护进度跟进表，配合项目管理工具进行更为便捷的管理，表格的制作方式是多种多样的，目的是清晰的反映进度，明确任务的负责人和有效的跟进。移动游戏开发过程改进在定范围内能够指导游戏的研发过程，但却也可能导致些问题，游戏在立项阶段有非常明显的无标准业务对象......”。

6、“.....制作人和整个策划组甚至整个团队都对游戏有着不同见解，且这些会随着游戏不断成型后进步发生改变，有时可能会是质的变化，例如修改游戏的操作方式等等，这就很可能出现完全的返工状况，那么前期的文档甚至代码的编写就会成为无用的工作量。根据游戏项目开发过程的特殊性，我们对整个敏捷过程进行了改善，传统的游戏开发将项目分成不同阶段，但这些分组主要是针对测试的，事实上对于开发过程管理北京大学硕士学位论文也同样适用，对于不同阶段制定不同的迭代计划，这些阶段可以有不同的开发方式和迭代周期。立项初期阶段快速原型开发阶段版本敏捷开发外部测试版本发布上线版本游戏类型规划组建团队技术标准可运行的符合质量标准的版本，完整的系统玩法与功能的全面测试与反馈图框架下的游戏项目阶段划分第个阶段是阶段，在这阶段中项目组的工作包括需求分析和竞品调研，主要目标是确定游戏的主要组成元素，进行风险预估，确定项目的可行性，这阶段我们主要采取快速原型的方式进行开发，首先由策划组进行简单的原型设计，尤其是界面和简单的交互设计......”。

7、“.....主要是为了罗列功能，我们通过程序实现简单的基本的战斗界面和操作方式，在敏捷小组内进行测试和讨论，调整操作方式，再进行简单原型的制作，直到获得满意的效果，这种方式虽然也需要返工，但相比于出现在游戏正式开发过程中的推翻重做的浪费，工作量是微乎其微的。这阶段的输出主要包括游戏的类型和目标用户游戏的操作模式制作出版本确定游戏的开发计划和整体规划进行团队组建进行人员的调配估算项目成本。在这阶段，项目组采用快速原型的方法进行开发，可尽快的交付可运行的版本，给出可运行，可交互的系统原型，根据反馈再进行修改。对于操作方式和游戏类型确定之后，在这阶段我们还要完成技术上的各类标准确定游戏引擎确定游戏的架构进步精确项目进度与成本预算。技术标准是游戏团队开发的规范和指导，只有明确标准后，后期工作才能更好的展开。在这阶段的不断验证下，我们可以把游戏项目中的关键因素基本确定，同时让开发团队能对游戏有直观的感受，让团队更加了解游戏，也有助于后期的开发。游戏的框架也可以确定......”。

8、“.....有依据，这是非常必要的，可以减少盲目设计和盲目开发，团队能更清楚了解游戏的发展，对游戏提出自己的见解。第三章实践与数据第二个阶段是版本阶段，这阶段开始敏捷开发，在这阶段，项目组通过详细设计来开始正式开发，并最终交付个完整的游戏。在的框架下正式开始游戏的迭代开发，迭代周期的选择是项目开发节奏的关键，进行迭代开发并不提倡迭代的周期越短越好，迭代的周期应当是权衡各个环节的时长，权衡项目组实际的工作效率来决定的，个迭代周期包括的工作环节是确定的，这些环节所占有的时间是不能忽略的，在个迭代周期中，从需求的分析，计划会议，评审会议等等，系列的过程都要占有定的时间，同样我们希望每个版本的增量是有明显进展的，这些有有利于团队的信心建设，我们希望在每个评审会议上都看到定的成果，这就需要相当的工作量，同时，较为整块的连续的工作时间，也会相对的提高开发的效率。但较短周期，对于需求变化的响应速度就越快，快速的响应变化是我们应用敏捷的根本原因，所以周期的选择......”。

9、“.....项目组需要综合各类因素进行最终周期的确认。在开发阶段，迭代周期般是较长的，个月的迭代周期是比较合理的。迭代周期游戏系统大小美术资源到位时长外包反馈时长程序开发人数和效率。版本阶段游戏开始封测，我们继续使用敏捷开发方法，但周期应调整为更短，这时期的和玩家反馈的增多，需要项目组快速跟进，在游戏正式运营后，般都会将周期控制在周左右，与游戏的更新周期保持同步。在周期缩短的同时，项目管理的机制也需要随之进行相应的修改。版本阶段游戏可进行外部测试，是正式上线前的最后测试，其主要目标是确保评估游戏的市场价值，确保和完善游戏的品质，做上线前的最后准备。主要任务包括进行玩法和功能的全面测试及时通过玩家反馈来进步修改对游戏开发过程进行总结等等，完成这些任务要贯穿整个版本的敏捷过程中。版本阶段是游戏的发布与上线阶段，在此阶段中按照上线游戏的标准，进步对游戏进行稳定的版本更新与资源的迭代。此时的迭代周期应保持和更新频率致，目前市场上的游戏多为周次更新......”。