彩仙子码报12码|黑色码报
【原創】本人在一個大型項目中全面利用禪道進行軟件項目管理的實踐_2016年12月6日更新
2016-04-20 09:15:31
李志
  • 訪問次數: 24
  • 注冊日期: 2007-12-17
  • 最后登錄: 2019-11-28
  • 我的積分: 542
  • 門派等級: 玄清 等級2 道童

以下是我在一個長期項目研發過程中采用敏捷思想進行項目開發管理的成功實踐,供大家參考
 
、項目背景    
1、這是一個長期維護,需要不斷擴展功能的O2O平臺,系統本身包含多達13個子系統,且還在不斷增加中
2、系統采用了“組件化架構”,各個組件之間實現了脫藕,可以各自單獨擴展
3、開發資源嚴重匱乏,程序員嚴重不足,且其中能獨立工作的程序員比例很低
 
、敏捷開發實踐
1、每一次版本迭代都包括:需求->設計->編碼->測試->交付這四個階段
2、用禪道對開發全過程進行規范化管理
3、每一次版本迭代的周期是2周
 
崗位劃分:
1、產品/項目經理PM(Product/Project Manager )
2、技術經理TM(Technical Manager )
3、測試經理QM(Quality Manager )
4、高級程序員(一般擔任開發小組長)MC(Master Coder)
5、程序員GC(General Coder)
6、前端工程師FE(Front Engineer)
7、測試員QE(Quality Engineer)
以上2、4、5、6屬于開發組,3、7屬于測試組
 
禪道使用的幾個小技巧
-- 禪道里的“項目”是指一個產品生命周期中對某一個階段性的工作的定義。 我的做法是把一個大版本定義為一個項目,V2.0是一個項目,V3.0就是另一個新項目
-- 版本的定義在細節上如果能注意的話,會讓程序員、測試員在使用過程中更加順暢,舉個例子:目前上線正常運行的是“XXXXX系統V2.0.0”版,正在開發,即將上線的是“XXXXX系統V2.0.1”版,那么在集成測試階段,就應該編輯一下這兩個版本的名稱,改為:“XXXXX系統V2.0.0(當前版本)”,“XXXXX系統V2.0.1(即將上線)”,使得測試員、程序員在處理bug時選擇版本的時候不用再動腦去想
-- 在禪道里配置好異步自動發提醒郵件,實現“工作追人”
 
具體開發工作流程如下:
 
1、需求討論
采用靜態原型法與甲方做需求前期討論
負責人:產品/項目經理
參與者:技術經理、測試經理及前端工程師、高級程序員

外部需求討論階段不需要進禪道,用excel格式的會議紀要、郵件等進行溝通,在需求相對比較明晰之后, 安排前端工程師制作靜態原型,以靜態原型+說明文檔的方式來與甲方進行反復的溝通確認,直至最終確定需求
 
2、需求確認
與甲方一起確定下一次發版需要進行開發的需求及優先級
負責人:產品/項目經理
參與者:技術經理、測試經理、高級程序員
把最終確定的下一次發版的需求細化,并把細化的需求錄入到禪道并設定好優先級為3(在后續過程中,甲方極有可能會臨時提出緊急需求,那些需求可以相應設置優先級為2或1),這里要注意一定是細化的需求,比如:原始需求是“支持多城市,定于4月15日上線區內其他4個城市”,從這個需求細化出來的應該是具體到頁面的需求,如:多城市_修改訂單列表頁面使之支持多城市...
確定下一次發版后要完成的需求后,項目組內部開全會通報所有需求, 測試經理開始準備測試用例
 
3、分配任務
根據需求細化并分配開發任務
負責人:技術經理
禪道路徑“項目-任務”,做開發任務分配的時候,一般來說都會從一個需求分出多個開發任務, 任務是最原子的事務,一個任務只能指派一個執行人,如:
需求為:修改XXX頁面使之支持不同城市的操作員只能顯示本城市的信息
分配出3個任務:
1)修改XXX頁面使之支持不同城市的操作員只能顯示本城市的信息-詳細設計
2)修改XXX頁面使之支持不同城市的操作員只能顯示本城市的信息-后端編碼
3)修改XXX頁面使之支持不同城市的操作員只能顯示本城市的信息-前端編碼
 
