후속 개발 프로젝트 회고

이번 후속 개발 프로젝트는 여러 툴들을 사용해보고 실제 프로젝트 현업에서 사용하고 있는 여러 툴들을 공부하고, 배워가면서 프로젝트를 진행했기에, 생소하거나 몰랐던 툴들을 많이 알게 된 프로젝트 였으며, 지금까진 해왔던 다른 프로젝트들과 달리 게임상의 로직 설계가 필요한 프로젝트였다. 로직을 직접 생각하여 개발한 프로젝트는 처음이였기에, 진행하면서 피드백들을 받고 많이 배웠으며, 느낀 점들이 더욱 많았다.

 

따라서 프로젝트 진행 흐름을 따라가면서 정리하고자 한다.

---

[ Agile process selection ]

 

Agile process 란 ?

 

  - 개발에 대한 개념적 방법론으로, 개발 프로젝트 기간을 짧은 주기로 나눠 반복적인 개발을 하는 것이 특징이다.

 

우리는 애자일 프로세스는 Scrum 방식에 kanban 보드를 도입하였다. 

스크럼은 짧은 개발 주기를 통해 제품을 생산하고 주기적인 제품 데모와 피드백 수용이 가능한 개발 방식이다.

여기에 Kanban board를 더해 애자일 프로세스를 구성했다.

 

스프린트와 칸반 보드

 

Kanban보드는 모든 프로세스를 다 함께 공유하여, 업무의 가시성을 확보하고 투명한 업무처리로 프로젝트 지연을 예방할 수 있다는 장점이 있고, 또한 각 개인이 권한을 부여받았다고 느끼게 만들어 자발적으로 참여하고 협업

하면서 프로젝트의 완성에 기여하고 있다는 생각을 불러일으키는 장점이 있기에 kanban 보드를 도입하였다

 

 

 

스크럼 전략의 세팅은 스크럼 팀의 경우 6명을 기준으로 하고 스크럼 마스터는 2명으로 설정했다. 프로덕트 오너의 경우 팀원 전체가 다 같이product backlog를 정리하고 우선순위를 결정하였고, 스프린트 기간은 2주로 설정하였다

---

[ Construct a WBS( Work BreakDown Structure ) ]

WBS(Work Breakdown Structure)란 ?

 

- 주로 프로젝트 관리에서 사용되는 도구이다. 프로젝트를 계층적이고 구조화된 작업 단위로 분해함으로써 프로젝트 관리자 및 팀이 프로젝트의 범위를 더 잘 이해하고 효과적으로 관리할 수 있도록 한다.

진행한 WBS 목록

 

우리는 프로젝트 진행 방법을 검증하기 위해 Space Invader 라는 게임에 로컬 멀티플레이어 기능과 쉽 커스터마이제이션 기능 두가지를 구현하는 것을 목표로 하였다.

---

[ Determine and implement time  -  estimation techniques ]

개발 목표와 해야 할 일을 설정했고, 그 다음으로는  각 해야 할 일에 대해 예상 시간을 추정 했다. 예상 시간을 결정하는데는 플래닝 포커라는 게임을 하여 결정하였다

 

 

 

플래닝 포커 ?

 

플래닝 포커 카드 각각에는 피보나치 수열의 숫자가 적혀 있는데 이는 작업의 복잡도나 걸리는 시간을  의미한다.

게임을 플레이하면 각자 선정한 작업에 대해 얼마정도 걸릴지 예상한 시간을 바탕으로 카드를 뽑고, 카드를 공개한다.

 숫자가 가장 높은 사람과 숫자가 가장 낮은 사람은 숫자를 선택한 이유에 대해 설명하고 다시 한번 더 플래닝 커를 진행하고 나온 숫자의 평균값을 선정한 작업에 걸리는 시간으로 설정하였다.

 

---

[ Operate in Jira ]

 

또한 지라와 깃을 연동하여 커밋과 PR을 통해서 지라에 이슈를 관리할 수 있는 오토메이션 기능을 사용 하였다.

---

[ Version Control System   & Project Management Tool ] 

깃 전략

Git 전략은 개발 프로세스를 체계화하고팀의 작업 효율성을 높이고 프로젝트의 품질 관리를 강화하는 데 중요한 역할을 하고 브랜치의 명확한 역할 분담은 프로젝트의 진행 상황을 이해하고 관리하는 데 도움이 된다.

 

 Git Strategy Overview

 

