1、2020年4月19日禪道使用手冊文檔僅供參考禪道使用說明禪道是第一款國產的優秀開源項目管理軟件。它集產品管理、項目管理、質量管理、文檔管理、組織管理和事務管理于一體，是一款功能完備的項目管理軟件，完美地覆蓋了項目管理的核心流程。先進的管理思想，合理的軟件架構，簡潔實效的操作，優雅的代碼實現，靈活的擴展機制，強大而易用的api調用機制，多語言支持，多風格支持，搜索功能，統計功能。系統概述禪道的功能列表：1.產品管理：包括產品、需求、計劃、發布、路線圖等功能。2. 項目管理：包括項目、任務、團隊、build、燃盡圖等功能。3. 質量管理：包括bug、測試用例、測試任務、測試結果等功能。4. 文檔管

2、理：包括產品文檔庫、項目文檔庫、自定義文檔庫等功能。5. 事務管理：包括todo管理，我的任務、我的Bug、我的需求、我的項目等個人事務管理功能。6. 組織管理：包括部門、用戶、分組、權限等功能。7. 統計功能：豐富的統計表。8. 搜索功能：強大的搜索，幫助您找到相應的數據。9. 靈活的擴展機制，幾乎能夠對禪道的任何地方進行擴展。10. 強大的api機制，方便與其它系統集成。禪道使用流程圖:最簡使用說明禪道的定位不是簡單的任務管理軟件，而是專業的協同管理軟件。研發類的項目管理本身具有其復雜性，因此禪道提供的都是必備的功能。但這并不意味著必須按照禪道的流程來使用，完全能夠按照自己的實際情況來使用

3、禪道。下面將介紹使用禪道的最簡單方式。2.1 HYPERLINK 使用禪道來進行項目任務管理2.1.1創立項目進入項目視圖，點擊右側的”新增項目“鏈接。 出現項目添加的頁面在這個頁面設置項目名稱、代號、起止時間、可用工作日、團隊名稱、項目目標和項目描述等字段。其中關聯產品是能夠為空的。2.1.2設置團隊點擊保存按鈕，會提示項目創立成功，然后能夠選擇設置團隊。 或者從項目視圖中的團隊菜單，也能夠進行項目的團隊管理。在維護項目團隊的時候，需要選擇都是哪些用戶能夠參與到這個項目中，同時需要設置這個用戶在本項目中的角色（角色能夠隨便設置，比如風清揚，冬瓜一號等）。可用工作日和可用工時每天需要仔細設置。

4、一般來講，一個人不可能每天8小時投入，也不可能一星期七天連續投入。設置完畢之后，系統會自動計算這個項目總得可用工時。2.1.3分解任務設置了團隊之后，下一步操作就是創立任務。在創立任務的時候，指派給是從項目團隊成員中讀取。姓名列表中的首字母能夠用來快速篩選用戶。任務的優先級、預計工時（單位小時）都需要進行設置。如果需要設置任務必須在某一個時間點截止，能夠設置截止日期。能夠上傳附件。2.1.4更新任務任務分解完畢之后，每個人就非常清楚自己做什么事情。因此項目啟動之后，對于項目團隊的成員來講，她要做的事情就是更新任務的狀態。任務的列表在任務的列表頁面，能夠看到系統中所有的任務列表，能夠經過各種標簽

5、方便的進行篩選。點擊某一個任務的鏈接進入詳情頁面。任務的詳情頁面在任務的詳情頁面能夠看到任務的詳細信息，包括歷次的修改記錄等信息。同時也給出了各種操作的按鈕。開始任務。開始某一個任務的時候，能夠設置已經消耗的時間和預計剩余的時間。單位都是工時。完成任務。完成任務的時候，需要設置下已經消耗的時間。2.1.5驗證關閉任務任務完成之后，會自動指派給任務的創立者，這時候任務的創立者能夠驗證任務是否完成。如果完成，則能夠將其關閉。這件任務就結束了。2.2 HYPERLINK 只使用禪道來做bug管理測試禪道的測試功能也能夠獨立出來單獨使用。這種方式很適合于測試團隊使用。禪道里面的bug最基本流程是：測試

