-
Notifications
You must be signed in to change notification settings - Fork 0
GitHub Projects 도입
여러 사람이 함께 개발하면 소스 코드뿐 아니라 누가 어떤 작업을 맡았는지, 현재 어디까지 진행됐는지, 무엇을 완료해야 작업이 끝나는지도 공유해야 합니다.
작업 내용을 말이나 메신저로만 전달하면 시간이 지난 뒤 내용을 다시 찾기 어렵고, 작업이 누락되거나 중복될 수 있습니다. 따라서 해야 할 일을 Issue로 기록하고 진행 상태를 한곳에서 확인할 수 있는 프로젝트 관리 도구를 사용합니다.
프로젝트 관리 도구는 개발 환경과 조직에 따라 다양하게 사용되어 왔습니다.
| 도구 | 간단한 특징 |
|---|---|
| Trac | Issue와 Wiki를 함께 제공하며, 소스 관리 도구와 연동해 사용하던 비교적 초기의 프로젝트 관리 도구입니다. |
| Redmine | 프로젝트별 Issue, 일정, Wiki 등을 제공하며 여러 개발 조직에서 협업 도구로 사용되어 왔습니다. |
| Jira | 세밀한 작업 흐름과 다양한 관리 기능을 제공해 현재도 많은 조직에서 사용하지만, 작은 팀이 처음 도입하기에는 설정과 관리가 다소 무거울 수 있습니다. |
| GitHub Projects | GitHub의 Issue 및 Pull Request와 직접 연결하여 작업 상태를 표, 보드, 로드맵 형태로 관리할 수 있습니다. |
각 도구에는 장단점이 있으며 특정 도구가 항상 정답인 것은 아닙니다. 중요한 것은 현재 팀의 규모와 작업 방식에 맞는 도구를 선택하고, 팀원이 실제로 계속 사용할 수 있도록 하는 것입니다.
우리 팀은 소스 코드를 GitHub에서 관리하므로 프로젝트 관리에도 GitHub Projects를 사용합니다.
- 소스 저장소와 작업 관리 공간을 따로 오갈 필요가 없습니다.
- Issue, 브랜치, Commit, Pull Request를 서로 연결하기 쉽습니다.
- 팀원이 저장소에서 바로 Issue와 프로젝트에 접근할 수 있습니다.
-
Todo,In Progress,Done과 같은 진행 상태를 보드에서 확인할 수 있습니다. - 처음에는 단순하게 시작하고 필요해질 때 필드와 화면을 추가할 수 있습니다.
Jira처럼 복잡한 관리 체계를 처음부터 만들기보다는, 현재 팀에 필요한 최소한의 기능부터 사용합니다.
개인 프로젝트인 YMS SaaS에서 GitHub Projects를 먼저 사용하며 작업 관리 방식을 시험하고 있습니다.
- GitHub Projects: 프로젝트 링크
이 화면을 통해 해야 할 작업, 현재 진행 중인 작업, 완료된 작업을 한눈에 확인할 수 있습니다.
개발 작업은 GitHub Projects의 칸반 보드에서 바로 Issue로 작성합니다. 설명은 생략하나, 저장소의 Issues 탭에서 생성할 수도 있습니다.
- GitHub 저장소의
Projects탭에서 우리 팀의 프로젝트를 엽니다. - 칸반 보드의
Todo열 아래에 있는+버튼을 선택합니다. -
Create new issue를 선택합니다. - Issue를 생성할 저장소를 선택합니다.
- 작업 제목을 입력합니다.
- 담당자(
Assignees), 라벨(Labels)과 작업 내용을 작성합니다. -
Create를 눌러 등록합니다.
Todo 열에서 만든 Issue는 프로젝트에 바로 추가되고 상태도 Todo로 지정됩니다.
보드 아래의 입력 칸에 제목만 입력하면 저장소에 속하지 않은 Draft issue가 만들어질 수 있습니다. 실제 개발 작업은
+→Create new issue를 선택하여 정식 Issue로 작성합니다.
Issue 제목은 목록에서 작업 내용을 알아볼 수 있도록 간결하고 명확하게 작성합니다.
좋은 예: 사용자 목록 화면에 Copy 버튼 추가
나쁜 예: 화면 수정
Issue 본문은 다음 형식을 기본으로 사용합니다.
## 작업 내용
구현하거나 수정할 내용을 작성합니다.
## 완료 조건
- [ ] 완료 여부를 판단할 수 있는 조건을 작성합니다.
- [ ] 필요한 테스트 조건을 작성합니다.
## 참고
관련 화면, 문서, 소스 경로 등을 작성합니다.
## 예상 작업 시간
예상 시간을 작성합니다.다른 팀원의 코드와 연결되는 작업이라면 관련 클래스명, 요청 경로, 입력값과 출력값처럼 사전에 합의가 필요한 내용도 Issue에 적습니다.
보드에서 Issue를 만든 뒤에는 작업 상황에 맞게 상태를 변경합니다.
| 상태 | 의미 |
|---|---|
Todo |
아직 시작하지 않은 작업 |
In Progress |
담당자가 확인하고 진행 중인 작업 |
Done |
리뷰와 Merge까지 끝난 작업 |
기본적인 관리 원칙은 다음과 같습니다.
- 개발을 시작하기 전에 담당자와 요구사항을 확인합니다.
- 작업을 시작하면 상태를
In Progress로 변경합니다. - 요구사항이 바뀌거나 작업이 막히면 Issue에 코멘트를 남깁니다.
- Pull Request를 작성할 때 관련 Issue를 연결합니다.
- Merge가 끝나면 작업 결과와 실제 작업 시간을 기록하고 Issue를 종료합니다.
- 프로젝트 상태가
Done으로 변경됐는지 확인합니다.
아이디어를 임시로 적어둘 수는 있지만, 실제 개발을 시작하기 전에는 정식 Issue로 만들어 담당자와 완료 조건을 분명히 합니다.
Issue 작성과 담당자 배정이 끝났다면 실제 개발을 시작합니다.
브랜치 생성부터 테스트, Commit, Pull Request, 소스 리뷰와 Merge까지의 자세한 과정은 작업 순서 문서를 참고합니다.