前言

作为一个独立的开发人员或小型开发团队，由于直接沟通成本低，过多的项目管理过程使研发过程复杂。此外，由于资源有限，小型开发团队很少配备专业的项目经理来操纵施工进度，因此，在小团队开发中，规范的项目管理方法往往被忽视。因此，如果没有外部压力（如发行商的催促），由于缺乏有效的预期、进度控制或其他原因，单独的开发团队更容易推迟项目。因此，如果没有外部压力（如发行商的催促），由于缺乏有效的预期、进度控制或其他原因，单独的开发团队更容易推迟项目。

因此，本文整理了一些个人认为单独团队相对有用的项目管理方法，希望能给大家带来启发。其实称之为“手册”并不是很合适。本文提到的方法主要来自NYU Game Center的项目管理课程Production Practicum中学，结合个人实际经验进行简单总结，不能作为严谨全面的“手册”。我希望它能吸引玉石。欢迎您谈谈您认为易于使用的项目管理方法。

项目管理的核心可以概括为确立谁需要在任何时候做最重要的事情，以及为什么要做，并最大限度地减少未知的模糊性。项目实施分为三个阶段-Production(开发前)，Production(开发中)，Post-Production(开发后)。 在各个阶段还有哪些重要的项目管理方法？

Pre-Production & Production

Waterful VS Scrum瀑布开发及敏捷开发

项目立项时，首先要确定的是团队要采用的开发方法，即瀑布式开发或敏捷开发。 在进入下一阶段之前，传统瀑布式发展注重完善每一个阶段。 传统瀑布式发展注重在进入下一阶段之前，每个阶段都是完美的。从需求分析到设计，从设计到开发(程序、艺术等)。)，再从测试。瀑布模型注重文档，前期没有迭代和反馈，对不具体易更改的项目不敏感。

然而，在游戏开发中，我认为好游戏不是想出来的，而是改变了。以玩家为核心的一切都是好游戏的根源，而非商业游戏需求的变化是很常见的。因此，关注小版本和频繁迭代和测试敏捷开发（如Scrum模型）可能更适合游戏，不仅是小团队，而且基本上被行业广泛推广和选择。敏捷开发灵便高，注重面对面的即时沟通(如迪拉y) Check-in日常站会等)，快速迭代(以Sprint为指导的短周期开发)，定期包装可立即检测运行版本等。后面讨论的方法基本上是敏捷开发中常用的一些方法。

Pitch Doc / Project Summary 项目文档直观总结

项目预期是独立开发团队中经常被忽视的一个重要环节，有效的项目预期可以帮助我们更好地控制整体情况，正确评估任务优先级，建立进展，最大限度地减少未知的模糊性。但在项目立项时，估计的第一项是Pitch Document，可以算是创意文档，以最少的篇数简短描述游戏的主要内容。在写创意的过程中，设计师不仅可以帮助他们建立创意原型，而且是项目实施角度的关键指导。Pitch 在向他人介绍游戏时，Doc必须随着项目的变化而保持升级。本文档约为2-5页，主要解决以下问题：

• 你想做什么？

