產品經理、測試人員、開發人員統一在 GitLab 中管理需求、bug。
Why
為什么通過 GitLab issue 管理，而不是 Jira、Redmine 等工具？
- 開發團隊最終交付物為項目代碼，需求、bug 最終都會轉換為一行代碼、一次 MR。通過 issue 可以讓每一步都可以溯源。
- GitLab issue 更輕量，Markdown 語法讓 issue 更專注於內容本身
How
- 每組通過獨立項目統一管理 issue，在 Readme 中描述使用方式及定義
- 通過 milestone 管理項目版本，對齊目標。節奏很重要
- 通過 label 管理優先級(
P0|P-1|P-100)、類型(bug|feature) - 通過 board 查看 issue 進度狀態，配合
To Do、Doing、Verify等 label，定義 issue 生命周期 - 通過模板定義 author 需要提供的信息
項目 Readme
# 新建 Issue 相關細節 - 模板：從以下 2 者中進行選擇 - feature - bug - Assignee：開發負責人 - Label： - 優先級 - P-1：全線 block 工作，直接在群里匯報，不需要走 gitlab，例如： - 網站無法使用 - P0：block 個人工作 - P1：暫時不 block 工作，但是周尺度需要解決 - P2：暫時不 block 工作，周尺度外需要解決（配合 DDL-調整優先級） - label(可選) - BUG - Feature - 里程碑 - 需求提出月份 # 驗收-After 工程已完成測試 - 工程會在完成 BUG Feature 后指定相關人員做驗收，默認誰提 feature BUG 誰做驗收（可能會存在特殊的指定） - 開發完成后會放入verify看板，驗收通過后由author關閉issue GitLab issue 模板
在項目 .gitlab/issue_templates 目錄下的 Markdown 文檔，可以在新建 issue 時被選擇。利用這個特性可以規范 issue 內容，督促 author 提供有效信息。如：
feature.md
# 背景 > 回答為何要做：不做會有怎樣的問題；做了會有怎樣的收益； # 需求說明 > 回答要實現的目標是什么==需求說明 # 方案 > 回答如何去做, 提供參考思路或模型（可選-工程拍板） # 驗證 > 回答何叫做到, 驗證結果滿足預期的標准有哪些, 是什么.（滿足測試用例）
bug.md
# 步驟 > 本來想做的事情-描述 # Bug行為 > 被 block 的點-描述 # 期望行為 > 應該是什么樣 # 附件 > URL/相關信息-id 號/截圖(整個界面的完整截圖) 小技巧
- issue comment 移動 board 狀態 ->
/board_move ~Doing - 跨組關聯 issue ->
group/project#issueNO - MR 中關閉關聯的 issue ->
close #9 - 添加子任務 ->
- [ ] subtask1 - 添加 issue 耗時 ->
/spend 3d 5h 10m
作者：crick77
鏈接：https://hacpai.com/article/1574179406015