本文首發(fā)于知乎專欄“紐大的游戲故事”，作者力嚕啊噢力，游戲葡萄已獲轉(zhuǎn)載授權(quán)。

作為獨立開發(fā)者或者小型開發(fā)團(tuán)隊，由于直接溝通成本較低，過多的項目管理流程反而使得開發(fā)過程變得繁瑣，除此之外也因資源有限，小型開發(fā)團(tuán)隊很少設(shè)有專職的項目經(jīng)理控制項目進(jìn)度，以至于規(guī)范的項目管理方法常常在小團(tuán)隊開發(fā)中被忽視。也正因如此，如若沒有外部壓力（例如發(fā)行商的督促）獨立開發(fā)團(tuán)隊也較容易因缺乏有效預(yù)估和進(jìn)度控制等原因?qū)е马椖客涎印?/p>

因而本文整理了一些個人認(rèn)為對于獨立團(tuán)隊來說相對實用的項目管理方法，希望對各位有所啟發(fā)。稱之為“指南”其實并不很貼切，本文中所提及的方法主要來源于在NYU Game Center的一門項目管理課程Production Practicum中所學(xué)，結(jié)合個人的實際經(jīng)驗進(jìn)行的簡易總結(jié)，并不能被當(dāng)作嚴(yán)謹(jǐn)全面的“指南”，希望借此拋磚引玉，歡迎各位也來分享自己認(rèn)為實用的項目管理方法。

項目管理的核心可以概括為隨時明確誰應(yīng)該在什么時候做當(dāng)下最該做的事情以及為什么要做，并且最大化的減少未知的模糊性。而項目開發(fā)分為三個階段Pre-Production(開發(fā)前)，Production(開發(fā)中)，Post-Production(開發(fā)后)。 那么各階段中又都有哪些重要的項目管理方法呢？（超長預(yù)警）

• Pre-Production

  • Waterful vs Scrum瀑布式開發(fā)及敏捷開發(fā)

  • Pitch Doc / Project Summary 直觀概括的項目文檔

    • Design Wiki

    • 1-Page Design Doc

  • Project Plan 項目計劃

    • MileStone 里程碑

    • Product Backlog/Feature List 待完成任務(wù)

    • Sprint 快速迭代

    • User stories

    • Size: Story Points 關(guān)于工作量預(yù)估

      • Planning Poker計劃撲克

    • Burn Down Chart & Velocity Chart

  • Daily/Weekly Check-in每日站會

  • Version Control版本控制

  • Pipeline 工作流程

  • Build Note 更新筆記 + Bug Report 問題報告 + Playtest 測試

• Post-Production

  • Retrospective 及時回顧總結(jié)

開發(fā)前&開發(fā)中

Waterful VS Scrum瀑布式開發(fā)及敏捷開發(fā)

在項目立項之初，首先需要確定的是團(tuán)隊要采用的開發(fā)方法，是瀑布式開發(fā)還是敏捷開發(fā)。 傳統(tǒng)的瀑布式開發(fā)強調(diào)把每一個階段都做到完美才進(jìn)入下一個階段。從需求分析到設(shè)計，從設(shè)計到開發(fā)（程序，美術(shù)等）再到測試。瀑布模型強調(diào)文檔，前期沒有迭代與反饋，因而對于需求不明確易變更的項目很不靈活。

而在游戲開發(fā)中，個人認(rèn)為好游戲不是想出來的而是改出來的，一切以玩家為中心才是好游戲的根本，非商業(yè)向的游戲需求變更更是家常便飯。因而強調(diào)小版本及頻繁迭代與測試的敏捷開發(fā)（例如Scrum模型）或許更加適合游戲，不僅是小團(tuán)隊，目前也已基本被業(yè)界普遍推廣采用。敏捷開發(fā)靈活性高，強調(diào)面對面的及時交流（例如Daily Check-in日常站會等），快速迭代（以Sprint為指導(dǎo)的短周期開發(fā)），經(jīng)常性的打包可運行版本及時測試等等。后文中將討論的方法基本是敏捷開發(fā)中常用到的一些方法。

Pitch Doc / Project Summary 直觀概括的項目文檔

