全面采用禪道的敏捷開發(fā)模式進(jìn)行整個(gè)軟件開發(fā)生命周期的管理，需求->設(shè)計(jì)->編碼->測試->交付這四個(gè)階段全部用禪道對應(yīng)的功能進(jìn)行規(guī)范化管理。崗位劃分：1、項(xiàng)目經(jīng)理2、技術(shù)經(jīng)理3、測試經(jīng)理4、高級程序員(一般擔(dān)任開發(fā)小組長)5、程序員6、前端工程師以上2、4、5、6屬于開發(fā)組，3屬于測試組具體開發(fā)工作流程如下：1、與甲方做需求前期討論負(fù)責(zé)人：項(xiàng)目經(jīng)理參與者：技術(shù)經(jīng)理、測試經(jīng)理及其它有必要參與的人員外部需求討論階段不需要進(jìn)禪道，用excel格式的會議紀(jì)要、郵件等進(jìn)行溝通2、與甲方一起確定需要進(jìn)行開發(fā)的需求及優(yōu)先級負(fù)責(zé)人：項(xiàng)目經(jīng)理參與者：技術(shù)經(jīng)理把最終確定的需求，細(xì)化之后把細(xì)化的需求錄入到禪道并設(shè)定好優(yōu)先級，優(yōu)先級為1的為下一個(gè)版本要實(shí)現(xiàn)的需求，這里要注意一定是細(xì)化的需求，比如：原始需求是“支持多城市，定于4月15日上線區(qū)內(nèi)其他4個(gè)城市”，從這個(gè)需求細(xì)化出來的應(yīng)該是具體到頁面的需求，如：多城市_修改訂單列表頁面使之支持多城市...確定下一次發(fā)版后要完成的需求后，項(xiàng)目組內(nèi)部開全會通報(bào)所有需求，測試經(jīng)理開始準(zhǔn)備測試用例3、確定好將要發(fā)版的組件版本負(fù)責(zé)人：項(xiàng)目經(jīng)理每一次發(fā)版的版本號規(guī)范如下：1）版本號第二位加1，第三位為0，如：V2.2.02）在正式發(fā)版之后如果有小改，則第三位遞增，如：V2.2.1，V2.2.2...一般來說，按兩周發(fā)布一個(gè)版本的周期發(fā)版在項(xiàng)目-版本中定義好版本，并把版本與需求關(guān)聯(lián)起來（一個(gè)需求可以和多個(gè)版本關(guān)聯(lián)，比如：需求002：訂單列表頁支持多城市的不同操作員只能看到本城市的訂單，此需求牽涉到：訂單中心組件V2.2.0、商品中心組件V2.2.0、微商城/PC商城組件V2.2.0這幾個(gè)版本，都要關(guān)聯(lián)上）這里要注意的是，要分組件定義版本，要求所有組件的版本號都保持一致，舉例如下：1）微商城/PC商城組件V2.2.02）訂單中心組件V2.2.03）商品中心組件V2.2.04）門店系統(tǒng)組件V2.2.05）呼叫中心組件V2.2.06）門店APP組件V2.2.0在項(xiàng)目-版本-查看bug，可查看此版本下的bug的清單4、根據(jù)需求細(xì)化并分配開發(fā)任務(wù)負(fù)責(zé)人：技術(shù)經(jīng)理禪道路徑“項(xiàng)目-任務(wù)”，做開發(fā)任務(wù)分配的時(shí)候，一般來說都會從一個(gè)需求分出多個(gè)開發(fā)任務(wù)，任務(wù)是最原子的事務(wù)，一個(gè)任務(wù)只能是一個(gè)執(zhí)行人，如：需求為：修改XXX頁面使之支持不同城市的操作員只能顯示本城市的信息分配出3個(gè)任務(wù)：1）修改XXX頁面使之支持不同城市的操作員只能顯示本城市的信息-詳細(xì)設(shè)計(jì)2）修改XXX頁面使之支持不同城市的操作員只能顯示本城市的信息-后端編碼3）修改XXX頁面使之支持不同城市的操作員只能顯示本城市的信息-前端編碼5、根據(jù)開發(fā)需求做設(shè)計(jì)文檔負(fù)責(zé)人：分配了任務(wù)的開發(fā)組相應(yīng)人員監(jiān)督人：技術(shù)經(jīng)理根據(jù)情況安排編碼程序員做設(shè)計(jì)文檔（沒有太大難度的功能）或者是由高級程序員或技術(shù)經(jīng)理做設(shè)計(jì)文檔（有一定難度的功能），統(tǒng)一放到SVN。文檔標(biāo)題格式：設(shè)計(jì)文檔_需求ID_需求標(biāo)題，如：設(shè)計(jì)文檔_需求001_修改XXX頁面使之支持不同城市的操作員只能顯示本城市的信息6、編碼階段負(fù)責(zé)人：分配了任務(wù)的開發(fā)組相應(yīng)人員監(jiān)督人：技術(shù)經(jīng)理、開發(fā)小組長1）程序員根據(jù)禪道上的任務(wù)按計(jì)劃編碼和做單元測試2）程序員每天早上要自己去開啟分配給自己的任務(wù)，任務(wù)完成后點(diǎn)擊“完成”這里要特別強(qiáng)調(diào)： 采用禪道來分配任務(wù)并不是說不需要當(dāng)面溝通，當(dāng)面溝通依然是最重要的禪道可與SVN集成，使得技術(shù)經(jīng)理可以直接在禪道上review代碼（社區(qū)版無此功能）3）技術(shù)經(jīng)理負(fù)責(zé)每天的代碼review和解決技術(shù)難題4）項(xiàng)目經(jīng)理負(fù)責(zé)每天監(jiān)控開發(fā)進(jìn)度，發(fā)現(xiàn)情況及時(shí)溝通處理，項(xiàng)目經(jīng)理根據(jù)任務(wù)的完成情況，及時(shí)修改需求的進(jìn)度，使得甲方能及時(shí)了解進(jìn)度情況，需求的進(jìn)度統(tǒng)一寫在備注”，格式如下：研發(fā)完畢時(shí)間：2016-04-08晚上7點(diǎn)測試完畢時(shí)間：2016-04-19晚上7點(diǎn)發(fā)布上線時(shí)間：2016-04-20凌晨2點(diǎn)7、編碼完成，提交集成測試1）技術(shù)經(jīng)理自測后認(rèn)為可以提交集成測試后， 在禪道路徑“項(xiàng)目-版本”里，提交測試2）技術(shù)經(jīng)理把代碼部署到測試服務(wù)器上3）測試經(jīng)理安排測試并提交bug（提交bug的時(shí)候，屬于這次發(fā)版要修正的bug，嚴(yán)重程度設(shè)為1，其他不屬于這次發(fā)版的bug，設(shè)為2或3）4）如果測試進(jìn)入收尾階段，即將定版的，技術(shù)經(jīng)理把當(dāng)前提交測試的代碼在SVN上打一個(gè)對應(yīng)版本的Branch分支（名稱格式：V2.2.0_Testing），修改bug的人員集中在幾個(gè)核心程序員上，減少引發(fā)新bug的幾率，在通知核心程序員switch到此Branch后，立即修改SVN上的權(quán)限設(shè)置從Trunk上刪除核心程序員的讀寫權(quán)限避免人為錯(cuò)誤，其他程序員在Trunk分支上繼續(xù)后續(xù)的開發(fā)注意：1）測試-bug中提交bug的時(shí)候，務(wù)必要選擇對應(yīng)的版本號2）每次技術(shù)經(jīng)理更新文件到測試服務(wù)器，都要在釘群里通告大家，并附上此次更新修復(fù)的bug清單8、測試完成，發(fā)版前的最后審核在測試經(jīng)理回歸完所有1級bug，認(rèn)為可上線后1）測試經(jīng)理報(bào)告項(xiàng)目經(jīng)理可以發(fā)版了2）項(xiàng)目經(jīng)理自己要再做一次測試，確保品質(zhì)3）項(xiàng)目經(jīng)理測試后也認(rèn)為沒問題了，提交給甲方進(jìn)行發(fā)版前的驗(yàn)收測試（如果有必要的，也可讓甲方在階段7參與測試）9、甲方確認(rèn)可以發(fā)版，正式發(fā)版在甲方進(jìn)行驗(yàn)收測試認(rèn)為可以發(fā)版后，1）測試經(jīng)理，進(jìn)禪道路徑“測試-版本”，修改已測試好的版本，設(shè)為“已完成”2）技術(shù)經(jīng)理把此次發(fā)版需要更新的代碼、數(shù)據(jù)庫SQL腳本打包出來3）項(xiàng)目經(jīng)理從禪道的項(xiàng)目-需求列表里導(dǎo)出（復(fù)制出）此次發(fā)版關(guān)聯(lián)的需求為Excel文件，此文件就是提供給甲方的changelog文檔4）項(xiàng)目經(jīng)理向甲方提供changelog文檔，并讓甲方簽署上線確認(rèn)書5）技術(shù)經(jīng)理把將要發(fā)版的文件小心謹(jǐn)慎地發(fā)布到生產(chǎn)服務(wù)器上6）項(xiàng)目經(jīng)理在禪道“產(chǎn)品-發(fā)布”中設(shè)定與項(xiàng)目-版本相同的發(fā)布，備注好發(fā)版時(shí)間和發(fā)版內(nèi)容，并把版本和發(fā)布一對一關(guān)聯(lián)起來7）技術(shù)經(jīng)理在發(fā)版第二天，在SVN上從Branch里導(dǎo)出一個(gè)Tag，名稱格式：V2.2.0_Release10、版本維護(hù)階段在發(fā)版之后，一般來說，還是會發(fā)現(xiàn)一些之前沒注意到的Bug需要修改，因此，在下一次大版本發(fā)版之前，需要繼續(xù)維護(hù)當(dāng)前版本，具體做法如下：1）技術(shù)經(jīng)理從之前發(fā)版的Tag下的Release導(dǎo)出一個(gè)Branch，如：V2.2.0_Fixbug2）測試經(jīng)理根據(jù)客戶處反饋的情況，繼續(xù)發(fā)bug到禪道上，嚴(yán)重程度為1，版本號為V2.2.03）技術(shù)經(jīng)理安排相關(guān)人員在V2.2.0_Fixbug分支下修改bug（一般來說，只安排專職負(fù)責(zé)舊版本維護(hù)的程序員去處理這些bug，最好是技術(shù)經(jīng)理自己負(fù)責(zé)處理），這里要注意SVN的權(quán)限，此Fixbug分支只給具體修改的程序員分配讀寫權(quán)限4）測試經(jīng)理安排做回歸測試5）2、3、4步驟循環(huán)進(jìn)行，直到認(rèn)為可以發(fā)版了，則確定版本號，比如為：V2.2.1，并從V2.2.0_Fixbug導(dǎo)出一個(gè)Tag為V2.2.1_Release，由技術(shù)經(jīng)理更新的生產(chǎn)服務(wù)器上（發(fā)版前也要導(dǎo)出修改的bug清單給甲方確認(rèn)）以上2、3、4、5步驟迭代循環(huán)，直到停止維護(hù)此版本11、停止維護(hù)老版本在新版本即將發(fā)布前夕，一般是5天內(nèi)，則停止老版本的維護(hù)1）技術(shù)經(jīng)理在告知相關(guān)程序員把本地的工作目錄switch到Trunk后，關(guān)閉svn上的老版本Branch的程序員讀寫權(quán)限2）項(xiàng)目經(jīng)理關(guān)閉老版本的發(fā)布，禪道路徑“產(chǎn)品-發(fā)布”，設(shè)置此版本對應(yīng)的發(fā)布為“停止維護(hù)”（這個(gè)步驟不能忘記，否則在bug里邊選擇版本的時(shí)候，沒有被停止維護(hù)的發(fā)布對應(yīng)的版本會一直顯示出來）這里要特別注意的是: 不是說這一次發(fā)版完成了才開始新的一次發(fā)版之旅，一般來說，在步驟2完成之后，項(xiàng)目經(jīng)理就要開始和甲方一起溝通下一次發(fā)版的需求了，然后是技術(shù)經(jīng)理從需求分配任務(wù)，開始新一次發(fā)版之旅。這就是螺旋狀上升的敏捷迭代開發(fā)之路。。。。。。。
本站僅提供存儲服務(wù)，所有內(nèi)容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請
點(diǎn)擊舉報(bào)。
