Jira中的全流程開發管理

1. 使用人員說明

需求相關：PO
開發相關：開發負責人，分系統負責人，開發人員
測試相關：測試人員，業務人員

2. 工具中的字段說明

2.1 Issue Type 事件類型說明

在創建一個Issue（事件）的時候，需要首先選擇Issue Type（事件類型），該類型分爲以下六種，具體分類及操作人員如下：

BR（業務需求）

記錄原始的業務需求，包括：服務檯收集的優化需求，DT/PM收集到的修改現有功能的業務需求，以及新的功能中業務提出的需求。每個業務需求由服務檯/BT/PM定義並增加到Jira的Issue中，並分解爲一個或多個產品需求PRD。

PRD（產品需求）

每一個PRD類型的Issue記錄一條產品需求，該產品需求的粒度以可實現的最小功能爲參考，工作量需少於5人天。PRD由業務需求分析得到並關聯到上級的BR，由BT/PM定義並增加到Jira的Issue中，指派給開發負責人（PM/子系統負責人）。

Task（任務）

任務類型服務於開發團隊，IT PM/ IT 子系統負責人接收到PRD，拆分爲開發任務task或者Subtask並指定給相關的開發人員進行開發。該任務或子任務由IT PM/ IT 子系統負責人增加到Jira的Issue中，並跟蹤其執行。

Subtask（子任務）

同task，可由PRD直接拆分爲Subtask。

Bug（缺陷）

缺陷分爲兩類，一類是服務檯或其他渠道收到的業務提交的缺陷，二是SIT及UAT出現的缺陷。缺陷由缺陷發現人增加到Jira的Issue中，一般是服務檯或測試人員，其他人員也可以提交缺陷，缺陷提交後指派給相關開發人員。如果不確定開發人員，指派給開發負責人或子系統負責人。

Test（測試）

測試爲編寫測試用例的類型，可以針對某一個Component，PRD進行測試用例的編寫、測試用例的執行及缺陷提交。

2.2 Status（狀態）說明

狀態說明了當前Issue的處理狀態，默認爲：TO DO （待定）。狀態分爲：TO DO（待定），Progressing（進行中），Resolved（已解決），Done（已完成），Reopen（重新打開），Pending(擱置)，Feedback（反饋）。

用戶可以通過瀏覽Issue頁面中的狀態操作按鈕，改變當前的狀態，操作爲【open】【progress】【reopen】【pend】【resolve】【Feedback】【Close】。狀態如下分類：

TO DO（待定）

每一個新建的Issue初始狀態都爲TO DO。

Progressing（進行中）

Issue（事件）指定給解決人之後，修改狀態爲Progressing，表示該Issue正在解決的過程中。

Resolved（已解決）

當解決人把指定的Issue解決完成後，修改狀態爲Resolved，表示該Issue已經解決完成，可以進行測試或驗證了。

Done（已完成）

測試人員或驗證人員（通常是PM），確認該Issue正確後，修改狀態爲Done，表示該Issue已經被驗證完成，是一個合格的Issue。原則上，解決人不能夠直接close指定給自己的Issue，必須由指定給自己的reporter來驗證。

Reopen（重新打開）

驗證不通過的Issue，修改狀態爲reopen，表示該問題仍未解決，可以指回給解決人繼續解決。

Pending(擱置)

無法處理，暫時擱置的問題，修改狀態爲pending。

Feedback（反饋）

解決人對問題有疑問的問題，修改狀態爲Feedback，並指回給reporter。

2.3 Priority(優先級)說明

在Jira中針對於BR/PRD/Bug定義了4類優先級，分別是：P1，P2，P3，P4。

需求類：BR及PRD

需求的優先級是指需求被實現的緊急程度，分爲P1,P2，P3,P4四個等級。對於需求的優先級要考慮多個維度，如：產品價值，時間關鍵性，減少風險及技術成本等。優先級是相對而言的，區分可參考如下分類：

缺失該功能會造成嚴重的問題和惡劣的影響
該需求與核心用戶利益相關
能夠解決大量用戶的高頻問題，提升基礎體驗

