本文工作流模式,是我担任
LIZI UI Design
团队 Leader 时,基于 GitLab 的工具集,创建的一套标准的研发工作流。当前文档是对这套工作流的拆解和说明。
由于团队成员分属不同业务线,日常碰面、交流的机会比较少,不能用早会、日报等普通的项目管理方式,对项目研发进度进行把控,所以需要一种全新的管理模式。
主要的痛点有:
基于以上痛点,选择了 GitLab 提供的工具集,来一一解决。
接下来,开始这套工作流的讲解。
小组成员,通过开会讨论,确定一个周期内的目标,包括有哪些交付物,需要的研发时长,再由此反推,确定好相应的里程碑。
进入 GitLab 的小组项目(以后的语境,均在此项目下,后续不进行累述),打开 Milestones 进行里程碑设置。
如下图所示,设置
主要的信息标签类别有:
进入 Labels 设置页面,点击 New Label 按钮进行创建即可。
看板的作用是可以清晰地、透明化地体现当前项目的进度情况和研发人员的工作状态。
如图所示,看板的阶段前后顺序依次为:
进入 Boards 界面,可以选择 Create new board 创建新的看板。
并通过 Add List 按钮,添加新的看板阶段。
如上图所示,Issue 的信息有:
其中,Assigness 的设置,可以在该 Issue 改变的时候,让任务执行者及时收到邮件通知。
另外,在 Description 中输入 /estimate(估时) 和 /spend(耗时) 进行工时的记录。
如图,输入估时后,在 Issue 的信息面板中,Time tracking 会有信息的展示。
如图,输入任务耗时后,在 Issue 的信息面板中,Time tracking 会根据任务估时和当前的消耗时长,进行百分比的进度展示。
通过 New Issue 的方式,将任务的信息记录到 Issue 中,并打上信息标签待准入。
经过团队成员确认后(可通过开会的方式,集中确认),将该 Issue,通过看板面,移动到待认领阶段。
并且,为该 Issue 打上 Milestone(里程碑)的标记,正式确认当前任务所属的里程碑。
在认领阶段的任务,团队成员只要将该 Issue 打上 developer:名字的标签,即可完成认领。
需要操作以下 3 个步骤:
如下图所示,操作完成后的 Issue 面板信息。
另外,如果想要利用 GitLab 的 To Do 功能,可以在该 Issue 面板的最上方,点击 Add To Do 按钮,即可。
任务状态的改变,都是通过看板,对 Issue 进行移动,来完成更改的。
比如,当前的任务正在编码中,就将 Issue 移动到 Doing 阶段。
具体如下图所示:
当任务编码完成后,Issue 移动到待 Review 阶段。
这个时候,可以由 Issue 的研发者去找团队其他成员进行代码 review,也可以由其他成员,主动进行 review。
review 的人员,需要将该 Issue 打上 reviewer:名字 的标签,表示自己负责当前任务的 review。
打标签后,如下图所示:
另外,需要研发者发起 Merge Request 请求,将 feature-**分支的代码,合并到对应的 dev-**分支。
如上图所示,需要做以下几件事:
负责 review 的人员,在 review 完代码后,对 MR 请求进行 resolve,合并进 release 分支。
然后,将看板中的 Issue 移动到待关闭阶段。
需要注意的地方:当 feature 分支的代码,与要合并的 dev 分支产生冲突时,需要研发在本地解决冲突,并 push 到远程的 feature 分支,才可以合并。
所有当前里程碑的任务完成后,将 dev-***分支的代码合并到 dev 主分支,再由 dev 分支合并到 master 分支和 release 分支,并进行版本发布操作。
然后,将看板中,待关闭阶段的 Issue 移动到 Closed 阶段。
最近笔者在整理第一本电子书书稿《前端面试手册》,有兴趣的同学可以关注下~
喜欢我文章的朋友,可以通过以下方式关注我: