禪道進階使用

3.1.使用流程

在禪道專案管理軟體中，核心的角色有產品經理、專案經理、研發團隊和測試團隊四種角色。如果您現在的團隊是採用敏捷開發的話，那麼可以對應到product owner, scrum master和team(dev and tester)。這幾種角色之間緊緊圍繞產品的需求展開協作，取得成果。禪道核心的管理流程全圖如下所示：

 

3.2.個人管理

3.2.1. 使用待辦進行個人事務管理

禪道設計的目標是團隊協作工具，但其實個人使用禪道也可以派上很大的用場。筆者在開發禪道過程中，從2009年10月開始，用禪道來管理禪道本身的專案管理，那時候禪道的開發團隊只有筆者光桿司令一人，後來和朋友們聊起，戲稱一個人的專案管理。

下面讓我們來展示下如何使用禪道來進行個人的事務管理。

3.2.1.1.建立待辦

 

• 新增待辦的時候，可以設定起止時間。也可以選擇暫時不設定。

• 如果是私人事務，可以勾選上。

3.2.1.2.瀏覽待辦

禪道提供了各種標籤來檢索待辦資訊。

其實個人使用禪道，還可以借鑑專案管理的概念，把自己要處理的事情放在專案裡面進行跟蹤管理，也是非常方便的。比如買房，考研，複習考試等等。

 

3.2.2. 關注需要自己處理的任務、需求、bug

禪道在我的地盤中提供了指派給自己的需求，任務，bug等快捷操作。凡是指派給自己的這些事項，都是需要及時處理的。因此對於每一位使用禪道的朋友來講，每天的工作其實也很簡單，就是將我的地盤中指派給自己的任務、需求或者bug及時處理掉就可以了。

3.2.2.1.我的任務

3.2.2.2.我的bug

3.2.2.3.我的需求

3.2.2.4.我的測試

3.2.3. 通過我的檔案檢視或修改個人資訊

在我的地盤中還有我的檔案一個頁面，在這個頁面可以檢視或者修改自己的個人資訊，包括修改密碼功能。

3.2.3.1.檢視個人資訊

備註：

原始碼提交帳號是該使用者在subversion系統中的提交帳號，主要用來做對照使用。如果沒有使用subversion整合功能，將這個欄位保留為空即可。

3.2.3.2.修改密碼

 

3.3.產品經理篇

3.3.1. 維護產品

產品管理對於公司來講，至關重要。只有做出好的產品或者服務出來，才能贏得市場，謀求發展和生存。所以產品經理的這個位子對於公司來講，是非常關鍵的，相當於公司的大腦，在決定著公司前進的方向。在禪道里面，產品和專案這兩個概念被明確的區分開來。產品是需求方，決定做什麼。專案是執行方，解決的是如何做的問題。而測試則是保障方，解決的是正確的做事情的問題。所以在禪道中，所有的一切都是圍繞產品展開的。產品是整個專案管理活動的核心。

3.3.1.1.建立產品

1. 用產品經理的角色登入禪道。
2. 進入產品檢視，然後點選頁面右側的“新增產品”連結，即可出現新增產品的頁面。
3. 如果系統中還沒有新增產品，系統也會自動跳轉到產品的新增頁面。

新增產品時需要注意的地方：

• 產品代號相當於大家對這個產品的一個隱喻，比如禪道專案管理軟體的程式碼是zentao。
• 產品負責人負責整理和解釋整個產品的需求，制定相應的釋出計劃。
• 測試負責人，可以指定預設的測試負責人。這樣可以適用於公司人比較多，提交bug不知道該給誰的情況。
• 釋出負責人主要的職責是建立釋出。
• 訪問控制，則可以控制訪問該產品的人員列表。比如可以將某一個產品設為私有，只有產品新增者、產品負責人、測試負責人、釋出負責人以及該產品的專案團隊才可以訪問。

3.3.1.2.產品多分支和多平臺功能

禪道7.4.beta版本開始，產品新增多分支和多平臺功能。多分支和多平臺功能使得產品的管理開發更加的清晰明瞭，非常適合一個產品擁有多個平臺和多個分支的管理，這樣需求明確的劃分到某個平臺和分支上，專案關聯開發是就一目瞭然。多分支可以用於某個產品有定製開發的需求，比如某個產品針對不同的行業或者不同的客戶有做二次開發，可以用產品的多分支來做區別管理。

下面給大傢俱體介紹產品多平臺功能。多分支的操作與多平臺是一樣的，可以直接參考。

新增產品時，可以在產品型別裡選擇多分支和多平臺。

產品建立成功後，產品頁面下會顯示多平臺以及維護平臺的選單。

點選 平臺 選單，即可維護平臺，右側可以做新增平臺。

平臺新增成功後，在提需求頁面，所屬產品後可以選擇所屬平臺。

需求建立成功後，在產品→需求頁面，需求名稱前就會顯示所屬平臺的名稱。

如果需求屬於所有平臺，那麼需求名稱前預設不顯示所屬平臺名稱。

在專案→產品關聯產品頁面時，同時可以選擇關聯的產品以及所屬平臺。

選擇了所屬平臺後，專案→需求關聯需求時，可以關聯該產品下所有平臺和專案關聯的產品平臺下的需求。

 

3.3.2. 建立和評審需求