缺失該功能，在一定時間內可控，但長期會有糟糕的影響
該需求與大部分用戶權益相關
需要加大投入，直到用戶需求基本被滿足。

具備該功能解決很多問題、產生正面的影響
該需求與效率或成本有關
需要有投入，但是不能佔用P1，P2上投入的資源，也是建立產品用戶忠誠度的重要因素。

具備該功能，在一段時間後可以有良好的效果
該需求與用戶體驗有關
屬於矛盾、錯誤、無關型需求，資源具備的情況下可對產品進行完善。

缺陷類：Bug

缺陷的優先級指缺陷必須被修復的緊急程度，分爲P1,P2，P3,P4四個等級。

重要且緊急的缺陷，必須被立即解決

較爲緊急的缺陷，需要在5-10個工作日解決的問題

重要不緊急的缺陷，缺陷需要正常排隊等待修復或列入軟件發佈清單

不重要不緊急的缺陷，可以在資源充足時被糾正。

2.4 Bug severity（缺陷嚴重程度）說明

缺陷嚴重程度是指因缺陷引起的故障對軟件產品的影響程度。缺陷的嚴重程度分爲：致命，嚴重，一般，輕微，建議。

致命

不能執行正常工作功能或重要功能，或導致系統癱瘓(死機)
嚴重地影響系統要求或基本功能的實現，且沒有辦法更正（重新安裝或重新啓動該軟件不屬於更正辦法）
服務器出現內存泄露

嚴重

嚴重地影響系統要求或基本功能的實現，但存在合理的更正辦法。（重新安裝或重新啓動該軟件不屬於更正辦法）
包括用戶使用當中出現頁面級異常
連接錯誤
統計數據錯誤
語言翻譯錯誤

一般

使操作者不方便或遇到麻煩，但它不影響執行工作功能或重要功能
包括用戶界面不一致
java script 腳本錯誤
文字錯誤
其它錯誤

輕微

頁面顯示格式不規範
不符合用戶的使用習慣
影響體驗的問題
其它錯誤

建議

使用過程中可以提升體驗的問題
後續可以新增加的功能

3. 項目設置

3.1 Component/s（組件/子系統）

Component定義了系統的組件/子系統，便於較大系統的任務分配及缺陷管理。該功能需要具有管理員權限的人員設置，見圖2-1。

圖 2-1 設置Component

設置完成之後，在創建Issue時，可以選擇已經設定好的Component，見圖2-2。

圖 2-2 選擇Component

3.2 Sprint（衝刺/階段性任務）

Sprint定義了一個衝刺/階段性任務，包含在這個時間週期內要完成的Issue，一個Sprint可以一次發佈也可以發佈多次，不作具體要求。見圖2-3

操作方法：

選擇左側菜單【Backlog】
右側，點擊【Create Sprint】，創建一個Sprint
點擊Sprint名稱，修改名稱，Sprint名稱的定義：項目關鍵詞+Sprint a.b.c.d ，a.b爲當前需求的版本號，c爲1位大的功能增加或變更順序號，d爲2位順序號，舉例：備件項目的一期需求1.0對，大的功能發佈順序號爲3，在該大的功能點已經完成10個Sprint，當前的Sprint名稱是：DTSSCM Sprint 1.0.3.11。
將下方的Issue拉入到Sprint任務列表中
開啓一個Sprint，點擊【Start Sprint】開啓一個Sprint，同一時間內，只能有一個Sprint被開啓。

圖 2-3 創建Sprint

3.3 Versions（版本）

在Release中可以定義發佈版本，版本的建立操作如下：

點擊【Release】，進入發佈頁面，見-圖 2-4 創建Version
填寫版本信息，版本號的定義：V a.b.c.d ，a.b爲當前需求的版本號，c爲1位大的功能增加或變更順序號，d爲2位順序號，舉例：備件項目的一期需求1.0對，大的功能發佈順序號爲3，在該大的功能點已發佈的次數爲25次，應到目前的版本號是：V 1.0.3.26。
如果是測試版本可以在後面添加：V 1.0.3.26-QA，生產版本：V 1.0.3.26-PRO，UAT版本：V 1.0.3.26-UAT。
點擊【Add】，添加一個版本信息
將發佈的Issue加入到version中，在Backlog頁面，點開左側Version，將Issue拖拉到version中，見-圖 2-5 添加發布內容

