GoodTeamStudio使用禪道做游戲開發項目管理的規范說明分享

2016-11-02 15:53:00
先知
原創
5519

GoodTeam Studio是成都的一家游戲開發商,2009年初開始創業,是國內最早的Android游戲開發團隊之一。

GoodTeam Studio官網: http://www.gts8.com/c1-Game/GTS-Game.html


以下是 GoodTeam Studio使用禪道做游戲開發所做的一些規范說明。

作者羅聰 翼。

很感謝作者的分享,也希望 GoodTeam Studio使用禪道做游戲開發的經驗能對大家的項目管理有所啟發。


GoodTeam Studio禪道項目管理說明書

1. 概述

1.1. 文檔目的

游戲在開發過程中需要考慮的項目管理流程,包括立項計劃,需求分析,項目排期安排,里程碑版本分拆,發布計劃,項目中的任務分解,版本出包管理,出包與測試配合,凍結功能后版本協同,基于版本和測試用例的測試任務協同,開發與運維的版本協同,配置文件的管理。

本套流程將使用禪道作為線上協同工具,其他工具功能類似,此處僅舉例演示。

1.2. 定義/縮寫

PRODUCT – 產品

PROJECT – 項目

S – STORY – 需求

T – TASK任務

TC – TEST CASE – 測試用例

TT – TTEST TASK – 測試任務

BUG – 缺陷

BUILD – 版本

DEBUG – 開發中的測試版本

RC – RELEASE CANDIDATE - 待發布版本

TRUNK – 最后的發布線上版本

QA – QUALITY ASSURANCE - 品質保證

QC – QUALITY CONTROL – 品質控制

2. 命名規范

在開發階段和上線階段,版本的命名應該有所區別。

2.1. 語言命名規范

對于不同語言,版本定義不受影響,唯一的變化是命名中的語言標示符,例如ARDCN_DEBUG_20130324表示安卓中文版,而對應具有相同功能的英文版本命名則為ARDEN_DEBUG_20130324。

2.2. 包命名規范

對于處于開發階段,包命名基于項目,以打包時間來定義包名,并附加DEBUG作為開發版本標示,用日期為數字結尾。

例如ARDCN_DEBUG_20130324(01)表示在2013年3月24日打的第1個安卓中文開發包。當開發完成打包操作后,禪道需要建立對應的項目版本,并關聯該包完成開發的需求,或者已經解決的BUG。

如果即將進入上線階段,版本開發已經封閉功能,不再增加新的功能而只是修改BUG和調優,那么版本命名將修改為RC版本。

例如ARDCN_RC_20130324(02),表示為在2013年3月24日打的第2個安卓中文待發布包。這里的包開發進度會進入快速迭代的狀態,直到版本穩定可用于提交發布。

3. 開發流程和周期

3.1. 開發流程

當版本通過測試可以上線后,那么該項目的最終版本將作為TRUNK版本建立在產品的里程碑上。

具體開發路線基于敏捷開發(SCRUM)設計,流程圖如下圖:

3.2. 開發周期

開發周期按照上線狀態分為未上線開發期和在線版本開發期,如果按照需求來分,則以里程碑階段來劃分開發期。例如,在未上線階段,可以使用快速迭代(SPRINT )的開發方式,以周為單位,在進入上線階段后,可以使用長期項目,不超過4周。

3.3. 短期迭代中的版本管理

在短期快速迭代中,禪道項目以小標示為主要開發節奏,例如1.1.0和1.1.1,每個版本僅用于BUG修復、優化和小功能更新,因此產品需要快速開啟禪道項目,可能會出現只有RC版本而沒有DEBUG版本的項目。

短期迭代需要嚴格控制版本的建立和BUG的指派,避免出現垮版本后開發內容和測試內容復核脫節。

3.4. 長期項目中的版本管理

對于大版本開發,禪道項目以大功能為開發節奏,時間可以以多周計或者以上線更新為標準,例如1.1.2和1.2.0。那么這里的版本任務將以導入的方式新增,因為一個需求可能需要在多項目之間做長期開發和調試。

4. 項目角色

基于禪道對項目負責人的責任劃分,包括以下幾種


