【產品】禪道項目管理簡析

      網友投稿 731 2025-04-08

      采用禪道的敏捷開發模式進行整個軟件開發生命周期的管理:

      需求->設計->編碼->測試->交付

      四個階段全部用禪道對應的功能進行規范化管理。

      1、崗位劃分

      1)項目經理PM

      2)技術經理TM

      3)測試經理QM

      4)高級程序員(一般擔任開發小組長)MC

      5)程序員GC

      6)前端工程師FE

      2、開發工作流程

      禪道里的“項目”對應的就是每一次的發版。

      比如:

      下一次要發版的版本號是V2.4,則就需要新增一個項目“XXXXX項目V2.4”,相應的,每一個“項目”下只會有對應的一個“版本”。

      如:

      “XXXX組件V2.4.0”,在開始每一個版本開發周期前就要在禪道上新建對應的“項目”。

      1)需求討論

      采用靜態原型法與甲方做需求前期討論

      負責人:項目經理

      參與者:技術經理、測試經理及前端工程師

      外部需求討論階段不需要進禪道,用excel格式的會議紀要、郵件等進行溝通,在需求相對比較明晰之后,安排前端工程師制作靜態原型,以靜態原型+說明文檔的方式來與甲方進行反復的溝通確認,直至最終確定需求。

      2)需求確認

      與甲方一起確定下一次發版需要進行開發的需求及優先級

      負責人:項目經理

      參與者:技術經理

      把最終確定的下一次發版的需求細化,并把細化的需求錄入到禪道并設定好優先級為3(在后續過程中,甲方極有可能會臨時提出緊急需求,那些需求可以相應設置優先級為2或1),這里要注意一定是細化的需求,比如:原始需求是“支持多城市,定于4月15日上線區內其他4個城市”,從這個需求細化出來的應該是具體到頁面的需求,如:多城市_修改訂單列表頁面使之支持多城市...

      確定下一次發版后要完成的需求后,項目組內部開全會通報所有需求,測試經理開始準備測試用例

      3)版本定義

      確定好將要發版的組件版本

      負責人:項目經理

      每一次發版的版本號規范如下:

      1)版本號第二位加1,第三位為0,如:V2.2.0

      2)在正式發版之后如果有小改,則第三位遞增,如:V2.2.1,V2.2.2...

      一般來說,按兩周發布一個版本的周期發版;

      在項目-版本中定義好版本,并把版本與需求關聯起來(一個需求可以和多個版本關聯,比如:需求002:訂單列表頁支持多城市的不同操作員只能看到本城市的訂單,此需求牽涉到:訂單中心組件V2.2.0、商品中心組件V2.2.0、微商城/PC商城組件V2.2.0這幾個版本,都要關聯上)

      這里要注意的是,要分組件定義版本,要求所有組件的版本號都保持一致,

      比如:

      要定義這么幾個組件的版本:

      1)微商城/PC商城組件V2.2.0

      2)訂單中心組件V2.2.0

      3)商品中心組件V2.2.0

      4)門店系統組件V2.2.0

      5)呼叫中心組件V2.2.0

      6)門店APP組件V2.2.0

      在項目-版本-查看bug,可查看此版本下的bug的清單

      4)分配任務

      根據需求細化并分配開發任務

      負責人:技術經理

      禪道路徑“項目-任務”,做開發任務分配的時候,一般來說都會從一個需求分出多個開發任務,任務是最原子的事務,一個任務只能是一個執行人。

      如:

      需求為:修改XXX頁面使之支持不同城市的操作員只能顯示本城市的信息

      分配出3個任務:

      1)修改XXX頁面使之支持不同城市的操作員只能顯示本城市的信息-詳細設計

      2)修改XXX頁面使之支持不同城市的操作員只能顯示本城市的信息-后端編碼

      3)修改XXX頁面使之支持不同城市的操作員只能顯示本城市的信息-前端編碼

      5)詳細設計

      根據開發需求做設計文檔

      負責人:分配了任務的開發組相應人員

      監督人:技術經理

      根據情況安排編碼程序員做設計文檔(沒有太大難度的功能)或者是由高級程序員或技術經理做設計文檔(有一定難度的功能),統一放到SVN,如果是那種很簡單的算法設計,可直接放到禪道-任務的備注。

      文檔標題格式:設計文檔_需求ID_需求標題,如:設計文檔_需求001_修改XXX頁面使之支持不同城市的操作員只能顯示本城市的信息

      6)編碼及單元測試

      負責人:分配了任務的開發組相應人員

      【產品】禪道項目管理簡析

      監督人:技術經理、開發小組長

      1)程序員根據禪道上的任務按計劃編碼和做單元測試

      2)程序員每天早上上禪道去“開啟”分配給自己的任務,任務完成后點擊“完成”

      這里要特別強調: 采用禪道來分配任務并不是說不需要當面溝通,當面溝通依然是最重要的

      禪道可與SVN集成,使得技術經理可以直接在禪道上review代碼(社區版無此功能)

      3)技術經理負責每天的代碼review和解決技術難題

      4)項目經理負責每天監控開發進度,發現情況及時溝通處理,項目經理根據任務的完成情況,及時修改需求的進度,使得甲方能及時了解進度情況,需求的進度統一寫在備注”,格式如下:

      研發完畢時間:2016-04-08晚上7點

      測試完畢時間:2016-04-19晚上7點

      發布上線時間:2016-04-20凌晨2點

      特別注意:數據庫變更的腳本,要統一放到SVN的“開發文檔-版本目錄”下,如:\01開發文檔\V2.2.0 ,命名格式:腳本文件_V2.2.0.txt,這個腳本文件由技術經理進行維護

      7)集成測試

      編碼完成,提交集成測試

      1)技術經理自測后認為可以提交集成測試后, ? 在禪道路徑“項目-版本”里,提交測試

      2)技術經理把代碼部署到測試服務器上

      3)測試經理安排測試并提交bug(提交bug的時候,屬于這次發版要修正的bug,嚴重程度設為1,其他不屬于這次發版的bug,設為2或3,每次提交bug,都要設置“抄送人”為項目組管理層,使得管理層的每一個人都能了解測試的進度)

      4)如果測試進入收尾階段,即將定版的,技術經理把當前提交測試的代碼在SVN上打一個對應版本的Branch分支(名稱格式:V2.2.0_Testing),修改bug的人員集中在幾個核心程序員上,減少引發新bug的幾率,在通知核心程序員switch到此Branch后,立即修改SVN上的權限設置從Trunk上刪除核心程序員的讀寫權限避免人為錯誤,其他程序員在Trunk分支上繼續后續的開發

      注意:

      1)測試-bug中提交bug的時候,務必要選擇對應的版本號

      2)每次技術經理更新文件到測試服務器,都要在釘群里通告大家,并附上此次更新修復的bug清單

      8)驗收測試

      集成測試完成,進行發版前的最后審核和驗收測試

      在測試經理回歸完所有1級bug,認為可上線后

      1)測試經理報告項目經理可以發版了

      2)項目經理自己要再做一次測試,確保品質

      3)項目經理測試后也認為沒問題了,提交給甲方進行發版前的驗收測試(如果有必要的,也可讓甲方在階段7參與測試)

      9)發版上線

      甲方確認可以發版,正式發版

      在甲方進行驗收測試認為可以發版后,

      1)測試經理,進禪道路徑“測試-版本”,修改已測試好的版本,設為“已完成”

      2)技術經理把此次發版需要更新的代碼、數據庫SQL腳本打包出來

      3)項目經理從禪道的項目-需求列表里導出(復制出)此次發版關聯的需求為Excel文件,此文件就是提供給甲方的發版說明(changelog)文檔,每次發版都在原文檔前部增加新一個版本的內容

      4)項目經理向甲方提供changelog文檔,并讓甲方簽署上線確認書

      5)技術經理把將要發版的文件小心謹慎地發布到生產服務器上

      6)項目經理在禪道“產品-發布”中設定與項目-版本相同的發布,備注好發版時間和發版內容,并把版本和發布一對一關聯起來

      7)技術經理在發版第二天,在SVN上從Branch里導出一個Tag,名稱格式:V2.2.0_Release

      10)版本維護

      在發版之后,一般來說,還是會發現一些之前沒注意到的Bug需要修改,因此,在下一次大版本發版之前,需要繼續維護當前版本,具體做法如下:

      1)技術經理從之前發版的Tag下的Release導出一個Branch,如:V2.2.0_Fixbug

      2)測試經理根據客戶處反饋的情況,繼續發bug到禪道上,嚴重程度為1,版本號為V2.2.0

      3)技術經理安排相關人員在V2.2.0_Fixbug分支下修改bug(一般來說,只安排專職負責舊版本維護的程序員去處理這些bug,最好是技術經理自己負責處理),這里要注意SVN的權限,此Fixbug分支只給具體修改的程序員分配讀寫權限

      4)測試經理安排做回歸測試

      5)2、3、4步驟循環進行,直到認為可以發版了,則確定版本號,比如為:V2.2.1,并從V2.2.0_Fixbug導出一個Tag為V2.2.1_Release,由技術經理更新的生產服務器上(發版前也要導出修改的bug清單給甲方確認)

      以上2、3、4、5步驟迭代循環,直到停止維護此版本

      11)中止維護

      在新版本即將發布前夕,一般是5天內,則停止上一個版本的維護

      1)技術經理在告知相關程序員把本地的工作目錄switch到Trunk后,關閉svn上的老版本Branch的程序員讀寫權限

      2)項目經理關閉老版本的發布,禪道路徑“產品-發布”,設置此版本對應的發布為“停止維護”(這個步驟不能忘記,否則在bug里邊選擇版本的時候,沒有被停止維護的發布對應的版本會一直顯示出來)

      refer:

      https://group.cnblogs.com/topic/74568.html

      開發者 項目管理 ProjectMan

      版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。

      版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。

      上一篇:字體變成繁體字
      下一篇:如何去掉和值為0的0(0減去任何數都等于0)
      相關文章
      久久亚洲AV成人无码国产| 亚洲色偷拍另类无码专区| 国产亚洲精品资源在线26u| 亚洲人成色4444在线观看| 亚洲国产成人超福利久久精品| 亚洲AV色香蕉一区二区| 亚洲成AV人片在线观看无码| 中文亚洲AV片不卡在线观看| 在线观看国产一区亚洲bd| 亚洲av日韩av无码av| 亚洲欧洲综合在线| 亚洲国产成人精品青青草原| 91亚洲国产成人久久精品网址| 亚洲色图古典武侠| 亚洲日本国产精华液| 亚洲人成毛片线播放| 亚洲AV综合色区无码二区偷拍 | 中文字幕亚洲不卡在线亚瑟| 亚洲色婷婷综合开心网| 亚洲精品无码99在线观看| 亚洲精品麻豆av| 久久青青草原亚洲av无码| 国产亚洲精品无码专区| 亚洲中文字幕日产乱码高清app| 亚洲热妇无码AV在线播放| 亚洲成色在线综合网站| 内射干少妇亚洲69XXX| 亚洲精品不卡视频| 亚洲综合色7777情网站777| 四虎亚洲精品高清在线观看| 亚洲午夜精品一区二区麻豆| 亚洲av无码av在线播放| 亚洲第一页综合图片自拍| 国产亚洲一区区二区在线| 国产AV无码专区亚洲精品| 久久亚洲精品成人AV| 亚洲免费一级视频| 亚洲另类无码专区首页| 亚洲av无码乱码在线观看野外| 久久久久亚洲爆乳少妇无 | 亚洲AV无码国产精品色|