NO IMAGE

作者:羅聰翼
很感謝作者的分享,也希望他的敏捷開發實踐經驗以及使用禪道做遊戲開發專案管理的規範能對大家的專案管理有所啟發。

目錄

一,劃邊界

柳傳志總結過3句企業要素,“搭班子、定戰略、帶隊伍”,其中兩大要素就是和人有關:搭班子和帶隊伍,知易行難,是科學更是藝術。實踐中每個人對事的理解不一,例如專案的目標和結算在老闆和員工心目中也是不一樣的,管理者看結果,專業的事情留給實踐者,而引導員工如何落地就一定要重過程。

整理一下,啟動一個專案的第一步就是立項,如何確定產品的方向和目標,如何把控專案進度,如何驅動產品迭代,以及如何調動團隊積極性等。去年在團隊上最深刻的反思,就是“和程式作鬥爭,而不要和程式設計師作鬥爭”。

3大要素也適用於過程,立項是基於產品去明確目標,而落地則是基於時間來考慮過程,同樣包含5 個關鍵步驟:選方向、定目標、控進度、帶團隊和排干擾。

1,方向

6年前從加入初創公司踏入了創業之路,那時我們的模式很原始很作坊,一切立項都是幾個人坐下來各自描述心中的想法,當一個點子獲得認可,大家一拍腦袋,“我靠這事靠譜!做出來一定呲皮!”,緊接著就挽起袖子開幹。

那時手機遊戲沒現在這麼複雜,4個人1個月就能做出一款3D遊戲,完成後上傳商店,默默的盼望點選和下載量爆漲,大部分結果最後都證明草率的立項只會是大家的一廂情願,心中的那股情懷也在這種不斷被現實打臉的過程中消失殆盡。

15年開始再做產品時,我們總結了之前的經驗,開始嘗試花掉6個月的時間去調研和思考方向,其中3個月會做各種各樣的Demo,一切妥當之後才會搭弓上箭,3個月做出第一版,上線驗證開始迭代。所以,方向成為了整個專案中最重要的一件事,無論是基於產品,還是基於過程。

為產品定方向,基本上是在考驗創業的領導人和你對合夥人的認識,無論是經典常用的SWOT還是5W2H分析,產品定方向是啟動一切之前最大的賭注。這裡我不做展開,先將視角迴歸在過程,起碼需要團隊坐下來討論並同步這麼幾個事情:

  • 方向和願景:用最簡單通俗的語言描述產品的價值
  • 機會和趨勢:不管市場是紅還是藍,瞭解對手甚至BAT為什麼做或者為什麼不做,明白了縫在哪,然後才知道怎麼去拼
  • 使用者畫像和使用者需求:針對使用者談價值需求,例如聊天記錄可以同步到雲能方便使用者切換使用場景,不一定提商業價值,例如使用者可以加入會員提升同步上限
  • 已知的解決方案和機會:我們和隔壁的公司和隔壁的隔壁的公司都在做這件事,那麼優勢是什麼
  • 團隊的利益點:明確大家的優勢和做完之後收穫的成長和利益,不僅僅包括分錢
  • 團隊的弱點:提出問題和困難,預估一些需要眾人去啃的硬骨頭
  • 時間結點:市場和資源的時間結點在哪,決定了大家手上的船票登上的是艘大船還是小船,還是自己划水跟著船前進
  • 上線計劃:對遊戲有封測、內測和公測,對APP呢,比如開個釋出會
  • 核心衡量指標:成不成總要有個依據來支撐專案前進,使用者量?流水?企業估值?

2,目標

也許是和外企的經歷有關,以前我對目標的認識就是KPI(Key Performance Indicator/關鍵績效指標),可完整可量化的業績指標(基於SMART)。在實踐中,我不斷思考以何種形式來將目標量化,例如程式碼質量是否可量化,記憶體調優是否可量化,相容性測試是否可量化,美術資源壓縮優化是否可量化,這個思維影響了我很長一段時間,回顧看看,發現自己一直奔波在過度依賴理性資料來執行判斷。

幾個月前和HR聊到目標時,他給了我另外一個思路,PBC(Personal Business Commitment/個人事業承諾),相比KPI,更適用於一些難以量化的場景,特別是針對研發這樣輸出價值難以量化的物件。前者是自上而下的目標分解,而後者是在理解目標之後自下而上的主動承諾。當一件事呈現雙向性的時候,不管你在團隊中處於什麼樣的角色,資訊都能實現同步的傳達,一線工程師不會和產品總監的當前工作計劃產生隔離,團隊就不會那麼容易產生跑偏和脫節。

換而言之,實現目標達成的最佳工具和手段,就是去掉溝通的障礙,降低通達的成本。有個驗證團隊是否擁有一致目標的方法,你問一個團隊負責人他某一個下屬的工作職責是什麼,不多不少就3條,他說完後你記下來,接著你去問這位下屬,你的工作職責是什麼,也是3條,完了兩邊一對,如果內容不一致,那麼團隊的溝通在目標達成上一定存在問題。這個方法我屢試不爽。

這種繼承式目標加關鍵結果導向的方式,實際上剛好匹配了Google的OKR(Objectives and Key Results/目標與關鍵成果)模式,它驅動了Google從40人發展到40000人,且大而有序。

3,控進度

以前做單機遊戲,左手邊坐的策劃,右手邊坐的主程,3個人有問題隨時轉頭。當後來開始牽頭網遊專案,團隊從3個人一下擴張到20人,算上運營和客服,小30個人的團隊,此刻傳統的溝通方式和協同就出現了大量的問題。資訊不同步,需求和缺陷的雜糅,版本管理混亂到無法回滾,根源其實就是進度的失控。