• Overview: 一句话简述游戏
• Platform & Genre: 目标平台和游戏分类
• Gameplay: 核心玩法简介(可以用图例解释，参照下面1-Page Design Doc）
• Feature: 为什么要玩这个游戏？／为什么是一个值得做的项目？／为什么是一个值得做的项目？／独特的特点是什么？..(如果是商业项目，可能需要简单的竞争产品分析)
• 同行业: 为了更方便、更快速地理解游戏，我们可以简单地谈论类似的类似作品

• 它看起来怎么样？

• 艺术方向：展示设计理念或参考图等

• 你打算怎么做？

• Team: 简要描述团队人员的分工和优势(为什么这个项目能做好)
• Scope, Budget, Timeline: 简要描述项目规模，预算及时间管理

除Pitch外 除了Doc之外，一些必要的项目文档也会在以后的开发中加入。然而，在敏捷开发中，由于沟通成本高，没有人需要阅读几十页的说明书，复杂的传统设计文档很少被用作沟通媒体应用。以下两种方法是当前行业需要使用必要的设计概念文件时常用的方法：

• Design Wiki (比如可以参考Stardeww Valley Wiki）

简单地说，将传统文档转化为在线文档，易于搜索和更新，方便联合编辑。它通常被用作查看存档应用程序，而不是开发指导文件。它通常被用作查看存档应用程序，而不是开发指导文件。

• 1-Page Design Doc (详见GDC讲座地址)

1-Page Design Doc是提高文档利用率和沟通效率的新形式。最初的灵感来源之一是建筑工程图纸，注意最少的篇数(只有一页！）以及直观的地图例解释设计。一页的数量大大缓解了开发者阅读复杂文本的痛苦，促进了立即交流和更新。图例比文本更容易显示系统之间的关系和变化规律。1-Page Design 常见的Doc类型可能是UX设计中常用的Flow Chart页面流程表，但实际上可以用于其他设计，如关卡设计、核心玩法分析等。

(不经意间在网上发现了一个设计师的个人网页，很多都是用了1-Page Design Doc的例子，看http://bobbyross.com/tutorials/）

Project Plan 项目计划

项目计划表是项目管理的核心文件，由于人力不足，小团队没有精力维护大量文件，所以从我自己的项目中，我将时刻表、里程碑、Backlog和Sprint的任务安排结合到这个表中。这样，我日常维护的文档基本上只有Project 文章将在Plan后提到Build Note。这样，我日常维护的文档基本上只有Project 文章将在Plan后提到Build Note。下图是我目前项目中使用的计划，可以看到顶部横轴是时间范围划分及其里程碑相关知识。时间段与工作密度有关。如果工作密度大，我的表格应该是半周一格。左竖轴的第一列是类别类型(设计)／美术／程序／音乐等。)，第二列将每个类别分为不同的Sprint主题及其Backlog，第三列和第四列是写User 可以说，Stories模式的具体内容是Features。 List对应于每个任务旁的Story Points估计的任务量。对应任务安排的时间点可以在中间用图形定义，不同的颜色由不同的人负责。如果按时进行，就会变成深色，如果没有相应的计划时间，计划就会变成灰色。

• MileStone 里程碑

里程碑不应该描述太多，主要是根据自己项目的情况来定义一些重要的时间节点，然后根据任务量和优先级来分配这段时间的工作。里程碑应包括定义为“进行”的时间段和具体内容或标准。

• Product Backlog/Feature List > Sprint Backlog 待达到目标

大家早就在文初简要提到了敏捷开发的工作模式，敏捷开发将一个长期的大项目划分为多个短周期，每个周期经历1-4周左右，称为Sprint(备战)。在项目立项初期，基于定制的Pitch Doc，团队成员应将目标转化为一系列待开发的Feature。 List(待实现的功能／特征)，然后形成最初的Backlog(待解决的问题)。

在项目实施初期，比如快速Prototype阶段，提出的Backlog可能会因为项目需求不明确而非常大和模糊。但没关系，这个时候不要以为这项工作没用，Backlog和Feature 在工程持续清晰的过程中，List会不断迭代更新，你预计会越来越准确。但没关系，这个时候不要以为这项工作没用，Backlog和Feature 在工程持续清晰的过程中，List会不断迭代更新，你预计会越来越准确。如下图所示，Product Backlog通常包含标题名、情况和叙述(写User Stories的方式)，以及Size任务量的预期等。

在定义了最初的Backlog之后，每个人都可以进入以Sprint为核心的设计阶段。首先，根据预期对项目全局的控制和优先级的区分，建立当前Sprint的主题和定义为“进行”的标准和内容，然后从总Backlog中取出符合这一Sprint的部分，将其溶解为易于识别的具体内容，并补充未考虑的任务，根据优先级排序产生我们的Sprint“To Do List(待办)”。每日站会(详见下文)后升级任务版，将今天要解决的问题从“To Do(需要做)"搬到"In Progress(进行中)”，将已解决的问题转移到待检测中／确定一栏。

作为日常进度控制的重要管理方案，任务管理看板可以使用实体或Trelo等软件。但由于这种看板不利于存档记录，所以上面提到的Project 从Projectttt中，Pran可以承担总操纵存档的角色 在Plan中取出相应的Backlog，Sprint完成后，存档更新到Project Plan就可以了。因为团队不大，情况特殊，我是唯一一个应用项目看板的人。所以为了方便，我没有重复使用额外的看板，而是直接使用了Project。 跟踪Plan的进展。

每次Sprint完成后，都要进行一个可交付试用版，并及时进行测试，根据反馈对此工作进行评估，并调整下一个方案。不要因为担心游戏不是最终的，尽快触摸游戏的关键服务主体“玩家”，以便尽快发现问题，及时调整开发方向。敏捷开发非常注重乐趣，规定优先维护玩家体验。对可交付版本的高要求和高频率自然会帮助我们确定什么是可以改善乐趣和用户体验的任务，并优先考虑它们，这是我认为在游戏开发中应该首先考虑的部分。

• User stories

Backlog的需求描述通常需要写User Stories的方式，以最清晰的描述方式，使这一需求的目的清晰易评。标准书写格式如下：

As a…, I want to…, so that…

为了方便，我想要。

需要注意的是，这个“角色”是指这个“行为”服务的对象。一般来说，它是游戏中的玩家，但还有其他服务目标，如额外的编辑器开发，以方便开发。

这样写似乎很麻烦，但是实际上真正使用的好处也比较明显。首先，它可以更准确地传达真正的开发需求。同时，“目的”可以让开发者确定为什么要做这项工作，这相当于评估主体和行为的制定，为以后的测试提供了可测量的要求。

• Size: Story Points 预计相关任务量

Story通常用于敏捷开发，以预测工作量 Points。Story Points是任务间的工作量，与具体的工作效率(如团队规模等)无关。)，这与我们在其他地方看到的时间预期不同，比如X人天或者Y小时，与细节密切相关。这种预测方法更灵活，不会因为细节的变化而导致所有预期都需要重新开展。 每个人的工作效率／也可以使用水平 Story Points进行评估。例如，根据预期和实际调整，人员A的每周工作效率基本上可以定义为30点，B是35点，然后评估团队效率，并在Sprint中分配多少任务。在日常工作中，如果实际工作量超过或低于预期，我们可以根据偏移统计确定项目是否可能推迟或按时完成。

Story的定义 Points时，我们可以将一个感觉最小的任务定义为1，然后根据其他任务与此任务相比的量级来评估其他Story Points。方案扑克是团队参与的预测方式之一，其特点是可以最大限度地获得更准确的预测，缺点是更耗时。

• Planning Poker方案扑克

简单来说，每个人手里都有一堆标有数字的扑克，代表Story Points等级。筛选出一个需要讨论的Backlog，每个人私下选择一个感觉相应任务量的等级卡，同时展示。如果差别不大，很明显，如果差距很大，差距很大，世界会互相讨论原因，然后继续游戏，直到所有成员基本达成协议。这款游戏有助于合理明确一些不可预测的任务，加强团队成员之间的沟通，解决对项目隐性理解不一致的问题。

此外，燃尽图和速度表是跟踪开发效率的两种形式，座标参数分别为Story Points的等级和时间，只有一个是关心速度，另一个是关心剩下的任务量。

• Burn Down Chart
• Velocity Chart

Daily/Weekly Check-每日站会in

日常站会是敏捷发展的重要习惯之一，一般在每天/每周开始，站起来实施是为了保证报告尽可能简单快捷。一般来说，规定简短直接地向其他团队成员解释三个问题：

• Did(上次站会后):“我上周/昨天做了什么？”
• Doing(本站会后):“我今天/本周要做什么？”
• Blockers:“我有没有遇到任何障碍/问题？”

在帮助制定计划的同时，这些都有助于制定计划，也让其他团队成员清楚你的进步。如果有工作交叉，可以及时沟通。同时，无形的压力会让你保持高效，防止无缘无故的延迟。

Version 控制Control版本

版本控制在开发中极其重要，也是业内必不可少的项目管理流程，但作为新手独立开发者，在早期阶段可能不会意识到这一点。简单来说，版本控制就是随时将新的无问题工程文件备份到云服务器上，所有变更都要先到当地进行，确认无危害工程正常运行的问题后再更新到服务器。简单来说，版本控制就是随时将新的无问题工程文件备份到云服务器上，所有变更都要先到当地进行，确认无危害工程正常运行的问题后再更新到服务器。

由于版本控制可以同时发展，大大提高了多人合作效率，实现了远程合作，如果出现问题，可以随时退回到以前的版本。及时独立开发，培养控制应用版本的习惯，使开发更加有条理和可控。有很多软件可以用于版本控制，比如SmartSVN，TortoiseSVN，Github等，服务器有一些免费的例子 Assembla 申请主机空间或使用 GitLab 配合 Source Tree 应用是不错的选择。

Pipeline 工作内容

总结整理工作流程图(包括谁负责什么部分)及其技术控制图(包括各部件使用的软件等)。)可以帮助新成员尽快融入项目，提示团队成员的工作内容。

然而，在小团队开发中，我认为最重要的应该是资源流程图（包括资源命名规范和存储位置）。梳理得越快，正确使用可以帮助项目保持有序和整洁，防止越来越大的项目因为没有尽快进行标准分类，甚至资源混乱而无法启动。

Build Note 升级手记 Bug Report 问题报告 Playtest 检测

在敏捷开发中，要保持Build的习惯。(通常导出可操作版本)和Build Note所谓的升级手记是对当前版本每次导出时更新的内容的总结。有一些类似于我们通常在应用程序中 在store中看到更新附则。Build Note的想要图是发送给QA便捷测试。然而，尽管我们在小团队中没有专业的QA，但我们仍然稳定地编写Build Note的习惯仍然很有用，因为他帮助我们立即梳理上一个版本的内容，并为测试提供参考。Build同时在内部使用 在Note中给出一些必要的变化项目额外的变化意图是非常重要的，因为在长期的开发中，有时会忘记为什么要改变当时的作用，Build Note可以帮助我们写下自己的设计思路。

在我的build 在Note中，我还将bug报告和检测报告放在一起，存档到每个版本，然后升级到Projectte Plan里。合理使用标签校准每个内容，使搜索更加方便。每次有好玩的版本，我都会检测到，所以每个build 在Note之后，我们都跟踪了Playtest的测试报告，并根据测试总结了一些需要更新或要求等级高的任务。同样，Tag校准也可以根据检测反映的任务要求优先考虑。

Post-Production

Retrospective 立即回顾总结

每次Sprint完成并完成项目后，别忘了花点时间整理前段时间的工作或项目，包括哪些做得好，哪些做得不好，如何改进，并立即整理项目，包括源代码、最终资源、原文件、文档等。良好的回顾习惯可以帮助团队发展磨合，有序的工程和资源、文档也可以使未来的升级或二次开发更加容易。良好的回顾习惯可以帮助团队发展，有序的项目和资源、文档也使未来的升级或二次开发更容易。简而言之，你现在会感激你的未来。