在獨立開發(fā)團(tuán)隊中常常被忽視的重要一環(huán)便是項目預(yù)估，而有效的項目預(yù)估可以幫助我們更好地把控全局，正確評估任務(wù)優(yōu)先級，明確進(jìn)度，最大化地減小未知模糊性等。而在項目立項之初，預(yù)估的第一項便是Pitch Document了，大概可以稱之為創(chuàng)意文檔，以最少的篇幅簡要地描述游戲的核心內(nèi)容。

設(shè)計者在將創(chuàng)意寫下來的過程中不僅可以幫助其明確創(chuàng)意雛形，也是立項后項目開發(fā)方向的核心指導(dǎo)。Pitch Doc需要隨著項目變化保持更新，是在向他人介紹游戲時的重要參考文件。這類文檔約在2-5頁左右，主要解決以下幾個問題：

• 你想要做什么？

  • Overview: 一句話概述游戲

  • Platform & Genre: 目標(biāo)平臺及游戲類型

  • Gameplay: 核心玩法概述（可以配合圖示解說，參考下文1-Page Design Doc）

  • Feature: 為什么要做這個游戲？／為什么是一個值得做的項目？／有什么與眾不同的特點？…（若是商業(yè)項目，可能需要簡單的競品分析）

  • 同類產(chǎn)品: 為了更方便迅速的理解游戲，可以簡要提及相似的同類型作品

• 它看起來是什么樣的？

  • 美術(shù)方向：展示概念設(shè)計或參考圖等

• 你打算怎么做？

  • Team: 簡要描述團(tuán)隊成員分工及強項（為何可以很好的完成這個項目）

  • Scope, Budget, Timeline: 簡要描述項目規(guī)模，預(yù)算及時間規(guī)劃

Design Wiki & 1-Page Design Doc

除了Pitch Doc外，在之后的開發(fā)中也還會配合增加一些必須的項目文檔。但在敏捷開發(fā)中，繁冗傳統(tǒng)的設(shè)計文檔由于溝通成本過高并且沒人想要讀一本幾十頁的說明書，已經(jīng)很少再作為溝通的媒介使用。以下兩項是目前在行業(yè)內(nèi)需要使用必要的設(shè)計說明文件時較常使用的方法：

Design Wiki （比如可以參考看看Stardew Valley的 Wiki ：鏈接
http://stardewvalleywiki.com/Stardew_Valley_Wiki）

簡單來說是將傳統(tǒng)文檔變成在線文檔，易檢索與更新，方便共同編輯。通常作為查詢歸檔使用，并不太作為開發(fā)指導(dǎo)文件。

1-Page Design Doc （詳參GDC講座地址：鏈接
http://www.gdcvault.com/play/1012356/One-Page）

1-Page Design Doc是提高文檔使用率及溝通效率的新形式。最初靈感源之一是建筑工程圖紙，強調(diào)以最少的篇幅（僅一頁?。┘爸庇^的圖示詮釋設(shè)計。一頁的篇幅極大地減輕了開發(fā)人員閱讀繁冗文字的痛苦，并且使得及時交流與更新變得更為便捷，圖示相較于文字也更容易展示系統(tǒng)間的關(guān)系及動態(tài)變化。1-Page Design Doc我們較常見的類型可能是UX設(shè)計中常用的Flow Chart界面流程圖，但其實也可用于其他設(shè)計中，常見的比如還有關(guān)卡設(shè)計，核心玩法解析等。

（在網(wǎng)上無意發(fā)現(xiàn)了一個設(shè)計師的個人網(wǎng)站中有不少使用了1-Page Design Doc的例子，可以看看TUTORIALS：鏈接
http://bobbyross.com/tutorials/）

Project Plan 項目計劃

項目計劃表可以算是項目管理中的核心文件了，小團(tuán)隊由于人力不足沒有精力維護(hù)大量文件，因此在我自己的項目中，我把時間表，里程碑，以及Backlog，Sprint的任務(wù)安排都集合在了這個表里。這樣我日常維護(hù)的文件基本就只有Project Plan及后文將提到的Build Note了。

