遊戲軟體管理經驗談 發佈區域：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)