Git 특강을 진행하셨던 최원영 강사님께서 다시 한번 수업을 해주셨습니다. 이번 강의는 프로젝트 관리와 관련된 여러 실무 지식들을 알려주셨습니다.
프로젝트 Life Cycle
Software Development Life Cycle (SDLC)
프로젝트 Life Cycle은 기획 단계에서 운영까지의 일련의 사이클을 뜻합니다.
일반적으로 개발 생명 주기와 배포 생명 주기로 나뉘는데, 개발자의 입장에서 개발 생명 주기 위주로 알아보도록 하겠습니다.
개발 생명 주기를 보통 소프트웨어 디벨롭먼트 라이프사이클(SDLC) 이라 칭하는데, 소프트웨어를 계획하고 개발, 시험, 배포하는 전 과정을 칭하는 개념입니다.
SDLC는 "요구 사항 분석 - 설계 - 구현 - 테스트 - 유지 및 보수"의 단계로 나뉩니다.
소프트웨어 개발 모델
소프트웨어 개발 모델에는 여러 형태가 존재합니다. 각각의 유형에 대한 이해를 위해 차례로 설명해보겠습니다.
-
build & fix
절차적으로 소프트웨어를 위한 코드를 작성하고, 개선할 부분이나 오류를 계속해서 고치는 방식입니다. 소프트웨어 개발 초기에는 대부분의 프로젝트가 이 모델 하에 이루어졌습니다. -
prototype
최소한의 요구 사항 분석 후 프로토타입을 제작해서 고객의 요구를 결과물에 적극적으로 반영하는 모델입니다. 고객 평가가 중요한 프로덕트에 적합한 모델입니다. -
waterfall
요구사항 분석 - 설계 - 구현 - 운용 순으로 진행하는 모델입니다. 대규모 프로젝트에 적합합니다. 폭포수라는 이름에 걸맞게 각 단계 완료 전에는 다음 단계 넘어가지 않는 구조입니다.
- spiral
"목표 설정 - 위험 분석 - 개발 및 검증 - 고객평가/다음 단계 수립"을 반복하는 모델입니다. 점진적으로 단계를 반복 수행해서 위험을 최소화하기 때문에, 은행이나 결제 시스템 등의 대형 시스템에 적합합니다.
Agile Model
Agile Model은 프로젝트의 생명주기동안 반복적인 개발을 촉진하는 개발 모델입니다.
코드 중심의 개발 방법론이머, 빠른 release가 필요한 프로덕트에 적합합니다.
XP(eXtreme Programming), Scrum 등 다양한 프레임워크가 존재합니다.
eXtreme Programming
eXtreme Programming은 고객 중심의 양질의 소프트웨어를 빠른 시간안에 전달하는 것이 목적입니다.
위의 이미지와 같이, 계획을 수립/수행한 뒤 이에 대한 피드백을 지속적으로 수행하는 형태입니다. 그러다 보니 요구사항의 변동이 잦을 경우 적합합니다.
기능 단위의 TDD 기반의 개발 모델이라 객체 지향 프로그래밍과 궁합이 좋은 방법론입니다.
XP 상의 프로젝트에서는 Pair Programming이 빈번하게 진행되다 보니 개발자 간의 실력 편차가 최소화되어야 합니다.
Scrum
XP가 일을 어떻게 할 지에 대한 방법론이라면 scrum은 일을 어떻게 정의할지에 대한 방법론입니다.
상호, 점진적 개발방법론에 속하는 방식이기 때문에, 참여 개발자들 사이에 일 단위의 짧은 미팅을 지속합니다.
또한 1~4주 간격의 sprint 단위로 프로젝트를 진행하게 됩니다.
일반적으로, 개발할 기능/수정사항에 대한 우선순위를 부여한 뒤, 이 순서대로 작업을 진행합니다.
Github 협업
github issue와 협업
지금까지 교육 과정에서는 github issue를 다소 소극적으로 사용해왔습니다. 주로 PR을 넣기 전에 본인의 PR에 대한 정보를 담고, PR을 생성하겠다는 것을 저장소 관리자에게 고지하는 의미로 사용해왔죠.
그러나 실제 현업에서 issue는 협업을 진행하는 데 있어서 매우 중요한 도구로 작용합니다.
아래 단락부터는 issue를 통해 프로젝트 계획/진행하는 과정에 대한 학습 내용을 기록할 것입니다.
issue 뜯어보기
issue 생성
github 저장소에 들어가보면 위 이미지와 같이 issue 페이지에 들어갈 수 있습니다.
issue에 들어가보면 new issue 버튼으로 새로운 issue를 생성할 수 있습니다.
보는 것과 같이 제목과 내용을 입력해 issue를 생성하면 되겠습니다.
내용란은 마크다운 문법으로 작성할 수 있기 때문에, 이미지 삽입이나 표, 체크 박스 생성 등이 모두 가능합니다.
또 Preview 레이어를 선택해 내가 작성한 issue의 출력물을 미리 확인할 수도 있습니다.
label
위의 issue 생성 이미지의 오른쪽 부분을 살펴보면, 다양한 항목들이 있는 것을 확인할 수 있습니다.
그 중 label은 말 그대로 issue의 성격이나 목적을 드러내기 위해 사용하는 꼬리표라고 할 수 있습니다.
label 칸의 설정 아이콘을 눌러 여러 label 중 적합한 것을 고를 수 있고, 맨 아래 edit label을 클릭해 label을 커스터마이징 할 수도 있습니다.
오른쪽 위의 new label 버튼으로 새로운 label을 생성할 수 있습니다.
사전에 설정된 label 만으로 issue의 내용을 잘 드러낼 수 없다면 새로운 label을 만드는 것이 현명합니다.
milestone
label 옆 레이어에는 milestone을 설정하는 기능도 마련되어 있습니다.
milestone은 issue와 관련해 일정 관리를 수월하게 해줍니다. 새로운 milestone을 만드는 버튼을 클릭해보겠습니다.
다음과 같이 milestone의 제목과, due date를 설정할 수 있습니다. 아래에 설명을 간략하게 적을 수 있는 칸도 있는 것을 확인할 수 있습니다.
이 milestone은 서로 다른 작업들 사이에서 due date를 다르게 설정하기 위해 사용됩니다.
github projects
github project는 말 그대로 github 상에서 프로젝트 관리를 위해 제공하는 기능입니다.
새로운 프로젝트를 만들고, 생성할 issue들을 적합한 project에 할당하는 방식으로 이루어집니다.
project는 일정 관리와 관련된 데스크톱 앱처럼 프로젝트 관리에 특화된 인터페이스와 기능을 제공하기 때문에 매우 유용합니다.
project 만들기
저장소 화면에서 project 레이어에 들어가면 새로운 프로젝트를 만들 수 있습니다.
이미지에서 볼 수 있듯이, 프로젝트 이름과 설명을 입력할 수 있습니다.
또한 하단에 보이는 것과 같이 프로젝트의 템플릿을 미리 정할 수 있습니다. 일반적으로 일정 관리를 하기 용이하도록 kanban 형태의 템플릿을 주로 사용합니다.
이번 포스팅에서도 kanban 형식의 프로젝트를 만들어 설명을 이어나갈 것입니다.
project 사용법
위 이미지는 실제 저장소에서 제가 속한 팀의 issue들을 project에 적용한 이미지입니다.
만약 project 생성 시 automation이 적용된 kanban 템플릿을 적용하면, 이미지에 보이는 것과 같이 milestone의 due date에 따라 진행중인 issue, 앞으로 예정된 issue를 알아서 분류해줍니다.
노션이나 여타 일정 관리 앱에서 사용하듯이, kanban 형식이라서 project 관리와 분석이 쉽습니다.
당연하게도, issue들이 project 페이지에 적용하기 위해서는 각각의 issue 페이지에서 해당 project를 할당해 주어야 합니다.
Github Wiki
wiki라는 명칭에서 어느 정도 파악할 수 있듯이, github wiki는 협업 간에 산출되는 기록물들을 아카이빙할 수 있는 기능입니다.
wiki에는 트러블 슈팅이나 기능 개발에 대한 기록물을 남길 수도 있고, 프로젝트 컨벤션에 대한 정의를 따로 모을 수도 있습니다.
말그대로 기록을 남길 수 있는 기능이므로, 팀의 상황에 따라 취사 선택하여 프로젝트 관련 기록물을 남길 수 있습니다.
오늘쪽에 페이지가 있는 것을 볼 수 있는데, 필요에 따라 페이지를 만들어서 마치 논문이나 도서처럼 기록물들을 분류한 목차를 생성할 수 도 있습니다.