圖 2-4 創建Version

圖 3-5 添加發布內容

在Release中可以發佈版本的操作如下：

在Release頁面，在列表中選擇要發佈的版本，此時該版本的Progress應該全部是綠色，表示所有的發佈Issue都已經被驗證完成了
選擇要發佈的版本記錄，點擊右側【Action】，如-圖 3-6 版本發佈
Action有5個選項，分別是：Release(發佈)，Build and Release(構建和發佈)，Archieve（實現），Delete，Edit。在這五個選項中，點擊【Release】，發佈該版本
發佈完成後該版本狀態變爲Released，發佈完成

圖 3-6 版本發佈

3.4 Tests Cycle（測試周期）

在Test中可以定義測試周期，測試周期是對測試的管理，包括用例，時間，結果，Bug等。一個測試周期執行通過後，說明系統整體是可靠的，可使用的，可以上線的。

一個測試周期要驗證的用例包括：此次修改的PRD下的測試用例及相關功能的主流程用例驗證。測試周期的操作流程：

左側菜單【Tests】，顯示Tests頁面，選擇【Cycle Summary】中的【+】，進入添加Cycle頁面，如-圖 3-6 進入Tests
Create new Cycle頁面中，填寫相關信息：如-圖 3-7 新建Cycle

Version：分兩類，Unschedule和發佈版本，Unschedule可以定義Component的測試內容，發佈版本可以定義此次發版中需要覆蓋的測試內容
Name ：Unschedule中可以用組件名稱及模塊名命名，其下還可以再分folder層，作爲細分目錄。發佈版本中可以按照版本號+第N輪來定義
Description：包含此次測試周期的描述，包括測試類別：SIT(上線前)，SIT（上線後），UAT等。還需要包括此次測試周期包含的主流程Cycle名稱
Build：構建版本號
Environment：環境，包括測試，UAT，生產等
From，To：此次測試周期的時間範圍

圖 3-6 進入Tests

圖 3-7 新建Cycle

添加Folder子目錄，子目錄可以做到更細的拆分，Component下可以再細分模塊，及主流程，如-
添加Tests測試用例，可以有三種方式添加：

Individually：按照單個的測試用例添加
Via Search Filter：按照篩選條件添加
From Another Cycle：按照其他的Cycle添加，把其他Cycle中的用例添加過來

圖 3-8 新建Tests/Folder

圖 3-9 新建Tests/Folder

執行Test Cycle，選擇左側的Cycle，顯示測試用例，【Select All】,並點擊【E】運行用例，進入運行頁面，如-圖 3-10 執行Test Cycle

圖 3-10 執行Test Cycle

測試執行頁面，選擇執行狀態，添加Bug，進入下一個用例的測試，直至執行完成。

圖 3-11 執行結果Test Cycle

使用流程

4.1 業務需求類

業務需求類包括兩類：服務檯或BT/PM收集到的優化或修改需求，以及BT/PM收集到的新的業務需求。該部分需求，前一類，可以直接在Jira中錄入用戶提出的BR，並新建對應的PRD進行產品需求分析，另一類需要在Confluence中定義詳細的產品需求，並把產品需求對應到相應的BR中。

1. 1. 新增BR（業務需求）

BR類型的Issue記錄原始的業務需求，包括：服務檯收集的優化需求，DT/PM收集到的修改現有功能的業務需求，以及新的功能中業務提出的需求。

參與人員：服務檯或BT/PM
具體操作：在Jira中，服務檯或BT/PM將業務需求，創建一個Issue，選擇類型爲：Busineess Requirement ，選擇Component，填寫相關信息，並將其指派給BT/PM，提交該Issue。按圖操作即可，見-圖 4-1 新增BR

圖 4-1 新增BR

4.1.2 新增PRD（產品需求）

PRD類型的Issue記錄一條產品需求，該產品需求PRD由業務需求分析得到，並關聯到上級的BR，由BT/PM定義並增加到Jira的Issue中，指派給開發負責人（IT PM/子系統/組件負責人）。