下圖便是我目前項目在用的計劃表，可以看到［頂部橫軸］是時間節(jié)點劃分以及里程碑相關(guān)內(nèi)容。時間點跟工作密度相關(guān)，我的表內(nèi)大概是半周一格，如果工作密度高可以分得更細(xì)。

［左側(cè)豎軸］第一列是大類類別（設(shè)計／美術(shù)／程序／音樂等），第二列再將每類分為不同的Sprint主題以及Backlog，三四列便是寫成User Stories形式的具體任務(wù)或者也可以說是Feature List了，每個任務(wù)旁對應(yīng)的是使用Story Points預(yù)估的工作量。

中間可以用色塊定義對應(yīng)任務(wù)安排的時間段，不同的顏色代表由不同的人負(fù)責(zé)。定期完成的就變成深色，沒有對應(yīng)計劃時間完成的，計劃就變?yōu)榛疑?/p>

MileStone 里程碑

里程碑應(yīng)該不用過多的解釋，主要是根據(jù)自己項目的情況定義一些重要的時間節(jié)點，再根據(jù)工作量及優(yōu)先級安排這個時間段內(nèi)的工作。里程碑應(yīng)當(dāng)包括時間點及定義為“完成”的具體內(nèi)容或標(biāo)準(zhǔn)。

Product Backlog/Feature List 待完成任務(wù)

我們在文初已經(jīng)簡要的提及了敏捷開發(fā)的工作模式，敏捷開發(fā)將一個長期的大項目切分成數(shù)個短周期，每個周期歷時約為1-4周不等，稱為一個Sprint（沖刺）。在立項之初，根據(jù)定下的Pitch Doc，團(tuán)隊成員要將目標(biāo)轉(zhuǎn)化為一系列待開發(fā)的Feature List（待實現(xiàn)的功能／特點），進(jìn)而形成最初的Backlog（待完成的任務(wù)）。

在項目開發(fā)早期，比如仍在快速Prototype階段時，可能由于項目需求尚不明確，提出的Backlog會比較大和模糊。不過沒關(guān)系，這個時候不要認(rèn)為這項工作是無用的，Backlog及Feature List會在項目不斷清晰的過程中不斷迭代更新，你的預(yù)估也會越來越準(zhǔn)確。

例如下圖中所示，Product Backlog通常包含標(biāo)題名，狀態(tài)，描述（寫成User Stories的形式），以及Size工作量預(yù)估等。

Sprint 快速迭代

那么定義完最初的Backlog之后，我們就可以開始進(jìn)入以Sprint為基礎(chǔ)的開發(fā)階段了。首先根據(jù)預(yù)估中對項目全局的把控及優(yōu)先級的判斷，確立當(dāng)前Sprint的主題及定義為“完成”的標(biāo)準(zhǔn)及內(nèi)容，然后從總Backlog中拿出符合這個Sprint的部分，將他們分解為易評估的具體任務(wù)并補充未考慮到的任務(wù)，根據(jù)優(yōu)先級排序形成我們這個Sprint的“To Do List（待辦）”。

每天的日常站會（詳見后文）后更新任務(wù)版，將今天要完成的任務(wù)從“To Do（要做）”移至“In Progress（進(jìn)行中）”，將已完成的任務(wù)移至待測試／確認(rèn)一欄。

任務(wù)管理看板作為日常進(jìn)度控制的主要管理方法，可以使用實體的，也可以使用例如Trello等軟件完成。但因為這樣的看板不太利于歸檔記錄，因此上面所說的Project Plan便可以承擔(dān)總控制歸檔的角色，從Project Plan中取出相應(yīng)的Backlog，Sprint完成后再歸檔更新至Project Plan即可。我因為團(tuán)隊很小且情況特殊，項目看板只有我一人使用，因而為了方便我沒有重復(fù)使用額外的看板，而是直接使用了Project Plan進(jìn)行進(jìn)度追蹤。