複雜龐大的專案執行起來最重要的一環就是控制進度,藉助SCRUM思路來指導,實踐中採用包括將單Sprint細分為2周,每天強調溝通的站立會,目標都是在確保每個環節都能可控,但資訊流是龐大的,一旦有產品上線,在研版本和線上版本,反饋需求和運營需求,產品計劃和市場計劃,客服追蹤和巡檢測試,如果一切都需要靠手動和人腦去關聯,會崩潰的。

流程中因為有了階段劃分,就一定會有檢查點,不論是里程碑的釋出,還是研發階段性接入進入調優階段,持續和梯度改進才能體現迭代的意義。

4,帶團隊

我曾嘗試去這樣假設,如果一個專案團隊是因為發起人或者精神領袖的個人光環而凝聚在一起,一旦這個人離去,這個專案會怎麼辦?

為了驗證,我實踐了這個假設,對於一個初創型的團隊,完全去中心化真的是作死。我嘗試用規則來穩定和平衡,但事實證明,相同的價值觀和緣分是讓團隊凝聚起來的首要前提,否則小團隊這般,未來如何才能大而有序?

SCRUM中強調的一點是主動和自覺,包括任務都應該是自由領取而非強制指派,構建小而美的團隊不能僅僅只靠核心團隊,否則這是在人為的在團隊中劃成了兩派,一派核心成員為了理想和目標奮鬥,一派成員就是打工心態,這樣的團隊很難成事。

團隊的成員結構也造就了團隊的獨特,在初創階段還不可能使用大規模團隊的管理方式,所以需要結合實際情況找到最佳的迭代節奏,先慢後快,還是先緊後鬆,一切都需要根據實際情況來調整。

當前幾個迭代跑動順利之後,專案的許可權就需要開始逐步下放,例如專案經理就需要成長為Scrum Master,產品經理細分到產品甚至成為模組的Owner,團隊成員從team member到team leader的成長,需求的拆分由技術主管交棒給團隊成員,至於之前提到的考核,也可以化零為整,調整為團隊的共進退,而不是個人的獨立考核。

敏捷不提倡單兵英雄主義,但一定需要給到團隊反饋和信心,所以有幾個會議需要在過程中強調議程和參與者,包括站立溝通會,需求完成後的演示會議,覆盤總結會,提高團隊的參與感和成就感。

5,排干擾

干擾來自於各方面,包括:優先且緊急,不優先且緊急,優先且不緊急,不優先不緊急。當發現團隊忙的昏天黑地,但成績卻十分緩慢或者依然存在大量延期,大可回頭看看規劃過程時,是不是在將有限的兵力去實現無意義或者並不是最重要的任務。

舉個栗子,老闆有一天走過來,說我需要做個什麼巴拉巴拉,你看這麼重要的事情,儘快完成!有時這種指令的傳達會出現多頭管理,那就是其實本來大家都清楚時間不夠了,但因為這是老闆說的,所以研發人員有時會自告奮勇地表現一下,沒問題可以加!然後偷偷調整了開發計劃。專案經理聽到就不幹了,說這樣計劃就不對了,但員工說這是老闆要求的,專案經理就去找老闆理論,老闆說既然你來了那就你來安排吧,專案經理說做可以,請等待N周,老闆不幹了說你太不重視我需求了!吵著吵著,專案經理離職了,掙了表現的員工因為專案延期也沒撈到什麼好處。別笑,這栗子還真事,成都某幼教產品團隊,老闆和產品經理是夫妻,專案經理乾的裡外不是人,庫房裡產品堆積如山,據說2016年的目標是響應國家號召:去庫存。

元旦前我面試了一位應聘者,她在某財務軟體公司任職期間負責研發團隊的QA工作,她有個思路我很贊同,那就是將需求的價值和人力的投入估算出研發的ROI(Return On Investment/投資回報率),用於評估研發的價效比,當然引數還包括了時間成本等。之前她就發現團隊效率特別低,之後開始找原因,發現產品需求來源於深圳公司,人員協同靠遠端,因為成都這邊只是研發團隊,上一個需求還沒消化,下一個需求又來了,有時需求專業度較高,還得從深圳派行業專家過來給程式設計師培訓!當初選擇在成都建研發中心是理解這邊人員成本低,可是納入公式後發現,同樣的成本去深圳少僱傭幾個貴的程式設計師,研發週期反而更短,最終成研所在ROI面前完敗,整體部門被裁掉。

這兩個小例子,其實都是希望證明一點,小而美的團隊需要更緊密的協作和更一致高效的步伐,管理者的心態需要轉變為服務者,需求的歸口和權利的下方應該提前約定。敏捷不是不接受變更和插入,而是需要協調一個共同認可的方式進行。一個專案經理最厲害的時候就是這個團隊不需要你了,作為Scrum Master應發揮的是教練角色,而不是保姆角色,這樣才能構建一個有自我組織的團隊。

二,實施

敏捷開發宣言告示了我們將思路付諸實踐的重點:

部署實施敏捷其實有很多方式,藉助部署指南,最傳統的方式是卡片和看板,藉助溝通來完善專案燃盡,評估方式還有打估算撲克這種神器。選定方案前摸索了大量工具,我試用過worktile,project,redmine,灰狐協作,Jira(最難用沒有之一),tower,最終選擇了禪道

接下來,就分享下經歷了3年反覆修訂的敏捷實踐吧(終於可以祭出這張圖了 ¯\_(ツ)_/¯)

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的複核測試,流程如下: