Recently, our company has become interested into a better work process. Even though we’re using Jira system, we’re not fully utilizing it.
Our team consists of a total of 5 people. we’re assigned at least two works each people within a sprint. and our JIRA board provide that only one sprint can be run. so we’re in trouble to manage our issue ticket and focus on our job. That’s why we need the better process for our productivity.
1. Constructing a sprint that can move in parallel.
the best to focus on my job is to have one assignment without any blockers. However, our company is still start-up and not many developer to handle all of business. so one people had to do multiple jobs. the first thing we can do is to have project that can move sprints in parallel. so we re-create the project.
2. Configuring a more detailed work process.
the previous work process was the most basic created project, consisting of to-dos, in-progress, and completed. we needed to manage in smaller units. So, We have organized it a little more subdivided as follows.
- OPEN: this node tells you the ticket is still in backlog.
- IN PROGRESS: this node tells you the ticket is in progress.
- IN REVIEW: this node tells you the ticket is done and move to code review.
- APPROVED: this node tells you the code review is done and merged to develop branch.
- QA중: this node tells you the ticket is in QA.
- QA완료: this node tells you the ticket completed QA.
- DONE: this node tells you the ticket is done!
- CLOSED: this node tells you the ticket is no longer required to proceed or created by mistake.
3. Setting the right issue type for us
Previously, we didn’t manage issue type so we can’t generate any valid reports. It was very important because it shows whether we are doing our job well or not. So we matched the issue type with Github as follows.
- feat: this tells you the ticket is related to new feature or any updates.
- fix: this tells you the ticket is related to fixing bugs.
- refactor: this tells you the ticket is related to improve the code.
- docs: this tells you the ticket is related to create or update the documentation.
- meetings: this tells you the ticket is related to meetings.
- test: this tells you the ticket is related to test code.
4. Integrating Github and Jetbrain
I think the reason technology advances is that humans are inherently lazy. Even we have proper JIRA system, it would be useless if we don’t manage. Therefore, we worked on integrating Github and Jetbrain so that team members can use it more conveniently. Let’s say we have a ticket and we start to work. the work process will proceed as follows.
- Create a branch through the JIRA command linked in the JetBrain tool. (Tickets automatically go IN-PROCESS.)
- Complete the task and create a commit. And generate PR. (At this time, the ticket moves to the IN-REVIEW state as the trigger is executed automatically.)
- When PR is completed and reflected in the develop branch, it automatically moves to the approved stage.
- In the QA stage, it is moved manually after proceeding. (This part is still figuring out how to automate it.)
- Create a PR from the develop branch to the master branch and move the ticket to Done if it is merged.
Conclusion
We still have many shortcomings and many areas for improvement. Nevertheless, it has improved a lot from the previous work process and we will always be watching to make sure we can make better use of it in the future.