版本的管理統一歸口產品經理,統一整理版本號和命名規范,并在打包前將配置更新至SVN,策劃和運營需配合,同時告知研發主管打包復核。

5.1. 開發計劃和版本的建立

版本由產品經理和項目經理討論后,確定開發計劃(PLAN)和開發版本(PROJECT)的關聯,開發計劃和項目的關系如下圖。

而其中,每個版本的開發需求也將會由產品經理根據策劃文檔和技術評估,參考工作量和版本計劃,分別關聯在對應的版本中。

這里計劃應該先于版本創建,所以當為指定版本關聯需求的時候,需求將自動關聯至計劃中。

5.2. 里程碑版本的建立

當一個項目階段完成后,需要創建里程碑版本(RELEASE),其中包含客戶端、服務器端和資源包。版本的打包控制和存包控制主要由服務器端主程執行,其中文件名規范同文件命名,由產品經理和項目經理確認復核。

配置目錄范例詳見下表:

需求( USER STORY)的創建和關聯由產品經理負責,全部需求統稱為產品的需求集(PRODUCT BACKLOG),當產品經理完成對需求的整理后,具體需求的補充和文檔描述由項目經理負責。而被關聯至對應項目中的需求,將成為該項目的需求集(SPRINT BACKLOG)。

6. 需求管理

6.1. 需求的創建

需求可以分為以下幾類:

1. 基于單個項目周期的需求

2. 基于多個項目周期的需求

3. 基于BUG反饋后新增的需求

4. 基于臨時功能調整后變更的需求

這里,前兩種需求均為固定設計的需求,在產品設計的初期就已經完成了創建,并且可以根據項目的版本計劃做排期關聯。

6.2. 需求的狀態

需求基于產品的設計和版本計劃,所以在創建需求的時候不需要考慮具體實現細節,所有的需求在根據計劃和版本錄入完畢后,再進入需求的設計和指派。需求的創建具體流程如下。

匯總需求的狀態總共有四種狀態,分別是草稿(DRAFT)、激活(ACTIVE)、已變更(CHANGED)和已關閉(CLOSED)。對應為需求的流程操作共有:創建(CREATE)、變更(CHANGE)、審核(REVIEW)、關閉(CLOSE)、激活(ACTIVE)。

其中,如果拒絕需求的評審,需要說明理由或是否滿足以下情況

1. 不是BUG

2. 已完成

3. 已細分

4. 重復

5. 延期

6. 不做

7. 取消

8. 設計如此

最終,流程圖如下:

6.3. 需求的階段

需求的階段屬性是用于描述需求的關聯關系,它可以被手動修改的,但是除了驗收階段需要手動操作,其他階段內狀態都會根據關聯情況自動更新的。其中


需求的階段主要用于輔助產品經理對不同階段下需求的復核狀態做確認,所以總的來說,需求的完整流程如下(這里計劃不是必選項,因為計劃是選擇性創建的)

6.4. 需求的變更

需求如果在經過評審后需要做變更,那么需求的狀態將會被修改為草稿,只有當需求評審再次通過之后,才能被激活進入開發階段。但是需求變更會影響基于需求創建的任務和用例,那么變更流程如下

6.5. 需求的編寫

需求描述可以參考INVEST原則,具體為INDEPENDENT, NEGOTIABLE, VALUABLE, ESTIMABLE, SMALL, TESTABLE,其中:

獨立性(INDEPENDENT): 要盡可能的讓一個需求獨立于其他的需求。需求之間的依賴使得制定計劃,確定優先級,工作量估算都變得很困難。通常我們可以通過組合需求和分解需求來減少依賴性。

可協商性(NEGOTIABLE): 一個需求的內容要是可以協商的,需求不是合同。一個需求卡片上只是對需求的一個簡短的描述,不包括太多的細節。具體的細節在溝通階段產出。一個需求卡帶有了太多的細節,實際上限制了和用戶的溝通。

有價值(VALUABLE): 每個需求必須對客戶具有價值(無論是用戶還是購買方)。一個讓需求有價值的好方法是讓客戶來寫下它們。一旦一個客戶意識到這是一個需求并不是一個契約而且可以進行協商的時候,他們將非常樂意寫下需求。

