推 justben:推經驗分享~ 10/18 22:16
推 cowbaying:規格書真像在寫教案 10/18 22:56
推 LaPass:推 10/18 23:39
→ AmosYang: +1 insightful 10/19 05:41
推 Knightaco:推 10/19 13:26
遊戲軟體管理經驗談
發佈區域：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)