Issue / Ticket 任務單

用來記錄需求、bug、問題或待辦工作的單位。

先用一句話理解

用來記錄需求、bug、問題或待辦工作的單位。

打個比方

像工作派單，每張單有目標、負責人與狀態。

什麼時候會遇到

需求變多、多人協作、客戶回饋需要整理時。

再往深一點看

Issue（或稱 ticket）是管理工作的最小單位：它可以是一個功能需求、一個 bug 回報、一個討論問題，或一個待辦改進。每個 issue 通常會有標題、描述、負責人、優先級與狀態，讓整個團隊都能看到「這件事做到哪了」。在 GitHub 上，你可以把 commit 或 PR 連結到特定 issue，合併後 issue 自動關閉，形成從需求到程式碼的完整追蹤鏈。在 Linear 這類工具裡，issue 還可以組織進 sprint 或 milestone，幫助掌控整個版本的進度。Issue 跟 PR 不同——issue 是「要做什麼、為什麼做」的討論，PR 是「已經寫好的程式碼請求合併」的審查。

舉個例子

客戶回報「手機上登入按鈕點不到」，你在 GitHub 開一個 issue 描述問題與重現步驟，指派給自己，標記為 bug。修好後開 PR 並在描述裡寫 Closes #42，合併進 main 後 issue 自動標記為已關閉，客戶問問題處理了沒，你直接把 issue 連結傳過去。

常見誤解

- 把需求、決策和 bug 都放在 Slack 或 LINE 群，時間一長找不到當初的討論，同一件事要重新解釋好幾次。
- Issue 寫得太簡略（只寫「登入壞了」），沒有重現步驟、預期結果和實際結果，接手的人根本不知道從哪裡開始查。
- Issue 開了就不更新狀態，幾週後積了一堆不知道是否還需要做的 issue，變成維護負擔而非管理工具。