項目管理及發(fā)布規(guī)范

1、項目管理及發(fā)布規(guī)范(gb2011-001)麥網(wǎng)開發(fā)部2011 年 5 月 10 h修訂歷史記錄日期版本說明撰敘2011 年 05 月 1 0 hvi.0編制，制定基本規(guī)范張濤項目開發(fā)管理綜述1、項目基本流程圖一 prd項目開發(fā)流程流程名稱參與人員說明prd review產(chǎn)品經(jīng)理prd review jn,如果仍有較多問題，需要2、流程角色及說明開發(fā)組負責人 開發(fā)品管產(chǎn)吊經(jīng)理修改丿訐，垂新revicwo如果基本 通過，調(diào)整后直接給開發(fā)組做分析與初步 設計，存入開發(fā)項目的文檔中。這時prd 版本，暫不發(fā)給測試部備案。prd分析及erd初 步設計項h負責人prd review后，項忖負責人對prd做

2、全面 分析，對發(fā)現(xiàn)的prd問題做回歸討論和修 改。同時對每一個需求點的實現(xiàn)方法做初 步erd設計。prd分析完畢后,將prd文 檔發(fā)給測試部歸檔。prd分析應當解決所 冇不確定的因素，確保開發(fā)過程中不會因 為prd問題而中斷。制定開發(fā)計劃項1丨負責人對prd分析的結(jié)果，將系統(tǒng)分模塊制定開 發(fā)計劃。開發(fā)計劃應包含erd詳細設計、 erdreview、開發(fā)、內(nèi)測、code review、 部署文檔編制及部署測試等時間。erd詳細設計項目負責人erdreview項目負責人、開發(fā)品管內(nèi)測 % codereview項目負責人開發(fā)完成后，由開發(fā)負責人、團隊成員進 行全面交叉內(nèi)部測試（盡可能避免白己測 試自

3、己的項bl ）。內(nèi)測包括： 開發(fā)結(jié)杲與prd需求的校對 功能測試 鏈接、文字 頁面樣式與產(chǎn)品部提供頁面的比對 原則上，提交測試厲立刻被打冋的項1=1, 視為不合格項1=1,將酌情扣減項日分數(shù)。項目部署文檔項目負責人、開發(fā)品管項目部署文檔，山項日負責人編寫。編寫 原則是，笫三人拿到部署文檔時，應能嚴 格按步驟止常部署成功。部署文檔應簡潔、 清晰、明了、全而，不能有錯漏。編寫部署文檔后，項目負責人應在開發(fā)環(huán) 境的生產(chǎn)模擬測試環(huán)境中，模擬部署，以 校驗部署步驟和部署結(jié)果。項目負責人口行部署測試結(jié)束后，應將部 署步驟，交由開發(fā)殆管模擬部署。開發(fā)吊 管測試通過后，由開發(fā)品管提交給測試部 測試。項目提交項

4、日由項目小組負責人統(tǒng)一合并代碼、編 譯、打包，并將打包的文件，放入共享日 錄：192. 168. 128. 55deployments 下。prd流程及規(guī)范prd流程分為卩rd調(diào)研.pro review prd分析.prd確認四個步驟。 pro review：由產(chǎn)品經(jīng)理、開發(fā)團隊成員、測試人員共同reviewo prd review后， 如果仍有較多問題，需要產(chǎn)品經(jīng)理修改后，重新reviewo prd分析:pro review通過并提供最新版本后，開發(fā)人員根據(jù)prd進行初步的prd 詳細分析與erd設計。分析包括所有功能模塊的實施方案，解決開發(fā)中可能出現(xiàn) 的所有問題，及時對prd的問題提出疑問

