如何理解 Jira 的 Story

#jira

雖然 Jira 的頁面載入的又慢，UX 又差勁，導致快要被新崛起的 Linear 幹掉，但在資訊產業 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 相關連起來。