作为独立开发者或者小型开发团队，由于直接沟通成本较低，过多的项目管理流程反而使得开发过程变得繁琐，除此之外也因资源有限，小型开发团队很少设有专职的项目经理控制项目进度，以至于规范的项目管理方法常常在小团队开发中被忽视。

也正因如此，如若没有外部压力（例如发行商的督促）独立开发团队也较容易因缺乏有效预估和进度控制等原因导致项目拖延。

因而本文整理了一些个人认为对于独立团队来说相对实用的项目管理方法，希望对各位有所启发。

称之为“指南”其实并不很贴切，本文中所提及的方法主要来源于在NYU Game Center的一门项目管理课程Production Practicum中所学，结合个人的实际经验进行的简易总结。

项目管理的核心可以概括为随时明确谁应该在什么时候做当下最该做的事情以及为什么要做，并且最大化的减少未知的模糊性。而项目开发分为三个阶段Pre-Production(开发前)，Production(开发中)，Post-Production(开发后)。那么各阶段中又都有哪些重要的项目管理方法呢？（超长预警）

• Pre-Production
  
• Waterful vs Scrum瀑布式开发及敏捷开发
• Pitch Doc / Project Summary 直观概括的项目文档
• Design Wiki
• 1-Page Design Doc
  
• Project Plan 项目计划
  
• MileStone 里程碑
• Product Backlog/Feature List 待完成任务
  
• Sprint 快速迭代
  
• User stories
  
• Size: Story Points 关于工作量预估
  
• Planning Poker计划扑克
  
• Burn Down Chart & Velocity Chart
  
• Daily/Weekly Check-in每日站会
  
• Version Control版本控制
  
• Pipeline 工作流程
  
• Build Note 更新笔记 + Bug Report 问题报告 + Playtest 测试
  
• Post-Production
• Retrospective 及时回顾总结

Pre-Production & Production

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

在项目立项之初，首先需要确定的是团队要采用的开发方法，是瀑布式开发还是敏捷开发。传统的瀑布式开发强调把每一个阶段都做到完美才进入下一个阶段。

从需求分析到设计，从设计到开发（程序，美术等）再到测试。瀑布模型强调文档，前期没有迭代与反馈，因而对于需求不明确易变更的项目很不灵活。

而在游戏开发中，个人认为好游戏不是想出来的而是改出来的，一切以玩家为中心才是好游戏的根本，非商业向的游戏需求变更更是家常便饭。因而强调小版本及频繁迭代与测试的敏捷开发（例如Scrum模型）或许更加适合游戏，不仅是小团队，目前也已基本被业界普遍推广采用。

敏捷开发灵活性高，强调面对面的及时交流（例如Daily 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: 简要描述项目规模，预算及时间规划

Design Wiki & 1-Page Design Doc

除了Pitch Doc外，在之后的开发中也还会配合增加一些必须的项目文档。但在敏捷开发中，繁冗传统的设计文档由于沟通成本过高并且没人想要读一本几十页的说明书，已经很少再作为沟通的媒介使用。以下两项是目前在行业内需要使用必要的设计说明文件时较常使用的方法：

Design Wiki （比如可以参考看看Stardew Valley的 Wiki Official Stardew Valley Wiki）

简单来说是将传统文档变成在线文档，易检索与更新，方便共同编辑。通常作为查询归档使用，并不太作为开发指导文件。

1-Page Design Doc （详参GDC讲座地址One-Page Designs）

1-Page Design Doc是提高文档使用率及沟通效率的新形式。最初灵感源之一是建筑工程图纸，强调以最少的篇幅（仅一页！）及直观的图示诠释设计。一页的篇幅极大地减轻了开发人员阅读繁冗文字的痛苦，并且使得及时交流与更新变得更为便捷，图示相较于文字也更容易展示系统间的关系及动态变化。1-Page Design Doc我们较常见的类型可能是UX设计中常用的Flow Chart界面流程图，但其实也可用于其他设计中，常见的比如还有关卡设计，核心玩法解析等。

（在网上无意发现了一个设计师的个人网站中有不少使用了1-Page Design Doc的例子，可以看看TUTORIALS）

————————

Project Plan 项目计划

项目计划表可以算是项目管理中的核心文件了，小团队由于人力不足没有精力维护大量文件，因此在我自己的项目中，我把时间表，里程碑，以及Backlog，Sprint的任务安排都集合在了这个表里。这样我日常维护的文件基本就只有Project Plan及后文将提到的Build Note了。