5、和修正意見。prd分析過程中，應同時 進行erd的初步設計。prd分析完成后，項目的所有成員，應對prd有深入的理 解。 prd確認：prd詳細分析完畢后，則為prd確認。prd確認后，應將確認的prd 加入項目的documents 錄中，同時，將prd發(fā)給測試部李敵備案。注意：prd確認后，開發(fā)和測試過程中，除開發(fā)團隊認為prd仍有問題或不明確的地 方需要調(diào)整外，不可隨意修改與調(diào)整prd,包括文字與內(nèi)容。prd調(diào)整應經(jīng)過開發(fā)總監(jiān)確 認后，并提交新的卩rd文檔給測試、開發(fā)備案后，才可接受更改。三、項目開發(fā)流程及規(guī)范開發(fā)流程分為：開發(fā)計劃、erd詳細設計、開發(fā)、自測、code review五個步

6、驟。 開發(fā)計劃：prd分析并確認后，項目主管應對項目的進度安排做詳細計劃。開發(fā) 計劃應包含erd設計和review、項目編碼、自測、code review、項目部署計劃及 部署測試等各方面的時間。 erd詳細設計：開發(fā)負責人在erd初步設計的基礎上，細化erd設計。（erd 設計要求，見erd設計模版） erd review： erd詳細設計完成后，由開發(fā)負責人、架構(gòu)師、開發(fā)總監(jiān)共同review erd設計，以評估方案的可行性、完整性和優(yōu)劣性，并及時修正方案。如果有問 題要進行erd的完善甚至重新設計，并再次進行erd的review直到erd設計得 到最終的確認。此時項目開發(fā)的干系人應該已經(jīng)完

7、全理解需求prd及erd設計的 相關模塊。 項目代碼開發(fā)：開發(fā)小組根據(jù)prd及erd,進行項目的編碼工作。除m18.v 1外, 所有項目都應在mls.develop分支下進行，開發(fā)完成后由項目負責人統(tǒng)一合并代碼 編譯提交。 自測：開發(fā)完成后，進行功能和代碼自測。自測應包括對每一項關鍵流程、用戶操 作分支，以及頁面、鏈接、文字等方面的全面測試。不得不通過測試或馬虎測試就 提交項目。提交項目的質(zhì)量，將作為重要的考核指標。 code review:自測完成后，或自測的過程中，項目團隊應根據(jù)code review規(guī)范， 對代碼進行交叉review （避免自己review自己的代碼）。四、項目提交流程及

8、規(guī)范項目提交流程分為代碼合并與編譯、編寫部署說明文檔、部署自測、提交部署、上線五 個步驟。 代碼合并與編譯：所有項目，均由開發(fā)小組負責人統(tǒng)一合并與編譯代碼。對于 m18.v3項目，由小組負責人將代碼合并到主干，并在主干上編譯release版本。主 干代碼只有簽出和撤銷簽出的權限，項目上線前不可簽入。 編寫部署說明文檔：功能自測的同時，開發(fā)負責人應同時著手開始編寫部署說明文 檔。部署說明文檔的編制原則為：根據(jù)部署說明文檔，測試人員即可順利按照部署 步驟執(zhí)行部署。部署說明應按制定的部署說明文檔模版編寫。部署說明文檔模版在 tfs的documents文檔模版中可以找到。 部署自測：編寫完部署說明文檔

9、后，開發(fā)負責人應在本地模擬測試環(huán)境中，根據(jù)部 署說明文檔一步步執(zhí)行模擬部署，測試部署結(jié)果，并根據(jù)實際遇到的問題調(diào)整部署 說明文檔，直至順利部署成功。 提交部署：部署自測通過后，將卩rd文檔、frd文檔、部署說明文檔、程序代碼、 數(shù)據(jù)庫腳本代碼（如果有）、數(shù)據(jù)庫權限分配文檔（如果有），統(tǒng)一放到 5m18_projcct_frontprojcct_prd 目錄下,并以項目名稱作為子目 錄，如（列表頁二期、會員行為頁二期）。上述工作就緒后，通過郵件通知張濤， 由張濤在本地做上線部署測試檢查，確認無誤后，轉(zhuǎn)發(fā)測試部。所有部署的郵件, 均通過張濤驗證并轉(zhuǎn)發(fā)測試。 項目上線：測試通過并上線后，由項目負責人配合配置管理員，將源代碼簽入，并 歸檔 5m18_projcct_frontprojcct_prd 下的部署包到 192.168.128.