Github 칸반 보드 경험기

들어가며

최근 운영 프로젝트 업무 내용 확인하다 보니 구축 시에는 칸반 보드를 생성하였으나 운영 모드에서는 사용하지 않아 파악이 어려웠던 경험이 있었고, 앞으로 진행하는 프로젝트는 깃헙 칸반 보드를 적극 사용했으면 하는 마음에 얘기를 해보고 싶어 졌습니다.

칸반보드를 도입하게 된 배경

기존에는 맥북의 그룹 메모, 슬랙 메신저로 정보를 취득하는 환경이다 보니 시간별로 데이터를 쌓는 구조여서 정보가 쌓을수록 데이터 구분이 되지 않았고, 산발적으로 쏟아지는 업무와 다수 작업자의 업무 및 진행사항은 프로젝트 그룹원 모두 파악하기 어려워 기억에 의존하거나 PL이 개인적으로 기록하고 있는 환경이었습니다. 

⇒ 작업자별 각자 업무를 파악하고, 여러 작업의 진척 상황을 한눈에 구분할 수 있고, 특정 업무별 히스토리를 기록할 수 있는 깃헙 칸반 보드를 도입하기로 하였습니다. 

칸반 보드(Kanban board)

‘간판’의 일본식 발음으로 도요타 생산 방식에서 유래

칸반 보드는 프로세스의 연속적인 흐름을 유기적, 시각적으로 구체화하여 전체 프로세스를 유연하게 하는 방법론으로 개발 프로세스의 병목현상을 방지, 리소스 낭비를 해결하는 목적을 두어 팀과 팀원이 할 수 있는 작업량 간의 밸런스를 맞추는 도구입니다. 

칸반 보드를 통해 얻고자 하는 것

• 업무 시각화를 통한 진척 관리
• 진행 중인 업무 제한하기
• 그룹 내 코드 피드백 루프를 만들기
• 개발 프로세스를 구축 + 발전시키기
• 프로젝트 정보 아카이빙(히스토리 확인 및 추후 참고용)

칸반 보드를 본격적으로 사용 시 고민해 보면 좋을 것

1. 칸반 보드를 어떻게 구성하는 게 좋을까
2. 칸반 보드 아이템은 언제, 어떻게, 누가 추가하는 게 좋을지
3. issue & pull request 어떻게 구성하는 게 좋을까

1-1. 프로세스 추가하기

깃헙 repository 내에서 프로젝트를 생성하면, 디폴트로 basic kanban이 생성되고 setting 탭을 이용해서 추가 설정이 가능합니다. 

• Todo : 해야 할 작업
• In Progress : 진행 중인 작업
• Done : 완료된 작업

저는 개인적으로 backlog, review 추가해서 작업 목록 리스트와 코드 리뷰를 관리할 수 있는 탭을 추가하는 걸 추천합니다.

• backlog : 아직 처리되지 않은 업무, 작업, 요구사항 목록 리스트
• review : 작업자가 작업 완료 이후 검수 상태

1-2. 아이템별 프로젝트 상세 세팅

• Text : 작업 분류 (bug-fix, hotfix, 기능 추가, 기능 삭제 등등) issue의 Label 속성과는 별개로 칸반에서 텍스트가 노출되어 시각적으로 인지 가능
• Number : 작업자에게 업무 우선순위를 부여하거나, 필요에 따라 지라 이슈 설정
• Date : Issue 생성 시 작업 마감일을 지정
• Single select : 작업의 우선순위를 지정(높음, 낮음, 보통)
• Iteration : 프로젝트의 개발 주기(대체로 주 단위), 스프린트 또는 버전 단위로 정의

아래 이미지는 backlog, review 탭을 추가하고 project 상세 세팅을 완료해서 이슈를 작성한 예시입니다. 

 

1-3. WorkFlow 추가하기

프로젝트 세팅 탭에서 "WorkFlow"를 지정할 수 있는데, 사용하고 있는 flows에는 자동화 설정 속성 “ON” 활성화해 주어야 실행이 됩니다. 아래 설정은 제가 개인적으로 편리하다고 생각해서 설정한 flow이고, 프로젝트에 따라서 조금씩 변형해 보시면 좋습니다. 

• Item added to project : 이슈 생성 시 backlog or Todo 탭으로 이동
• Item closed : 칸반의 item (issue / pull request) 가 “Closed” 되면 ⇒ Done으로 이동
• Pull request merged : pull request가 “Merged“ 되면 ⇒ Done으로 이동
• Item reopened : Closed 된 칸반 아이템을 “Reopen” 하는 경우 ⇒ Todo 탭으로 이동

2. 칸반 아이템 추가하기

• 프로젝트 PM / PL이 각 주기에 요구 사항을 추가하고 우선순위, 기한을 설정
• 규모에 따라서 요구 사항 추가, 우선순위 + 기한을 설정을 나눠서 진행
• 작업자 스스로 추가해서 업무 상황을 공유.

3. issue & pull request 템플릿 만들기

issue, pull request를 작성하는 양식을 표준화하면 가독성을 높일 수 있고 좀 더 쉽고 빠르게 작성할 수 있어 템플릿을 생성하는 것을 추천합니다. 

issue 설정 방법

repository 내 [ Setting > General > Features > issues ] 탭에서 템플릿 기능 추가 마크다운 양식으로 추가해서 문서로 저장할 수 있습니다.

• feature 이슈 예시
  

  

• bug 이슈 예시

// feature
### 설명

### 진행사항
- [ ]
- [ ]

### 참고 내용 및 이미지

// bug
### 설명

### 재현 방법
- 테스트 환경 디바이스 :
- [ ] 데스크톱
- [ ] 태블릿
- [ ] 모바일 - ios
- [ ] 모바일 - aos
- 디바이스 버전 : 
- [ ] chrome
- [ ] safari
- [ ] firefox
- 테스트 방법 : 

### 진행 사항
- [ ] .
- [ ] .

### 피그마

### 참고 내용 및 이미지

pull request 설정 방법

pull_request_template.md 파일로 작성하여 루트 디렉토리 내 생성하여 push 하면 pull request탭에서 확인할 수 있습니다. 

### 설명 

***

### 수정 내용
- [ ] 공통 추가
- [ ] 공통 수정
- [ ] 화면 기능 추가
- [ ] 화면 기능 개선
- [ ] bugfix
- [ ] 빌드, 환경 수정
- [ ] 리팩토링
- [ ] 기타 :

*** 
### 작업 내용

마치며

이 글은 작년에 프로젝트 진행하면서 깃헙 칸반 보드 경험했던 글을 적어보았습니다.

올해는 내부 프로젝트를 깃헙 repository를 이용하면서 깃허브의 pull-request, issue, milestone 등 프로젝트 관리에 다양하게 이용해 보고 있는데요. 여러 프로젝트를 진행하면서 개선되고 새로운 기능들은 한 번 더 업데이트를 해보는 게 좋을 것 같습니다.

읽어주셔서 감사합니다.

이 글은 pxd XE Group Blog에서도 보실 수 있습니다.