在每個Sprint結(jié)束后都要完成一個可以交付試玩的版本，并立即進(jìn)行測試，根據(jù)反饋評估這次的工作并調(diào)整接下來的計劃。不要因為擔(dān)心游戲不完美就憋著不測試，盡早的接觸游戲的核心服務(wù)主體“玩家”才能盡快的發(fā)現(xiàn)問題及時調(diào)整開發(fā)方向。敏捷開發(fā)極其強調(diào)可玩性，要求優(yōu)先維護(hù)玩家體驗。對可交付版本的高要求及高頻率自然而然地會幫助我們明確哪些是可以提高可玩性及用戶體驗的任務(wù)，并優(yōu)先完成他們，這也是我認(rèn)為在游戲開發(fā)中應(yīng)首要考慮的部分。

User stories

Backlog的需求描述通常需要寫成User Stories的形式，用最清晰的表述方法讓這個需求的目的明確且易評估。標(biāo)準(zhǔn)寫法格式如下：

As a…, I want to…, so that…

作為<角色>，我想要<行為>，以便于<目的>。

其中需要注意的是這個“角色”指的是這個“行為”服務(wù)的對象，在游戲中通常來說都是玩家，但也有其他情況比如為了方便開發(fā)進(jìn)行的額外編輯器開發(fā)等服務(wù)對象就不屬于玩家。

這樣寫看似比較麻煩，但實際上真正用起來好處也是比較明顯的。首先可以更準(zhǔn)確的傳達(dá)真正的開發(fā)需求，同時“目的”可以讓開發(fā)人員明確為什么要做這個工作，并且這樣寫相當(dāng)于設(shè)定了評估主體和行為，為后期測試提供了一個可測量的標(biāo)準(zhǔn)。

Size: Story Points 關(guān)于工作量預(yù)估

對于工作量的預(yù)估，在敏捷開發(fā)中慣常使用的是Story Points。Story Points是任務(wù)間的工作量比較，而無關(guān)乎實際工作效率（例如團(tuán)隊規(guī)模等），與我們在其他地方見到的比如X人天或Y小時等與具體情況緊密相關(guān)的時間預(yù)估不同，這種預(yù)估方式擁有更強的靈活性，不會因為具體情況的改變導(dǎo)致所有預(yù)估需要重新進(jìn)行。

每個人的工作效率／能力也可以使用 Story Points進(jìn)行評估。比如根據(jù)預(yù)估及實際調(diào)整后可以基本定義人員A的每周工作效率是30點，B是35點等，再據(jù)此評估團(tuán)隊效率，安排這個Sprint中可以放進(jìn)多少點的任務(wù)。在實際工作中，如果有實際工作量超出或少于預(yù)估的情況，我們可以根據(jù)偏移量的統(tǒng)計，判斷項目是否可能延期或提前完成。

在定義Story Points時，我們可以將一個認(rèn)為最小的任務(wù)定義為1，再根據(jù)其他任務(wù)相對于這個任務(wù)的量級評估其余的Story Points。計劃撲克是其中一種團(tuán)隊參與的預(yù)估方法，優(yōu)點是可以最大程度的獲得較準(zhǔn)確的預(yù)估，缺點就是比較耗時。

Planning Poker計劃撲克

簡單來說就是每個人手上有同樣的一沓標(biāo)有數(shù)字的撲克，代表Story Points的點數(shù)。挑選出一個需要討論的Backlog，每人私下選好一張認(rèn)為相對應(yīng)的工作量點數(shù)牌，同時亮出。如若差距不大，則可確定，若差距較大，差距大的幾個人間互相討論理由，再繼續(xù)游戲，直至所有成員基本達(dá)成一致。這個游戲可以幫助有效確定一些不好預(yù)估的任務(wù)，也可以加強團(tuán)隊成員的溝通，解決對潛在的對項目理解不一致的問題。

Burn Down Chart & Velocity Chart

除此之外，燃盡圖和速度表是追蹤開發(fā)效率的兩種方式，坐標(biāo)參數(shù)都分別是Story Points點數(shù)及時間，只是一個是關(guān)注完成速度，一個是關(guān)注工作量還剩多少。

Daily/Weekly Check-in每日站會

敏捷開發(fā)中的一個重要習(xí)慣便是每日站會，通常在每日/每周開始時進(jìn)行，站立執(zhí)行是為了保證匯報盡可能的簡潔及快速。通常來說要求簡短直接的向其余團(tuán)隊成員說明三個問題：

• Did（上個站會后）:“我上周/昨天做了什么”