我們產品經理可能都習慣了寫需求設計文件，或者規格說明書，通過一個非常完整的word文件將某一個產品的需求都定義出來。但在禪道里面，我們提倡 按照功能點的方式來寫需求。簡單來講，就是將原來需求設計文件中的每一個功能點摘出來，錄在禪道里面，作為一個個獨立的功能點。如果按照scrum標準走 的話，我們可以稱之為使用者故事(user story)。所謂使用者故事，就是來描述一件事情，作為什麼使用者，希望如何，這樣做的目的或者價值何在，這樣有使用者角色，有行為，也有目的和價值所在，非常方便與團隊成員進行溝通。 

3.3.2.1.建立需求

1. 使用產品經理角色登入系統。
2. 進入產品檢視。
3. 在頁面右側，有“提需求”選單，點選選單，出現新增需求的頁面。

 

• 需求的標題是必填項。
• 所屬計劃和模組，可以暫時保留為空。
• 需求稽核那塊，我們選上不需要稽核，這樣新建立的需求狀態就是啟用的。只有啟用狀態的需求才能關聯到專案中，進行開發。
• 需求可以設定抄送給欄位，這樣需求的變化都可以通過email的形式抄送給相關人員。
• 可以設定關鍵詞，這樣可以比較方便的通過關鍵詞進行檢索。

3.3.2.2.評審需求

在建立需求的時候，有一個“不需要評審”的複選框，如果選中該複選框的話，需求的建立是啟用中的。但大部分情況下面，需求還是需要評審的。即使產品完全有一個人負責，也可以將一些不成熟的想法存為草稿，後續再進行處理。新增需求的評審流程如下：

 

下面我們來看下具體的需求評審頁面：

• 評審結果可以選擇確認通過、有待明確、拒絕等操作。如果選擇“確認通過”，則需求的狀態改為“啟用中”，然後就可以關聯到專案中進行開發了。
• 如果選擇“有待明確”，會保持需求的草稿狀態，並將需求指派回需求的建立者頭上，有其繼續進行完善。
• 如果選擇了“拒絕”，則需要給出相應的拒絕原因，拒絕原因可以有：

• 由誰評審是記錄的參與評審的人員名單，可以輸入使用者名稱來自動篩選。一般來講需求評審可以是一個線下的評審會議，在禪道里面記錄下參與需求評審的人員即可。

3.3.3. 變更和評審需求

變更是需求管理必不可少的流程，禪道專案管理軟體對需求的變更提供了全面的支援。其實需求的變更並不可怕，但不清楚影響範圍的變更是很可怕的。在傳統專案管理中，由於沒有有力工具的支撐，產品經理在變更需求的時候，無法知曉該需求的影響範圍，會有很大的隨意性。禪道專案管理軟體將需求、任務、bug和用例都納入為一體管理，就可以很清楚的知曉變更的影響範圍，從而給產品經理更好的指導。

禪道里面需求變更的基本流程如下：

 

下面我們來看下具體的操作：

3.3.3.1.變更需求

禪道專門提供了需求的變更流程。凡是對需求標題、描述、驗證標準和附件的修改，都應該走變更流程。變更之後的需求狀態為變更中。

• 編輯操作是無法修改需求的標題、描述、驗收標準和附件的。
• 在變更需求的時候，如果選擇了“不需要評審”，則需求狀態自動變成啟用，不需要再走評審流程。
• 在變更需求的時候，會列出該需求的影響範圍：

 

3.3.3.2.評審需求

1. 通過需求的詳情頁面檢視變更前後的變化

2. 評審需求，給出評審結果

• 評審結果可以選擇確認通過，撤銷變更，有待明確或者拒絕。如果選擇確認通過，則需求的狀態從“已變更”變為“啟用中”。
• 如果選擇撤銷變更，則取消當前的變更，並回退到之前的版本。
• 如果選擇有待明確，需求被打回到需求的變更者，繼續進行完善。
• 如果選擇拒絕，則需要給出相應的拒絕原因。
• 同樣在評審需求的時候，也會列出相應的影響範圍，評審者可以參考。

3.3.3.3.確認需求變更

當需求變更被確認之後，研發團隊和測試人員需要確認需求的變更。

1. 任務確認需求變動

 2. Bug確認需求變動

 3. 用例確認需求變動

 

3.3.4. 需求的狀態和研發階段

禪道軟體設計的需求有兩個欄位來跟蹤它的變化，一個是需求的狀態欄位，一個是需求的研發階段欄位，下面來看下這兩個欄位。

3.3.4.1.需求的狀態

需求狀態(status)欄位，總共有四種狀態，分別是草稿(draft)、啟用(active)、已變更(changed)和已關閉(closed)。對應為需求的流程操作共有：建立、變更、稽核、關閉、啟用，其狀態流轉圖如下：

 

3.3.4.2.需求的研發階段

需求還有一個階段(stage)欄位，用來描述啟用的需求在研發過程中所處的階段。目前總共有未開始、已計劃、已立項、開發中、開發完畢、測試中、測試完畢、已驗收、已釋出。

那麼需求的研發階段是如何變化的呢？一種方案是通過編輯操作，來修改研發階段。但我們更提倡另外一種方案，就是在建立任務的時候，仔細設定任務的型別，比如開發，測試。禪道的程式會自動根據不同型別任務的變化來自動計算需求的研發階段，其規則如下：