6、人員提出bug - 開發人員解決bug - 測試人員驗證關閉。2.2.1創立產品使用 HYPERLINK t _blank bug管理功能之前，需要先創立產品。禪道里面設計的理念是bug主要附屬在產品概念下面的，后面我們會詳細講述產品和項目之間的關系。新增產品的時候，需要設置產品的名稱、代碼，幾個負責人信息。2.2.2提出bug有了產品之后，我們就能夠來創立bug了。在創立bug的時候，必填的字段是影響版本，bug標題，重現步驟這些基本的信息。所屬項目，相關產品，需求能夠忽略。創立bug的時候，能夠直接指派給某一個人員去處理。如果不清楚的話，能夠保留為空。2.2.3解決bug當一個bug指派給

7、某一位研發人員之后，她能夠來驗證解決這個bug。經過各種標簽和檢索條件找到需要自己處理的bug在對bug進行出來之前，需要先要找到需要自己處理的bug。禪道提供了各種各樣的檢索方式，比如指派給我，能夠列出所有需要我處理的bug。解決bug研發人員解決bug，選擇解決方案，一般來講有效的解決bug方案是”已解決“。詳細的解決方案，我們在后續的文章中會詳細加以講述。2.2.4關閉bug當研發人員解決了bug之后，bug會重新指派到bug的創立者頭上。這時候測試人員能夠來驗證這個bug是否已經修復。如果驗證經過，則能夠關閉該bug。進階使用說明3.1 HYPERLINK 使用流程3.1.1 HYPE

8、RLINK 禪道使用流程圖解在禪道項目管理軟件中，核心的角色有產品經理、項目經理、研發團隊和測試團隊四種角色。如果您現在的團隊是采用敏捷開發的話，那么能夠對應到product owner, scrum master和team(dev and tester)。這幾種角色之間緊緊圍繞產品的需求展開協作，取得成果。禪道核心的管理流程全圖如下所示：3.2 HYPERLINK 產品經理篇3.2.1 HYPERLINK 維護產品 HYPERLINK t _blank 產品管理對于公司來講，至關重要。只有做出好的產品或者服務出來，才能贏得市場，謀求發展和生存。因此產品經理的這個位子對于公司來講，是非常關鍵的

9、，相當于公司的大腦，在決定著公司前進的方向。在禪道里面，產品和項目這兩個概念被明確的區分開來。產品是需求方，決定做什么。項目是執行方，解決的是如何做的問題。而測試則是保障方，解決的是正確的做事情的問題。因此在禪道中，所有的一切都是圍繞產品展開的。產品是整個項目管理活動的核心。3.2.1.1創立產品用產品經理的角色登錄禪道。進入產品視圖，然后點擊頁面右側的“新增產品”鏈接，即可出現新增產品的頁面。如果系統中還沒有添加產品，系統也會自動跳轉到產品的添加頁面。添加產品時需要注意的地方：產品代號相當于大家對這個產品的一個隱喻，比如禪道 HYPERLINK t _blank 項目管理軟件的代碼是zent

10、ao。產品負責人負責整理和解釋整個產品的需求，制定相應的發布計劃。測試負責人，能夠指定默認的測試負責人。這樣能夠適用于公司人比較多，提交bug不知道該給誰的情況。發布負責人主要的職責是創立發布。訪問控制，則能夠控制訪問該產品的人員列表。比如能夠將某一個產品設為私有，只有產品添加者、產品負責人、測試負責人、發布負責人以及該產品的項目團隊才能夠訪問。我們產品經理可能都習慣了寫需求設計文檔，或者規格說明書，經過一個非常完整的word文檔將某一個產品的需求都定義出來。但在禪道里面，我們提倡 按照功能點的方式來寫需求。簡單來講，就是將原來需求設計文檔中的每一個功能點摘出來，錄在禪道里面，作為一個個獨立的

11、功能點。如果按照scrum標準走 的話，我們能夠稱之為用戶故事(user story)。所謂用戶故事，就是來描述一件事情，作為什么用戶，希望如何，這樣做的目的或者價值何在，這樣有用戶角色，有行為，也有目的和價值所在，非常方便與團隊成員進行溝通。 3.2.2 HYPERLINK 創立和評審需求3.2.2.1創立需求使用產品經理角色登錄系統。進入產品視圖。在頁面右側，有“新增需求”菜單，點擊菜單，出現新增需求的頁面。需求的標題是必填項。所屬計劃和模塊，能夠暫時保留為空。需求審核那塊，我們選上不需要審核，這樣新創立的需求狀態就是激活的。只有激活狀態的需求才能關聯到項目中，進行開發。需求能夠設置抄送給

