[Git] 프로젝트 관리는 애자일(Agile), GitHub에서 칸반(Kanban) 보드 사용 방법

협업/프로젝트 할 때 프로젝트 관리는 필수라고 생각합니다.

 

애자일은 효율적이고 유연한 방식으로 목표에 달성 할 수 있도록 하는 업무 방식을 목표로 하기 때문에 요새 많은 기업들이 문화로 도입하고자 노력중 입니다.

 

칸반이란?

칸반(Kanban)은 반복적인 프로세스의 단계를 명확히 나누는 프로젝트 관리 방식입니다. 보통은 칸반 보드로 시각화되고 각각 단계는 열로 표시합니다. 

 

 

GitHub에서 칸반을 사용하는 방법을 간단하게 알아보겠습니다.

 

 

GitHub -  칸반 보드 컬럼 정의

GitHub에서 칸반(Kanban) 보드를 사용할 때, 각 컬럼(Backlog, Ready, In Progress, In Review, Done)의 의미는 다음과 같습니다:

1. Backlog (백로그):
   • 해야 할 일 목록입니다. 아직 작업이 시작되지 않은 일감(이슈, 작업)을 여기에 모아둡니다.
   • 이 단계에서는 작업 우선순위를 정하거나 할 일을 추가해 놓습니다.
   • 현업에서는 일감으로도 불립니다. (ex. Jira)
2. Ready (레디):
   • 작업을 시작할 준비가 된 일감이 위치하는 칸입니다.
   • Backlog에서 작업 우선순위가 정해지고, 곧 작업이 시작될 수 있는 상태가 되면 Ready로 이동합니다.
3. In Progress (진행 중):
   • 현재 작업 중인 일감이 위치합니다.
   • 개발자가 작업을 시작하면 해당 일감을 In Progress로 이동시켜 현재 작업 중임을 나타냅니다.
4. In Review (리뷰 중):
   • 작업이 완료되었지만, 다른 팀원의 코드 리뷰나 검토가 필요한 상태입니다.
   • 리뷰어가 이 단계에서 코드를 검토하고 피드백을 제공합니다.
5. Done (완료):
   • 작업이 완전히 끝나고, 검토 및 테스트를 모두 통과한 상태입니다.
   • 이 단계로 이동된 일감은 더 이상 작업이 필요하지 않습니다.

이러한 칸반 보드를 통해 작업의 진행 상태를 한눈에 파악할 수 있어 프로젝트 관리에 큰 도움이 됩니다.

 

 

GitHub -  칸반 보드 사용 방법

레퍼지스토리 만들기

 

projects > New projects

 

칸반 선택

 

사용하기

Projects에서 다시 편집할 수 있습니다.

---

 

 

마일스톤 만들기

- 마일스톤(Milestone)은 프로젝트 관리에서 중요한 목표나 이정표를 의미합니다. 특정 기간 내에 이루어야 할 중요한 작업이나 목표를 설정해 놓은 것으로, 프로젝트의 진척 상황을 확인하고 관리하기 위해 사용됩니다.

 

이슈 만들기

- 레파지스토리 선택

- To do list 작성하기

 

Assignees, Labels, Projects(Priority, Size, ..) 를 선택합니다.

  - Assignees: 팀원

  - Labels: 개발 등

  - Priority: 우선순위(P0: 1순위, P1: 2순위, P2: 3순위) 

  - Size: 프로젝트 규모

  - Milestone

 

 

레파지스토리에서 확인

 

 

+ 추가(선택)

 칸반 컬럼 이동 - 자동화할 수 있습니다. (workflows 활용)

 

종료

 

자동으로 Done 넘어감

---

+ 추가 팁 (선택)

 

- 팀 프로젝트를 진행할 경우, 이슈 만든 다음에 In review 에서 ex) "@tom 코드 리뷰 부탁드립니다."(tom이 팀원 이름이라고 가정할 때) 입력하기

 

 

 

---

+

깃허브 추가 기능 - Discussions

Settings > General > Discussions 체크

 

- 게시판(질의응답) / 공지 등 다양한 것을 할 수 있습니다.

- 문서들이 쌓이게 됩니다 !

 

 

---

그렇다면, 우리 부서는 어느 기반으로 애자일 방법론을 사용해야 할까?

• 프로젝트 같은 종료 일이 정해져야 하는 업무가 많이 발생하는 경우는 스크럼을 사용하는 것이 효율적 입니다.
• 지속적인 업무를 다루며 프로젝트 개발 및 ops까지 함께 다뤄야 하는 상대적으로 작은 단위의 팀에서는 칸반을 사용하는 것이 효율적 입니다.

Hotfix 라는 이슈를 다루는 관점에 대한 스크럼과 칸반의 차이

HotFix란 말 그대로 예측되지 않았던 요청입니다.

운영되고 있는 서비스라면 고객이 마주친 버그 일 수도 있고, PO가 계획 당시에는 미처 정의하지 못했던 급한 business requirement 일 수 있습니다.

스크럼 에서는 Hotfix는 해당 스프린트에 “절대” 넣지 않습니다.
스프린트 진행 중 발생하는 모든 Hotfix는 무조건 다음 스프린트의 백로그로 쌓이게 되고 다음의 업무가 됩니다. (운영 중인 서비스라면 개발자가 돌아가며 운영 업무를 맡기도 합니다)

칸반 에서는 Hotfix 또한 바로 프로젝트 backlog에 쌓습니다.
반대로 칸반은 쌓여진 Hotfix를 바로바로 처리할 수 있습니다. 해당 프로젝트를 끝내기 위해 처리해야 할 이슈 카드로 동일하게 취급합니다.