4、詳細設計
根據開發需求做設計文檔
負責人:分配了任務的開發組相應人員
監督人:技術經理
根據情況安排編碼程序員做設計文檔(沒有太大難度的功能)或者是由高級程序員或技術經理做設計文檔(有一定難度的功能),統一放到SVN/Git,如果是那種很簡單的算法設計,可直接放到禪道-任務的備注。
文檔標題格式:設計文檔_需求ID_需求標題,如:設計文檔_需求001_修改XXX頁面使之支持不同城市的操作員只能顯示本城市的信息
 
5、編碼及單元測試
負責人:分配了任務的開發組相應人員
監督人:技術經理、開發小組長
1)程序員根據禪道上的任務按計劃編碼和做單元測試
2)程序員每天早上上禪道去“開啟”分配給自己的任務,任務完成后點擊“完成”
這里要特別強調: 采用禪道來分配任務并不是說不需要當面溝通,當面溝通依然是最重要的
禪道可與SVN/Git集成,使得技術經理可以直接在禪道上review代碼(社區版無此功能)
3)技術經理負責每天的代碼review和解決技術難題
4)產品/項目經理負責每天監控開發進度,發現情況及時溝通處理,產品/項目經理根據任務的完成情況,及時修改需求的進度,使得甲方能及時了解進度情況,需求的進度統一寫在備注”,格式如下:
研發完畢時間:2016-04-08晚上7點
測試完畢時間:2016-04-19晚上7點
發布上線時間:2016-04-20凌晨2點

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

 
6、版本定義
在即將提交集成測試前,設置好各個組件的版本
負責人:產品/項目經理
每一次發版的版本號規范如下:
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的清單
 
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、驗收測試
集成測試完成,進行發版前的最后審核和驗收測試, 注意 :這里都是針對7所分出來的那個用于此次發版的Branch分支(如:V2.2.0_Testing)
在測試經理回歸完所有1級bug,認為可上線后
1)測試經理報告產品/項目經理可以發版了
2)產品/項目經理自己要再做一次測試,確保品質
3)產品/項目經理測試后也認為沒問題了,提交給甲方進行發版前的驗收測試(如果有必要的,也可讓甲方在階段7參與測試)
 
9、發版上線
甲方確認可以發版,正式發版, 注意 :這里都是針對7所分出來的那個用于此次發版的Branch分支(如:V2.2.0_Testing)
在甲方進行驗收測試認為可以發版后,
發版當天:
1)測試經理,進禪道路徑“測試-版本”,修改已測試好的版本,設為“已完成”
2)技術經理把此次發版需要更新的代碼、數據庫SQL腳本打包出來
3)產品/項目經理從禪道的項目-需求列表里導出(復制出)此次發版關聯的需求為Excel文件,此文件就是提供給甲方的發版說明(changelog)文檔,每次發版都在原文檔前部增加新一個版本的內容
4)產品/項目經理向甲方提供changelog文檔,并讓甲方簽署上線確認書
5)技術經理把將要發版的文件小心謹慎地發布到生產服務器上
6)產品/項目經理在禪道“產品-發布”中設定與項目-版本相同的發布,備注好發版時間和發版內容,并把版本和發布一對一關聯起來
發版第二、三天:
1) 技術經理在發版第二天,在SVN上從Branch里導出一個Tag,名稱格式:V2.2.0_Release
2)技術經理在發版第二天,整理禪道-任務,屬于本次發版已完成的任務,全部做 關閉處理,之前計劃要做,但未完成的,可關聯到下一個版本
3)產品/項目經理在技術經理完成2)之后,對相應的本版本的需求,做 關閉處理
 
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里邊選擇版本的時候,沒有被停止維護的發布對應的版本會一直顯示出來) 
 