12、字段，這樣需求的變化都能夠經過email的形式抄送給相關人員。能夠設置關鍵詞，這樣能夠比較方便的經過關鍵詞進行檢索。3.2.2.2評審需求在創立需求的時候，有一個不需要評審的復選框，如果選中該復選框的話，需求的創立是激活中的。但大部分情況下面，需求還是需要評審的。即使產品完全有一個人負責，也能夠將一些不成熟的想法存為草稿，后續再進行處理。新增需求的評審流程如下：下面我們來看下具體的需求評審頁面：評審結果能夠選擇確認經過、有待明確、拒絕等操作。如果選擇“確認經過”，則需求的狀態改為“激活中”，然后就能夠關聯到項目中進行開發了。如果選擇“有待明確”，會保持需求的草稿狀態，并將需求指派回需求的創立者

13、頭上，有其繼續進行完善。如果選擇了“拒絕”，則需要給出相應的拒絕原因，拒絕原因能夠有：由誰評審是記錄的參與評審的人員名單，能夠輸入用戶名來自動篩選。一般來講需求評審能夠是一個線下的評審會議，在禪道里面記錄下參與需求評審的人員即可。3.2.3 HYPERLINK 變更和評審需求變更是 HYPERLINK t _blank 需求管理必不可少的流程，禪道項目管理軟件對需求的變更提供了全面的支持。其實需求的變更并不可怕，但不清楚影響范圍的變更是很可怕的。在傳統項目管理中，由于沒有有力工具的支撐，產品經理在變更需求的時候，無法知曉該需求的影響范圍，會有很大的隨意性。禪道項目管理軟件將需求、任務、bug和

14、用例都納入為一體管理，就能夠很清楚的知曉變更的影響范圍，從而給產品經理更好的指導。禪道里面需求變更的基本流程如下：下面我們來看下具體的操作：3.2.3.1變更需求禪道專門提供了需求的變更流程。凡是對需求標題、描述、驗證標準和附件的修改，都應該走變更流程。變更之后的需求狀態為變更中。編輯操作是無法修改需求的標題、描述、驗收標準和附件的。在變更需求的時候，如果選擇了“不需要評審”，則需求狀態自動變成激活，不需要再走評審流程。在變更需求的時候，會列出該需求的影響范圍：3.2.3.2評審需求經過需求的詳情頁面查看變更前后的變化 評審需求，給出評審結果評審結果能夠選擇確認經過，撤銷變更，有待明確或者拒絕

15、。如果選擇確認經過，則需求的狀態從“已變更”變為“激活中”。如果選擇撤銷變更，則取消當前的變更，并回退到之前的版本。如果選擇有待明確，需求被打回到需求的變更者，繼續進行完善。如果選擇拒絕，則需要給出相應的拒絕原因。同樣在評審需求的時候，也會列出相應的影響范圍，評審者能夠參考。3.2.3.3確認需求變更當需求變更被確認之后，研發團隊和測試人員需要確認需求的變更。任務確認需求變動： 缺陷確認需求變動用例確認需求變動3.2.4 HYPERLINK 需求的狀態和研發階段禪道軟件設計的需求有兩個字段來跟蹤它的變化，一個是需求的狀態字段，一個是需求的研發階段字段，下面來看下這兩個字段。3.2.4.1需求的

16、狀態需求狀態(status)字段，總共有四種狀態，分別是草稿(draft)、激活(active)、已變更(changed)和已關閉(closed)。對應為需求的流程操作共有：創立、變更、審核、關閉、激活，其狀態流轉圖如下：3.2.4.2需求的研發階段 需求還有一個階段(stage)字段，用來描述激活的需求在研發過程中所處的階段。當前總共有等待、已計劃、已立項、開發中、開發完畢、測試中、測試完畢、已驗收、已發布。那么需求的研發階段是如何變化的呢？一種方案是經過編輯操作，來修改研發階段。但我們更提倡另外一種方案，就是在創立任務的時候，仔細設置任務的類型，比如開發，測試。禪道的程序會自動根據不同類型