우리가 활용한 git 전략은 Main, Dev, Feature Branch를 기반으로 한 전략으로, Gitflow에서 Release Branch를 비활성화한 형태로, 테스트 목적의 개발에 특화되어 있다.

---

 

Core Structure of Git Strategy

 

 

이 전략에서는 Main, Dev, Feature Branch 세 가지 주요 브랜치를 활용한다. Main 브랜치는 안정화된 최종 제품을 나타내며, Dev 브랜치는 개발 중인 기능들의 집합이고, 새로운 기능은 Feature Branch에서 개발된다.

---

Release Branch의 비활성화

 

정식적인 Release가 아닌 테스트 목적으로 개발하는 경우, 기본적인 버그 수정과 같은 작업은 Dev 브랜치에서 진행 한다 그렇기에 release Branch는 필요하지 않다고 판단하였고, 비활성화했다.

---

 

Release Branch의 잠재적 활용과 HotFix 와 Fix Branch의 역할

 

실제 제품을 출시함으로 필요에 따라 Release Branch를 활성화하여 정식 배포 전의 다음 버전을 준비하는 작업을 수행할수 있게 하였고, 추가적으로, Main 브랜치에서 발생하는 긴급 수정은 HotFix 브랜치를 통해서, Dev 브랜치에서 발생하는 일반적인 버그 수정은 Fix Branch를 통해서 수정하였다. 이러한 분리된 접근은 브랜치 관리를 명확하게 했다.

---

[GitHub – Jira Integration]

 

 

 

Jira는 효과적인 프로젝트 관리와 이슈 추적을 위한 도구로, 복잡한 프로젝트를 관리하고 조직화하는 데 사용되고, 내부에 Agile 프로세스를 바탕으로 여러 툴이 존재하며, 프로젝트를 시각화하며 자동화시키는 기능이 있다. GitHub은 코드 저장, 버전 관리, 그리고 협업을 위한 플랫폼이다.

 

우리는 Jira Software와 Github 2개의 도구를 함께 사용함으로써, 우리는 프로젝트 관리와 코드 관리를 통합 했다.

 

 

Jira와 GitHub을 연동함으로써, 코드 변경 사항과 프로젝트 진행 상황을 실시간으로 추적할 수 있었고, 이를 통해서 개발 프로세스의 투명성을 높이고, 팀원 간의 협업을 강화할 수 있었다. 또한, 이슈 해결 및 버전 관리가 용이해져 프로젝트의 전반적인 생산성을 향상시키는것이 가능했다.

---

 

 

Jira와 GitHub연동 설정

 

Jira에서 GitHub 앱을 설치하고, GitHub 저장소를 Jira 프로젝트에 연결하고, 적절한 접근 권한을 설정한다.

이 과정을 통해 두 플랫폼 간의 데이터 동기화가 이루어지고, 이 연동을 통해, GitHub에서의 커밋과 풀 리퀘스트를 Jira 이슈와 연결할 수 있다.

 

자동화를 덕분에 코드 변경사항이 자동으로 Jira 이슈에 기록되어, 팀원들의 프로젝트 진행 상황의 최신 상태를 쉽게 파악할 수 있었다.

 

Jira를 활용하여, Epic 크기의 작업 단위를 나누어 2개의 Sprints로 분리, 선정하여서 한 Sprint 내에는 2개의 Stories를 담았으며, 그 하위 Issues로 여러 Tasks가 위치하는 형태로 Sprint를 생성했다.

 

,

 Jira 내 해당 Issue에서 Branch 형성을 하여 SAC-Issue No.-Story No.-Task No.-Task Name으로 운용하였고. 또한, 커밋 메시지에 Jira 이슈 번호를 포함시킴으로, Jira에서 해당 커밋을 특정 이슈랑 연관시켰다.

이러한 설정을 바탕으로 Jira에서 Automation을 통해, “브랜치를 만들면, 이슈를 진행 중으로 이동하였고 풀리퀘를 병합하면, 이슈를 완료로 이동 등의 규칙을 적용하여, 커밋이 이루어지면, 관련 Jira이슈가 자동으로 업데이트되어,.프로젝트 관리자와 팀원 모두가 실시간으로 진행 상황을 확인할 수 있었다.

