개발 프로젝트 GitHub Repository에 꼭 필요한 요소를 이해한다.
칸반이 무엇인지 이해한다.
칸반 원칙과 실천 방안에 대해서 이해한다.
Github Project, 이슈, 마일스톤 기능을 이용하여 칸반 보드를 제작할 수 있다.
칸반 보드로 업무 시각화를 할 수 있다.
🐋GitHub Repository
💙GitHub Repository에 꼭 필요한 파일
- README.md
-
오픈소스 프로젝트에 들어가면, 가장 먼저 확인할 수 있는 정보가 바로 이 README.md 파일이다.
-
README.md 파일을 적는 양식은 따로 존재하지 않지만, 대체로 어떻게 하면 해당 오픈소스를 활용할 수 있는지에 대한 상세한 정보가 작성되어 있다.
(프로젝트 이름 / 프로젝트 핵심 기능 소개 / 팀원 소개)
- .gitignore
- gitignore dotfile은 git으로 관리하지 않는 파일 모음이다.
여기에는 개인이 따로 관리해야 하는 중요한 secret token이나, 다른 동료와 공유할 필요가 없는 설정 파일, 그 외 공유할 필요 없는 파일을 기록하면 git이 이를 파악하지 않고, push 할 때도 GitHub Repository에 push되지 않는다.
- LICENSE
-
해당 코드의 라이선스를 표기한다.
-
GitHub에 public하게 공개된 리포지토리도 라이선스에 따라서 사용을 할 수도 있고, 하지 못 할 수도 있으니 사용할 때 라이선스를 잘 보고 사용해야 한다.
-
회사에서 사용하는 코드는 private으로 관리하고, 외부에 공개하지 않아 라이선스 정보를 따로 표기하지 않기도 하지만 모종의 이유로 회사에서 작성하는 코드가 public으로 공개된다면, LICENSE를 명확하게 표기해야 한다.
💙프로젝트 관리에 활용할 수 있는 GitHub 기능
- Issue
- 말 그대로 프로젝트에 새로운 기능을 제안하거나, 버그를 찾아 제보하는 등 프로젝트의 이슈를 의미
- Milestone
-
GitHub Milestone은 이정표 역할을 하며, 태스크 카드(Issue)를 그룹화하는 데 사용한다.
-
GitHub Milestone에 연결된 태스크 카드(Issue)가 종료되면 GitHub Milestone마다 진행 상황이 업데이트되는 것을 볼 수 있다.
-
이 GitHub Milestone 기능을 통해 연관된 이슈의 추적과 진행 상황을 한눈에 파악할 수 있는 장점이 있다.
- Pull Request
-
내가 작업한 내용을 중요 Git branch에 합칠 수 있는지 확인하는 요청이다.
-
GitHub에서는 Pull Request에서 커밋한 코드를 따로 선택하여 해당 부분에 코멘트를 달 수 있다. (코드리뷰)
- Project
- GitHub 내에서 업무 관리를 해줄 수 있게 돕는 새로운 기능
🐋GitHub Project Kanban
💙칸반이란?
팀과 조직이 작업을 시각화하고, 업무의 병목 현상과 리소스 낭비를 해결하는 업무 관리 방법
💙칸반 보드를 통한 시각화
칸반의 대표적인 특징은 칸반 보드를 통한 업무 시각화!
칸반 보드는 아래 사진처럼 업무를 하나의 티켓으로 표현하고, 업무 단계를 하나의 열로 표현한다.
- 새로운 업무가 생기면 가장 왼쪽 열에 업무가 쌓이고, 업무가 잘 진행되면 가장 오른쪽으로 전달되어 쌓이는 방식으로, 어떤 업무가 현재 어느 업무 단계에 있는지 한눈에 파악할 수 있다.
이렇게 한눈에 업무를 파악할 수 있게 되면 각 팀원이 다른 팀원이 어떤 일을 하고 있는지 투명하게 확인할 수 있고, 문서 파일에 쌓여있는 업무 현황보다 훨씬 더 종합적이고 빠르게 업무 흐름을 파악할 수 있다.
💙Work In Progress(WIP)로 진행 중인 업무 제한 및 흐름 관리
WIP는 현재 진행하고 있는 작업을 의미한다.
칸반에서는 각 업무 단계에 WIP 제한(WIP limit)을 둘 수 있다.
WIP 제한이 2이면, 두 개 이상의 카드가 해당 열에 위치할 수 없게 된다. 아래의 예시의 경우 하나의 업무를 추가할 수 있는 것!
💙업무 흐름 관리
그렇다면, WIP를 두는 이유는 무엇일까?
➡ 업무가 과도하게 쌓이지 않는 원활한 업무 흐름을 위해!
모든 팀원이 100%의 리소스를 사용하고 있는 상태에서 계속 새로운 업무가 쌓이게 되면, 업무가 과부하되어서 업무 효율이 나지 않게된다.
막히는 고속도로에 계속해서 차가 진입하여 속도가 더 느려지는 현상에 비유할 수 있겠다. 즉, WIP 제한은 고속도로 진입로에서 종종 볼 수 있는 신호등과 같은 역할을 한다.
💙진행 중인 업무 제한
특히 개발 프로젝트는 타 업무와 달리 맥락 전환(context switching)이 없이 집중할 수 있어야 업무 효율이 증가한다.
개발 업무는 지식 업무에 해당하기 때문에 밤새 야근하거나 인원을 더 많이 투입한다고 해서 더 좋은 퀄리티의 산출물이 더 빠른 시간 안에 나오지는 않는다.
특히 소통이 많이 필요한 개발 프로젝트의 경우 인원수가 늘어난다고 해서 소요 기간이 드라마틱하게 증가하지도 않는다.
즉, WIP 제한은 한 번에 처리하는 업무의 양을 최소화하여 팀원이 한 번에 여러 업무를 동시에 진행해서 생기는 맥락 전환의 문제를 방지할 수 있고, 업무 흐름을 적당하게 유지시켜 업무가 차근차근 처리될 수 있도록 한다.
💙명확한 팀 정책 설정
칸반을 잘 활용하기 위해서는 명확한 정책을 설정해야 한다.
정책 수립 시에는 팀원이 모두 모여서 합의를 이뤄야 하고, 합의한 정책은 향후 업무 진행 상황에 따라서 팀원들이 모여서 언제든지 다시 조정할 수 있다.
프로젝트가 본격적으로 시작하기 전에 정하면 좋을 정책은 아래와 같다.
- 회의 시간 및 해당 회의에서 논의할 내용
- 팀원 간 소통 원칙
- 칸반 티켓을 언제, 어떻게, 누가 추가할지
- WIP 제한
💙회의와 리뷰를 통해 함께 업무를 개선
보통 칸반을 사용하는 경우, 데일리 칸반 회의와 주간 보충 회의를 진행한다.
-
데일리 칸반 회의
-
업무의 상태 및 흐름을 관찰하고 추적한다.
-
어떻게 하면 구현하고자 하는 기능을 좀 더 빠르게 구현할 수 있을지, 업무가 끝난 인원이 다른 업무를 당겨올 수 있는지 등을 정할 수 있다.
- Ex) 프론트엔드 개발자 A가 게시판 CRUD 사용자 인터페이스를 모두 다 구현해서 시간이 충분한 경우, 백로그에 있는 다른 프론트엔드 작업을 가져와서 하거나, WIP에 있는 다른 프론트엔드 개발자 B의 업무를 도와 집중하여 끝낼 수 있게 돕는다던지의 의사결정
-
-
주간 보충 회의
-
칸반 보드에 추가할 만한 업무가 있는지 확인하고, 다음 주에는 어떤 업무를 할 것인지 정한다.
- Ex) 프로젝트 진행 상황이 매우 원활하여, 추가로 구현하기로 했던 기능을 구현할 수 있게 된 경우에는 주간 보충 회의를 통해 해당 기능 구현 티켓을 칸반 보드에 추가할 수 있다.
-
추가로 격주, 혹은 월간으로 KPT 회고를 진행할 수도 있는데, 지금까지의 진행 상황에 대해서 솔직하게 회고하고, 어떻게 하면 좀 더 잘할 수 있을지 개선점을 찾을 수 있다.
💙칸반 실천법
지금까지의 설명이 아래의 칸반의 6가지 실천법 을 풀어서 설명한 것!
- 업무 시각화
- 진행 중인 업무 제한
- 흐름 관리
- 명확한 프로세스 정책
- 피드백 루프 구현
- 협력적인 개선, 실험적인 발전
💙칸반 원칙
칸반 실천법은 모두 칸반 원칙을 잘 지키기 위해서 만들어졌다.
즉, 해당 구성 요소를 기계적으로 충족시키려고 하기보다는, 종종은 칸반 원칙으로 되돌아와서 지금 하고 있는 작업이 칸반 원칙에 잘 맞는지 고민을 해봐야 한다.
-
하던 업무를 칸반 보드에 올려두는 것부터 시작
당장 할 일부터 칸반 보드에 올려두고 시각화하는 것부터 시작이다. -
점진적인 변화를 추구하도록 하자
칸반은 당장의 업무 내용이나 방향성을 갑자기 뒤엎고 화려하고 멋진 기획을 만들기 위한 수단이 아닌, 현재 하고 있던 일이나 업무를 잘 수행하기 위한 하나의 수단이다. 칸반을 위해서 갑작스럽게 업무 방식을 극적으로 변화시키지 말아야 한다. -
직위에 관계없이 리더십을 발휘할 수 있다.
칸반은 팀장만 관리하는 것은 아니다. 각 팀원도 칸반을 보고 WIP 제한을 늘리거나 줄이는 것을 제안할 수 있고, 새로운 업무 티켓을 발행하거나 기존 업무 티켓의 진행을 도울 수 있다.
Ex) FE와 BE사이의 API 설계나 요구사항 명세서를 적는 기획 단계에서는 서로 어떤 기능을 더 구현하고 덜 구현할지 충분히 제안하고 의견공유
🐳GitHub Issue
Use GitHub Issues to track ideas, feedback, tasks, or bugs for work on GitHub.
GitHub Issue를 아이디어 공유, 피드백, 태스크, 버그 관리로 사용하세요. - GitHub
제목과 본문을 작성했다면, 우측 탭을 이용해 세부 설정을 진행할 수 있다.
(※ 태스크 카드를 먼저 생성한 뒤, 세부 설정 작업을 진행할 수도 있다.)
-
Assigness: 해당 태스크를 맡은 사람을 지정해 줄 수 있다. assign yourself를 누르시면 자신의 태스크로 만들 수 있다. -
Labels: 태스크 카드에 라벨링을 할 수 있다. -
Projects: Projects를 지정할 수 있다. -
Milestone: 마일스톤을 지정할 수 있다.
💙GitHub Issue 템플릿 카드
이슈 반복 생성을 편하게 할 수 있는 이슈 템플릿 카드 기능이다.
레포의 settings에 들어가서 Issues의 Set up templates를 클릭해서 작성할 수 있다.
💙GitHub Milestone
You can use milestones to track progress on groups of issues or pull requests in a repository.
마일스톤을 이슈, PR 그룹의 진척도를 확인하는 데 사용하세요. - GitHub
말 그대로 이슈나 PR그룹을 만들어서 그 그룹 당 진척도를 가시적으로 확인할 수 있다.