這里要特別注意的是:  不是說這一次發版完成了才開始新的一次發版之旅,一般來說,在步驟2完成之后,產品/項目經理就要開始和甲方一起溝通下一次發版的需求了,然后是技術經理從需求分配任務,程序員開始熟悉任務需要用到的技術,測試組開始熟悉具體的業務流程和細節,從而開始新一次發版之旅。這就是 螺旋狀上升的敏捷迭代開發之路。。。。。。。
 
PS:配套此開發流程的還有對應各個崗位的“崗位作業書”,更進一步細化每個崗位的具體工作內容,我將在后續博文中放出
 
歡迎各位同好一起探討敏捷開發的實踐方法,大家好,才是真的好^_^
有興趣共同探討的請加Scrum干貨Q群:302304689


李志 最后編輯, 2016-12-06 08:32:26
沙發
2016-04-20 10:14:05
春哥
  • 訪問次數: 10586
  • 注冊日期: 2005-04-30
  • 最后登錄: 2019-12-02
  • 我的積分: 528351
  • 門派等級: 幽靈 等級7 春哥
很好的經驗!加300積分。:)
春哥 最后編輯, 2016-04-20 10:14:48
板凳
2016-04-20 13:47:10
李志
  • 訪問次數: 24
  • 注冊日期: 2007-12-17
  • 最后登錄: 2019-11-28
  • 我的積分: 542
  • 門派等級: 玄清 等級2 道童

項目經理崗位作業書

=====================

每日例行工作:

1、早上開始上班后立即召開朝禮

2、寫朝禮紀要并發給相關人

3、在日志中制定今日工作計劃并掛到主線

4、上禪道檢查任務完成進度是否與計劃相符

5、上禪道檢查Bug修復情況是否正常

6、處理各種臨時任務,加入到禪道的任務列表,如:甲方提出的緊急任務等

7、如有必要,與技術經理、測試經理溝通

8、發現開發進度有嚴重延誤的,立即與上級領導溝通

9、抽空參與測試,了解系統的真實情況

?

周一例行工作:

1、公司層面的項目組周例會

?

周末例行工作:

1、項目組周工作總結會

2、發送項目周總結給項目組管理層及公司管理層

?

分階段工作:

1 、需求討論

職責:總負責人

協作人:技術經理、測試經理及前端工程師

工作內容:

組織召開會議與甲方溝通需求,根據溝通結果與前端工程師一起制作靜態原型,然后拿給甲方繼續溝通,反復迭代,直至最終通過靜態原型落實每一項需求

?

2 、需求確認

職責:總負責人

協作人:技術經理、測試經理

工作內容:

1、把步驟1落實的需求逐條錄入禪道:

菜單路徑:產品à需求à提需求

必填項:所屬產品、所屬計劃、需求來源、不需要評審、需求名稱、優先級(設為1)、需求描述(需求的詳細描述,并給出靜態原型頁面鏈接)、抄送給(項目組管理層)

2、?錄入完需求后主動通知技術經理、測試經理

如有必要,則組織相關人召開會議研討需求細節

?

?

3 、版本定義

職責:總負責人

協作人:無

工作內容:

1)把即將發布的組件版本錄入到禪道

菜單路徑:項目à版本à創建版本

必填項:產品、名稱編號、構建者、打包日期(計劃提交集成測試的日期)

每一次發版的版本號規范如下:
a、版本號第二位加1,第三位為0,如:V2.2.0
b、在正式發版之后如果有小改,則第三位遞增,如:V2.2.1,V2.2.2...
一般來說,按兩周發布一個版本的周期發版,這里要注意的是,要分組件定義版本,要求所有組件的版本號都保持一致,以叫酒為例:
目前至少要定義這么幾個組件版本:
a、微商城/PC商城組件V2.2.0
b、訂單中心組件V2.2.0
c、商品中心組件V2.2.0
d、門店系統組件V2.2.0
e、呼叫中心組件V2.2.0
f、門店APP組件V2.2.0
?