---

 

정리하자면, 이 연동을 통해 우리는 프로젝트 관리의 효율성을 크게 향상시킬 수 있었다. GitHub에서의 커밋과 풀 리퀘스트가 Jira 이슈와 실시간으로 연결되어, 개발자와 프로젝트 관리자 모두가 프로젝트의 진행 상태를 더욱 명확하고 신속하게 파악할 수 있게 되었다. 

---

[Code Review] 

code review는, 품질 향상에 도움을 주는 과정으로, GitHub와 Jira를 사용하면서 필연적으로 거쳐야 하는 과정이다.

 

 

우리는 코드 리뷰 요청 과정에서 리뷰어에게 기능 설명, 현재 PR의 변경점 등을 자세히 전달하도록 하였고,어떤 내용들을 테스트했는지 들어가야 하도록 정했고, 필요한 부분은 pdf 로 구체적인 설명을 제공하도록 하였다.

 

 

 

또한 D - N 규칙도 정하였는데 d- n 규칙은 개발자가 코드 리뷰 요청 시, 해당 코드 리뷰가 얼마나 긴급한지를 명시적으로 표현하는 데 사용된다. 

 

 

 

'D-n'의 'D'는 'Day'를 의미하며, 'n'은 숫자를 나타낸다. 이는 리뷰어가 리뷰를 완료해야 하는 기한을 'n'일 내로 정하는 것이다. 예를 들어, D-0은 가장 긴급한 리뷰를 의미하며, 즉시 리뷰가 필요함을 나타낸다. 이는 앱의 오류나 장애와 같은 긴급한 수정이 필요한 경우에 사용한다.

---

코드 리뷰 요청에는 p-n 룰을 사용하여 리뷰어가 자신의 코멘트를 얼마나 강조하고 싶은지를 명확하게 표현할 수 있도록 하였다.

 

Pn 룰은 다음과 같다. 

 

P1 (Request changes): 리뷰어는 이 태그를 사용하여, PR의 내용에 중대한 오류나 중요한 수정이 필요함을 나타낸다. 리뷰 요청자는 이에 대해 반드시 조치를 취해야 한다.

P2 (Request changes): 이는 중요하지만 P1만큼 긴급하지 않은 사항에 사용하고, 리뷰 요청자는 이에 대한 적극적인 고려를 해야 한다.

P3 (Comment): 이는 리뷰어의 권장 사항을 나타내며, 리뷰 요청자는 이를 고려하여 수용하거나 논리적인 이유를 들어 반영하지 않을 수 있다.

P4 (Approve): 이는 리뷰어가 제안하는 사항이지만, 반영 여부는 리뷰 요청자의 재량에 달려 있다.

P5 (Approve): 이는 단순한 의견이며, 리뷰 요청자는 이를 무시해도 무방하다.

---

[Testing with Junit ] 

 

 

 

우리는 유닛 테스트로 테스트를 진행하였다.

유닛 테스트란 개별 코드 단위가 예상대로 동작하는지 확인하고, 소스코드의 기능이 의도된 대로 정확히 작동 하는지 검증하는 절차이다. 유닛 테스트는 단일 함수 또는 모듈을 대상으로 진행 하기 때문에 실행 속도가 빠르고, 특정 기능에 집중하여 테스트 하기에 용이하다. 그렇기 때문에 유닛테스트로 테스트를 진행하였다,

 

 

또한 Given-When-Then이라는 테스트 설계 패턴을 사용하여 테스트를 진행 하데, Given 는 테스트 케이스의 시작 상태를 설명하는 부분으로 시작 조건을 나타내고, When 는 시스템의 동작 발생을 나타내는 부분으로 특정한 행동, 이벤트 메소드 호출 등을 다룬다. Then은 특정한 행동이나 이벤트가 발생한 후의 시스템 상태나 결과를 설명한다.

 

Given-When-Then은 자연어에 가까운 구조를 사용하므로 코드를 보는 사람이 테스트 시작 상태, 동작, 결과를 명확하게 이해할 수 있기에 선택하였다.

 

Junit 으로 작성한 커스터 마이징 테스트 코드는 아래에 링크에 있다.

 

https://whgmsla.tistory.com/163

커스터 마이징 테스트 코드 구현(Junit, UnitTest )

---