另外，還有一類需求時IT基於系統優化提出的，也可以以PRD類型添加，Link到對應的設計方案。

參與人員：BT/PM IT leader
具體操作：

在Jira中，按照BR的記錄，將對應的產品設計需求，創建一個Issue
首頁選擇【create】，選擇組件，輸入概要信息summary及Description描述
選擇【Plan】頁，建立該PRD與BR的關係，使用關係：【 is subtask of 】，選擇要關聯的業務需求BR
必須填寫到期時間：Due date，時間爲上線時間。
選擇指定人，指定給子系統/組件負責人，或者不明確的部分指定給IT PM。
點擊【create】創建一個PRD。見-圖 4-2 新增PRD
將該PRD關聯到Confluence中的需求頁面，在Issue的瀏覽頁面，選擇【more】中的【Link】，進入link頁面，如-圖 4-3 選擇Link
進入到Confluence中，找到需求頁面，複製頁面地址，如-圖 4-4 複製頁面地址
在Jira的Link頁面，添加複製的頁面地址到：Confluence Page頁面，點擊【link】，如-圖 4-3 添加Link。

圖 4-2 新增PRD

圖 4-3 選擇Link

圖 4-4 複製需求地址

圖 4-5 添加Link

4.1.3 新增task/Subtask（開發任務）

任務部分管理從開發承接到BT/PM的PRD並進行開發的過程，需要根據每一個PRD的要求及時間要求進行開發任務的分解和執行。新功能的開發需要比到期時間due date至少提前1天，給測試預留時間。

參與人員：IT PM / IT 子系統/組件負責人
具體操作：

在Jira的Issue瀏覽頁面中，找到需要完成的PRD，在菜單【more】中選擇【Create sub-task】，創建一個subtask子任務類型的Issue，如-圖 4-6 Create sub-task
在創建頁面填寫信息，如下是必填項：

選擇組件Component
填寫概述Summary，詳細描述Description
選擇指定完成人
選擇到期時間due date，新功能要比PRD到期時間至少提前1天

點擊【Create】，創建該開發子任務。如-圖 4-7 Subtask信息
查看PRD中的信息，有添加完成的子任務及狀態，如-圖 4-8 查看Subtask信息

圖 4-6 Create sub-task

圖 4-7 Subtask信息

圖 4-8 查看Subtask信息

1. 1. 新增Test（測試用例）

Test測試提供支持PRD測試的功能，可以針對某一個Component，PRD進行測試用例的編寫、測試用例的執行及缺陷提交。

參與人員：測試人員
具體操作：

創建測試用例有兩個入口：

一個是直接在頁面【Create】一個類型爲Test的Issue，這樣可以關聯到PRD，由PRD關聯到組件；

另外一個是，從類型爲PRD的Issue中菜單【more】中的【Create Zephyr Test】，選擇組件，創建跟組件關聯的測試用例。如-圖 4-9 創建Test

圖 4-9 創建Test

填寫測試用例信息：

在Jira中編寫測試用例

選擇組件Component
填寫概述Summary，Summary的內容爲：組件中的模塊Mod1 / 模塊的分功能Func1 / 用例概述+三位順序號，如：庫存調賬/新增庫存調賬/符合要求的輸入001
填寫描述Description，可填寫用例的前提條件及說明信息
編寫用例，填寫：步驟，數據及期望結果
點擊【Add】添加用例信息
添加用例信息後點擊【Create】，創建一個測試用例，如-圖 4-10 添加Test信息

圖 4-10 添加Test信息

在Jira中增加一個測試用例，鏈接到Testlink中的測試集

選擇組件Component
填寫概述Summary，Summary的內容爲：組件中的模塊Mod1 / 模塊的分功能Func1 / 用例概述+三位順序號，如：庫存調賬/新增庫存調賬/符合要求的輸入001
填寫描述Description，可填寫用例的前提條件及說明信息
編寫用例，填寫：

步驟：Testlink地址

數據：Testlink中的項目名稱/測試集1/測試集2

期望結果：如Testlink，可空白

