基于gitlab社区版的项目管理总结

多人员参与问题

产品某一个业务功能的实现会涉及到前端、后端、android、ios等多人员，gitlab 企业版提供了issue有多个assignees的功能，但很可惜社区版是没有这项功能的。

In GitLab Enterprise Edition, you can also select multiple assignees to an issue, making it easier to track, and making clearer who is accountable for it.

Consider a team formed by frontend developers, backend developers, UX designers, QA testers, and a product manager working together to bring an idea to market.

Multiple Assignees for Issues makes collaboration smother, and allows shared responsibilities to be clearly displayed. All assignees are shown across your team’s workflows and receive notifications (as they would as single assignees), simplifying communication and ownership.

Once an assignee had their work completed, they would remove themselves as assignees, making it clear that their role is complete.

社区版如何解决此问题？

解决此问题之前，先介绍一下Group。

1. Group是一个容器，里面可以包含子Group和Project

2. 产品研发参与的人员和角色可以在group中定义、也可以在project中定义，会有继承关系。

   例如：groupA下有projectA， groupA的参与人员有memberA，角色为guest，依据继承，projectA中的参与者也就会有memeberA

3. 在Project中创建issue，可以在分组目录通览

有了上面的知识后，开始解决某一业务功能多人参与的问题，步骤如下：

1. 一个产品对应一个根Group，分别建立前端、后端、android、ios对应的子分组
2. 产品所有的研发人员加入到根Group中，角色为Guest，前端、后端、android、ios人员分别加入到对应的子分组中，角色为Developer
3. 在前端、后端、android、ios等子分组中建立对应的Project（private或internal的）
4. 在每个子分组的Project中为这个业务功能分别创建issue，因为这些issue是为了解决同一个业务功能，issue描述的业务功能内容会相同，但是这些issue在每个分组中又会有所区别，例如前端会关注界面的样式、内容，后端会关注接口的逻辑和数据接口，在issue中描述要体现出来。

有了这几步操作，貌似并没有解决掉各个分组的研发人员需要交流沟通的问题。这里采用如下方式解决：

在根Group建立一个general project（public的），里面存放所有的设计文档、接口文档、原型和UI图。这个project是产品组每个成员都可看到的，这样通过这些文档就达到了沟通的目的。当然，这样做的一个约束（算不上缺点）就是需要设计、文档、UI图先行。这样也就能更好的规范了开发流程，解偶了各个开发人员之间的依赖关系，整体结构如下图：

image.png

总结：同一业务功能，不同类型的开发人员都有自己对应的group、project、issue，这些开发人员通过根project中的文档、UI进行交流沟通。对于同一issue，同一组中多个人员参与的话，只需在issue comment中@相应的人员即可

约束总结

根分组project维护的目录结构如下：

1. phone目录：存放移动端相关文档和设计图

   origin: psd原图

   prototype: 原型文件

   sketch:效果图

   document存放文档

2. web目录：存放web端相关文档和设计图

分组中维护的issue类型：

1. 子分组Project中只维护如下类型的issue

   1. 业务功能：例如查车、绑车
   2. 软件功能：例如友盟、版本设计
   3. bug

2. 根分组Project中主要维护的issue类型包含：

   1. 产品新想法
   2. 新需求

通过根分组中的issue定义产品里程碑，开展产品的迭代。根据子分组中的issue定义包的里程碑，开展软件的迭代

Issue标签规范

1. 领域相关

   • area/android android相关
   • area/ios ios相关
   • area/backend 后端相关
   • area/frontend 前端相关

2. 优先级相关

   • priority/P0 十分紧急（必须放下手中的工作立刻修复）
   • priority/P1 较为紧急（完成手中目前的阶段性工作，开始此项）
   • priority/P2 普通（完成手中所有p1的阶段性工作，开始此项）
   • priority/P3 不紧急（没事干的时候，开始此项）

3. 研发issue类型

   • kind/dev bug bug类型
   • kind/dev enhancement 改进项
   • kind/dev feature 新功能

4. 研发进度issue类型

   • open（issue board自带）
   • progress/dev doing 开发中
   • progress/dev done 开发完成
   • progress/dev schedue 下一步开发
   • closed（issue board自带）

   通过里程碑标识出已open的所有issue，团队站会时沟通将下一步要开发的issue标识为dev schedue ，将正在进行还没有开发完成标识为dev doing，开发完成的标识为dev done，里程碑关闭后将相关的issue close掉。

5. 产品issue类型

   • kind/product idea（产品新想法：例如，增加蓝牙无钥匙进入）

   • kind/product enhancement(产品已有功能改进：例如，交互功能、指令功能)

   • kind/product feature(产品新功能)

     注：尽量杜绝研发完成后，交互、样式、名称等细节的修改，这些在设计阶段确定完成（一步走稳之后再走下一步）

6. 产品进度issue类型

   • progress/product confirmed 已确认（经过讨论）
   • progress/product desiging 设计中
   • progress/product developing 研发中
   • progress/product done 产品迭代完成
     后面这三种类型，需要同时指定迭代里程碑

   注：产品类型的issue需要由owner进行review（原因：产品issue的提出可能是各种类型的人提供），入口比较杂，所以需要审阅。研发类型的issue不需要审阅，因为肯定是项目经理录入，入口可控。

7. 产品迭代和软件迭代

   涉及到产品迭代，则创建根组里程碑；涉及到某一端的软件迭代（例如android端3个apk），则创建子组里程碑；涉及到某一个软件的迭代，则创建project里程碑

   软件某一里程碑出现bug，在该里程碑中修复。小版本号升级

   产品里程碑v1.0
   软件版本则可为v1.0.0，当该里程碑的软件发现bug并修复后，软件版本可为v1.0.1

issue录入模版

1. bug issue 录入模版
2. 新需求录入模版
3. 业务功能issue模版
4. 软件功能issue模版
5. 产品亮点录入模版

模拟演练

1. 录入 产品新需求issue

   在根Group下的project中录入

2. 根据产品新需求issue，出用例、出思维导图，然后出原型，出效果图

   在根Group下的project中录入

3. 原型、设计文档都已在根Group下的project创建好，android里程碑已定义好，增加该里程碑中的研发issue信息

   New issue -> 标题、内容 -> 标签打上：area/android, priority/P1, kind/dev feature, 里程碑指定为该里程碑， assignee指派给具体的人员