17、任務的變化來自動計算需求的研發階段，其規則如下：如果需求沒有關聯到項目，也沒有關聯到計劃，則需求的研發階段是等待。如果需求關聯到了計劃，還沒有關聯到項目中，則需求的研發階段是已計劃。如果需求關聯到了項目中，但還沒有分解任務，則需求的研發階段是已立項。如果需求關聯到了項目中，且進行了任務分解:如果有一個開發任務進行中，而且所有的測試任務還沒有開始，需求的研發階段為“研發中”。如果所有的開發任務已經完成，而且所有的測試任務還沒有開始，則為“研發完畢”。如果有一個測試任務進行中，則視為“測試中”。如果所有的測試任務已經結束，但還有一些開發任務沒有結束，則視為測試中。如果所有的測試任務已經結束，而且所

18、有的開發任務已經結束，則視為測試完畢。驗收階段是需要產品經理手工來進行確認的。如果需求關閉，且關閉原因是“已發布”， 則需求的研發階段是“已發布”。3.2.5 HYPERLINK 建立發布計劃古人云，凡事預則立，不預則廢。產品需要做規劃，才能有輕重緩急，才能正確的做事。因此對于產品經理而言，計劃是必須的。對于產品經理自己而言，發布計劃能夠幫助她規劃產品，制定發布的節奏，調整需求的優先級。對于公司其它部門的同事以及外部的客戶而言，發布計劃能夠讓她們知曉產品的進展情況，以便做好相應的安排。同時在項目關聯需求的時候，計劃能夠幫助需求的關聯。3.2.5.1創立計劃進入產品視圖，選擇某一個產品。點擊“計

19、劃列表”出現計劃列表頁面，點擊頁面右側的“創立計劃”，即可出現計劃增加頁面。 3.2.5.2關聯需求創立完計劃之后，能夠為計劃關聯需求也能夠在添加需求的時候指定計劃(已經過期的計劃不會列出)3.2.5.3計劃和項目之間的關系禪道軟件中并沒有對計劃和項目并沒有非常強的對應關系。如果某一個開發團隊的計劃和執行都非常好，那么一個計劃能夠對應一個項目。但這是非常理想的狀態。一般情況下面是這樣，在項目關聯需求的時候，大部分的需求都關聯自一個計劃，但同時也關聯了其它計劃的部分需求。3.2.6 HYPERLINK 建立發布項目結束后產品人員的一個工作就是創立發布，經過創立發布，能夠告訴公司其它相關的部門，她

20、們能夠在新版本產品的基礎上開展工作。同時也是鼓舞團隊士氣非常好的一個手段。3.2.6.1創立發布的前提創立發布有兩個前提：該產品有關聯過項目。該項目有創立過版本。3.2.6.2如何創立發布進入產品視圖，選擇發布列表。然后點擊“創立發布”，即可出現創立發布的頁面。選擇了版本之后，系統會自動計算這個版本所對應的項目中完成的需求和解決的bug，能夠進行關聯選擇。如果系統自動計算的需求和bug不完整，能夠在描述字段里面補充。5.2.7 HYPERLINK 文檔管理禪道軟件內置了基本的文檔管理功能，這樣禪道沒有覆蓋到的流程就能夠經過文檔管理功能來補充。禪道文檔庫共分為三種類型：產品文檔庫、項目文檔庫和自

21、定義文檔庫。其中產品文檔庫用來存儲產品層面產生的文檔，項目文檔庫用來存儲項目過程中產生的文檔。自定義文檔庫則能夠用來存儲知識庫、公司管理規范等文檔。下面讓我們來看下具體的操作。3.2.7.1維護分類進入文檔視圖。選擇產品文檔庫。然后選擇頁面下方的“維護分類”鏈接，即可出現維護分類的的頁面。3.2.7.2添加文檔在產品視圖，點擊頁面右側的“創立文檔”，即可進入文檔的創立頁面。文檔共有文件、鏈接和網頁三種類型。文件類型的文檔能夠上傳一個附件。鏈接類型的文檔能夠是一個網頁鏈接。網頁型的文檔能夠直接使用富文本編輯器撰寫。3.2.7.3瀏覽文檔文檔添加之后，能夠在文檔庫里面查看相應的文檔列表。也能夠在產