1. 如果需求沒有關聯到專案，也沒有關聯到計劃，則需求的研發階段是"未開始"。
2. 如果需求關聯到了計劃，還沒有關聯到專案中，則需求的研發階段是"已計劃"。
3. 如果需求關聯到了專案中，但還沒有分解任務，則需求的研發階段是"已立項"。
4. 如果需求關聯到了專案中，且進行了任務分解:
   如果有一個開發任務進行中，並且所有的測試任務還沒有開始，需求的研發階段為“研發中”。
   如果所有的開發任務已經完成，並且所有的測試任務還沒有開始，則為“研發完畢”。
   如果有一個測試任務進行中，則視為“測試中”。
   如果所有的測試任務已經結束，但還有一些開發任務沒有結束，則視為"測試中"。
   如果所有的測試任務已經結束，並且所有的開發任務已經結束，則視為"測試完畢"。
5. "驗收"階段是需要產品經理手工來進行確認的。
6. 產品→釋出中關聯的需求後，需求的研發階段是“已釋出”。

需求所屬產品為多分支或多平臺型別的所處階段說明：

以多平臺為例，該產品有安卓、ios兩個平臺。

（1）如果需求沒有關聯到專案，也沒有關聯到計劃，則需求的研發階段是“未開始”。

（2）如果需求屬於所有平臺，關聯的計劃也屬於所有平臺，則需求的階段為“所有平臺：已計劃”。如果計劃屬於ios平臺，則需求的階段為“ios：已計劃”。如果需求屬於某個特定平臺，階段計算方式等同原來的普通產品的情況。

（3）如果專案關聯的是產品的某個平臺，假如關聯了ios平臺，同時關聯了產品所有平臺下和ios平臺下的需求，沒有分解任務。則ios平臺下的需求此時階段都是“已立項”，所有平臺的需求則是“ios：已立項”。假如該需求所有平臺還是“已計劃”，則顯示“所有平臺：已計劃”“ios：已立項”。

如果一個需求同時被兩個專案關聯，而兩個專案，一個關聯了產品的ios平臺，一個關聯了所有平臺。同時都沒有分解任務，那麼這個需求的階段就是“所有平臺：已立項”“ios：已立項”。

注：禪道7.2.stable版本開始，可以編輯需求手動更改需求的所處階段。

點選需求標題，進入需求詳情頁面，點選編輯需求，在頁面的右側顯示需求的基本資訊，需求所處階段一欄點選下拉選中你要修改的需求所處階段，儲存即可。

再回到產品---需求列表頁面，就可以看到需求的所處階段已經由已立項變為測試中了。

 

3.3.5. 需求的注意事項

3.3.5.1.禪道中需求的寫法

在禪道中，我們預設給大家提供了一個需求的模板：作為一名<某種型別的使用者>，我希望<達成某些目的>，這樣可以<開發的價值>。這個模板是借鑑自scrum開發裡面的使用者故事(user story)的寫法。只不過我們使用了相對比較中性的概念。

在這個模板中，總共有三個元素：角色，要做的事情，價值或者原因。我們平時在寫需求的時候，往往會忽略角色和價值原因這兩個元素，只關注了要做的事情。其實這有很多的問題。不進行使用者角色的劃分，會影響對產品功能的設計和定位，從而導致產品往往是給一個使用者角色開發的，就是產品經理自己。:)而忽略開發的原因或者價值，會讓開發人員感到困惑。他們可能並不理解你這樣做的原因或者目的，不理解的需求實現起來自然會有問題。 

3.3.5.2.需求的INVEST原則

