Jira 大概是 Trello 以外在資訊產業最多人用的專案管理系統了吧！在 Jira 的專案如果是開設成 Software 的話，應該會有以下幾種 issue type：
- Epic
- Story
- Task
- Subtask
- Bug
當然它們字面上的意思誰都知道，但是其中在 Jira 或是所謂的「敏捷」開發流派內的角色與意義為何，其實一直沒有認真的了解過。
這裡試著以我在網路上吸收到以及融合本人觀點的對於這些 Jira issue type 的理解，另外需要特別提前聲明本人不完全懂也不是「敏捷」、「agile」、「scrum」流派的信仰者，因為至今仍然覺得「敏捷」與現實的商業流程有不相容的地方，現實上更像是隕石開發與敏捷或瀑布的混搭版 XD。因此下文若有對「敏捷」理解不正確的地方敬請見諒。
階層關係
在 Jira issue type 的階層關係上，越高的層次抽象性越大，也越用於描述一種較廣泛的、不精確的、整體的概念；而越低的層次更貼近單一的功能，或者需求，或者做法。
先撇開軟體，以戰爭為例，我們可以把戰爭由高至低分出五個層次：
- 戰爭：國與國的層次，例如台灣與中國就是典型的國與國的層次，只有國家才會發起戰爭，並且國家也代表了整體國民的意志。（當然會傾向執政黨的意志，不過幸好台灣是個會正常政黨輪替的民主國家）
- 戰略：由參謀本部策劃出整體的攻守策略與推想，包括前線與後勤補給等的大範圍資源調度等方面的設想，譬如各式兵推演習等狀況的假設，提供給國家領導人與下層單位實兵操作。
- 戰術：軍團、聯兵旅或旅或營層級，根據上級單位的指示在駐地或其它地方掌握當地地形地貌實施的攻守策略，以及透過火協與友軍的溝通支援等工作。
- 戰鬥：排級或班級，接受命令負責攻克或防守某個陣地，與敵軍交火時每一伍、人之間的交叉掩護。
- 戰技：你各位啊本職學能他媽的…要做好啊！
回到 Jira 的階層，由高至低排序：
- 頂天層：Project
- 第零層：Component
- 第一層：Epic
- 第二層：Story / Task / Bug
- 第三層：Subtask
這邊也把 project 與 component 加進來，雖然它們並非 issue type 的層級，不過在專案層級上的確也具有角色，所以就一併列入了。
根據 Jira 的文件，story 用於表達較小部份的產品需求；epic 用於表達較大部份的用戶案例，一個 epic 可以被切割成數個 story；而 subtask 則是 story 的再下一層，用於當需要把 story 切割成更小的工作細項時使用。
Story
在 story 這種對於需求的描述出現以前，從需求轉化為規格的這段過程，只出現於人腦（直接腦補轉換沒有付諸文字），或是做為規格的補述，可是這樣直觀的轉換中會落失需求的原始動機與需求對客戶的價值高低，這些資訊的遺漏會導致開發人員落入「知其然而不知其所以然」的狀況，用經典的鞦韆圖可以很直觀的表達這樣的狀況。
在 story 這種 issue type 被設計出來以後，終於有地方可以讓需求的原始動機與價值有記載的地方，並且也把需求至規格這段原先腦補的過程以文字記錄下來，目的當然是希望團隊的所有成員在做產品的時候可以理解需求的原始動機與價值，以避免錯誤理解或過度設計的問題發生。如果拿 5W1H 對一個 issue 做解構的話，story 會負責用於描述為何（why）會有這個 issue，以及是誰（who）發出這個 issue、issue 的需求是什麼（what）、在何時（when）何地（where）發生，而開發人員如何（how）在技術層面處理這個 issue，則不是建立 story 時所必須填入的內容（至少在 story 標題的地方不是）。
開發人員如果有需要可以另開 task 或 bug 類型的 issue 來記載對開發人員來說實際需要進行的工項，並連結相關的 story 與 task / bug 工項。
另外一方面，如果要把相關的 story 整理起來，則利用 epic 讓 story 能被有組織的被歸納起來，也能為專案的諸多需求有分門別類的地方。
Story 的粒度
Story 用於描述使用者需求，然而「使用者需求」這件事本身就難以估量，特別是在面對不同的層級的客戶，他們的需求可能會長的相當不一樣，對客戶的大老闆來說，他要一套「幫助公司營運的 ERP 」，然而對客戶的基層員工來說，他要的是「幫我在結帳頁面加個會員資訊區塊好讓我對會員進行個人化服務」，在實際建立 story 時，面對過於廣泛而粗略的需求（上帝的旨意往往就是這麼虛無飄渺），還是必須依賴人力去把這類需求拆解成數條更具體且具有可執行性的項目後再建成 story，這項工作可能落在專案經理或專案分析師上面，對老闆兼撞鐘的小公司來說，就是落在老闆兼專案經理兼開發兼測試的人上面。
另外一種情況也不適合用 story 描述，即過於細節的工項，舉例來說，在一個 POS 系統，顯然結帳頁面載入的微互動不會是客戶在意的點，這種過於細節的部份就會以 subtask 的方式描述，想反的來說，對遊戲來說，UX 的流暢感相當重要，同樣一件事在遊戲專案上就會提昇至 story 層級。
第三種不適合用 story 描述的工項，即過於工程面或規格面的部份，舉凡 API 交換的規格、欄位的命名規範、錯誤處理的機制、log 檔的紀錄等等，皆不屬於 story 的範疇，應該用 task 來建立這些工項，有必要的話再用 Jira 的 issue link 的功能讓 story 與 task 相關連起來。
Story 的標題格式
網路上最常看到的格式：
As a XXX, I want XXX feature so that XXX.
這句充滿贅字又是洋文的句子應該簡化成這樣：
某某某 要 如此如此 才能 這般這般。
絕對不要把贅字也寫進來，不論是洋文還是華文。
小隊員日誌 