22、品視圖的文檔庫里面查看這個產品下面的所有文檔。3.3 HYPERLINK 項目經理篇3.3.1 HYPERLINK 建立項目3.3.1.1創立項目進入項目視圖，點擊右側的”新增項目“鏈接。 出現項目添加的頁面在這個頁面設置項目名稱、代號、起止時間、可用工作日、團隊名稱、項目目標和項目描述等字段。其中關聯產品是能夠為空的。注意事項：項目代號是一種隱喻，也就是團隊內部能夠互相了解和知曉，比如禪道項目曾經使用過“opensesame來作為項目的代號。團隊名稱，能夠自己定義，比如叫做“禪道開發團隊”等等。在添加項目的時候，能夠選擇關聯與之相關的產品，以便后續進行需求的關聯。項目能夠控制它的訪問權限，分

23、為默認、私有和自定義白名單三種。3.3.2 HYPERLINK 組建項目團隊項目組建之后要做的事情就是設置團隊。很多朋友經常問，為什么我在創立任務的時候，只能指派給自己呢？其實原因很簡單，是因為沒有設置團隊。當項目創立成功之后，能夠根據提示設置團隊。或者從項目視圖中的團隊菜單，也能夠進行項目的團隊管理。在維護項目團隊的時候，需要選擇都是哪些用戶能夠參與到這個項目中，同時需要設置這個用戶在本項目中的角色（角色能夠隨便設置，比如風清揚，冬瓜一號等）。可用工作日和可用工時每天需要仔細設置。一般來講，一個人不可能每天8小時投入，也不可能一星期七天連續投入。設置完畢之后，系統會自動計算這個項目總得可用工

24、時。當團隊設置完畢之后，整個項目的可用資源就已經確定了：起止時間確定了，參與的人員也確定了。下面就是來確定項目中要做的事情了。3.3.3 HYPERLINK 確定項目要完成的需求列表項目團隊組建完畢之后，接下來要做的一個工作就是確定這期項目要做的需求。這項任務其實是整個團隊，包括產品在內，共同完成的。3.3.3.1關聯產品如果在創立項目的時候，已經關聯過產品，能夠忽略這個步驟。以項目經理身份登錄。進入項目視圖。點擊“關聯產品”按鈕。然后點選該項目相關的產品即可。3.3.3.2關聯需求在關聯需求的時候，能夠按照優先級進行排序。關聯的需求狀態必須是激活的（評審經過，不能是草稿）3.3.4 HYPE

25、RLINK 組織進行任務分解需求確定之后，項目中幾個關鍵的因素都有了：周期確定、資源確定、需求確定。下面我們要做的事情就是為每一個需求做wbs任務分解，生成完成這個需求的所有的任務。 3.3.4.1訪問項目的需求列表頁面：在項目的需求列表頁面，能夠很方便地對某一個需求進行任務分解。同時還能夠查看這個需求已經分解的任務數。3.3.4.2分解任務這時候創立任務的時候，就能夠選擇需求了。我們同時提供了需求查看的鏈接。如果需求和任務的標題是一樣的，能夠經過”同需求“按鈕快捷的復制需求的標題。3.3.4.3任務分解的幾個注意事項需要將所有的任務都分解出來。這里面包括設計，開發，測試，美工，甚至包括購買機

26、器，部署測試環境等等。任務分解的粒度越小越好，比如幾個小時就能夠完成。如果一個任務需要多個人負責，繼續考慮將其拆分。事務型的事務能夠批量指派，比如需要讓團隊里面的每一個人都寫個項目總結，能夠選擇類型是事務，然后批量指派給團隊里面的所有人員。任務的類型請仔細設置，這個會涉及到需求研發階段的自動計算。后面我們會有講解。任務的分配最好是自由領取，這樣能夠最大程度上調動大家的積極性。任務的分解最好是由團隊共同完成，不要由項目經理一人包辦。3.4 HYPERLINK 開發團隊篇3.4.1 HYPERLINK 領取任務，并每天更新任務當項目的任務分解完畢之后，項目團隊成員需要領取自己喜歡做的任務，開始每天