點擊【Add】添加用例信息
添加用例信息後點擊【Create】，創建一個測試用例，如-圖 4-11 添加Test信息鏈接Testlink

圖 4-11 添加Test信息鏈接Testlink

用例添加完成後，點擊左側側邊欄的【Tests】，進入Tests頁面，可以查看用例情況，以及組件下的用例。如-圖 4-12 查看Test

圖 4-12 查看Test

4.1.5 新增Versions（版本發佈）

Release及Version提供了對發佈版本的管理，可以在Release頁面直觀的看到定義完成的一次版本發佈的執行情況，是否進入可發佈階段。

參與人員：BT/PM
具體操作：

創建一個Version，在Release中定義一個版本Version
在Backlog頁面中，將要發佈的內容從Sprint列表中拖到發佈版本中，如-圖 4-13 添加發布內容
可以在Release中查看發佈內容的完成情況，如-圖 4-14 查看版本執行情況

圖 4-13 添加發布內容

圖 4-14 查看版本執行情況

4.1.6 執行task/Subtask（開發任務）

參與人員：開發人員
具體操作：

指定任務爲Subtask，查看Summary中有上級PRD的編號鏈接，如-圖 4-14 執行Task/Subtask。
點擊編號，可以打開本任務關聯的PRD，查看本任務的需求，在Confluence中的需求說明書，如-圖 4-14 執行Task/Subtask

圖 4-14 執行Task/Subtask

圖 4-15 查看PRD 需求文檔

開發人員完成指定到自己的開發任務，參考PRD中關聯的Confluence中的需求文檔，需要在評論區留言，說明已經按照需求文檔的要求來進行開發，如-圖 4-15 添加評論

圖 4-15 添加評論

開發完成後，修改Issue狀態爲Resolved，並將該任務指回給任務分配人。

4.1.7 檢查PRD（產品需求）

參與人員： IT PM / IT 子系統/組件負責人
具體操作：檢查開發任務完成情況，如果一個PRD的子任務全部爲Resolved，將子任務狀態修改爲Done，並將完成的PRD修改狀態爲Resolved，將PRD指派給測試人員進行測試。如-圖 4-16 檢查PRD完成情況

圖 4-16 檢查PRD完成情況

4.1.8 執行PRD Test（功能測試）

參與人員：測試人員/服務檯
具體操作：

對指派給自己的PRD，按照PRD中關聯的用例（relates to的test類型的Issue），執行測試；

圖 4-14 查看用例

執行用例，進入用例頁面，點擊上方菜單的執行【Execute】

圖-4.15 執行用例

進入選擇版本和測試周期頁面，選擇當前版本號及週期（有版本號），指派人，或者直接選擇：Execute ad Hoc(執行一個臨時的測試周期)，點擊執行，如-圖 4-15 執行用例

圖 4-15 執行用例

按測試用例執行測試，如果是功能用例直接編寫在Jira中的，按照測試步驟執行，如果測試用例在Testlink中的，按鏈接地址的目錄執行測試。測試結果有5類，PASS通過，FAIL失敗，WIP進行中，BLOKED阻塞，UNEXECUTED未執行，選擇實際結果進行填寫
記錄執行結果：不通過的用例，提交Bug，並指給開發人員進行修改，後續對bug 進行跟蹤；通過的用例，設爲Pass，不滿足測試條件的用例，設置爲Blocked。如-圖 4-16 執行結果
測試PASS的用例，將狀態設置爲Done，如-圖 4-17 關閉測試用例
PRD中的用例全部通過後，返回到該PRD，將其狀態修改爲Done，指回給任務分配人員。，如-圖 4-18 關閉PRD

圖 4-16 執行結果

圖 4-17 關閉測試用例

圖 4-18 關閉PRD

4.1.9 執行Release（發佈）

該發佈版本中所有的Issue狀態爲Done時，可以啓動版本發佈。版本發佈首先要進行上線前測試，該上線前測試跟項目的不同有的是SIT的延伸，有的是業務進行的UAT測試，不管是那種測試都要涉及到場景及此次發佈可能引起的其他流程的驗證活動。

檢查發佈狀態

