The workflow model in this paper is a set of standard R&D workflow created based on GitLab toolset when I served as LIZI UI Design team Leader. The current document disassembles and explains this workflow.

background

As team members belong to different business lines, there are few opportunities to meet and communicate with each other, and ordinary project management methods such as morning meeting and daily report cannot be used to control the progress of project research and development. Therefore, a new management mode is needed.

The main pain points are:

  1. The research and development goals and milestones of the project are not clear
  2. The breakdown of tasks is not clear
  3. Team members cannot keep track of each other’s current development status
  4. Collaboration between team members and lack of information recording

Based on the above pain points, we choose the tool set provided by GitLab to solve them one by one.

Next, start this workflow.

Key Elements

Identify project milestones

Team members meet and discuss to determine the goals for a cycle, including what deliverables are available and how long the development will take, and then work backwards to determine the corresponding milestones.

Enter the group project of GitLab (the subsequent context is under this item, and there is no elaboration in the follow-up) and open renamed project for milestone setting.

As shown below, set

  • Milestone Code (Title)
  • Job Description
  • Start Date
  • Due Date

Identification information label

tag

The main categories of information labels are:

  • To access
  • shelters
  • Doing
  • To review
  • Stay close
  • Developer: name
  • Reviewer: name

Set up the

Enter the Labels setting page and click the New Label button to create Labels.

Kanban Settings

The function of kanban is to clearly and transparently reflect the progress of the current project and the working status of the r&d staff.

Stage show

As shown in the figure, the sequence of kanban stages is as follows:

  1. Open (default Open phase)
  2. To access
  3. shelters
  4. Doing
  5. To Review
  6. Stay close
  7. Closed (default shutdown phase)

Set up the

On the Boards screen, select Create New Board to Create a new kanban.

Add a new Kanban stage through the Add List button.

Issue of the set

Issue instructions

As shown in the picture above, the message of Issue is:

  • Task Name (Title)
  • Description of the task
  • Assignee of tasks
  • Milestones to which a task belongs
  • Current state of the task (Labels)
  • The Due date of the task

Assigness can be set up so that taskers receive email notifications when the Issue changes.

In addition, enter /estimate and /spend in Description to record the time.

Example of task evaluation duration

As shown in the figure, Time tracking information will be displayed in the information panel of Issue after entering Time estimation.

Example of task consumption duration

As shown in the figure, after input the task Time, in the information panel of Issue, Time Tracking will display the progress by percentage according to the estimated task Time and the current consumption Time.

Task workflow explanation

The initial task

Record the task information to an Issue through New Issue and label it for access.

After confirmation by team members (through a meeting, confirm centrally), move the Issue to the unclaimed stage via the dashboard.

Also, mark the Issue with a Milestone to officially confirm the Milestone to which the current task belongs.

To claim the task

For tasks in the claim phase, team members can claim the Issue simply by labeling it with the name Developer:.

Determine the time information and development cycle of the task

You need to perform the following three steps:

  1. Assignee is set to itself for receiving email reminders
  2. Set Due date, approximate estimated completion date of the task
  3. Description allows you to set the estimated time and duration of a task

As shown below, the information of the Issue panel after the operation is completed.

In addition, if you want To use the To Do function of GitLab, you can click the Add To Do button at the top of the Issue panel.

Task state changes

The change of task status is accomplished by moving the Issue on kanban.

For example, if the current task is being coded, move the Issue to the Doing stage.

The details are shown in the figure below:

Review stage

Changing Issue Status

When the task coding is complete, the Issue moves to the stage to be reviewed.

At this point, the developer of the Issue can review the code with other members of the team, or other members can take the initiative to review the code.

Review staff will need to label the Issue with a reviewer: name indicating that they are responsible for the review of the current task.

After labeling, the picture is as follows:

Submitted to Mr.

In addition, need developers launched the Merge Request Request, will feature – * * * branch code, merged into the corresponding dev – * * * branch.

As shown in the figure above, the following things need to be done:

  • Identify the branches to merge
  • Fill in the merged information (Title)
  • In Description, type # to be prompted, select the corresponding Issue to be associated with the current MR

  • Set Assignee and Milestone

Code branch merge

The review person, after reviewing the code, resolves the MR request and merges it into the Release branch.

Then, move the Issue in kanban to the pending close phase.

Note: When the code of the feature branch conflicts with the dev branch to be merged, the developer needs to resolve the conflict locally and push it to the remote feature branch before merging.

release

After all the tasks for the current milestone are complete, the dev-*** branch code is merged into the dev main branch, which is then merged into the Master and release branches, and the release operation is performed.

Then, move the Issue in the Kanban phase to the Closed phase.