[ Quality management  (with Class Diagram)

Quality management ?

품질 관리(Quality Management)는 제품 또는 서비스의 특정 기준이나 요구 사항을 충족시키기 위한 계획, 조정, 보증 및 향상의 과정을 포함하는 것

 

 

우리는 Class Diagram을 사용하여 관리하였다. 우리팀만 개발에 참여한 것이 아닌 다른 팀과 협업하여 개발하였기에 SpaceInvader 어떤 구조로 개발되었는지 파악하는데 도움이 되고, Class Diagram은 객체지향 시스템 모델링에서 가장 많이 쓰이는 다이어그램이며, 바로 프로그램 코드로 변환하기 용이하다는 장점이 있어 품질관리를 Class Diagram을 선택하여 사용하였다.

---

느낀점

이번 프로젝트에서 정말 많을 걸 배우고 느꼈다. 가장 먼저 생각나는 점은 체계적인 협업을 하는 방식을 배운 것 같다. Git 사용 전략, 애자일 프로세스, 지라 사용, JunitTest , 플래닝 포커 등 프로젝트를 진행을 도와주는 여러 툴들과 규칙들을 만들고 지키도록 프로젝트를 진행하니까, 프로젝트의 진행과정을 쉽게 볼수 있어서 도움이 많이 되었다.

그러나 프로젝트 진행하면서, 모르고 있었던 생소하고 처음 보는 개념들과 처음 사용해보는 여러 툴아 많았기에 적용시키는 과정에서 어려움이 있었다. -애자일 프로세스의 개념과 ,시간 추정기법, junit test  , 지라 티켓 사용하여 github 랑 연동 모르는 것 투성이 였다. 

 

또한 실제로 개발을 진행할때 아쉬움이 많이 남았는데 , 우선 코드를 해석하는 능력이 부족하여 개발을 진행할 때, 다른 팀원들이 만든 코드를 보고 이해하는 과정에서 어려움이 있었다. 그리고 코드를 효율적으로 개발하지 못하였다.

지금까지는 복잡한 로직이 필요없는 단수한 기능 개발만 해왔기에, 이번 게임 프로젝트 처럼 시작 단계에서 로직을 잘 설계하고, 효율적으로 진행하는 방법을 알지 못하였기에 그냥 구현을 목적으로 하고 코드의 효율성을 따지지 못하고 어떻게든 구현하려고 애썻고, 코드의 모듈화등 이런 개념을 몰랐기에, 코드를 비효율적을 개발한 것을 느꼇다.

그렇기에 코드 설계와 모듈화의 중요성을 배우게 되었다.  

 

이번에 코드리뷰를 통한 피드백에서 많이 배웠는데 이번에 나는 스크린에 그림->2차원 배열로 변환 -> 저장, 2차원배열을 스크린에 그리는 방식으로 개발했다. 팀원들의 피드백은>2차원 배열을 생성 후 사용자의 입력에 따라 2차원 배열을 업데이트하고 UI의 스킨은 오로지 2차원 배열을 참조하여 사용자에게 전달하는 방식이 더 효율적이라는 것을 알게 되었고,코드 모듈화 등의 코드의 기능별로 분리하여 구현하는 것의 장점들을 피드백 받고, 프로젝트 설계 단계에서 효율적으로 설계하는 것이 그 코드를 이용하는 팀원들에게도 영향을 미치는 사실을 체감하게 된 기회였다. 내가 저렇게 구조를 짜면, 뒤에 파일 생성할떄도 나의 비효율적인 코드 로직을 따라 진행해야 하기에 , 처음에 설계를 잘했어야 하는데 어떻게 설계하는 것이 효울적으로 설계하는지에 대한 지식이 부족했기에, 효율적인 설계에 관해서 공부도 해야겠다고 느꼇다.

 

내가 생각지 못한 부분을 , 몰랏던 부분을 , 다른 관점들을 배울 수 있는 팀 프로젝트를 하게 되어 많이 감사했다.

팀원들과 프로젝트를 진행해보고, 더 나아가 다른 팀원들과 협업한 경험은 매우 귀중한 경험이었다. 다른 팀들과 협업 자체를 처음 해보았기에, 다른 팀원의 요구사항을 조율하여서 팀들끼리 조율하고, 개발한 경험은 앞으로 하게 될 프로젝트에서도 도움이 되는 귀중한 경험이라고 생각한다