可以估算性(ESTIMABLE):開發團隊需要去估計一個需求以便確定優先級,工作量,安排計劃。但是讓開發者難以估計需求的問題來自:對于領域知識的缺乏(這種情況下需要更多的溝通),或者需求太大了(這時需要把需求切分成小些的)。

短小(SMALL): 一個好的需求在工作量上要盡量短小,最好不要超過10個理想人/天的工作量,至少要確保的是在一個迭代(SPRINT)中能夠完成。需求越大,在安排計劃,工作量估算等方面的風險就會越大。

可測試性(TESTABLE):一個需求要是可以測試的,以便于確認它是可以完成的。如果一個需求不能夠測試,那么你就無法知道它什么時候可以完成。

7. 項目管理

當需求被分拆至項目之后,項目負責人包括開發團隊需要和產品經理一同進入需求的細分和項目的開發,這里的團隊參與很重要,切勿由產品經理代做需求拆分。

7.1. 需求拆分為任務

當需求已經和項目關聯完成后,項目負責人或產品主管需要和項目團隊開展需求演示會(由需求發起者對需求做說明),并由開發人員做技術評估,評估完成后即可對需求進行任務的拆分。需求拆分中,需要考慮以下幾個方面:

1. 任務的分解按照任務類型來分解,例如開發、測試、美術甚至部署環境等。

2. 同類型的任務分解以指派負責人為主。

3. 分解任務盡量保證可以在幾個小時內完成,方便追蹤。

4. 分解任務時,需要基本確定開發周期,需要資源。

7.2. 任務的指派和完成

當進入任務流程中,項目負責人或產品主管需要配合開發人員完成任務的開發,同時給出需求的復核反饋,其中對應流程如下

其中,任務在創建至結束的狀態流程如下

這里的版本提交和測試提交分別詳見后面的描述。

8. 版本管理

8.1. 項目階段性版本

在階段開發完成后,需要打包建立版本之前,由項目負責人(即策劃)提交該版本的需求發布方案,由項目負責人確認版本的完成內容,并且完成第一個版本。這里的打包內容包含已經完成的需求(如果需求分解的任務全部完成,則需求狀態將自動更新為已完成)和在該版本中修改的BUG。

當開發打出產品第一個項目的第一個APK包時,禪道上需要建立對應項目中的版本,該版本僅用于關聯該版本在此項目中完成的需求。在后面的版本中,需要關聯該版本包已經解決的BUG,包括測試已經確認和未測試(需要通過對打出的APK包驗證后才能確認)。

作為項目的第一個版本,其中在開發中不會產生BUG,那么打包流程包含如下:

其中,已完成的需求將自動被關聯至BUILD頁面中,而部分完成的需求可以手動選擇關聯,但未完成的需求,則不應該關聯至打包BUILD中。

建立版本之后,需要將該版本提交測試進行測試用例的關聯和測試,測試人員需要將發現的全部BUG匯報在對應的測試用例上,并且關聯對應的BUG、需求和任務。開發人員在接到BUG反饋后,可以快速定位開發階段內的代碼COMMIT時間,進入BUG修復階段。例如已經打出的版本是ARDCN_DEBUG_20130324(01),那么測試的BUG需要全部關聯在這個版本上。

當提交測試執行BUG修復,或者增加新的需求之后,DEBUG_BUILD02在打包的過程中,除了需要包含之前存在BUG的需求,還需要包含基于BUILD01的BUG。這里包的命名需要根據時間遞增做調整,如果是當天的多個包,那么命名即為ARDCN_DEBUG_20130324(02)。該版本將作為下一個測試任務提交測試。

打包流程如下:

其中,已經完成并且復核無Bug的需求,就不需要關聯到當前DEBUG版本中了,如果在上一個需求中報出的BUG已經被修復,那么就需要關聯至當前BUILD中做測試驗證。

DEBUG已經結束全部需求開發后,版本將更改為RC版本,主要針對發布前的BUG修復,其中,打包流程如下:

