全面採用禪道的敏捷開發模式進行整個軟體開發生命週期的管理，需求->設計->編碼->測試->交付這四個階段全部用禪道對應的功能進行規範化管理。
崗位劃分：
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這幾個版本，都要關聯上）
4、根據需求細化並分配開發任務
負責人：技術經理
禪道路徑「專案-任務」，做開發任務分配的時候，一般來說都會從乙個需求分出多個開發任務，任務是最原子的事務，乙個任務只能是乙個執行人，如：
需求為：修改***頁面使之支援不同城市的操作員只能顯示本城市的資訊
分配出3個任務：
1）修改***頁面使之支援不同城市的操作員只能顯示本城市的資訊-詳細設計
2）修改***頁面使之支援不同城市的操作員只能顯示本城市的資訊-後端編碼
3）修改***頁面使之支援不同城市的操作員只能顯示本城市的資訊-前端編碼
5、根據開發需求做設計文件
負責人：分配了任務的開發組相應人員
監督人：技術經理
根據情況安排編碼程式設計師做設計文件（沒有太大難度的功能）或者是由高階程式設計師或技術經理做設計文件（有一定難度的功能），統一放到svn。
文件標題格式：設計文件_需求id_需求標題，如：設計文件_需求001_修改***頁面使之支援不同城市的操作員只能顯示本城市的資訊
6、編碼階段
負責人：分配了任務的開發組相應人員
監督人：技術經理、開發小組長
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完成之後，專案經理就要開始和甲方一起溝通下一次發版的需求了，然後是技術經理從需求分配任務，開始新一次發版之旅。這就是螺旋狀上公升的敏捷迭代開發之路。
禪道的使用
admin 管理員 部門 建立部門 需求部門,開發部門,測試部門,專案部門,產品部門 組織 建立使用者 產品經理，專案經理，開發人員，測試人員 分配許可權 產品模組 新增模組 產品 建立產品 需求 提需求 專案專案 新增專案 團隊 新增人員 產品 關聯產品 需求 分配任務 開發，測試 開發我的地盤 ...
禪道的使用流程
在系統建立乙個新的使用者帳號 開啟 組織 使用者 新增使用者 頁面 在新增使用者表單中填寫新使用者資訊 儲存使用者資訊。2.建立產品 在系統建立乙個新的產品 開啟 產品 新增產品 頁面 在表單中填寫要建立的產品資訊 儲存產品資訊 3.建立需求 在系統建立乙個新的需求 開啟 產品 需求 新增需求 頁面...
禪道敏捷專案管理軟體的安裝和使用
一 安裝 建立 opt 目錄 這個包是乙個自解壓縮格式的，chmod a rx 7z，新增執行許可權。執行這個包，會自動解壓縮，比如.zentaopms.3.0.beta1.linux.7z，解壓縮之後，會生成乙個 opt lampp 的目錄。二 啟動和停止服務 cd opt lampp 這裡面有s...