在我們創建Jira時，Jira上會填寫各式各樣的字段，不同的字段對於不同的角色人員，使用方式也是不同的，通過這篇文章，希望大家能夠對Jira使用有更深刻的認識。
為什么需要嚴格規范?
- 易於開發，測試，產品經理溝通協作，消除溝通上不必要的麻煩
- 規范的使用便於整個項目的進度跟進，任務統計，項目里程碑更清晰
- 清晰的展現項目開發過程中需求，任務，開發售后等多維度的統計
- 掌握和運用Jira，也是一個人個人能力的提升
問題類型
從Jira大的類型上以及差異上來划分，主要有默認類型與缺陷類型兩大類，首先說明下Jira的問題類型，以便在我們創建Jira時能夠選擇合適的類型。
默認類型
（史詩）Epic：本身可以被拆成大量story的一個合集，此種類型的Jira經常代表一個大的功能模塊，不對應具體的一個用戶需求。
（故事）Story：具體的一個用戶需求，由項目/產品經理去創建，描述一個用戶需求的願景
（任務）Task：常用於新增的任務或者任務調整
（子任務）Sub-task：建立在Story或者Task下的子任務，用於記錄實現這個父任務的子任務，可以分工給不同的人
（改進）Improvement：對已有功能或任務的改進和完善
（重構）Backend Logic Enhancement：記錄開發過程中需要進行的重構任務
（客戶問題）Customer Issue：客戶在使用過程中發現的問題，來自客戶的真實環境
缺陷類型：
（缺陷）Bug：記錄產品在測試過程中發現的問題
最佳實踐
以下矩陣表，對每個字段加以深入說明，我們每個人的角色，都規定了使用的規范，在我們使用Jira時需要嚴格執行。
默認類型的Jira:
Bug類型的Jira：
結語
希望這篇文章能夠對剛剛開啟使用Jira管理的公司或者團隊答疑解惑，Jira使用很簡單，不過能夠有個最佳實踐是非常重要的。
小編也是依靠多年的敏捷開發經驗細心整理的這套矩陣圖，更多優秀原創帖子以及疑惑，歡迎關注作者