當版本作為TRUNK結束此階段的項目開發后,測試需要將新增的BUG報到下一個項目中,并且將版本指派給TRUNK。

8.2. 產品里程碑版本

產品的里程碑版本是指某一個項目階段性結束,或者是以新版本發布為時間點所建立的版本。以禪道為例,該版本直接建立在產品視圖下,以對應完成項目中得最后一個版本為基礎版本,使用選擇調用的方式,將其作為階段性的TRUNK版本。

其中, 所有在V1.0.1開發過程中產生的BUG都不會作為發布項目關聯至最終產品發布版本。同時所有已發布的需求將在建立發布之后,自動修改狀態為已發布。

需求是否需要關閉由產品經理在版本發布后,手動執行關閉操作即可。同時,在完成里程碑版本建立之后,產品經理需要建立或啟動下一個階段的開發項目,同時在開發端需要對代碼做階段性備份。

9. 測試管理

測試人員(TEST)即QC的主要工作是協助策劃根據策劃文檔撰寫測試用例,并驗證開發提交的結果是否符合策劃的設計預期,而品控人員(QA)則集中在最終游戲的品質,以維護公司的規范和指標為重要工作依據,那么將兩者做對比如下:


9.1.
用例管理 與開發相結合的主要為QC測試人員,QA流程另行規范。

在需求被創建之后,測試就需要為對應的需求創建測試用例。其中測試用例的依據是策劃文檔,用例的創建流程如下

其中,只有當需求通過評審后,才能創建測試用例,用例直接基于需求做分解。

9.2. 測試任務管理

在項目創建第一個版本后,項目主管需要將其以測試任務(TEST TASK)的方式提交測試,測試人員接到測試任務之后,除了關聯對應需求的測試用例(TEST CASE)至該測試任務之外,還需要關聯或者創建新的專項測試用例,用于完成測試任務中的額外需求描述。

其中,測試人員在得到測試任務后,除了選擇對應需求和對應需求產生BUG的測試用例關聯外,還需要考慮其他特殊的測試用例,例如為單獨BUG創建的測試用例,以及用于性能適配等創建的特殊用例。

當測試任務創建完成之后,測試人員將啟動測試任務,并逐條執行測試用例,了其中測試用例的執行流程如下:

其中,用例執行的三種結果

1. 通過:用例執行后結果和期望相符,保存用例結果即可。

2. 阻塞:當用例執行的前提條件無法滿足時,用例無法繼續執行,則需要標記為阻塞。

3. 失敗:用例執行后結果和期望不符,需要在結果中提交對應的錯誤描述,保存后再頁面上給出具體問題描述。

當全部用例均執行結束后,測試人員則填寫對應備注然后關閉測試任務即可。

9.3. BUG 管理

在測試人員按照測試用例做測試驗收的時候,如果測試結果和預期不符,那么測試需要將其作為BUG報給項目,并關聯對應的需求或任務。

由于測試任務和需求以及BUG都事先做了關聯,那么在填寫BUG內容時,需要手動補充完善的內容包括:

1. 模塊名稱:用于定位BUG位于產品的具體位置

2. 當前指派者:BUG統一指派給項目經理即策劃

3. 標題填寫:標題使用如下模板【版本號】需求標題-問題描述,例如【1.1.0】發布商城數據-完成后返回錯誤頁面

4. 重現步驟補充:如果重現步驟和測試用例的描述有區別,這里需要做步驟的補充,同時給出必要的截圖

5. 相關任務:可選補充,關聯對應需求下分解的任務

6. 類型和嚴重程度:BUG類型包括代碼錯誤、界面錯誤、設計缺陷、配置相關、部署問題、安全問題、性能問題、適配問題、音樂音效等,嚴重程度;

如果提出的BUG不是基于測試用例,那么需要在填寫BUG詳情的時候手動補充全部關聯信息。

提交BUG后的解決流程如下:

其中,測試需要先提交給項目經理即策劃做評估,如果屬于可修復BUG則指派給對應的服務端、客戶端開發或美術,由開發做修復并提交計劃至下一個BUILD中。如果該BUG屬于新的功能需求,或者不能使用修復的方式解決,則執行轉需求操作,并轉入新建需求的流程中。如果不屬于BUG,那么項目經理即策劃將給出設計如此的反饋說明,指派回測試人員即可。

