李士心：全面使用禅道做敏捷開發的規範化管理分享
作者：李士心
來源：https://www.zhihu.com/question/21518108/answer/96043412
全面采用禅道的敏捷開發模式進行整個軟件開發生命周期的管理，需求->設計->編碼->測試->交付這四個階段全部用禅道對應的功能進行規範化管理。
崗位劃分：1、項目經理
2、技術經理
3、測試經理
4、高級程序員(一般擔任開發小組長)
5、程序員
6、前端工程師
以上2、4、5、6屬于開發組，3屬于測試組
具體開發工作流程如下：
1、與甲方做需求前期討論
負責人：項目經理
參與者：技術經理、測試經理及其它有必要參與的人員
外部需求討論階段不需要進禅道，用excel格式的會議紀要、郵件等進行溝通
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點
7、編碼完成，提交集成測試
1）技术经理自测后认为可以提交集成测试后， 在禅道路径“项目-版本”里，提交测试
2）技術經理把代碼部署到測試服務器上
3）測試經理安排測試並提交bug（提交bug的時候，屬于這次發版要修正的bug，嚴重程度設爲1，其他不屬于這次發版的bug，設爲2或3）
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里边选择版本的时候，没有被停止维护的发布对应的版本会一直显示出来）
这里要特别注意的是: 不是说这一次发版完成了才开始新的一次发版之旅，一般来说，在步骤2完成之后，项目经理就要开始和甲方一起沟通下一次发版的需求了，然后是技术经理从需求分配任务，开始新一次发版之旅。这就是螺旋状上升的敏捷迭代开发之路。
