游戏开发与制作小记（10章）
第十章 项目计划
项目计划是项目所有相关内容的最终计划书，包括游戏设计，技术设计以及其他设计文档的详细说明
项目计划包括：估计、资源、工具、跟踪、依赖、风险和预备计划。
制定一个项目计划，我们需要列出需要完成的任务，谁来完成这些任务，项目完成的时间，这些任务的关系。任务列表，预计完成任务所需的时间以及任务之间的依赖关系。这些时间是要反复确定的。
所有的项目信息都编辑成一些有价值的项目分析报告，利用Microsoft Project或SureTrak工具，可以产生无数的个报告和图表来查询项目组成员的工作分配情况、关键路径、度量项目开发的进程以及说明项目状态的其他方法。作者建议使用Microsoft Project进行计划，使用Microsoft Team Manager进行任务跟踪。
甘特图和网络图
网络图用于确定任务与人物之间的依赖关系，以及整个项目的关键路径
甘特图也可以体现出任务之间的依赖关系。左边的表格至少包括任务名，任务开始时间，任务持续时间以及资源名。理想的甘特图输入的是一些单独的、清楚的、持续时间较短的（最长只有2.5~3天）、不连续的任务。早期的甘特图中的时间和位置可以估计你需要多少人，需要多少时间，有助于你早期确定的成本。
注意！只有非常有经验、开发过类似项目的、并且十分清楚游戏开发范围的项目计划者才能起草项目主要任务进度表
利用设计文档
任务间隔和评测任务难度
评测任务难度就是在项目成员中公平分配任务。实际上，将一些大的任务细分成小的任务就间接地进行了任务难度评测（小任务更好评测难度），更容易将任务合理的分配下去。
任务的执行时间
任务执行时间不是项目经理应该完成的工作，应该让完成任务的开发者完成自己任务的时间估计，并且如果让他们自己完成时间估计会促使他们更快的完成。应该让他们知道为自己的任务分割和估计时间是他们自己分内的事。
时间估计错误的处理
当他们某项任务估计错误的时候，你有三种选择——删除这个功能、接受这个功能延时开发、要求按时开发完毕，如果开发者向你推荐某个功能，如果没有必要或开发时间不允许，向他们说明情况。如果时间允许或者开发人员能够基础一定时间完成这个功能。就应该接受开发者的功能（何乐而不为呢）。
估计未知性任务
对于一些没有先例的任务的时间估计，应尽量将任务划分至最细，将其中可以估计的小任务估计时间，不可估计的可使用排除法，从开发时间中刨除已知的开发时间剩下的就是未知时间的最大值。
但一定要注意，这个任务是一个十分重要的任务么？如果没有完成而超过最大时间，它值得延期完成吗？任务的内容是这个游戏的核心特征么？这个特征实现后你的游戏的竞争力能提升多少？在你的项目中，如果任务的优先级定了，那些高优先级的任务应该分配任务的最大时间（像上述的未知时间任务，就应分配最大时间）
任务优先级
对你的所有任务进行优先级的标注（预生产、Beta测试都将是A级任务）如果有些任务不好定级别（任务重要程度基本相同）这时就应该试着将优先级细分，并快速的进行划分（越慢越难划分）。在错误处理中，错误修改的优先级也可以依照这个方法进行划分。下图为BUG级别划分节选：
资源平衡
在进度中经常会出现有一两个任务超期的现象，这时你就要将这些即将超期的任务提升为A级任务，并有义务帮助他们完成超期任务。调整你的开发时间，如果有必要将降低一些任务的优先级级别，以适应变化的时间。当开发时间比较充裕的时候（仅有一两个人进行A级开发，其他人闲着）可以着手进行B级开发，如果时间使你犹豫是否进行下一级开发时，将下一级开发任务细分成时间允许的任务量，然后进行开发。总之，充分利用你的资源。
任务依赖
认真制定任务依赖，研究甘特图确定依赖关系，不要连接太多的任务依赖，不要用任务依赖来体现任务的优先级（相对于Microsoft Project软件，因为它有处理优先级的单独机制）如果发现某个人正在等的必要任务（由于有任务依赖）他可以完成，就要适当调整任务分配，将这个任务交由他完成，将他的任务转移一部分交由别人完成，以缩短任务等待时间。如果还是不能解决问题，你就要适当降低任务的优先级。
列出十大风险的文档
这里需要一些风险列举，十个就够，列出太多不能突出重点。列出风险，并写出解决的方案。这一部分力求简短，内容突出，这一部分在项目进行的同时进行维护，不断修改其内容，以增强风险意识。
你制定的是一个多长时间可以完成工作的计划，而不是确定一个没有选择所完成工作的完成项目的时间。