如果該BUG需要新的測試角度進行專項測試,那么在BUG指派開發的同時,則需要項目經理通知測試撰寫對應的專項測試用例,這里建立的過程將自動關聯BUG本身。

BUG被修復后,開發人員需要在指派回測試人員的同時,填寫為解決該BUG所創建的版本號(該BUILD可以提前創建但是不做內容關聯,這里的版本創建流程禪道可能會在未來做一定調整),以及該對應的解決方案,其中包括:

1. 設計如此:該缺陷或問題屬于設計范圍,解決確認由項目經理在確認前給出。

2. 重復BUG:可能存在多名測試人員報出同樣問題的BUG,那么關閉的同時需要給出重復BUG的ID。

3. 外部原因:由于斷電斷網等外部原因導致的BUG,如果設計者認為這屬于非開發可解決的問題,那么可以選擇該理由解決BUG,并且以新的需求等方式提出解決方案。

4. 已解決:通用的解決方案,需要注明大致的解決方案。

5. 無法重現:在測試的描述不清等情況下,開發人員無法通過重現步驟復現該BUG,那么可以選擇該解決方案理由將BUG指派給提出該BUG的測試人員,由測試人員重新提交復現步驟。

6. 延期處理:如果該BUG不屬于該項目內可解決的范圍,或者屬于下一個版本的開發計劃,可以選擇該方案回復。該BUG將在未來創建項目的時候,以導入的方式成為新項目的開發任務。

7. 不予解決:如果項目經理即策劃或開發均評估任務該BUG不需要做修復,包括修復成本過高,設計上處于可接受范疇等情況,可以選擇不予解決的方案回復。

那么當全部BUG都被標識解決之后,新的版本將會被執行打包發布,測試人員基于該新版本對BUG做驗證測試,如果已經完全修復,測試人員即可選擇關閉該BUG,否則打回開發人員重新修復,流程如下:

其中,在創建版本的時候,需要復核所有基于上一個版本提出的BUG修復狀態,而復測需要在創建新的版本后做復測,復測完成后才能關閉,如果測試未通過,則需要激活并指派回項目經理。

10. 未完成任務和BUG管理

當一個版本完成開發之后,可能會依然存在沒有完成的任務或者暫時沒有修復的BUG,那么在項目經理創建下一個項目的時候,則需要將這些未完成任務和BUG重新導入至新的項目中,并由系統自動將對應的需求也關聯在一起。

11. 版本對應的 SVN管理

11.1. 打包成果的SVN管理

當版本處于開發階段時,版本號也是以DEBUG為標示打包時,需要將所有包打包存放在SVN上的DEBUG目錄下。當需要進入發布測試階段時,需要將包存放在SVN上的RC目錄下。當測試全部通過,那么主程需要將最后一個RC包復制到PUB目錄,并且提交給運維和市場部,用于服務器端發布和客戶端升級。具體存放規則如下:

其中不同語言包的打包管理放置在同成果目錄下即可,只需要按照語言和打包需求重命名文件夾。

11.2. 版本配置文件的SVN管理

由于開發版本和線上版本的區別,DEBUG、RC和TRUNK版本在配置文件上需要做區分。

在DEBUG和RC版本中,打包主要用于驗證需求開發,而不需要做線上的維護,因此版本配置文件管理需要主要集中在游戲本身的配置文件,多個版本之間可以不增加VERSION CODE 和資源版本號等文件。而打包對應表需要保存DEBUG和RC打包成果的對應關系。

在TRUNK正式 版本更新中,由于打包主要用于更新線上版本,因此版本號和資源包等需要基于線上的版本做自增加,同時版本記錄由統一的文檔管理,存放在PUB目錄下。而打包對應表則需要保存RC和PUB打包成果的對應關系。

12. 執行流程

12.1. 產品經理

產品經理創建產品,產品命名使用” 【類型】產品名_平臺語言” ,例如【研發】我是海盜王_安卓中文,計劃命名使用”上線類型幾期”,例如”刪檔內測1期”,其流程如下:

