需求

整个需求阶段，主要是首先有一个idea后，所有相关人员通过用户故事地图进行讨论，进行需求的整理、排期，最后通过gitlab issue落地的过程。

issues介绍

在整个软件的交付的周期中，issues的主要提出者是项目产品，主要是使用在以下的场景：

• 需求的整理：在通过用户故事地图完成需求的整理、排序、阶段划分后，我们通过issues实现最终结果的落地。
• 缺陷反馈：软件中出现了需要修复的bug，提出个issue标记出来，进行解决。
• 讨论、交流：issues的相关人员可以在issue的讨论区进行讨论、交流，同时大家也会了解到issue的进度情况。

同时项目的开发人员也可以使用issues来进行自己的任务管理。

在创建一个issue的时候我们可以设定该issue的标签、里程碑、执行人、截止时间等。

标签(labels)

我们通过标签实现对issues的分类，方便对issues进行管理和筛选。每个issue可以贴上多个标签。对于标签主要从两个方面进行标签的划分。

• 一个是issue的性质，包括（bug、enhancement等）
• 一个是issue的优先级，可以通过颜色来进行划分。

里程碑(milestone)

对于一个阶段的多个需求可以设立一个里程碑，可用于确定哪些问题需要在当前版本解决，那些问题在下一个版本解决。 此外，由于每个问题都定有里程碑，每当一个问题解决，它会自动更新进度条。

如何使用issues

issues的主要使用者是项目产品和开发人员：

项目产品

当产品有新的需求的时候，可以到相关项目下创建自己的需求，并可以指定相关人员、标签、截止日期和里程碑，创建需求时需要注意以下几点：

1. issue的标题应该描述出最后想要的结果来。
2. issue的标题尽量使用简洁的英文描述为开头，方便开发人员创建分支。
3. 每个issue尽可能的小，可以将多个小issue关联到一个大的issue里，通过子任务的方式体现，同时可以直接连接到相关issue上(使用#进行关联)。

如果一个项目有前端、后端、ios等的时候，需要创建一个这个项目的群组，然后在群组下分别创建后端、前端、ios等项目，产品人员需要在当前群组下创建产品的项目。将需求任务创建到这个项目下，然后各个项目的负责人在将项目关联到相关项目下进行任务分配。

开发人员

开发人员主要是通过issues进行自己的开发任务管理，可以给自己的开发任务贴上develop标签，并可以和产品提出的需求进行关联。

issues使用中的一些小技巧

1. 快速引用

   Issue 这里是没有 reply 按钮的，如果你想回答具体某个问题，可以用鼠标选中那段话，然后敲r 。 这样这段话就自动出现在你的评论框中了。

2. 拉别人进来讨论

   可以在评论框中输入 @user 来通知某人进来讨论，无论这个人是不是这个项目的参与者。

3. 用版本留言关闭 Issue

   如果有人给我的项目提了个 Bug，在一个编号为20的 Issue （后面简写为 Issue#20） 里。那我写几行代码修复这个 Bug 之后，在客户端作版本时，只要在版本留言里面写 fix #20 这样的字样，这个版本同步到 Github 上之后，这个 Issue#20 就自动关闭了。

4. 问题关联

   可以在当前的issue里通过#来关联其他issue，如果是跨项目进行关联前面需要加上项目的path，例如：root/demo#20。