27、的開發。除了日常的編碼工作之外，還應當每天花點時間在禪道里面更新下任務的狀態以及消耗情況。3.4.1.1領取任務領取任務能夠經過兩種方式，一種是經過“指派”操作，一種是經過“編輯”操作。3.4.1.2更新任務狀態項目開始之后，每個人每天應當及時更新自己所負責的任務的狀態。禪道提供了幾個快捷的操作按鈕：開始、完成、關閉、取消和激活。開始、完成和取消沒有什么歧義。解釋下關閉和激活。禪道有一個可選流程，就是當任務完成之后，會自動指派回任務的創立者頭上，這時候任務的創立者能夠驗證任務是否完成。如果完成，則將任務關閉。如果任務沒有完成，則激活任務。這個流程是可選的，不是必須的流程。適用于傳統的命令-控制

28、式的管理。如果對于敏捷開發團隊來講，忽略這個流程即可。3.4.1.3更新任務的消耗除了更新自己負責任務的狀態之外，還應該及時更新任務的工時消耗情況：最初預計，即創立任務的時候的最初預計。該字段在任務開始之后，不應該再進行修改。這個字段當任務結束之后，能夠和已經消耗字段進行對比，以糾正自己的估計。已經消耗，則是你在這個任務上所有花費的工時數。預計剩余，則是你預計這個任務完成大約還需要多少時間。如果預計剩余為0，則表示任務完成。這里面需要特別強調的是，最初預計 已經消耗 + 預計剩余。一定要每天更新自己所負責的任務，因為燃盡圖的繪制，就是經過預計剩余這個字段來計算的。3.4.2 HYPERLINK

29、 創立版本當完成若干功能之后，就能夠創立版本了。版本的概念在英文里面是build，能夠對應到軟件配置管理的范疇。這是一個可選流程，但還是建議團隊能夠實施版本管理。這個版本主要的作用在于明確測試的范疇，方便測試人員和開發人員的互動，以及解決不同版本的發布和bug修復等問題。流程如下：首先是團隊經過開發，完成了若干需求，或者解決了一些bug。這時候某一位發布負責人在subversion中創立了一個tag(標簽)，比如禪道的tag目錄如下：創立了tag之后，這位發布負責人就能夠在禪道里面創立一個版本了。說明：名稱編號，團隊應該有自己的配置管理規范。比如能夠是產品名_版本號_狀態(stble, bet

30、a之類)_日期不同開發語言其版本的存在形式也不同，有的需要編譯，有的只需要源代碼。請根據公司的實際情況來填寫源代碼地址，或者是存儲地址。在創立版本的時候，可選擇這次版本完成的功能和解決的bug。這樣提交給測試人員進行測試的時候，就能夠明確這次測試的范疇，測試能夠更加有針對性。描述字段能夠填寫一些測試的注意事項、重點內容等。3.4.3 HYPERLINK 申請測試當版本創立完畢之后，就能夠提交給測試人員進行測試了，提交測試會生成一個測試任務。在這兒需要和大家解釋下這個測試任務的概念。其實英文里面里面比較合適的單位是testrun，但翻譯到中文里面沒有太貼切的詞語，我們暫時用了測試任務的概念。但這

31、個測試任務和項目里面創立的類型為“測試”的任務沒有直接關聯。請大家在使用的時候，注意這個細節。一般來講，我們在分解任務的時候，能夠創立若干測試類型的任務，比如測試某某，測試某某，大概估計下測試需要的時間。然后具體的測試工作經過測試視圖的測試任務來跟蹤。申請測試的步驟：進入項目視圖，點擊“測試申請”。然后選擇“提交測試”，即可出現提交測試的頁面。說明：負責人為本次測試的負責人。能夠指定這次測試預計起止的時間。任務描述里面，能夠注明此次測試需要注意的地方。還需要說明的一點是，當前測試任務還沒有指派的功能，因此需要大家線下通知測試團隊的負責人，由她來負責組織相應人員來進行測試。3.4.4 HYPER

