Overview
개발 프로젝트 제작을 위해 Github를 다루는 방법에 대해서 소개
Chapter1-1. Github 리포지토리
- 개념학습: 프로젝트 Github 리포지토리에 꼭 필요한 요소에 대해서 학습
- 튜토리얼: 프로젝트 Github 리포지토리를 함께 만들어보기
Chapter1-2. Github Project 칸반
- 개념학습: 칸반이 무엇인지 학습
- 퀴즈: 학습한 개념의 이해도를 확인
- 튜토리얼1: Github 이슈, 마일스톤 기능을 활용하여 프로젝트 할 일을 나눠보고 기한을 설정
- 튜토리얼2: Github Project 기능을 활용하여 칸반 뷰로 업무를 시각화
학습목표
- 개발 프로젝트 Github 리포지토리에 꼭 필요한 요소를 이해한다.
- 칸반이 무엇인지 이해한다.
- 칸반 원칙과 실천 방안에 대해서 이해한다.
- Github Project, 이슈, 마일스톤 기능을 이용하여 칸반 보드를 제작할 수 있다.
- 칸반 보드로 업무 시각화를 할 수 있다.
1. 프로젝트 Github
1.1. Github 리포지토리
개념학습
지금까지는 Github 리포지토리를 코드를 공유하고 과제를 클론 받는 단순한 원격 코드 저장소로써 사용해왔습니다. 이번 Pre-Project부터는 Github 리포지토리를 하나의 완성된 개발 프로젝트에 대한 코드와 주요 정보를 공유하는 수단으로 사용하는 방법에 대해서 안내합니다.
Github 리포지토리에 꼭 필요한 파일
README.md
Github는 개발자의 SNS라고 불릴 정도로 다양한 종류의 오픈소스 프로젝트가 공유되어 있습니다. 오픈소스 프로젝트에 들어가면, 가장 먼저 확인할 수 있는 정보가 바로 이 README.md 파일입니다. 기본적인 마크다운 사용법을 잘 숙지하고 있으면 간단한 소개 페이지처럼 제작할 수 있습니다. README.md 파일을 적는 양식은 따로 존재하지 않지만, 대체로 어떻게 하면 해당 오픈소스를 활용할 수 있는지에 대한 상세한 정보가 작성되어 있습니다.
Pre-Project Github 리포지토리 README.md 파일은 아래 정보를 꼭 포함해야 합니다.
- 프로젝트 이름
- 프로젝트 핵심 기능 소개
- 팀원 소개
.gitignore
gitignore dotfile은 git으로 관리하지 않는 파일 모음입니다. 여기에는 개인이 따로 관리해야 하는 중요한 secret token이나, 다른 동료와 공유할 필요가 없는 설정 파일, 그 외 공유할 필요 없는 파일을 기록하면 git이 이를 파악하지 않고, push 할 때도 github 리포지토리에 push되지 않습니다.
LICENSE
해당 코드의 라이센스를 표기합니다. 깃허브에 public하게 공개된 리포지토리도 라이센스에 따라서 사용을 할 수도 있고, 하지 못 할 수도 있으니 사용할 때 라이센스를 잘 보고 사용해야 합니다. 회사에서 사용하는 코드는 private으로 관리하고, 외부에 공개하지 않아 라이센스 정보를 따로 표기하지 않기도 합니다. 하지만 모종의 이유로 회사에서 작성하는 코드가 public으로 공개된다면, LICENSE를 명확하게 표기해야 합니다.
프로젝트 관리에 활용할 수 있는 Github 기능
Issue
Issue는 말 그대로 프로젝트에 새로운 기능을 제안하거나, 버그를 찾아 제보하는 등 프로젝트의 이슈를 의미합니다.
Pre-Project에서는 Issue를 하나의 칸반 티켓처럼 사용합니다.
Milestone
Milestone은 이정표 역할을 하며, 태스크 카드(Issue)를 그룹화하는 데 사용합니다. Milestone에 연결된 태스크 카드(Issue)가 종료되면 Milestone마다 진행 상황이 업데이트되는 것을 볼 수 있습니다. 이 Milestone 기능을 통해 연관된 이슈의 추적과 진행 상황을 한눈에 파악할 수 있는 장점이 있습니다.
Pre-Project에서는 Bare Minimum, Advanced Challenge, Nightmare를 표시하기 위해 사용합니다.
Pull Request
Pull Request는 내가 작업한 내용을 중요 git branch에 합칠 수 있는지 확인하는 요청입니다. Github에서는 Pull Request에서 커밋한 코드를 따로 선택하여 해당 부분에 코멘트를 달 수 있습니다. 현장에서도 Pull Request를 보면서 코멘트를 남기면서 코드 리뷰를 진행하기 때문에 Pull Request 과정에 익숙해지는 것이 중요합니다.
Project
Project는 Github 내에서 업무 관리를 해줄 수 있게 돕는 새로운 기능입니다.
Pre-Project에서는 이 Project 기능을 이용하여 칸반 보드를 생성하고, 칸반으로 Pre-Project의 업무 흐름을 관리합니다.
1.2. Github Project 칸반
개념학습
팀 개발 프로젝트는 여러 인원이 함께 업무를 처리합니다. 취미로 만드는 사이드 프로젝트는 혼자 기획하고 개발해도 문제가 없으나, 타겟 사용자가 있고 해당 사용자가 돈을 지불할 만한 상용 웹 애플리케이션을 만들려면 많은 사람이 함께 모여서 일해야 합니다. 이렇게 여러 직군이 모여서 함께 개발을 하다 보니 자연스럽게 협업 방식이나 업무 관리 방식에 대한 많은 논의가 생겨났습니다. 칸반도 이런 논의 중 생겨난 하나의 업무 관리 방식 중 하나입니다.
칸반이란?
칸반은 팀과 조직이 작업을 시각화하고, 업무의 병목 현상과 리소스 낭비를 해결하는 업무 관리 방법입니다.
칸반 보드를 통한 시각화
칸반의 대표적인 특징은 칸반 보드를 통한 업무 시각화입니다. 칸반 보드는 아래 사진처럼 업무를 하나의 티켓으로 표현하고, 업무 단계를 하나의 열로 표현합니다. 새로운 업무가 생기면 가장 왼쪽 열에 업무가 쌓이고, 업무가 잘 진행되면 가장 오른쪽으로 전달되어 쌓이는 방식입니다. 어떤 업무가 현재 어느 업무 단계에 있는지 한눈에 파악할 수 있습니다.
이렇게 한눈에 업무를 파악할 수 있게 되면 각 팀원이 다른 팀원이 어떤 일을 하고 있는지 투명하게 확인할 수 있고, 문서 파일에 쌓여있는 업무 현황보다 훨씬 더 종합적이고 빠르게 업무 흐름을 파악할 수 있습니다.
Work In Progress(WIP)로 진행중인 업무 제한 및 흐름 관리
WIP는 현재 진행하고 있는 작업을 의미합니다. 칸반에서는 각 업무 단계에 WIP 제한(WIP limit)을 둘 수 있습니다. WIP 제한이 2이면, 두 개 이상의 카드가 해당 열에 위치할 수 없게 됩니다. 아래 예시의 경우 하나의 업무를 추가할 수 있습니다.
업무 흐름 관리
WIP를 두는 이유는 무엇일까요? 업무가 과도하게 쌓이지 않는 원활한 업무 흐름을 위해서입니다. 모든 팀원이 100%의 리소스를 사용하고 있는 상태에서 계속 새로운 업무가 쌓이게 되면, 업무가 과부하되어서 업무 효율이 나지 않게 됩니다. 막히는 고속도로에 계속해서 차가 진입하여 속도가 더 느려지는 현상에 비유할 수 있습니다. 즉, WIP 제한은 고속도로 진입로에서 종종 볼 수 있는 신호등과 같은 역할을 합니다.
진행중인 업무 제한
특히 개발 프로젝트는 타 업무와 달리 맥락 전환(context switching)이 없이 집중할 수 있어야 업무 효율이 증가합니다. 제조업 업무는 어떻게 해서든 기계 가동률을 높이거나 일부 생산을 아웃소싱하면 더 짧은 기간 내에 산출물을 만들 수도 있습니다. 하지만 개발 업무는 지식 업무에 해당하기 때문에 밤새 야근하거나 인원을 더 많이 투입한다고 해서 더 좋은 퀄리티의 산출물이 더 빠른 시간 안에 나오지는 않습니다. 특히 소통이 많이 필요한 개발 프로젝트의 경우 인원수가 늘어난다고 해서 소요 기간이 드라마틱하게 증가하지는 않습니다.
Comments powered by Disqus.