游戏软体管理经验谈 发布区域：PTT GameDesign版（telnet://ptt.cc），部落阁Black Straits Historical （http://ndark.wordpress.com/） 版权所有，禁止转录 作者：NDark，目前任游戏公司软体工程师（专案主程式） 时间：2011 秋 什麽叫做（软体）规划 当我们手上拿到一份企划人员产出的文件，软体人员就会开始进行分析与规划。 分析就是把企划文件变为软体人员可以实做的软体架构规格书。 规划就是要实行这样的软体架构规格书，要如何安排工作项目及分配人力。 - 简单来讲，一份详尽的软体规格文件，必须交给两个不同的程式设计人员，都能做出相 同的东西。 - 同理可证，一份详尽的企划规格文件，交给不同的软体架构分析师（或主程式），都会 产出相同的软体架构规格书。 所以由粗略到精细，我们可以把这些设计文件分为几种等级 - 需求（发想）文件 - 企划规格书 - 软体架构规格书 - 工作项目 企划的文件写到什麽程度叫做需求文件？什麽程度才能称作企划规格书？这个很难界定。 多半是企划人员与程式人员共同都了解并同意里面的内容後就可以成为一个企划规格书。 企划规格书是是可以实行的，或是如上述所言，交给不同的团队都可以实行的。 对於企划规格书有几个审核上要注意的事项，或是常犯的错误。这些错误不一定是滔天大 罪，但是这些错通常很明显，应该在出厂的时候就应该要勘误完成，放任这种文件出厂， 讲老实话很难不被抓出来鞭。（看到有问题的企划书时真的忍不住，就像有虫在身上咬一 样） - 有错别字：这不是什麽大问题，但是看起来就会觉得企划自己都不看重自己的文件。我 们永远都不知道这些文件最後会被拿来干什麽？也许有一天就复制贴上到会议报告投影 片中，到时候因为这一点小缺失而出丑的就是整个团队。能够及早勘误掉的错误就尽可 能在源头就处理。 - 语句不通顺。 - 前後文复制贴上造成的笔误：原本不应该相同的文字却相同，造成理解上的困扰。 - 名词前後不一：譬如前面叫做火焰，後面叫做火圈。在软体分析时就会被当作不一样的 东西。造成实作上的困扰。 - 从错误的版本继续修改造成两份文件的矛盾。 - 部份规格修改後，相关的地方没有一并修改：这是发生在专案开发一段时间後，由於同 一件事情可能分开在不同的地方描述，因此修改了一处，常常会忘记连带修改其他地方 。就造成规格内容的不一致。 - 承上，同一件事在不同地方重复描述。或是同一件事分开成好几个部份在不同地方描述 。这两种算是文件章节编排所造成的阅读困难。而这种阅读困难，会造成软体分析师的 困扰。 - 使用写文章的描述方式来写规格书：写规格书不是写小说，不可以用起承转合长篇章回 来写。最好能使用条列式的方式来撰写。一条列写一个事项。 - 建议将不同的章节以主体的不同来来描述，然後再辅助超连结让阅读人可以快速查找。 譬如说在主角的章节中描述攻击行为："打倒哥布林後，哥布林会做出。。。的死亡演出 "，这边就不应该太详细的描述哥布林的死亡演出，因为这边的主体是主角。应该改为" 打倒哥布林後，哥布林会做出死亡演出。（请参阅哥布林演出动作章节）" - 承上，将参数的描述内容统一在一个地方撰写。譬如说"一分钟闪动五次"这样的写法是 不好的，因为谁都不知道这个一分钟五次的参数什麽时候会被改变，而参数表改变时有 时候就忘记一起修改其他部分相关内容的描述，然後就导致前後矛盾。这边的描述法应 该改为"以一定的频率闪动（请参阅表格Ａ）" - 没有列出优先度：一个企划文件刚开始通常会很完整，完整到一定会造成超过团队的合 理工时（意思是会做太久），所以砍规格是很常见的事情。若要交由外人来砍，不如企 划人员就先把优先度排好，方便讨论後在尽量能够表达游戏特色的情形下，砍掉一些比 较难做，又没什麽价值的功能项目。 软体架构规格书 软体架构规格书该怎麽写，其实我也还在拿捏，以最高标准来说，两个程式设计人员看到 同一份软体架构规格书都应该刻出相同的程式码。因此软体架构规格书就应该精细到每一 个元件的每一个成员，每一个介面，以及介面内部要做的事情。最後是元件间的沟通。 "若是有办法写出这麽详尽的文件，干麻不乾脆直接写code就好了！！"其实这是我每一次 写软体架构规格书内心的呐喊，但除非团队的程式之间的产出元件不用作任何的沟通，不 好好规范必定会造成未来磨合的痛苦（必定要砍掉重练）。 简单来讲，软体架构规格书就是要详述目标元件，把命名与介面写清楚，让使用者能够了 解如何使用这个元件，把运作内容写清楚，让执行的人员可以完成各介面的实作。然後把 成员写清楚，确定元件间的隶属关系，使用的资料结构，以及订好命名规格。 可以由下而上，先由执行人员草拟规划，再由资深人员调整。也可以由上而下，资深人员 先定好大概的框架。底层执行时再补充没想到的可能细节。 内容大致上会像这样 什麽什麽手铐元件 - 有一个什麽什麽手铐元件，主要是用来把坏蛋的手拘束起来。（第一句话就把把元件的 名称与功用讲清楚） - 手铐元件是由两个可旋转的双层金属半圆环，与一个金属链子所组成。（元件的组成物 ）手铐是由警察所拥有。（元件被谁拥有） - 一个警察可以不只有一个手铐。（元件的资料结构） - 金属链的预设长度为。。。（规范定义） - 手铐的使用方式有"取出手铐"，将手铐自容器中取出，初始完成後手铐可以开始使用。 - 手铐的使用方式有"将金属半圆环套在手腕上"，其步骤如下，先将目标物的手腕捕捉， 将手铐的其中一个金属半圆环可活动处套入该目标手腕上，等待可活动处进行一个循环後 发出咖滋声。 - 因为有两个金属半圆环，至多可以进行两次的捕捉动作，捕捉完成的金属半圆环不能再 进行其他手腕的捕捉动作。 - 手铐的使用方式有"解开手铐"，对指定金属半圆环传入一个金钥，就可以解开其中一个 金属半圆环，一次解开一个金属半圆环。 - 手腕可以被复数金属半圆环所捕捉。 - 同一副手铐的两个金属半圆环不一定要捕捉相同的对象。 估算时程的方法 当我们已经有一份详尽可以实行的软体架构规格书，接下来要做几项工作 拆解工作项目。 估算工作项目的时程。 安排人力。 拆解工作项目的说明很模糊， "完成游戏"就可以是一个工作项目。更上面的"游戏发售完毕"也可以是一个工作项目。要 拆解到什麽程度？大致上会拆解到一个员工可以在一定时间完成的地步。这个一定时间很 弹性，依据管理层想要以什麽样的频率来检视软体工程师的进度，如果是跑scrum的团队 ，就应该精细到以天为单位。我的经验多半会从一天到一周为范围。规划时期最低工作项 目是一天（执行时期出现的项目就比较弹性，但是最短能在半天会比较合理），但一项目 内可包含多项小工作合并执行。超过一周的工作项目必定可以再拆解为多个子工作项目。 多半可以从上而下，将游戏的完成依序拆解为树状的架构。（这时有一个好的具象化工具 来协助就很有帮助）当我们把工作项目全部展开，如果规划有认真执行，那麽展开的这些 千百个工作项目这就是我们全部要做的事情。 这边补充几点 如果有心要品质管理的话，测试验证的工作项目必须在此一并排入，但是不建议隐藏在各 工作项目中。譬如说有一个工作项目"实作武器系统"，那麽就应该（通常就算没排最後也 必定会发生）跟着数个工作项目： - "测试完成武器系统"：避免软体人员报告说完成了，可是根本装不上去的现象发生（说 不定连编译都编不过）。提供软体团队内部就先透过这个工作项目来把关。主程式跟软 体人员说"你执行给我看，我看没问题就是测完了。" - "武器系统除错"：完成放上游戏跟其他系统整合後，一定会有错误，或是在某些情形下 与规格不符，处理那些例外错误的时间就堆在这里。这样就避免要回去把"实作武器系 统"的完成度倒退的难堪窘境。 - "武器系统维护"：完成数个礼拜後，可能因为其他模组完成并装上了，才发现跟其他模 组会互冲，那还是回来改。 - "武器系统验证"：这一个工作项目才是真正品质管理人员要做的，拿出测试清单，把所 有该测的东西测过一遍就是验完了。 有关除错／维护／验证这种东西时程比较不好估，通常是经验法则。列不列项目与时程看 团队的习惯。一并排出的目的就是为了抓一个除错的缓冲时间，我想软体人员都可以理解 有时候 "做完不叫完成"。 如果是特定的错误，也可以等到错误出现时再列类似这样的工作项目："[臭虫] 武器系统 在使用按钮时失效的错误" 如果要安排管理人员（专案经哩，专案负责人，制作人，主程式，主美术，主企划，测试 窗口）的工作，注意要明确安排管理或日常行政运作的工作项目。譬如说"安排与讨论工 作"，"检验软体人员完成内容"，"建置发布版本"这些就是纯管理的工作项目－这些工作 没有实际贡献到游戏中，但是就是花了一定量的时间。以我任主程式的经验来说，每天花 在沟通管理讨论日常运作上的时间大概是百分之四十。剩下的六十才是真正写程式。如果 是更高阶的管理职，那麽管理与实际工作的比例可能就是九十比十，甚至完全做管理。 接下来第二步就是在软体管理上最难处理，也就是争议最大的部份之其一：估算时程。 为什麽说困难？估算时程是在决定一个未来的事情，而未来是说不准的。在还没做之前， 如何能知道该工作项目要做多久？都是单凭经验。因为靠的是经验，不同人来估，就会有 不同的结果。那麽到底要依照谁估的时程为准？ 这不只是技术问题，还是政治问题。基层人员估计的时间跟实际执行的时间不符之时（通 常是暴了），最多跟你两手一摊，或是责成加班。专案真的暴了是已发生的事实，谁切腹 都没用。 估算时程有几种作法可以参考 - 由下而上，先请可能的执行人员对工作项目做评估後往上累计。缺点在於工作项目规格 可能就不够明朗到基层人员也看得懂。人员经验不足可能导致错估时程（可能会超级短 或超级长）。菜鸟受到压力或想表现就会以少报多（估计太短，就我的经验以少报多的 工作项目在未来老天都会找对应的臭虫来要我们还债）。 - 相反地由上而下，由资深人员分析，分项可以比较贴近正常值，但是容易没有顾及执行 人员的能力（占计过短），也就是菜鸟事实上都会做的比较久。 - 如果都以团队中技术力最差的人员来占计，则整体占计会太长。 - 也可以分两阶段来估计，粗占时程由资深人员评占。真正执行前由执行人员再做调整。 缺点在执行期开始後，时程必定是不断变动的，然而只要管理阶层能够认同了解，这样 的做法也许是比较弹性的。 安排人力 第三步就是进行人力的安排，那些工作项目要给谁做。这时候就真正可以把工作项目排上 几道人力轨道上，粗步就可以估计出全部的工作都做完之时，完成时间点在何时？然而这 里有一些安排人力上值得注意的事。 - 哪些工作给谁执行？工作的技术力强弱，人员有工作的偏好等等。 - 哪些工作是有依存性的？有些工作要先做才能做後续的其他工作，这样的工作就不能同 时由不同人员进行。 - 团队的人员合作的默契如何？如果整合良好，有依存性的工作就比较能弹性的交给不同 人员来先後执行（像上下游，或工厂的pipeline）。相反地，如果合作能力不足，那麽 就可能倾向一个人负责上下游的前後几个工作，一路做下去。 当我们以很重要到不重要的顺序，以及上述的规则把工作安排到人力上时，常常就会发现 人力轨道上有些不平衡的现象，就像是某些人力容易处於空闲的状态，这时就要花心思调 整尽量让每个人员的工作量，执行工作的重要性能够平衡。我自己的经验是把技术力低但 是需要长时间投入的工作交给比较资浅的人员，让他能够专注在一件事上。把比较需要审 慎规划的工作交给资深人员。不将技术力强的员工工作排的太满，让他们有弹性支援各项 突发状况。把重要但是不紧急，或是能见度比较低的工作揽在自己身上。不将重要的技术 工作通通交给同一个人，让其他人与此技术核心人员做一个工作上的搭配多少了解一下运 作内容，或是安排技术分享的时间。 里程碑的安排 不管是用瀑布式，还是跑scrum，多半都会切多个版本或里程碑，定期验证专案的内容。 就我的经验，里程碑的 "时机点的选择"比我们脑海想像中来得重要。不建议只依靠最终 发售日来随便逆推某一个月底。 决定里程碑的依据，就是我们希望里程碑带给专案什麽样的帮助？一个里程碑通常代表着 可以试玩的版本，也就是一个有经过除错的版本，此版本应该经过团队认真（加班後）的 看待。因此我们可以说一个里程碑就是伴随着功能完成－测试与除错－发布－庆功宴－检 讨－重新出发这样的步骤。缺少或是轻视其中一环，都很容易对士气造成打击。功能没完 成就测试，测试没完成就发布给玩家试玩，辛苦的发布了却得不到公司的感激，发布版本 後发现一些潜在问题却没人检讨，马上又投入没日没夜的加班赶下一个版本等等。 如果工作项目有认真规划时程，那麽以重点功能完成整合的时机来做里程碑是比较适合的 。重点在於完成了功能才来进行检验，而非为了赶里程碑的时间而随意应付。我经历过很 多次为了一个不知为何设定（或说根本没有列出规格）的里程碑而在测试开始之後硬补上 一些没有意义，一定会重做，只是为了检验或展示而做的工作。我也遇过很多次展示与测 试日期定死了，到了测试开始当天发现功能根本还没做完。这些功能只好赶进度在测试期 一半，甚至到了展示前一天才完成，所以根本就没有时间好好测，到了展示时理所当然就 变成臭虫跳出来给团队看，导致团队出糗了这要怪谁呢？是怪程式没完成？还是测试没测 出错误？还是怪美术素材太晚给不能测？测出错误没来得及修好？还是怪这样的时程规划 ？这样的里程碑规划对团队的士气很容易造成负面影响。 里程碑的结束也很重要，能够让团队有种"终於做完了，可以稍微喘息，辛苦看得到回报 ，距离成功又完成了一点"的感觉，才算一个良好的里程碑。不管是里程碑排的过於紧密 ，团队还未获得充份休息充电就马上开始奔跑。或是排的过长，工作太过於发散，没人知 道整个游戏的进度到什麽程度，没有确认整合上的潜在问题，或根本没有测试。都会造成 可能的团队危机。 软体规划的结论 软体规划是专案规划的一部分，专案规划完毕後就可以产出提案／发案报告。其中应该会 包含：市场分析，占计时程，占计成本（含人力配置），风险管理。很多工作项目或规格 因为经验不足（从没做过）所以会导致规格描述不清，漏列导致估计时程的不准确。这是 非常常见的情形，却也只能依靠有经验的软体人员来补足缺失。 -- "May the Balance be with U"(愿平衡与你同在) 视窗介面游戏设计教学，讨论，分享。欢迎来信。 视窗程式设计（Windows CLR Form）游戏架构设计（Game Application Framework） 游戏工具设计（Game App. Tool Design ） 电脑图学架构及研究（Computer Graphics） --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 118.160.136.11 ※ 编辑: NDark 来自: 118.160.136.11 (10/18 21:26) ※ 编辑: NDark 来自: 118.160.136.11 (10/18 21:27)