基于 Gitlab 进行开发团队管理的尝试——00. 通过 issue 管理需求

What

产品经理、测试人员、开发人员统一在 Gitlab 中管理需求、bug。

Why

为什么通过 Gitlab issue 管理，而不是 Jira、Redmine 等工具？

1. 开发团队最终交付物为项目代码，需求、bug 最终都会转换为一行代码、一次 MR。通过 issue 可以让每一步都可以溯源。
2. Gitlab issue 更轻量，markdown 语法让 issue 更专注于内容本身

How

1. 每组通过独立项目统一管理 issue，在 Readme 中描述使用方式及定义
2. 通过 milestone 管理项目版本，对齐目标。节奏很重要
3. 通过 label 管理优先级(P0|P-1|P-100)、类型(bug|feature)
4. 通过 board 查看 issue 进度状态，配合 To Do、Doing、Verify 等 label，定义 issue 生命周期
5. 通过模板定义 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 号/截图(整个界面的完整截图)

小技巧

1. issue comment 移动 board 状态 -> /board_move ~Doing
2. 跨组关联 issue -> group/project#issueNO
3. MR 中关闭关联的 issue -> close #9
4. 添加子任务 -> - [ ] subtask1
5. 添加 issue 耗时 -> /spend 3d 5h 10m