32、LINK 解決bug提交測試之后，測試人員展開測試，便會有bug產生。這時候研發團隊的一個重要職責便是解決bug。禪道里面bug的處理流程比較簡單：測試人員提交bug = 開發人員解決bug = 測試人員驗證關閉，這是比較正常的流程。還有一個流程是激活流程：測試人員提交bug = 開發人員解決bug = 測試人員驗證未經過 = 激活bug = 重新解決 =驗證關閉。開發人員所需要做的事情便是處理自己負責bug，并在禪道中登記解決方案：項目視圖中的bug列表bug的詳情頁面也能夠找到“解決”操作的按鈕。解決bug的時候，需要填寫bug的解決方案。附：bug的解決方案禪道軟件總共提供了其中解決方案

33、：bydesign = 設計如此，無需改動。duplicate = 重復Bug，以前已經有同樣的bug。external = 外部原因，非本系統原因。fixed = 已解決;notrepro = 無法重現，無非重現bug。postponed = 延期處理，確實是bug，但現在不解，放在以后。willnotfix = 不予解決這其中“已解決”和“延期”的bug視為有效bug。3.4.5 HYPERLINK 文檔管理敏捷開發不提倡面面俱到的文檔，但必要的文檔還是很有必要的，比如數據庫的設計文檔、接口文檔、測試總結報告等等。具體文檔庫的使用，請參考：產品經理篇中的文檔管理。3.4.6 HYPERLI

34、NK 確認bug當測試人員提交了bug之后，如果開發人員來不及解決這個bug，這時候可選的一個操作是確認這個bug，給測試人員一個反饋。bug列表頁面會顯示是否已經確認過。bug詳情頁面有確認操作按鈕。需要說明的是，如果一個bug被解決之后，也會自動變成已確認。3.5 HYPERLINK 測試團隊篇3.5.1 HYPERLINK 維護bug視圖模塊在禪道軟件中，bug也同樣需要維護模塊，以便更好的組織管理bug。這個地方需要特別說明下，bug模塊、用例模塊和產品模塊是獨立的，每個視圖都有自己的模塊。為什么這樣做呢？主要是考慮到使用的角色不同。在產品視圖里面，主要是用來組織需求。而在bug模塊，

35、則主要偏重bug管理，那么可能會有和產品視圖不同的模塊劃分。至于測試用例視圖，則更不同了。模塊劃分里面會有很多和測試用例直接相關的劃分，比如兼容性測試，壓力測試等等。因此禪道將這三個模塊分開，需要單獨進行維護。進入測試視圖，然后選擇缺陷管理。在頁面的左側，會出現該產品的缺陷模塊列表。模塊列表的下部，有模塊維護的連接，點擊此鏈接，即可維護模塊，詳情的維護界面，維護模塊的時候是一級級進行維護的。比如能夠選擇我的地盤，然后維護它的子模塊。左側的數字是用來排序的，能夠將經過調整模塊的排序字段來調整它在模塊樹里面的位置。能夠選擇某一個模塊編輯，編輯的時候能夠修改它所屬的上級模塊，以及這個模塊的默認負責人

36、(當創立bug的時候，會自動將這個用戶作為默認的負責人)能夠選擇產品視圖的某一個模塊，將其下級模塊復制到當前的測試視圖的模塊中。3.5.2 HYPERLINK 提交bug進入測試視圖的“缺陷管理”點擊頁面右側的創立bug，即可進入bug創立頁面。說明：項目和任務，以及相關需求，應該認真填寫，這樣能夠將bug和項目，任務，需求關聯起來，以便以后的統計分析。影響版本是必填的。而這里面的列表來源，則是項目中的build。如果這個地方沒有build的話，則需要到項目中創立一個build。重現步驟應該翔實準確，確保開發人員能夠重現改bug。3.5.3 HYPERLINK 驗證bug，關閉當開發人員解決bug之后，就需要來驗證bug，如果沒有問題，則將其關閉。3.5.4 HYPERLINK 激活bug如果開發人員解決bug之后，驗證無法經過，則能夠將bug重新激活，交由最后的解決者去重新解決。還有一種情況就是bug關閉之后，過了一段時間，bug又重現了，也需要重新激活。激活bug的時候，指派給會自動設置成為最后的解決者頭上。3.5.5 HYPERLINK 找到自己需要的bug測試人員一個非常重要的工作就是篩