游戏软体管理经验谈 发布区域：PTT GameDesign版（telnet://ptt.cc），部落阁Black Straits Historical （http://ndark.wordpress.com/） 版权所有，禁止转录 作者：NDark，目前任游戏公司软体工程师（专案主程式） 时间：2011 秋 软体管理可以使用的工具 本章节说明软体管理上常使用的工具，由简而繁依照优先顺序分别是： 版本控制，错误追踪，专案管理。 我接触过大部分的软体团队都可以认可版本控制的重要性，也都在使用中了。这层比较没 什麽争议。即便是只有一个程式设计师的团队，都建议使用版本控制软体来控管程式设计 师每日，甚至一天中各时段的实作。强迫人员把程式码上传管理，对公司及团队绝对有利 ，对程式码的品质也有帮助。 要使用哪一种版本控制的工具，完全是视乎团队的特性，习惯，或专案的规模。 - 开发人员使用的习惯？若是刚开始使用版本控制的团队，Subversion搭配TortoiseSVN（ 小乌龟）是免费的，不管是架设或使用都算是相当平易近人。 - 开发人员有无定期出差？出差时还要进code就要使用某些不需要伺服器的版本控制软体。 - 专案受到版本控制的档案量？Subversion档案数量大的有时会有一点效能问题。 这边比较值得一提的是企划与美术人员的产出要不要纳入版本控制的范畴？ 游戏最终使用的媒体（包含脚本）是必然一定要。 如果没有强烈排斥的话，其他企划文件，脚本制作中的文件，美术原始素材，中继档都建 议要纳入版本控制。但可以不需要强制统合在一个Repository内。 对於企划与美术人员而言，这样的档案管理方式比较陌生，因此若有适应问题，就需要政 治力的介入，让企划与美术人员了解到这不是在扯後腿，而是在团队规模提升时帮助团队 管理档案，让团队的各人有需要时都能看到其他人员的成果，减少同时修改一份文件时造 成的版本冲突。 subversion：http://subversion.tigris.org/ TortoiseSVN：http://tortoisesvn.tigris.org/ 第二层是错误追踪软体。 我们从反面列出没有错误追踪软体会造成什麽问题？ - 回报用口头的方式，若是没有记录下来，会忘记或漏列。 - 有回报，但是没有厘清责任，造成没有人认领或处理。 - 甚至会因为不同测试人员口头回报（譬如说老板走过也看到这个问题，就随口讲了一下 ，工程师接到老板指示，还不敢赶快处理吗），造成问题被重复处理。 - 有回报，有认列，有处理，但是处理完毕没有回馈，以致於问题目前的状况只能用口头 的方式询问。每天不断的询问。造成软体人员工作不断被打断，询问者与被询问者工时 的浪费。（假如一个软体人员身上挂了二十几个错误，每天不断地清查这二十几个项目 就不知道要花多少时间）甚至会有 "你到底在问哪一个bug？不是三天前就解决了吗？" 的情形发生。 - 管理层不能透过一个简单的表达窗口（甚至不用问任何一个测试人员）来了解目前的专 案的稳定度：错误越少，表示越接近可以发售的状态；错误很多，表示时程应该调整一 下先把专案稳定下来；有延宕已久的错误，代表可能有潜在的风险；很久没有更新，表 示测试人员不知道有新版本或测试人力被抽走。 该用哪一个工具？Mantis算是简单好用的佼佼者。（http://www.mantisbt.org/） 有制定测试的规范时就该使用错误追踪软体。 最後一层是专案管理软体， 可以分为工作管理与文件管理。但是由於文件管理是另外的课题，我们这里不讨论。 不使用专案管理软体依然可以做游戏。企划人员依然每天写文件，美术人员依然每天画图 ，程式人员依然每天写code。然而这些工作的分派，还是有赖专案经理或主程式，主美术 ，主企划在开案或是每周每天的会议中进行。会议依然是必须持续进行且有用的。每次的 会议纪录就是确认接下来要执行的工作。而管理层再把这些工作告知执行的人员。最阳春 就是透过便利贴（如scrum）或e-mail的方式。最不负责就是只透过耳提面命的确认。 如同错误追踪软体，专案管理软体就只是把这些管理工作，变成一个各组员都可以存取的 介面。只是错误（bug）变成了工作（task）。这样的工具软体造成的好处大致就跟错误 追踪一样：工作有认列，有规格，有分派，有执行与结束，有工时，有完成度。 什麽时机要导入专案管理软体？ 大约是专案人员的规模可以切成三层（专案经理－主程式－程式人员）的时候就应该导入 （当然提早导入也没有坏处）。 在此之前，因为团队规模不大，团队组员几乎都可以坐成一圈，工作靠着面对面还勉强可 以顺畅沟通。专案管理软体让管理阶层能够不透过打扰工作执行人员的方式就可以了解目 前专案进行的概况。每日进行的进度。 可以使用什麽工具？同样介绍免费的redmine（http://www.redmine.org/）。它同时可以 用作错误追踪之用。但是我比较习惯把这两个系统切开来。 最後对於游戏专案管理或软体管理工具的结论。 我都抱持着一个信念：事在人为。 对於一个合谐的团队，没有这些软体不会造成什麽大问题，维持 "人和"［注］就能保持 专案继续推进。使用这些软体工具，就是协助我们将原本是透过口头或信件传递的资讯， 变为一个组织化过後的情报系统。若执行的人员不收e-mail，从来也不连上这些软体工具 的窗口。那麽这些工具对这专案而言就如同废铁。 反之，若是管理阶层不当或过分的使用这些软体工具（譬如过於将数据奉为圭臬，或是只 是追求形式），也有可能会造成下有对策，这些工具就会变成例行敷衍的橡皮图章。 我从学生时代的专案开始就担任主程式的角色，我很需要一个协助我分派工作的工具。所 以当我接触到这些软体工具後很自然而然的愿意接受并使用它们。但是这些工具只是协助 我进行日常的工作，真正在规划，管理，解决问题的还是 "人"。这点是导入这些工具的 管理者必须非常严肃体认到的一点。若是要我在人与工具之间挑一个，我必定会留下真正 能执行工作的团队人员。 ［注］： "一地鸡毛——软件项目中的人际困局"（ http://www.programmer.com.cn/8197/） -- "May the Balance be with U"(愿平衡与你同在) 视窗介面游戏设计教学，讨论，分享。欢迎来信。 视窗程式设计（Windows CLR Form）游戏架构设计（Game Application Framework） 游戏工具设计（Game App. Tool Design ） 电脑图学架构及研究（Computer Graphics） -- ※ 发信站 :批踢踢实业坊(ptt.cc) ◆ From: 118.160.137.171 ※ 编辑: NDark 来自: 118.160.137.171 (10/13 22:01) ※ 编辑: NDark 来自: 118.160.137.171 (10/13 22:05)