敏捷系列 | 一次搞懂敏捷專案管理中的Epic、Story/Task與Subtask
從子彈筆記的概念出發，對比子彈筆記與敏捷專案管理中Epic、Story/Task與Subtask的相似之處
相信有不少在進行敏捷專案管理的企業，一定都會用JIRA這款軟體來做管理，剛開始我在使用JIRA管理專案時，一直對於Epic(史詩)、Story(故事)/Task(主任務)、Subtask(子任務)這項目的定義感到困惑。
為了清楚理解Epic(史詩)、Story(故事)/Task(主任務)、Subtask(子任務)之間的關係，因此跑去書店購買了《Mike Cohn 的使用者故事：敏捷軟體開發應用之道》，並爬了一些網路文章，大概可以將Epic、Story、Subtask解釋為：
- Epic(史詩)：一個過於龐大的故事，通常可以區分成複合故事或複雜故事
- Story(故事)：使用者故事描述使用者或購買者有價值的系統或軟體功能
- Task(主任務)：專案代辦的事項
- Subtask(子任務)：代辦事項中具體的行動
當下在閱讀時，初步理解Epic應該是在描述一個複雜且大型的功能，Story(故事)指的是從一位用戶的視角出來，來想像使用這項功能後，能夠幫助我解決什麼樣的問題，也就是常常在敏捷專案中，撰寫使用者故事常會聽到的 As a “role”, I want to “do something”, so that I can “get value”.
而Task(主任務)則是專案某件的代辦事項需要被完成，例如約一場客戶會議，完成客戶報價，舉辦使用者訪談等，Subtask則是依附在Story/Task底下的子項目，例如：與客戶確認合約、撰寫需求規格書等。
但這時候問題來了，如果今天老闆突然跟你說：「欸~Alex，最近我看我們用戶在app上下單時，都只能單次下單，我看很多app都有購物車功能，能讓用戶選購好一推產品後，一次進行下單，我覺得我們會需要開發這項功能。」
因此當接受到這項「開發app購物車功能」的任務時，我是要把他放在Epic還是Story呢？
然而在一次與團隊IT夥伴在討論Epic(史詩)、Story(故事)/Task(主任務)、Subtask(子任務)這幾個項目在敏捷專案中的分類想法時，讓我聯想到先前讀過的電腦玩物站長Esor這本書《大腦減壓的子彈筆記術：用Evernote打造快狠準任務整理系統》，Esor的子彈筆記將專案管理的方式拆解成：「專案、任務、行動」三個分類，這樣的區分方式其實跟敏捷專案中的Epic(史詩)、Story(故事)/Task(主任務)、Sub-task(子任務)分類方式很相似。
因此，今天會用購物車功能為例，來與大家分享我對於Epic(史詩)、Story(故事)/Task(主任務)、Sub-task(子任務)的理解，並比較他們與Esor的子彈筆記專案管理方式的相似之處。
一、Story就如同子彈筆記中的任務，是一個成果交付的最小單位
Esor認為任務應該是在大型的目標專案群組中，最小、最基本的單位，換言之，當我們在接收到一個專案時，會把它拆解成數個任務，如果專案中的各項任務都有被交付，意味著這個專案也就完成了。
因此我們可以把專案與任務的關係畫成以下的關係圖：
當我們了解到子彈筆記中專案與任務的上下層關係後，再回到敏捷專案中的Epic與Story，前面有提到Epic可以被理解成一較大的功能需求單位，或是這個需求過於複雜，一時之間不好做拆解或想像時，我們可以把一個Epic視為是一個專案。
再來是Story，Story在敏捷專案中的定義為：「一個可以被估計開發時數(Story Point)、易於修改調整，且具成果產出的最小單位」，對照到子彈筆記中的任務是再適合不過了，因為Story符合子彈筆記中所說的「一任務，一筆記」換言之一個Story就是一個可被專案交付項目，因此Story很適合拿來被放入到每次團隊的Sprint衝刺，搭配燃盡圖使用，可以讓團隊一目瞭然來檢視這個Story所耗費的開發時數。
因此我們可以把Epic與Story的關係畫成以下的關係圖，並把子彈筆記中的專案與任務放到關係圖中一併做對照：
接著我們再來區分敏捷專案中的Story與Task，Story主要是用來描述用戶功能，跟功能實作比較有關，例如用戶可以在購物車中新增商品，背後可能就會有一支新增商品的API在運作，而Task則是專案各階段產出物，例如一個產品功能可能會經歷，需求收集、需求分析、功能開發與測試上線，在完成需求收集時，我們會需要產出一份用戶需求訪談報告，這份產出報告就可以被視為一個Task。
二、Subtask就如同子彈筆記中的行動，也就是要完成這件事情的所需步驟
當我們釐清子彈筆記中專案-任務與敏捷專案中Epic-Story的應對關係後，再來就是思考該行動與任務之間的關係。
行動，英文為action，也就代表執行任務的意思，舉例來說，你今天要規劃一趟到三天兩夜的花蓮行，旅途中我們會需要規劃交通、住宿、餐廳、景點等，根據Esor子彈筆記的概念，三天兩夜的花蓮行就是一個專案，交通、住宿、餐廳、景點這些都是任務，假如我們在交通的部分選擇搭火車，而訂購火車票裡面包含的環節如查詢時刻表、確認班次、付款、取票這一連串的行為，就是為了完成訂購火車票這項任務的行動。
因此當我們有了行動就是為了完成任務所需執行具體步驟的概念後，就可以繪製出專案-任務-行動這三者的關係圖：
理解了專案-任務-行動這三者的關係後，再回到我們購物功能的案例，購物車功能本身就是一個Epic，完成這個需求我們會需要讓用戶可以在購物車中新增商品，也會希望購物車能夠幫我們結算這些商品總金額，這些都可以被視為一個Story，我們該用戶可以在購物車中新增商品呢？，也許是透過開發一支新增商品的API來實現，這時候我們就可以具體拆解出要完成這支API的具體步驟，像是：功能實作分析、功能程式開發、功能驗收、部屬上線，這些一連串的步驟，都可以被視為是一個行動，對應到敏捷專案中的名詞，它們就是Sub-task，也就是子任務。
順著這個思路，我們可以繪製出敏捷專案中的Epic-Story-Subtask三者之間的關係：
確認上述Epic-Story-Subtask三這之間的關係後，再把Esor子彈筆記中對於專案-任務-行動的關係圖進行比對，可以得到以下結果：
從上述比對結果中我可以發現，其實敏捷專案管理其實也是一種子彈筆記心法，讓我們可以快速且精準地鎖定要完成的任務，並設定具體的產出目標，加速我們專案推進的效率。
三、結語
當然敏捷專案管理除了Epic(史詩)、Story(故事)/Task(主任務)、Subtask(子任務)外，還有包含product backlog、sprint、retrospective等概念，但若就以管理專案項目的角度切入，其實敏捷專案管理與子彈筆記所提倡的概念頗有相似之處，都是幫助我們在變動快速的環境下，如何有效地精準打擊，有彈性地來解決問題，讓我們擁有更充裕的時間來因應快速變化的市場與需求。
感謝各位朋友的支持與鼓勵!
當你／妳閱讀完這篇文章後，請依喜歡與實用程度給我1–10個拍手。
讓我能了解各位朋友寶貴的回饋意見，撰寫更優質的內容分享給你/妳!
