進(jìn)度要求
- 第一天上午策劃給出文檔，晚上后端、前端和策劃三方確定配置表的格式。
- 第二天后端給出功能接口，實(shí)現(xiàn)主邏輯。
- 第三天前后端開(kāi)始對(duì)接，在游戲能看到功能主界面。
- 第四天主邏輯暢通，策劃提供正式配置，程序給出自測(cè)版本。
- 第五天策劃驗(yàn)收，修改細(xì)節(jié)。
a) 解放策劃
在新的協(xié)作模式下，我們要求周一到周三程序配置樣板數(shù)據(jù)（還需要監(jiān)督執(zhí)行），策劃只需要確認(rèn)表格式，解釋功能的細(xì)節(jié)。
b) 對(duì)策劃的要求
- 第一天需要給到文檔。
- 第四天需要給到正式配置，在自測(cè)環(huán)節(jié)能確認(rèn)功能的完整性，知道什么細(xì)節(jié)沒(méi)做。
- 第五天能及時(shí)驗(yàn)收。
c) 對(duì)管理的要求
- 閱讀所有功能文檔，知悉功能的實(shí)現(xiàn)方式和難度。
- 及時(shí)察覺(jué)進(jìn)度異常的功能，并且提供協(xié)助。比如周1,3,4都是有明確交付內(nèi)容的，容易察覺(jué)問(wèn)題，周2就需要及時(shí)和下屬溝通、部門之間相互反饋、或者閱讀開(kāi)發(fā)人員的代碼來(lái)了解問(wèn)題。
合版
合版目標(biāo)
- 加快合版時(shí)間。
- 減少合版過(guò)程中的沖突。
- 開(kāi)發(fā)服保持持續(xù)可工作的狀態(tài)。
串行化合版本
- 一個(gè)功能合版完成后另一個(gè)功能才能開(kāi)始合版。
- 合版本的開(kāi)始是提交配置到開(kāi)發(fā)服，結(jié)束是在開(kāi)發(fā)服確認(rèn)功能符合驗(yàn)收要求。
- 合版過(guò)程管理由黃嘉輝、梁增樂(lè)、劉鵬鵬負(fù)責(zé)，他們決定功能能否合版，以及何時(shí)合版。
- 功能需要合版時(shí)，向各自的合版負(fù)責(zé)人申請(qǐng)，確定合版排隊(duì)順序，輪到自己合版時(shí)才能開(kāi)始合版。
- 功能自測(cè)階段，策劃已確認(rèn)功能通暢，即可申請(qǐng)合版，以減少封版當(dāng)天扎堆合版的情況。
- 合版期間（周四晚上-周五晚上），開(kāi)發(fā)服發(fā)車權(quán)限由黃老師控制。其他內(nèi)容在策劃服驗(yàn)證，不可以在開(kāi)發(fā)服發(fā)車。
功能合版流程
- 策劃提交配置表，前后端提交配置表控制文件。
- 后端合并代碼到主干（不提交），生成協(xié)議codec和協(xié)議xml，協(xié)議xml提交到protocol項(xiàng)目的主干。
- 后端清空本地配置，更新svn的配置。
- 前端合并代碼到主干（不提交），用最新的協(xié)議xml重新生成前端協(xié)議。
- 前端清空本地配置，更新svn的配置。
- 前后端啟服聯(lián)調(diào)，三方在本地確認(rèn)功能的完整性和正確性。
- 前后端提交代碼和資源。
- 開(kāi)發(fā)服發(fā)車，三方在開(kāi)發(fā)服確認(rèn)功能的完整性和正確性。
- 交給策劃驗(yàn)收負(fù)責(zé)人驗(yàn)收。
驗(yàn)收
驗(yàn)收注意事項(xiàng)
- 合版時(shí)間盡可能提前。
- 程序要保證自測(cè)版本的質(zhì)量，尤其界面排版等細(xì)節(jié)問(wèn)題。
- 策劃要保證優(yōu)化反饋文檔的完整性，盡可能一次指出所有問(wèn)題，不要一次給一點(diǎn)優(yōu)化。
- 策劃優(yōu)化反饋文檔用svn管理，每一批優(yōu)化都是一個(gè)excel sheet，功能不通的反饋需要特殊標(biāo)記。優(yōu)化的批次數(shù)和功能不通的反饋數(shù)會(huì)作為大家工作質(zhì)量的評(píng)估資料。
- 驗(yàn)收當(dāng)天中午黃嘉輝、梁增樂(lè)、劉鵬鵬需要了解各功能的優(yōu)化進(jìn)度，以評(píng)估封版時(shí)間，決定是否需要協(xié)助。
- 很難修復(fù)的bug和優(yōu)化暫緩，先把其他內(nèi)容提交給策劃驗(yàn)收，盡可能不影響合版和驗(yàn)收負(fù)責(zé)人驗(yàn)收。
- 如遇開(kāi)發(fā)服掛了的情況，可以申請(qǐng)驗(yàn)收負(fù)責(zé)人在本地體驗(yàn)功能，提優(yōu)化。但是最終的驗(yàn)收需要在開(kāi)發(fā)服進(jìn)行。