• Doing（這個站會后）:“我今天/這周要做什么”

• Blockers:“我有沒有遇到什么阻礙/問題”

這些在幫助自己明確計劃的同時，也讓其余成員清楚你的進(jìn)度，如有工作交叉的部分可以及時溝通，同時隱形的壓力會讓你保持高效率，避免無故拖延。

Version Control版本控制

在開發(fā)中，版本控制極為重要，這也是行業(yè)內(nèi)必備項目管理流程，但是作為小白獨立開發(fā)者在早期可能并不會意識到這點。簡單來說版本控制就是隨時將最新無問題的工程文件備份至云端服務(wù)器，所有修改均先在本地進(jìn)行，確認(rèn)無影響工程正常運行的問題后再更新至服務(wù)器。

版本控制由于可以同時開發(fā)極大促進(jìn)了多人合作效率最大化，并使遠(yuǎn)程合作成為可能，出現(xiàn)了問題也可隨時回退至之前的版本。即時是一人獨立開發(fā)，養(yǎng)成使用版本控制的好習(xí)慣也會使開發(fā)更有條理及可控。版本控制可使用的軟件非常多，比如SmartSVN，TortoiseSVN，Github等，服務(wù)器有一些是免費的比如可以在 Assembla 上申請一個服務(wù)器空間或者用 GitLab 配合 Source Tree 使用也是不錯的選擇。

Pipeline 工作流程

歸納整理工作流程圖（包括誰負(fù)責(zé)什么部分）以及技術(shù)流程圖（包括各部分使用的軟件等）能盡快幫助新成員融入了解項目，也能提醒團(tuán)隊成員工作流程。

但在小團(tuán)隊開發(fā)中，個人認(rèn)為最重要的應(yīng)該是資源流程圖了（包括資源命名規(guī)則及存放位置），越早整理，規(guī)范使用可以幫助工程保持有序整潔，避免了越來越龐大的工程因沒有盡早規(guī)范梳理，以致資源混亂卻無從下手的情況。

Build Note 更新筆記 + Bug Report 問題報告 + Playtest 測試

在敏捷開發(fā)中，要養(yǎng)成經(jīng)常Build的好習(xí)慣。（經(jīng)常導(dǎo)出可運行版本）而Build Note即所謂的更新筆記就是每次導(dǎo)出時針對這個版本有哪些更新的內(nèi)容所寫的總結(jié)，有一些類似我們通常在app store中看到的更新附錄。Build Note的愿意圖是提供給QA方便測試的。

然而在小團(tuán)隊中即使我們沒有專職QA，保持良好地撰寫B(tài)uild Note的習(xí)慣依然很有用，因為它幫助我們及時理清我們在上個版本中完成了的內(nèi)容，并給測試提供參考。另外在內(nèi)部使用的Build Note中給一些必要的變更項附加變更意圖是很重要的，因為在長期開發(fā)中有時候會忘記當(dāng)時為什么要修改某個功能，Build Note可以幫助我們記下自己的設(shè)計思路。

在我的Build Note中，我把Bug報告與測試報告也放到了一起，歸檔到每個版本下，再據(jù)此統(tǒng)一更新到Project Plan里。有效利用［Tag（標(biāo)簽）］標(biāo)定每個條目使得檢索變得更為方便，在每次有可玩版本后我都會測試，因此每個Build Note后都跟了一個Playtest的測試報告，根據(jù)測試總結(jié)出一些需要更新或者需求等級高的任務(wù)。同樣地，也可以給根據(jù)測試反饋的任務(wù)需求利用Tag標(biāo)定優(yōu)先級。

開發(fā)后

Retrospective 及時回顧總結(jié)

在每個Sprint完成及結(jié)項后都別忘了花點時間對前段時間的工作或項目進(jìn)行總結(jié)，包括哪些做的好哪些不好的，如何改進(jìn)，并及時對項目進(jìn)行整理，包括源代碼，最終資源及原文件，文檔等。良好的回顧習(xí)慣可以幫助團(tuán)隊進(jìn)步磨合，并且井井有條的工程及資源，文檔等也使日后的更新或者二次開發(fā)變得容易的多?？傊?，未來的你會感謝現(xiàn)在的你的。