.gif&blockId=11b00c82-b138-8050-a58b-dcbceda2ef8f)
Git Project를 살펴보기 전 프로젝트에 실제로 적용한 Agile 개발 방법론에 대해 사전 지식을 훑고 가보자.
Agile
•
신속한 반복 작업을 통해 실제 작동 가능한 소프트웨어를 개발하여 지속적으로 제공하기 위한 소프트웨어 개발 방식
SCRUM
•
요구사항을 파악하고 빠르게 개발하는 방안
•
스프린트 반복 주기 1~4주
계획,개발,리뷰 작업 등 최소 단위의 Cycle
•
매일 10~15분 정도의 Scrum meeting 회의 진행
◦
(한일/할일/이슈에 대해 발표)
Scrum meeting : 어제 한일, 오늘 할일, 해결해야 할 장애/문제 요소를 공유하는 회의
•
팀을 우선으로 작업
◦
자신의 task보다 주변 이슈가 더 급하면 도와줘야 한다. 마치 배에 구멍이 나면 그 문제 해결이 1순위
•
주요 역할자
◦
제품 책임자(Product Owner)
▪
제품 백로그(요구사항) 관리/설명
▪
제품 백로그의 우선순위 관리
▪
만족스럽게 개발되었는지 확인
◦
스크럼 마스터(Scrum Master)
▪
팀을 보호하고 장애 요소를 해결
▪
일일 스크럼 회의를 진행
▪
모니터링 및 Tracking
◦
개발 팀(Developer)
▪
실제 개발 진행 팀
•
스프린트 단계(Cycle)
◦
스프린트 계획 회의(Sprint Planning Meeting)
▪
제품의 요구기능(User Story)과 우선순위를 백로그로 지정
◦
스프린트 백로그(Sprint Backlog)
▪
정한 우선순위를 바탕으로 기능 배분을 팀과 조율
▪
스프린트 백로그를 작성한 뒤 팀원에게 작업 할당
◦
일일 스크럼(Daily Scrum)
▪
어제 한일, 오늘 할일, 해결해야 할 장애/문제 요소를 공유하는 회의
◦
스프린트 리뷰(Sprint Review)
▪
매회의 스프린트가 종료할 때마다, 스프린트 리뷰(Review)를 통해 만들어진 제품을 검토하고 개선사항을 이해
◦
스프린트 회고(Sprint Retrospective)
▪
팀의 개발 문화(프로세스)에 대한 개선 방안에 대해 의논
칸반 보드(Kanban Board)
•
팀의 업무를 시각화한 프로젝트 관리의 한 형태
•
팀이 업무와 각 팀원이 할 수 있는 작업량 간에 밸런스를 맞추는 도구
•
보드에서 업무는 열로 구성된 프로젝트 보드에 표시되며, 각 열은 업무 단계를 나타낸다.
업무 분류 체계(WBS: Work Breakdown structure)
•
프로젝트를 완료하는 데 필요한 작업, 활동 및 결과물을 계층적으로 표현한 것
•
전체 업무를 분류하여 구성 요소로 만든 후 각 요소를 평가하고 일정 별로 계획하며그것을 완수할 수 있는 사람에게 할당해 주는 역할
•
WBS 구성요소
항목 | 설명 |
계정 코드(WBS ID) | WBS의 각 요소를 식별하기 위한 코드 |
주요업무 | 세부 업무를 묶는 그룹 |
세부업무 | 업무의 구체적인 내용 |
작업자 | 세부업무를 수행할 작업자 또는 파트를 작성 |
상태 | 업무 진행 사항을 작업중(In Progress), 완료(Completed), 확인(Milestone)으로 구분 |
시작일 | 업무의 시작일자 |
종료일 | 업무의 종료 일자 |
기간 | 업무의 시작과 종료 일지를 기준으로 작성 |
진척도 | 업무의 진척도를 %로 표기 |
일정차트 | 기간과 진척도를 반영하여 컬러로 표기 |
WBS사전 | WBS 각 요소 상세 정보 제공 문서 |
Github Projects
•
작업 정리, 프로젝트 계획, Workflow 자동화, 진행 상황 추적, 이슈 관리, 상태 공유, 마무리 등의 프로젝트 관리에서 관련한 유용한 기능을 제공하는 GitHub 협업툴
•
필자의 Organization Repository
시작하기
1.
Github Project 생성을 원하는 레포지토리에 접속후 Projects 탭 클릭
2.
Link a project 버튼 옆의 화살표 탭 클릭후, New Project 를 클릭, 버튼이 New Project로 변경되면 클릭
필자는 이미 프로젝트가 생성되어 있으므로 New Project로 뜬다.
아마 GitHub 업데이트가 될 때마다 해당 기능은 변동이 될 수 있을 것 같다.
3.
프로젝트에 맞는 템플릿을 고른다. 필자는 Kanban Board 템플릿을 사용
기본 사용법
View 설정
•
해당 View에서 내림 표시 버튼을 누르면 View 설정을 할 수 있다.
◦
레이아웃(Layout)
▪
View의 시각화 방식을 설정할 수 있다.
◦
구성(Configuration)
▪
Fields : 필드
▪
Column by :열의 기준이 되는 필드
▪
Group by : 선택한 필드 기준으로 그룹으로 묶기
▪
Sort by : 정렬 방식
▪
Slice by : 사이드바로 나타내 주는 미니 검색 창
Issue 관리
1.
Issue탭에서 관리
a.
Issue 생성
•
Assignees : 연관인 = 해당 기능 관리자
•
Labels : 특수 정보 표시
•
Projects : 연동 프로젝트
•
Development : 해당 기능을 작업중인 Branch
•
Title : 제목
•
Description : Task List 및 버그 리포트
b.
생성된 이슈에서 Project탭 수정
•
Priority : 우선 순위
•
Start Date, End Date : 시작~종료 날짜 (Roadmap에 반영)
2.
Project에서 관리
a.
Project에서 Board 하단에 Add Item클릭
b.
레포지토리 선택 및 issue 생성
i.
#을 치면 레포지토리 목록이 표시
ii.
레포지토리 선택 후 Create new Issue 클릭
iii.
이슈 생성
iv.
해당 이슈를 클릭한 후 Project 설정 및 Development에서 Branch연결
팀 프로젝트 기본 틀 제작
•
본 프로젝트는 프로젝트 협업이 처음인 팀원들이 많아 알기 쉽게 각 패널 및 열에 대한 설명을 한글로 작성해놨다.
•
테이블은 다음과 같다.
◦
칸반 보드(Kanban Board)
▪
칸반 보드 확인
◦
우선순위 보드(Priority Board)
▪
Backlog 우선순위 확인
◦
WBS(Roadmap)
▪
스프린트 세부 진행 일정
◦
리뷰(In Review)
▪
현재 리뷰 진행중인 이슈 확인
◦
팀 이슈(Team Issue)
▪
팀 전체 이슈 확인
◦
개인 이슈(my Issue)
▪
개인별 Assignees
칸반 보드(Kanban Board) 필드 구성
•
Backlog : 현재 해야하는 Feature 목록
•
Ready : 개발 준비가 완료된 Feature 목록
(Issue에서 개발에 관련된 Task List가 모두 Check로 되어 있는 기능)
•
In progress : 개발이 진행되고 있는 Feature 목록
•
In Review : Develop Branch에서 '기능' 테스트를 진행하고 있는 Feature 목록
•
Release : 배포 전 '전체' 테스트 단계에 들어간 기능 목록
•
Done : Main Branch에 올라간 기능 목록
우선 순위(Priority) 필드 구성
•
High : 높은 우선순위
•
Middle : 중간 우선순위
•
Low : 낮은 우선순위
Issue
•
Assigneers : 담당자
•
Label : 해당 이슈 상태
•
Projects : 소속 프로젝트
•
Milestone : 기간
•
Development : 참고 브랜치
Issue Templete
•
매번 Issue를 생성하여 폼에 맞춰서 글 작성을 하는 것도 번거롭고 중구난방으로 작성되는 것을 방지하기 위해 총 2개의 Issue 템플릿을 만들었다.
•
Templete 생성 방법
1.
해당 레포지토리의 Settings의 General 탭으로 들어간다.
2.
Features 카테고리의 Issues에서 Set up templates를 클릭한다.
3.
작성하고 싶은 초기 양식을 선택한다.
4.
템플릿을 작성한다.
5.
우측 상단에 Propose changes를 누르면 Commit 창이 나온다.
•
1번 : main branch로 즉시 commit & push
•
2번 : 새로운 branch를 생성하고 pull&request 시작
6.
완료되면 레포지토리에 .github/ISSUE_TEMPLATE에 해당 이슈 템플릿 md파일이 생성된다.
7.
이슈가 생성되면 이렇게 템플릿을 선택할 수 있다.
브랜치별 권한(룰) 설정: branch ruleset
사용 이유
•
다른 개발자(팀원)들과 협업을 하다보면 파일을 머지(합치기)를 하다가 문제가 생길 수 있다.
•
따라서 특정(master/main) 브랜치들은 일반 개발자분들이 푸쉬(또는 풀)를 할 수 없도록 규칙을 정할 수 있다.
•
규칙을 지정하는 방식으론 총 두 가지가 있는데 필자는 기존방식과는 다른 새로운 branch ruleset 방식을 사용하였다.
아무리 구글링을 해봐도 잘 안나오길래 정말 최근(2024.07.31 기준)에 나온 방식인 거 같다.
사용 방법
1.
해당 레포지토리의 Settings의 General 탭으로 들어간다.
2.
Add branch ruleset을 클릭한다.
Add classic branch protection rule은 예전 방식
3.
Ruleset설정
•
Ruleset Name : 룰 이름
•
Enforcement status : 해당 룰셋 사용 여부
•
Bypass List : 룰에서 제외되는 역할 지정
•
Targets : 타겟이 되는 브랜치(룰이 적용이 되는)
4.
Rules 지정
•
Bypass 권한이 있는 유저만 해당 타겟에 대한 Create, Update, Delete 가능
•
머지를 하기전에 Pull Request 발생
•
다른 개발자들의 approval이 있는 경우에만 머지 진행
•
개발자들이 푸쉬를 못하게 금지(수정 불가)