產品經理提出需求,需求命名為動名詞,例如調整對話框的樣式,其流程如下:

當開發和測試都完成,并且發布的RC版本達到上限要求后,產品經理會執行發布流程,命名模板為”版本名稱_版本 “,例如ARDCN_CB1.0.1,流程如下:

在完成上一個項目之后,產品經理需要創建新的項目,并且導入未完成的BUG和任務,流程如下:

12.2. 項目經理

項目經理由策劃擔任,其完善需求的流程如下:

當評審通過后,項目經理需要和團隊一起開啟需求分析會,并拆分需求,流程如下:

其中,任務標題模板使用”【類型】需求-任務描述”,其中類型中,開發使用【R】,策劃使用【D】,美術使用【A】,例如【R】主城界面-添加旗幟飄揚效果。

當開發完成并且已經進入測試后,項目經理需要和測試共同配合驗證需求和任務的完成情況,流程如下:

所有的BUG都會由測試人員統一錄入后指派給項目經理,處理流程如下:

12.3. 開發主管

開發主管為任務的第一接收人,由主程或主美擔任。在接到任務后,其對任務的工作流程如下:

當開發完成后,任務會指派回來,開發主管需要對任務和完成情況做驗收,流程如下:

當全部開發任務都完成后,需要進行版本創建,命名模板為”版本類型版本號_日期“,其中版本類型包括DEBUG和RC,例如”DEBUG1.1.4_20140401”, 由主程創建版本,流程如下:

版本創建完成后,需要以測試任務的方式提交測試,測試任務命名模板為“版本號 測試類型“,例如“DEBUG1.1.4_20140408 功能測試”或“RC1.1.4_20140409回歸測試”,提交測試任務流程如下:

當測試提出BUG后,由項目主管執行BUG分發,接收后處理流程如下:

12.4. 開發人員

開發人員在接到任務后,執行任務流程如下:

在出現BUG的情況下,BUG會由開發主管指派過來,處理流程如下:

12.5. 測試人員

測試人員在需求立項之后,需要根據需求創建測試用例,用例標題命名模板為” 需求-測試目的”,例如主界面-角色信息驗證測試,創建用例流程如下:

測試人員在接到測試任務后,需要將對應的測試任務關聯上去并執行測試,如果測試用例對應的需求有變更,還需要更新測試用例,流程如下:


當測試發現錯誤或問題后,需要報BUG ,標題模板為 【版本號】需求名稱 - 錯誤描述,如【 1.1.0 】玩家封號 - 查詢玩家報錯,報 BUG 流程如下:

當開發完成了對BUG 的修復后,開發主管會重新打包,提交的測試任務中會包含之前報上去的 BUG ,此時測試對新版本不僅要完成新增需求的測試,還要完成 BUG 的復核測試,流程如下:




發表評論
評論通過審核后顯示。
文章分類
聯系我們

聯系人:魏中顯

電話:18561939726

Email:[email protected]

QQ:1746749398

地址:青島開發區長江路232號國貿中心C座2單元2902室

聯系人:徐賀

電話:15216484215

Email:[email protected]

QQ:1492153927

地址:青島開發區長江路232號國貿中心C座2單元2902室

聯系人:徐賀

電話:13730922971

Email:[email protected]

QQ:2845263372

地址:青島開發區長江路232號國貿中心C座2單元2902室

聯系人:孫良宇

電話:13165056632

Email:[email protected]

QQ:3137772959

地址:青島開發區長江路232號國貿中心C座2單元2902室

聯系人:徐亞京

電話:17663982076

Email:[email protected]

QQ:2679672214

地址:青島開發區長江路232號國貿中心C座2單元2902室

聯系人:劉斌

電話:17685869372

Email:[email protected]

QQ:526288068

地址:青島開發區長江路232號國貿中心C座2單元2902室

云禪道

云端的項目管理軟件

尊享禪道項目軟件收費版功能

無需維護,隨時隨地協同辦公

內置subversion和git源碼管理

每天備份,隨時轉為私有部署

免費試用
三肖中特期准黄大仙373745