參與人員：IT PM / IT 子系統/組件負責人
具體操作：此次發佈中的PRD及Bug全部爲Done時（內容條爲綠色），說明可以進行發佈。

上線前測試（UAT或SIT流程）

參與人員：測試人員/服務檯或者業務人員
具體操作：

測試負責人點擊左側菜單【Test】，進入項目的Test頁面，在當前版本下創建一個測試周期，將相關主流程或場景的用例添加到該測試周期中，見章節3-4.有一些用例可能在驗證PRD時測試通過，看情況是否重新執行
執行該測試周期的內容，選擇要發佈的版本，頁面右側會顯示包含的用例,選擇【Select All】，點擊【E】，執行全部測試用例，如-圖 4-19 執行測試周期
針對每一個用例選擇測試結果，並提交Bug
測試用例通過後，Test頁面下的該測試周期顯示爲綠色，說明流程已經全部驗證完成，通知IT PM 可以上線，如-圖 4-20 上線測試完成
此處說明，如果有遺留的Bug可以不影響此次上線，經過討論可以不必要求測試周期全部顯示綠色，也就是說測試中可以有用例沒有通過

圖 4-19 執行測試周期

圖 4-20 上線測試完成

發佈

參與人員：IT 開發人員
具體操作：將系統按順序部署到正式的生產環境

圖 4-21 上線發佈

上線後測試

參與人員：BT/PM 測試人員或者業務
具體操作：在生產環境執行上線測試周期的內容，確認無誤後，上線發佈完成

4.2 Bug類

Bug類的Issue包括兩部分，一部分是服務檯/BT收到的用戶反饋問題，另一部分是測試過程中發現的問題。這部分的流程直接指派給開發進行處理，無需進行需求分析。

4.2.1 新增Bug（缺陷）

參與人員：服務檯/測試人員，以及其他發現問題的人員
具體操作：

點擊頁面【Create】創建一個Bug 類型的Issue事件，或者從Test測試用例的Execute執行中，創建一個Bug
選擇組件
輸入Summary概述，輸入Description描述
選擇優先級：P1/P2/P3/P4，選擇問題嚴重程度：致命/嚴重/一般/輕微/建議
指定修改人員，指定人默認爲組件負責人，如果明確實際修改人直接指派給修改人，不明確可以按默認
點擊【Create】創建一個Bug。

圖 4-22 創建Bug

4.2.2 執行開發（修改Bug）

參與人員：開發人員
具體操作：開發人員完成指定到自己的Bug，完成後修改狀態爲Resolved指回給任務分配人，進行驗證，通常是測試人員。

4.2.3 檢查BUG修復（缺陷）

參與人員：服務檯/測試人員，或者業務
具體操作：驗證已經Resolved的Bug類Issue，如果通過將狀態改爲Done，如果不通過，將狀態改爲Reopen，重新指回給開發人員進行修改。

Jira中的全流程開發管理

1. 使用人員說明

2. 工具中的字段說明

2.1 Issue Type 事件類型說明

2.2 Status（狀態）說明

2.3 Priority(優先級)說明

2.4 Bug severity（缺陷嚴重程度）說明

3. 項目設置

3.1 Component/s（組件/子系統）

3.2 Sprint（衝刺/階段性任務）

3.3 Versions（版本）

3.4 Tests Cycle（測試周期）

4.1 業務需求類

4.1.2 新增PRD（產品需求）

4.1.3 新增task/Subtask（開發任務）

4.1.5 新增Versions（版本發佈）

4.1.6 執行task/Subtask（開發任務）

4.1.7 檢查PRD（產品需求）

4.1.8 執行PRD Test（功能測試）

4.1.9 執行Release（發佈）

4.2 Bug類

4.2.1 新增Bug（缺陷）

4.2.2 執行開發（修改Bug）

4.2.3 檢查BUG修復（缺陷）

Jira中的全流程開發管理

Git 使用手冊 - Windows 下客戶端安裝配置（1）

Myeclipse+Maven+Testng+Selenium開發環境配置(1)-Maven安裝與配置

web調試

在servlet中輸出Json信息

Mac下配置sublime實現LaTeX

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結