除了上面基本的模板之外，在撰寫使用者故事的時候，可以參考INVEST原則：(摘自http://duweizhong.blogbus.com/logs/112151436.html)

• I dependent(獨立的):一個使用者故事對於另一個使用者故事應該是獨立的（儘可能的）。故事之間的依賴性使得增加了計劃編制，確立有限級，故事估計這些工作非常困難。通常，可以通過組合使用者故事或者分割使用者故事來減少依賴性。
• N egotiable(便於溝通的):一個使用者故事是便於溝通的。一個故事的卡片是包含故事詳情的簡短描述。這些詳情是通過討論階段來完成的。一張還有很多詳情的卡片實際上減少了和客戶的會談。
• V aluable(有價值的):每個故事必須對客戶具有價值（無論是使用者還是購買方）。一個讓使用者故事有價值的好方法是讓客戶來寫下它們。一旦一個客戶意識到一個使用者故事並不是一個契約而且可以進行協商的時候，他們將非常樂意寫下故事。
• E stimable(可估計的):開發者需要去估計一個使用者故事以便確定有限級並對故事進行規劃。但是讓開發者難以估計故事的問題來自：對於領域知識的缺乏（這種情況下需要更多的溝通），或者故事太大了（這時需要把故事切分成小些的）。
• S mall(短小):一個好的故事應該在工作量上短小，描述具有代表性，而且不超過2-3人周的工作量。超過這個範圍的使用者故事，將會在劃分範圍和估計時出現很多錯誤。
• T estable(可測試的) :一個使用者故事是可測試的來用於確認完成，記住，我們不開發不能測試的故事。如果你不能測試那麼你永遠不知道你什麼時候是完成了。一個不可測試的使用者故事例子：軟體應該是易於使用的。

一個編寫良好的使用者故事是敏捷開發的基礎。它們應該相互獨立，詳情應該便於開發者和使用者進行溝通，應該對使用者有價值，應該對於開發者來說盡可能的清晰以便進行估計，應該短小，通過預定義測試用例的使用確保它是可以測試的。

3.3.5.3.禪道里面的需求和原型圖、需求設計文件的區別

傳統管理模式中，很多產品經理都在用原型圖軟體設計原型圖或者非常完整的需求設計文件。設計完之後，交給設計人員進行頁面設計，然後由開發人員合併程式碼。那麼原型圖和使用者故事之間的關係和區別是什麼呢？

• 和user story相比，原型圖或者需求設計文件是一個整體，可以給人巨集觀的把握。這是原型圖的優點。比較直觀。
• 它是一個整體，所以就沒有辦法進行分解。你不可能分解成，做頁面導航條，做頁面的中間部分等。
• 沒有分解，所以原型圖也就沒有辦法進行優先順序的排序。比如頁面部分，有的很重要，有的不重要。但在原型圖裡面是體現不出來優先順序的。
• 沒有分解，自然也就無法進行跟蹤。你沒有辦法得知原型圖完成了多少。
• 過於死板，給設計人員和開發人員留下的發揮的空間太少，後演變成被動執行。
• 需求設計文件規定的比較細緻，會讓產品經理陷入太多的細節，對整體的把握會減弱。

雖然相比較於使用者故事而言，傳統的原型圖或者需求設計文件有一些不足，但在實際的開發過程中，二者可以相輔相成。禪道從1.2版本中，已經增加了文件庫管理。可以將原型圖作為設計文件，上傳到某一個產品相關的文件庫中，和使用者故事相互配合，是一個好的方案了。

3.3.6. 維護產品模組

新增完產品之後，就需要來設定產品的模組。模組相當於對產品需求的一個分類，通過組織模組，可以讓大家對產品有一個巨集觀的把握和認識，也方便對需求進行分類和整理。

 

設定模組的步驟：

1. 使用產品經理角色進入產品檢視。
2. 選擇要維護的產品。
3. 點選選單中的“模組”。

• 維護模組的時候是一級級進行維護的。比如可以選擇"我的地盤"，然後維護它的子模組。
• 右側的數字是用來排序的，可以將通過調整模組的排序欄位來調整它在模組樹裡面的位置。
• 可以選擇某一個模組編輯，編輯的時候可以修改它所屬的上級模組。

產品模組同步顯示的問題：

禪道從5.2.1版本開始，產品的模組可以同步到專案任務、測試Bug和用例裡。

專案任務、測試Bug和用例也可以單獨維護自己的模組。需要注意的是產品模組同步到專案任務裡是有條件的。

 

專案→任務裡顯示模組的規則：

1、專案中關聯的需求在產品中的模組。比如產品模組A下面有4個需求，專案都沒有關聯，那麼在專案中是不會顯示模組A的，只要關聯了4個需求中的任何一個及以上，專案模組就可以顯示模組A。

2、建立任務的時候可以選擇產品的某個模組（即使沒有關聯該模組下面的需求建立任務的時候也可以關聯），建立任務後也會顯示出該模組。

3、專案也可以維護自己的模組：專案→任務頁面 左側點選維護模組，可以新增維護專案自己的模組。

最新版本禪道，新增了列表頁顯示模組名的功能。（如果新增模組時有填寫模組簡稱，那麼就顯示模組名簡稱。）

產品需求列表頁面左側的模組顯示欄下有“列表頁是否顯示模組名”的編輯按鈕。

禪道里預設列表頁不顯示模組名，點選進入選擇框，選擇只顯示一級模組。

儲存成功後，需求的列表頁的顯示如下。

需求名稱前顯示有該需求所屬模組的名稱。如果該需求不屬於任何模組，就不顯示模組名。

還可以選擇 只顯示最後一級模組，點選儲存。

設定成功後，在需求列表頁面需求的名稱前即只顯示最後一級模組的名稱。

 

3.3.7. 建立釋出計劃

古人云，凡事預則立，不預則廢。產品需要做規劃，才能有輕重緩急，才能正確的做事。因此對於產品經理而言，計劃是必需的。

• 對於產品經理自己而言，釋出計劃可以幫助他規劃產品，制定釋出的節奏，調整需求的優先順序。
• 對於公司其他部門的同事以及外部的客戶而言，釋出計劃可以讓他們知曉產品的進展情況，以便做好相應的安排。
• 同時在專案關聯需求的時候，計劃可以幫助需求的關聯。

3.3.7.1.建立計劃

1. 進入產品檢視，選擇某一個產品。
2. 點選“計劃列表”
3. 出現計劃列表頁面，點選頁面右側的“建立計劃”，即可出現計劃增加頁面。 

3.3.7.2.關聯需求

建立完計劃之後，可以為計劃關聯需求

也可以在新增需求的時候指定計劃(已經過期的計劃不會列出)

 

3.3.7.3.計劃和專案之間的關係

禪道軟體中計劃和專案並沒有非常強的對應關係。如果某一個開發團隊的計劃和執行都非常好，那麼一個計劃可以對應一個專案。但這是非常理想的狀態。一般情況下面是這樣，在專案關聯需求的時候，大部分的需求都關聯自一個計劃，但同時也關聯了其他計劃的部分需求。

3.3.8. 建立釋出

專案結束後產品人員的一個工作就是建立釋出，通過建立釋出，可以告訴公司其他相關的部門，他們可以在新版本產品的基礎上開展工作。同時也是鼓舞團隊士氣非常好的一個手段。

3.3.8.1.建立釋出的前提

建立釋出有兩個前提：

1. 該產品有關聯過專案。
2. 該專案有建立過版本。可以參考http://www.zentao.net/help-read-79213.html

3.3.8.2.如何建立釋出

1. 進入產品檢視，選擇釋出列表。
2. 然後點選“建立釋出”，即可出現建立釋出的頁面。
3. 如果產品是有多分支/多平臺的，可以選擇在哪個分支/平臺下建立釋出。

如果是沒有使用多分支/多平臺的，可以忽略上面的操作，直接點選右上角的“建立釋出”操作。

建立成功後，即可關聯需求和Bug。

• 選擇了版本之後，系統會自動計算這個版本所對應的專案中完成的需求和解決的bug，可以進行關聯選擇。
• 如果系統自動計算的需求和bug不完整，可以在描述欄位裡面補充。

禪道7.4.beta版本開始，新增了釋出的停止維護功能。

在產品--釋出列表頁面，右側的操作按鈕有停止維護按鈕，點選操作即可。

停止維護的釋出版本，在禪道系統裡是預設不顯示了的。

3.3.9. 路線圖

禪道軟體中，計劃和釋出組成了產品的路線圖，通過路線圖可以非常直觀的瞭解產品過去釋出過的版本和將來的計劃。如下圖，綠色的部分代表了釋出過的版本，黃綠色的部分代表了將來的計劃。點選某一個釋出或者計劃，可以檢視其具體的需求資訊。

3.3.10.    文件管理

禪道軟體內建了基本的文件管理功能，這樣禪道沒有覆蓋到的流程就可以通過文件管理功能來補充。禪道文件庫共分為三種類型：產品文件庫、專案文件庫和自定義文件庫。其中產品文件庫用來儲存產品層面產生的文件，專案文件庫用來儲存專案過程中產生的文件。自定義文件庫則可以用來儲存知識庫、公司管理規範等文件。下面讓我們來看下具體的操作。

3.3.10.1.維護分類

1. 進入文件檢視。
2. 選擇產品文件庫。
3. 然後選擇頁面下方的“維護分類”連結，即可出現維護分類的的頁面。

3.3.10.2.新增文件

在產品檢視，點選頁面右側的“建立文件”，即可進入文件的建立頁面。

• 文件共有檔案、連結和網頁三種類型。
• 檔案型別的文件可以上傳一個附件。
• 連結型別的文件可以是一個網頁連結。
• 網頁型的文件可以直接使用富文字編輯器撰寫。

3.3.10.3.瀏覽文件

文件新增之後，可以在文件庫裡面檢視相應的文件列表。

也可以在產品檢視的文件庫裡面檢視這個產品下面的所有文件。

3.3.11.    主持產品會議

按照scrum的管理流程，開發團隊需要定期召開迭代計劃會議。計劃會議一般控制在一天之內結束，共分為兩個部分。其中第一個部分主要由產品經理負責講解需求，確定需求的優先順序，決定本期專案要完成的需求列表。然後下午由研發團隊對需求進行任務分解。

產品計劃會議的流程如下：

1. 由專案經理提前準備，告訴大家會議的具體的時間和地點。
2. 產品經理可以事先對需求做一個劃分，將本期專案計劃要實現的需求事先關聯到專案中。(如果需求太多，來不及一一講解)
3. 然後由產品經理給大家做需求的講解，與會的成員應當認真聽講，並提出自己的意見.
4. 每一個需求講解完畢之後，大家對需求的工作量進行估計，並根據需求的工作量確定每一個需求的優先順序。
5. 然後按照需求優先順序的高低以及工作量的大小，對關聯到專案中的需求做調整：將不需要實現的移除，關聯新的需求。

計劃會議的產出：這個計劃會議我們需要拿到的結果就是專案檢視的需求列表。

計劃會議對應到禪道軟體就是專案的關聯需求操作：

 

3.3.12.    參與專案管理、演示和總結

很多公司的產品經理容易犯的一個錯誤就是專案開始之後，找不到產品經理了。就拿筆者之前所在的公司來講，產品經理只是在計劃會議上面給我們講解下需求，然後專案開始之後，就消失了。其實這樣很不好，會造成很多的問題：

1. 首先，單純的靠文字描述和計劃會議，不可能保證100%的人員100%的理解正確，很有可能會有理解偏差的情況。所以產品人員應該隨時瞭解專案進展情況，隨時發現問題，隨時解決問題。
2. 其次，產品經理不參與專案過程，很容易造成產品經理和開發團隊的對立，不利於團隊的發展。而且很容易扯皮，大家互相推諉責任。

因此，產品經理在專案開始之後，應當隨時瞭解專案的進展情況：參與團隊的例會，在禪道里面通過專案檢視瞭解任務進展，通過bug檢視缺陷情況，需求完成之後及時檢查確認等等。

在專案開發完成之後，產品人員應當對本期所作的需求進行確認，以保證是自己想要的東西。同時應當積極參加團隊召開的演示會議，聽取大家的意見和反饋，並整理成相應的需求，錄入到禪道中。

產品經理還應當積極參加專案的總結會議，吸取經驗教訓，調整下一步的工作。

3.3.13.    需求的基本統計報表

針對一些公司需要對產品需求進行統計的情況，禪道專案管理軟體從2.0版本開始，提供了需求的基本統計報表功能。在產品檢視下的需求子欄目，點選“統計報表”連結，即可根據需要進行需求的統計，包括：

1.  產品需求數量。

2. 模組需求數量。

3. 按照計劃進行統計。

4. 按照狀態進行統計。

5. 按照所處階段進行統計。

6. 按照優先順序進行統計。

7. 按照預計工時進行統計。

8. 按照由誰建立來進行統計。

9. 按照當前指派來進行統計。

10. 按照關閉原因來進行統計。

11. 按照變更次數來進行統計。(根據版本號來進行計算，版本號 - 1為變更次數)

 

3.4.專案經理篇

3.4.1. 建立專案

很多朋友使用禪道之後經常問的一個問題就是產品和專案的關係。就像前面的《禪道和scrum的對應關係》這篇文章所描述的那樣，禪道里面的專案其實對應的是敏捷開發裡面的迭代的概念。只不過我們為了大家更容易理解和接受，還是沿用了傳統的專案的概念。

建立專案

1. 進入專案檢視，點選右側的”新增專案“連結。

2. 出現專案新增的頁面

在這個頁面設定專案名稱、代號、起止時間、可用工作日、團隊名稱、專案目標和專案描述等欄位。其中關聯產品是可以為空的。

注意事項：

1. 專案代號是一種隱喻，也就是團隊內部可以互相瞭解和知曉，比如禪道專案曾經使用過“opensesame"來作為專案的代號。
2. 團隊名稱，可以自己定義，比如叫做“禪道開發團隊”等等。
3. 在新增專案的時候，可以選擇關聯與之相關的產品，以便後續進行需求的關聯。
4. 專案可以控制它的訪問許可權，分為預設、私有和自定義白名單三種。

3.4.2. 組建專案團隊

專案組建之後要做的事情就是設定團隊。很多朋友經常問，為什麼我在建立任務的時候，只能指派給自己呢？其實原因很簡單，是因為沒有設定團隊。

當專案建立成功之後，可以根據提示設定團隊。

或者從專案檢視中的團隊選單，也可以進行專案的團隊管理。

在維護專案團隊的時候，需要選擇都是哪些使用者可以參與到這個專案中，同時需要設定這個使用者在本專案中的角色（角色可以隨便設定，比如風清揚，冬瓜一號等）。可用工作日和可用工時每天需要仔細設定。通常來講，一個人不可能每天8小時投入，也不可能一星期七天連續投入。

設定完畢之後，系統會自動計算這個專案總得可用工時。

  當團隊設定完畢之後，整個專案的可用資源就已經確定了：起止時間確定了，參與的人員也確定了。下面就是來確定專案中要做的事情了。

3.4.3. 確定專案要完成的需求列表

專案團隊組建完畢之後，接下來要做的一個工作就是確定這期專案要做的需求。這項任務其實是整個團隊，包括產品在內，共同完成的。確定的過程應該是線下的產品計劃會議，請參考：http://www.zentao.net/book/zentaopmshelp/140.html

3.4.3.1.關聯產品

如果在建立專案的時候，已經關聯過產品，可以忽略這個步驟。

1. 以專案經理身份登入。
2. 進入專案檢視。
3. 點選“關聯產品”按鈕。然後點選該專案相關的產品即可。

3.4.3.2.關聯需求

1. 在關聯需求的時候，可以按照優先順序進行排序。
2. 關聯的需求狀態必須是啟用的（評審通過，不能是草稿）

3.4.4. 組織進行任務分解

需求確定之後，專案中幾個關鍵的因素都有了：週期確定、資源確定、需求確定。下面我們要做的事情就是為每一個需求做wbs任務分解，生成完成這個需求的所有的任務。note:是完成需求的所有任務，這裡麵包括但不限於設計，開發，測試等。

3.4.4.1.訪問專案的需求列表頁面：

•  在專案的需求列表頁面，可以很方便地對某一個需求進行任務分解。
• 同時還可以檢視這個需求已經分解的任務數。

3.4.4.2.分解任務

• 這時候建立任務的時候，就可以選擇需求了。
• 我們同時提供了需求檢視的連結。
• 如果需求和任務的標題是一樣的，可以通過”同需求“按鈕快捷的複製需求的標題。

3.4.4.3.任務分解的幾個注意事項

1. 需要將所有的任務都分解出來。這裡麵包括設計，開發，測試，美工，甚至包括購買機器，部署測試環境等等。
2. 任務分解的粒度越小越好，比如幾個小時就可以完成。
3. 如果一個任務需要多個人負責，繼續考慮將其拆分。
4. 事務型的事務可以批量指派，比如需要讓團隊裡面的每一個人都寫個專案總結，可以選擇型別是事務，然後批量指派給團隊裡面的所有人員。
5. 任務的型別請仔細設定，這個會涉及到需求研發階段的自動計算。後面我們會有講解。
6. 任務的分配好是自由領取，這樣可以大程度上調動大家的積極性。
7. 任務的分解好是由團隊共同完成，不要由專案經理一人包辦。

3.4.5. 召開每天的站立會議

專案任務分解完畢之後，整個專案要完成的任務也都已經確定，每個人負責的任務也確定。這時候就進入到每天的迭代過程。專案經理的一個職責就是每天負責召開站立會議。

具體的形式如下：

1. 每天固定時間召開。
2. 專案團隊成員站立在一起開會。
3. 每個人講述三件事情：昨天做了什麼，今天計劃做什麼。有沒有什麼問題。
4. 會議控制在15分鐘之內結束。

注意事項：

1. 不要坐著開會。
2. 站立會議不要試著解決問題，大家更多的是溝通互相的進度，而不是解決具體的問題。具體的問題，會後討論。
3. 控制會議時間，不要超過15分鐘。
4. 站立會議不是彙報會議，而是大家的溝通。及時發現問題。
5. 非專案團隊成員可以參加，但不能發言。

3.4.6. 通過燃盡圖瞭解專案的進展

專案團隊成員除了每天的編碼工作、參加站立會議之外，還有一個工作就是在禪道里面更新自己所負責任務的狀態以及它的預計剩餘時間。然後禪道系統會根據專案中所有任務預計剩餘的時間累加起來，繪製成燃盡圖。燃盡圖的英文名字叫做 burn down chart，先來看一個例子：

• 此圖橫軸為日期，縱軸為工時數。
• 工時數乃專案中所有任務剩餘工時的總和，每天計算一下，形成座標，然後把線連線起來，形成此燃盡圖。
• 新版本的禪道，燃盡圖可以設定是否顯示週末，還可以修改專案首天工時。修改首天工時，需要到組織--許可權裡分配。
• 燃盡圖的更新，需要配置定時任務，具體請參考http://www.zentao.net/help-read-79063.html

燃盡圖和甘特圖的區別：

禪道核心的管理理念是基於scrum的。所以它的主要工具是燃盡圖，而不是甘特圖。這也恰恰反映了兩種截然不同的管理思路。甘特圖需要嚴格的設定過 任務的起止時間和前置關係，是一種控制式的管理。而燃盡圖則更關注於做完整體的專案還剩下多少時間。所以在我們開源版本里面我們更提倡大家用好燃盡圖。

3.4.7. 通過各種列表的各種功能瞭解專案進展

其實做好專案管理也很簡單，做到資訊公開、透明，很多事情自然而然就會變得簡單。除了每天召開站立會議，更新燃盡圖之外，專案經理還可以通過專案的各種列表功能來掌握專案的進展情況：

3.4.7.1.首頁的專案進展列表

禪道軟體在首頁提供了進行中的專案的概況列表。通過這個列表，可以很方便的知道目前整個公司正在進行的專案的進展情況。這個圖裡面的進度是按照總消耗/(總消耗 + 總剩餘)計算出來的一個工時的進度。

3.4.7.2.專案檢視的所有專案列表

首頁的專案列表只是正在進行中的專案，我們在專案檢視中，還提供了所有專案進展情況的列表。

 

3.4.7.3.通過任務列表檢視具體的任務的進展情況

1. 可以通過各種檢索標籤來

2. 可以通過分組檢視，來按照不同的欄位進行分組

3.4.7.4.通過專案任務樹狀圖，瞭解專案需求和任務的開發情況。

禪道開源版8.2beta版本新增了任務的樹狀圖功能。可以清晰的顯示專案所關聯的需求，需求和任務的關聯關係以及任務的開發情況。

滑鼠放在任務標題上，會顯示任務的狀態，工時資訊，以及操作按鈕。

 

3.4.8. 召開演示會議和總結會議

3.4.8.1.演示會議

在專案結束之後，專案經理應該召開相關人員（團隊，以及其他相關的部門，領導，或者合作伙伴等等）召開演示會議。演示會議的目的旨在向大家展示本期專案團隊所取得的成果，這是一個提高團隊士氣、增加成就感的非常好的方式，也是聽取反饋，調整下一步計劃的方式。

演示會議不用特別正式，它不是彙報會議。不用準備精美的ppt，只需要有一個大螢幕，然後團隊的成員分頭介紹自己所負責的東西。在演示過程中，會有人提出很多的問題或者建議，產品經理應當將其記錄下來，轉換為後面的需求。

3.4.8.2.總結會議

演示會議完之後，團隊內部應該召開總結會議。這個會議的參與人員主要是團隊成員了。該會議的注意議題是總結這次專案我們做的好的地方，做的不好的地方。要將其記錄下來，存到文件管理中，比如叫做第幾期專案總結。然後確定下一期專案要解決的問題，可以重點解決一個，比如開發環境的問題。

 

3.4.9. 專案任務基本的報表統計

禪道專案管理軟體提供了基本的專案統計功能，專案經理可以通過這個功能來掌握一些巨集觀的資訊：

• 按照所屬專案進行統計。
• 按照指派給進行統計。
• 按照任務型別進行統計。
• 按照優先順序進行統計。
• 按照截止日期進行統計。
• 按照初預計進行統計。
• 按照預計剩餘進行統計。
• 按照已經消耗進行統計。
• 按照由誰完成進行統計。
• 按照關閉原因進行統計。
• 按照每天完成任務數進行統計。

需要注意的是：禪道的統計報表是根據你當前的列表範圍進行統計的。比如你現在檢視的是進行中的任務，那麼統計就是在所有進行中的任務列表中進行的。換言之，你可以通過切換不同的檢索條件來獲得你想要的統計報表。

 

3.5.開發團隊篇

3.5.1. 參加專案計劃會議，分解任務

按照scrum的流程，專案團隊成員要參加產品的計劃會議和專案的任務分解。

       在參加產品計劃會議的時候，應當充分理解需求，並發表自己的意見，以確保自己對每一個需求理解都是正確的。

專案計劃會議的主要任務是對需求進行任務分解，團隊成員應全力參與。分解任務之後，自願領取自己喜歡的任務。

注意：這個地方的團隊成員，不僅僅是開發人員，也包括測試人員，dba，即所有的專案團隊中的成員。

 

3.5.2. 領取任務並每天更新任務

當專案的任務分解完畢之後，專案團隊成員需要領取自己喜歡做的任務，開始每天的開發。除了日常的編碼工作之外，還應當每天花點時間在禪道里面更新下任務的狀態以及消耗情況。

3.5.2.1.領取任務

按照scrum的原則，好是大家領取自己喜歡做的任務，這樣才能更好的調動團隊的積極性。有的朋友會問，如果沒有人領取怎麼辦？大家都挑簡單的怎麼辦？一個新手挑選了一個關鍵任務怎麼辦？每個人的任務量不太均衡怎麼辦？其實這些問題都不是問題。因為資訊是公開透明的，一個個體不可能每一期都只挑簡單的任務，做簡單的事情。當然了，專案經理巨集觀層面的把握也必不可少，尤其是一些關鍵任務，需要平衡下。

領取任務可以通過兩種方式，一種是通過“指派”操作，一種是通過“編輯”操作。

3.5.2.2.更新任務狀態

專案開始之後，每個人每天應當及時更新自己所負責的任務的狀態。禪道提供了幾個快捷的操作按鈕：開始、完成、關閉、取消和啟用。

開始、完成和取消沒有什麼歧義。解釋下關閉和啟用。

禪道有一個可選流程，就是當任務完成之後，會自動指派回任務的建立者頭上，這時候任務的建立者可以驗證任務是否完成。如果完成，則將任務關閉。如果任務沒有完成，則啟用任務。這個流程是可選的，不是必須的流程。適用於傳統的命令-控制式的管理。如果對於敏捷開發團隊來講，忽略這個流程即可。

3.5.2.3.更新任務的消耗

除了更新自己負責任務的狀態之外，還應該及時更新任務的工時消耗情況：

• 初預計，即建立任務的時候的初預計。該欄位在任務開始之後，不應該再進行修改。這個欄位當任務結束之後，可以和已經消耗欄位進行對比，以糾正自己的估計。
• 已經消耗，則是你在這個任務上所有花費的工時數。
• 預計剩餘，則是你預計這個任務完成大約還需要多少時間。如果預計剩餘為0，則表示任務完成。

這裡面需要特別強調的是，初預計 ≠ 已經消耗 + 預計剩餘。

一定要每天更新自己所負責的任務，因為燃盡圖的繪製，就是通過預計剩餘這個欄位來計算的。

 

3.5.3. 建立版本

當完成若干功能之後，就可以建立版本了。版本的概念在英文裡面是build，可以對應到軟體配置管理的範疇。這是一個可選流程，但還是建議團隊能夠實施版本管理。這個版本主要的作用在於明確測試的範疇，方便測試人員和開發人員的互動，以及解決不同版本的釋出和bug修復等問題。

有的同學會問，既然是版本管理，那麼禪道能不能管理原始碼？禪道當然是無法管理原始碼了，呵呵，這是非常專業的一個事情，已經有非常好的開源軟體來解決這個問題。比如subversion和git。大家可以根據自己實際的需要部署安裝。禪道里面的版本是做了一個記錄。

流程如下：

1. 首先是團隊經過開發，完成了若干需求，或者解決了一些bug。
2. 這時候某一位釋出負責人在subversion或者git中建立了一個tag(標籤)，比如禪道的tag目錄如下：

1. 建立了tag之後，這位釋出負責人就可以在禪道里面建立一個版本了。

注：新版本的禪道，先建立版本，儲存成功後，在版本的詳情頁面再關聯需求和Bug。

如果在版本詳情頁面沒有看到關聯按鈕，那麼聯絡管理員到組織→許可權裡分配相關許可權。

說明：

1. 名稱編號，團隊應該有自己的配置管理規範。比如可以是產品名_版本號_狀態(stble, beta之類)_日期
2. 不同開發語言其版本的存在形式也不同，有的需要編譯，有的只需要原始碼。請根據公司的實際情況來填寫原始碼地址，或者是儲存地址。
3. 新版本的禪道，先建立版本，然後再關聯需求和bug。關聯需求和bug後提交給測試人員進行測試的時候，就可以明確這次測試的範疇，測試可以更加有針對性。
4. 描述欄位可以填寫一些測試的注意事項、重點內容等。

 

3.5.4. 申請測試

當版本建立完畢之後，就可以提交給測試人員進行測試了，提交測試會生成一個測試任務。在這兒需要和大家解釋下這個測試任務的概念。其實英文裡面裡面比較合適的單位是testrun，但翻譯到中文裡面沒有太貼切的詞語，我們暫時用了測試任務的概念。但這個測試任務和專案裡面建立的型別為“測試”的任務沒有直接關聯。請大家在使用的時候，注意這個細節。

一般來講，我們在分解任務的時候，可以建立若干測試型別的任務，比如測試某某，測試某某，大概估計下測試需要的時間。然後具體的測試工作通過測試檢視的測試任務來跟蹤。

 

申請測試的步驟：

1. 進入專案檢視，點選“測試”。
2. 然後選擇“提交測試”，即可出現提交測試的頁面。

說明：

1. 負責人為本次測試的負責人。
2. 可以指定這次測試預計起止的時間。
3. 任務描述裡面，可以註明此次測試需要注意的地方。
4. 還需要說明的一點是，目前測試任務還沒有指派的功能，所以需要大家線下通知測試團隊的負責人，由他來負責組織相應人員來進行測試。或者是在專案--任務裡建立測試型別的任務，指派給相應的測試人員。

3.5.5. 解決bug

提交測試之後，測試人員展開測試，便會有bug產生。這時候研發團隊的一個重要職責便是解決bug。禪道里面bug的處理流程比較簡單：

       測試人員提交bug => 開發人員解決bug => 測試人員驗證關閉，這是比較正常的流程。還有一個流程是啟用流程：

測試人員提交bug => 開發人員解決bug => 測試人員驗證未通過 => 啟用bug => 重新解決 =>驗證關閉。

開發人員所需要做的事情便是處理自己負責bug，並在禪道中登記解決方案：

1. 專案檢視中的bug列表

相關推薦