圖片引用自 HJL
在上一篇文章《工作劃分篇》中，我提到了在遊戲中設定需求項目的方法，而這次要把小圓圈再放大，工作劃分除了細節的描寫外，更重要的是如何安排每一個階段的進程，在這裡我導入的是敏捷開發專案管理框架「Scrum 」的觀念
過去工作分派後，日常生活會呈現兩種情況，一種是緊迫盯人，每天照三餐問對方東西作好了沒，一種是放牛吃草，反正等時間到了東西有出來就好
在工作分派前，整個遊戲製作沒有任何明確排程，好比遊戲什麼時候作好，遊戲什麼時候要做到什麼樣的地步，都沒有統一的規範，甚至有明確排程的情況還比較像是，「程式向美術要元件，問美術什麼時候可以作好」的時候。多半情況下，美術不知道遊戲到底整體作得怎樣，程式也不知道美術進行到哪，如此沒有章法的作法，很容易拉長遊戲製作的時間，甚至最終產出了只作出一半的作品
老實說，我沒有辦法提出讓遠程工作的夥伴，能夠永遠為一個專案無條件犧牲奉獻的方法，好比某A突然收到兵單，總不可能在他隔天去火車站的路上綁架人家吧，所以異地工作的無酬方式，本身就存在各種不定的風險 。･ﾟ･(つд`ﾟ)･ﾟ･
但如果大家決定一起坐下來完成某件事情，最後卻因為怠惰、茫然、混亂等管理不當的因素導致拆夥，我認為這是非常可惜的事情，台灣也因此少了一個有潛力的新星，倘若導入專案管理的方法，或許就能夠降低風險，這就是為什麼哈利菠菜要提出一個遊戲團隊管理模式的原因了
※
關於敏捷開發與「Scrum」的詳細內容，可以到 Wiki 上檢索，畢竟是非常成熟的軟體管理框架，網路資料眾多所以我在這裡僅就適合遊戲開發團隊的方法作分享
不管你的遊戲有多大，在遊戲製作開始都要設定一個「進程」，而團隊必須要在進程裡面完成開始進程前所設定好的需求項目，這個進程的長度多半是兩週到四週
當然我的意思不是要團隊爆肝，幾週就把東西全部生出來，而是透過一個進程一個進程的連接，慢慢把遊戲作好。但遊戲的事情這麼多，我們要怎麼決定進程裡面該做哪些事情呢? 該從哪一個項目下手比較好?
在這裡，我會建議優先以「讓遊戲可以展示」為最高準則，也就是想辦法先完成最小可行性產品，在那之前團隊要先討論出最小產品應該要有哪些功能，並針對這些功能設定需求項目
在以「最小產品先行」的前提下，程式端負責的需求項目可能如下(建議需求項目不要一次開很多，因為進程完畢之後一定還會再回頭修正)：
| ID | 名字 | 重要性 | 備註 | 時間 |
| 101 | 玩家可以看到開始畫面的背景與4個按鈕 按鈕分別是重新開始/讀取存檔/工具/人員名單 |
90 | 需導入背景圖像 4個按鈕圖像 |
5P |
| 102 | 玩家可以點選重新開始按鈕進入遊戲 | 80 | 進入遊戲後先展示一張jpg底圖 | 1P |
| 103 | 玩家可以點選讀取存檔進入遊戲存檔介面 | 80 | 需導入界面圖像 | 1P |
| 104 | 玩家可以聽到開始畫面的背景音樂 | 80 | 需導入音樂 | 2P |
| 105 | 玩家可以點選工具調整音樂、音效、畫面品質選項 | 80 | 需導入介面按鈕 | 4P |
| 106 | 玩家可以看到場景上的主角 | 80 | 需導入人物圖像 | 4P |
| ... | ... | ... | ... | ... |
美術端的需求項目可能如下：
| ID | 名字 | 重要性 | 備註 | 時間 |
| 201 | 玩家可以看到開始畫面的背景與4個按鈕 按鈕分別是重新開始/讀取存檔/工具/人員名單 |
90 | 背景大小JPG1600*900 4個PNG按鈕大小100*80 詳細位置參考9/18的會議檔 |
4P |
| 202 | 玩家可以看到進入遊戲後的第一個場景 | 80 | 背景大小JPG1600*900 |
4P |
| 203 | 玩家可以看到存檔的介面 | 80 | 背景JPG1600*900 1個PNG按鈕返回大小100*80 詳細位置參考9/18的會議檔 |
2P |
| 204 | 玩家可以看到工具的介面 | 80 | 背景JPG1600*900 3個PNG按鈕返回大小100*80 |
3P |
| 205 | 玩家可以看到人物站在場景上 | 80 | 45張序列圖，各單位大小300*200 圖檔不可超過800KB |
7P |
| ... | ... | ... | ... | ... |
經過第一次開會後，團隊決定好首個進程要花10個工作天的時間來執行，所以美術跟程式都各有10P的時間單位可以用，程式的話可以選擇作101+102+105的選項，這樣加起來的時間單位剛好是10P，而美術的話可以完成201+202+203的需求項目
在這裡建議美術與程式都要開一個雲端協同工作 ( ex.Dropbox ) 的資料夾，只要美術一有新的東西更新到裡面，程式就可以直接套用，免得每次作好東西還要打擾正在工作的對方
兩邊如果有完成該項目的需求時，可以用協同工作表 ( ex.Google 文件 ) 中的試算表進行管理，把需求項目後面再多一個完成與否的欄位，只要完成一項需求就先把該需求作標記，以方便管理跟檢查
進程中，我會建議團隊所有成員，每天都要花15分鐘的時間用 Skype 開視訊會議，主要討論昨天作了什麼事情，時間盡量不要太長，如果少於15分鐘也可以，這樣的方式可以確保團隊的默契，同時讓整個進程步上軌道，當然能用視訊討論是最好，如果不方便，隨便用一個線上聊天室都可以
當進程結束後，團隊要開一個 Demo 的常會，檢討進程中的問題，好比說程式發現某個功能實作要花比較久的時間，屆時後面的某個項目時間就要修正，而美術可能也發現作某個東西的時間不必要這麼久，於是把一些時間單位再作縮短，或是說 Demo 的時候發現程式出現某個bug，倘若該bug沒有在未來的需求項目中，就要安排到下一次的進程
Demo 結束後設定下一個進程的時間跟內容，就這樣反覆的進程>Demo>進程>Demo...，遊戲就可以慢慢成型囉! (๑•̀ㅂ•́)و✧
※
看到這裡，你可能會想說，每天說自己昨天作了什麼事情很重要嗎?
「是的，非常重要」這時候某個路人甲跳出來「要監督大家有沒有作事情 ( • ̀ω•́ )」
首先謝謝路人這位熱心的路人甲 ( 喂 )，其實....這是非常錯誤的心態 ( 打臉 )，所謂監督是建立在不信任的基礎，如果團員存有貳心，那我建議拆夥算了，作遊戲的確會有壓力，但如果變成罪惡感，對團隊、對整個遊戲都不好 (｡ŏ_ŏ)
遠端工作建立在團員的高度"自律"上，所以每天15分鐘討論的重點不是在於檢查有沒有作事，而是讓整個團隊參與過程，讓程式知道原來美術要做這些事情要這麼多心力，美術知道原來程式要建立一個功能是多麼傷腦，每日會議因此增加了團隊凝聚力
另一方面，如果有問題也可以在現場提出來，倘若專案開發有兩個美術，那美術可以跟企劃討論風格統調的問題，即早先作修正，程式如果發現該功能開發有困難，可以討論是否要選擇折衷的方式開發 ( 當然這要看折多少，如果把 RPG 折成 AVG 就折的稍微大了一些 ( ºΔº |||))
一個進程結束後的 Demo ，其用意在於隨時讓產品處在完整階段，藉此增加團隊的信心跟士氣，「喔喔喔! 人物可以在上面移動了耶」、「沒想到介面放上去看起來好屌」，美術會看到自己的東西馬上被實作的樣子，有些時候「東西能不能跑」比美術畫很漂亮或程式碼寫得很完善要重要許多，有了成果後，也更願意持續投入心力在遊戲創作中了
※
無論如何，管理只是一種工作的方法，並不是萬靈丹，不是導入管理就可以百分之百完成遊戲，身為製作人/領導人的你，還必須隨時扮著黑臉與白臉，隨時激勵大家的士氣，某些時候要很樂觀，有些時候要比任何人都看得見痛處，必須要能夠統御大家完成作品，並以身作則，要比團隊中的任何人更遵守管理的章法，在大東京玩具箱這本漫畫第五集裡是這麼說的 ：
※
看到這裡，你可能會想說，每天說自己昨天作了什麼事情很重要嗎?
「是的，非常重要」這時候某個路人甲跳出來「要監督大家有沒有作事情 ( • ̀ω•́ )」
首先謝謝路人這位熱心的路人甲 ( 喂 )，其實....這是非常錯誤的心態 ( 打臉 )，所謂監督是建立在不信任的基礎，如果團員存有貳心，那我建議拆夥算了，作遊戲的確會有壓力，但如果變成罪惡感，對團隊、對整個遊戲都不好 (｡ŏ_ŏ)
遠端工作建立在團員的高度"自律"上，所以每天15分鐘討論的重點不是在於檢查有沒有作事，而是讓整個團隊參與過程，讓程式知道原來美術要做這些事情要這麼多心力，美術知道原來程式要建立一個功能是多麼傷腦，每日會議因此增加了團隊凝聚力
中國獨立遊戲 《雨血》
另一方面，如果有問題也可以在現場提出來，倘若專案開發有兩個美術，那美術可以跟企劃討論風格統調的問題，即早先作修正，程式如果發現該功能開發有困難，可以討論是否要選擇折衷的方式開發 ( 當然這要看折多少，如果把 RPG 折成 AVG 就折的稍微大了一些 ( ºΔº |||))
一個進程結束後的 Demo ，其用意在於隨時讓產品處在完整階段，藉此增加團隊的信心跟士氣，「喔喔喔! 人物可以在上面移動了耶」、「沒想到介面放上去看起來好屌」，美術會看到自己的東西馬上被實作的樣子，有些時候「東西能不能跑」比美術畫很漂亮或程式碼寫得很完善要重要許多，有了成果後，也更願意持續投入心力在遊戲創作中了
無論如何，管理只是一種工作的方法，並不是萬靈丹，不是導入管理就可以百分之百完成遊戲，身為製作人/領導人的你，還必須隨時扮著黑臉與白臉，隨時激勵大家的士氣，某些時候要很樂觀，有些時候要比任何人都看得見痛處，必須要能夠統御大家完成作品，並以身作則，要比團隊中的任何人更遵守管理的章法，在大東京玩具箱這本漫畫第五集裡是這麼說的 ：
『只有一個人的自我、能量是大不到那裡去的。唯有把所有人的自我都融合在一起，才能完成一款遊戲。所以才會有人說，電玩不是一個人能做出來的。』( 圖文截取自 銀狐 Silver Fox 的碎碎唸 )
※
在進程篇中，大家是不是比較清楚管理遊戲的專案了呢? 相信導入這樣的管理模式，可以很快讓遊戲製作步上軌道，如果手上已經有遊戲開發計劃的朋友，可以開始試著把加進自己的團隊中喲，另外如果團隊還不明白要怎麼作，我也很樂意參一腳當個小顧問，聽聽你們的狀況或想法，台灣萬歲、獨立遊戲製作萬歲 ヽ(●´∀`●)ﾉ
---
歡迎各路好手踢館討論 (*´艸`*)
---
歡迎各路好手踢館討論 (*´艸`*)
---