2)把版本與需求關聯

菜單路徑:項目à需求à關聯需求

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

?

4、分配任務

職責:開始醞釀下一版的需求

協作人:前端工程師等必要人員

工作內容:開始醞釀下一版的需求

?

5、詳細設計

職責:有必要的話要開始和甲方討論下一版的需求

協作人:前端工程師等必要人員

工作內容:有必要和甲方討論下一版的需求

?

6、編碼及單元測試

職責:和甲方開始深入討論下一版的需求

協作人:前端工程師等必要人員

工作內容:和甲方開始深入討論下一版的需求

?

7、集成測試

職責:基本上確定下一版本的主要需求

協作人:前端工程師等必要人員

工作內容:

?

8、驗收測試

職責:總負責人

協作人:技術經理、測試經理

工作內容:對整個系統進行抽樣測試

?

9、發版上線

職責:總負責人

協作人:技術經理、測試經理

工作內容:督導技術經理的升級上線工作,負責向甲方提交上線相關的文檔

?

10、版本維護

職責:與甲方確定下一版的需求

協作人:技術經理、測試經理及其他必要人員

工作內容:一般來說,在當前版本發版后的2天內,與甲方確定下一個版本的所有需求(開發內容)

?

11、中止維護

職責:總負責人

協作人:技術經理、測試經理及其他必要人員

工作內容:

李志 最后編輯, 2016-05-26 10:25:28
#3
2016-05-15 07:39:19
李志
  • 訪問次數: 24
  • 注冊日期: 2007-12-17
  • 最后登錄: 2019-11-28
  • 我的積分: 542
  • 門派等級: 玄清 等級2 道童
占位1
#4
2016-05-15 07:39:30
李志
  • 訪問次數: 24
  • 注冊日期: 2007-12-17
  • 最后登錄: 2019-11-28
  • 我的積分: 542
  • 門派等級: 玄清 等級2 道童
占位2
#5
2016-05-15 07:39:42
李志
  • 訪問次數: 24
  • 注冊日期: 2007-12-17
  • 最后登錄: 2019-11-28
  • 我的積分: 542
  • 門派等級: 玄清 等級2 道童
占位3
#6
2016-05-15 07:39:54
李志
  • 訪問次數: 24
  • 注冊日期: 2007-12-17
  • 最后登錄: 2019-11-28
  • 我的積分: 542
  • 門派等級: 玄清 等級2 道童
占位4
#7
2016-05-25 08:41:02
wanxiang123
  • 訪問次數: 4
  • 注冊日期: 2016-05-16
  • 最后登錄: 2018-12-19
  • 我的積分: 63
  • 門派等級: 幽靈 等級1 幽魂
6
#8
2016-12-06 08:35:32
李志
  • 訪問次數: 24
  • 注冊日期: 2007-12-17
  • 最后登錄: 2019-11-28
  • 我的積分: 542
  • 門派等級: 玄清 等級2 道童


筆者第一篇閱讀量過千的文章,值得紀念^_^

#9
2016-12-06 09:12:20
石洋洋
  • 訪問次數: 5727
  • 注冊日期: 2011-04-06
  • 最后登錄: 2019-12-06
  • 我的積分: 93192
  • 門派等級: 幽靈 等級6 修羅
1/1
彩仙子码报12码 nba比赛比分记录 河北十一选五基本跨 22选5开奖结果今 逍遥麻将卡五星新版本 大唐河北麻将代理 东北麻将规则 快速时时彩 女孩与枪 1分彩是不是有人控制 足球球足球球探比分 1zplay电竞比分安卓版 p2p投资理财平台源码 带黄色片的连续剧 极速11选5 中原河北麻将下载app 纽卡斯尔对曼城比分预测